特定の個人のさまざまなデータを含む巨大な .txt ファイルの読み取りと処理を扱うプロジェクトに取り組んでいます。
同じ ID に割り当てられたすべてのファイルからすべてのエントリを取得するという観点から、複数のファイルが読み取られ、(すべてのファイルに存在する) 個々の ID によって並べ替えられ、マージされます。つまり、各個人は、すべてのファイルに複数のエントリ (行) を持つことができます。1 つの ID に関して見つけたすべての情報を取得して保存し、次の ID に渡す必要があります。
FileChannel今まで、 、FileInputStreamを試してきましMappedFileBufferたが、どうやら私のケースに最も適しているのはFileInputStreamと でBufferedReaderあり、それらを比較することをCollection.sort()お勧めします。重要な問題は、アプリケーションを利用しようとしている PC のパフォーマンスを認識しておらず、ファイルが 2GB を超える可能性があることです。どんな助けでも大歓迎です。
ターゲット環境がメモリに収まるよりも多くのデータを処理することが予想される場合は、何らかの形式のオンディスク ストリーミングを使用するか、ファイルを複数回再解析する必要があります。
どのオプションを追求するかの決定は、データの分布によって異なります。
ID あたりの行数が比較的少ない場合 (つまり、個別の ID が多数ある場合)、すべての ID の照合結果が必要であると仮定すると、再解析が最も遅くなります。
ID が比較的少ない (行数が多い) 場合は、再解析がより効率的になる可能性があります。
私の推測では、各 ID の再解析は一般的なケースでは非効率的であると思われます (ただし、個別の ID が 10 個未満であることがわかっている場合は、再解析ベースのソリューションを検討します)。
アイデアは、ファイルを一度だけ解析して、結果を一種のリストのマップに入れるということです...
Map<Id,List<Record>>
あなたが直面している問題は、そのようなマップを保持するのに十分なメモリがないことです...
そのため、各 ID のリストを保持するために、中間の一時ディスク ストアを作成する必要があります。
オン ディスク ストアには 2 つのオプションがあります。
独自のロール
データベースを使用する (例: derby または hsqldb または ...)
オプション1はより多くの作業ですが、ユースケースに合わせて最適化できます（つまり、追加のみで書き込み、最後にすべてのレコードを読み込んで並べ替えます）
オプション2は、解析中にデータをランダムに読み取りたい場合にデータベースがIDのインデックスを維持するため、パフォーマンスのリスクを冒して実装する方が簡単かつ迅速です（このユースケースでは行いません）...
選択しなければならない場合は、オプション 2 から始めて、パフォーマンスが最適ではない場合にオプション 1 を使用するというメンテナンスの頭痛の種を自分自身に導入するだけです。(時期尚早の最適化を避ける)
バッファリングされたリーダーを使用する必要があります（非常に大きな（64k）バッファを使用して、競合する読み取り/書き込み操作でディスクを破棄しないようにします（ディスクはパフォーマンスを低下させるものです）
ファイルが十分に大きい場合は、外部ソートを使用する必要があります。その場合、データベースが実際に最も実用的な代替手段になり始めます。JDK には外部ソート メソッドはありません。