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

澳门新濠天地娱乐网站

最近,云上的用户遇到了集群性能问题,这更具代表性。只需分享

Mongos x 2,碎片x 3

测试1:集合不打开分片,批量插入导入数据,每批100个文档

测试2:集合打开片段,随机生成shardKey,并且事先已拆分块以确保写入被均分为3个分片

测试1:单个shard cpu运行已满,插入qps大约为6w

测试2:3个碎片cpu运行满,插入qps约为7w(平均每片2.4w)

注意:在两个测试中,mongos都不是瓶颈,容量不足

从测试结果来看,每个碎片承受1/3的负荷,它确实达到了水平扩展的目的。但是在分片后,单个分片的能力会降低吗?如果是这样,分片的可扩展性如何工作?

这里的核心问题是mongos和mongod上批量插入的处理行为的差异

导入数据时,一旦插入数据,并插入100个数据,性能差距就会很大;首先,减少了客户端与服务器之间的网络交互;同时,服务器可以将批量插入放入事务中,减少开销;

当mongos收到批量插入时,因为批量中的数据需要根据shardKey分配到不同的分片,实际上需要分割批处理;这里mongos也进行了优化,并将在碎片中连续分发。标签上的文档将发送到后端分片。

在集合未打开片段的情况下,mongos接收的批处理肯定会转发到主分片,因此转发仍然是整个批处理操作;在收集开放碎片的情况下,shardKey是随机生成的,因为用户测试。基本上,整个批处理操作一个接一个地发送到后端分片,并且对后端分片的请求基本上完全未合并。

因此在上面的测试中,碎片后每个碎片的单个碎片6w qps没有碎片和2.4w qps实际上是请求是否执行之间的差异。

从上面的分析可以看出,当批量写入片段集合时,不可能预测数据应该分散到哪个片段。实际上,当写入后端分片时,批处理的效果会丢失,但这批量导入一般是在数据导入阶段发生,影响相对较小。

作者:张有东

阅读原文

本文是云栖社区的原创内容,未经许可,不得转载。