2

トランザクションデータを保存するためにテーブルストレージを使用することを検討していますが、基本的に1日/月あたりの合計である非常に高レベルのレポートをサポートする必要があります。

私が持っているオプションのカップル：

  • パーティション/行キー構造を使用し、合計を動的に実行します
    （例：20101101_ITEMID_XXXXXXXX（x = guidまたはtime、一意にする））次に、行キーの一部（ITEMID_201011）を使用して月のデータをクエリし、「タイプの「コスト」プロパティ。

    しかし、1000レコードのクエリ制限はこれによってどのように管理されますか？（つまり、1日に1000を超えるトランザクションがある場合、合計は困難になります）

  • 別のレコードを使用してその日の合計を保存し、新しいレコードが追加されたらこれを更新し
    ます。たとえば、行キー「20101101_ITEMID_TOTAL」を使用して、日数の合計、月、または年の合計を照会します。

これを行うための最良の方法は何ですか？テーブルストレージを使用するこのタイプの要件の「ベストプラクティス」はありますか？

4

1 に答える 1

1

何がベスト プラクティスなのかはわかりませんが、AzureWatchにも同様の状況があり、テーブルで事前に集計された値を間違いなく使用しているとコメントできます。

主にパフォーマンス上の理由からです。単一のパーティション キーと行キーの範囲でクエリを実行しても、テーブル ストレージは瞬時ではありません。レコードのダウンロードにかかる時間はかなり長く、データをオブジェクトにデシリアライズする必要があるため、レコードによっては CPU が急増する可能性があります。1000 レコードの制限のためにテーブル ストレージに複数回移動する場合は、さらに多くの料金を支払うことになります。

考慮すべきその他の考え:

集計された合計が変更されることはありますか? 「いいえ」の場合、これは事前集計へのもう 1 つのナッジです

生データがなくなった後も集計値を保持する必要がありますか、それとも生データを消去する必要がありますか? はいの場合、それは事前集計への別のナッジです

于 2010-11-25T16:29:01.937 に答える