小朱® 的技術隨手寫

 

在前一篇 Table Storage 中，筆者已說明了 Table storage 的組成以及其用法限制等等，接下來要說明的是 BLOB Storage。

 

BLOB Storage 和 Table Storage (甚至是 Queue Storage) 的作法非常相近，BLOB storage 也是使用一個結構化的資料來源來儲存每一個儲存在 BLOB Storage 中的資料，只是它比 Table Storage 更適合用來儲存大型的二進位物件，如果你對前一篇文章還有印象，Table Storage 的二進位 (binary) 資料類型最多只能儲存到 64KB 的資料，但 BLOB Storage 卻可以儲存到 2GB 大小的資料（這是 Development Storage 的限制，在雲端的 BLOB Storage 最高可以存到 200GB 的資料），因此適合應用來當做雲端上的檔案與資料管理的主要服務。BLOB Storage 基於性質，分成 Block BLOB 以及 Page BLOB 兩種，Block BLOB 是以區塊來讀寫的一種儲存方式，它的識別方式是以 Block ID 為主，一個 ID 最大的容量是 4MB，一個 Block BLOB 可以容納 50000 個 block (亦即 200GB)，比較適合一般的檔案；而 Page BLOB 則是以經常存取的隨機二進位檔案為主，它是使用 range 來定義，應用程式可以在 Page BLOB 中隨機將資料寫到 range 範圍內的任何位元中，Page BLOB 最高可以儲存到 1TB 的資料量。

 

每一個帳戶都有一個自己的 BLOB Storage，每個 Storage 中可以定義出不同數量的 Container，就像是資料夾一樣，資料夾中的檔案即是 Blob，以檔案為單位記錄，而儲存的單位視 BLOB 類型的不同再區分，像 Block BLOB 是以 Block 為單位儲存，階層圖如下所示：

 

 

每一個 Container 的名稱必須是 3-63 個字元，全部都要小寫字，並且可以允許的是英文字元，數字半型字元以及 “-“ 符號。若要使用 “-“ 符號時，則該符號的前後都要有至少一個字元或數字。Blob 的命名長度限制為 1-1024 字元，且最好不要用 “.” 作結束 (因為可能會拒絕存取)，並且要小心使用 “/”來劃分階層。

 

而實際的資料儲存，BLOB Storage 也是和 Table Storage 相似，使用一個內建的 Entity Data Model，對應到資料庫的三個表格：Blob，BlobContainer 與 BlobData，其中 BlobContainer 是作為記錄 BLOB Container 資料之用，而 Blob 是儲存每個檔案的索引之用，真正儲存檔案的地方是在 BlobData，每一個 BlobData 資料列中儲存最高 4MB 的檔案資料，並賦與一個 BlockID，由 BlockID 來維護檔案的二進位資料順序，並且也可以降低因為資料列儲存大小過大而造成的效能問題。例如下圖就是檔案實際儲存在 BlobData 表格中的內容：

 

 

其中 Spring.NET-1.2.0-net-2.0-api.zip 的大小是 34,506KB，因此被切割成 9 個 Block 儲存，未達到切割 Block 標準的，都只儲存為一個資料列。

 

外界對於 BLOB 的操作，可以分成 REST API 以及直接抓取 URL 兩種，REST API 留待日後再提，直接抓取的部份可以利用 URL 來設定：http://[BLOB-storage-root-url]/accountname/containername/[resourcepath] ，例如要抓取在 Development Storage 中的 WindowsAzureSDK Feb 2010.chm（如上圖的最後一列），則 URL 可以設為：http://127.0.0.1:10000/devstoreaccount1/myfile/WindowsAzureSDK Feb 2010.chm。另外，雖然 BLOB 的實體階層只有到 Container，但是若要再切分出階層時，可以在 Blob 的名稱上以 “/” 的方式來區分出虛擬階層，如此在 URL 上就會呈現出階層的感覺，例如若上傳的 BLOB 的名稱是如下圖：

 

 

那麼就可以用 http://127.0.0.1:10000/devstoreaccount1/myfile//filedownloads/Fiddler1Setup.exe 來抓取此檔案。

 

 

當然，BLOB 如果只能記錄檔案，那麼似乎也太少了，如果想要增加一些描述性的資料的話，若還要依賴 Table Storage，那兩邊的同步性似乎問題就不小，但還好的是，BLOB storage 允許每個檔案擁有自己的描述性資料，稱為 Metadata，只要在加入或更新 BLOB 資料時，都可以寫入 Metadata 資料，讓檔案的描述資訊更加完整。Metadata 是由鍵值對 (name-value pair) 來組成，BLOB Storage 要求 Metadata 的鍵值名稱必須要是符合 C# identifier 規範，否則會在 serialize 階段擲出例外而失敗。

 

最後要提的是，因為 BLOB 是一個檔案儲存的區域，而若是有些檔案很大時，可以考慮利用 Windows Azure 的 CDN (Content Delivery Network) 機制來提供檔案資源，CDN 可以在 Windows Azure 的網站上設定啟用，且在 CTP 期間內不收費。

 

參考資料：

Windows Azure SDK – Blob Service Concepts: http://msdn.microsoft.com/en-us/library/dd179376.aspx