如何估算Windows Azure Table存儲查詢性能？

Question

我想評估我的Windows Azure Table存儲查詢的縮放比例。爲此，我已經組建了一個簡單的測試環境，可以增加表中的數據量，並測量查詢的執行時間。根據我想定義的成本函數，可以用來評估未來查詢的性能。

我已經評估了以下疑問：

1. 查詢與PartitionKey和RowKey
2. 查詢與PartitionKey和屬性
3. 查詢與PartitionKey和兩個RowKeys
4. 查詢與PartitionKey和兩個屬性

對於最後兩個查詢我檢查了以下兩種模式：

1. PartitionKey == 「......」 & &（RowKey == 「......」 || RowKey ==「...」）
2. （PartitionKey ==「...」& & RowKey ==「...」）|| （PartitionKey == 「......」 & & RowKey == 「...」）

爲了儘量減少傳輸延遲，我執行上Azure的實例的測試。從測量，我可以看到，

• 查詢1（這並不奇怪，因爲該表是基於這些字段建立索引）是非常快的，這是關於10-15ms，如果我有表中約15項。
• 查詢2需要分區掃描，所以執行時間隨存儲的數據線性增加。
• 查詢3.1與查詢2幾乎完全一樣。所以這個查詢也是用完整的分區掃描執行的，對我來說這似乎有點奇怪。
• 查詢4.1比查詢3.1慢兩倍以上。所以它似乎是用兩個分區掃描進行評估的。
• 最後，查詢3.2和4.2執行幾乎一模一樣4比2，查詢

較慢的時候，你能解釋一下查詢/過濾器解釋的內部？即使我們接受查詢3.1需要分區掃描，查詢4.1也可以使用相同的邏輯（並在同一時間）進行評估。查詢3.2和4.2對我來說似乎很神祕。那些指針？

很明顯，這一點是我想查詢一個查詢內的不同元素，以最大限度地降低成本，同時不會失去性能。但似乎對每個元素使用單獨的查詢（使用Task Parallel Library）是唯一真正的快速解決方案。接受的方式是什麼？

Answer 1

使用像3.2和4.2這樣的查詢，將會有一個個完整的分區掃描以及屬性。即使這些分區位於兩臺獨立的機器上，查詢也不會並行運行，這就是爲什麼您看到執行時間很長的原因。這是因爲Windows Azure沒有對查詢進行查詢優化。以一種方式編寫代碼是他們可以並行運行的責任。

如果您希望獲得更快的性能，那麼您需要使用任務並行庫並行運行查詢以獲得更高的性能。

Answer 2

由於表存儲內部實現的細節是非公開的，如果您想評估未來查詢的性能，我想建議您檢查http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx獲取一些最佳實踐。

最好的問候，

徐明。