MongoDB于2009年发布，其最初的设计目标是性能和易于存取数据。作为文档数据库，允许数据以嵌套的状态保存，并且能够以任意方式查询嵌套的数据。这使得它能够灵活地处理各类大小任务，正因为多功能、强大、灵活，因而广泛被使用。

阿里巴巴由于业务发展的需要，对于互联网场景下的各类数据库技术都有比较深入的研究，目前也致力于打造MongoDB云服务。 在本次“遇见未来”系列专访栏目中，我们有幸邀请到了阿里云高级技术专家张友东，分享阿里在使用MongoDB的一些感悟和新的尝试。

遇见未来
DB舞台孰是王者之MongoDB专访

1. 自我介绍 & 团队介绍

张友东

大家好，我是阿里云的高级技术专家张友东（林青，阿里花名），主要关注分布式存储与数据库技术领域，目前从事阿里云数据库的开发工作，致力于让开发者使用上最好的云数据库服务。

2. MongoDB技术的发展历程,以及文档数据库的兴起与发展
MongoDB 发展至今刚过10年，2017年成功上市也说明了市场对 MongoDB 的认可，10年前是移动互联网爆发的关键节点，iphone 的诞生催生了大量移动应用的诞生，大数据场景不再是大公司的专利。在移动互联网高速发展的同时，各种各样的业务场景，快速版本更替的需求，对数据库基础设施提出了更高的要求，导致在很多场景下，结构严谨的关系数据模型并不是最佳选择，而且关系型数据库在扩展性上也无法适应快速发展的业务需求。

在这个背景下，MongoDB 等 NoSQL 数据库应运而生，在 MongoDB 文档模型下，数据没有固定 schema，访问、修改起来非常灵活，特别适合于需要快速开发迭代的互联网应用场景，目前 MongoDB 在电商、游戏、物联网等场景都着有广泛的应用。

3. 目前您和团队的工作重心是什么呢？
在 MongoDB 云数据库方面，目前团队的核心的目标是打造最好（用户体验最好、性能最好、成本最低）的 MongoDB 云服务。

借助阿里云数据库团队的大中台，为 MongoDB 云数据库构建了一套完整的管理体系。用户可以在控制台自助的购买 MongoDB 云数据库实例，对实例进行弹性的规格伸缩，同时 MongoDB 云数据库还提供了备份恢复到任意时间点、审计日志、秒级别性能监控等企业级功能。我们正在研发 CloudDBA（即将在阿里云控制台上线），与 AI 技术结合，为 MongoDB 实例提供自动化的诊断分析、容量规划、索引推荐等功能。

在 MongoDB 内核开发方面，我们针对用户使用、运维管理方面的需求会做大量的改进，比如上面介绍的很多中台管理功能，我们都是在内核层面做尽改进，配合中台一起做，以发挥最佳的效果。同时我们结合新硬件及技术的发展趋势，会在内核存储引擎方面也做了大量的研究和优化工作，让引擎发挥更大的效能。

4. MongoDB数据库有哪些主要的特点和优势？
总的来说，MongoDB 的很多功能特点都是为了让开发者能更加简单、方便、低成本的进行业务开发迭代，让 DBA 运维管理起来更加简单。

• MongoDB 基于文档模型（JSON），存储的内容无固定的 schema，用户可以很方便的添加或删除文档的字段，这种模型非常适合需求多变、快速迭代的业务场景。
• MongoDB 复制集通过 Raft 一致性协议实现自动的管理，相比传统基于主备结构的高可用，运维管理成本极低。
• MongoDB 分片集群使得后端存储可以方便的实现横向扩展，以适应用户高速增长的业务需求。
• MongoDB 还支持丰富的二级索引功能，单 key 索引、符合索引、文本索引、TTL 索引、地理位置索引等，极大降低了用户的开发成本。
• MongoDB 支持丰富的 Aggregation Pipeline 操作以及 MapReduce 计算框架，用户可以直接基于 MongoDB 的数据做 OLAP 计算分析。

5. MongoDB在过去的版本演进中，比较重大的变化包括哪些呢？目前在3.4版本上，您最关注的核心特性有哪些，可以简单介绍下吗？
从接触 MongoDB 到现在，我经历了从 MongoDB 3.0 到 MongoDB 3.6 四个大版本的发布，也看到 MongoDB 内核不断的提升。

• 3.0 里引入存储引擎的概念，除了支持 2.x 版本里的 mmapv1外，还引入了 WiredTiger 的存储引擎。
• 3.2 版本里引入了 Raft 协议，让 MongoDB 复制集在可靠性、一致性方面有了更加坚实的后盾。
• 3.4 版本在主备复制、sharding 方面做了很大的提升，在复制、迁移的速度及并发度上都有了明显的提升。
• 3.6 里引入了 oplog ChangeStream 的特性，这个特性会极大的扩展 MongoDB 的生态边界。

上面简单列举了每个大版本我觉得最重要的提升，实际上每个大版本的提升都远不止于此，详细的改进项官方都有详细的 ReleaseNote 文档，有兴趣的同学可以进一步了解。

6. 请您介绍一下MongoDB中目前比较成熟并且流行的存储引擎和他们的使用场景吗？
MongoDB 主要支持的存储引擎有 WiredTiger 和 mmapv1，WiredTiger 从3.2版本开始就是默认的存储引擎，在多核场景下做了很多优化，基本能覆盖绝大部分应用场景；mmapv1 目前仅在大量集合及索引的场景还有用武之地，针对这个场景，WiredTiger 开发团队也在做改进，在3.8+的版本里会彻底废弃 mmapv1引擎。

除了官方自带的 WiredTiger 和 mmapv1 引擎外，开源社区还支持 MongoRocks 存储引擎，这个引擎基于 RocksDB 实现，基于 LSM-tree 的存储结构，在高并发写入场景相比 WiredTiger 更有优势。为了更好的服务用户的业务，我们在 MongoDB 云数据库上也支持了 MongoRocks 引擎。

7. MongoDB的强伸缩性在企业环境中有哪些优势，及其具体的应用场景？

MongoDB 灵活的文档模型，在需求多变的应用场景下适应性极强，以游戏为例，基于传统关系模型，构建一款游戏，可能需要抽象很多张表，比如用户表、角色表、装备表等，然后在查询时基于多张表做关联，在遇到运营需求变更时，则需要进行表的 schema 变更，这通常是一个很重的线上操作，有可能需要停服来做变更。而基于 MongoDB，分散的信息可以组合到一个文档里存储，降低了数据查询成本，同时由于文档结构能方便的进行在线修改，能很好的适应游戏运营策略的调整。

另外，MongoDB 提供了复制集、分片集群2种部署模式，使得用户可以渐进式的扩展。在业务发展初期，业务量较小，最大的诉求是提供持续稳定的数据服务，这时用户只需要部署复制集即可，运维管理成本很低；随着业务不断的发展，当单个复制集不能再垂直扩展（存储能力或写入能力达到单机瓶颈），可以通过部署分片集群来进一步扩展。

8. 相较于RDBMS，MongoDB真的能带来巨大的性能提升吗？主要是通过哪些技术实现的？在性能提升的同时，有没有带来一些问题

性能上的提升要看结合具体的场景，并不是所有业务切换到 MongoDB 上都会有性能提升，根据我个人的理解，MongoDB 的性能提升主要体现在以下几个方面。

基于 MongoDB 自身的特性，开发、管理成本会有大幅降低，这本身就是一种性能提升。
基于文档模型，很多业务可以将原来关系模型里分散在多张表的数据存储到一个集合/文档中，避免了查询时的多表 join 操作（更少的计算操作），查询的内容更具局部性（更少的 IO 操作），这个也会对性能有很大的提升。
作为数据库的发动机，存储引擎至关重要，WiredTiger 存储引擎的设计理念非常先进，在多核下性能表现非常好，其能量还没有完全释放，这也意味着 MongoDB 性能发挥的空间还很大。

9. MongoDB未来的演进方向是什么样的呢？
从 MongoDB 的 RoadMap 看，在未来几年还是在往 NewSQL 路线上继续前行，即兼有关系型数据库的强大功能和 NoSQL 数据库的易扩展性。

事务的支持是 MongoDB 后续发展的一个重点，虽然基于文档模型，很多场景都可以通过建模后依赖单文档事务来解决，但有了多文档/多集合的事务后，这些场景实现起来会更加简单，这也非常符合 MongoDB 的理念，让开发者做更少的工作，实现自己的 Giant ideas。

执行（查询）引擎、存储引擎在数据库里是永恒的话题，MongoDB 在未来也会不断在这两方面持续优化提升（MongoDB World 分享里有大量 Slides 介绍相关的优化），让引擎能更好的带动数据库转动。
    
除了数据库本身的不断提升，另一个方向就是不断的扩展数据库的边界，比如3.6里已经推出的 Oplog Change Stream 功能，oplog 能方便订阅之后，可以用 oplog 做很多事情，比如能恢复到任意时间点的增量备份，跨复制集的同步，甚至是往异构数据库的数据复制。数据打通之后，用户基于一份 MongoDB 的数据就能发挥更大的作用，比如跟 BI 工具打通做商业数据分析，与 Spark 等计算框架打通做数据分析处理等。

10. 除了MongoDB，您还比较关注哪一个数据库呢？可否简单聊一下对任意一款NoSQL/NewSQL数据库的认识和看法？请问您如何看待数据库的未来，会朝着什么样的方向发展？
除了 MongoDB，社区比较流行的数据库，比如 MySQL、Redis等也都有关注，还有近几年涌现的分布式数据库 Google Spanner、TiDB，以及基于计算存储分离思想的 AWS Aurora，阿里云的 PolarDB等。

关于未来数据库的发展，简单的谈下个人的看法。

业务场景需求推动技术发展。Google Spanner 与 AWS Aurora 两条截然不同的发展路线，我觉得根本原因是最初驱动技术发展的业务场景不同，Google Spanner 更侧重于解决 Google 内部业务对分布式数据库的需求，存储、计算能力易扩展，全球分布等；而 AWS Aurora 则是解决 AWS 上云数据库的的诉求，解决如何提供更大容量的数据库，如何让数据库扩展起来更加简单轻量级，如何100%的兼容 MySQL的社区生态让用户能无缝做业务切换等问题。

执行/引擎层百花齐放，接口层不断统一。目前我们看到的数据库有几百种，很多数据库都有自己定义的一套访问接口规范，但总结起来主要有 SQL 接口，Document 接口、KV 接口、Graph 接口等，目前已经有一个趋势就是，在现有访问接口表达能力已经很强大的时候（同时也有商业上的原因），各种数据库在接口定义上已经不断趋近标准化，比如关系型数据库最通用的 SQL 标准，而基于文档接口访问的数据库很多都兼容 MongoDB 的访问接口，KV 数据库则兼容 Redis 访问接口等，在统一的访问接口下，各个数据库的执行引擎、存储引擎上做更多的创新工作。

未来数据库将更加智能。AI 技术已经在各行各业逐步发挥作用，数据库领域也不例外，类似参数调优、问题诊断、日志分析这样的"体力活"，以后可能都会被数据库内核自动做掉，开发者和业务 DBA 只需要更加专注自己的业务开发。

11. 对于想学习MongoDB的技术爱好者，您有什么建议给他们吗？
对于想学习 MongoDB 技术的同学，强烈推荐的学习资料就是 MongoDB 官方文档，涵盖接口使用，数据库配置、内部实现、用户案例等各种内容的介绍，非常全面，社区里平时问的比较多的问题，99% 都能从官方文档上找到答案。

另外，正在学习或使用 MongoDB 的同学，也可以加入到 Mongoing 中文社区，社区的官网（mongoing.com）会有 MongoDB 技术相关的文章，以及官方技术文档的中文翻译，社区还会定期的在各大城市组织线下的技术交流活动，为 MongoDB 技术爱好者提供一个交流与学习的平台。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业，以及每一个向未来而努力的人，听见时代最前沿的声音，见证成长！