バックグラウンド - .NET 4.0、Azure SDK 1.7、Azure テーブル ストレージを使用します
問題 N 個のエントリを最も効率的に (= 最速の処理時間で) 読み取る方法 (N は多数のエンティティ (1000 から数百万) であり、各エンティティは一連の Azure テーブルから非常に小さい (<200 バイト) であり、事前に各エンティティの PartitionID と RowID、つまり [(P1,R1),(P2,R2),...,(PN,RN)] を知っています。
そのようなリクエストを「バッチ」処理する最も効率的な方法は何ですか。当然、その下では、IO ロックまたは同期化ロックのいずれかを介してスレッドロックを発生させることなく、フェッチを非同期/並列化する必要があります。理想的には、CPU が Azure テーブル ストレージへの呼び出しを行うサーバーのスループット >80% に達することを確認する必要があります。処理は、CPU バウンド対 IO またはメモリ バウンドである必要があります。
Azure Storageから読み取るための「最速の」処理時間を求めているので、パフォーマンスを向上させるための一般的なヒントをいくつか示します（一番上のものが最も重要です）。
Azureストレージが2012年7月以降に作成されていることを確認します。これはAzureストレージのGen2であり、SSDドライブ上のストレージが含まれています。
あなたの場合、テーブルストレージは、Azure StorageのGen2のパーティションのスケーラビリティターゲットを増やしました：http：//blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network- storage-and-2012-scalability-targets.aspx
.NETのデフォルト接続はこの番号を変更します（これは新しいSDKで対処される可能性がありますが、確かではありません）：http ://social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/d84ba34b-b0e0- 4961-a167-bbe7618beb83
Azure Storageを「ウォームアップ」することができます。トランザクションが多いほど、使用するコントローラー/ドライブキャッシュが多くなります。これは、この方法で常にストレージにアクセスするにはコストがかかる可能性があります
複数のAzureストレージアカウントを使用できます。これにより、負荷を非常に効率的に分散できます（シャーディング）：http ：//tk.azurewebsites.net/2012/08/26/hacking-azure-for-more-disk-performance/
テーブルストレージで設計/設計する方法はいくつかあります。パーティションキーと行キーがあります。ただし、テーブル自体もあります。これはNoSQLであることに注意してください。したがって、同じ構造で異なるデータを提供する100個のテーブルを作成できます。これは、それ自体でパフォーマンスを向上させる可能性があり、これらのテーブルをさまざまなAzureストレージアカウントに保存することもできます。RowKey-> PartitionKey-> Table->複数のストレージアカウントはすべて、より高速なアクセスのための「インデックス」と考えることができます
私はあなたのデータを知りませんが、PartitionKeyで検索するので（私は推測します）、PartitionKeyごとに1,000,0000の非常に小さなレコードを保存する代わりに、zipファイルにそれを入れて実際にすばやく解凍してから並列クエリを実行しますローカルサーバーにある場合のlinq。小さなオブジェクトがたくさんあるので、キャッシュで遊ぶことは常に役に立ちます。おそらく、パーティション全体をメモリに入れることができます。別のオプションは、バイナリ/コンマで区切られた列データなどを含むパーティションキーを格納することです。
Azure 1.7 SDKを使用しているとのことですが、問題が発生し、StorageClient2.0ライブラリを使用していました。StorageClient2.0ライブラリで1.8SDKを使用しました。過去2年以上にわたってライブラリの効率が向上した可能性があるため、注目すべき点（必ずしもパフォーマンスではありません）