4

Windows Azure テーブル ストア クエリがどのようにスケーリングされるかを評価したいと考えています。この目的のために、テーブル内のデータ量を増やし、クエリの実行時間を測定できる簡単なテスト環境をまとめました。時間に基づいて、将来のクエリのパフォーマンスを評価するために使用できるコスト関数を定義したいと思います。

次のクエリを評価しました。

  1. PartitionKey と RowKey を使用したクエリ
  2. PartitionKey と属性を使用したクエリ
  3. PartitionKey と 2 つの RowKey を使用したクエリ
  4. PartitionKey と 2 つの属性を使用したクエリ

最後の 2 つのクエリでは、次の 2 つのパターンを確認しました。

  1. PartitionKey == "..." && (RowKey == "..." || RowKey == "...")
  2. (PartitionKey == "..." && RowKey == "...") || (PartitionKey == "..." && RowKey == "...")

転送の遅延を最小限に抑えるために、Azure インスタンスでテストを実行しました。測定値から、私はそれを見ることができます

  • クエリ 1 (当然のことながら、テーブルはこれらのフィールドに基づいてインデックスが作成されているため) は非常に高速です。テーブルに約 150000 のエントリがある場合、約 10 ～ 15 ミリ秒です。
  • クエリ 2 はパーティション スキャンを必要とするため、実行時間は格納されたデータに比例して増加します。
  • クエリ 3.1 はクエリ 2 とほぼ同じように実行されます。そのため、このクエリもフル パーティション スキャンで実行されますが、これは少し奇妙に思えます。
  • クエリ 4.1 は、クエリ 3.1 よりも 2 倍以上遅くなります。そのため、2 つのパーティション スキャンで評価されているようです。
  • 最後に、クエリ 3.2 と 4.2 は、クエリ 2 よりもほぼ正確に 4 倍遅くなります。

クエリ/フィルター インタープリターの内部について説明できますか? クエリ 3.1 にパーティション スキャンが必要であることを認めたとしても、クエリ 4.1 も同じロジックで (同時に) 評価できます。クエリ 3.2 と 4.2 は、私にとって謎のようです。それらに関する指針はありますか？

明らかに、これの要点は、パフォーマンスを失わずにコストを最小限に抑えるために、1 つのクエリ内で個別の要素をクエリしたいということです。しかし、要素ごとに (Task Parallel Library を使用して) 個別のクエリを使用することが唯一の高速なソリューションのようです。これを行うための受け入れられた方法は何ですか?

4

2 に答える 2

2

3.2や4.2のようなクエリでは、属性とともに1つずつフルパーティションスキャンが行われます。これらのパーティションが2つの別々のマシン上にある場合でも、クエリは並行して実行されません。そのため、実行に非常に長い時間がかかります。これは、WindowsAzureにはクエリによるクエリ最適化がないためです。それらが並行して実行できるように書くことはコードの責任です。

より高速なパフォーマンスが必要な場合は、タスク並列ライブラリを使用してクエリを並列に実行し、パフォーマンスを向上させる必要があります。

于 2012-05-30T06:27:59.847 に答える
1

テーブル ストレージの内部実装の詳細は非公開であるため、今後のクエリのパフォーマンスを評価する場合は、 http://blogs.msdn.com/b/windowsazurestorage/archive/2010/を確認することをお勧めします。ベスト プラクティスについては、11/06/how-to-get-most-out-of-windows-azure-tables.aspxを参照してください。

よろしくお願いします、

明徐。

于 2012-05-25T09:17:45.957 に答える