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