namazu-dev(ring)

[Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>]

なぜ今まで気づかなかったのか不思議ですが、 NMZ.i と NMZ.w と
統合すればインデックスのサイズをさらに節約できることがわかり
ました。

# その作業の面倒くささから、無意識が抑制していたのかも :-)

とあるメイリングリスト664通を対象に (最新の mknmzで)インデッ
クスを作ると 、 NMZ.* ファイルのサイズは

  % du NMZ.* |sort -nr |head
  633     NMZ.i
  311     NMZ.w
  257     NMZ.pi
  218     NMZ.p
  133     NMZ.field.summary
  100     NMZ.ii
  32      NMZ.field.subject
  30      NMZ.field.message-id
  28      NMZ.field.from
  24      NMZ.field.to

となります。この結果を見ると、 NMZ.i の次に NMZ.w のサイズが
大きいことがわかります。実は NMZ.i には NMZ.w の内容がまるご
と格納されているので、その分のデータは NMZ.i から削除できま
す。

すると、 633 Kb だった NMZ.i が 322 Kb に縮小します。ただし、
今度は NMZ.w にランダムアクセスする必要があるので、それ用の
インデックスを作るには、

  % wc -l NMZ.w
  25172 NMZ.w
  % expr 25172 '*' 4 
  100688

約 100 Kb 必要になります。つまり、全体では約 211 Kbを稼げる
計算になります。

この規模のインデックスでは NMZ.w と NMZ.i の比は 1:2 でした
が、インデックスの規模が大きくなるにつれて、 NMZ.w のサイズ
は 1:3, 1:4 とNMZ.i と比べて相対的に小さくなっていきます。

しかし、いずれにせよ、インデックス全体のサイズが小さくなるこ
とに変わりはないので、明日にでもさっそく実装を試みるつもりで
す。

また、インデックスが小さくなるのとは別に、検索速度が向上する
のでは、期待もあります。

なぜなら、今までは NMZ.i という巨大なファイルをランダムアク
セスしていたのに対し、新しい実装では NMZ.w という比較的小さ
なファイルをランダムアクセスするため、ディスクキャッシュが効
率よく働く効果が期待できるからです。

# 「うん、これはいい」と古川さんにひとこと言ってもらえると、
# やる気がでるかな :-)

-- Satoru Takabayashi