2

前の質問: Data structure for storage huge number of indexs, each pointing to a setから、逆インデックスの実装に適したデータ構造に関する回答を得ました。ただし、問題は、Linux サーバーで 128 GB の RAM 制限にすぐに達する可能性があるため、再度メモリが不足した場合に備えて準備したいと考えています。

現在、インバート インデックスのインデックスの総数は 39 億に達しており、これには約 50 GB の RAM が必要です。データベースシステムなどを提案する人もいるかもしれませんが、これは実験的研究のためのものであり、独自のデータを管理したいと考えており、いかなる種類のデータベースシステムも使用しません.

ファイルアクセスにmmapを使用する必要があるのはいつですか?これは有望に見えますが、ググってみたら、最初に mmap に固定スペースを割り当ててから、データの挿入を開始する必要があることがわかりました。反転インデックスは大きくなりますが、ビルドするまで正確な数はわかりません。(一部のデータは、そのようなデータを反転インデックスにプッシュする前に最初に処理する必要があります) そのために大量のメモリを割り当てることができますが、現在の反転インデックスだけで既に 50 GB の RAM を取得しています。そして、これが 2 番目の問題 (2) につながります。私たちのサーバーには多くの人が使用しており、50 GB 以上のスペースがあると、データがハードディスク内で断片化されます。

あるいは、ファイル I/O を使用してこれを管理し、階層型ディレクトリのような B-Tree を作成するとどうなりますか? 具合が悪くなるかも…

今回は、上記の前の質問と同じように、いくつかの提案をお願いしたいと思いますが、今回は、RAM とハード ディスクの間でデータを交換する必要があります。128 GB の RAM はこれを保持できない可能性があります。

4

1 に答える 1

1

可能であれば、システムにスワップ領域を追加し、カーネルにスワッピングを任せます。

それが不可能な場合は、インデックス キーによってブロック内のデータをクラスタリングし、アクセス時にメモリ内のブロックを圧縮/解凍するか、ディスクにスワップ アウトすることを検討します。

于 2013-03-02T00:31:39.547 に答える