the documentationには、Azureテーブルストレージパーティションの最小操作速度が500操作/秒であることが記載されています。Azureテーブルストレージパーティション個別のパフォーマンス
自分のデータが正しくパーティション化されている場合、これらの各パーティションの並列操作は互いに影響しませんか？
たとえば、パーティションAで高価なフルテーブルスキャン（500エンティティ/秒で最大）を実行する必要がある場合、パーティションBで発生した操作のパフォーマンスに影響しますか？
ストレージアカウントの上限は5000回/秒です。これは本質的に、他のパフォーマンスに影響を与える前に10個のパーティションを最大限に活用できることを意味しますか？
可能な限り、常にテーブルスキャンを回避する必要があります。彼らは非常に高価な操作です（特にパーティションがたくさんある場合）。テーブルストレスの観点からあまりそうではありませんが、非常に高い総レイテンシを持っています（後述）。それは、単にそれを避けることができないことが時々あります。
私たちはストレージアーキテクチャを更新し、ターゲット制限の束を増やしました。
各ストレージアカウントは現在、20K IOPS /秒です。 各パーティションは2k/secになりました
パーティションのやりとりは少し微妙で、使用方法（および時間の経過とともに）によって異なります。
Azureストレージには2つのステージがあります.1つのサーバーセットが範囲を処理し、もう1つが実際のストレージ（つまり3つのコピー）を設定します。テーブルが冷たい場合、すべてのパーティションは1台のサーバーによってサービスされる可能性があります。パーティションに持続的なストレスが加わると、システムはワークロード（すなわちシャード）を追加のサーバーに自動的に広げ始めます。破片はパーティションの境界に作られています。
ストレスが低い/中程度の場合は、スレッシュホールドに達しないか、最小限の回数しかヒットしないことがあります。また、アクセスパターンには何らかの影響があります（追加する場合はシャーディングは役に立ちません）。すべてのパターンをランダムにアクセスできるようになります。システムのリバランシングが始まると、数秒間503応答が得られ、その後正常に戻ります。
テーブルスキャンを実行する場合は、実際にテーブルに複数回ラウンドトリップします。クエリがパーティションの最後に到達すると、見つかったデータ（条件が満たされていない場合はデータがない）と継続トークンが返されます。クエリは、テーブルの一番下に達するまで、再度送信されます（トークンで戻されます）。これはSDKによって抽象化されていますが、直接REST呼び出しを行った場合はそれが表示されます。
テーブルのパフォーマンスの観点からは、スキャンは現在スキャン中のパーティションにのみ影響します。
複数のパーティションにヒットする広範なクエリを高速化するには、実際には複数の並列アクセス（パーティションごとに1つのスレッド）まで分割してから、クライアントで結合してください。本当にそれはあなたが戻っているデータの量、テーブルの大きさなどによって異なります。
あなたの所見は正しいです、各パーティションのパフォーマンスは独立しています。しかし、テーブルストレージのパフォーマンスもVMの帯域幅の影響を受けます（ほとんど？）。 Azure pricingを見ると、「I/Oパフォーマンス」の列があり、さらに小さなマシンと小さなマシンには「低」と「中程度」のI/Oがあります。したがって、マシンが10MB/sのデータしか取得できない場合、テーブルストレージのパフォーマンスはほとんど無関係です。つまり、仮想化されたストレージ（OSの一部として）もこの帯域幅を使います。
ストレージアカウントの上限が5000 /秒であることは、そのレベルに達すると一部の操作でタイムアウトが発生する可能性があることを意味します。あたかも正しかったかのように、任意の数のストレージアカウントを設計して、そのパフォーマンス上限を回避するのは簡単です。
テーブルストレージを負荷のかかる状態に置いている可能性がある場合は、問題がどこにあるかを見つけるのに十分な診断でコードを作成し、再試行を可能にするために一時的なフォルト処理を実行するようにしてください。