2

2k のパーティションがあるとします。IE 2k 個別のパーティション キー。すべてのパーティションには 3 つの GUID 行キーがあります。

説明する：

パーティション 1 - Guid 1 (行キー) - Guid 2 (行キー) - Guid 3 (行キー)

パーティション 2 - Guid 4 (行キー) - Guid 5 (行キー) - Guid 6 (行キー)

....などなど

すべてのパーティションで正確な GUID のクエリを実行するとします。どのようなクエリ パフォーマンスが見られるでしょうか。直接検索またはテーブル スキャン?

詳細な背景情報。次のスキーマを使用する予定です。

UserEntity
パーティション キー - ユーザー ガイド
行キー - ユーザー名

OpenIdEntity
パーティション キー - ユーザー GUID (UserEntity と同じ)
行キー - OpenId

ここで、ユーザーがログインするときに、1) オープン ID を見つける必要があります (ここでは、パーティションに関係なく、1 つの異なる行キーを持つレコードを選択します) 2) ユーザー名を見つけます。(1 つの個別のパーティション キーを持つレコードを選択します。プロパティなどのテーブル スキャン。パーティション キーが既知であり、パーティションが小さいため、テーブル スキャンの影響は最小限に抑える必要があります)

私の懸念は、Azure Table Storage がテーブル全体をスキャンして 1 つの個別の行キーを見つける場合、ステップ 1 が遅くなることです。

前もって感謝します。

4

1 に答える 1

5

あなたの懸念は当然です。「RowKey X を持つすべてのエンティティ」という形式のクエリは、完全なテーブル スキャンになります。

使用しているパーティション キーのセットがわかっている場合は、n 個の並列クエリ (パーティションごとに 1 つ) を発行できます。たとえば、「PartitionKey 1 と RowKey X を持つすべてのエンティティ」、「PartitionKey 2 と RowKey X を持つすべてのエンティティ」などです。これらを並行して発行すると、 n 個の直接ルックアップを実行していることになり、通常、テーブル スキャンよりもはるかに高速になります。 .

于 2012-08-25T03:29:00.263 に答える