その中に〜8億のエントリ（文字列）を含むハッシュマップがあります。実際には、ハッシュマップに既にあるファイルにシリアル化されます。
現在、サイズが約 3,500 万の文字列の別の巨大なリストがあります。これらの 3500 万の文字列を 1 つずつ読み取り、それ自体が別の方法である特定の方法でフォーマットする必要があります (非常に軽い処理です)。
次に、リストの 1 つの文字列に対して行われた書式設定の結果が hashMap に既に存在するかどうかを確認する必要があります。
Javaでこれを行う最も効率的な方法は何ですか?
ブルーム フィルターを使用してみることができます。
要素がセットのメンバーであるかどうかをテストするために使用される、スペース効率の良い確率的データ構造。偽陽性の検索結果は可能ですが、偽陰性はそうではありません。つまり、クエリは「セット内 (間違っている可能性があります)」または「間違いなくセット内にありません」のいずれかを返します。
(ウィキペディアより引用)
Google Guava はJava での実装を提供します。
ハッシュ関数をインメモリにする必要がある場合は、ハッシュ関数の開発方法を改善することから始めます。これに役立つ優れたリソースは、dzoneの記事にあります。
それ以上のステップは、ソートされた構造を維持することで発生する可能性のあるレイテンシーを気にしない場合、Map インターフェースの別の実装を使用することです。
大規模なデータセットが、ディスクからデシリアライズしているハッシュ テーブルに既に存在し、それを変更できない場合は、明白なことを行ってハッシュ テーブルを直接チェックするよりもはるかに優れた方法を実行できるとは思えません。大きなハッシュ テーブルを別の形式に変換すると、すべてのルックアップをそのままテーブルで一度に 1 つずつ実行するよりもコストがかかる可能性があります。(約 3,500 万回の定数時間操作に対して、少なくとも 8 億 + 3,500 万回の定数時間操作は、おそらくそれほど優れているとは言えず、使用する新しい形式によってはさらに多くなる可能性があります。)
大規模なデータセットが格納されているテーブルが既にスレッド セーフであり、プログラムを実行しているコンピューターに複数のコアがある場合、コアごとに 1 つのルックアップ スレッドを実行することで高速化される可能性がありますが、それでも高速化されない可能性があります。調整のオーバーヘッドと、個々の操作がかなり安価であるためです。
大規模なデータセットの準備方法を変更する能力はありますか? たとえば、ハッシュセットとして書き出すのではなく、別のものとして書き出すことはできますか? デフォルトのハッシュ関数を変更できますか? また、ハッシュしている文字列のプロパティについて、より安価なハッシュ関数を構築するために使用できるものを知っていますか? 入力ファイル内で特定の順序になりますか? これらの種類のものを使用してルックアップを高速化できる可能性がありますが、単純な方法よりも大幅な高速化は、問題の特定の詳細についてより多くを知ることに依存する可能性があります。