vlambda博客
学习文章列表

该业务存储智能产品相关数据，总数据量20多亿，单个集群ES磁盘消耗约30T。业务迁移背景如下（以下为业务开发同事整理)：

源ES集群业务在两个机房各申请了一个集群，由业务自己通过双写的方式来保障数据一致性，当一个集群异常业务自己切流量到另外一个集群。

源ES集群部署架构及资源规格如下：

如上图所示，由于为了实现两机房双活容灾及单集群抖动引起的业务故障，在A机房和B机房各搭建了一个ES集群，业务通过双写来自己维护两个集群的数据一致性。

当A机房集群1异常，或者A机房掉电，则业务切流量到B机房备集群2，对应架构图如下：

A机房集群1和B机房集群2内部部署架构完全已有，单个集群总共有26个节点，每个节点都部署在容器中，单个容器规格资源如下所示：

单个集群总资源消耗如下：

两个集群总资源消耗如下：

从上面的分析可以看出，为了保障业务多活和集群高可用，业务通过双写实现，异常后业务自己判断切换，这增加了业务痛点。该架构主要痛点如下：

业务开始迁移MongoDB的时候，通过和业务对接梳理，该集群规模及业务需求总结如下：

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

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

业务读写流量很低，但是数据量较大，因此分片数确定为2个分片。

按照以往测试验证及线上真实数据迁移对比，同样的数据存入MongoDB和Es中真实磁盘消耗占比如下：

• MongoDB:Es ≈ 1：6

25亿Es真实磁盘消耗30.5T，预计MongoDB磁盘消耗5T左右，考虑到未来数据增长，我们按照50亿数据计算，预计需要10T空间。2个分片，因此每个分片5T数据，最终确定单个mongod实例容器磁盘规格5T。

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

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

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

分片及存储节点规格总结：2分片/16CPU、64G内存、5T磁盘。

mongos及config server规格总结：8CPU/8G内存/50G磁盘

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

说明：

弊端：如果是异地机房，B机房和C机房写存在跨机房写场景。如果A B C为同城机房，则没用该弊端，同城机房时延可以忽略。

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

和业务沟通确定，业务每条数据都携带有唯一_id（用户生成的，不是MongoDB内部生成），同时业务查询更新等都是根据_id维度查询该设备下面的单条或者一批数据，因此片建选择_id。

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

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

sh.shardCollection("user_xxx.user_xxx", {_id:"hashed"}, false, { numInitialChunks: 8192} )

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

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

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

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

1、MongoDB readConcern 原理解析：

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

单个容器规格：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)"})

更多存储引擎及mongodb内核涉及实现参考：

mongodb源码分析、更多实践案例细节：

https://github.com/y123456yz/reading-and-annotate-mongodb-3.6

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

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

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

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

当前已有2个表从Es迁移到该MongoDB集群，同时该业务新增了15亿其他业务数据到该集群，当前目的MongoDB集群已有近20亿数据。

由于该集群ES没有历史时延统计曲线统计，因此ES的时延统计只有以下现象(来自业务方反馈)：

查询秒级耗时，对我们业务影响挺大，感知非常明显。

从上面的监控可以看出，由于除了迁移有源Es的数据，另外还有该业务的其他业务数据流量流向该集群，因此MongoDB集群流量相比Es会更高，MongoDB整体时延约1.5ms左右，远远好于之前Es的秒级时延抖动。

原Es单个集群一共26个节点，每个节点副本容器规格：32CPU、64Gmem、2T磁盘，磁盘类型SSD，单个集群规格总结如下：

当前该MongoDB集群已有约16亿数据(其中部分为Es集群以外数据，该集群除了存储部分Es迁移过来的数据，还存储该业务线其他业务数据)，该MongoDB集群规格如下：

源Es两个集群和目的MongoDB集群资源对比如下：

说明：由于集群部署方式可能有很多冗余，上面的CPU和内存成本比对比实际上不客观，可能Es部署时候规格设置浪费。当然，MongoDB实际上CPU资源也非常空闲，所以CPU和内存指标对比无太大参考作用。

由于目的MongoDB集群中当前除了有源ES迁移过来的部分表外，还有该业务的其他数据，为了保障磁盘对比的客观性，磁盘对比选材过程如下(说明：源Es有两个集群，这里只计算单个集群单分数据的磁盘消耗，如果按照两个集群计算，磁盘成本比为12:1，这种对比方法不客观)：

通过上面的选择算法，基本上做到了同样数据在Es和MongoDB中的对比，磁盘真实消耗对比结果如下(说明：以下数据的Es磁盘占用为单个Es集群单副本方式计算结果，如果算2个Es集群，Es磁盘还需要乘2，es由我司Es开发人员提供，为了客观公平，Es按照一个集群单副本计算；MongoDB磁盘占用计算方法为2个分片主节点真实磁盘占用之和，包括数据磁盘消耗+索引磁盘消耗)：

从上面的数据对比可以看出，同样的数据Es磁盘占用约为MongoDB磁盘占用的6倍，和之前其他Es迁移MongoDB过程的数据占用比值类似。

表1文档内容如下：

 {        "_id" : null,        "channel" : null,        "content" : "04A193398BE7xxx7E080E2C3CC7B3sxxxxxxxxxC99F9520B8CD0842638DB0F550E125xxxxxxxxxxxxxDB5D3F320642A42CECD3EB5C27714524D0C1BF2A0C6B607D0DFDB669D6633A0E48C65B2623EA15E6DBB0FBF643150E18DD3D0575BDE448C03735A8841E312F8AF0D2BF67D1D357D1AB6249BF3FA4E014C5Axxxxxxxxxxxxxx30C10487667",        "create_time" : ISODate("2021-02-16T09:56:03Z"),        "duid" : "6F9E856EDDBB5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxF41B0676FB2DE2171C18450E683DE1E9523B518F266856E01B0D6855E29911E5D10F0FA7E4A8EE5816333D89296E7554F05A58",        "update_time" : ISODate("2021-02-16T09:56:03Z")   }

表2文档内容如下：

 {        "_id" : "F9654874C1A37F74DA5E862C408EDC45",        "channel" : "10001",        "content" : "BA7110279AF5XXXXXXXXX6D7ACB8D0F9XXXXXXXXXXXXXX5CDB4693BE949F70E78A20E",        "create_time" : ISODate("2021-01-21T11:49:46Z"),        "imei" : "F96548XXXXXXXXXXXXXXXXX2C408EDC45",        "update_time" : ISODate("2021-01-21T11:49:46Z")   }

由于业务开发对业务场景评估不到位，当前我司线上MongoDB和Es适用过程存在如下现象：

从线上真实业务使用情况为例，以下场景不适合MongoDB，实际上也不适合mysql等数据库：

有些业务场景，查询条件是由用户触发，查询条件不固定，可能存在多个字段的随机组合查询。MongoDB和MySQL等数据库，都需要手动创建索引，由于8字段以上的随机组合查询情况种类太多，因此很难手动建索引覆盖所有场景，所以选择Es更优，只是成本会更高。

虽然MongoDB也支持全文检索，MongoDB-4.2以下版本全文检索能力性能和ES没法比，建议全文检索适用Es。

MongoDB-4.2全文搜索已经开始支持Lucene 引擎，可能性能会有很大提升，暂时没做研究，也没做性能对比，后续有空在研究。

例如查询db.member.find({"name":{ $regex:/XXX/ }})，查询name字段包含XXX的查询，这类查询Es更优，因为mongodb、mysql等底层都是KV存储，查找KEY的时候都是从左到右比较key字符串，如果是非前缀匹配模糊查询，就需要全表扫描。

查询以某字段为开头的文档，db.member.find({"name":{$regex:/^XXX/}})这类就比较适合用mongodb查询，前缀匹配。

MongoDB和Es不同场景性能对比(以下为真实线上数据对比)：

最后，脱离业务场景评估一个数据库优劣很不合适，主流数据库都优其存在的意义，不能因为数据库在某种场景下不合适而全盘否定该数据库。

《》一文中以下观点个人认不太赞同，主要如下：

MongoDB近几年持续排名全球前五，市值近两年已翻数倍，当前市值近200亿左右。DB-Engines Ranking排名得分持续提升，说明本身有自己得市场和应用场景，而不是浪得虚名，没《从MongoDB迁移到ES后，我们减少了80%的服务器》一文中说的不堪一击。

从该文章可以看出，单个文档200多字节，MongoDB存储引擎wiredtiger默认高压缩、高性能、细粒度锁。单个复制集即可存储数十亿数据，你们用了十多个容器。

同样的数据，默认mongodb磁盘占用是Es的六分之一，加上这是日志集群，MongoDB可以采用1mongod+1mongod+1arbiter部署，规格8c/32gb/100gb 2个容器就可以满足要求。这样的部署才是合理的，成本会比同样数据Es减少数倍。如果用mongodb，本身2个8c/32gb/100gb+1个低规格选举节点容器即可搞定的事，你用了15台。

任意组合的查询不是mongodb不支持，是建索引麻烦，包括mysql、tidb等数据库都是需要手动一个一个建索引。

这本身就是个数据库选型问题，随机组合条件太多，索引不好建，你应该把索引查询条件对应索引建好后对比。不过多字段的随机组合查询，确实不适合用mongodb，建索引麻烦。

建议把mongodb对应查询索引建好，重新测试下查询性能数据。

我司最大的mongodb集群单表几千亿数据，查询2ms以内。

10亿规模对我们线上业务就是毛毛雨，我们把mongodb集群归类为如下几档：

当前我司15%-20%左右集群是百亿级以上集群，已成功实现单个集群万亿级离线数据读写存储，当前正在挑战单个万亿级实时在线数据高并发在线读写。

万亿级离线数据读写优化案例详见：

后续将分享《单集群万亿级在线数据高并发读写优化实践》

我司25%-35%以上数据存储文件、图片等元数据，甚至包括少量交易集群，非常核心，当前我司规模早已超过万亿级。

没有万能的数据库，正如上文所述，MongoDB在高并发写、固定字段索引查询方面的性能表现。此外MongoDB存储引擎高压缩高性能，在成本上面体现很明显。

业务场景很重要，不能“捧一个，踩一个”，主流数据库都有其存在的理由，排名第五绝不是浪得虚名。

不太赞成这样定义核心数据，用事务的不一定是核心数据，不用事务的也未必不是核心数据。例如我司存储的几千亿文件、图片等元数据，没有用到事务，但是是非常核心的数据，丢失会造成严重后果。

结合公司内部使用MongoDB为例，有时候出现以下情况：一些不适合MongoDB的业务场景，例如全文检索、8字段以上的随机组合查询、非前缀匹配模糊查询，这些场景本身不适合选用MongoDB，但是业务选型错误，造成使用过程中的瓶颈。

甚至有相关研发人员因为选型错误在各种群里面说：“远离mongo，珍爱生命”(该业务有全文检索需求)；此外还存在业务数组索引使用不当引起集群抖动(该业务数组用法没建索引引起)，认为MongoDB设计有问题，这些都是极不负责的行为。

通过这些真实业务接触过程中的案例，总结如下几点：