1

パーティション キーを指定せずにすべてのパーティションのスキャンを実行した場合、スキャンは同時にスキャンされる各パーティションと並行して自動的に行われますか?

ありがとう。

4

4 に答える 4

5

エンティティはPartitionKey/RowKeyの組み合わせで保存されるため、スキャンは最初のパーティションから順番に実行されます。

于 2013-02-26T15:15:13.423 に答える
2

GauravMantriは正しいです。

強制的に並列実行する場合は、可能なすべてのPartitionKeyでフィルタリングしてから、コード内でそれらのクエリを並列に実行する必要があります。これは、かなりの数の異なるものに依存するため、「より良い」（より速い/より簡単/より安い）場合とそうでない場合があります。

結局のところ、私は典型的な状況についてこれをアドバイスしません。データを別の方法で整理することをお勧めします。

于 2013-02-26T17:40:32.953 に答える
1

Gaurav が言うように、それは自動ではありません。しかし、それはそれができないという意味ではありません。

PartitionKey について特定の仮定を立てることができれば、Azure テーブルに対して非常に簡単に並列実行できます。たとえば、PartitionKey が GUID の場合、範囲内のデータを検索することで、たとえば 10 個のスレッドを開始できます。最初のスレッドで使用する範囲の例を次に示します。範囲 [a, e[. 必要に応じてこれを調整し、必要に応じて 20 個のスレッドを実行できることに注意してください。

(PartitionKey ge 'a' および PartitionKey lt 'e')

GUID の代わりに一意でない値、たとえば国のリストを使用する場合は、国と同じ数のスレッドを開始するだけです。

Azure テーブル全体を実際にスキャンする必要がある唯一のケースは、PartitionKey がすべてのエンティティで同じ場合です。この場合、おそらく設計上の問題に直面しています。

于 2013-03-05T01:23:42.323 に答える
0

数か月後、テーブル全体のスキャンを並列化することによるパフォーマンスへの影響について議論するための回答を投稿したいと思います。

Guid 行キー シード値が与えられた場合、優れた分散を備えたキー生成アルゴリズムを使用する 128 パーティション スキームを使用しました。

経験的なテストでは、状況によっては、シングル スレッド クエリのパフォーマンスがはるかに優れていることが示されました。テーブルのサイズと、Azure がパーツをどのように分散させたかによって、違いが生じるようです。

要するに、製品のライフタイム中にチェックして、別の戦略でパフォーマンスが向上するかどうかを確認する必要がある領域です。

そのため、テーブルに対する自動テストに予想される期間を設定して、劣化があれば赤信号を点滅させて再度チェックできるようにしました。

于 2015-02-02T11:25:54.473 に答える