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

最近云上用户用户遇到一个 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 的效果,但这个批量导入一般发生在数据导入阶段,影响比较小。

作者简介

张友东,阿里云高级技术专家,主要关注分布式存储与数据库等技术领域,先后参与淘宝分布式文件系统TFS、阿里云数据库(PolarDB、MySQL、MongoDB、Redis)等项目的开发工作,致力于让开发者用上最好的云数据库服务。

MongoDB sharding 集合不分片性能更高?》有1个想法

  1. 刚忙完有点时间,正准备写这个case分享呢,看见博主的文章已经有描述了,就不写了哈,博主提到的云上用户应该就是我,后面补充一个case,借博主留言区分享一下

    测试3:集合开启分片,bulk write(同一个bulk内相同的shardKey),chunk 已提前 split 好,能确保写入均分到3个shard
    测试3结果:3个 shard cpu 跑满,insert qps 18w 左右(平均每个分片6w左右)

    这个结果说明mongo集群在bulk-write in mongos有优化的:
    each of those targeted writes are grouped into a batch for a particular shard
    下面是这个相关问题的资料 jira &git pr(有更多的case以及源码)
    https://jira.mongodb.org/browse/SERVER-10723 (mongo官方jira)
    https://github.com/mongodb/mongo/commit/24f85cdfdba1db685f4da499d8fcb77385e57da7 (183行有注释说明)
    https://github.com/Tokutek/mongo/issues/912 (Tokutek 版mongo相关issues)

发表评论