大きなファイル (ファイル サイズは 30 MB から 1 GB の範囲) に 10 スレッドでアクセスし、ファイル内の各行を処理して、10 スレッドで別のファイルに書き込みたいと考えています。1 つのスレッドのみを使用して IO にアクセスすると、他のスレッドがブロックされます。この処理には、ファイル システムから 1 行のコードを読み取るのとほぼ同じ時間がかかります。もう 1 つの制約があります。出力ファイルのデータは、入力ファイルのデータと同じ順序でなければなりません。
このシステムの設計について、あなたの考えを知りたいです。ファイルへの同時アクセスをサポートする既存の API はありますか?
また、同じファイルに書き込むと、デッドロックが発生する可能性があります。
時間の制約が気になる場合は、これを達成する方法を提案してください。
3 つのスレッドから始めます。
もちろん、出力ファイルが入力ファイルとは物理的に異なるディスク上にあることも確認します。
処理が I/Oよりも遅くなる傾向がある場合(キューのサイズを監視する)、データの読み取りと書き込みの方法が同期されている 2 つ以上の並列 "プロセッサ" で実験を開始できます。
クラスは文字列をディスパッチすべきではありません。元のシーケンスを維持したいので、行番号などのメタ情報Lineを含むクラスでそれらをラップする必要があります。
収集されたデータに対して実際の作業を行う処理クラスが必要です。あなたの場合、やるべきことはありません。クラスは情報を保存するだけで、いつかそれを拡張して追加の処理を行うことができます (たとえば、文字列を逆にする、他の文字列を追加するなど)。
次に、処理スレッドである種の多方向マージソートを行い、インスタンスへのすべての参照を順番に収集するマージクラスが必要です。 Line
合併クラスは、データをファイルに書き戻すこともできますが、コードをきれいに保つために...
もちろん、メインメモリが不足している場合、このアプローチには多くのメモリが必要です。メモリのオーバーヘッドを小さく保つために、その場で機能するストリームベースのアプローチが必要です。
UPDATEストリームベースのアプローチ
以下を除いて、すべて同じままです。
スレッドはReader、読み取ったデータをBalloon. このバルーンには、保持できる特定の数のLineインスタンスがあります (数が大きいほど、より多くのメイン メモリを消費します)。
処理スレッドLineはバルーンから s を取得し、リーダーはバルーンが空になるにつれて、より多くの行をバルーンに送り込みます。
マージ クラスは、上記のように処理スレッドから行を取得し、ライターはデータをファイルに書き戻します。
I/O スレッドで使用する必要があるかもしれません。これはFileChannel、大きなファイルの読み取りにより適しており、ファイルの処理中に消費するメモリが少ないためです (ただし、これは推測にすぎません)。
考えられる方法の 1 つは、入力ファイルを読み取り、読み取った行をブロッキング キューに入れる単一のスレッドを作成することです。複数のスレッドがこのキューからのデータを待機し、データを処理します。
別の可能な解決策は、ファイルをチャンクに分割し、各チャンクを個別のスレッドに割り当てることです。
ブロックを回避するには、非同期 IO を使用できます。パターン指向ソフトウェア アーキテクチャ ボリューム 2 のProactor パターンも参照してください。
スレッドの理想的な数は、ハードウェア アーキテクチャやその他のものによって制限されることに注意してください (スレッド プールを参照して、最適なスレッド数を計算することを検討してください)。「10」が良い数であると仮定して、先に進みます。=)
パフォーマンスを探している場合は、次のことができます。
持っているスレッドを使用してファイルを読み取り、ビジネス ルールに従ってそれぞれを処理します。出力ファイルに挿入される次の予期される行を示す 1 つの制御変数を保持します。
次の予想される行の処理が完了したら、それをバッファー (キュー) に追加します (出力ファイルに直接挿入する方法を見つけることができれば理想的ですが、ロックの問題が発生します)。それ以外の場合は、この「将来の」行をバイナリ検索ツリー内に格納し、ツリーを行位置で並べます。Binary-search-tree は、検索と挿入に "O(log n)" の時間計算量を提供します。これは、コンテキストに対して非常に高速です。次の「予期される」行の処理が完了するまで、ツリーを埋め続けます。
出力ファイルを開き、定期的にバッファを消費し、ファイルに行を書き込むスレッドをアクティブにします。
また、ファイルに挿入される BST の「マイナー」予想ノードを追跡します。これを使用して、検索を開始する前に将来の行が BST 内にあるかどうかを確認できます。
このアプローチでは、 - O(n) を使用してファイルを読み取ります (ただし、並列化されています) - O(1) を使用して順序付けられた行をキューに挿入します - O(Logn)*2 を使用してバイナリ検索ツリーを読み書きします - O( n) 新しいファイルを書き込む
さらに、ビジネス ルールと I/O 操作のコストがかかります。
それが役に立てば幸い。
春のバッチが思い浮かびます。
順序を維持するには、後処理ステップが必要です。つまり、順序付けされた読み取りインデックス/キーを処理コンテキストに格納します。処理ロジックは、処理された情報もコンテキストに格納する必要があります。処理が完了したら、リストを後処理してファイルに書き込むことができます。 .
ただし、OOM の問題には注意してください。
順序を維持する必要があるため、問題自体は、読み取りと書き込みは順次処理であるため、並行して実行できないということです。並行して実行できるのはレコードの処理だけですが、これもライターが 1 つだけではあまり解決しません。 .
設計案は次のとおりです。
頑張って、最高のデザインを手に入れてください。
乾杯 ！！
私は過去に同様の問題に直面しました。単一のファイルからデータを読み取って処理し、結果を他のファイルに書き込む必要がある場合。加工部分が重かったので。だから私は複数のスレッドを使用しようとしました。私の問題を解決するために私が従ったデザインは次のとおりです。