Luceneの内部構造を見る３

前回はLuceneインデックスのファイル構成について確認しました。
いよいよ各ファイルについて見ていきますが、その前にLuceneで使われているデータ型が
「Primitive Types」に書いてありますので、確認しておきます。



Byteはフォーマットファイルの最小単位となる8bitです。

UInt32、UInt64はそれぞれ32bit、64bitの固定長の整数で、左側が大きな桁を表します。

VIntは、可変長の整数です。
各byteの一番左の１bitで次のbyteを使用するかどうかを表します。
１なら次のbyteを使用、0なら使用しません。
続く７bitは通常通り、左に行くに従って大きな桁になっていくのですが、
byteを股がる場合は、右のbyteのほうが大きな桁になることに注意してください。
画像の（１）、（２）、（３）の矢印の順に桁が上がっていきます。

CharはUTF-8でエンコードされます。

Stringはまずvintで使用するbyte数を表し、その数だけcharが続きます。

次回は、各ファイルについて見ていきます。

Luceneの内部構造を見る２

Luceneのファイルフォーマットを引き続き見ていきます。

Overviewです。
インデックスはセグメントで構成されます。
セグメントはドキュメントの追加で作成され、マージ操作でまとめられたりします。

各セグメントは、以下のようなファイルで構成されます。
（設定によっては.cfs形式の１つのファイルにまとめられます。）




次回以降は、各ファイルについて詳しく見ていきます。

Luceneの内部構造を見る１

Solr内部で使われているLuceneの中身を見ていきたいと思います。

なお、ただ使うだけなら全く必要ない情報ですので、内部構造に興味がある

場合だけ読んでもらえればよいかと思います。

一番核となるインデックスファイルのフォーマットがここで公開されて いますので、
まずはこれから見ていきます。

「Definitions」では、Document、Field、Termの定義が書いてあります。

それぞれの関係はこんな感じ。

続いての「Inverted Indexing」とは、日本語で言うところの「転置インデックス」を作ることです。

Documentに対して単語が対応している状態から、単語（Term）をキーにして

Documentを対応づけることで、単語からDocumentを素早く検索できるようにします。

検索エンジンでは一般的な手法です。

こんなイメージです。（※実際は少し違うみたいです。）

次回に続きます。