深度：微软全球规模分布式数据库 NoSQL

SQL Server 在企业环境中有很大优势，但很多人可能不知道，由于旗下诸如 Power BI、Bing，以及 Office Web Apps 等应用面临一些新的挑战，例如数据泛滥、对移动性的需求激增、对低延迟的渴求。过去五年来 Microsoft 一直在打造一个分布式 NoSQL 数据库。

这一项目是由曾经负责开发 Windows Workflow Foundation（以及 Live Mesh 和从来未曾面世的 Courier 平板）等重要技术的 Microsoft 员工 Dharma Shukla 从 2010 年底开始负责的。该项目的目标是为 Microsoft 开发全球规模的分布式数据库系统。

2014 年 8 月，Microsoft 将 DocumentDB 作为一种 Azure 服务发布了公开预览版。这一举措证明了 NoSQL 世界中已经出现的紧张形势，NoSQL 提供了自由的数据格式，但传统 SQL 提供了数据一致性和事务原子性。在这两个领域，越来越多的人正在努力提供融合这两种特性的方式。

对于 Azure DocumentDB，业界普遍认为这种技术最吸引人的地方是：它不是对开源项目的重新包装，也不是对现有微软产品的扩展或重写，而是一个全新的产品。

DocumentDB 所强调的一个重点在于 NoSQL 真正代表的含义：“not only SQL（不只有 SQL）”，该技术的目标在于在各方面为用户提供更好的选择。DocumentDB 可实现 NoSQL 的扩展能力，SQL 的丰富功能，在全球 17 个 Azure 落地的地区通过基于 SSD 的群集获得的低延迟，以及商用化 Azure 服务提供的服务级别协议，外加与 HIIPA 和 ISO 有关的合规性。DocumentDB 还提供了与 JavaScript 集成所实现的数据库编程和 Hadoop 分析能力。

作为云 PaaS 服务，DocumentDB 省略了自行配制 NoSQL 数据库的各种繁琐操作，甚至通过暴露 MongoDB API，还可无需改动直接运行 MongoDB 应用程序。借此 DocumentDB 用户可以通过一种新的方式在本地环境中尝试 DocumentDB 应用，并能通过更为快速的方式将 MongoDB 应用迁往云中，同时避免遇到 MongoDB 用户经常需要面对的安全困扰。

负责这一项目的 Microsoft 员工 Dharma Shukla 认为：“这个项目的重点是为开发全球规模分布式应用程序的开发者提供一种全球规模的数据库，这种数据库可以用于 Web 应用，移动应用，物联网应用，任何希望全球化规模的应用都可以顺利使用…… 我们能提供类似 NoSQL 存储系统那样的规模，同时能使用 SQL 作为查询语言。”

规模化，支持 SQL 查询语法

类似 SQL Server 这样的关系型数据库是为过去的典型工作负载设计的。以前的传统应用中，人们对数据库读取速度的关注远远超过写入速度。但现在情况不同了，物联网设备会生成大量信号，可联网汽车会生成大量类似发动机温度之类的信息。信息的生成已经不足以用“海量”来形容。全球各地正在以极高的速度生成大量数据，数据库写入操作开始变得更重要。SQL 在响应查询方面的表现很不错，但随着写入操作的崛起，NoSQL 顺势而起。

NoSQL 数据库针对写入操作的处理进行了优化，可实现极大的规模。但从数据库读取内容时，NoSQL 无法提供丰富的查询功能。用户真正需要的是一种针对写入操作进行优化的数据库引擎，这种引擎必须能支持足够大规模的快速写入，同时依然能提供丰富的查询功能。与其他 NoSQL 方法不同，DocumentDB 的用户无需在规模和强大的查询能力之间进行取舍，通过吞吐率和存储之间的去耦合，用户可以对吞吐率进行灵活缩放，同时保持存储系统的相对独立。

Shukla 举了一个例子：“使用 DocumentDB 的过程中，用户甚至可以实现：‘预计我的网站在 9-10 点之间会产生极高的流量，需要实现每秒上百万次写入的指标，但在全天的其他时段我希望恢复为每秒一百次写入的正常指标。’用户可以动态更改吞吐率和存储需求，服务的调整工作将由云平台自动进行。”此外还可以仅缩放一个地区的服务，但其他地区保持不变。

直接使用服务而无需考虑架构细节，这一特性消除了部署工作面临的一个最常见的障碍。为了每周给一个 Web 服务部署更新，用户通常需要留出一定的时间管理对数据库内不同字段所做的改动，需要创建新的架构，需要丢其并新建索引，而在进行这一切操作时，数据库无法处理任何查询。但在使用 DocumentDB 的情况下，用户可以在程序内部更改应用程序和数据结构，随后直接将这些改动发送至数据库即可，无需担心架构或辅助索引的创建。这意味着花费更少的精力就能以更高的频率对自己开发的应用进行迭代。

这一特性与搜索引擎常用的蜘蛛程序非常类似。搜索引擎的蜘蛛程序无需考虑网页布局，只需要关注网页的内容。而 DocumentDB 也只需要关注和处理各种 JSON 文档。这样的特性使得开发者可以更加轻松地掌握 DocumentDB，因为数据库引擎本身也使用了 JavaScript 语言。

全新类型的一致性

任何分布式系统都需要确保数据库的分布式副本保持一致。DocumentDB 在这方面的独特之处在于，与其他 NoSQL 数据库不同，DocumentDB 在强一致性（Strong consistency）和最终一致性（Eventual consistency）之外提供了新的选择。

强一致性确保了用户始终可以获得数据库中所存储内容的最新版本，但速度可能会略慢。最终一致性的延迟更低，但确保了用户最终将获得最新版本。

目前其他所有技术只提供了两个选择：强一致或最终一致。选择强一致需要在敏捷度方面妥协，选择最终一致需要在编程模型方面妥协。这造成了两种极端的选择，而且跨越多个数据中心的应用无法实现强一致，此时只能选择最终一致。而很多用户选择最终一致的唯一原因就在于，只有这种方式可以同时兼顾到高可用和低延迟。

DocumentDB 新增了两种一致性级别：会话（Session）一致和限制陈旧（Bounded Staleness）一致。

(点击放大图像)

会话一致可以维持会话内部（仅限会话内部，而不能涵盖整个数据库）读写操作顺序为最高优先级，或者确保维持所有读写操作的顺序并让读取操作在新写入操作完成后等待一个固定的时间间隔再开始处理。在会话和限制陈旧层面上实现的一致性级别为用户分布式系统中不同因素的权衡提供了更多选择。

会话一致提供了与最终一致同样出色的可用性和延迟，同时可以使用更加可预测的编程模型。这种模式主要被用于开发移动应用、游戏，以及社交类应用，但也很适合用于消息、分析，以及物联网应用。

限制陈旧可以在整个数据库范围内确保读写操作按顺序进行。Shukla 举了一个例子：“例如在开发证券行情自动记录收报机应用时，这种情况生成的数据只有一个来源，其他端点都是这些数据的消耗方，同时用户会希望实现可预测的读取延迟。每次在美国西海岸写入数据后，用户希望在例如不超过90ms 的时间内读取到这些数据，并且无论西海岸执行了多少次写入操作，用户都会希望在整个世界范围内精确维持这样的操作顺序，这种需求就很适合使用限制陈旧模式。”

据悉这两个选项使得DocumentDB 更加独一无二，目前仅1-2% 的DocumentDB 用户会继续使用经典的强一致和最终一致级别。

DocumentDB，沧海遗珠？

DocumentDB 业务还不够广为人知，但目前已经实现 20% 的月增长率。Microsoft 未给出确切数字，但 Shukla 声称 DocumentDB“已获得比 MongoDB、Basho，以及其他同类本地 NoSQL 数据库产品在内更多的付费用户。MongoDB 实现了上千万的下载量，但付费用户只占到其中的一小部分。”

据悉 DynamoDB 曾是市面上唯一可以支持 SSD 后端系统的，但 DocumentDB 除了使用 SSD 作为后端，还可以针对架构无关（Schema-free）数据实现丰富的查询功能，而 DynamoDB 只能提供有限的，基于分区的查询。选择 Cassandra 的用户意在全球性布局，但无法进行查询；选择 MongoDB 的用户意在该软件为 NoSQL 市场提供的专用工具所实现的查询能力，但需要承担大量架构管理工作，同时该技术还缺乏 SQL 或 JavaScript 查询能力。

作为一种 PaaS 服务， DocumentDB 清晰明了的服务级别协议（SLA）也是一种优势。SLA 对于大型企业用户来说很重要，能够在服务使用全过程中为数据丢失和出错、延迟、查询、可用性、吞吐率等方面提供担保。

目前 Microsoft 内部已经在 Xbox、Bing、Microsoft HoloLens、Office Web Apps 以及多个 Azure 服务中使用了 DocumentDB。由于能够兼容 MongoDB，Microsoft 希望 DocumentDB 能够被更多用户所接受。

查看英文原文： Meet Microsoft’s ‘planet scale’ NoSQL database

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。