namazu-ml(ring)

[Satoru Takabayashi <ccsatoru@xxxxxxxxxxxxxxxxxx>]

Rei FURUKAWA <furukawa@xxxxxxxxxxxxxxxx> wrote:

>近々、データベースの pack 'w' 化が予定されていますが、フォーマットの変
>更点を、次のように予想しているのですが、こんな感じでよいでしょうか？

なかなか作業が進まなくてすみません。


>  > * NMZ.i
(snip)
>「エントリの総数 * 2」「文書ID」「スコア」が pack 'w' される。

はい、そうです。これによりサイズがかなり縮まることを期待しています。


>  > * NMZ.ii
>  >     [NMZ.i中の単語1の位置][NMZ.i中の単語2の位置]
>  >     [NMZ.i中の単語3の位置]....
>
>「位置」が pack 'w' される

NMZ.ii は namazu コマンドから int型のバイト数 (通常4byte) を元に計
算してアクセスされるので、 pack 'w' を導入してひとつのデータを表す
バイト数が可変になるとちとまずいです (勘違いしているかも)。

NMZ.ii の性質上、データの値は 0 からはじまって徐々に大きくなるので
バイト数が切り替わる地点を別のファイルなりに保存しておけばなんとか
なるのですが、そこまでするとちょっと複雑になります。

同じことは NMZ.fi, NMZ.pi, にも言えます。どうしましょう?


>  > * NMZ.h
>  >     [NMZ.ii中の\x0000の位置][NMZ.ii中の\x0001の位置] ...
>  >     [NMZ.ii中の\xffffの位置][番兵]
>
>NMZ.ii が pack 'w' されるのに伴い、offset / sizeof(int) だったものが
>offset になる。
>
>NMZ.h 内の値自体は、pack 'w' されない

NMZ.h は単語の先頭2byteをもとに検索範囲を限定するものです。が、実
際には大した効果はありません。この機会に廃止してもいいような気がし
ます。

ところで、インデックスに「ブロック」という概念を導入して100KB 程度
単位でアクセスするようにすればインデックスを zlib などで効率的に圧
縮できます。将来の課題として考えています。



>  > * NMZ.p
(snip)
>これは、正しくは
>
>    [ハッシュ値\x0000を含む文書数][ハッシュ値\x0000を含む文書ID]...
>    [ハッシュ値\x0001を含む文書数][ハッシュ値\x0001を含む文書ID]...
>    ...
>    [ハッシュ値\xffffを含む文書数][ハッシュ値\xffffを含む文書ID]
>
>ですよね？で、変更点は、
>「文書数」「文書 ID」が、pack 'w' される

すみません、間違っていました。変更点はその通りです。


>  > * NMZ.le
>  >   - little-endian なインデックスのときに存在
>  > * NMZ.be
>  >   - big-endian なインデックスのときに存在
>
>これはもうやめましょう。やめるチャンスですし。どちらかに固定でいいです
>よね。

そうですね。この機会に廃止してしまいましょう。個人的には big
endian の方がわかりやすい気がします。

-- Satoru Takabayashi