0

したがって、データ階層は非常に単純です。

Account >> SubAccount >> Category >> Product

各製品の毎日の統計 (これは単なる数値であり、毎日のパフォーマンスと呼びましょう) を取得する必要があります。数十のアカウント、数十のサブアカウント、数百のカテゴリ、および数百万の製品が存在する可能性があります。

これを可能にする API の形式は次のとおりです。

GetCurrentPerformance(Product)

現在、Web ベースのダッシュボードで、任意の製品、カテゴリ、サブアカウント、およびアカウントの時間対パフォーマンスを表示できる必要があります。また、GetCurrentPerformance(Product).

私はこのソリューションをクラウド、できれば AWS で構築しています。毎日取得したデータを最適に保存する方法を決定しようとしています。これが私が考えたものです：

  1. すべてをデータベース (RDBMS) に入れます。テーブルのサイズが手に負えないほど急速に大きくなることが懸念されます。
  2. 製品ごとにフラット ファイルを維持し、このファイルに 1 日のパフォーマンスを追加します。フェッチ中にカテゴリ、サブアカウント、およびアカウントの統計を計算し (平均)、カテゴリ、サブアカウント、およびアカウントごとにファイルを維持します。懸念: ファイルは S3 に保存する必要があり、S3 は追加をサポートしていません。全体的なファイルのプル、データの追加、ファイルのプッシュに非常に時間がかかります。
  3. (すべての製品にわたって) 毎日のデータに対して 1 つのファイルを維持します。次に、バッチ ジョブで、各製品、カテゴリ、サブアカウント、およびアカウントの統計を計算します。平均計算のためにすべてのファイルを参照する必要がないように、ファイル/データベースを維持します。懸念:特定の製品のタイムラインを表示するには、何百ものファイルを読み取る必要があります。
  4. No-SQL データベース? これについては経験がありません。

これは非常に単純な問題のように思えますが、最善の方法については混乱しています。提案をいただければ幸いです。

4

1 に答える 1

0

現在のパフォーマンスと以前のパフォーマンスのみを考慮し、過去のパフォーマンス統計を必要としない場合は、RDBMSで次のように正常に機能します。

create table product_performance (
  product_id integer primary key,
  current_perf number,
  previous_perf number
);

次に、以下を実行してパフォーマンスを設定できます。

update product_performance
set    current_perf = :new_perf,
       previous_perf = current_pref
where  product_id = :product;

履歴パフォーマンスを維持したい場合（時間の経過に伴う変化を追跡できるようにするため）、次のようなものが必要になります。

create table product_performance (
  product_id integer,
  performance_date date,
  performance number,
  is_current char(1), --optional, may improve the performance of finding current perf easier
  primary key (product_id, performance_date)
);

それぞれの新しいパフォーマンス値は、製品と日付の単なる挿入です。

どちらの方法を使用する場合でも、ダッシュボードの取得クエリが再実行されるのを待つよりも、新しいパフォーマンスを設定するときにアラートを発生させる方がよい場合があります。

于 2013-02-17T12:33:36.090 に答える