0

Luceneのインデックスの（ファイル形式ではなく）メモリ内表現はどのように見えますか？リバースインデックス全体が、たとえば投稿リストの配列としてメモリにロードされていますか（各投稿リストにはドキュメントID、ドキュメント内の用語の頻度、および位置が含まれています）？何かのようなもの

class Posting {
  private int docID;
  private int termFreq;
  private int[] termPositions;
}

class PostingList {
  private Posting[] postings;
}

public class SomeClassThatHoldsTheIndexInMemory {
  private PostingList[] index;  // Indexed by some internal term ID?
}

インデックスを構成するすべてのもの（用語に関する補助情報を含む）がメモリに保持されていない可能性があることを理解していますが、確かに何かがありますか？

インデックスのメモリ内表現を定義するクラスはどれですか？インデックスが上記のようになっている場合、Luceneはどのようにして用語（文字列）から用語ID（整数）に移行しますか？

4

1 に答える 1

2

Luceneのメモリ内表現は、RAMDirectoryクラスを考慮して定義されます。これは、基本的に、HashMap（Stringキー）と（RAMFiles）のです。RAMFile次に、ファイルのバイトを表すバイトバッファのリストです。に保存するのと同じ情報FSDirectory。

Luceneは転置インデックスを格納します。インデックスは、増分（場合によってはマージされていない）セグメントのセットとして編成されます。「インデックスコミット」に属する各セグメント、および各セグメントは多かれ少なかれ別の転置インデックスです。1つのドキュメントのみの転置インデックスを保持する「セグメント」を見つけることもできます。

「投稿」またはDocument元の構造は、インデックスに追加するとすぐに失われます。さらに、（私が知る限り）ドキュメントのコレクション全体を繰り返すことはできません。とにかく、投稿/ドキュメントを二次構造に保存したり、シリアル化されたバージョンをインデックスに保存したり、オブジェクトStoredFieldのプロパティを1つずつ保存したりすることを妨げるものは何もありません。また、フィールドに独自の「反復可能な」ドキュメントIDを定義することもできません。

DirectoryReadersはインデックスの内部構造をSegmentReader扱います。

Luceneを使用したとき、「用語ID」のようなものを見たことがありませんでした。ただし、「ドキュメントID」は一般的な概念です。

于 2013-03-09T18:04:00.093 に答える