您是怎么开始接触到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存储引擎之间的区别，在不同版本之间的区别，影响内存管理的相关参数在不同配置下对于脏块刷新的影响，脏块刷新不同的行为对于系统并发更新吞吐率的影响，务求深入理解其工作原理，来进行优化配置以及降低未来发生问题的风险。就是这样一步步的在实践中完善开发和运维规范，积累运维经验，总结佳实践。