mongodb 3.4与 mongodb 3.2性能对比

2016年12月1日，mongodb 发布 3.4 版本，按照官方 release note，分片集群和复制集合相较 3.2 版本主要有如下改动：

分片集群（Sharded Cluster）部分：

• Membership Awareness

MongoDB 3.4 里，分片集群的所有组件，Config server、mongod、mongos 都能相互感知整个分片集群的存在，了解整个分片集群的配置信息，这样能避免分片集群的误配置，比如在现在的版本，有可能会将一个 shard 错误的加到多个 sharded cluster 了。这个特性引入了如下限制：分片集群里 mongod 启动时，必须显式配置 sharding.clusterRole 为 shardsrv；3.4 版本的 mongos 不能连接低版本的 mongod。

• Config server 的 Primary 节点负责负载均衡

MongoDB 3.2 及以前版本里，分片集群的负载均衡由 mongos 负责，多个 mongos 会抢一个分布式锁，抢锁成功的 mongos 会对执行负载均衡任务，在 shard 间迁移 chunk；在 3.4 版本里，负载均衡将由 Config server 的 Primary 节点负责，预计会在负载均衡并发度及效率上会有大的提升。

• 不再支持 SCCC Config server 的模式

MongoDB 3.2 版本引入了复制集模式的 Config Server（CSRS 模式），在此之前，Config server 由多个镜像的单节点组成（SCCC 模式），3.4 版本里，MongoDB 将不再支持 SCCC 模式的 Config server。所以往 3.4 版本升级时，如果 Config server 还是 SCCC 模式，需要先 升级为 SCRS 模式。

• Sharding Zones

分片集群里引入了 Zone 的概念，主要取代现在的 tag-aware sharding 机制，能将某些数据分配到指定的一个或多个 shard 上，这个特性将极大的方便 sharding cluster 的跨机房部署，详细了解 Sharding zone 机制。

• Faster Balancing

使用 wiredtiger 引擎时，moveChunk 的 secondaryThrottle 选项默认设置为 false，即不用等待迁移的数据复制到 secondary 节点 ； 支持并行的 chunk 迁移，对于包含 N 个 shard 的 sharding 集群，MongoDB 最多可以同时跑 N/2 个迁移任务。

复制集（Replica Set）部分

• majority WriteConcern 支持配置是否刷 journal

配置复制集时，增加 writeConcernMajorityJournalDefault 选项，默认为 true，即当指定 WriteConcern 为 majority 时，数据写到大多数节点并且 journal 成功刷盘后，才向客户端确认成功；如果为 false，数据写到大多数节点的内存，就向客户端确认。

• 支持配置 Primary 追数据的时间

配置复制集时，增加 catchUpTimeoutMillis 选项，默认为 2s，来指定新选举出来的 Primary 从其它拥有更新数据的节点追数据的时间，增加该时间能最大限度的减少需要 rollback 的数据，但可能增加整个 failover 的时间，该选项只能在 protocolVersion 为 1 时使用。

• 支持 Linearizable Read Concern

"linearizable" Read Concern 级别保证，一定能读到 WriteConcern 为 majority，并且确认时间在读请求开始之前的数据，该级别仅在查询结果只有单个文档的情况下有效。

• 提升全量同步

在拷贝数据的时候，同时建立所有的索引（以前版本只有id 索引是在同步数据时建立的）；拷贝数据的阶段，secondary 不断拉取新的 oplog，确保 secondary 的 local 数据库有足够的空间来存储这些临时数据。

• Decimal Type

MongoDB 3.4 新增对 decimal128 format的支持，最多支持 34 位小数位。跟 Double 类型不同，decimal 数据存储的是实际的数据，无精度问题，以 9.99 为例，decimal NumberDecimal("9.99") 的值就是 9.99； 而 Double 类型的 9.99 则是一个大概值 9.9900000000000002131628......

• Aggregation

MongoDB 在 3.4 版本增加了大量的 aggregation 操作符，功能更加强大了，举几个例子 bucket 能对方便的对数据进行分类；

$grahpLookup 在 3.2 的$lookup 的基础上更进一步，能支持更复杂的关系运算了；

$addFields 使得文档操作更丰富了，比如将某些字段求和存储为新的字段。

详细的介绍请参考 Aggregation 部分

• Collation and Case-Insensitive Indexes

MongoDB 3.4 开始支持 collation，在之前的版本里，文档里存储的字符串，不论是中文还是英文，不论大小写，一律按字节来对比，引入 collation 后，支持对字符串的内容进行解读，可以按使用的 locale 进行对比，也支持对比时忽略大小写。

create、createIndexes、find、aggregate 等涉及字符串操作的命令都支持 collation。

• 视图（Views）

MongoDB 3.4 里增加了对 只读视图的支持，视图将集合里满足某个查询条件的数据虚拟成一个特殊的集合，用户可以在特殊的集合上做进一步的查询操作。

• 安全提升（Security Enhancement）

MongoDB 3.4 支持轮转的将复制集、或分片集群的各个节点开启鉴权，不需要停服务，详细步骤参考 Enforce Keyfile Access Control in a Replica Set without Downtime

• 工具（MongoDB Tools）

MongoDB 3.4 引入 mongoreplay 工具，可用于监控并记录 mongod 上执行的命令并 replay 到另一个 mongod 实例上，该工具可用于代替 mongosniff。

下面针对 Mongodb3.2 和 Mongodb3.4 在 kw 级文档记录下，不同并发时 读写性能的表现进行评测：

测试条件：

ts90 机型，256g 内存，12*800G SSD，2 个 12 核 cpu（已开启超线程）

系统参数：关闭 numa、设置 THP（transparent_hugepage）为 never，swappiness 设置为 0，文件系统 ext4，关闭 atime

mongodb 配置：3.2 和 3.4 版本配置一致，核心参数如下 syncPeriodSecs: 60 journal:enabled: true wiredTiger:engineConfig:cacheSizeGB: 35

测试方法：

1、用 100-200-500-1000 并发，分别导入 1000000w 文档，测试不同并发下写入性能差异；

2、在 1000000 文档基础上，用 100-200-500-1000 并发，80%读取请求，20%更新请求，测试不通并发下，混合场景 mongodb 的吞吐和读取时延。

一、写入速度对比：

二、80%写入、20%读取情况下，系统吞吐（ops/sec）对比

三、混合读写情况相爱，系统读取平均响应耗时对比

结论：

• 在当前测试的 4 种并发场景下，100 并发时， mongdodb3.4 和 3.2 的表现性能最优；
• 写入性能上，mongodb3.4 和 3.2 提升有限，约 2%；
• 混合场景中，mongodb3.4 吞吐高于 3.2，约 7%；
• 虽然 mongodb3.4 相较于 3.2 在读写性能上提升有限，但 WT 引擎一直在不断优化，且如文初描述 3.4 新版本在同步性能、Aggregation 操作、视图、分片规范和安全性上还是有很多改动，对同步压力大、嵌套 query 较多等业务场景依然建议予以升级尝试。