千亿数据扛不住，三思后还是从MySQL迁⾛了……
作者介绍
杨亚洲，前滴滴出⾏专家⼯程师，现任OPPO⽂档数据库MongoDB负责⼈，负责数万亿级数据量⽂档数据库MongoDB内核研发、性能优化及运维⼯作，⼀直专注于分布式缓存、⾼性能服务端、数据库、中间件等相关研发。后续持续分享《MongoDB内核源码设计、性能优化、最佳运维实践》。
前⾔
线上某IOT核⼼业务集之前采⽤MySQL作为主存储数据库，随着业务规模的不断增加，MySQL已⽆法满⾜海量数据存储需求，业务⾯临着容量痛点、成本痛点问题、数据不均衡问题等。
400亿该业务迁移MongoDB后，同样的数据节省了极⼤的内存、CPU、磁盘成本，同时完美解决了容量痛点、数据不均衡痛点，并且实现了⼀定的性能提升。
此外，迁移时候的MySQL数据为400亿，3个⽉后的现在对应MongoDB集数据已增长到1000亿，如果以1000亿数据规模等⽐例计算成本，实际成本节省⽐例会更⾼。迁移MongoDB后，除了解决业务痛点问题，同时也促进了业务的快速迭代开发，业务不在关⼼数据库容量痛点、数据不均衡痛点、成本痛点等问题。
当前国内很多mongod⽂档资料、性能数据等还停留在早期的MMAP_V1存储引擎，实际上从MongoDB-3.x版本开始，MongoDB默认存储引擎已经采⽤⾼性能、⾼压缩⽐、更⼩锁粒度的wiredtiger存储引擎，因此其性能、成本等优势相⽐之前的MMAP_V1存储引擎更加明显。
⼀、业务迁移背景
该业务在迁移MongoDB前已有约400亿数据，申请了64套MySQL集，由业务通过shardingjdbc做分库分表，提前拆分为64个库，每个库100张表。主从⾼可⽤选举通过依赖开源orchestrator组建，MySQL架构图如下图所⽰：
说明：上图中红⾊代表磁盘告警，磁盘使⽤⽔位即将100%。如上图所⽰，业务⼀年多前⼀次性申请了64套MySQL集，单个集节点数⼀主三从，每个
节点规格如下：
cpu：4
mem：16G
磁盘：500G
总节点数：64*4=256
SSD服务器
该业务运⾏⼀年多时间后，总集数据量达到了400亿，并以每⽉200亿速度增长，由于数据不均衡等原因，造成部分集数据量⼤，持续性耗光磁盘问题。由于节点众多，越来越多的集节点磁盘突破瓶颈，为了解决磁盘瓶颈，DBA不停的提升节点磁盘容量。业务和DBA都⾯临严重痛点，主要如下：
数据不均衡问题
节点容量问题
成本持续性增加
DBA⼯作量剧增(部分磁盘提升不了需要迁移数据到新节点)，业务也提⼼吊胆
⼆、为何选择MongoDB-附⼗⼤核⼼优势总结
业务遇到瓶颈后，基于MongoDB在公司已有的影响⼒，业务开始调研MongoDB，通过和业务接触了解到，业务使⽤场景都是普通的增、删、改、查、排序等操作，同时查询条件都⽐较固定，⽤MongoDB完全没任何问题。
此外，MongoDB相⽐传统开源数据库拥有如下核⼼优索：
优势⼀：模式⾃由
MongoDB为schema-free结构，数据格式没有严格限制。业务数据结构⽐较固定，该功能业务不⽤，但是并不影响业务使⽤MongoDB存储结构化的数据。
优势⼆：天然⾼可⽤⽀持
MySQL⾼可⽤依赖第三⽅组件来实现⾼可⽤，MongoDB副本集内部多副本通过raft协议天然⽀持⾼可⽤，相⽐MySQL减少了对第三⽅组件的依赖。
优势三：分布式-解决分库分表及海量数据存储痛点
MongoDB是分布式数据库，完美解决MySQL分库分表及海量数据存储痛点，业务⽆需在使⽤数据库前评估需要提前拆多少个库多少个表，MongoDB对业务来说就是⼀个⽆限⼤的表(当前我司最⼤的表存储数千亿数据，查询性能⽆任何影响)。
此外，业务在早期的时候⼀般数据都⽐较少，可以只申请⼀个分⽚MongoDB集。⽽如果采⽤MySQL，就和本次迁移的IOT业务⼀样，需要提前申请最⼤容量的集，早期数据量少的时候严重浪费资源。
优势四：完善的数据均衡机制、不同分⽚策略、多种⽚建类型⽀持
关于balance：⽀持⾃动balance、⼿动balance、时间段任意配置balance.
关于分⽚策略：⽀持范围分⽚、hash分⽚，同时⽀持预分⽚。
关于⽚建类型：⽀持单⾃动⽚建、多字段⽚建
优势五：不同等级的数据⼀致性及安全性保证
MongoDB在设计上根据不同⼀致性等级需求，⽀持不同类型的Read Concern 、Write Concern读写相关配置，客户端可以根据实际情况设置。此
外，MongoDB内核设计拥有完善的rollback机制来保证数据安全性和⼀致性。
优势六：⾼并发、⾼性能
为了适应⼤规模⾼并发业务读写，MongoDB在线程模型设计、并发控制、⾼性能存储引擎等⽅⾯做了很多细致化优化。
优势七：wiredtiger⾼性能存储引擎设计
⽹上很多评论还停留在早期MMAPv1存储引擎，相⽐MMAPv1，wiredtiger引擎性能更好，压缩⽐更⾼，锁粒度更⼩，具体如下：
WiredTiger提供了低延迟和⾼吞吐量
处理⽐内存⼤得多的数据，⽽不会降低性能或资源
系统故障后可快速恢复到最近⼀个checkpoint
⽀持PB级数据存储
多线程架构，尽⼒利⽤乐观锁并发控制算法减少锁操作
具有hot-caches能⼒
磁盘IO最⼤化利⽤，提升磁盘IO能⼒
其他
更多WT存储引擎设计细节可以参考：
source.wiredtiger/3.2.1/architecture.html
优势⼋：成本节省-WT引擎⾼压缩⽐⽀持
MongoDB对数据的压缩⽀持snappy、zlib算法，在以往线上真实的数据空间⼤⼩与真实磁盘空间消耗进⾏对⽐，可以得出以下结论：
MongoDB默认的snappy压缩算法压缩⽐约为2.2-4.5倍
zlib压缩算法压缩⽐约为4.5-7.5倍(本次迁移采⽤zlib⾼压缩算法)
此外，以线上已有的从MySQL、Es迁移到MongoDB的真实业务磁盘消耗统计对⽐，同样的数据，存储在MongoDB、MySQL、Es的磁盘占⽐≈1：3.5：6。
后续会有数千亿hbase数据迁移MongoDB，到时候总结同样数据MongoDB和Hbase的磁盘消耗⽐。
优势九：天然N机房(不管同城还是异地)多活容灾⽀持
MongoDB天然⾼可⽤机制及代理标签⾃动识别转发功能的⽀持，可以通过节点不同机房部署来满⾜同城和异地N机房多活容灾需求，从⽽实现成本、性能、⼀致性的“三丰收”。更多机房多活容灾的案例详见Qcon分享：
优势⼗：完善的客户端均衡访问策略
MongoDB客户端访问路由策略由客户端⾃⼰指定，该功能通过Read Preference实现，⽀持primary 、primaryPreferred 、secondary 、secondaryPreferred 、nearest 五种客户端均衡访问策略。
分布式事务⽀持
MongoDB-4.2 版本开始已经⽀持分布式事务功能，当前对外⽂档版本已经迭代到 version-4.2.11，分布式事务功能也进⼀步增强。此外，从 MongoDB-4.4版本产品规划路线图可以看出，MongoDB 官⽅将会持续投⼊开发查询能⼒和易⽤性增强功能，例如 union 多表联合查询、索引隐藏等。
更多MongoDB核⼼优势细节详见我分享的⼀篇⽂章，也欢迎各位参加讨论：
mongodb源码分析、更多实践案例细节：
github/y123456yz/reading-and-annotate-mongodb-3.6
话题讨论 | MongoDB 拥有⼗⼤核⼼优势，为何国内知名度远不如 MySQL ⾼？
xie.infoq/article/180d98535bfa0c3e71aff1662
三、MongoDB资源评估及部署架构
业务开始迁移MongoDB的时候，通过和业务对接梳理，该集规模及业务需求总结如下：
已有数据量400亿左右
数据磁盘消耗总和30T左右
读写峰值流量4-5W/s左右，流量很⼩
同城两机房多活容灾
读写分离
每⽉预计增加200亿数据
满⾜⼏个⽉内1500亿新增数据需求
说明：数据规模和磁盘消耗按照单副本计算，例如MySQL 64个分⽚，256个副本，数据规模和磁盘消耗计算⽅式为：64个主节点数据量之和、64个分⽚主节点磁盘消耗之和。
1、MongoDB资源评估
分⽚数及存储节点套餐规格选定评估过程如下：
内存评估
我司都是容器化部署，以往经验来看，MongoDB对内存消耗不⾼，历史百亿级以上MongoDB集单个容器最⼤内存基本上都是64Gb，因此内存规格确定为64G。
分⽚评估
mongodb和mysql结合业务流量峰值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规格评估
由于容器调度套餐化限制，因此CPU只能限定为16CPU(实际上⽤不了这么多CPU)。
mongos代理及config server规格评估
此外，由于分⽚集还有mongos代理和config server复制集，因此还需要评估mongos代理和config server节点规格。由于config server只主要存储路由相关元数据，因此对磁盘、CUP、MEM消耗都很低；mongos代理只做路由转发只消耗CPU，因此对内存和磁盘消耗都不⾼。最终，为了最⼤化节省成本，我们决定让⼀个代理和⼀个config server复⽤同⼀个容器，容器规格如下：
8CPU/8G内存/50G磁盘，⼀个代理和⼀个config server节点复⽤同⼀个容器。
分⽚及存储节点规格总结：4分⽚/16CPU、64G内存、7T磁盘。
mongos及config server规格总结：8CPU/8G内存/50G磁盘
2、集部署架构
由于该业务所在城市只有两个机房，因此我们采⽤2+2+1(2mongod+2mongod+1arbiter模式)，在A机房部署2个mongod节点，B机房部署2个mongod节点，C机房部署⼀个最低规格的选举节点，如下图所⽰：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。