これは、何年も前に「Knight's Tour」の解決に取り組んでいたときに直面したいくつかの問題を思い出させます。(現在解決されている数学の問題ですが、私ではありません。)
あなたのハッシュでさえ、それほど役に立ちません。. . ほぼ GUID のサイズで、既知の宇宙全体で簡単に一意にすることができます。
リストをディスクに保持するだけでも、約 0.75 テラバイトかかります。. . 4ギガのメモリであろうとなかろうと、それらを保持するためだけに巨大なディスクが必要になります. また、以下で説明するソート/マージ ソリューションを実行するには、その 2 倍以上のディスクが必要になります。
そのリストを並べ替えることができれば、一度に 1 つずつリストを投げて、隣り合った一意のコピーを探すことができます。もちろん、それだけの量のデータを並べ替えるには、バイナリであるため、カスタムの並べ替えルーチン (作成したもの) が必要になります (16 進数に変換すると、データのサイズが 2 倍になりますが、標準のルーチンを使用できるようになります)。. . おそらくそこにいても、おそらくそれだけの量のデータで窒息するでしょう。. . 独自のカスタム ルーチンに戻ります。
考慮すべき点:
それだけの量のデータを並べ替えるには、数週間、数か月、あるいは数年かかるでしょう。メモリ内で適切なヒープ ソートなどを行うことができますが、ディスク領域が非常に限られているため、メモリ内で何を行うかに関係なく、ファイルの「バブル」ソートを行う可能性があります。
生成アルゴリズムがどのように見えるかに応じて、「1 メモリ ロード」相当のデータを生成し、その場所で並べ替えてから、ファイル (並べ替え済み) でディスクに書き出すことができます。それが完了したら、ソートされた個々のファイルをすべて「マージ」する必要があります。これは、はるかに簡単な作業です (数千のファイルがあるとしても、比較的簡単な作業です)。
ジェネレーターがデータについて何でも教えてくれる場合は、それを有利に利用してください。たとえば、私の場合、Knight's Moves を処理していると、出力値が常に大きくなっていることがわかりました (常に移動ごとに 1 ビットを追加していたため)。その小さな知識により、独自の方法でソートを最適化することができました。データを見て、似たようなことを知っているかどうかを確認してください。
もちろん、データを小さくすることは常に良いことです。たとえば、120 ハッシュについて話していますが、それは可逆的ですか? その場合、ハッシュが小さいのでソートします。そうでない場合、ハッシュはあまり役に立たない可能性があります(少なくとも私のソートソリューションでは)。
私はこのような問題の仕組みに興味があります。アイデアや考えられる解決策について意見を交換したいだけでも、このテーマについてメールを交換できれば幸いです。