2

テーブル ストレージに増分レポートを作成する必要があります。複数の異なるワーカー ロール インスタンス (それぞれ複数のインスタンスを持つ異なるロール) から同じレコードを更新できる必要があります。

私のレポートは主に、最初に保存した生データを解析した後にインクリメントする必要がある値で構成されています。

私が見つけた楽観的な解決策は、再試行メカニズムを使用することです。レコードを更新してみてください。結果コード 412 が返された場合 (最新の ETAG 値がない場合)、再試行してください。このソリューションは、ユーザーが増え、同時に更新する必要があるデータが増えるほど、効率が低下し、コストが高くなります (私の場合は正確です)。

頭に浮かぶ別の解決策は、特定のレコードを更新できる可能性のある 1 つの worker ロールのインスタンスを 1 つだけ持つことです。これは非常に問題があります。これは、Azure で達成したいスケールとは逆に、設計によってアーキテクチャにボトルネックを作成することを意味するためです。

このようなユースケースのベストプラクティスを念頭に置いている人がいる場合は、ぜひ聞いてください.

4

2 に答える 2

2

ほとんどのクラウド ストレージ (Table Storage はその 1 つです) は、単一のエンティティ/BLOB などに対するスケーラブルな書き込みを提供しません。この制限は、そもそもクラウド ストレージを作成するために行われたコア トレードオフに起因するため、この制限に対する応急処置はありません。

基本的に、ストレージ ユニット (エンティティ/ブロブなど) は 20 ミリ秒ごとに約 1 回更新できます。専任の労働者がいてもいなくても、この面では何も変わりません。

代わりに、別の角度からタスクに取り組む必要があります。カウンターの場合、最も一般的なアプローチは、シャード カウンターを使用することです(リンクは GAE 用ですが、Azure で同等の動作を実装できます)。

また、非同期アーキテクチャ ala CQRSの痛みを軽減する別の方法では、エンティティの更新待ち時間に課すパフォーマンスの制約が大幅に緩和されます。

于 2010-12-12T17:54:10.873 に答える
0

このアプローチには再構築が必要だと思います。スケーラビリティを確保し、競合の量を制限するために、一意のTable / PartitionKey / RowKeyを提供することにより、すべての書き込みが楽観的に機能することを確認する必要があります。

レポートをマージするためにこれらの値が必要な場合は、レポートの目的でレコードを事後集計/マージする別のプロセス/ワーカーを用意してください。キューまたはタイミングメカニズムを使用して、集約/マージを開始できます

于 2010-12-12T19:28:41.983 に答える