Azure Table Storage分區設計

Question

我有一些軟件可以在很長一段時間內收集大約200個讀數/秒的數據。它爲此使用了一個SQL數據庫。我期待使用Azure將大量舊的「歸檔」數據移至。

該軟件使用多租戶類型體系結構，因此我計劃爲每個租戶使用一個Azure表。每個租戶可能正在監控10-20個不同的度量標準，因此我打算將度量標識（int）用作分區密鑰。由於每個指標每分鐘只有一個讀數（最大值），因此我計劃使用DateTime.Ticks.ToString（「d19」）作爲我的RowKey。

我對這將如何縮放比較缺乏一點理解;所以希望有人能夠清除它：

對於性能Azure可能會/可能會通過partitionkey拆分我的表以保持事情的快捷。在這種情況下，這將導致每個指標一個分區。

但是，我的rowkey可能會代表大約5年的數據，所以我估計大約有250萬行。

Azure是否足夠聰明，然後基於rowkey進行拆分，或者我正在設計未來的瓶頸？我通常不會過早地優化，但是像Azure這樣的東西似乎不像平常那​​樣明智！

尋找一位Azure專家，讓我知道我是否在正確的路線上，或者我是否應該將數據劃分到更多的表中。

Answer 1

幾點意見：

除了存儲數據，你可能也想看看你會怎麼要檢索的數據可能會大大改變你的設計。您可能想問自己的一些問題：

• 當我檢索數據時，我是否總是檢索特定指標和日期/時間範圍的數據？
• 或者我需要檢索特定日期/時間範圍內所有指標的數據？如果是這種情況，那麼你正在看全表掃描。顯然你可以通過做多個查詢（一個查詢/ PartitionKey）來避免這種情況。
• 我需要先看到最新的結果，或者我並不在乎。如果它是以前的，那麼你的RowKey策略應該是類似(DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks).ToString("d19")。

此外，由於PartitionKey是一個字符串值，您可能想int值轉換爲string值與一些「0」 prepadding使你的所有的ID出現在順序，否則你會得到1，10，11， ...，19，2，...等。

據我所知，Windows Azure只根據PartitionKey而不是RowKey對數據進行分區。在分區內，RowKey充當唯一鍵。 Windows Azure會嘗試在同一個節點上保留同一個PartitionKey的數據，但由於每個節點都是物理設備（因此具有大小限制），因此數據也可能會流向另一個節點。

您可能想要從Windows Azure存儲團隊閱讀此博客文章：http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx。

UPDATE 根據您的意見以及上面的一些信息，讓我們嘗試做一些數學。這是基於這裏公佈的最新可擴展性目標：http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx。該文件指出：

單桌隔斷表分區都在一個 表中的實體具有相同分區鍵值，並且通常表有很多 分區。單個表分區的吞吐量目標是：每秒

注

• 最高2,000實體，這是單個分區，而不是一個單一的表。因此，具有良好分區的表格可以處理高達20000個實體/秒，這是上面描述的總體賬戶目標 。

現在你提到你已經10 - 20個不同的度量點，併爲每個度量點，你會是每分鐘最多1分的記錄，這意味着你會寫一個最多20個實體的寫/分鐘/表格，遠低於2000個實體/秒的可擴展性目標。

現在問題仍然是閱讀。假設用戶每個分區讀取最多24小時的數據（即24 * 60 = 1440分）。現在假設用戶獲取所有20個指標的數據1天，那麼每個用戶（因此每個表）將獲取最多28,800個數據點。我想你所留下的問題是，每秒鐘可以獲得多少次這樣的請求才能達到該閾值。如果您能以某種方式推斷這些信息，我認爲您可以對您的架構的可擴展性達成一些結論。

我也推薦看這個視頻：http://channel9.msdn.com/Events/Build/2012/4-004。

希望這會有所幫助。