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