MongoDB sharding 集合不分片性能更高?

213 阅读2分钟

最近云上用户用户遇到一个 sharding 集群性能问题的疑惑,比较有代表性,简单分享一下

测试配置

  • mongos x 2、shard x 3
  • 测试1:集合不开启分片,批量 insert 导入数据,每个 batch 100 个文档
  • 测试2:集合开启分片,随机生成 shardKey,chunk 已提前 split 好,能确保写入均分到3个shard

测试结果

  • 测试1:单个 shard cpu 跑满,insert qps 在 6w 左右
  • 测试2:3个 shard cpu 跑满,insert qps 在 7w 左右(平均每个分片2.4w左右)

注:两个测试里,mongos 都不是瓶颈,能力足够

从测试结果看,每个shard都承担 1/3 的负载,的确达到横向扩张的目的,但为啥分片之后,单个shard的能力就下降了呢?如果是这样,sharding的扩展能力如何体现?

结果分析

这里核心的问题在于 batch insert 在 mongos 和 mongod 上处理行为的差别

  1. 导入数据时,一次 insert 一条数据,和一次 insert 100 条数据,性能差距是很大的;首先减少了client、server 端之间的网络交互;同时 server 可以将 batch insert 放到一个事务里,降低开销;
  2. mongos 在收到 batch insert 时,因为一个 batch 里的数据需要根据 shardKey 分布到不同的shard,所以一个 batch 实际上需要被拆开的;这里 mongos 也做了优化,会尽量将连续的分布在一个shard上的文档做 batch 发到后端 shard。
  3. 在集合不开启分片的情况,mongos 收到的 batch 肯定是转发给 primary shard,所以转发过去还是一整个 batch 操作; 而在集合开启分片的情况下,因为用户测试时,shardKey 是随机生成的,基本上整个 batch 被打散成单条操作,逐个往后端 shard 上发送,请求到后端 shard 基本已经完全没有合并了。

所以在上述测试中,不分片的单个 shard 6w qps、与分片后每个 shard 2.4w qps,实际上就是请求是否 batch 执行的差别。

对应用的影响

从上面的分析可以看出,batch 往分片的集合写入时,因为无法预知数据应该分散到哪个分片,实际上往后端 shard 写入时,会失去 batch 的效果,但这个批量导入一般发生在数据导入阶段,影响比较小。


本文作者:张友东

原文链接

本文为云栖社区原创内容,未经允许不得转载。