微软的Azure云平台提供了一系列的数据存储服务，包括文件存储、BLOB存储以及关系型数据库存储。而在去年8月份，微软还发布了一款新的云数据库服务Azure DocumentDB。与其他服务相比，DocumentDB究竟有哪些特别之处，它解决了用户哪些需求。在本文中，我们就将深入介绍一下微软AzureDocumentDB文档数据库存储。
首先，DocumentDB在一些场景中会比传统关系型数据库更有优势。文档数据库在NoSQL家族中是***且应用最为广泛的一类，比如MongoDB。它通过JSON文档来存储数据，不需要固定的Schema生成数据表（table）和列（column）。开发人员可以根据需求来创建一系列的集合（collection）、文件和字段。你可以把集合看作是关系型数据库中的表，文件就相当于一张表中的行（row），字段相当于表中的列。
因为文档数据库没有固定的结构，所以开发者可以根据新的数据需求来快速地进行调整。举例来说，关于一本书信息，用关系型数据库来存储的话，它的列将包含书名、作者、出版社、出版日期以及页数等。现在电子书这么流行，要添加电子书文件大小的信息，传统上来说DBA需要先修改数据库表的定义，才能添加新的列。而使用文档数据库就可以自动地添加新的字段，DBA将文件大小字段（通常以KB来计算）添加到JSON文档，然后存储到数据库即可。包括产品、客户以及设备等信息都可以使用文档数据库来存储相应的数据。
在读写方面，文档数据库也有着独特的优势。但对于那些已经习惯关系型数据库的人来说，文档数据库要体现它的优势则需要不同的方法来进行设计。
这些数据库往往是去规范化的，通过一个单独的文档来存储相关内容，而不是使用几张表。去规范化的宗旨是避免连接（join），它是造成查询延时的罪魁祸首之一。 连接只有在拥有适当索引的数据库表和精心设计的查询语句当中才能够体现出高效率。但由于要在不同的表之间进行键（key）的匹配，同时需要在磁盘的不同位置来检索数据，因此产生延迟是不可避免的。
DocumentDB的“同”与“不同”
Azure DocumentDB与其他比较流行的文档数据库有所不同，它的一些特性更合传统关系型数据库开发人员的胃口。它支持SQL集合查询，底层数据库引擎经过调整后可以更好地适应JSON文档存储。然而，DocumentDB的SQL与标准化的SQL之间还是存在一定差异。举例来说，DocumentDB SQL支持数据的分层引用。如果在一个集合中有一个客户文档叫做“'customers”，这个文档又包含一个地址文档的话：
- {
- customer_id: 139839,
- customer_fname: 'Susan',
- customer_lname: 'Washington',
- customer_address: {
- street: '1256 SE Main St',
- city: 'Portland',
- state: 'ME'
- }
- }
在这种情况下，你需要在SQL语句中以“customers.customer_address.city”引用城市。它的查询语言还支持数组，这在文档数据库中是很常见的。
DocumentDB能够在没有指定索引的情况下自动地对文档进行索引。如果你已经习惯在关系型数据库中把索引数量控制在最少以改善写性能，那么这个功能也许就没那么重要。但对于文档数据库来说却不同，因为文档中的字段是千变万化的。任何一个字段，即使是在很少文档中包含的字段，也可能会用在一个WHERE语句里，那么它就可以从索引中获益。
DocumentDB支持存储过程、用户定义函数和触发器，这些都是SQL Server用户非常熟悉的功能。此外，DocumentDB不使用T-SQL，它是由JavaScript语言开发的。
.NET开发者可能更倾向于使用LINQ库来查询DocumentDB，查询处理器可以将LINQ查询映射到SQL查询中，并将其运行在数据库上。
微软以容量单位来收取DocumentDB的费用，即存储数据所需要的核心资源。一个标准的容量单位包括10GB的本地SSD存储，每秒2000个请求和2GB的BLOB存储。其中每秒2000个请求对于每秒2000个读操作或者500个插入、替换和删除操作已经绰绰有余。在服务预览阶段，微软将以半价的形式收取服务费用，即每一个容量单位的DocumentDB收费标准为0.73美元/天。
