万亿级文档数据库MongoDB集群性能优化实践

1、万亿级文档数据库MongoDB集群性能优化实践分享目录推广经验分享机房多活实现性能优化案例成本优化案例其他分享主题一如何把mongodb从淘汰边缘变为公司主流数据库？如何把mongodb从淘汰边缘变为公司主流数据库？入职前mongodb状态：集群抖动口碑差新业务想用不敢用业务考虑迁移已有mongodb到其他数据库入职一个月内集群数减少15%如何把mongodb从淘汰边缘变为公司主流数据库？我做了什么？优化集群，解决集群抖动问题内部分享性能优化方法给重点业务分享mongodb原理成立mongodb用户群业务痛点问题及其解决方案实时用户群同步如何把mongodb从淘汰边缘变为公司主流数据库？入职2

2、月后，mongodb公司内部状态：准备迁走的核心业务继续使用mongodb大数据量业务开始迁移到mongodb越来越多部门开始使用mongodb入职1年后，mongodb相关数据增长：总集群数增长比例： 700%总数据量增长比例： 2000%读写流量增长比例： 550%mongodb用户群用户数增长比例： 800%总结：mongodb赢得用户信任原因总结： 口碑分享主题二当前国内对mongodb误解(丢数据、不安全、难维护)？当前国内对mongodb误解(丢数据、不安全、难维护)？业务接入过程中经常咨询的几个问题：误解一. 丢数据？误解二. 不安全，网上一堆说mongodb被黑客攻击，截图一堆

3、新闻？ 误解三. DBA吐槽mongodb太难维护？谈谈当前国内对mongodb误解(丢数据、不安全、难维护)？误解原因：mongodb本身很优秀，但是很多DBA和相应开发把控不住国内系统性分析mongodb内核实现原理相关资料欠缺网络社会以讹传讹，DBA或者相关开发自身把控不住演变为mongodb的锅分享主题三mongodb机房多活方案-实现成本、性能、一致性三丰收社区mongodb双向同步方案(放弃该方案)机 房 A mongodb集群放弃该方案原因：成本高数据一致性问题人力原因机房A 客户端机 房 B mongodb集群机房B 客户端mongodb同步系统oppo互联网mongodb:杨

4、亚洲方案一：同城三机房多活方案(1mongod+1mongod+1mongod方式)存储层B机房 mongod(从)A机房 mongod(主)C机房 mongod(从)B机房 mongod(从)A机房 mongod(主)C机房 mongod(从)shard-1shard-nA机房Client代理层客户端A机房 mongosB机房 mongosC机房 mongosB机房ClientC机房Clientoppo互联网mongodb:杨亚洲1. 代理高可用；3. nearest就近访问2.任一主机房异常，快速选主4. 弊端：异地机房存在跨机房写场景方案二：同城两机房多活方案（2mongod+2mong

5、od+1arbiter模 式）存储层shard-1A机房Client代理层客户端A机房 mongosB机房 mongosB机房ClientA机房 mongod(主)C机房 mongod (arbiter)B机房mongod(从)B机房mongod(从)A机房mongod(从)shard-nA机房 mongod(主)C机房 mongod (arbiter)B机房mongod(从)B机房mongod(从)A机房mongod(从)oppo互联网mongodb:杨亚洲1. 代理高可用；3. nearest就近访问2.任一主机房异常，快速选主4. 弊端：异地机房存在跨机房写场景方案三：异地三机房多活方案

6、(1mongod+1mongod+1mongod方式)-解决 跨机房写存储层B机房 mongod(从)A机房 mongod(主)C机房 mongod(从)B机房 mongod(从)C机房 mongod(主)A机房 mongod(从)shard-1shard-3代理层客户端A机房 mongosB机房 mongosC机房 mongos每个机房代理通过打标签的方式，代理转发数据到主节点在本机房的分片上去。A机房数据转发到分片shard-1，B机房数据转发到分片shard-2，C机房数据转发到分片shard-3。B机房ClientA机房ClientC机房ClientA机房 mongod(从)B机房 m

7、ongod(主)C机房 mongod(从)shard-2oppo互联网mongodb:杨亚洲分享主题四mongodb线程模型瓶颈及其优化方法mongodb默认线程模型(一个链接一个线程)说明：listener线程负责接受所有的客户端链接listener线程每接收到一个新的客户端链接就创建一个线程，该线程只负责处理该链接请求处理。该网络线程模型缺陷：一个链接创建一个线程，如果10万个链接，那么就需要10万个线程，系统负责、内存消耗也会很多当链接关闭的时候，线程销毁，频繁的线程创建和消耗进一步增加系统负载典型案例：1. mysql默认方式、mongodb同步线程模型配置，适用于请求处理比较耗时的场

8、景，如数据库服务新连接fd-n创建 线程新连接fd1listener线程worker线程线程1client客户端oppo互联网mongodb:杨亚洲线程n线程2mongodb默认线程模型(动态线程模型：单队列方式)说明：该模型把一次请求转换为多个任务：mongodb数据读操作(网络IO)、db层数据访问(磁盘IO)。任务入队到全局队列，线程池中的线程从队列中获取任务执行。同一个请求访问被拆分为多个任务，大部分请求下通过递归调用同一个请求的多个任务会由同一个线程处理；。当任务太多，系统压力大的时候，线程池中线程数动态增加；当任务减少，系统压力减少的时候，线程池中线程数动态减少；该网络线程模型缺陷

9、：1.线程池获取任务执行，有全局锁竞争，这里就会成为系统瓶颈典型案例：1. mongodb动态adaptive线程模型，适用于请求处理比较耗时的场景，如数据库服务线程1任务n锁竞 争任务1线程2线程n全局队列worker动态线程池调度状态机调 度模块client请求oppo互联网mongodb:杨亚洲说明：把一个全局队列拆分为多个队列，任务入队的时候按照session链接hash散列到各自的队列，工作线程获取获取任务的时候，同理通过同样的hash 算法去对应的队列获取任务，通过这种方式减少锁竞争，同时提升整体性能。典型案例：1. mongodb内核多队列adaptive线程模型优化，特定场景性

10、能有很好的提升，适用于请求处理比较耗时的场景，如数据库服务。mongodb优化后线程模型(动态线程模型-多队列方式)线程1任务n锁1任务1线程2队列1worker动态线程池线程n-1线程n任务n锁2任务1队列2任务n锁3任务1队列n.调度hash散列client请求oppo互联网mongodb:杨亚洲分享主题五并行迁移-集群扩容速率N倍提升优化实践并行迁移-集群扩容速率N倍提升优化实践(高版本)mongod(主)shard1clientsmongos1mongod (从)mongod(从)mongod(主)mongos2mongod (从)mongod (从)mongod(主)mongod (

11、从)mongod (从)shard2shard_ n.mongod(主)新增分 片1mongod (从)mongod(从)mongod(主)mongod (从)mongod (从)mongod(主)clientclientmongos_nmongod (从)mongod (从)新增分 片2新增分 片n.源分片列表mongod(主)mongod (从)mongod (从)config扩容新增分片列表.oppo互联网mongodb:杨亚洲并行迁移过程（假设需要迁移的表名为：test， 从3节点扩容到6节点）：选取需要迁移的块，假设源集群有M分片，扩容新增N分片，则一般情况需要迁移的块=min(M,

12、N)迁移步骤：1. configServer-master选出需要迁移的块；2. config.locks表中id=test这条记录上锁；3.通知需要迁移的源分片开始迁移；4. 迁移完成后延时10s，重 复1-4步骤实现持续性chunk数据迁移并行迁移-集群扩容速率N倍提升优化实践并行迁移步骤：说明：假设需要迁移的表名为test， 源分片数M，扩容后新增分片数NconfigServer-master选出需要迁移的块，一般S=min(M, N)，也就是M和N中的最小值；config.locks表中获取id=test这条记录对应的分布式锁； 3.异步通知需要迁移的S个源分片开始迁移；等待S个chu

13、nk迁移完成迁移完成后延时10秒重复步骤1-5并行迁移-集群扩容速率N倍提升优化实践并行迁移瓶颈：获取分布式锁时间太长，原因：config.locks表中id=test表的分布式锁可能被其他操作锁住configServer异步通知源分片中的S个分片同时开始迁移数据到目的分片，任一个chunk迁移慢会拖累整个迁移 过程。本批次确认迁移完成后，还需要延时10s；一般SSD服务器，一个chunk迁移都在几百ms内完成。优化方法：避免其他操作占用分布式锁，例如splite我们可以关闭autoSplite功能，或者调大chunksizeconfigServer并行迁移不把多个分片的并行迁移放到同一个逻辑

14、，而是放到各自的逻辑。延时放到各自分片迁移逻辑里面控制，不受全局延时控制分片延时可配置，支持实时动态命令行调整分享主题六:性能优化案例案例1.千亿级核心元数据mongodb集群性能数倍提升优化实践 案例2.万亿级数据量mongodb集群性能数十倍提升优化实践案例1.千亿级数据量mongodb集群性能数倍提升优化实践-背景业务背景：核心元数据数据量千亿级前期写多读少，后期读多写少高峰期读写流量百万级时延敏感数据增长快，不定期扩容同城多活集群案例1.千亿级数据量mongodb集群性能数倍提升优化实践-优化过程优化策略1：部署及使用方式优化预分片，写入负载均衡。WriteConcern： w: ma

15、jority，写大部分节点成功才返回客户端OK读写分离，读从优先。enableMajorityReadConcern关闭，有性能损耗。案例1.千亿级数据量mongodb集群性能数倍提升优化实践-优化过程优化策略2：存储引擎cache淘汰策略优化wiredtiger存储引擎cache淘汰策略相关的几个配置如下:wiredtiger淘汰相关配置默认值工作原理eviction_target80%当用掉的内存超过总内存的百分比到 eviction_target， 后台evict线程开始淘汰eviction_trigger95%当用掉的内存超过总内存的 eviction_trigger，用户线 程也开始

16、淘汰eviction_dirty_target5%当cache中脏数据比例超过 eviction_dirty_target，后 台evict线程开始淘汰eviction_dirty_trigger20%当cache中脏数据比例超过 eviction_dirty_trigger, 用 户线程也开始淘汰evict.threads_min4后台evict线程最小线程数evict.threads_max4后台evict线程最小线程数wiredtiger存储引擎cache淘汰策略优化后配置:eviction_target: 75%，eviction_trigger：97%，eviction_dirty_

17、target: %3，eviction_dirty_trigger：25%，evict.threads_min：4， evict.threads_max：16总体思想：evict线程尽早淘汰脏页page到磁盘，增加evict淘汰线程数加快脏数据淘汰，避免用 户请求线程进行脏数据淘汰。案例1.千亿级数据量mongodb集群性能数倍提升优化实践-优化过程优化策略3：存储引擎checkpoint优化存储引擎checkpoint检测点，把当前存储引擎脏数据全部记录到磁盘。触发条件如下: 1.固定周期做一次checkpoint快照，默认60s2.增量journal日志达到2G少部分实例存在如下现象：一会

18、儿磁盘IO几乎空闲0%，一会儿磁盘IO短暂性100%。进行如下优 化后可以缓解该问题:checkpoint=(wait=30,log_size=1GB)该优化总体思路：缩短checkpoint周期，减少checkpoint期间积压的脏数据，缓解磁盘IO高问题。 遗留问题：SSD盘只有极少数节点有该问题，原因未知，后续继续跟踪。.存储层B机房 mongodA机房 mongodC机房 mongodB机房 mongodA机房 mongodC机房 mongodshard-1shard-n.代理层客户端A机房 mongosB机房 mongosC机房 mongos瓶颈点：代理缓存所有客户端的链接信息到内存

19、中，并定期更新到config库的system.sessions表中。大流量大数据量集群客户端链接众多，大量更新sessions表，最终主分片性能下降引起整个集群性能瞬间数倍下降。ClientClientClient案例1.千亿级数据量mongodb集群性能数倍提升优化实践-优化过程oppo互联网mongodb:杨亚洲system.sessions优化： 优化前架构图.存储层B机房 mongodA机房 mongodC机房 mongodB机房 mongodA机房 mongodC机房 mongodClientshard-1shard-n.Client代理层客户端A机房 mongosB机房 mongo

20、sC机房 mongos优化方法：config库的system.sessions表启用分片功能。mongos定期更新优化为散列到不同时间点进行更新。Client案例1.千亿级数据量mongodb集群性能数倍提升优化实践-优化过程oppo互联网mongodb:杨亚洲system.sessions优化： 优化后架构图案例1.千亿级数据量mongodb集群性能数倍提升优化实践-优化过程优化策略4：sharding集群system.session优化该优化总体思路：之前代理集中式更新单个分片，优化为散列到不同时间点更新多个分片。该优化后system.sessions表更新引起的瞬间性能数倍降低和大量慢日

21、志问题得到了解决。案例1.千亿级数据量mongodb集群性能数倍提升优化实践-优化过程优化策略5：tcmalloc内存优化db.serverStatus().tcmalloc监控发现部分mongod实例pageheap、内存碎片等消耗过高。通过系统 调用分析得出：内存碎片率、pageheap过高，会引起分配内存过程变慢，引起集群性能严重下降。该优化总体思路：借助gperftools三方库中tcmalloc内存管理模块，实时动态调整tcmalloc内存Release Rate，尽早释 放内存，避免存储引擎获取cache过程阻塞变慢。案例2.万亿级数据量mongodb集群性能数倍提升优化实践业务背

22、景：集群存储离线数据集群总数据量万亿级前期主要为数据写入，要求万亿级数据几周内尽快全部写入集群后期主要是读流量，单次查询数据条数比较多，要求快速返回每隔一定时间周期(周为单位)会有持续性大量写入案例2.万亿级数据量mongodb集群性能数倍提升优化实践优化策略1：基础性优化分享主题六中读写分离、预分片、wiredtiger存储引擎优化、session优化、tcmalloc使用优 化等基础性优化策略同样适用于该集群，具体详见分享主题六:百万级高并发读写/千亿级数据 量mongodb集群性能数倍提升优化实践案例2.万亿级数据量mongodb集群性能数倍提升优化实践优化策略2：存储模型优化前状况 优

23、化前数据模型结构如下：_id: ObjectId(5fh2ebd18856960dbac31abc), characteristic: xxxx,key1: *,keyn: *,以上为单条数据的数据模型，该集群总数据量万亿级。数十万条数据拥有同样的characteristic特性，总特性数总计数百万个。一次性查询数十个characteristic很慢。瓶颈点： 一次性查询数十个characteristic特征条件的数据，每个特征拥有数百万数据，一次查询总计千万行数据。由于数据量很 大，每行数据几乎全在磁盘，一次查询需要千万次IO操作，查询成为瓶颈。案例2.万亿级数据量mongodb集群性能数倍

24、提升优化实践优化策略2：第一轮数据存储模型优化：_id: ObjectId(5f29ebd18856960dbac31abc), characteristic: xxxxgroup: key1: *keyn: *,#该characteristic下第一条数据key1: *keyn: * #该characteristic下第n条数据该数据模型把相同characteristic特性的数十万数据合并到为一条数据，减少磁盘IO操作，整个读性能会有近百倍提升。瓶颈点：该轮优化解决了读瓶颈，却引入了新的写瓶颈。1. 向group数组中写入数据，数据长度越来越长，写性能成为新的瓶颈。案例2.万亿级数据量mo

25、ngodb集群性能数倍提升优化实践优化策略2：第二轮数据存储模型优化：_id: ObjectId(5f29ebd18856960dbac31abc), characteristic: xxxx,heshNum: num, group: key1: *,keyn: *,#该characteristic下第一条数据key1: *,keyn: *, #该characteristic下第n条数据如上，把同一个characteristic特征的数十万数据散列为500份，这样合并后group数组中也就只包含数百条数据信息，这样合并后单条数据过大、mongodb单条数据最大限制等瓶颈问题都可以得到解决。总体

26、数据模型优化思路：通过合理的数据合并操作来减少网络IO、磁盘IO、mongodb内核处理时间，最终使读和写达到平衡。分享主题七成本节省-记某服务千亿级数据迁移mongodb，百台SSD服务器节省优化实 践成本节省-千亿级数据迁移mongodb，百台SSD服务器节省优化实践迁移背景：需要迁移的数据量数千亿级源集群磁盘紧张，业务写入快，需要快速完成数据迁移源集群数据存储于高io ssd服务器业务对性能没太高要求目的mongodb集群采用低io 大容量sata盘迁移难点：如何快速完成数据迁移？成本节省-千亿级数据迁移mongodb，百台SSD服务器节省优化实践瓶颈点：由于目的集群为低io大容量sata盘，迁移太慢，源集群磁盘有写满风险单向同步系统源集群/SSD目的mongo集群/SATA写入快Client迁移慢成本节省-千亿级数据迁移mongodb，百台SSD服务器节省优化实践优化策略：同步数据到大容量SSD中转集群拷贝中转集群数据到目标大容量SATA盘服务器加载数据单向同步系统源集群/SSD写入快Client同步