杨亚洲，前滴滴出行专家工程师，现任OPPO文档数据库MongoDB负责人，负责数万亿级数据量文档数据库MongoDB内核研发、性能优化及运维工作，一直专注于分布式缓存、高性能服务端、数据库、中间件等相关研发。后续持续分享《MongoDB内核源码设计、性能优化、最佳运维实践》。

前言

一、业务迁移背景

• 已有数据量400亿左右

• 数据磁盘消耗总和30T左右

• 读写峰值流量4-5W/s左右，流量很小

• 同城两机房多活容灾

• 读写分离

• 每月预计增加200亿数据

• 满足几个月内1500亿新增数据需求

 分片数及存储节点套餐规格选定评估过程如下：

我司都是容器化部署，以往经验来看，MongoDB对内存消耗不高，历史百亿级以上MongoDB集群单个容器最大内存基本上都是64Gb，因此内存规格确定为64G。

业务流量峰值3-5W/s，考虑到可能后期有更大峰值流量，因此按照峰值10W/s写，5w/s读，也就是峰值15W/s评估，预计需要4个分片。

MySQL中已有数据400亿，磁盘消耗30T。按照以网线上迁移经验，MongoDB默认配置磁盘消耗约为mysql的1/3-1/5，400亿数据对应MongoDB磁盘消耗预计8T。考虑到1500亿数据，预计4个分片，按照每个分片400亿规模，预计每个分片磁盘消耗8T。

线上单台物理机10多T磁盘，几百G内存，几十个CPU，为了最大化利用服务器资源，我们需要预留一部分磁盘给其他容器使用。另外，因为容器组套餐化限制，最终确定确定单个节点磁盘在7T。预计7T节点，4个分片存储约1500亿数据。

由于容器调度套餐化限制，因此CPU只能限定为16CPU(实际上用不了这么多CPU)。

此外，由于分片集群还有mongos代理和config server复制集，因此还需要评估mongos代理和config server节点规格。由于config server只主要存储路由相关元数据，因此对磁盘、CUP、MEM消耗都很低；mongos代理只做路由转发只消耗CPU，因此对内存和磁盘消耗都不高。最终，为了最大化节省成本，我们决定让一个代理和一个config server复用同一个容器，容器规格如下：

8CPU/8G内存/50G磁盘，一个代理和一个config server节点复用同一个容器。

由于该业务所在城市只有两个机房，因此我们采用2+2+1(2mongod+2mongod+1arbiter模式)，在A机房部署2个mongod节点，B机房部署2个mongod节点，C机房部署一个最低规格的选举节点，如下图所示：

说明：

迁移过程由业务自己完成，通过阿里开源的datax工具实现，该迁移工具的更多细节可以参考：https://github.com/alibaba/DataX

该集群优化过程按照如下两个步骤优化：数据迁移开始前的提前预优化、迁移过程中瓶颈分析及优化、迁移完成后性能优化。

和业务沟通确定，业务每条数据都携带有一个设备标识ssoid，同时业务查询更新等都是根据ssoid维度查询该设备下面的单条或者一批数据，因此片建选择ssoid。

为了充分散列数据到4个分片，因此选择hash分片方式，这样数据可以最大化散列，同时可以满足同一个ssoid数据落到同一个分片，保证查询效率。

MongoDB如果分片片建为hashed分片，则可以提前做预分片，这样就可以保证数据写进来的时候比较均衡的写入多个分片。预分片的好处可以规避非预分片情况下的chunk迁移问题，最大化提升写入性能。

sh.shardCollection("xxx.xxx", {ssoid:"hashed"}, false, { numInitialChunks: 8192} )

注意事项：切记提前对ssoid创建hashed索引，否则对后续分片扩容有影响。

客户端增加nearest 配置，从离自己最近的节点读，保证了读的性能。

A机房业务只配置A机房的代理，B机房业务只配置B机房代理，同时带上nearest配置，最大化的实现本机房就近读，同时避免客户端跨机房访问代理。

禁用该功能后ReadConcern majority将会报错，ReadConcern majority功能注意是避免脏读，和业务沟通业务没该需求，因此可以直接关闭。

MongoDB默认使能了enableMajorityReadConcern，该功能开启对性能有一定影响，参考：

MongoDB readConcern 原理解析

https://developer.aliyun.com/article/60553

OPPO百万级高并发MongoDB集群性能数十倍提升优化实践
https://mongoing.com/archives/29934

单个容器规格：16CPU、64G内存、7T磁盘，考虑到全量迁移过程中对内存压力，内存碎片等压力会比较大，为了避免OOM，设置cacheSize=42G。

全量数据迁移过程中，迁移速度较块，内存脏数据较多，当脏数据比例达到一定比例后用户读写请求对应线程将会阻塞，用户线程也会去淘汰内存中的脏数据page，最终写性能下降明显。

wiredtiger存储引擎cache淘汰策略相关的几个配置如下:

由于业务全量迁移数据是持续性的大流量写，而不是突发性的大流量写，因此eviction_target、eviction_trigger、eviction_dirty_target、eviction_dirty_trigger几个配置用处不大，这几个参数阀值只是在短时间突发流量情况下调整才有用。

但是，在持续性长时间大流量写的情况下，我们可以通过提高wiredtiger存储引擎后台线程数来解决脏数据比例过高引起的用户请求阻塞问题，淘汰脏数据的任务最终交由evict模块后台线程来完成。

全量大流量持续性写存储引擎优化如下：

db.adminCommand( { setParameter : 1, "wiredTigerEngineRuntimeConfig" : "eviction=(threads_min=4, threads_max=20)"})

前面章节我们提到，在容器资源评估的时候，我们最终确定选择单个容器套餐规格为如下：

16CPU、64G内存、7T磁盘。

全量迁移过程中为了避免OOM，预留了约1/3内存给MongoDB server层、操作系统开销等，当全量数据迁移完后，业务写流量相比全量迁移过程小了很多，峰值读写OPS约2-4W/s。

也就是说，前量迁移完成后，cache中脏数据比例几乎很少，基本上不会达到20%阀值，业务读流量相比之前多了很多(数据迁移过程中读流量走原MySQL集群)。为了提升读性能，因此做了如下性能调整(提前建好索引)：

上面的内核优后后，业务测时延监控曲线变化，时延更加平稳，平均时延也有25%左右的性能优后，如下图所示：

总结：

原mysql集群一共64套，每套集群4副本，每个副本容器规格：4CPU、16G mem、500G磁盘，总共可以存储400亿数据，这时候大部分节点已经开始磁盘90%水位告警，DBA对部分节点做了磁盘容量提升。

总结如下：

说明：由于MySQL迁移MongoDB后，数据不在往MySQL中写入，流量切到MongoDB时候MySQL中大约存储有400亿数据，因此我们以这个时间点做为对比时间点。以400亿数据为基准，资源消耗对比如下表(每个分片只计算主节点资源消耗，因为MySQL和MongoDB都是4副本)：

由于MongoDB四个分片还有很多磁盘冗余，该四个分片相比400亿数据，还可以写1100亿数据。如果按照1500亿数据计算，如果还是按照MySQL之前套餐规格，则MySQL集群数需要再增加三倍，也就是总集群套数需要64*4=256套，资源占用对比如下：

从上面的内容可以看出，该业务迁移MongoDB后，除了解决了业务容量痛点、促进业务快速迭代开发、性能提升外，成本还节省了数倍。成本节省总结如下：

CPU和内存成本比例：4:1

磁盘成本比例：3.3:1

CPU和内存成本比例：16:1

磁盘成本比例：3.3:1

从上面的分析可以看出，数据量越大，按照等比例换算原则，MongoDB存储成本会更低，原因如下：

主要是因为MongoDB海量数据存储及高性能原因，索引建好后，单实例单表即使几百亿数据，读写也是ms级返回(注意：切记查询更新建好索引)。

此外，由于MongoDB分布式功能，对容量评估更加方便，就无需提前一次性申请很多套mysql，而是根据实际需要可以随时加分片。

MongoDB存储引擎wiredtiger默认高压缩、高性能。

最后，鉴于客观性成本评价，CPU/内存成本部分可能会有争议，比如mysql内存和CPU是否申请的时候就申请过大。MongoDB对应CPU也同样存在该问题，例如申请的单个容器是16CPU，实际上真实只消耗了几个CPU。

但是，磁盘节省是实实在在的，是相同数据情况下mysql和MongoDB的真实磁盘消耗对比。

当前该集群总数据量已经达到近千亿，并以每个月200亿规模增加，单从容器计费层面上换算，1000亿数据按照等比例换算，预计节省成本10倍。