平安科技汪洋：MongoDB 的平安路

1月5日至6日即将在深圳举办的2018 MongoDB 年终盛会正在火热报名中，为使大家能对大会嘉宾及议题有更深的了解，在现场更好地互动，我们特地采访了部分嘉宾，听听数据库专家大佬们与MongoDB的故事。

受访

嘉宾

汪 洋

问

首先能否请您介绍一下自己以及您所关注的领域？

答

大家好！我来自平安科技，现在在平安云负责数据库产品部和存储产品部两个部门。多年来我一直从事和数据库、存储还有操作系统相关的工作。当前，我的关注领域主要集中在数据库技术，如果按照产品分类，包括RDBMS、NoSQL、NewSQL等；如果按照负载分类，包括MPP OLAP和HTAP等。因为现在负责云数据库和云存储，所以也对Cloud Database、iSDS、mSDS等相关领域的技术比较感兴趣。此外，对Docker以及K8S技术也非常关注，如何将云数据库产品大规模容器化部署是目前思考的课题之一。

问

您是怎么开始接触到MongoDB的呢？

答

MongoDB大概是5年前开始接触，想起来也有一定的偶然性。在一次公司的数据库架构评审中，发现了一个开发团队使用了一个叫做MongoDB的新型数据库产品。当时，还有些许的质疑，也象很多人一样，以为是“芒果数据库”，怎么起这么一个有点搞笑的名字？不过，也正是因为这件事情，让我开始关注NoSQL领域的产品和技术，了解它们的特性和适用的应用场景，毕竟技术是服务于场景的，也正是因为有这些场景才催生和完善了技术，推动着技术进步。我了解到MongoDB并不是MangoDB，而是Humongous，代表海量的意思。从设计之初，产品的初衷就是要让对海量数据的存储和访问更加便捷。

问

和传统数据库相比，MongoDB有哪些优势使得您的团队选择了它？

答

正如我前面所说，MongoDB的设计初衷是存储和访问海量的数据，所以其中一个优势就是它的海量数据存储能力。MongoDB是一个原生的分布式数据库，它不需要象其他很多数据库一样，需要你使用各种开源组件来拼接来构成一个分布式的架构。MongoDB产品本身就是一个分布式架构的产品，数据的分片，扩容/缩容时数据的自动均衡，数据的路由，分片信息的存取以及高可用，所有这些都紧密地集成在一起，成为整个产品不可分割的一部分。除了这一点，还有两点我也想简单提一下。第一对于开发人员来说，相对于RDBMS，MongoDB容易上手，学习成本较低，限制也较少，可以快速进行产品的验证和POC。换句通俗的话来说，就是可以快速试错，缩短Time To Market的时间。而这一点，在今天的商业环境中时非常重要的。第二对于运维人员来说，运维成本也不高，很多在其他数据库架构设计中要考虑的问题在MongoDB的设计之初已经被考虑进来，集成到了产品之中。例如Replication Set技术，主库和副本集之间数据的同步，发生问题时的投票，故障的切换都在Replication Set的技术中被自动的实现。有了Replication Set，可以大幅提升系统高可用性，降低计划和非计划停机的时间，减轻运维人员的压力。

问

MongoDB在平安的使用规模如何？是否方便说下哪些重要的业务在使用MongoDB？

答

MongoDB从2014年开始被引入平安并且推广，到今天已经有接近500套集群在运行，分片和非分片架构都有。随着这些年来数据的爆炸性增长，MongoDB的易用性，其功能的不断完善，以及平安数据库团队对MongoDB运维经验的累积和技能的不断提升，我们推广的力度也不断加大。当前MongoDB的使用范围已经覆盖到全集团包括产险、寿险、养老险、健康险、普惠、基金、信托、租赁、智慧城市等28家专业子公司，由此可见其适用场景之广！具体到系统来说，我们的智能电销语义分析平台，平安直播平台，包括本次大会将要分享的应用运营数据分析与自动自助化支持平台都把MongoDB做为主要的后台数据库系统。

问

实践过程中是否遇到过什么困难之处呢？

答

任何一个新数据库的产品我们引入都是非常谨慎的，也正因为平安集团是一家金融企业，受到一行两会的监管，系统的稳定性高于一切。但一个产品从陌生到走向成熟，无论对于开发还是运维人员来说，又是一个必经的阶段。如何平衡这两者之间的矛盾是我们面临的第一个挑战。如何选择系统来进行试点；制定开发规范，如何培训开发人员养成良好的开发习惯；制定运维规范，如何逐渐的积累经验；制定架构规范，事先想到可能会发生的问题在设计初期就加以预防，这些都是要考虑的问题。具体到技术上，在实践过程中还是会遇到不少的问题。例如对于分片架构来说，如何选择适合的分片键，既能够让数据在分片间均衡的分布，又不会引发查询性能下降。另外一个例子就是MongoDB的内存管理，我们的一个系统有一个时期经常出现性能下降的情况，究其原因和MongoDB的脏块刷新机制相关。在缺少文档详细讲解的情况下，我们进行了大量的测试，来了解MongoDB的内存管理机制，包括在MMAPv1和WT存储引擎之间的区别，在不同版本之间的区别，影响内存管理的相关参数在不同配置下对于脏块刷新的影响，脏块刷新不同的行为对于系统并发更新吞吐率的影响，务求深入理解其工作原理，来进行最优化配置以及降低未来发生问题的风险。就是这样一步步的在实践中完善开发和运维规范，积累运维经验，总结最佳实践。

问

对于那些初次使用MongoDB的用户，你有什么建议吗？

答

对于初次接触或者使用MongoDB的用户，无论开发和运维人员，或者是DevOps团队，第一条建议是放诸于四海皆准的，也是我一直坚信并且在讲的，就是数据库不是黑盒子。每一种数据库都有它自己的设计思路，都有它自己独有的工作机制和实现方法，如果想用好一个数据库，想最大化发挥它的潜力，想达到极致的技能，就必须要深入了解它。而最系统化和最全面了解它的方式就是阅读文档，并且是官方文档。对于开源数据库来说，如果有兴趣还可以阅读源码，文档和源码二者可以相辅相成，可以帮助你更快的学习知识点，更快地了解内部工作机制。还有一个建议可以给到开发人员，特别是来自SQL数据库的开发人员。既要保持SQL数据库系统设计时的良好习惯，同时又要转变思维，拥抱NoSQL。前者的一个具体例子是MongoDB虽然给了开发人员建模设计上的灵活性，但不代表可以天马行空的定义Document，每一个Document的属性都各不相同。Schemaless的意思不是完全不管不顾Schema设计，而是说去除了RDBMS强加的硬性限制，给了开发和运维人员建模设计上一定的灵活性。如果每个Document的逻辑属性和物理长度都不尽相同，很快功能上和性能上的问题就会暴露出来，基于如此设计的一个系统很难生存下去。后者的意思是不要象在RDBMS中总是想着进行不同Collection之间的关联，这样会复杂化设计。也不要在DML语句中使用性能低下或者需要长时间执行的查询语句，由于不同版本锁的粒度不同，带来的结果可能会极大的降低系统的吞吐量。虽然MongoDB每个版本都在降低锁的粒度，从DB级到Collection级到Document级，但保持简洁的编码风格，书写高性能的查询更新语句，永远都是一个好的习惯！

【更多嘉宾专访将陆续发出，敬请期待~】