本文章是由機器翻譯。

.style0 { background-color:#E2F4FD;padding:5px; } .style1 { vertical-align:bottom; } .style2 { vertical-align:top; } .style3 { vertical-align:top; } .style4 { vertical-align:top; } .style5 { vertical-align:top; } .style6 { vertical-align:bottom; } .style7 { vertical-align:top; } .style8 { vertical-align:top; } .style9 { vertical-align:top; } .style10 { vertical-align:top; } .style11 { vertical-align:bottom; } .style12 { vertical-align:top; } .style13 { vertical-align:top; } .style14 { vertical-align:top; } .style15 { vertical-align:top; }

Windows Azure 內行人

雲端內 Windows Azure Tables 的 NoSQL 資料

Bruno Terkaly
Ricardo Villalobos

下載代碼示例

將資料存儲在磁片上的價格下降那麼厲害那似乎像是科幻小說，公司能夠存儲大量的資料，一發不可收拾。但能夠存儲大量資料，經濟上解決了只有一半的問題。資料已成為如此龐大而複雜傳統的資料庫管理工具和資料處理應用程式是遠遠不夠。隨著這麼多磁片上的資料，出現了新問題，如接收資料、 執行搜索、 共用資料、 分析它和，最終，直觀顯示它。

雲計算已加緊填補這一需要的力量。運行並行軟體解決方案的能力 — — 數十、 數百個或甚至數千台伺服器上運行 — — 是使組織能夠處理所有存儲資料的銀彈。

Microsoft 意識到這一重要趨勢幾年前。Windows Azure 存儲 (WAS) 2008 年 11 月發起，大大提高了企業的能力，要從數量龐大的資料存儲中獲得價值。

Brad卡爾德，傑出的工程師，在微軟和牧羊人帶領 WAS 系統，建設的話說"Windows Azure 存儲是雲存儲系統，為客戶提供高度可用和持久的任何時間段為存儲資料看似無限量的能力。當使用 Windows Azure 存儲時，你獲得您的資料從任何地方，在任何時候，，只支付您的使用和存儲。

是在 Microsoft 內部用於應用程式，如社會網路搜索 ； 現任視頻、 音樂和遊戲的內容 ； 和管理醫療記錄。它還用於通過 Bing 搜尋引擎提供幾乎立即公開可搜索內容從 Twitter 或 Facebook 的職位或狀態更新。約 350 TB 的資料，Facebook 和 Twitter 的資料的範圍是非凡。當此資料被攝入時，事務輸送量將達到每秒之間每天 2 到 30 億交易總計約 40000 項交易高峰。

這個月，我們將探索 WAS 的一個方面 — — Windows Azure 表 — — 無論它是如何工作和如何開發人員可以快速啟動並運行。

景觀

現代資料科學家面臨著很多選擇時選擇資料平臺，每個都有自己的長處和弱點。例如，許多大資料解決方案基於 NoSQL，這意味著並不使用關係資料庫管理系統 (RDBMS) 模型的概念 — — 有沒有表和任何 SQL 語句。相反，資料結構通常是大規模關聯陣列或鍵/值對的集合。受歡迎的選擇今天是 MongoDB、 卡珊多拉、 HBase、 附錄、 Neo4j 和 Windows Azure 表。這篇文章將集中在 Windows Azure 表上。

主要的差異，儘管 SQL 和 NoSQL 資料庫有一個共同點：這些技術是作為服務的雲計算，讓開發人員不用再向手動提供和 de-provision 的資料伺服器提供的。例如，Windows Azure 表作為服務提供，開發人員永遠不會覺得在不同的物理伺服器。

在本月的專欄中，我們將開始與淺的一些功能和 Windows Azure 表的能力。接下來，我們將提供一些代碼來演示如何您可能與 Windows Azure 表插入和查詢資料的工作。而且，最後，我們會看看的一些設計目標和 WAS 的高級別的實現細節。

基本觀念

Windows Azure 表的重要特性之一是跨三個地理上分散的地區，包括美國、 歐洲和亞洲提供了存儲。每個 Microsoft 資料中心符合國際組織的標準化 (ISO) 27001、 SSAE 16 ISAE 3402、 歐盟示範條款和健康保險可攜性與責任法案 (HIPAA) 業務關聯協定 (BAA) 標準。另一個重要功能是地理冗余存儲，使您可以複製您的資料在另一個資料中心內同一區域，添加另一級別的災害復原。

WAS 性能和能力是對存儲帳戶關聯起來。每個存儲帳戶包括 200 TB 的存儲容量。已優化 Windows Azure 表提供令人難以置信的快速查詢寫重工作負載下的性能。你可以閱讀更多在 bit.ly/cMAWsZ。

圖 1 顯示為 2012 年 6 月 7 日之後創建的單個存儲帳戶的可擴充性目標。

圖 1 可伸縮性目標為單個存儲帳戶的

有人分析也是可用的允許開發人員對存儲的跟蹤請求，使用趨勢分析和優化存儲帳戶中的資料訪問模式。閱讀更多在 bit.ly/XGLtGt。

請注意 WAS 系統包括其他抽象，如 blob 和佇列。我們將在這裡集中 Windows Azure 表，用於存儲非關聯式結構化和半結構化資料。他們支援 NoSQL 金鑰值查找在規模和寫重工作負載下的最簡潔的方式表達的 Windows Azure 表值。從開發人員的角度來看，Windows Azure 表是用於存儲大型物件集合的非均勻或現職高流量的網站上的頁面。

Windows Azure 表可以從幾乎任何地方訪問。整個存儲系統是具象狀態傳輸 REST 啟用的這意味著任何能夠 HTTP 的用戶端可以與 WAS 系統通信。明顯的客戶包括 iOS、 Android、 Windows 8 和不同的 Linux 發行版本。其餘 API 支援插入、 upserts、 更新和刪除操作，並選擇或查詢。

當使用 Windows Azure 表，起始點關鍵瞭解如何控制資料的分區方案。對於任何給定的 Windows Azure 表，資料架構師必須定義 （提前），PartitionKey 和 RowKey。這也許是最重要的決定，你會使用 Windows Azure 表時。PartionKeys 和 RowKeys 確定如何您的資料自動分區的存儲服務和您的查詢將執行的方式。建議您瞭解如何在名為 PartitionKey 和 RowKey 您決定最後定稿之前查詢您的資料。稍後，我們將深入探討力學事務的一致性及它們與 PartitionKeys 的關係。現在，讓我們看一下如何在 WAS 系統磁碟分割表的資料的一個簡單示例。

快速教學

想像一下您想要存儲和檢索電子郵件從變異­ou 的域例如，以下：bterkaly@microsoft.com、 ricardo.villalobos@microsoft.com、 brunoterkaly@hotmail.com 和 ricardovillalobos@hotmail.com。這些電子郵件地址中的功能變數名稱是 microsoft.com 和 hotmail.com，而電子郵件名稱是 bterkaly 和 ricardo.villalobos。典型的查詢首先搜索的功能變數名稱，然後通過電子郵件名稱。

在此簡單示例中，PartitionKey 和 RowKey 的選擇是相當簡單的。我們會將功能變數名稱映射到 PartitionKey 和 RowKey 的電子郵件名稱。

中的代碼圖 2 應使事情搞清楚。它說明了四個簡單的功能：

• 定義實體 (EmailAddressEntity)
• 定義的表，將存儲實體 （電子郵件­AddressTable)
• 插入到表的實體 （插入電子郵件地址­到 EmailAddressTable 的實體）
• 查詢表來搜索特定的實體 （bterkaly@microsoft.com 搜索）

圖 2 實體 EmailAddressEntity

// Our entity derives from TableEntity public class EmailAddressEntity : TableEntity {   // Basic information that makes up our entity   public string EMailAddress { get; set; }   public string PhoneNumber { get; set; }   // A necessary default constructor   public EmailAddressEntity()   {   }   // A two-parameter constructor   public EmailAddressEntity(string email, string phone)   {     EMailAddress = email;     PhoneNumber = phone;     SetKeys(email, phone);   }   // A method that initializes the partition key and row key   public void SetKeys(string email, string phone)   {     int startIndex = email.IndexOf("@");     // Extract the mailname from the e-mail address     string mailname = email.Substring(0, startIndex);     // Extract the domain from the e-mail address     string domain = email.Substring(startIndex + 1);     // Perform the mandatory assignments to the partition key and row key     PartitionKey = domain;     RowKey = mailname;     PhoneNumber = phone;   } }

首先，我們定義實體結構本身，EmailAddressEntity，如中所示圖 2。實際的表 （一個實體容器） 將在以後定義，當我們向表中插入 EmailAddressEntity。一個實體可以被作為一個單獨的物件 ； 它是可以在 Windows Azure 表中存儲的資料的最小單位。如前文所述，實體是類型化的名稱-值對，通常稱為屬性的集合。表是實體的集合，每個實體屬於一個表，就像關係資料庫表中的行不會。但是，Windows Azure 表存儲中的表不具有固定的架構。沒有任何規定要求在一個表中的所有實體都是結構上完全相同，正如關係資料庫表的情況。

有四個主要部分中的資訊圖 2。首兩個電子郵件地址和電話號碼，只不過是兩種我們想要存儲的字串。其他兩個是 PartitionKey 和 RowKey，其中我們以前討論過的屬性。所需的所有實體的三個屬性是時間戳記，它由系統內部使用，以便開放式併發。

時間戳記列不同于 PartitionKey 和 RowKey 列因為它由 WAS 系統會自動填滿。相比之下，發展商所插入的 PartitionKey 和 RowKey 屬性。

總之，PartitionKey 和 RowKey 的重要性是大多是有關查詢性能和事務的一致性。我們以前解釋查詢性能，很大程度上依賴于資料的存儲節點跨分區的方式。但是，PartitionKeys 還允許您對多個實體進行更改，因為相同的操作，使開發人員能夠回滾更改的一部分應任何單個操作失敗。要求是實體是同一實體組，這實際上意味著實體共用相同的 PartitionKey 的一部分。在單個 PartitionKey 內支援事務。

中的代碼圖 3 闡釋了具現化類型 EmailAddressEntity 的一個實體 （從圖 2），然後將該實體插入到 EmailAddressTable。請注意我們正在使用本機存放區模擬器。這讓我們運行和測試我們的代碼和資料本地沒有連接到一個資料中心。

圖 3 插入 EmailAddressEntity

try {   // Use the local storage emulator   var storageAccount = CloudStorageAccount.DevelopmentStorageAccount;   // Create a cloud table client object   CloudTableClient tableClient = storageAccount.CreateCloudTableClient();   // Create an e-mail address table object   CloudTable emailAddressTable =     tableClient.GetTableReference("EmailAddressTable");   // Create the table if it does not exist   // Only insert a new record once for this demo   if (emailAddressTable.CreateIfNotExists() == true)   {     // Create a new EmailAddressEntity entity     EmailAddressEntity emailaddress = new       EmailAddressEntity("bterkaly@microsoft.com", "555-555-5555");     // Create an operation to add the new e-mail and phone number to     // the emailAddressTable     TableOperation insertEmail = TableOperation.Insert(emailaddress);     // Submit the operation to the table service     emailAddressTable.Execute(insertEmail);   } } catch (Exception ex) {   // Put the message in the Web page title (for testing purposes)   // Real error messages should go to a proper log file   this.Title = ex.Message.ToString();   throw; }

中所示，您可以在Visual Studio2012 年，在伺服器資源管理器窗格中查看您的資料圖 4，這使得編寫和測試代碼更加容易的過程。您還可以附加到在資料中心中的 Windows Azure 表的實際實例的伺服器資源管理器。

**
圖 4 伺服器資源管理器**

中的代碼圖 5 闡釋如何查詢資料。

圖 5 查詢 Windows Azure 表

// Use the local storage emulator var storageAccount = CloudStorageAccount.DevelopmentStorageAccount; try {   // Create the table client   CloudTableClient tableClient = storageAccount.CreateCloudTableClient();   CloudTable emailAddressTable =     tableClient.GetTableReference("EmailAddressTable");   // Retrieve the entity with partition key of "microsoft.com"    // and row key of "bterkaly"   TableOperation retrieveBrunoEmail =     TableOperation.Retrieve<EmailAddressEntity>(     "microsoft.com", "bterkaly");   // Retrieve entity   EmailAddressEntity specificEntity =     (EmailAddressEntity)emailAddressTable.Execute(retrieveBrunoEmail).Result;   TableResult result =     emailAddressTable.Execute(TableOperation.Retrieve<EmailAddressEntity>(     "microsoft.com", "bterkaly"));   // Pull the data out that you searched for   // Do something with emailAddress and phoneNumber   string emailAddress = specificEntity.EMailAddress;   string phoneNumber = specificEntity.PhoneNumber; } catch (Exception ex) {   // Put the message in the Web page title (for testing purposes)   // Real error messages should go to a proper log file   this.Title = ex.Message.ToString();   throw; }

該代碼將執行一個簡單的查詢，使用 PartitionKey 和 RowKey。請注意您可以構造相當複雜的查詢使用這些篩選器，因為您可以聯接在一起在特設的時尚。我們建立一個查詢物件，該物件使用組合的篩選器。最後一步就是執行查詢並做與 EmailAddressEntity 所需的任何。WAS 用戶端庫極大地簡化了創建讀取更新/刪除 (CRUD) 操作以及所需的查詢。

裡面是什麼

我們認為它可能有助於在 WAS 系統，所示的內部體系結構略有深入瞭解一下圖 6。很多的下列敘述基於引用本文中稍後介紹的Brad卡爾德紙。

**
圖 6 Windows Azure 存儲塔內件**

是由組成的系列存儲郵票跨其八個資料中心。存儲郵票是 10 至 20 架的存儲節點的群集。每個機架坐在一個單獨的故障域。每個機架帶有冗余網路和電源。每個存儲郵票包含大約 30PBs 的原始資料存儲。

要保持低成本，它是重要的是要保持高於 70%的利用率，衡量能力、 交易和頻寬運行這些存儲郵票。90%以上的持續被認為太高了，不過，因為這會使小淨空高度出現了機架故障時，系統需要做更多與少。

存儲位置服務

開發人員已不能直接控制對存儲位置服務 (SLS)。在帳戶一級，不僅不會補充勞工計畫將帳戶命名空間映射跨所有郵票，也是負責災害復原、 存儲的帳戶分配和負載平衡。補充勞工計畫極大地簡化了添加新存儲在資料中心中的能力。它可以為客戶分配新存儲帳戶的新的郵票，以及平衡現有存儲帳戶從舊郵票載入到的新的郵票。所有這些操作的補充勞工計畫是自動完成的。

讓我們看看存儲郵票組成的三層靠近了 — — 流、 分區和前結束 (FE) — — 從底部開始。

流層提供內部介面的區域圖層用來讀取和寫入大型檔，並負責核心複製功能。流層還處理打開、 關閉、 刪除、 重命名、 閱讀、 追加到和串聯這些較大的檔。它不是在流的資料的物件的語義。

分區層為不同類型的存儲的物件 （表、 blob，佇列） ； 提供資料模型 邏輯和語義，以處理不同類型的物件 ； 一個高度可伸縮的命名空間的物件 ； 負載平衡的訪問物件跨所有可用的分區伺服器 ； 事務排序和強一致性的訪問物件 ； 和土力工程處複製的資料物件從主到次區域。

分區層還封裝稱為物件表重要的內部資料結構。有幾個版本的物件表中，包括實體表，其中存儲的所有帳戶的所有實體行的郵票。它用來公開 Windows Azure 表資料抽象。物件表還與要確保資料的一致性的 blob、 故事和佇列進行訂購交易的區域圖層進行交互。

鐵層是由一組採取傳入請求的無狀態伺服器組成。一旦收到請求，FE 查找 enter 鍵、 進行身份驗證和授權請求，然後將請求路由到適當的分區伺服器區域圖層 （基於 PartitionName） 中。為了提高性能，FE 維護和緩存區域圖，以便路由到適當的分區伺服器加快對頻繁訪問的資料。

總結

在本文中，我們提供了一些高級別、 可操作的指導原則，以及一些建築細節上的 WAS 系統如何設計的和特別是如何 Windows Azure 表可以説明您管理您的資料。我們要感謝Brad卡爾德為一些在分享他個人的見解"Windows Azure 存儲空間：高度可用雲存儲服務有Strong的一致性，"23 ACM 專題討論會對作業系統的系統原則 （SOSP） 最近發表的檔。您可以下載他的論文在 bit.ly/tMIPus。

Windows Azure 存儲用戶端庫 2.0

早在 2012 年 10 月下旬，Microsoft 發佈了一個新的用戶端存儲庫 — — Windows Azure 存儲 (WAS) 用戶端庫 2.0 — — 這大大提高了可用性、 可擴充性和性能與 Windows Azure 表進行交互時。您可以安裝 WAS NuGet 從與用戶端庫 2.0 bit.ly/YFeHuw。這可以在Visual Studio2012 內。詳細看看一些強大的新功能，請訪問 bit.ly/VQSaUv。

新的庫包含一些新的辦法，以提高可用性、 可擴充性和性能的功能。一個不錯的功能保存您的工作與平原舊 C# 物件 (POCO) 時擔心序列化和反序列化邏輯的麻煩。另一個很酷的功能是 EntityResolver，它允許您為執行用戶端的預測，以便您可以基於您感興趣的資訊動態創建物件。簡而言之，你可以直接從轉換表實體資料沒有單獨的表中的實體類類型的反序列化的每個屬性單獨的用戶端物件類型。另一種功能強大的技術是 IQueryable 介面，這將使您的表達方式來定義複雜的LINQ查詢。

Bruno Terkaly 是微軟的開發人員宣傳員。他淵博的知識是來自在該領域使用眾多平台、語言、架構、SDK、程式庫和 API 撰寫程式碼的多年經驗。他花時間編寫代碼，博客，給現場演示上構建基於雲計算的應用程式，特別使用 Windows Azure 平臺。Terkaly 也是作者的兩個 Windows 存儲應用程式，教孩子汽車顏色和教孩子音樂。您可以閱讀他在博客上的 blogs.msdn.com/brunoterkaly。

Ricardo Villalobos 是經驗豐富的軟體架構設計師，在為供應鏈管理產業的公司設計和建立應用程式擁有 15 以上的經驗。他在從達拉斯大學工商管理持有不同的技術認證，以及碩士學位，微軟作為一個雲建築師在 Windows Azure CSV 孵化組工作。

Terkaly 和比利亞洛聯合目前在逃的行業會議。他們鼓勵讀者與他們聯繫的可用性。可以在達成 Terkaly bterkaly@microsoft.com 和比利亞洛沃斯可以達成 Ricardo.Villalobos@microsoft.com。

感謝以下技術專家對本文的審閱：Brad卡爾德 （Microsoft） 和潔 Haridas (微軟)