深入解讀:微軟云數據庫服務Azure DocumentDB的“同”與“不同”
微軟的Azure云平臺提供了一系列的數據存儲服務，包括文件存儲、BLOB存儲以及關系型數據庫存儲。而在去年8月份，微軟還發(fā)布了一款新的云數據庫服務Azure DocumentDB。與其他服務相比，DocumentDB究竟有哪些特別之處，它解決了用戶哪些需求。在本文中，我們就將深入介紹一下微軟AzureDocumentDB文檔數據庫存儲。
首先，DocumentDB在一些場景中會比傳統關系型數據庫更有優(yōu)勢。文檔數據庫在NoSQL家族中是***且應用最為廣泛的一類，比如MongoDB。它通過JSON文檔來存儲數據，不需要固定的Schema生成數據表（table）和列（column）。開發(fā)人員可以根據需求來創(chuàng)建一系列的集合（collection）、文件和字段。你可以把集合看作是關系型數據庫中的表，文件就相當于一張表中的行（row），字段相當于表中的列。
因為文檔數據庫沒有固定的結構，所以開發(fā)者可以根據新的數據需求來快速地進行調整。舉例來說，關于一本書信息，用關系型數據庫來存儲的話，它的列將包含書名、作者、出版社、出版日期以及頁數等。現在電子書這么流行，要添加電子書文件大小的信息，傳統上來說DBA需要先修改數據庫表的定義，才能添加新的列。而使用文檔數據庫就可以自動地添加新的字段，DBA將文件大小字段（通常以KB來計算）添加到JSON文檔，然后存儲到數據庫即可。包括產品、客戶以及設備等信息都可以使用文檔數據庫來存儲相應的數據。
在讀寫方面，文檔數據庫也有著獨特的優(yōu)勢。但對于那些已經習慣關系型數據庫的人來說，文檔數據庫要體現它的優(yōu)勢則需要不同的方法來進行設計。
這些數據庫往往是去規(guī)范化的，通過一個單獨的文檔來存儲相關內容，而不是使用幾張表。去規(guī)范化的宗旨是避免連接（join），它是造成查詢延時的罪魁禍首之一。 連接只有在擁有適當索引的數據庫表和精心設計的查詢語句當中才能夠體現出高效率。但由于要在不同的表之間進行鍵（key）的匹配，同時需要在磁盤的不同位置來檢索數據，因此產生延遲是不可避免的。
DocumentDB的“同”與“不同”
Azure DocumentDB與其他比較流行的文檔數據庫有所不同，它的一些特性更合傳統關系型數據庫開發(fā)人員的胃口。它支持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支持存儲過程、用戶定義函數和觸發(fā)器，這些都是SQL Server用戶非常熟悉的功能。此外，DocumentDB不使用T-SQL，它是由JavaScript語言開發(fā)的。
.NET開發(fā)者可能更傾向于使用LINQ庫來查詢DocumentDB，查詢處理器可以將LINQ查詢映射到SQL查詢中，并將其運行在數據庫上。
微軟以容量單位來收取DocumentDB的費用，即存儲數據所需要的核心資源。一個標準的容量單位包括10GB的本地SSD存儲，每秒2000個請求和2GB的BLOB存儲。其中每秒2000個請求對于每秒2000個讀操作或者500個插入、替換和刪除操作已經綽綽有余。在服務預覽階段，微軟將以半價的形式收取服務費用，即每一個容量單位的DocumentDB收費標準為0.73美元/天。
