深度：Microsoft全球规模的NoSQL分布式数据库

数据库 NoSQL 云计算 数据库管理 Microsoft

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能够被更多用户所接受。