パーティション全体をクエリした後のAzureテーブルのストレージパフォーマンスの大幅な低下

Question

Azureテーブルストレージを時系列データベースとして使用します。データベースは、より多くの行（各パーティションごとに約20行/秒）で常に拡張されます。毎日、私はその日のデータ用に新しいパーティションを作成して、すべてのパーティションが同じサイズを持ち、決して大きくなりすぎないようにします。

これまではすべてが問題なく動作していましたが、特定のパーティションからデータを取得したいときは、1000の値に対して2.5秒以上かかることはなく、平均して1秒かかるでしょう。

私はパーティションのすべてのデータを照会しようとしましたが、実際には非常に遅くなりました。手順の途中では、各クエリは1000の値に対して30〜40秒かかるでしょう。

私は小さな範囲で再起動するために手順をキャンセルしました。しかし、すべてのクエリに時間がかかりすぎる。最初からすべてのクエリは15〜30秒必要です。データが効率の悪い方法で再配置されたことがあります。そのため、パフォーマンスが大幅に低下しています。もしそうなら、そのような並べ替えを処理する方法はありますか？

Answer 1

時系列データの課題の1つは、すべてのデータを1つのパーティションに書き込むことができ、テーブルストレージが拡張するための追加リソースを割り当てることができないことです。同様に、複数のパーティションにデータを分散すると、クエリを並列化してはるかに大きなスケールを得ることができますが、読取り操作では、すべてのデータを1つのパーティションに格納するという制約があります。

Storage Analyticsを有効にしていますか？私は、あなたが全然抑えられているのか、他の潜在的な問題が起こっているのかを知ることに興味があります。詳細については、Storage Monitoring, Diagnosing and Troubleshootingガイドをご覧ください。

必要な情報がまだ見つからない場合は、AzTableFeedback@microsoft.comまで電子メールでお問い合わせください。

Azure Storage Table Design Guideは、一般的なスケーラビリティガイダンスと、パターン/アンチパターン（よく見えるように追加だけのアンチパターンを参照）について説明します。

Answer 2

Jasonが指摘したリンクを参照することをお勧めします。あなたはあなたのパーティションキーをどのように生成するのかについてあまり詳しく述べなかったが、いくつかのアンチパターンに陥っているサウンドからそれを聞いた。 Append（またはPrepend）とあまりにも多くのエンティティを単一のパーティションに適用することでインクルードします。パーティションサイズを縮小し、パーティションキーにハッシュまたはランダムなプレフィックスを入れて、辞書順ではないようにすることをお勧めします。

Azureストレージはバックグラウンドで範囲パーティション化スキームに従います。したがって、取得したパーティションキーが一意であっても、シーケンシャルであれば同じ範囲に入り、単一のパーティションサーバーによって処理される可能性があります。あなたのストレージ要求の負荷分散とスケールアウトを行うために、紺色のストレージサービスの能力を全面的に阻害します。

もう1つの側面は、エンティティをどのように読んでいるのか、パーティションキーと行キーを使用したポイントクエリ、最悪の場合、PKとRKのない完全なテーブルスキャンですあなたの場合でもあなたのパーティションサイズのためにかなり悪い性能になるパーティションスキャン。