1

たとえば、このアプリケーションは動物の移動と農場の価格を追跡します。現在の在庫数を取得するための最も簡単な解決策は、開始番号を取得し、現在の番号が取得されるまですべての移動を合計することです。しかし、これはメモリ集約的であり、動きの数が年々増加するにつれてますます遅くなります。

1 年を「凍結」するという贅沢はないので、変更を受け入れることはできません。システムは、いつでも動きの変更を処理でき、更新された数値をリアルタイムで表示できなければなりません。

これは単なる在庫数ではありません。このような多数の変数を追跡し、これらの変数に基づく集計計算を含む各期間 (日、週、月、年) のレポートを作成する必要があります。

計算およびレポート目的で複数年にわたるデータ ストリームを処理するための、最も一般的で、優先される、「最良の」、最速でエレガントな方法は何ですか? このシナリオでは、データベース設計とアーキテクチャはどのように関係しますか (つまり、データベース スキーマが適切に設計されている限り、ORM を使用しても問題ないでしょうか?)。ここでの重要な要件は、最適なパフォーマンスとリアルタイムの可用性です。

私は大規模なシステムを見てきました。そのため、ある種の作業は週、月、年の集計テーブルなどのタイム スライスに分割されます。この問題を解決するための共通の設計パターンがあれば特に興味があります。

4

3 に答える 3

1

SQL データベース (PostgreSQL) を使用します。RDBMSはこれらのもので非常に高速です:)

すべての履歴を ORM オブジェクトとして取得し、それを合計すると、アプリケーションは長期的には機能しない可能性があります。RDBMS 内でほとんどの統計処理を行う SQL クエリを使用する必要があります。もちろん、オブジェクトの表示と編集に ORM を使用することもできます。

ソリューションは、予想されるデータ量で非常に安全である必要があり、RDBMS は適切なインデックス作成とより多くのメモリでスケーリングできると思います。

膨大な量のランダム データを作成し、事前にスケーラビリティをテストすることもできます。

于 2011-08-19T00:50:47.990 に答える
1

それは通常、彼らが非常に得意とするものであるため、DBに集約します。

OLAP (対OLTP ) データベース設計 をご覧ください。

于 2011-08-23T00:54:58.893 に答える
1

一般的なアプローチはおそらく 1 つだけです。それは、作業を分割することです。

時間を分割して、負荷の低い期間中に定期的に集計を計算し、それらを別々のテーブルに保存できます。一部の集計関数では、精度を失うことなく、短期間の集計から長期間の集計を計算することもできます。

スペースで分割することもできます-分散データベースとmap-reduceエンジンの組み合わせを使用するソリューションがあります-たとえば、Apache Pigを見てください。このアプローチでは、多くの学習と非学習が必要になりますが、スケーラビリティが向上するはずです。

最初に知っておくべきことは、読み取りと書き込みの比率と、実行したいクエリの種類です。

于 2011-08-19T15:11:30.113 に答える