MongoDB分片集合性能随分片数量增长的变化及查询性能拐点咨询

1. MongoDB分片集合的性能是否会随分片数量增加而下降？ #

不是绝对的线性下降，得看具体场景：

• 当分片数量在合理范围内增加时，性能反而会提升：分片能把数据和查询负载分散到更多节点上，缓解单节点的资源压力，读、写性能都会有明显改善。
• 但分片数量超过某个阈值后，性能会开始下降：分片过多会带来额外开销——mongos路由节点需要维护更多分片的元数据，查询时要协调更多分片的返回结果，数据块均衡、心跳检测等管理成本也会上升，这些额外开销会抵消分片带来的收益。

2. 分片集合的读查询性能开始受负面影响的分片数量阈值？相关经验法则？ #

• 阈值大概在数百个分片级别，绝大多数业务到这个量级时就会开始感受到性能损耗，很少会到数千个（除非是超大规模的特殊场景）。这个阈值不是固定值，会受以下因素影响：

  • 查询模式：如果是单键分片的定向查询（仅命中单个分片），分片数量增加的影响很小；但如果是跨分片的聚合、范围查询这类需要遍历多个分片的操作，分片越多，mongos合并结果的开销就越大。
  • 硬件与部署：mongos节点的CPU、内存越强，能支撑的分片数量就越多；如果是跨机房部署分片，网络延迟会让阈值进一步降低。
  • 元数据规模：分片越多，config server存储的元数据（数据块信息、分片状态等）就越大，mongos加载和同步元数据的成本也会越高。

• 经验法则：

  • 不要为了分片而分片：先评估数据量和负载，当单节点无法承载时再考虑分片，初期分片数尽量控制在数十个以内。
  • 分片数要和物理节点、数据块匹配：确保每个分片上的数据块数量合理（一般每个分片保持10-100个数据块），避免分片数远多于实际物理节点数（比如10个物理节点却分1000个分片，会导致大量空分片或数据块过小）。
  • 盯紧关键监控指标：关注mongos的CPU使用率、元数据查询耗时、跨分片查询的结果合并耗时，当这些指标出现明显上升时，就要警惕分片数量是否过多。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture