Azure DocumentDB对比MongoDB
（此文章同时发表在本人微信公众号“dotNET每日精华文章”)
今天推荐的文章对Azure DocumentDB和MongoDB的进行了比较，也给出了一些使用建议。
我想很多朋友都应该知道Azure，不过估计也有很多人不知道微软还推出了自己的NoSQL数据库产品。当然这个产品仅限以PaaS的方式来在Azure中提供。DocumentDB去年秋天开始预览，这个正式上线（按照Azure的说法是Generally Available）。当然，在NoSQL市场上，混战激烈，尤其MongoDB占了将近一半的市场份额。本文作者David Green特意拿DocumentDB同MongoDB进行了比较。
相同点
他首先分析了两者的相同点。NoSQL数据库通常分为如下几种：Key-Value存储，列存储，图存储，文档存储，或者混合模型。而DocumentDB和MongoDB都同属文档存储类别，都具备如下特点：使用分区来容错，反范式组织数据集合来避免传统关系结构，模仿面向对象编程中的实体对象来突出人可读的数据格式。
除了上面的这些共同特点外，两者都具备一些特别的优势。首先，两者都支持多种编程语言的客户端SDK，DocumentDB支持主流的.NET、Node.js、JavaScript、Python和Java，当然MangoDB的支持更为丰富。其次，两者都使用了类似的数据格式——JSON（MongoDB使用的是JSON的扩展BSON）。最后，两者使用的通用语都是JavaScript。
不同和优势
David在谈完两者的相同点之后，着重介绍了不同之处和DocumentDB的某些优势。
- PaaS：DocumentDB是直接以PaaS提供的。这样带来的好处是配置、管理、维护都更为简单。MongoDB则需要自行部署到VM中，需要花费成本运维。由于PaaS有诸多好处，作者都建议即使要使用MongoDB都最好使用第三方搭建好的现成PaaS。
- 伸缩能力：由于DocumentDB是PaaS驱动的架构，所以其处理水平扩展的方式和MongoDB完全不同。DocumentDB分区后无需管理复制，MongoDB还需同时处理复制。这点也是得利于DocumentDB后台依赖于Azure的伸缩能力。
- 原生REST接口：虽然两者都为开发人员提供了多种语言的SDK，但是DocumentDB是原生提供REST接口的，其实SDK也是REST接口的包装。相反，MongoDB没有原生REST接口，不过其有Wire协议和元数据驱动（基于TCP），可以语言无关的访问到数据。不过在有些情况下基于HTTP的REST接口显然更加方便（比如物联网）。
- 数据交换格式：DocumentDB使用JSON更加标准（RFC 7159 和 ECMA-404）。
- 索引处理：两者虽然都是基于B-Tree来进行索引，不过DocumentDB提供了两类索引Hash和Range，Range暂时不支持时间字段的索引，DocumentDB也不支持地理位置信息的索引而是依靠Azure Search来解决这个问题。从产品的角度看，在这点上MongoDB具备优势，不过实际使用过程中不会有太大的问题。
- 异步处理：由于DocumentDB原生提供REST接口，而这些接口或者.NET SDK都提供了async/await的支持，以提供并发处理能力。
- 定价：虽然MongoDB是开源免费，不过运维的费用也不会少。DocumentDB是基于使用量付费，不过费用不高，且可以通过DreamSpark和BizSpark来获取Azure免费订阅。
- 一致性：MongoDB的一致性可以配置来是否启用一致性，DocumentDB可以配置4级一致性等级。
- 二进制大对象存储：MongoDB依赖GridFS来实现Blob的存储，DocumentDB依赖Azure Blob Storage。
- 监控：Azure为DocumentDB提供了丰富的监控指标，MongoDB通过Mongo Monitoring Service (MMS)来跟踪宿主主机的情况。
- 可编程性：两者都支持JavaScript，DocumentDB的.NET SDK对LINQ支持更好，不过对debug支持不好（主要没有本地模拟器）。
- 其他的不同：DocumentDB对聚合操作暂时有一定限制，无服务端排序，工具还不够丰富。MongoDB情况要稍好些。
最后，作者给出了一些使用上的建议：DocumentDB可以满足NoSQL的基本需求，不过文档和应用案例都还需要继续改善。不管怎么样，DocumentDB可以让你（在使用Azure的情况）很快进入NoSQL的世界。
由于原文信息量巨大，更多详情还是“阅读原文”。
