namazu-dev(ring)

[Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>]

補足です。

Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx> wrote:

>開発当初から、NMZ.{i,ii,w,wi} を作成する処理の効率の悪さが気
>になっていました。が、この部分の処理をいじるのは厄介なので、
>長い間、放置してきました (悪い習慣だ…)。 2.0 を機会に改善し
>ようと思います。(それほど難しくない)

NMZ.{i,ii,w,wi,p,pi} です。
               ^^^^

関係する話題が [namazu 966] にありました。

| >Added Files: 878,914 files
| >Total Files: 878,914 files
| >Size: 2,167,480,108 bytes
| 
| これはすごい! 世界新記録です。 :-)
(snip)
| ところで、Namazu のインデックスは 32 bit 符合付き整数の壁が
| あるので、
| 
| >NMZ.i	721295588
| 
| この約 687 Mb のファイルが 2Gb を越えると扱えなくなります。
| 同じようなファイルを対象にインデックスを作ると仮定して、単純
| に計算すると、Namazuが扱える最大規模のインデックスは
| 
|   ファイル数: 2,048 / 687 * 878,914       =     2,620,110 (約262万)
|   合計サイズ: 2,048 / 687 * 2,167,480,108 = 6,461,425,416 (約 6 Gb)
| 
| となります。この規模のインデックスを作るには相当たくさんのメ
| モリ (2 Gbくらい?) を積んで $ON_MEMORY_MAX を 300 Mb くらい
| に設定しないと (インデックス作成が遅くて) やっていられないと
| 思います。
| 
| # 細かい話: NMZ.i, NMZ.p を作成する部分の処理は非効率なので、
| # 対象ファイルが多くなるにつれてどんどん遅くなっていきます
| # (たびたび書き直すので、全体で O(n^2) の仕事量を要する)。 
| # $ON_MEMORY_MAX の値を大きくすれば、NMZ.i, NMZ.p の作成の回
| # 数を少なくできるので、その分、速くなります。ほかの部分の処
| # 理は大体、線形なので対象ファイルの数に関わらず、ほぼ一定で
| # す。(たぶん)
| 
| ちなみに、最新の実装では 1.4.0.8-beta-8 に比べて、 NMZ.i,
| NMZ.p が 2-3割くらい小さくなっています。また、 NMZ.i とNMZ.w 
| を統合して NMZ.i のサイズを小さくする計画もあるので、そうす
| ると、もう少し規模の多いインデックスが作れるはずです。
| 
| # そんな巨大なインデックスを作る人はいないと思うけど。…と油
| # 断してはいけないかな :-)
| 
| そんなわけで、Namazu 2.0 では、1.3.0.xとくらべて全体のインデッ
| クスのサイズはおおよそ半分くらいになる見込みです。もちろん情
| 報の量は削らずに、です。(1.3.0.xのインデックスに無駄が多かっ
| たからなんだけど ;-）

-- Satoru Takabayashi