微软推出支持 Microsoft Azure 平台的 NoSQL 文档数据库

由于微软的 SQL Server 已经成为它们的旗舰产品，因此人们总是倾向于将微软与关系型数据等同起来，不过这种情况即将因为一个新的 NoSQL 产品的到来而发生改变了。微软在上周宣布推出 DocumentDB 的预览版，这是一个依托于云端的托管文档型数据库，它对 JavaScript 有很好的支持，并且包括自动建立索引与事务等方面的特性。

DocumentDB 是一个无结构的、基于 SSD 的数据库，它能够对 JSON 文档进行存取操作，并且通过一套 REST API 进行访问。根据微软的官方说辞，这个仅针对 Microsoft Azure 平台的服务将满足用户对非关系型数据库方面的需求，同时又保留了关系型数据库中一些有用的概念。

我们经常从用户那里倾听他们的需求，他们希望能有一个数据库可以跟上他们高速发展的应用的步伐，因此这个数据库必须高速、灵活并且可伸缩性强。随着越来越多的 NoSQL 数据库出现，它们也成为许多开发者首选的开发工具。但是运行与管理这些 NoSQL 数据库的成本高昂，尤其是在大规模使用的情况下。同时，我们也听到用户另一方面的需求，他们希望能利用关系型数据库系统的天然优势，例如复杂的查询功能与事务处理，这些特性对他们依然非常重要。大多数数据库为开发者提供的选择都显得有些极端，要么是强一致性，要么是最终一致性；要么使用查询功能十分有限的无结构形式，要么使用具有丰富查询功能但高度格式化的形式；在事务及扩展性等方面同样要面对两难的选择。事实上，在许多真实世界的场景中，我们需要在这些极端方案中寻找一种折衷以达到目的。

那么 DocumentDB 与传统的关系型数据库在哪些方面具有相似之处呢？首先可以使用一种轻量级的 SQL 语法对文档进行查询，并且支持原生的 JavaScript 类型，例如对象和数组。其次，大多数流行的 NoSQL 数据库只支持数据存储的最终一致性，而 DocumentDB 则提供了四种不同的一致性模型可供选择。

DocumentDB 为读写与查询提供了四种不同的一致性级别：强制一致、有限过期（Bounded Staleness）一致、会话一致以及最终一致。这四种完整定义的一致性级别使你能够在一致性、可用性及延迟等方面进行合理的权衡。有限过期能够保证完整的写入顺序，这种一致性适用于处理时间以及按顺序操作的应用程序。而会话一致性能够读取属于你自己的写入保证，它适用于以用户为中心的应用。

同样，在文档索引与事务方面的特性也能够找到关系型数据库常见的能力，其中索引方面具有如下特性：

当你往集合中加入文档时，DocumentDB 会自动为这些文档建立索引，以便你进行查询。能够在不设定结构，并且不提供第二级索引的情况下实现文档的自动索引，这是 DocumentDB 的一项关键特性。而实现这一特性的关键是由乐观写入、无锁并且使用日志结构的索引维护技术决定的。

对于 DocumentDB 的索引维护存在多种选项，虽然在默认的情况下会进行自动索引，但你也可以选择关闭这一行为，或者对其进行微调，例如可以指定将处于某个路径下或符合某个模式的特定文档从索引中去除，或是加入到索引中。还可以设定以同步或者是异步方式对索引进行更新。

DocumentDB 服务为配合服务端业务逻辑也提供了多种选择，它支持用户定义函数、存储过程和触发器。

由于 DocumentDB 的数据库引擎对 JavaScript 和 JSON 进行了深入支持，因此它能够以一种非常直观的编程模型，通过存储过程及触发器的方式直接执行基于 JavaScript 的应用程序逻辑。这使得以下两点成为可能：(a) 能够以一种高效的方式实现在数据库引擎中直接进行并发控制、恢复、以及对 JSON 对象的自动索引。(b) 能够以 JavaScript 编程语言自然地表控制流、参数变量、赋值，异常处理等基本功能，并且直接与数据库事务进行交互。

…

在某个牵涉到同一集合中多个文档的 ACID 事务操作中，DocumentDB 能够以快照隔离级别将基于 JavaScript 的存储过程与触发器进行封装。在执行过程中，如果某个 JavaScript 抛出异常，则整个事务将被撤消。

…

请注意，在 DocumentDB 处理多个文档时，它并不要求任何特殊形式的 JSON 规范以实现文档之间的关系建立，DocumentDB 的 SQL 查询语言提供了一套非常强大的结构化关系查询操作，能够在无需特殊标注的情况下对文档进行查询及转换，并且也不需要使用特别的属性以建立文档之间的关系。

那么这个数据库的性能如何呢？ GigaOm 表示，DocumentDB 使用了 SQL Server 2014中名为 Hekaton 的内存引擎，微软的副总裁 Scott Guthrie 也透露了这项技术已经在微软内部被大量使用的事实。

过去一年中，我们已经在微软内部的一些常用服务中使用了 DocumentDB，现在运行中的每个 DocumentDB 数据库都具有几百 TB 容量的数据，每天都要复杂百万级的复杂查询，并且依然保持性能良好，在延误方面至多只有几个毫秒而已。

那么这一产品对 Microsoft Azure 平台上其它的 NoSQL 工具会产生什么影响呢？微软目前依然提供了一套基于键 - 值对的 NoSQL 产品，名为 Azure Table Storage ，而且他们不久前才发布了一个基于 Redis 的缓存服务。而MongoDB 最近刚刚在Microsoft Azure 平台上创建了一个托管服务，它的走向还有待观察。不过，有一个基于Windows 的NoSQL 产品发言人对于DocumentDB 提出了尖锐的批评，即 RavenDB 的创建人 Oren Eini。他在一篇博客中表示 DocumentDB 并未给他留下什么深刻的印象，并且将他的吐槽一一列举如下：

• 缺乏排序选项，也没有良好的分页功能
• 容易遭受 SQL 注入攻击，并且没有其它的替代方案可以避免
• 难以部署，也难以配合现有的代码进行使用
• 在开发与测试两方面的感觉都很糟糕
• 糟糕的客户端 API
• 大量的表扫描
• 在查询与优化方面的选择太少
• 在客户端只能发起单表事务操作
• 完全不支持跨集合的事务操作
• 只支持极小的文档尺寸

虽然 DocumentDB 只刚刚发布了一个“预览”版本，但微软还是为它发布了.NET、Node.js、JavaScript 和 Python 等方面的 SDK。该产品的价格是基于“能力单元”进行计算的，每个单元级别支持每秒 2000 次读取、每秒 500 次插入、替换或删除操作、以及 10GB 的存储空间。在预览阶段，每个能力单元的价格为每天0.73 美元，比起预计的正式商用版价格大约便宜了50%。DocumentDB 现在Microsoft Azure 的美国西部、欧洲北部以及欧洲西部地区可以使用。

查看英文原文： Microsoft Introduces NoSQL Document Database for Microsoft Azure