3

高いパフォーマンスを確保するためにAzureTableStorageをパーティション分割する方法を読んでいます。私の提案した戦略が、データストアに効率的でスケーラブルな挿入と単純なクエリを提供する機能を提供するかどうかを知りたいです。

30秒ごとにデータの小さなパケット（〜50バイト）をAZTにアップロードする1000の異なるプロセスがあります。私のクエリは、事実上常にプロセスと時間で単純にクエリすることです。たとえば、特定の日付の午後7時から午後9時までのプロセスAのすべてのログを照会したいとします。

私が提案する戦略は、プロセスごとにテーブル（1000テーブル）を作成し、各パーティションに6時間のデータが含まれるように行をパーティション化することです（1日あたり4つの新しいパーティション、パーティションあたり720行）。パーティションキー「NOV82012-0」には、11月8日の深夜から午前6時まで720行が含まれます。「NOV82012-1」には午前6時から正午などが含まれます。

これにより、継続トークンについて心配する必要がないように、どのパーティションにも常に1000行未満になるようにする必要があります。各プロセスのデータには独自のテーブルがあるため、プロセスごとに簡単に「フィルタリング」することもできます。

これはこの場合の理想的な戦略ですか？私は何かが足りないのですか？

4

2 に答える 2

2

実際、.NET SDKを使用している場合は、継続トークンについて心配する必要はありません。クエリでAsTableServiceQuery（）を呼び出すと、継続トークンを自動的に処理するオブジェクトを取得できます。

あなたが言っていることに基づいて、いくつかの基準でフィルタリングしたい：

  • プロセス
  • 日にち
  • 時間

プロセスごとに1つのテーブルを作成する必要はあまりありません。Process+Dateという組み合わせのキーでパーティションを作成できます。例：

  • A_20121108
  • A_20121109
  • B_20121108

プロセス名と日付を組み合わせることで、物事を簡単にするために、単一のテーブルに固執することができます。行については、パーティションごとに1000を超えるアイテムがあっても問題ありません。同じパーティションに特定の日のすべての行があることの利点は、行キーに基づいてそのパーティションの範囲を簡単に選択できることです（これは半擬似コードであり、テストしていません。改善する必要があるかもしれません。行キー）。

from item in context.CreateQuery<XXX>("XXX") 
where item.PartitionKey == "A_20121108" && item.RowKey.CompareTo("20121108120000") >= 0 && item.RowKey.CompareTo("20121108193000") <= 0
select item;
于 2012-11-08T21:48:12.793 に答える
1

私は、すべてのプロセスに対して単一のテーブルを使用するというSandrinoの提案に同意します。

ATSがうまく機能しないことの1つは、削除のサポートです。これを念頭に置いて、テーブルレベルで時間範囲ごとに分割することをお勧めします。このようにして、その時間範囲のデータが不要になったときにテーブルを削除できます。

その場合、キーイング構造は次のようになります。

テーブル名=プレフィックス+YYYYMM（年と月）
プロセス例201211

PKey=プロセス+DDHHMM（日、時間、分）
例A081834、B122359など

RKey=秒またはサブ秒。
1秒未満で一意性を保証できない場合は、GUIDを追加することを検討してください

于 2012-11-09T02:17:21.650 に答える