DocumentDB 是微软于 2014 年推出的，基于 Windows Azure 的一个 PaaS 云产品。正如它的名字所示，这个产品是个文档数据库。它主要是冲着 MongoDB 的市场去的，它的数据模型和 MongoDB 很像。

2017 年初，微软推出了和 MongoDB 兼容的 DocumentDB 的 API。在 2017 年 5 月微软面向程序员的 Build 大会上，微软宣布 DocumentDB 升级为 Cosmos DB。Cosmos DB 包含多个数据模型，文档模型成为其子集。

今天，我就带你回顾下这个 MongoDB 竞品的发展历程。

让我们把时间线拉回 2013 年。那时候我还在微软，一个同事神神秘秘地宣布他要离开我们组，去投奔一个秘密项目了。和以往的各种离别不同，这个同事对于接下来转去做什么，一句话也不肯多说。事关公司机密，只是道听途说，这个秘密项目已经开发若干年，微软投入了若干人力物力。

因为我所在的组做的是经典的大数据基础架构的东西，而我同事十余年如一日地在数据库引擎上做开发，换来换去的组都是数据库引擎开发这方面的。所以我只能大概猜测，他要去的这个组做的应该也是和数据库相关的事情。我实在猜不出来，到底是一款什么样的神秘的数据库产品。

那时的数据库市场正如火如荼，大数据和 NoSQL 的风潮一浪高过一浪。MongoDB 更是以简单易用、功能强大、服务周到，而成为很多创业者和初创企业的首选。像 MongoDB 这样的，基于文档而非传统关系模型的数据库，是如此受欢迎。

那个时候的我一直有个困惑：为什么这么美好而巨大的市场，就没有人觊觎呢？如果我是某家大公司的人，我一定会组个团队，开发一个和 MongoDB 一样容易卖钱的产品。

上面这两件事情一直盘旋在我脑海之中，但很长一段时间里都只是彼此孤立地存在。

然而，它们终究还是以很巧合的方式重合了。2014 年，微软正式公开了一个新的数据库——DocumentDB。

2014 年公布的当然只是预览版，正式版于 2015 年才正式发布。那个时候，我已经离开微软，而我朋友的 LinkedIn 档案终于更新，改成了自己是做 DocumentDB 的。有一天，我偶然看到这个朋友的 LinkedIn 才恍然大悟，原来微软早就已经开始觊觎 MongoDB 的市场，并秘密研发大杀器了。

我们知道，MongoDB 作为一个产品来说，其易用性达到了相当的高度。唯一不足的，是产品的稳定性。MongoDB 充其量就是一个“杂牌军”，在系统是不是丢数据、能不能够有比较好的分布式处理能力、够不够安全方面，都有很多的问题。

而 DocumentDB 开始杀入市场的时候，面对强大的 MongoDB，这场大战并不好打。面对当时的境况，DocumentDB 最终选择了几个切入点。

  1. 和 MongoDB 不一样，DocumentDB 最初的查询语言是一种 SQL，它的类型系统和表达式则是 JavaScript。使用这样一个组合，微软认为能够更好地实现对用户的支持。
  2. DocumentDB 请来了图灵奖获得者莱斯利 · 兰伯特（Leslie Lamport）坐镇，系统对于事务处理的支持远远强于 MongoDB，并且提供了可供选择的事务处理级别。相对而言，MongoDB 对事务处理的支持是很脆弱的，有各种各样的丢数据的例子，微软觉得 DocumentDB 在这方面做得好很多。
  3. 和 MongoDB 不同，DocumentDB 会自动索引数据库里面的文档。这样一来，访问 DocumentDB 的时候速度要好很多。自动索引让用户也方便很多。
  4. DocumentDB 被做成了在 Windows Azure 上的一个 PaaS 服务。这样一来，用户自己就不需要部署什么东西了。

这个产品推出以后，在一定程度上证明了微软决策的正确性。微软这次的产品确实在易用性上有了本质的飞跃，也因此受到了很多人的欢迎。

然而，使用 SQL 到底是利大于弊还是弊大于利，是一件说不清楚的事情。毕竟，有人喜欢 SQL，也有人讨厌 SQL。而 MongoDB 的 API 方式和对语言的支持，与 SQL 走的是完全不一样的道路。这种不同，导致程序员们非常喜欢使用 MongoDB。当然，这也使得 MongoDB 失去了大量只会写 SQL 或者对 SQL 有明显偏好的人。

那个对事务处理的支持和事务处理级别的选择的设计，确实让用户在精准服务和省钱之间必须做出选择。这种选择在 MongoDB 里没有，而且 MongoDB 在事务处理上也没有提供特别明确的语义支持。

对于很多用户来说，事务处理是一个很重要的需求。没有事务处理的话，数据的写和读就会麻烦很多，应用程序的开发就不一定会顺利。所以对事务处理的支持，和事务处理级别的选择，是 DocumentDB 非常重要的一个功能。我觉得，这也是它比 MongoDB 更出彩的特征。

为什么微软决定把 DocumentDB 做成 Windows Azure 的一个服务，而不是作为一个单独的产品来卖呢？我想一方面固然是 Windows Azure 自动帮每个用户管理了很多东西，另外一个很重要的方面是微软觉得这个产品会很成功，所以能够借助产品让 Windows Azure 的订阅和使用数都上一个台阶。而且微软为了推广这个产品，在 Windows Azure 上的收费很低。可以说，为了让这个产品去推动 Windows Azure 的订阅，微软也是不遗余力。

实际上，这个产品一开始算不上多么成功。的确是有不少人在用，但是这个比例和微软期望的，或者和 MongoDB 的使用率比起来，实在是低很多。而从已有的 MongoDB 迁移到 DocumentDB 上，又意味着程序的重新开发。很多人一点都不想重新开发一个新程序，所以即便 DocumentDB 有厉害的地方，也只有新的应用在用，而老的基于 MongoDB 的应用转化过来的比例并不高。

为了彻底解决这个问题，让那些使用 MongoDB 作为数据库的应用可以顺利地迁移到 DocumentDB 上，2017 年的时候，微软准备了一个大杀器：为 DocumentDB 提供了一套和 MongoDB 完全一样的 API。

这次微软终于决定不再玩 SQL 了，也不再矜持了。既然 Mongo 是标准，那么我们就在自己的系统里面把标准给兼容了。那样你们要是在 MongoDB 上跑的，就可以不用改程序直接跑到我的数据库上来。

这种做法颇有点流氓做派。但是我们也知道，API 不可能申请专利，加上 MongoDB 本身还是开源的，所以微软的这种做法也是情理之中的事。这样一来，但凡背后用了 MongoDB 的程序，都可以顺利地转化过来了。

MongoDB 自己本身也并非没有问题，而这反过来给微软帮了很大的忙。在 2017 年 1 月的时候，黑客们大规模袭击了默认安装的 MongoDB。这些 MongoDB 没有密码，可以被随意登录。黑客袭击 MongoDB 后，将数据删除或者转移到其他地方，并留言需要支付若干比特币才给恢复数据。造成这个问题的主要原因，还是 MongoDB 本身的默认安全设置不好。

这的确是给微软提供了很多活动的空间。在“更安全”的宣传下，又提供了 MongoDB 的 API，DocumentDB 终于开始迅猛发展，被越来越多的人使用。这又反过来促使微软对 DocumentDB 有了进一步的期望。

2017 年 5 月微软全球 Build 大会上，作为大会主讲内容的一部分，微软宣布 DocumentDB 升级成为 Cosmos DB。Cosmos DB 直译过来就是“宇宙数据库”。Cosmos DB 是 DocumentDB 的一个超集，不仅包括 DocumentDB 的所有功能，而且增加了对图数据库在内的多种其他数据库的支持。

Cosmos DB 最初宣布的时候，很多人对这个命名表示了疑惑，因为这和微软内部大数据处理平台 Cosmos 的名字很像。也因此，很多时候不知情的人会以为，微软是把内部数据平台 Cosmos 开放给外面的人使用了。然而实际上，Cosmos DB 和 Cosmos 并无半毛钱关系。

但是，Cosmos DB 的宣传如火如荼、声势浩大。再加上图灵奖获得者的现身说法，Cosmos DB 的知名度被迅速打开，并且获得了很多人的信任。

于是从 DocumentDB 升级到 Cosmos DB，微软不仅完成了在文档数据库上面的布局，看起来其能力更是远远超过了 MongoDB。这个数据库自 2017 年 5 月以来，Windows Azure 的用户都在使用。虽然效率如何还需要时间去检验，但是其易用性已经经过了考验。

无论如何，作为 MongoDB 在市场上唯一的竞争对手，Cosmos DB 的目标很宏大。如果微软能够顺利地让这个产品成长起来，那么在将来它很可能是 Windows Azure 云服务里面非常有特色的一个服务。当然，如果微软没能做好产品，用户又不愿意绑定到 Windows Azure 的战车上，未来就会堪忧了。

在我个人来看，未来 Cosmos DB 的成败概率大致在一半一半，而这在很大程度上取决于 MongoDB 怎么解决自己的问题，以及其他的云计算厂商打算怎么玩转文档数据库这个游戏。