Annotated Lucene(中文版)

Annotated Lucene 作者：naven

3           索引類關系圖

下面逐個介紹與建立索引有關的一些類及它們的關系。 

3.1      org.apache.lucene.store.IndexWriter

一個IndexWriter對象只創建并維護一個索引。IndexWriter通過指定存放的目錄（Directory）以及文檔分析器（Analyzer）來構建，direcotry代表索引存儲（resides）在哪里；analyzer表示如何來分析文檔的內容；similarity用來規格化（normalize）文檔，給文檔算分（scoring）；IndexWriter類里還有一些SegmentInfos對象用于存儲索引片段信息，以及發生故障回滾等。以下是它們的類圖：

3.2       org.apache.lucene.store.Directory

一個Directory對象是一系列統一的文件列表（a flat list of files）。文件可以在它們被創建的時候一次寫入，一旦文件被創建，它再次打開后只能用于讀取（read）或者刪除（delete）操作。并且同時在讀取和寫入的時候允許隨機訪問（random access）。

在這里并不直接使用Java I/O API，但是更確切地說，所有I/O操作都是通過這個API處理的。這使得讀寫操作方式更統一起來，如基于內存的索引（RAM-based indices）的實現（即RAMDirectory）、通過JDBC存儲在數據庫中的索引、將一個索引存儲為一個文件的實現（即FSDirectory）。

Directory的鎖機制是一個LockFactory的實例實現的，可以通過調用Directory實例的setLockFactory()方法來更改。

3.3       org.apache.lucene.store.FSDirectory

FSDirectory類直接實現Directory抽象類為一個包含文件的目錄。目錄鎖的實現使用缺省的SimpleFSLockFactory，但是可以通過兩種方式修改，即給getLockFactory()傳入一個LockFactory實例，或者通過調用setLockFactory()方法明確制定LockFactory類。

目錄將被緩存（cache）起來，對一個指定的符合規定的路徑（canonical path）來說，同樣的FSDirectory實例通常通過getDirectory()方法返回。這使得同步機制（synchronization）能對目錄起作用。

3.4       org.apache.lucene.store.RAMDirectory

RAMDirectory類是一個駐留內存的（memory-resident）Directory抽象類的實現。目錄鎖的實現使用缺省的SingleInstanceLockFactory，但是可以通過setLockFactory()方法修改。

3.5       org.apache.lucene.store.IndexInput

IndexInput類是一個為了從一個目錄（Directory）中讀取文件的抽象基類，是一個隨機訪問（random-access）的輸入流（input stream），用于所有Lucene讀取Index的操作。BufferedIndexInput是一個實現了帶緩沖的IndexInput的基礎實現。

3.6       org.apache.lucene.store.IndexOutput

IndexOutput類是一個為了寫入文件到一個目錄（Directory）中的抽象基類，是一個隨機訪問（random-access）的輸出流（output stream），用于所有Lucene寫入Index的操作。BufferedIndexOutput是一個實現了帶緩沖的IndexOutput的基礎實現。RAMOuputStream是一個內存駐留（memory-resident）的IndexOutput的實現類。

3.7       org.apache.lucene.store.Analyzer

Analyzer類構建用于分析文本的TokenStream對象，因此（thus）它表示（represent）用于從文本中分解（extract）出組成索引的terms的一個規則器（policy）。典型的（typical）實現首先創建一個Tokenizer，它將那些從Reader對象中讀取字符流（stream of characters）打碎為（break into）原始的Tokens（raw Tokens）。然后一個或更多的TokenFilters可以應用在這個Tokenizer的輸出上。警告：你必須在你的子類（subclass）中覆寫（override）定義在這個類中的其中一個方法，否則的話Analyzer將會進入一個無限循環（infinite loop）中。

3.8       org.apache.lucene.store.StandardAnalyzer

StandardAnalyzer類是使用一個English的stop words列表來進行tokenize分解出文本中word，使用StandardTokenizer類分解詞，再加上StandardFilter以及LowerCaseFilter以及StopFilter這些過濾器進行處理的這樣一個Analyzer類的實現。

3.9       org.apache.lucene.search.Similarity

Similarity類實現算分（scoring）的API，它的子類實現了檢索算分的算法。DefaultSimilarity類是缺省的算分的實現，SimilarityDelegator類是用于委托算分（delegating scoring）的實現，在Query.getSimilarity(Searcher)}的實現里起作用，以便覆寫（override）一個Searcher中Similarity實現類的僅有的確定方法（certain methods）。

查詢q相對于文檔d的分數與在文檔和查詢向量（query vectors）之間的余弦距離（cosing-distance）或者點乘積（dot-product）有關系（correlates to），文檔和查詢向量存于一個信息檢索（Information Retrieval）的向量空間模型（Vector Space Model (VSM)）之中。一篇文檔的向量與查詢向量越接近（closer to），它的得分也越高（scored higher），這個分數按如下公式計算：

其中：

1.          tf(t in d)與term的出現次數（frequency）有關系（correlate to），定義為（defined as）term t在當前算分（currently scored）的文檔d中出現（appear in）的次數（number of times）。對一個給定（gived）的term，那些出現此term的次數越多（more occurences）的文檔將獲得越高的分數（higher score）。缺省的tf(t in d)算法實現在DefaultSimilarity類中，公式如下：

2.          idf(t) 代表（stand for）反轉文檔頻率（Inverse Document Frequency）。這個分數與反轉（inverse of）的docFreq（出現過term t的文檔數目）有關系。這個分數的意義是越不常出現（rarer）的term將為最后的總分貢獻（contribution）更多的分數。缺省idff(t in d)算法實現在DefaultSimilarity類中，公式如下：

3.          coord(q,d) 是一個評分因子，基于（based on）有多少個查詢terms在特定的文檔（specified document）中被找到。通常（typically），一篇包含了越多的查詢terms的文檔將比另一篇包含更少查詢terms的文檔獲得更高的分數。這是一個搜索時的因子（search time factor）是在搜索的時候起作用（in effect at search time），它在Similarity對象的coord(q,d)函數中計算。

4.          queryNorm(q)是一個修正因子（normalizing factor），用來使不同查詢間的分數更可比較（comparable）。這個因子不影響文檔的排名（ranking）（因為搜索排好序的文檔（ranked document）會增加（multiplied）相同的因數（same factor）），更確切地說只是（but rather just）為了嘗試（attempt to）使得不同查詢條件（甚至不同索引（different indexes））之間更可比較性。這是一個搜索時的因子是在搜索的時候起作用，由Similarity對象計算。缺省queryNorm(q)算法實現在DefaultSimilarity類中，公式如下：

sumOfSquaredWeights（查詢的terms）是由查詢Weight對象計算的，例如一個布爾（boolean）條件查詢的計算公式為：

5.          t.getBoost()是一個搜索時（search time）的代表查詢q中的term t的boost數值，具體指定在（as specified in）查詢的文本中（參見查詢語法），或者由應用程序調用setBoost()來指定。需要注意的是實際上（really）沒有一個直接（direct）的API來訪問（accessing）一個多個term的查詢（multi term query）中的一個term 的boost值，更確切地說（but rather），多個terms（multi terms）在一個查詢里的表示形式（represent as）是多個TermQuery對象，所以查詢里的一個term的boost值的訪問是通過調用子查詢（sub-query）的getBoost()方法實現的。

6.          norm(t,d)是提煉取得（encapsulate）一小部分boost值（在索引時間）和長度因子（length factor）：

ú            document boost – 在添加文檔到索引之前通過調用doc.setBoost()來設置。

ú            Field boost – 在添加Field到文檔之前通過調用field.setBoost()來設置。

ú            lengthNorm(field) – 在文檔添加到索引的時候，根據（in accordance with）文檔中該field的tokens數目計算得出，所以更短（shorter）的field會貢獻更多的分數。lengthNorm是在索引的時候起作用，由Similarity類計算得出。

當一篇文檔被添加到索引的時候，所有上面計算出的因子將相乘起來（multiplied）。如果文檔擁有多個相同名字的fields（multiple fields with same name），所有這些fields的boost值也會被一起相乘起來（multiplied together）：

然而norm數值的結果在被存儲（stored）之前被編碼成（encoded as）一個單獨的字節(single byte)。在檢索的時候，這個norm字節值從索引目錄（index directory）中讀取出來，并解碼回（decoded back）一個norm浮點數值（float value）。這個編/解碼（encoding/decoding）行為，會縮減（reduce）索引的大小（index size），這得自于（come with）精度損耗的代價（price of precision loss）- 它不保證decode(encode(x))=x，舉例來說decode(encode(0.89))=0.75。還有需要注意的是，檢索的時候再修改評分（scoring）的這個norm部分已近太遲了，例如，為檢索使用不同的Similarity。