9.0 KiB
065 | 直面MongoDB，谈微软的NoSQL战略
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最终选择了几个切入点。
- 和MongoDB不一样，DocumentDB最初的查询语言是一种SQL，它的类型系统和表达式则是JavaScript。使用这样一个组合，微软认为能够更好地实现对用户的支持。
- DocumentDB请来了图灵奖获得者莱斯利 · 兰伯特（Leslie Lamport）坐镇，系统对于事务处理的支持远远强于MongoDB，并且提供了可供选择的事务处理级别。相对而言，MongoDB对事务处理的支持是很脆弱的，有各种各样的丢数据的例子，微软觉得DocumentDB在这方面做得好很多。
- 和MongoDB不同，DocumentDB会自动索引数据库里面的文档。这样一来，访问DocumentDB的时候速度要好很多。自动索引让用户也方便很多。
- 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怎么解决自己的问题，以及其他的云计算厂商打算怎么玩转文档数据库这个游戏。