小朱® 的技術隨手寫

 

Windows Azure 內含有三個基本的服務，分別是 BLOB，Queue 以及 Table 三種，各負有不同的任務，BLOB 是指在雲端上儲存檔案或二進位資料；Queue 是儲存需要按順序排列的資料，並且會有一支程式會依據順序 (FIFO) 來處理這些資料；而 Table 則是儲存資料用，它的作用有點像是關聯性資料庫，但它只是獨立存在的一個個體，無法與其他表格有所關聯，若是要實作關聯式資料庫的應用，那麼 SQL Azure 會比 Table 更好用。

 

那麼 Table Storage 是在做什麼的呢？其實你可以將它視為是一個簡單的結構化資料儲存空間 (structural data storage)，雖然儲存它的媒介也是資料庫，然而不像關聯式資料庫那樣的嚴謹，它可以儲存一些需要結構化或是有制式結構的零散資料，像是影像檔案的 EXIF 資料，圖檔的簡要說明，或者是主要資料的延伸資料等等，等於是輔助應用程式做描述性資料 (metadata) 或是輕量資料 (lightweight data) 的一個空間，若應用程式沒有需要使用到 SQL Azure 關聯式資料庫的資料量以及功能 (例如 FK) 的話，用 Table Storage 綽綽有餘。

 

Table Storage 的資料庫組成是由一個 TableContainer 以及一個 TableRow 資料表所組成：

 

 

每一個資料表都是一個 Container，註冊在 TableContainer 資料表中，並且使用 AccountName 和 TableName 來識別，這可以讓不同的帳戶名稱可以有相同的資料表名稱，且不至於發生衝突。而表中的每一列則包含了更多的鍵值，除了 AccountName 和 TableName 外，又加入了 PartitionKey 以及 RowKey 兩種，其中 PartitionKey 是作為識別在不同的資料表中的同一筆資料，或者是作為 Grouping 的資料，例如下列的圖示：

 

 

 

PartitionKey 可以作為不同但具有相同屬性的資料列的識別，以資料庫設計來說，就是利用複合主鍵 (compoud key) 來實作資料群組識別的功能。RowKey 則是專屬該列的識別鍵，實際儲存到資料庫時，PartitionKey 會和 RowKey 一起作為一個資料列的識別子 (identifier)。在 Table Storage 中，資料列被稱為 Entity，每個 Entity 都必須有不同的 PartitionKey 以及 RowKey，簡單的說，在 Table Storage 的核心中，就已經包含了一個由 ADO.NET Entity Framework 所設計的 Entity Model，這點在開發 Table Storage 的應用程式時會有更深的感觸，因為 Table Storage 所開放出來的 REST API，其實就是由 ADO.NET Data Services (以後會更名為 WCF Data Services) 所構成的 API，在 Windows Azure SDK 上所顯露的 REST API，基本上就和 ADO.NET Data Services 幾乎一模一樣。

 

Table Storage 的資料儲存結構，其實與 ASP.NET 的 Profile 行為非常像，資料不是由欄位歸檔，而是由 XML 做組織。例如下列的程式碼：

 

 

實際儲存在 Table Storage 中的資料如下圖：

 

 

請注意 Data 欄位，那個欄位就是儲存這個 Entity 的所有屬性，屬性以名稱作為標籤名稱，其實值以標籤的 InnerText 所保存，這個技巧被廣泛用在很多的系統中，架構上也類似筆者曾發表的 Profile 架構設計。用 XML 來管理半結構化的資料，可以降低設計多個表格的負擔，但它的缺點就是會受限資料型別 (因為要儲存在 XML)，因此 Table Storage 的 Entity 欄位，只支援下列的資料類型：

 

同時，為了要讓 ADO.NET Data Services REST API 可以順利執行，Table Storage 的 Entity 名稱與屬性名稱有下列的限制：

 

1. 表格名稱必須是英文字母，不可以由數字開頭，不分大小寫，且長度最小 3 個字元，最長 63 個字元。
2. 欄位名稱必須要讓 XML 可以接受，且最長是 255 字元，最好是依據 C# 的識別項規範來命名。

 

而 PartitionKey 以及 RowKey 則有下列的限制：

 

1. 不可以包含 “\”，”/”，”#”，以及 “?” 四種字元。
2. 在每一次對 Entity 的新增，修改與刪除時，都必須要設定 PartitionKey 以及 RowKey。
3. PartitionKey 最長 1KB，RowKey 最長也是 1KB。

 

備註：
上面針對 Table Storage 的討論，其來源都是 SDK 以及在 Development Storage 資料庫中所得到的資訊，也許會和正式的 Windows Azure Table Storage 的實體架構有所出入。

 

參考資料：
Windows Azure SDK, Understanding Table Service Data Model: http://msdn.microsoft.com/en-us/library/dd179338.aspx
Microsoft PDC 2008, Windows Azure Tables: Programming Cloud Table Storage (PPT)