Azure Cosmos DB技术性解读
Azure Cosmos DB是微軟公司打造的一項全球分布式、橫向分區、多模型數據庫服務。該服務允許客戶彈性（及獨立形式）跨越任意數量地理服務區對吞吐量與存儲進行擴展。Azure Cosmos DB可立足第99百分位比例提升99.99%高可用性水平，提供可預測吞吐量以及多套經過明確定義的一致性模型，從而保證實現低延遲表現。Azure Cosmos DB亦當前行業中第一項，同時也是惟一一項全球分布式數據庫服務。其可提供全面的服務水平協議（簡稱SLA），其中涵蓋客戶最為關心的四大維度：吞吐量、第99百分位比例延遲表現、可用性以及一致性。
作為一項云服務，我們對Azure Cosmos DB進行了精心設計與工程開發，同時充分考慮到多租戶及全球分布等實際因素。在今天的博文當中，我們將對Azure Cosmos DB當中的關鍵性功能以及架構選擇作出解讀。
Azure Cosmos DB基本信息
圖靈獎獲得者兼全球知名計算機科學家Leslie Lamport博士的工作成果深刻影響到眾多大規模分布式系統。Azure Cosmos DB自然也不例外。在Azure Cosmos DB長達七年的構建過程當中，Leslie的成果一直是我們最重要的靈感源泉。
在此前接受采訪時，Leslie亦分享了他對于Azure Cosmos DB基礎架構的看法及其在Azure Cosmos DB設計工作當中發揮的巨大作用。
Azure Cosmos DB的設計目標
Azure Cosmos DB自2010年起既已立項，當時的代號為“Florence項目”。其目標在于解決開發者在微軟環境下構建互聯網規模應用程序時面臨的幾大根本性痛點。我們為Azure Cosmos DB制定出以下發展目標。
保證客戶能夠在全球規模下根據需求以彈性方式擴展吞吐量與存儲量。?從收到請求到完成擴展，這套系統應能夠在99%比例的場景下于5秒之內交付經過配置的吞吐能力。
幫助客戶構建起具備高度響應性的關鍵性任務應用程序。?這套系統必須能夠在99%比例的場景下交付可預測且擁有可靠性保障的端到端低讀取與寫入延遲。
確保這套系統“始終開啟”。這套系統必須實現99.99%的可用性，且不因與數據庫相關的具體服務區數量而受到影響。為了保證客戶能夠對應用程序的端到端可用性屬性進行測試，該服務必須能夠在穩定狀態下允許客戶模擬服務區故障或者標記與其數據庫下線狀況相關的服務區。這將有助于難應用程序的端到端可用性屬性。
使得開發人員能夠編寫出正確的全球分布式應用程序。這套系統必須圍繞數據一致性提供直觀且可預測的編程模型。盡管強大的一致性會帶來成本提升，但僅依托于“最終一致性”在數據庫當中編寫大型全球分布式應用程序將引發難以回溯的應用程序代碼問題、缺陷以及正確性bug。
為之前4項目標提供嚴格且符合財務要求的綜合性SLA。
減輕開發人員所面臨的數據庫模式/索引管理以及版本控制等負擔。對于全球分布式應用程序而言，確保數據庫模式與索引同應用程序模式保持同步往往尤為難以實現。
以原生方式支持多種數據模型以及各類高人氣數據訪問API。外部公開API與內部數據表達之間的翻譯流程必須高效可行。
提供極低運營成本以幫助客戶節約資金投入。
Azure Cosmos DB設計中值得強調的各個方面
無論立足單一目標抑或是全部要求，以上提到的各項前提都需要新穎的解決方案與復雜的工程權衡方有望實現。Azure Cosmos DB在設計當中的獨特之處，在于我們采取獨特的方法以引導這些約束條件并在各工程技術任務之間選取最佳平衡點。
以下為Azure Cosmos DB系統設計當中值得強調的各個重要方面。我們將在后續博文當中更為具體地為大家闡述其相關細節。
Azure Cosmos DB的設計旨在以動態形式配置數據庫引擎與底層存儲之間的接近度，從而支持匹配不同性能SLA的多個服務層。根據具體服務層，系統可通過配置用于支持計算及存儲資源，從而（a）立足同一進程空間進行同地協作; （b）立足同一集群內的各設備進行分解; 或者（c）跨越同一服務區內多個不同集群/數據中心進行分解。
Azure Cosmos DB面向吞吐能力、延遲、一致性以及可用性等角度建立起綜合性SLA體系。這些SLA負責明確定義一套全球分布式設置當中對于延遲、一致性、可用性以及吞吐能力間的權衡結果。
Azure Cosmos DB在系統內核層面采取獨特的資源治理設計，其能夠提供一套一致性編程模型以跨越一組異構性數據庫運營集實現吞吐能力配置。
Azure Cosmos DB擁有一套高度模塊化且資源得到充分治理的方案，旨在解決各類常見協調問題，具體包括跨服務區復制以及透明分區管理等等。
Azure Cosmos DB在設計上能夠跨越多個地理服務區實現吞吐能力的彈性擴展，同時保證不影響到SLA。該系統在設計上即考慮到跨服務區吞吐量擴展需求，且可確保吞吐量變化以即時形式存在。
Azure Cosmos DB的設計與實現方案可精確指定一組簡單明確且符合TLA+要求的、經過良好定義的一致性模型。這種能力使得各一致性模型能夠充分適應各類現實場景，提供可證明的一致性保證，在多租戶與全球分布式設置當中擁有商業可行性，同時提供一套直觀的編程模型以幫助開發人員編寫出正確的分布式應用程序。據我們所知，Azure Cosmos DB亦是目前市場上惟一一套全球分布式數據庫系統，其可實現有限過期、會話與一致性前綴等一致性模型的順利運營，同時將其交付給開發者并配合明確的語義、性能/可用性權衡以及SLA支持能力。
Azure Cosmos DB擁有一套寫入優化型資源治理與模式中立式數據庫引擎（備注：自相關論文發布以來，其又迎來了可觀的長足演進）。這套引擎能夠持續處理大規模更新，以自動化方式對全部輸入內容進行索引，并在保證確認客戶更新前以同步方式實現索引持久性與高可用性的同時，維持穩定的低延遲表現。
Azure Cosmos DB在設計中充分考慮到其核心數據模型與類型系統的具體需求并配合極具可擴展數據庫引擎設計，旨在允許用戶高效向其核心數據模型當中添加、翻譯以及投射多種數據模型以及API與編程語言類型系統。
一項多模型、多API數據庫服務
(點擊放大圖像)
圖一：Azure Cosmos DB是一套多模型、多API全球分布式數據庫平臺
如圖一所示，Azure Cosmos DB能夠原生支持多種數據模型。Azure Cosmos DB數據引擎的核心類型系統基于原子-記錄-序列（簡稱ARS）。各原子由一組小型原始類型組成，具體包括字符串、布爾類型以及數字等組成。其中各記錄為結構體，序列則為包含有原子、記錄或序列的數組。Azure Cosmos DB的數據庫引擎能夠高效將各數據模型翻譯并投射至基于ARS的數據模型當中。Azure Cosmos DB的核心數據模型可原生接受來自動態類型編程語言的訪問，并可直接表達為JSON或者其它類似的形式。這樣的設計亦使其能夠原生支持用于數據訪問及查詢的各類主流數據庫API。Azure Cosmos DB的數據庫引擎目前支持DocumentDB SQL、MongoDB、Azure Table Storage以及Gremlin圖形查詢API。我們還計劃對其進行進一步擴展，借以支持其它高人氣數據庫API。而最重要的優勢在于，開發人員可以利用流行的OSS API以構建應用程序，且同時享受經過實戰驗證且完全受控的全球分布式數據庫系統所能帶來的所有助益。
資源模型與API投射
開發人員能夠通過訂閱Azure的方式配置數據庫帳戶，從而輕松運用Azure Cosmos DB。數據庫帳戶負責管理一套或者多套數據庫。Azure Cosmos DB數據庫能夠管理用戶、權限以及容器。Azure Cosmos DB容器屬于模型中立型容器，可用于容納用戶生成的任意實體、存儲規程、觸發器以及用戶定義函數（簡稱UDF）。客戶數據庫帳戶當中的各類實例——包括數據庫、用戶、權限以及容器等等——皆被稱為資源，具體如圖二所示。
(點擊放大圖像)
圖二：資源模型與API投射
每種資源皆由一條穩定的邏輯URI作為惟一標識，并被表達為一個JSON文檔。使用Azure Cosmos DB的應用程序的整體資源模型屬于一套層級化資源疊加結構，根植于數據庫帳戶當中并可利用超鏈接進行導航。除了用于表達用戶所定義的任意內容的條目資源內容之外，所有其它資源皆遵循一套系統定義模式。條目資源的內容模型基于此前提到的原子-記錄-序列（簡稱ARS）原則。如表一所示，容器與條目資源皆被進一步投射為面向特定API接口類型的物化資源類型。舉例來說，在使用面向文檔API時，容器與條目資源會被分別投射為集合（容器）與文檔（條目）資源; 同樣的，對于面向圖形的API訪問，底層容器與條目資源會被分別投射為圖形（容器）、節點（條目）以及邊緣（條目）資源; 而在使用鍵-值API進行訪問時，其將被投射為表（容器）與條目/行（條目）。
?
| API | 容器被投射為…… | 條目被投射為…… |
| DocumentDB SQL | 集合 | 文檔 |
| MongoDB | 集合 | 文檔 |
| Azure Table Storage | 表 | 條目 |
| Gremlin | 圖形 | 節點與邊緣 |
表一：基于特定API數據模型的容器與條目投射方式。
橫向分區
(點擊放大圖像)
圖三：利用橫向分區實現彈性可擴展性。
Azure Cosmos DB容器當中的全部數據（例如集合、表以及圖形等）皆由資源分區進行橫向分區與透明化管理，具體如圖三所示。一個資源分區，是指一套根據客戶指定分區-鍵進行分區的一致性、高可用性數據容器; 其負責為其管理下的資源組提供單一系統鏡像，且屬于可擴展性與分布機制的基本單元。Azure Cosmos DB在設計當中充分考慮到客戶根據不同地理服務區間應用程序流量模式實現吞吐量彈性擴展的需求，幫助其借此支持受地理位置與時間因素影響的波動性工作負載。該系統以透明化方式管理各分區，且不會影響到Azure Cosmos DB容器的可用性、一致性、延遲或者吞吐能力。
客戶可立足Azure Cosmos DB容器以分或秒等粒度水平通過編程方式配置吞吐量，從而實現容器的彈性吞吐能力擴展。從內部來看，該系統以透明方式管理各資源分區，從而為特定容器提供其需要的吞吐能力。大家可以根據自身系統資源預算水平對整體吞吐量進行劃分，借此交付不同資源分區，并最終利用資源橫向分區實現吞吐量的彈性擴展。由于Azure Cosmos DB容器擁有全球分布式特性，因此Azure Cosmos DB可確保某一容器的吞吐量可用于該容器分布涵蓋到的全部服務區，而且整個各數值變更只需要數秒即可完成。客戶可通過分或秒等粒度級別對Azure Cosmos DB容器的吞吐量進行配置（吞吐量的請求單位，簡稱RU，被稱為‘貨幣單位’）。以分鐘級別配置的吞吐量適用于管理工作負載當中以秒為單位出現的意外資源需求峰值。舉例來說，客戶可能以一小時為周期在某一容器當中配置10000 RU每秒與100000 RU每分鐘。如圖四所示，該工作負載在任意某分鐘內出現的資源需求峰值會被該分鐘內配置的RU每分鐘所抵消。在本示例當中，客戶能夠將吞吐量的整體配置成本降低達73%。
(點擊放大圖像)
圖四：客戶在處理意外工作負載峰值時，利用RU每秒與RU每分鐘方式降低實現成本。
立足基礎層面建立全球分布體系
如圖五所示，客戶資源通過兩大維度進行分布：在特定服務區中，全部資源雙可利用資源分區進行橫向分區（本地分布）。而各資源分區亦可跨地理服務區進行復制（全球分布）。
(點擊放大圖像)
圖五：同一容器可同時進行本地與全球分布。
當客戶對吞吐量或存儲量進行彈性擴展時，Azure Cosmos DB能夠以透明方式在所有服務區內執行分區管理操作。無論具體規模、分布或者故障情況如何，Azure Cosmos DB都能夠持續提供單一全球分布式資源系統鏡像。Azure Cosmos DB當中的資源全球分布系統屬于交鑰匙型方案：無論何時，您僅需數次點擊（或者通過編程方式進行一次API調用），即可將任意數量地理服務區與其數據庫帳戶進行關聯。另外，無論數據規模或者服務區數量如何，Azure Cosmos DB皆保證在99%比例的場景下，能夠于接到客戶申請的1小時之內完成服務區關聯。之所以能夠實現這一效果，是因為我們以并行方式將來自全部源資源分區的數據饋送并復制至新的關聯服務區當中。客戶亦可移除現有服務區，或者對原本關聯至其數據庫帳戶的服務區進行“離線”操作。
透明多歸屬與99.99%高可用性
客戶也可以將“優先級”動態關聯至與其數據庫帳戶相關的服務區處。一旦發生服務區故障，此優先級可用于將請求定向至特定服務區。而且盡管可能性極低，但如果出現服務區規模的災難事件，Azure Cosmos DB亦會根據優先級設定進行自動故障轉移。為了測試應用程序的端到端可用性，客戶可以手動方式觸發故障事件（要求每小時內最多進行兩次此類操作）。Azure Cosmos DB保證在客戶觸發服務區故障時提供零數據丟失保障，同時為服務區災難期間因系統觸發之自動故障轉移帶來的數據丟失狀況設定上限。應用程序本身并不需要在服務區故障狀況下進行重新部署，而且可用性SLA仍然有效。為此，Azure Cosmos DB允許開發者利用邏輯（任意服務區）或者物理（特定服務區）端點與其資源進行交互。前者能夠確保應用程序在故障場景下以透明化方式實現多歸屬; 后者則提供細粒度控制，以確保將指向該應用程序的讀取與寫入請求重新定向至特定服務區。Azure Cosmos DB為每個數據庫帳戶提供高達99.99%的可用性SLA。這一可用性保證不因具體規模（客戶數據庫中的實際吞吐量與存儲量）、服務區數量或者特定數據庫所關聯之各服務區間的地理距離而受到影響。
在99%的場景下提供低延遲保證
作為SLA中的組成部分，Azure Cosmos DB向客戶作出99%場景下的端到端低延遲保證。對于典型的1 KB條目，Azure Cosmos DB承諾在同一Azure服務區內，在99%的場景下實現端到端讀取延遲低于10毫秒、索引寫入延遲則低于15毫秒。其平均延遲通常比承諾低得多（低于5毫秒）。通過為各項數據庫事務設定的請求處理上限，Azure Cosmos DB允許客戶端明確區分各事務間的高延遲與不可用數據庫。
SLA支持下的多種經過良好定義的一致性模型
目前可用的商業分布式數據庫可分為兩類：（1）不提供經過良好定義且可證明的一致性選項的數據庫; （2）提供兩種極端一致性選項的數據庫——即強一致性與最終一致性。前一種系統要求應用程序開發人員自行為其復制協議負責，這意味著開發者必須獨力在一致性、可用性、延遲以及吞吐量之間作出艱難探索。后一種系統則以非黑即白的方式強迫開發者作出極端性選擇。盡管目前已經出現眾多關于一致性模型的研究與建議，但商業分布式數據庫服務仍然沒能在強一致性與最終一致性之外真正構建起可行的一致性實現途徑。相比之下，Azure Cosmos DB允許開發者根據一致性頻譜（如圖六所示）從五種經過良好定義的一致性模型當中作出選擇——具體包括強一致性、有限過期一致性、會話一致性、一致性前綴以及最終一致性。
(點擊放大圖像)
圖六：頻譜中列出多種經過良好定義的一致性選項。
開發者們能夠利用Azure Cosmos DB在其數據庫帳戶當中對默認一改級別進行配置（隨后新配置將覆蓋特定讀取請求的一致性設定）。從內部來看，默認一致性級別往往適用于跨服務區分區組內的數據。根據統計，我們的客戶中有73%使用會話一致性，而20%傾向于選擇有限過期一致性。我們發現，約有3%的客戶會首先實驗我類一致性級別，而后才為應用程序作出特定級別選擇。我們同時發現，平均只有2%的客戶會立足單一請求采用不同的一致性級別。為了向客戶通報有違一致性SLA的狀況，我們采用一套線性檢查器并保證其在所遙測的服務當中持續運行。在有限過期選項當中，我們會監控并報告一切有違k與t界限的狀況。對于所有四種較為寬松的一致性選項，我們還特別對概率性有限過期（簡稱PBS）指標進行了追蹤與報告。
全資源治理堆棧
Azure Cosmos DB旨在允許客戶以彈性方式根據應用流量模式跨越不同服務區實現吞吐量擴展，從而立足地理位置與時間因素支持波動性工作負載。要以具備成本效益的方式運營成千上萬種不同類型的全球分布式工作負載，我們必須實現細粒度多租戶機制，即由數百家客戶共享同一設備，并由數千家客戶共享同一集群。為了在保證運營成本效益的同時實現各客戶間的性能隔離，我們從根本層面充分考量了系統的資源治理方式。作為一套資源治理系統，Azure Cosmos DB屬于一套包含眾多級聯組件的大規模分布式隊列系統，且其中各組件皆通過精心調校以保證在系統資源預算配額范圍之內提供可預測的吞吐能力。為了以最佳方式利用特定集群當中的系統資源（包括CPU、內存、磁盤以及網絡），集群中的每臺設備都可以動態方式托管十余家到百余家客戶。另外，從準入控制到全部I/O路徑，整體堆棧內皆部署有速率限制與背壓控制機制。我們的數據庫引擎可實現細粒度并發性，并在盡可能節約系統資源的同時最大程度提供高吞吐量。
單位時間內發生的數據庫操作數量（即吞吐量）屬于系統資源預留與消費的基本單位。客戶可以針對具體數據執行廣泛的數據庫操作。而根據實際操作類型與載荷（請求與響應），操作所消費的系統資源量亦有所區別。為了為計算請求所消耗的資源建立標準化模型，將系統資源預算同特定資源分區所需要交付的吞吐量相關聯，同時為客戶提供無關硬件形式的一致性數據庫操作吞吐能力，我們為吞吐量定義出一種基于速率的抽象貨幣，并將其稱為請求單位或者RU（詳見圖七）。這一單位適用于兩種基于時間粒度的維度——請求單位每秒（RU/s）以及請求單位每分（RU/m）。客戶可以彈性方式通過編程配置容器上的RU/s（及/或RU/m），從而實現容器吞吐能力擴展。從內部來看，該系統管理各資源分區以為特定容器交付吞吐能力。要利用資源橫向分區機制實現吞吐量的彈性擴展，要求各個資源分區能夠根據特定系統資源預算交付整體吞吐量中的一部分。
(點擊放大圖像)
圖七：RU/s（及RU/m）為各數據庫操作吞吐量的標準化貨幣單位。
作為準入控制機制的一部分，每個分區則采用自適應速率限制規則。如果資源分區在一秒內接收到的請求數量超出了其經過校準的響應能力，則客戶端將收到“請求速率過大”提示，并需要等待特定時間間隔方可進行重試。資源分區每秒對RU備用容量（如果有）執行（限制）背景調查（例如對日志結構化數據庫引擎進行背景調查、定期提取快照備份以及刪除過期條目等）。一旦請求被核準，我們即會計算其中每項微操所消耗的RU資源（例如分析條目、讀取/寫入頁面或者執行查詢運算等）。
結論
Azure Cosmos DB將全球分布、彈性橫向可擴展性以及多模型與模式中立式數據庫引擎作為設計目標。作為一套云原生多租戶數據庫系統，Azure Cosmos DB在設計上充分考慮到立足整體堆棧實現資源交叉治理。從初始設計開始，我們就要求Azure Cosmos DB必須具備全球數據分布、多種明確一致性水平選項、彈性跨地理服務區吞吐量擴展等能力，同時必須在自身綜合性SLA當中涵蓋全部客戶對于吞吐量、一致性、延遲以及可用性的實際要求。
鳴謝
Azure Cosmos DB于2010年以“Florence項目”的形式正式誕生，期間被納入Azure DocumentDB并最終逐步發展為現在Azure Cosmos DB的形式。我們對Dave Campbell、Mark Russinovich、Scott Guthrie以及Gopal Kakivaya提供的支持表示由衷感謝。我們也要感謝多年以來微軟各團隊多年以來對Azure Cosmos DB的廣泛使用。我們站在了巨人的肩膀上——Azure Cosmos DB當中眾多組件技術正是前輩大德們辛勤耕耘的結果; 另外還要感謝Service Fabric團隊為我們提供了強大的分布式系統基礎設施以及支持與合作。我們感激Leslie Lamport博士帶來的深刻啟發，這亦不斷影響著我們在分布式系統設計方法層面的理解方向。最后但同樣重要的是，我們要感謝Azure Cosmos DB工程師團隊作出的發展承諾以及為此投入的不懈努力。
原文地址：http://www.infoq.com/cn/articles/technical-interpretation-of-azure-cosmos-db
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的Azure Cosmos DB技术性解读的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AspectCore.Extension
- 下一篇： 使用BigQuery分析GitHub上的