Namazu-devel-ja(旧)

[knok@xxxxxxxxxxxxx]

  インデックスサイズを小さくする単純な手法として、zlib を利用すること
は以前考えていました。たぶんそれほど難しいことではないと思います。

At Wed, 24 Dec 2003 17:59:47 +0900,
Komai @home wrote:
> メリットとしては、以下のような点が挙げられるでしょうか。
> （実装する人の大変さとか考えていなくてイメージのみの部分もありますが。）
> 
> 1)スコアの計算にいろいろバリエーションを持たせられる。
>   その場合、多少計算速度が落ちるますが、バリエーションの数を２つ３つと増やしていける。
>   イメージとしては、NMZ.field.｛いろいろ｝をいろいろ簡単に増やせるように現在のNamazuが
>   なっているそういう良い伝統をスコア値にも適用したい。
>   それだけインデックスのファイルが増えますが。。（これはデメリット）

  スコアに対する柔軟性はたしかに欲しいですね。以前馬場さんが PageRank 
的な処理を mknmz の外部で行う実装例をかかれていたのですが、mknmz とそ
ういう処理を結びつける仕組みが必要だなあ、とは漠然と思っていました。
  きょうび全文検索自体はできて当然の処理であって、そのなかから重用度の
高い情報を抽出できることが、求められてきているのだと思います。

  さらにいえば、転置インデックスを保存する形式としての NMZ.* は素性と
してはあまり良くないなあとも感じていて、他にいろいろと存在するフォーマッ
トや DB backend を選択可能にしたほうがよいのでは、とも思っています。

  その一歩として NMZ.* を扱う処理を分離するという作業を HEAD でやりか
けていたのですが、ずいぶん前に途中で放置しています... この作業の先には、
完全に分離してインデックス作成処理自体をライブラリ化し、他のアプリケー
ションとの連携をもっと容易にしたいという目論見もありました。

  ただまあ、ここまでコードが肥大化してきていると、いまのコードをベース
にするのは厳しいかも、という気もしないでもないです。
-- 
野首 貴嗣
E-mail: knok@xxxxxxxxxxxxx
	knok@xxxxxxxxxx / knok@xxxxxxxxxx