如何“玩转”MongoDB？罗辑思维数据库性能优化之路！

Posted 2021-05-01 java架构学习专栏

当整个世界由IT走向DT时代，数据库领域也发生了重大变化，NoSQL成为企业应用常态，这也是MongoDB之所以受欢迎的根本原因。MongoDB介于关系数据库和非关系数据库之间，支持的数据结构非常松散，类似json的bson格式，可存储比较复杂的数据类型。因此，MongoDB可以让开发人员上手更快、系统更容易扩展。

但是，MongoDB到底适用于哪些场景? 在使用MongoDB的时候，需要注意些什么？MongoDB和mysql相比，有何区别？对于一个新手DBA来说，应该从何处入手？可能很多人，都不是特别清楚！在第十届数据库技术大会（DTCC 2019）即将到来之际，罗辑思维首席DBA李丹老师，接受了ITPUB专访，结合罗辑思维的数据库性能优化与实践经验，为我们带了很多干货内容。

一切以业务为中心，MongoDB选型之初

“引入MongoDB，主要是为了解决MySQL集中式架构带来的弊端，包括对海量数据存储、读写分离及弹性扩展不够灵活等问题。” 李丹老师首先介绍了MongoDB选型的初衷。

李丹，有近10年的专职数据库从业经验，主要从事MySQL、MongoDB自动化运维及私有云平台建设，曾专注于开源数据库MySQL、MongoDB等相关技术领域的学习与研究。

其实，罗辑思维整体的数据库架构设计思路，和大多数互联网创业公司的发展脉络差不多。在早期的时候，罗辑思维的数据库完全依赖云厂商，但是随着业务的发展，之前的过度依赖逐渐暴露出了一些缺陷，比如：故障响应速度不够迅速、批量管理不够自动化、资源配置不能按需扩缩容、数据库与数据仓库实时数据不能友好同步等等，类似问题变得越来越棘手。而MongoDB适合大部分OLTP场景，比如：需求频繁变化的游戏业务、要求实时上报的物联网数据、外卖类地理位置查询、TB或PB级别的海量数据存储及99.999%的高可用要求等。特别是MongoDB4.0，引入了事物概念，这对一些具有数据强一致性需求的业务场景来说，也有了更多的选择。当然，没有任何一种数据库能100%适用于所有应用场景，如果你的业务具有很复杂的关联查询，或金融类的业务，那暂时不推荐使用MongoDB。

对于罗辑思维的数据库选型我们通常准从这几个原则：1、一切以业务为中心，什么适合业务需求就用什么； 2、技术社区足够活跃，生态圈相对完善； 3、数据库技术被业界认可，与之相对应的市场人才丰富； 4、数据库相对成熟稳定，案例丰富； 5、DBA和开发人员对数据库都相对熟悉，运维成本低。

增加数据库弹性扩展能力，

MongoDB价值凸显

现在，我们已开始尝试混合云模式，其中数据库类型主要是MySQL和MongoDB，当然Redis缓存数据库我们也广泛使用。MySQL主要分普通主从结构，以及读写分离架构。MySQL虽然优势明显，简单可依赖，用户基数大，案例极其丰富，社区非常活跃，周边工具集完善；但是劣势也非常明显，那就是关系表的不灵活性，高可用及读写分离依赖第三方插件，无法做到弹性扩展等等。

与MySQL相比，MongoDB有着浑然天成的优势，灵活的json类文档模型、丰富的数据压缩模式，可调一致性，基于raft协议的自动高可用等。尤其是mongos分片集群，能让数据自动切片及自动数据均衡，为分布式架构的弹性容量及性能扩展提供了友好的支撑。大家可能比较关心的是如何在高可用切换的时候，如何能实现对业务的透明化？我们采用了“MongoDB+consul”方案，当然也有人采用lvs+MongoDB等。

MongoDB给罗辑思维带来了很大的改变：第一， mongos分布式集群架构，让我们面在对海量数据和高并发的场景下，也能轻松的保证容量及性能的弹性扩、缩容；第二，基于raft协议的自动高可用，给运维带来了极大的便利，无需引入第三方中间件，就能保证业务99.999%的可用性；第三，各语言的MongoDB驱动基本都实现了读写分离功能，在无需引入第三方中间件情况下，轻松实现5种读策略的控制；第四，提供snappy、zilib压缩比达2~5倍的多种不同的数据压缩模式，极大地节约了存储成本。MongoDB很大程度上降低了我们的运维成本，这也让我们有更多的时间在业务早期即可与研发工程师深度配合，进行设计优化。

把握数据库发展趋势，

新手DBA需避免“踩坑”

“坦白说，在刚接触MongoDB的时候，对它的类js语法结构、分布式数据库的理论及运维方式等，感觉很不习惯” 李丹老师如是说。MongoDB是文档型数据库，在使用初期会不太习惯，尤其在使用方式及运维思路上，大多数关系型数据库DBA都会感觉不适应。但是，随着对MongoDB了解的加深，特别是如果经历过大规模的运维实践的考验，你便能切身体会到MongoDB给工作带来的便利性。

 

不过，在MongoDB的构建过程中，的确有很多需要注意的关键点，需要考虑不同场景下的数据迁移问题，比如集群间业务拆分的数据迁移、数据库版本升级的数据迁移、机房间的数据迁移等等。一些不熟悉MongoDB的同行，在做机房迁移的时候，他们认为需要在对应机房搭建一套新集群。实际上，这种方式利用好MongoDB自动高可用特性，直接在对应机房扩节点后，进行高可用切换，就能轻松完成。当然，如果是跨版本数据的迁移一定要注意兼容性，MongoDB在有些版本的特性支持上，可能变化较大。

关于MongoDB的运维，也存在很多问题。比如：读写一致性问题，默认配置的情况下，主节点故障切换可能会引发数据回滚，建议一般配置”写大多数”模式。MongoDB3.4版本，SCRAM-SHA-1的认证策略，可能在高并发短连接模型下会出现cpu负载飙高的情况，这个时候需要对认证策略回退。针对性能优化，通常要对研发人员进行使用及索引优化方面的培训，核心业务DBA会深入业务层面，指导设计与优化。当然我们也会做一些事后的补救措施，如自动分析索引的使用情况、自动慢查询分析推送等等。对于负载过高的情况，可能引发的因素很多。一般来说可能是因为慢查询，特定版本高并发短连接问题等等。通常状态下，如果是阻塞至无法登录，可能需要强制shutdown节点，以rolling的方式快速创建索引。而对特定版本高并发、短连接导致负载高，可降级认证策略，或者业务采用连接池……