0

1 日あたり 50 万件のレコードがあり、各レコードは最大 500 バイトで構成されており、1 年間のレコードを分析する必要があります。プロセスを高速化するには、すべてのレコードを一度にロードする方がよいでしょうが、最大 88 GB のメモリが必要になるため、それはできません。レコード数は将来的に超える可能性があります。

別のアプローチは、これらのレコードをグループとして分析し、25000 のグループがあり、それを超える可能性があるため、これらのレコードをグループごとにロードすることでした。

一度に 1 つのグループをロードし、グループを分析し、破棄して別のグループをロードすることができます....しかし、これは非常に遅いプロセスになり、データベース サーバーに 25000 回アクセスします!!!. メモリでデータを使用できるシングル スレッド プロセスは、データベースへのトリップを伴うマルチスレッド プロセス (スレッド数 32) よりもはるかに高速です。

この膨大なデータの読み込みを処理し、ノーを最小限に抑えることができるアプローチはありますか? データベースへの旅行の数または使用可能なメモリを超えるサイズのコレクションをロードするか、データのオンデマンドロードをラップできるライブラリ(部分コレクション)?

4

4 に答える 4

1

分散型アプローチ (つまり、分析を並行して実行する別々のマシンを使用し、中央コントローラーによって調整される) をとることとは別に、私が考えることができる唯一のことは、データベースのデータを直接、データベースのファイルシステム上のファイルにストリーミングすることです。解析を実行するマシン (これは、解析実行の前段階として行うことができます)。

ストレージ ハードウェアが高速な場合 (SSD など)、データベース呼び出しを分析プログラム内のファイル読み取りに置き換えると、パフォーマンスが向上する場合があります。

于 2013-01-08T06:47:05.697 に答える
1

1回のリクエストでそれらを取得し、それらに沿って実行し、進むにつれてそれらを破棄することを考えたことはありませんか? LHadoop クラスターをクッキングしますか?

分析に必要なものがわからない場合、推奨事項を作成しても無駄です。

于 2013-01-08T06:42:26.750 に答える
-2

互いに独立している 25000 個のグループがある場合は、負荷に応じて他の「ワーカー」スレッドを生成し、それらにデータを提供するコントローラー スレッドがあるマルチスレッド アプローチが適しています。

コントローラ スレッドは、最適に処理できるデータ量 (1 回の反復で処理される複数のグループは、使用可能なメモリの量によって制限されます) を取得し、spwan するスレッドの数を決定します。これは、それぞれが異なるワーカー スレッドのセットを持つ複数のアプリ サーバーを追加することで、よりスケーラブルにすることもできます。

于 2013-01-08T06:46:48.183 に答える