ITPub博客

首页 > 数据库 > NoSQL > 如何“玩转”MongoDB?罗辑思维数据库性能优化之路!

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

原创 NoSQL 作者:李代丽 时间:2019-03-14 11:09:47 0 删除 编辑

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

▲罗辑思维首席DBA李丹老师

但是,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的方式快速创建索引。而对特定版本高并发、短连接导致负载高,可降级认证策略,或者业务采用连接池……

针对更多避免采坑的案例,这里先留个悬念,DTCC2019数据库技术大会当天会做具体分享。近年来,数据库的发展可谓日新月异,熟练掌握MongoDB运维知识体系,学习更多关于MongoDB的最佳实践经验,可以为DBA或开发人员的职业发展带来更大的竞争力。

总之,不管是从MongoDB本身成熟度来看,还是从技术人员个人发展的角度考虑,都非常建议大家现在就开始尝试MongoDB,也期望MongoDB能让你收获更多惊喜。

最新的DTCC大会动态,关注 http://dtcc.it168.com/ 或长按并试别下方二维码即可直达。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31545808/viewspace-2638355/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-09-19

  • 博文量
    65
  • 访问量
    96508