壊れたインデックスを調査するには: ナマズのブログ

Namazu はときより何らかの理由により、インデックスが壊れることがあります。
主に各種ソフトウェアの不具合によるものですが、具体的には分かりません。また、インデックスが壊れていても気づかないことも多々あります。
このため、インデックスが壊れているか否か検証する方法があるとよさそうです。
そうすれば、インデックスを壊す原因を突き止めやすくなるでしょう。

1. NMZ.i と NMZ.ii の整合性
NMZ.ii の値と、NMZ.i のデータの整合性は検証可能です。
- NMZ.ii のデータ(オフセット）は小さい順に並んでいます。
- NMZ.ii の最初の値は 0 です。
- NMZ.ii の最後の値をオフセットとした NMZ.i の値と先のオフセットを加算すると、NMZ.i のファイルサイズです。
- NMZ.i の単語データ長(+4)を累積していくと NMZ.ii の値と一致するかで検証可能です。(行区切りのチェック)
- NMZ.i の文書IDが小さいもの順に並んでいる。(ただし差分のため、チェックにはあまり有効ではない)

注意) BER 圧縮に注意すること

2. NMZ.w と NMZ.wi の整合性
- 単語ごとに改行が含まれるため、改行の個数が単語の個数です。
- NMZ.w の単語数と、NMZ.wi のデータ数は一致します。
- NMZ.wi のデータ(オフセット）は小さい順に並んでいます。
- NMZ.wi の指す位置はNMZ.wの単語の先頭文字です。 (行区切りのチェック)
- 単語の並びは昇順です。
- nul 文字や制御文字（改行を除く)は含まれません。
- EUC-JP 以外は含まれないはずですが、一部文字化けした単語がゴミとして含まれる可能性はあります。

3. NMZ.w* と NMZ.i* の整合性
- NMZ.i の単語数と NMZ.w の単語数は一致します。

4. NMZ.p と NMZ.pi の整合性
- NMZ.pi は必ず 262144 バイト(2^16 * sizeof(int))です。
- NMZ.pi のデータ(オフセット）は小さい順に並んでいます。
- NMZ.pi の最初の値は 0 です。
- NMZ.pi の最後の値をオフセットとした NMZ.p の値と先のオフセットを加算すると、NMZ.p のファイルサイズです。
- NMZ.p のデータ長(+4)を累積していくと NMZ.pi の値と一致するかで検証可能です。(行区切りのチェック)

5. NMZ.field.xxx と NMZ.field.xxx.i の整合性
- NMZ.w と NMZ.wi の整合性とほぼ同じ

6. 文書IDの整合性
- NMZ.i に含まれる文書IDは、最大文書IDまでです。
- NMZ.p に含まれる文書IDは、最大文書IDまでです。
- NMZ.t は全文書数分のデータです。
- NMZ.field.xxx は有効な全文書数分のデータです。
- NMZ.status の files は有効な全文書数です。
- NMZ.r は全文書数、有効な全文書数の両方の情報が含まれます。

7. 単語数の整合性
- NMZ.status の keys と NMZ.w の単語数は一致します。（文書削除後も)

8. テキストファイルの妥当性
- UNIX 改行
- EUC-JP (除く NMZ.r)

これらをきちんとチェックするツールがあるとインデックスが壊れているかどうか簡単に調べられて便利だと思います。


データのチェックのため、レコード単位でCRC 等をインデックスに含めるのが簡単で良いのかもしれません。

追記:
pnamazu に tool2/nmzcheck.pl がありました。

この文書は、不定期に更新します。