(此文章同时发表在本人微信公众号“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的世界。
由于原文信息量巨大,更多详情还是“阅读原文”。