了解 Windows Azure 存储计费 – 带宽、事务和容量
我們收到關于如何估算 Windows Azure存儲成本，以便了解如何更好地構建一個經濟有效的應用程序的問題。在本文中，我們將從帶寬、事務和容量這三種存儲成本的角度探討這一問題。
使用 Windows AzureBlob、表和隊列時，存在以下幾方面的存儲成本：
1.帶寬 –從托管存儲帳戶的位置傳入和傳出的數據量
2.事務 –對您的存儲帳戶所執行請求的數量
3.存儲容量 –持續存儲的數據量
請注意，隨著我們向存儲系統添加更多功能，本文內容也會不時予以更新。本文將作為指導原則，使服務能夠在應用程序運行于生產環境之前估算其存儲帶寬、事務和容量使用情況。
Azure存儲服務目前在中國地區提供了一定的免費數據傳輸和存儲事務的額度。
-
存儲事務：前100億個存儲事務是免費的。
具體定價信息請參考：http://www.windowsazure.cn/zh-cn/pricing/overview/
您可以在這里找到有關定價的詳細信息。
下面概述了這三個方面的計費情況：??????
1.???帶寬 –由于應用程序需要基于存儲數據進行計算，因此我們允許托管服務與存儲歸置在一起。這樣我們就能在歸置在一起的計算和存儲之間提供免費的帶寬，將僅對從數據中心外部訪問存儲所用的帶寬計費。
2.???事務 – Blob、表(Table)和隊列(Queue)向存儲服務提交的每一個 REST 請求均視為一個潛在的待計費事務。這樣，應用程序就可以通過控制向存儲服務發送請求的頻率和數量來對事務成本加以控制。我們會分析收到的每一個請求，然后根據我們處理請求的能力及請求的結果將其劃分為可計費或不可計費兩類。
3.???容量 –我們通過匯總所存儲對象（Blob、實體(Entity)和消息）及其應用程序和系統元數據的大小來測算待計費的存儲容量。
接下來，我們將解釋如何了解您的應用程序的這三個方面。
什么時候帶寬會被計費
要訪問 Blob、表和隊列，首先需要通過Windows Azure開發人員門戶創建一個存儲帳戶。在創建存儲帳戶時，您可以指定存儲您的存儲帳戶的位置。我們目前在中國提供的數據中心位置包括：
1.?中國北部 (北京)
2.?中國東部 (上海)
存儲帳戶中的所有數據都將通過所選位置進行存儲和訪問。一些應用程序會選擇在地理上最接近其客戶群的位置，以盡可能降低對這些客戶的延遲。這里一個關鍵方面是，您應該在開發人員門戶中為您的托管服務選取與存儲服務需要訪問的存儲帳戶相同的位置。原因就在于在同一位置內部傳輸數據所用的帶寬是免費的。相比之下，當從存儲帳戶指定位置傳入或傳出數據時，本文開始部分提及的帶寬費用將會累計。
這里需要重點指出的是，在同一位置訪問所用的帶寬是免費的，但相關事務不是。對存儲系統的每一次訪問都計為一個待計費事務。此外，僅對被視為可計費的事務所使用的帶寬收費，下文有對此類事務的具體定義。
帶寬方面涉及的另一個概念是在您通過 Windows Azure內容分發網絡 (CDN)使用 Blob時。如果在 CDN中未找到 Blob或者 Blob的生存期 (TTL)已過期，將從存儲帳戶（來源）中讀取并進行緩存。這種情況下，將針對緩存 Blob（從來源傳輸至 CDN）所消耗的帶寬對存儲帳戶收費（同時也構成一個事務）。所以要強調的是，應該對引用次數很多并足以獲得緩存命中的 Blob使用 CDN，這樣，在 Blob 因 TTL而在緩存中過期之前，將可以抵消掉把 Blob從存儲帳戶傳輸至 CDN產生的額外時間和成本。
下面舉出了幾個示例：
-
您的存儲帳戶和托管服務都位于“美國中北部”。由于位于同一位置，托管服務訪問存儲帳戶數據消耗的所有帶寬都是免費的。
-
您的存儲帳戶位于“美國中北部”，托管服務位于“美國中南部”。托管服務訪問存儲帳戶數據消耗的所有帶寬將產生本文開始時列出的帶寬費用。
-
您的存儲帳戶位于“美國中北部”，您的 Blob 由位于歐洲的其中一個 Windows Azure CDN邊緣位置進行緩存和提供服務。由于此 Windows AzureCDN邊緣位置與您的存儲帳戶不在同一位置，當在 Windows AzureCDN中讀取來自存儲帳戶的數據進行緩存時，將會產生上述帶寬費用。
- 您的存儲帳戶位于“美國中北部”，但可通過世界各地的網站和服務進行訪問。由于不是通過位于同一位置的 Windows Azure 托管服務進行訪問，因此將收取標準帶寬費用。
如何對事務計數
對于事務，我們首先要解釋的是，什么才算作一個 Windows Azure存儲事務。Windows Azure Blob、表和隊列的每一次 REST 調用都算作 1個事務（事務是否計費取決于具體計費分類，計費分類將在本文稍后討論）。REST調用詳細信息請參見：
-
Blob
-
表
-
隊列
上述每次 REST調用都算作 1個事務，包括以下類型的請求：
- 查詢/列表請求和繼續令牌(continuation tokens) – 表查詢以及列表 Blob容器、表和隊列可以返回繼續令牌。也就是說必須繼續進行查詢/列出操作直至任務完成。如前文提到過，對存儲服務的每一個 REST 請求都算作 1個事務。而每次查詢/列表繼續都是對存儲服務的另一個 REST 請求，因此可算作另一個事務。
-
批量操作 –我們目前支持兩種批量操作：
-
獲取消息 -從某個隊列中一次獲取多達 32條消息的能力。
-
實體組事務 – 通過 Azure表“插入”、“更新”或“刪除”的任何組合針對多達 100 個實體執行原子事務的能力。要求所有實體都在同一個表中，具有相同的 PartitionKey值，而且總請求大小必須低于 4MB。
-
這兩類批量操作都將產生對存儲服務的單個 REST請求。因此，它們的每次請求都算作一個事務。
在使用存儲客戶端庫時，有幾個函數調用可產生對存儲帳戶的多個 REST請求。
-
上傳 Blob – 在上傳 32 MB以上的 Blob時，存儲客戶端庫默認會將此 Blob分為多個 4 MB的塊。塊的大小可以通過設置CloudBlockBlob.StreamWriteSizeInBytes字段來更改。上傳時，客戶端庫會將塊作為單獨的PutBlock REST 請求上傳，并最終通過PutBlockList集中提交所有塊。每個 PutBlock將算作 1個事務，最終的 PutBlockList也將算作 1個事務。
-
表查詢 –當使用TableQuery進行查詢時，它將負責處理繼續令牌，因此會利用在前一個查詢請求中收到的繼續令牌重新發出查詢，以獲取其余實體。如上所述，對服務重新發出的每一個繼續令牌查詢都算作 1個事務。
- 表操作 –對于表服務而言，每次使用CloudTable.Execute，也就是向服務器發出一次請求，將被視為1個事務。特別指出的是，使用CloudTable.ExecuteBatch也視為1個事務，即便一次提交包含高達100個獨立操作。所以開發者可以多利用CloudTable.ExecuteBatch來節省表操作中的事務量。 [ZY1] ?
下面舉出了幾個示例：
-
向 Blob服務發出的單個 GetBlob請求 = 1個事務
-
向 Blob服務發出的單個 PutBlob請求 = 1個事務
-
大規模 Blob上傳帶來通過 PutBlock執行的 100個請求及最終 1個 PutBlockList集中提交 = 101個事務
-
使用總共 5個請求列出大量 Blob（由于有 4 個繼續令牌）= 5個事務
-
表單個實體的插入請求 = 1 個事務
-
針對 100個實體的獨立表操作= 100 個事務
-
針對 100個實體的組操作= 1 個事務
-
表查詢指定具體 PartitionKey和 RowKey匹配（得到一個單一實體）= 1個事務
-
表查詢通過單一存儲請求返回 500 個實體（未遇到繼續令牌）= 1個事務
-
表查詢產生對表存儲的 5 個請求（由于有 4個繼續令牌）= 5個事務
-
隊列放置消息 = 1個事務
-
隊列獲取單個消息 = 1個事務
-
隊列獲取空隊列消息 = 1個事務
-
隊列批量獲取 32個消息 = 1個事務
- 隊列刪除消息 = 1個事務
現在我們了解了什么是事務，接下來看看哪些事務計費，哪些事務不計費。
當某個事務到達我們的服務時，如果屬于以下分類范圍，那么我們不會將其計為可計費事務，而且不對這些事務收取帶寬費用：
-
預身份驗證失敗 –如果對于某個事務，我們甚至都沒有機會去進行身份驗證，那么此事務不會計入可計費事務。例如：具有錯誤 HTTP頭的錯誤格式的請求、錯誤格式的 URL、請求的時間范圍無效等。
-
身份驗證失敗 –如果某個事務的身份驗證失敗，我們不會將其計為存儲帳戶的可計費事務。
-
配額權限失敗 –我們為每個存儲帳戶設定了500TB 的配額。當存儲帳戶達到這一限額時，我們會將存儲帳戶轉入只有 READ+DELETE權限但沒有 WRITE權限的模式。此時存儲帳戶還可以執行獲取和刪除操作，但無法執行放置/發布操作。在這種模式下，要求有寫入權限的請求將會失敗，我們不會將這些請求列為可計費事務。
-
共享訪問簽名 (SAS) HTTP動詞/權限不正確 – 如果發送簽名得到正確驗證（身份驗證），但 REST操作關鍵字（PUT、POST、GET、DELETE）沒有正確匹配權限，那么此請求將不算作可計費事務。例如，如果權限指定只能執行 PUT 操作，但實際在有效 SAS上使用了動詞 GET，那么此請求將失敗，不會列為可計費事務。
-
匿名請求失敗 –沒有簽名的請求將被視為匿名請求，我們將以下三種失敗情況劃分類為不計入可計費事務的事務：
-
權限不正確 –匿名請求只能是 GET請求。如果不是 GET請求，將會被拒絕，并且不列入可計費事務。
-
找不到容器 –如果針對匿名 GET請求的容器不存在，那么此請求不會計為可計費事務。
-
找不到 Blob – 如果針對匿名 GET請求的嘗試訪問的 Blob不存在，那么此請求不會計為可計費事務。
-
意外超時 – 如果某個請求因存儲系統問題出現超時，則不會計為可計費事務。
-
滿足以上任何條件的事務都不會列為可計費事務，而且不會對相關請求消耗的帶寬收費。我們將其他事務列為可計費事務，這些事務是否會產生上述帶寬部分中所述的帶寬費用則因情況而異。
我們將可計費事務分為以下幾類：
-
成功的事務 –任何針對存儲系統成功完成的事務。
-
預期的失敗 –預期的失敗來自以下三個方面：
-
事務錯誤 –這些需求有正確的權限，經過了正確的身份驗證，但是因對存儲帳戶中的數據應用了事務語義而失敗。例如:
-
嘗試獲取或刪除一個早已被刪除或根本不存在的對象，導致 NotFound錯誤。
-
嘗試創建一個已經存在的對象，導致 AlreadyExists錯誤。例如，我們發現一些應用程序會在每次將消息放置于隊列之前，在此隊列中執行 CreateIfNotExist操作。這就導致針對他們想加入隊列的每個消息都會向存儲系統發出兩個不同的請求，導致創建隊列失敗。確保僅在最開始創建 Blob容器、表和隊列，避免上述額外的事務成本。
-
采用 ETag Match、Non-Match、Modified-Since或 Unmodified-Since命令執行有條件的操作，即使操作失敗（返回 NotModified或PreconditionFailed消息），也將算作一個事務。
-
嘗試添加一個已經存在的表實體，將導致失敗（沖突 - 409）。同樣，嘗試更新一個并不存在的實體也將會導致失敗（未找到 - 404）。這些操作都將帶來事務成本。這其實是想要執行 Upsert的應用程序所面臨的問題，目前我們正在就此評估如何支持 Windows Azure表。在提供 Upsert之前，用戶應該評估他們的使用方案，確定是先 INSERT后 UPDATE還是先 UPDATE后 INSERT，以便最小化預期失敗次數及發送到 Window Azure 表的總體事務數。
-
有效共享訪問簽名 (SAS)，但出現 ContainerNotFound 或 BlobNotFound的情況。如果 SAS簽名獲得正確驗證，但未找到容器或未找到要訪問的 Blob，此項操作也算作一個可計費事務。
-
這樣的例子還有很多，原因就在于根據存儲服務提供的語義（例如有條件的操作、租賃、序列號等），會有很多因素導致請求遭遇預期失敗。
-
-
限制 –存在因事務率超過每個分區目標吞吐量而被限制的請求。分區目標吞吐量在“Windows Azure 存儲服務概覽及其可伸縮性目標”一文中有過介紹。這些被限制的請求也算作可計費事務。在這種情況下，客戶端將使用指數退避算法，并重試請求，默認情況下存儲客戶端庫會提供此選項。如果是服務的重復出現事件，則此服務應該考慮對數據結構進行額外分區，如即將發布的“Blob、表和隊列”一文中所述。
-
預期超時 – 在您向服務發送請求時，您可以指定您自己的超時時間，可將其設置為小于SLA超時。如果此請求的超時時間小于 SLA 超時，在請求超時時，將被劃分為預期超時，并計入可計費事務。
-
如何估算容量
客戶要求了解有關 Blob、表和隊列存儲成本的更多詳細信息，以便在運行于生產環境之前估算他們的應用程序所使用的存儲容量大小。
首先需要了解存儲容量的每月計費累計方式。存儲容量每日至少計算和匯總一次，然后通過整個月的數據平均得出 GB/月費用。例如，如果在上半個月使用 10 GB，下半個月使用 0 GB，則月度計費基數將為 5 GB。
下面將介紹如何計算 Blob、表和隊列的存儲容量。
其中 Len(X)表示字符串中的字符數。
Blob容器 –下面說明了如何估算每個 Blob容器使用的存儲量：
48字節 + Len(容器名稱) * 2 字節 +
?每個元數據[3字節 + Len(元數據名稱) + Len(值)] +
每個簽名標識符[512字節]
以下是明細信息：
-
每個容器 48字節的開銷包括最后修改時間、權限、公共設置和一些系統元數據。
-
容器名稱以 Unicode形式存儲，因此字節數按字符數乘以 2計算。
-
對于每個存儲的 Blob容器元數據，我們會存儲名稱長度（以 ASCII碼存儲）加上字符串值的長度。
每個簽名標識符的 512字節包括簽名標識符名稱、開始時間、到期時間和權限。
Blob –下面說明了如何估算每個 Blob使用的存儲量：
對于 Block Blob（基本 Blob 或快照）：
124字節 + Len(Blob名稱) * 2字節 +
每個元數據[3字節 + Len(元數據名稱) + Len(值)] +
8字節 +已提交和未提交塊數 *塊 ID大小（字節） +
SizeInBytes(唯一的已提交數據塊存儲的數據) +
SizeInBytes(未提交數據塊中的數據)
對于 Page Blob（基本 BLob 或快照）：
124字節 + Len(Blob名稱) * 2字節 +
每個元數據[3字節 + Len(元數據名稱) + Len(值)] +
具有數據的不連續頁面范圍數 * 12字節 +
SizeInBytes(唯一的頁面存儲的數據)
以下是明細信息：
-
Blob 124字節的開銷包括最后修改時間、大小、緩存控制、內容類型、內容語言、內容編碼、內容-MD5、權限、快照信息、租賃和一些系統元數據。
-
Blob名稱以 Unicode形式存儲，因此字節數按字符數乘以 2計算。
-
對于每個存儲的元數據，我們會存儲名稱長度（以 ASCII碼存儲）加上字符串值的長度。
-
對于 Block Blob
-
對塊列表為 8字節
-
塊數乘以塊 ID大小（字節）
-
加上所有已提交和未提交塊中的數據大小。注意，如果使用了快照，則大小僅包括此基本或快照 Blob的唯一數據。如果一周之后未使用未提交的塊，這些塊將被回收，此時它們將不再計入之后的計費。
-
-
對于 Page Blob
-
字節數按具有數據的不連續頁面范圍數乘以 12計算。這是在調用 GetPageRanges API時所看到的唯一頁面范圍數。
-
- 加上所有存儲頁面中的數據大小（字節）。注意，如果使用了快照，則大小僅包括所清點基本或快照 Blob的唯一頁面。
表 –下面說明了如何估算每個表使用的存儲量：
12字節 + Len(表名) * 2 字節
以下是明細信息：
-
每個表的 12字節開銷包括最后修改時間和一些系統元數據。
- 表名以 Unicode形式存儲，因此字節數按字符數乘以 2計算。
實體 –下面說明了如何估算每個實體使用的存儲量：
4字節 + Len (PartitionKey + RowKey) * 2字節 +
每個屬性(8字節 + Len(屬性名稱) * 2 字節 + Sizeof(.Net屬性類型))
以下是明細信息：
-
每個實體的 4字節開銷包括時間戳和一些系統元數據。
-
PartitionKey和 RowKey值中的字符數，以 Unicode形式存儲（乘以 2計算字節數）。
-
因此，對于每個屬性，為 8字節開銷 +屬性名稱 * 2字節 +來自以下列表的屬性類型的大小。
不同類型的 Sizeof(.Net屬性類型)為：
-
字符串 –字符數 * 2字節 + 4字節的字符串長度
-
DateTime – 8字節
-
GUID – 16字節
-
Double – 8字節
-
Int – 4字節
-
INT64 – 8字節
-
Bool – 1字節
- 二進制 – sizeof(值)字節 + 4字節二進制數組長度
隊列 –下面說明了如何估算每個隊列使用的存儲量：
24字節 + Len(隊列名稱) * 2 +
每個元數據(4字節 + Len(隊列名稱) * 2 字節 + Len(值) * 2 字節)
以下是明細信息：
-
每個隊列的 24字節開銷包括最后修改時間和一些系統元數據。
- 對于所存儲的每個隊列元數據，名稱長度和值均以 Unicode存儲，因此字節數為乘以 2。
消息 –下面說明了如何估算每個消息使用的存儲量：
12字節 + Len(消息)
以下是明細信息：
-
12字節開銷包括 InvisibilityTime、Creation Time、Dequeue Count、Message ID 和一些系統元數據。
- 如果您使用 REST界面，還包括代表消息的字節數。如果使用存儲客戶端庫，則采用以下格式存儲消息：UTF8(Base64(消息))，而且所使用存儲將是其長度。
Brad Calder
如果您有任何疑問, 歡迎訪問MSDN社區，由專家來為您解答Windows Azure各種技術問題
本文翻譯自：
http://blogs.msdn.com/b/windowsazurestorage/archive/2010/07/09/understanding-windows-azure-storage-billing-bandwidth-transactions-and-capacity.aspx
總結
以上是生活随笔為你收集整理的了解 Windows Azure 存储计费 – 带宽、事务和容量的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： bat学习（七）给图片文件前边批量加上序
- 下一篇： java信息管理系统总结_java实现科