Azure表存儲並行查詢

如果我沒有指定分區鍵並因此執行所有分區的掃描，那麼掃描是否與每個同時掃描的分區並行自動進行？Azure表存儲並行查詢

謝謝。

來源

2013-02-26 Luke Puplett

掃描從第一個分區開始按順序完成，因爲實體通過PartitionKey/RowKey組合存儲。

來源

2013-02-26 15:15:13

Gaurav Mantri是正確的。

如果你想強制它並行執行，你必須按照所有可能的PartitionKeys進行過濾，然後在代碼中並行執行這些查詢。這可能會或可能不會「更好」（更快/更容易/更便宜），因爲它取決於不同的事情。

最終，我不會爲典型情況提供此建議。你可能會更好地組織你的數據。

來源

2013-02-26 17:40:32 Jaxidian

感謝您的回覆。我看到它的方式，碎片的重點是能夠在許多較短的數據集上運行令人尷尬的並行查詢。不得不自己編寫代碼很不幸，結果是許多小的聯合SQL Azure實例變得更具吸引力。 – 2013-02-26 21:18:03

在進行並行搜索時，不需要查詢所有可能的分區鍵。您可以使用「小於」和「大於」的組合在同一個線程中搜索多個PartitionKey實例。 – 2013-03-05 01:25:34

@HerveRoggero是正確的，儘管您仍然希望確保在所有查詢中包含所有可能的PartitionKeys，即使一次打多個。 – Jaxidian 2013-04-01 20:43:25

正如Gaurav所說，它不是自動的。但這並不意味着它無法完成。

如果您可以對PartitionKey進行某些假設，則可以非常容易地並行執行Azure表。例如，如果您的PartitionKey是GUID，則可以通過在範圍中搜索數據來啓動10個線程。以下是您將在第一個線程上使用的範圍示例，檢索範圍[a，e [中的所有實體。請注意，您可以根據需要調整它，並根據需要運行20個線程。

（PartitionKey GE「a」和PartitionKey LT「E」）

相反，如果你使用一個非唯一值的GUID，讓我們說國家的名單，因爲你有你只會啓動多少線程國家。

您真正需要掃描整個Azure表的唯一情況是當所有實體的PartitionKey相同時，在這種情況下您可能面臨設計問題。

來源

2013-03-05 01:23:42

幾個月後，我想發佈一個答案來討論並行掃描全表掃描的性能影響。

我使用了128分區方案，使用具有出色分佈的密鑰生成算法，並給出Guid行密鑰種子值。

經驗測試表明，單線程查詢可以在某些情況下執行得更好，更好。我認爲，表格大小和Azure分配部件的方式似乎有所不同。

總之，它需要在產品生命週期中檢查一個區域，看看不同的策略是否會提高性能。

因此，我所做的是在自動化測試中放置一個預期的持續時間，以便任何降級都可以閃爍紅光再次檢查。

來源

2015-02-02 11:25:54

Azure表存儲並行查詢

回答

相關問題