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 的效果，但这个批量导入一般发生在数据导入阶段，影响比较小。

本文作者：张友东

阅读原文

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