2

Azure ストレージを介して次のシナリオを処理するための最適なアプローチを決定できませんでした。

  • ~1MB から ~500MB までの ~1500 以上の CSV ファイル全体で ~20GB のデータ
  • 各ファイルはまったく同じモデルを使用し、各model.toString()は ~50 文字 ~400byte です
  • 毎営業日、6 時間の間に、1 分あたり ~8000 以上の新しい行が生成されます
  • プロパティ値に基づいて、各行は正しいファイルに移動します
  • スナップショット期間に数秒の遅延があっても、複数の読み取りがサポートされている限り、複数のインスタンスの書き込みは必要ありません。

Block Blobを使用したいのですが、〜 400MB の単一ファイルをコンピューターにダウンロードし、1 行追加してアップロードし直すだけでは意味がなく、他の方法を見つけることができませんでした。

Page Blobを使用するドライブ オプションがありますが、残念ながら SDKv2 ではサポートされていません。

そして最後の1つは、数十万行を継続して読み取る以外は問題ないように見えるテーブルです

基本的に、データをすぐに取得する場合はファイルを書き込むことを好みます。しかし、あきらめる価値がある場合は、1 日の終わりに 1 回の更新で済みます。つまり、1 ファイルあたり約 300 ~ 1000 行です。

このシナリオを処理するための最良のアプローチは何ですか?

4

1 に答える 1

3

上記の要件に基づくと、Azure テーブルが最適なオプションです。単一の Azure ストレージ アカウントを使用すると、次のものが得られます。

ストレージ トランザクション– 1 秒あたり最大 20,000 のエンティティ/メッセージ/ブロブ

単一テーブル パーティション– テーブル パーティションは、同じパーティション キー値を持つテーブル内のすべてのエンティティであり、ほとんどのテーブルには多くのパーティションがあります。単一パーティションのスループット目標は次のとおりです。

  • 毎秒最大 20,000 エンティティ
  • これは単一のテーブルではなく、単一のパーティション用であることに注意してください。したがって、適切なパーティション分割を備えたテーブルは、1 秒あたり最大数千の要求を処理できます (ストレージ アカウントのターゲット 20,000 まで)。

テーブル– テーブルのパーティションをより多くのサーバーに自動的に分散できるようにするために、テーブルにはよりきめ細かい PartitionKey を使用します。

「数十万行」を連続して読み取る場合、主な障害はストレージ レベル 20,000 トランザクション/秒ですが、パーティションを非常に細かく設計して数百のサーバーでセグメント化すると、数分で「数十万」を読み取ることができる可能性があります。

ソース:

  1. Windows Azure ストレージの抽象化とそのスケーラビリティ ターゲット
  2. Windows Azure のフラット ネットワーク ストレージと 2012 年のスケーラビリティ ターゲット
于 2013-03-11T16:46:43.760 に答える