リアルタイムデータ処理アーキテクチャ

Question

私は次のようなアーキテクチャを構築することを検討しており、他の人が考えることを見たいと思っていました。

システムでは、各ユーザーで収集されたデータに対して、単純ではないアルゴリズムが実行されていると仮定しています（単純に何かを合計したものではありません）。一部のユーザーは10行のデータを持ち、一部のユーザーは数万のデータを持ちます。データは、時間の経過と共にユーザージオポジションになります。 10〜100万人以上のユーザーがおり、多くのユーザーのデータが毎日入ってくることがあります。

定期的な間隔（1/5/15分、基本的にはできるだけ早く）で、各ユーザーのデータにその非自明なアルゴリズムを実行すると、報告される数の数が吐き出されますでる。

モデルを作成する1つの方法は、NoSQL dbに格納し、各ユーザーのデータをAkkaクラスターで処理することです。 DBの推奨事項はありますか？

基本的に追加されたデータは変更されませんが、データは変更されませんが、常に成長し続け、一部のユーザーのデータは他のデータよりも不均衡です。ユーザーあたりのデータを処理するには、そのすべてをどこかのメモリにロードする必要があります。そのため、すべてのデータが1分間隔でメモリに格納され、再処理されるシナリオが最善のシナリオです。 RAMを使用してメモリ内のサーバがダウンすると、すべてのデータを再ロードする必要があり、それには時間がかかります。

Answer 1

私は現在、同様の問題に取り組んでいます。私のシステムは約35,000,000の "レコード"を持ち、各レコードはそれに約4-5の値を持っています。私は現在、1つのミッドレンジデスクトップ（スピンプラッターを備えた6コアAMD）で約20時間でそれらを処理することができます（軽微な処理ではありません）。

保存のために、Postgresからほぼすべてを試し、Cassandra、Hypertableに移しました。それから、私のユースケースでは、書き込みまたは読み取りのいずれかでランダムアクセスを必要とせずに、データを順番に再生することしか含まれていないことに気付きました。私はChronicleを見つけました。これはまさに私が探していたものです。私はすべてのデータを保存するのに十分なRAMがなかったので、ディスクからすべてを読み取る必要がありました。クロニクルでは、毎秒約800,000レコードまで記録しました。

現在のバージョンのクロニクルはわかりませんが、私が使用したバージョンでは「インデックス」ファイルが作成されましたが、これは余分なものでした。それ以来、私は自分のコードを使用しています。これは基本的にインデックスファイルなしのクロニクル（メモリマップファイル）で、平均30 MB /秒のスピンディスクで1.300.000レコード/秒になります。

もう1つの重要な点は、データを圧縮することです。それは大きな違いになります。 ビットのデータを圧縮しました（3ビットに値を圧縮すると、実際には3ビットしか書き込まれず、8は書き込まれます）。私はバイト境界を使用して圧縮を使用して、30-40％悪化していることがわかりました。たとえば、1人のGPSデータが急速に変化しないことが予想されます。したがって、連続する各データポイントにはわずか2ビットしか必要ありません。

私はあなたのようなリアルタイム処理を必要としなかったので、私の主な目的は、1台（または少なくとも少数の）マシンでできるだけ多くの処理パフォーマンスでした。私はAkka、Hadoop（これはちょうどPITAですが、それはお勧めしません）を試しました。その周りにはApache Sparkがあります。私の問題は、これらのほとんどが大規模なクラスタで動作するように作られていて、単一のマシン上で（または少なくとも私が望むほど高速にすることができないほど）速くないことでした。

私は処理チェーンを自分で実装しました。これは、約500.000レコード/秒の処理がと I/Oで出てきたと言いました。私のデータは独立した断片に簡単に分割されるので、ノードを調整する必要はありません。

さらに多くのデータがあり、リアルタイム処理が必要な場合は、私が行ったよりもはるかにスケールアウトしなければならないかもしれません。個々のパフォーマンスが最も重要な部分ではないかもしれません。

とにかく、これが役立つことを願っています。