没有一个技术天生完美，MongoDB 十年发展全纪录

2007 年，MongoDB 公司的前身 10gen 正式成立，2009 年 2 月开源数据库 MongoDB 1.0 正式面世，以开源的方式进入市场接受考验。时至今日，MongoDB 已经从一个在数据库领域籍籍无名的“小透明”，变成了话题度和热度都很高的“流量”数据库。

• 2009 年 2 月，MongoDB 数据库首次在数据库领域亮相，打破了关系型数据库一统天下的局面；

• 2014 年 12 月, MongoDB 收购了 WiredTiger 存储引擎，大幅提升了 MongoDB 的写入性能；

• 2016 年, MongoDB 推出 Atlas，在 AWS、 Azure 和 GCP 上的 MongoDB 托管服务；

• 2018 年 6 月, MongoDB 推出 ACID 事务支持，成为第一个支持强事务的 NoSQL 数据库；

• 2018 年 11 月，MongoDB 将其开源授权修改为 SSPL；

10 年间，MongoDB 的每一次创新几乎都引起了业界的讨论。当然除了好消息，MongoDB 也有一些其它的声音传出，例如 2017 年广为人知的“MongoDB 赎金”事件，因默认不需要用户名密码登录的设置，屡次发生的企业数据泄露事件。

MongoDB 到底是个什么样的数据库呢？作为数据库，其到底经历了怎样的发展历程，拥有哪些核心竞争力？展望未来，MongoDB 又将走向何方？…为了让大家更加清晰全面的了解 MongoDB，我们特意邀请 MongoDB 中文社区发起人、MongoDB 官方大中华区首席架构师唐建法撰写了本文。

众所周知，数据库是所有软件中除了操作系统之外最复杂的软件。按照 DB-Engines.com， 一个专门跟踪数据库流行程度并每月发布数据库排名的一个网站的统计，排名前 5 的数据库分别为 Oracle, MySQL, SQLServer, PostgreSQL 和 MongoDB。

从一个名不经传的科技创业公司，到今天可以说是家喻户晓的知名数据库厂商；从一个籍籍无名的小透明数据库，到现在成长为各大公司争相采用的数据库产品，MongoDB 到底经历了怎样的发展历程？

MongoDB 编年史

技术发展重要节点及事件

文档数据库鼻祖的诞生

2007 年, 10gen 创始人 Eliot 和 Dwight 在寻找一个能够支持他们的云计算平台的海量数据库。不奇怪，当时成熟的数据库基本上都是基于单机架构的传统关系型数据库如 Oracle, MS SQLServer 等。即便 Oracle 支持一些集群部署，其扩展性也仅限于 2 到 4 台服务器的范围。在没有很好的解决方案的情况下，10gen 的创始人决定自己研发一个数据存储服务，能够把开发者使用的程序对象数据存到一个类似于数据库的地方，并提供非常易用的 API 让开发者可以对数据进行常见的增删改查操作。为了最大程度方便开发者，Eliot 决定使用 JSON 作为数据格式来存储。JSON 的数据在英文中被称之为 JSON Document，这也是文档数据库名字的由来。 事实上证明这个基于 JSON 的选择，成就了一家伟大的新型数据库公司。

MongoDB 自动分片

2010 年 8 月, 10gen 发布了 MongoDB 1.6，第四个大版本。这个版本最大的一个功能就是 Sharding，自动分片。在关系型数据库中，当数据量达到一定程度，单个节点服务器资源充分饱和无法保证及时的服务响应时间时，通常会采用分区分表的数据库优化方案。但是这些方案都是侵入式的，很多时候意味着应用程序需要做较大的改动，来配合数据库端的改动。而 MongoDB 的自动分片，可以在一个集群的几个分片服务器内自动进行数据的分布和均衡。在尽可能把数据均匀的分布到多个存储节点的同时，为应用开发者提供无缝的体验。开发者无须关心数据的具体位置，程序也不需要因为分片与否而进行修改。采用分片技术，开发者可以很容易使用数十甚至数百个节点。早期的用户如百度就是基于这种分片技术，为 3 亿多用户、3000 亿条数据量的百度云盘文件元数据管理提供有效的集群解决方案。

MongoDB 支持存储引擎 API 并引入 WiredTiger 存储引擎

2014 年 12 月，MongoDB 收购了 Keith Bostic 和 Michael Cahil 的 WiredTiger 存储引擎团队，并将其集成到 3.0 版本中，成为一个新的存储引擎。

在此之前，MongoDB 在存储层使用的是操作系统自带的 MMAP API 进行数据落盘持久化工作。从功能实现角度，使用 MMAP 使得早期团队可以集中注意力在 MongoDB 的 API、查询、索引计划、数据同步等上层逻辑。但是随着 MongoDB 使用场景的增多以及数据量的增加，MMAP 在大量写入场景下的性能瓶颈日益凸显，同时也成为了早期很多性能槽点的根源之一。

WiredTiger 的引入是 MongoDB 走向一个成熟数据库的最重要的里程碑。在性能上，WiredTiger 较之老版本的 MongoDB 提升了 7-10 倍，有效地解决了之前 MMAP 在大量写入下的性能瓶颈。

值得一提的是，Bostic 和 Cahil 在之前曾把他们的前一代产品 BerkerlyDB 卖给了 Oracle。Oracle 随后推出以 BerkerlyDB 为核心的 Oracle NoSQL 数据库。Oracle NoSQL 基本上是一个未被人听说过的产品。从这一点上似乎证明了，对广大开发者来说，首先要有一个易用的数据库，然后才是一个高性能的数据库。

MongoDB 支持 Join

2015 年 12 月，在发布的 3.2 版本中，在 MongoDB 的聚合框架（Aggregation）中增加了一个不起眼的操作符: $lookup。 这个看上去虽小，但是意义巨大的功能意味着第一次作为一个 NoSQL 数据库，MongoDB 终于开始支持了关系型数据库的核心功能：关联。从 3.2 开始，你可以一次同时查询多个 MongoDB 的集合（表），不用像以前那样，如果有多表查询需要在代码中发起多个数据库查询，然后在内存中进行手工关联。

MongoDB 成功上市纳斯达克

2017 年 10 月，MongoDB 成功在纳斯达克敲钟，成为 26 年来第一家以数据库产品为主要业务的上市公司。一年多后再看，MongoDB 的股价蹭蹭蹭的升了 4 倍多。如果我们和 Cloudera / Hortonworks 比较，两家以 Hadoop 产品为主要业务的大数据科技公司，两家现在加起来的市值，尚不如一个 MongoDB。这是为什么？

最大的原因就是基于 Hadoop 产品的目标场景是大数据分析，首先用大量低成本存储聚集所有企业内外部数据，然后用 MapReduce 技术来对客户进行画像，贴标，或者制作一些统计报表。虽然这些场景确有价值，较之于 MongoDB 驱动的操作型场景，如新型手机应用，游戏，物联网，数字化银行等，无疑 MongoDB 支撑的是直接面向客户的，更加有业务价值的应用。

MongoDB 赎金事件

随着 MongoDB 的用户数量持续快速增长，日渐成为企业的标准数据库，MongoDB 的负面事件也不断。2017 年网络上流传最多的就是所谓的赎金事件。黑客们侵入用户的 MongoDB 数据库，把数据全部删掉，然后留下一条消息，要求用户用比特币支付价值几千美元的赎金，才将数据库数据恢复。

究其根底, 这个其实和很多 MongoDB 数据泄露，如后来的 58 同城 2 亿份简历事件，具有同样的技术原因：MongoDB，为了最大程度上方便程序员快速开发应用，默认方式下不需要设置用户名密码登录。这样一来，很多粗心的程序员，特别是创业公司，往往在系统正式上线时候也没有启用鉴权。就譬如你买了一套房子却没有使用门锁一样。只要稍具一些安全常识，就可以妥善防范数据在公网上泄露，具体细节可以参考 MongoDB 中文社区之前发过的这篇博文(http://www.mongoing.com/archives/3738) 。

MongoDB 支持 ACID 多行多表强事务

2018 年 6 月，MongoDB 推出 4.0 版本。和 3 年前有点类似，本来要发布 2.8 版本的，结果因为引入 WiredTiger 存储引擎，版本改成了 3.0。 按原计划本该发布 3.8 的，但是由于引入了千呼万唤始出来的多文档 ACID 强事务机制，MongoDB 决定版本改为 4.0.

ACID 事务机制已经是关系型数据库如 Oracle, SQLServer，PostgreSQL 的标配。之前 MongoDB 对事务的支持仅限于单文档内。如果你在开发一个电商应用，在一笔交易内要完成插入订单，扣库存，推送到消息队列等操作，原先的 MongoDB 版本无法保证这几个步骤的原子性，也没有出错情况下的回滚机制。 因为这个功能的缺失，很多开发者或架构师会在交易性的业务中有意避开 MongoDB。而随着 4.0 的发布，MongoDB 终于可以挺起胸昂起背，向世界宣布 MongoDB 正式成为第一阶层操作型数据库，可以用来支撑几乎所有的业务场景。

SSPL 开源协议

2018 年末 MongoDB 又一次被推上风口浪尖。这一次是 MongoDB 在 10 月份发布了其修改版开源协议：从 AGPL 到 SSPL。对于大多数开发者来说，他们可能都不清楚他们一直以来用的 AGPL 到底是什么样的一个开源协议。简单一点来说，对于 AGPL，如果不去修改 MongoDB 的源码，用户基本上就是在符合开源协议的情况下使用 MongoDB。但是一旦涉及到源码的改动，比如说很多云厂商在推出 MongoDB 服务的时候，为了满足自己环境、性能、场景及管理的需求，几乎无法避免不去修改源码。这样情况下，按照 AGPL，云厂商必须对外公布你的改动，以及相关联的软件。但是 AGPL 里面对于这一部分有一些比较模糊的地方，以至于很多云厂商并没有按照游戏规则来进行开源。在这样的情况下，MongoDB 推出了基于 AGPL 上的修改版：SSPL。对于绝大绝大部分的开发者或企业，SSPL 和 AGPL 没有任何区别。只有那些在公有云上提供 MongoDB 托管服务 (MongoDB as a Service)的公有云厂商会在 SSPL 协议下受到影响：要么和 MongoDB 达成商业合作采用商业协议，要么开源其所有云管理解决方案。

当然，MongoDB 不是唯一的一家开源软件公司针对云厂商改变开源协议。MongoDB 之前有 Redis，之后有 Kafka，都在类似的背景下作了开源协议修改。目前看来，开源社区似乎并不太喜欢这种商业化的运作，但是开发者可以记住：MongoDB 技术本身并无过错，还是以前的那个开源的 MongoDB，还是可以在你的应用中帮你解决切实的数据管理问题。

MongoDB 社区发展

MongoDB 的成功，很大程度上是开发者社区起了非常关键的作用。MongoDB 则从一开始就全力以赴支持了开源社区，上到 CTO，下至开发工程师，大家在社区里，论坛上，邮件组里热心的为用户提供技术支持，吸取用户的反馈。在现在仍然非常活跃的 Google Group，最早你可以看到这个邮件：

这个是当时的联合创始人 Dwight 在群里发布关于 MongoDB 的功能改进。到了 2012 年，MongoDB 成立专门的技术支持团队，其中有个成员 Stephen Steneker 组织起了专门的社区支持团队，开始在 Stackoverflow 和 Google Groups 提供系统性的技术支持。

除了对社区提供技术支持，MongoDB 社区极具特色的用户组织 MUG（MongoDB User Group）则是对推广 MongoDB 技术最有影响力的一个渠道。这些用户社区往往是由社区里的 MongoDB 爱好者，在当地组织起来， 踊跃分享 MongoDB 截然一新的开发模式，和分布式系统解决的扩展性问题。

在中国地区也有同样的 MUG 组织。 MongoDB 中文社区（mongoing.com）自 2014 年成立，专门服务大中华地区及其他地区使用中文的用户。 中文社区由博客、线下活动、技术问答、微信/QQ 群、文档翻译等模块组成，截至 2019 年社区已成功举办数十场人数超百的线下活动，发表关于 MongoDB 应用优质文章百余篇，会员总数已超 2 万，相关合作单位已达 20 多家。根据百度指数统计 MongoDB 的搜索频率明显高于其他类似数据库。中国地区的下载量也于 2017 年开始正式超过了美国成了全球最大的下载使用地区，这里面中文社区功不可没。

未来规划及期望

1. 坚持开源和商业化两条腿走路的策略

MongoDB CTO Eliot 非常明确 MongoDB 会将开源坚持到底。从很多方面看，Eliot 都是一个典型的程序员出身的技术 geek。 让 MongoDB 成为程序员在开发应用时候的首选数据库，可以说是他的个人梦想。要做到这一点，作为一个通用型的数据库，其开发的易用性、功能的完善性、性能的稳定性以及数据的安全性，都需要大量的人力来投入。有一个成功的商业化支撑，才能充分保证这些复杂研发工作的高效、有序进行。所以 MongoDB 商业化上的成功，只会进一步让社区用户获利。

从商业化的角度，MongoDB 雄心勃勃地在全球布局。连续几年 50%左右的增长，位列快速增长软件公司前三，使其获得了华尔街投资者的青睐。前段时间 AWS DocumentDB 的发布，大家都以为会给 MongoDB 带来很大的打击，事实上，开发者还是相信一个已经发展了 10 多年，经过了战火洗礼的原生 MongoDB。当然，云供应商锁定也是让开发者们考虑的一个重要地方：大家还是希望在需要的时候，可以自由的切换到其他的云计算供应商。

2. 加注云数据库

2016 年 MongoDB 发布 Atlas，一个在 AWS,、GCP、 Azure 上面提供的跨云 MongoDB 托管服务。 Atlas 成为 MongoDB 发展最快的一个业务。在云计算大方向下，MongoDB 正在大规模投入云服务的建设中。

持续增强跨地域集群，跨云集群等云上分布式能力

MongoDB Atlas 已经是目前在跨中心跨地域部署方面比较领先的一个云数据库。按照其主打的 Cloud-agonostic 的策略，很可能未来会提供跨云集群部署能力，为企业提供最可靠的容灾解决方案。

云数据库增值服务： Stitch

一个类似于 AWS Lambda 的无服务器产品。允许开发者直接跳过虚拟机部署，中间件安装等步骤，直接在基于 Atlas 的 Stitch 平台上提交代码并立即运行代码。Stitch 目前有以下几大关键功能：

• Query Anywhere, 提供对 MongoDB 数据库的访问；

• Functions, 无服务器架构下实现业务逻辑的地方，目前支持 javascript；

• 细颗粒度的权限管理, 使用 GUI 配置方式快速定义应用的权限管理；

• 外部 API 集成，平台直接继承了许多实用的 API 如 Twitter, Google, Facebook 等；

云数据库增值服务： Trigger

在 Atlas 上面提供的实时流计算处理能力，类似于传统数据库的触发器，但是更加灵活，并且可以支持每小时数百万的并发流数据处理能力。可以支持实时事件响应，状态通知等场景

3. 补足分析型的短板

我可以找出一大堆用 MongoDB 来做大数据分析的客户，如某世界级半导体企业用 MongoDB 替换 Hadoop 来管理产线大数据，为数据科学家的产品质量分析及事故溯源提供支持，又如某电信公司使用 MongoDB+Spark 来执行用户行为分析并驱动实时精准促销推送。这些场景都是上百至上千亿的数据量。但是相对于用 MongoDB 来作为操作型数据库（OLTP)，分析型的使用可能只是个零头。如果要发展成为一个企业的标准数据库，势必要在分析上提供更多的能力，如海量数据的并发分析性能、多表关联分析以及数据可视化等。 前不久发布的 MongoDB Charts 也彰显了 MongoDB 在这一方面的发展方向。

结语

没有一个技术是完美的，MongoDB 也不例外。但是回顾过去 10 年，MongoDB 从几十乃至数百个 NoSQL/NewSQL 产品中脱颖而出，面对社交网络上大量的各种负面打击，披荆斩棘杀出一条血路，获得今天这个相对来说一个比较成功的市场地位，绝对不是一个偶然行为。 作为一个技术人，要具备一定的辨别能力，在网上充斥各种 MongoDB 数据泄露或者其他负面故事的背后，你要认识到作为一个文档型数据库，MongoDB 的核心竞争力在于：

• 基于 JSON 的数据模型最接近开发者的面向对象的设计思维；

• 灵活动态的模型意味着在需求多变的时候极大简化数据库设计流程；

• 自动分片、多节点自动同步和跨中心能力支持各种现代化复杂部署需求。