0

問題は次のとおりです。リアルタイムでいくつかのデータを収集します。たとえば、1 秒あたり 100 エントリとします。リアルタイムのレポートが必要です。レポートは時間単位でデータを表示する必要があります。やりたいことは、受信データの合計をいくつか作成し、スマートなインデックスを作成して、「2012-01-01 09:00 の場合、featureA = x、featureB = y の value2 を教えてください」などのクエリを簡単に処理できるようにすることだけです。 10:00"

I/O 操作が多すぎるのを避けるために、メモリ内のデータを集約し (つまり、それらを合計します)、データベースにフラッシュします。約 10 秒ごとに発生するとしましょう。これは、リアルタイム レポートの許容可能な待機時間です。

したがって、基本的に、SQL 用語では、次のような 20 (またはそれ以上) のテーブルになります (わかりました。合計を組み合わせることでテーブルを少し減らすことができますが、大きな違いはありません)。

  1. 時間、機能 A、機能 B、機能 C、値 1、値 2、値 3
  2. 時間、機能 A、機能 D、値 4、値 5
  3. 時間、FeatureC、FeatureE、value6、value7
  4. 等

(解決策が SQL でなければならないとは言いません。当面の問題を説明するためにこれを提示するだけです。) Time 列はタイムスタンプ (時間精度) で、Feature 列はシステム エンティティの ID であり、値は整数値です (数）。

だから今問題が発生します。データの性質上、データを集計したとしても、これらの集計テーブルへの挿入がまだ (多すぎます) 存在します。これは、一部のデータがまばらであるためです。つまり、100 エントリごとに、集計テーブルのいくつかに 50 エントリがあることを意味します。ハードウェアをアップグレードすることで前進できることは理解していますが、私が感じているのは、よりスマートな格納メカニズムを使用することで、よりうまくいく可能性があるということです。たとえば、SQL データベースを使用できますが、そのほとんどの機能 (トランザクション、結合など) は必要ありません。

したがって、このシナリオを考えると、私の質問は次のとおりです。大量のトラフィックのリアルタイム レポートにどのように対処していますか? Google は何らかの方法で Web 分析のためにこれを行っているため、結局のところ可能です。ここに秘密兵器？私たちは、Hadoop & Co、NoSQL、クラスタリングなど、あらゆるソリューションに対してオープンです。

4

1 に答える 1

2

収集とレポート/分析のためのストレージ要件を分割する以外に、私たちが行っていたことの 1 つは、値に重大な変更が発生した頻度と、データがどのように使用されるかを調べることでした。

データがどのように見えるかはわかりませんが、レポートと分析では通常、重要なパターンを探します。アウトへの耐性、およびその逆、特に振動への耐性。分析したい場合に備えて「無限」の量のデータを収集することは称賛に値するかもしれませんが、実装の有限の限界にぶつかった場合は、選択を行う必要があります。

私は製造環境でこのようなことをしました。2 つのレベルの分析がありました。粒度が可能な限り高い制御用の 1 つ。その後、データが過去にさらに進んだため、レポート用に要約しました。

私はあなたのように見える問題に数回以上遭遇しました.

したがって、私はこの問題を単に技術的な観点からではなく、実際的なビジネスの観点から見てみたいと思います。ビジネスが余裕があると信じている金額から始めて、そのためにどれだけ提供できるかを確認します。

于 2012-09-18T15:29:55.887 に答える