namazu-dev(ring)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mknmz next generation (Re: filters)
小関 吉則 (KOSEKI Yoshinori) <kose@xxxxxxxxxxxxxxxxxx> wrote:
>1. 複数の INDEX をマージする機能 (mknmzの後処理)
この機能は TODO です。:-)
[namazu-dev 1088] に書いた「インデックスを効率よく作成する方
法」と深く関わるので、じっくり方法を検討してから実装したいと
思います。
[namazu-dev 1088]より
| * 文書をどんどん読み込んでいって、$ON_MEMORY_MAX の値 (標
| 準では 5 MB) を越えた時点で NMZ.{i,ii,w,wi} を作業ファイ
| ルに書き出す
| * もし、すでに作業ファイルが存在するときは単純に連結し、連
| 結地点を配列に記録しておく
| - それぞれ別個のファイルにした方が単純だが、数が多くなる
| とマージするときにファイルの open/close の管理が面倒
| * 最後にまとめてマージする (k-way merging)
|
| 初回 ooooo (長さOMM)
| 2回 ooooo
| 3回 ooooo
| 4回 ooooo
| :
| n/OMM回 ooooo
| 最後 ooooooooooooooooooooooooo...oo (長さn)
|
| * 効率が良い: O(n * log n) のアルゴリズム
この、「すでに作業ファイルが存在するときは単純に連結し、連結
地点を配列に記録しておく」方法はよく考えると駄目な気がしてき
ました。ディスクの seek が頻繁に発生するでしょうから。
ディスクの seek には時間がかかるので、できるだけ線形にデータ
を読み込める方法で実装したいと思います。とすると、単純に別個
のファイルに分割した方がよさそうです。分割したファイルは単純
に先頭から線形に読み込めばいいわけですから。
マージする単純な方法は、 2つのペアを 1つにまとめていく方法で
す。直感的にはこんな感じ:
oooooooooooooooo
oooooooo
oooo
oo
o
`o' が 1つのファイルを表わします。最初の行の o の数を n とす
ると、 o の数の合計は 2n - 1になります。しかし、それぞれの行
では n に比例した処理を要するので全体の計算量は n * log_2 n
になります。直感的にはこんな感じ:
x x x x x x x x x x x x x x x x
xx xx xx xx xx xx xx xx
xxxx xxxx xxxx xxxx
xxxxxxxx xxxxxxxx
xxxxxxxxxxxxxxxx
GNU の sort コマンドでは 2つのペアではなく、複数個 (16個) を
まとめてマージしています (logの底が大きくなる)。しかし、
Namazu では処理すべきファイルが多いので、たくさんの unit を
まとめてマージするのは難しいです。同時に open できるファイル
数の制限に引っ掛かってしまうでしょうから。
>2. 複数の INDEX から検索できる機能 (namzuの機能)
こちらは大昔から実現しています。:)
-- Satoru Takabayashi