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的数据模型最接近开发者的面向对象的设计思维；
灵活动态的模型意味着在需求多变的时候极大简化数据库设计流程；
自动分片、多节点自动同步和跨中心能力支持各种现代化复杂部署需求。

创作场景

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