ドキュメントには、AzureTableStorageパーティションの最低速度が500操作/秒であると記載されています。
データが正しくパーティション化されている場合、これらの各パーティションでの並列操作は相互に影響を与えませんか？
たとえば、パーティションAで高額な全表スキャン（最大500エンティティ/秒）を実行する必要がある場合、パーティションBで発生する操作のパフォーマンスに影響がありますか？
ストレージアカウントには、5000操作/秒の制限があります。これは基本的に、お互いのパフォーマンスに影響を与え始める前に、10個のパーティションを最大化できることを意味しますか？
原則として、可能な限りテーブル スキャンを回避する必要があります。これらは非常にコストのかかる操作です (特に、多くのパーティションがある場合)。テーブル ストレスの観点からはそれほどではありませんが、集計レイテンシが非常に高くなります (以下で説明します)。とはいえ、それを避けることができない場合もあります。
ストレージ アーキテクチャを更新し、ターゲット制限を引き上げました。
各ストレージ アカウントは 20k IOPS/秒になりました。各パーティションは 2k/秒になりました
パーティションがどのように相互作用するかは少し微妙であり、それらがどのように使用されているか (および時間の経過とともに変化する) によって異なります。
Azure ストレージには 2 つの段階があります。1 組のサーバーが範囲を処理し、もう 1 組が実際のストレージ (つまり 3 つのコピー) を設定します。テーブルがコールドの場合、すべてのパーティションが 1 つのサーバーによって処理される場合があります。パーティションが持続的なストレス下に置かれると、システムはワークロード (すなわちシャード) を追加のサーバーに自動的に分散し始めます。シャードはパーティション境界で作成されます。
低/中のストレスの場合、シャードのしきい値に達することがないか、最小限の回数しかない可能性があります。また、アクセス パターンにもある程度の影響があります (追加のみの場合、シャーディングは役に立ちません)。すべてのパターンにわたるランダム アクセスは、はるかに優れた拡張性を発揮します。システムのリバランス中は、数秒間 503 応答が返された後、通常の動作に戻ります。
テーブル スキャンを実行すると、実際にはテーブルへのラウンド トリップが複数回行われます。クエリがパーティションの最後に到達すると、見つかったデータ (基準が満たされない場合はデータなし) と継続トークンを含む応答が返されます。その後、テーブルの一番下に到達するまで、クエリが何度も再送信されます (トークンが返されます)。これは SDK によって抽象化されますが、REST を直接呼び出した場合は表示されます。
テーブルのパフォーマンスの観点から、スキャンは現在スキャンしているパーティションにのみ影響します。
複数のパーティションにヒットする幅広いクエリを高速化するには、実際には複数の並列アクセス (たとえば、パーティションごとに 1 つのスレッド) に分割してから、クライアントで合体できます。実際には、返されるデータの量、テーブルの大きさなどによって異なります。
あなたの観察は正しいです。各パーティションのパフォーマンスは独立しています。しかし..テーブル ストレージのパフォーマンスは、(ほとんど?) VM の帯域幅の影響も受けます。Azure の価格を見ると、"I/O パフォーマンス" の列があり、極小および小型のマシンには "低" と "中" の I/O があります。そのため、マシンが 10MB/s でしかデータを取得できない場合、テーブル ストレージのパフォーマンスはほとんど意味がありません。また、(OS の一部として) 仮想化されたストレージもこの帯域幅を使い果たすことに留意してください。
5000/秒のストレージ アカウント制限は、そのレベルに達し始めると、一部の操作でタイムアウトが発生する可能性があることを意味します。ストレージ アカウントの数に関係なく設計を行ってください。事前に正しく設計すれば、そのパフォーマンスの上限を簡単に回避できます。
テーブルストレージに負荷がかかっている可能性があると思われる場合。問題がどこにあるかを見つけるのに十分な診断機能を備えたコーディングを行い、一時的な障害処理を行って再試行できるようにしてください。