Lucene学习总结之三：Lucene的索引文件格式(1)
Lucene的索引里面存了些什么，如何存放的，也即Lucene的索引文件格式，是讀懂Lucene源代碼的一把鑰匙。
當我們真正進入到Lucene源代碼之中的時候，我們會發現:
- Lucene的索引過程，就是按照全文檢索的基本過程，將倒排表寫成此文件格式的過程。
- Lucene的搜索過程，就是按照此文件格式將索引進去的信息讀出來，然后計算每篇文檔打分(score)的過程。
本文詳細解讀了Apache Lucene - Index File Formats(http://lucene.apache.org/java/2_9_0/fileformats.html?) 這篇文章。
?
一、基本概念
下圖就是Lucene生成的索引的一個實例：
Lucene的索引結構是有層次結構的，主要分以下幾個層次：
- 索引(Index)：
- 在Lucene中一個索引是放在一個文件夾中的。
- 如上圖，同一文件夾中的所有的文件構成一個Lucene索引。
- 段(Segment)：
- 一個索引可以包含多個段，段與段之間是獨立的，添加新文檔可以生成新的段，不同的段可以合并。
- 如上圖，具有相同前綴文件的屬同一個段，圖中共兩個段 "_0" 和 "_1"。
- segments.gen和segments_5是段的元數據文件，也即它們保存了段的屬性信息。
- 文檔(Document)：
- 文檔是我們建索引的基本單位，不同的文檔是保存在不同的段中的，一個段可以包含多篇文檔。
- 新添加的文檔是單獨保存在一個新生成的段中，隨著段的合并，不同的文檔合并到同一個段中。
- 域(Field)：
- 一篇文檔包含不同類型的信息，可以分開索引，比如標題，時間，正文，作者等，都可以保存在不同的域里。
- 不同域的索引方式可以不同，在真正解析域的存儲的時候，我們會詳細解讀。
- 詞(Term)：
- 詞是索引的最小單位，是經過詞法分析和語言處理后的字符串。
?
Lucene的索引結構中，即保存了正向信息，也保存了反向信息。
所謂正向信息：
- 按層次保存了從索引，一直到詞的包含關系：索引(Index) –> 段(segment) –> 文檔(Document) –> 域(Field) –> 詞(Term)
- 也即此索引包含了那些段，每個段包含了那些文檔，每個文檔包含了那些域，每個域包含了那些詞。
- 既然是層次結構，則每個層次都保存了本層次的信息以及下一層次的元信息，也即屬性信息，比如一本介紹中國地理的書，應該首先介紹中國地理的概況，以及中國包含多少個省，每個省介紹本省的基本概況及包含多少個市，每個市介紹本市的基本概況及包含多少個縣，每個縣具體介紹每個縣的具體情況。
- 如上圖，包含正向信息的文件有：
- segments_N保存了此索引包含多少個段，每個段包含多少篇文檔。
- XXX.fnm保存了此段包含了多少個域，每個域的名稱及索引方式。
- XXX.fdx，XXX.fdt保存了此段包含的所有文檔，每篇文檔包含了多少域，每個域保存了那些信息。
- XXX.tvx，XXX.tvd，XXX.tvf保存了此段包含多少文檔，每篇文檔包含了多少域，每個域包含了多少詞，每個詞的字符串，位置等信息。
所謂反向信息：
- 保存了詞典到倒排表的映射：詞(Term) –> 文檔(Document)
- 如上圖，包含反向信息的文件有：
- XXX.tis，XXX.tii保存了詞典(Term Dictionary)，也即此段包含的所有的詞按字典順序的排序。
- XXX.frq保存了倒排表，也即包含每個詞的文檔ID列表。
- XXX.prx保存了倒排表中每個詞在包含此詞的文檔中的位置。
在了解Lucene索引的詳細結構之前，先看看Lucene索引中的基本數據類型。
?
二、基本類型
Lucene索引文件中，用一下基本類型來保存信息：
- Byte：是最基本的類型，長8位(bit)。
- UInt32：由4個Byte組成。
- UInt64：由8個Byte組成。
- VInt：
- 變長的整數類型，它可能包含多個Byte，對于每個Byte的8位，其中后7位表示數值，最高1位表示是否還有另一個Byte，0表示沒有，1表示有。
- 越前面的Byte表示數值的低位，越后面的Byte表示數值的高位。
- 例如130化為二進制為 1000, 0010，總共需要8位，一個Byte表示不了，因而需要兩個Byte來表示，第一個Byte表示后7位，并且在最高位置1來表示后面還有一個Byte，所以為(1) 0000010，第二個Byte表示第8位，并且最高位置0來表示后面沒有其他的Byte了，所以為(0) 0000001。
- Chars：是UTF-8編碼的一系列Byte。
- String：一個字符串首先是一個VInt來表示此字符串包含的字符的個數，接著便是UTF-8編碼的字符序列Chars。
?
三、基本規則
Lucene為了使的信息的存儲占用的空間更小，訪問速度更快，采取了一些特殊的技巧，然而在看Lucene文件格式的時候，這些技巧卻容易使我們感到困惑，所以有必要把這些特殊的技巧規則提取出來介紹一下。
在下不才，胡亂給這些規則起了一些名字，是為了方便后面應用這些規則的時候能夠簡單，不妥之處請大家諒解。
1. 前綴后綴規則(Prefix+Suffix)
Lucene在反向索引中，要保存詞典(Term Dictionary)的信息，所有的詞(Term)在詞典中是按照字典順序進行排列的，然而詞典中包含了文檔中的幾乎所有的詞，并且有的詞還是非常的長的，這樣索引文件會非常的大，所謂前綴后綴規則，即當某個詞和前一個詞有共同的前綴的時候，后面的詞僅僅保存前綴在詞中的偏移(offset)，以及除前綴以外的字符串(稱為后綴)。
比如要存儲如下詞:term，termagancy，termagant，terminal，
如果按照正常方式來存儲，需要的空間如下：
[VInt = 4] [t][e][r][m]，[VInt = 10][t][e][r][m][a][g][a][n][c][y]，[VInt = 9][t][e][r][m][a][g][a][n][t]，[VInt = 8][t][e][r][m][i][n][a][l]
共需要35個Byte.
如果應用前綴后綴規則，需要的空間如下：
[VInt = 4] [t][e][r][m]，[VInt = 4 (offset)][VInt = 6][a][g][a][n][c][y]，[VInt = 8 (offset)][VInt = 1][t]，[VInt = 4(offset)][VInt = 4][i][n][a][l]
共需要22個Byte。
大大縮小了存儲空間，尤其是在按字典順序排序的情況下，前綴的重合率大大提高。
2. 差值規則(Delta)
在Lucene的反向索引中，需要保存很多整型數字的信息，比如文檔ID號，比如詞(Term)在文檔中的位置等等。
由上面介紹，我們知道，整型數字是以VInt的格式存儲的。隨著數值的增大，每個數字占用的Byte的個數也逐漸的增多。所謂差值規則(Delta)就是先后保存兩個整數的時候，后面的整數僅僅保存和前面整數的差即可。
比如要存儲如下整數：16386，16387，16388，16389
如果按照正常方式來存儲，需要的空間如下：
[(1) 000, 0010][(1) 000, 0000][(0) 000, 0001]，[(1) 000, 0011][(1) 000, 0000][(0) 000, 0001]，[(1) 000, 0100][(1) 000, 0000][(0) 000, 0001]，[(1) 000, 0101][(1) 000, 0000][(0) 000, 0001]
供需12個Byte。
如果應用差值規則來存儲，需要的空間如下：
[(1) 000, 0010][(1) 000, 0000][(0) 000, 0001]，[(0) 000, 0001]，[(0) 000, 0001]，[(0) 000, 0001]
共需6個Byte。
大大縮小了存儲空間，而且無論是文檔ID，還是詞在文檔中的位置，都是按從小到大的順序，逐漸增大的。
3. 或然跟隨規則(A, B?)
Lucene的索引結構中存在這樣的情況，某個值A后面可能存在某個值B，也可能不存在，需要一個標志來表示后面是否跟隨著B。
一般的情況下，在A后面放置一個Byte，為0則后面不存在B，為1則后面存在B，或者0則后面存在B，1則后面不存在B。
但這樣要浪費一個Byte的空間，其實一個Bit就可以了。
在Lucene中，采取以下的方式：A的值左移一位，空出最后一位，作為標志位，來表示后面是否跟隨B，所以在這種情況下，A/2是真正的A原來的值。
如果去讀Apache Lucene - Index File Formats這篇文章，會發現很多符合這種規則的：
- .frq文件中的DocDelta[, Freq?]，DocSkip,PayloadLength?
- .prx文件中的PositionDelta,Payload? (但不完全是，如下表分析)
當然還有一些帶?的但不屬于此規則的：
- .frq文件中的SkipChildLevelPointer?，是多層跳躍表中，指向下一層表的指針，當然如果是最后一層，此值就不存在，也不需要標志。
- .tvf文件中的Positions?, Offsets?。
- 在此類情況下，帶?的值是否存在，并不取決于前面的值的最后一位。
- 而是取決于Lucene的某項配置，當然這些配置也是保存在Lucene索引文件中的。
- 如Position和Offset是否存儲，取決于.fnm文件中對于每個域的配置(TermVector.WITH_POSITIONS和TermVector.WITH_OFFSETS)
為什么會存在以上兩種情況，其實是可以理解的：
- 對于符合或然跟隨規則的，是因為對于每一個A，B是否存在都不相同，當這種情況大量存在的時候，從一個Byte到一個Bit如此8倍的空間節約還是很值得的。
- 對于不符合或然跟隨規則的，是因為某個值的是否存在的配置對于整個域(Field)甚至整個索引都是有效的，而非每次的情況都不相同，因而可以統一存放一個標志。
| 文章中對如下格式的描述令人困惑： Positions --> <PositionDelta,Payload?>?Freq Payload --> <PayloadLength?,PayloadData> PositionDelta和Payload是否適用或然跟隨規則呢？如何標識PayloadLength是否存在呢？ 其實PositionDelta和Payload并不符合或然跟隨規則，Payload是否存在，是由.fnm文件中對于每個域的配置中有關Payload的配置決定的(FieldOption.STORES_PAYLOADS) 。 當Payload不存在時，PayloadDelta本身不遵從或然跟隨原則。 當Payload存在時，格式應該變成如下：Positions --> <PositionDelta,PayloadLength?,PayloadData>?Freq 從而PositionDelta和PayloadLength一起適用或然跟隨規則。 |
?
4. 跳躍表規則(Skip list)??
為了提高查找的性能，Lucene在很多地方采取的跳躍表的數據結構。
跳躍表(Skip List)是如圖的一種數據結構，有以下幾個基本特征：
- 元素是按順序排列的，在Lucene中，或是按字典順序排列，或是按從小到大順序排列。
- 跳躍是有間隔的(Interval)，也即每次跳躍的元素數，間隔是事先配置好的，如圖跳躍表的間隔為3。
- 跳躍表是由層次的(level)，每一層的每隔指定間隔的元素構成上一層，如圖跳躍表共有2層。
需要注意一點的是，在很多數據結構或算法書中都會有跳躍表的描述，原理都是大致相同的，但是定義稍有差別：
- 對間隔(Interval)的定義： 如圖中，有的認為間隔為2，即兩個上層元素之間的元素數，不包括兩個上層元素；有的認為是3，即兩個上層元素之間的差，包括后面上層元素，不包括前面的上層元素；有的認為是4，即除兩個上層元素之間的元素外，既包括前面，也包括后面的上層元素。Lucene是采取的第二種定義。
- 對層次(Level)的定義：如圖中，有的認為應該包括原鏈表層，并從1開始計數，則總層次為3，為1，2，3層；有的認為應該包括原鏈表層，并從0計數，為0，1，2層；有的認為不應該包括原鏈表層，且從1開始計數，則為1，2層；有的認為不應該包括鏈表層，且從0開始計數，則為0，1層。Lucene采取的是最后一種定義。
跳躍表比順序查找，大大提高了查找速度，如查找元素72，原來要訪問2，3，7，12，23，37，39，44，50，72總共10個元素，應用跳躍表后，只要首先訪問第1層的50，發現72大于50，而第1層無下一個節點，然后訪問第2層的94，發現94大于72，然后訪問原鏈表的72，找到元素，共需要訪問3個元素即可。
四、具體格式
上面曾經交代過，Lucene保存了從Index到Segment到Document到Field一直到Term的正向信息，也包括了從Term到Document映射的反向信息，還有其他一些Lucene特有的信息。下面對這三種信息一一介紹。
4.1. 正向信息
Index –> Segments (segments.gen, segments_N) –> Field(fnm, fdx, fdt) –> Term (tvx, tvd, tvf)
上面的層次結構不是十分的準確，因為segments.gen和segments_N保存的是段(segment)的元數據信息(metadata)，其實是每個Index一個的，而段的真正的數據信息，是保存在域(Field)和詞(Term)中的。
4.1.1. 段的元數據信息(segments_N)
一個索引(Index)可以同時存在多個segments_N(至于如何存在多個segments_N，在描述完詳細信息之后會舉例說明)，然而當我們要打開一個索引的時候，我們必須要選擇一個來打開，那如何選擇哪個segments_N呢？
Lucene采取以下過程：
- 其一，在所有的segments_N中選擇N最大的一個。基本邏輯參照SegmentInfos.getCurrentSegmentGeneration(File[] files)，其基本思路就是在所有以segments開頭，并且不是segments.gen的文件中，選擇N最大的一個作為genA。
- 其二，打開segments.gen，其中保存了當前的N值。其格式如下，讀出版本號(Version)，然后再讀出兩個N，如果兩者相等，則作為genB。
-
IndexInput genInput = directory.openInput(IndexFileNames.SEGMENTS_GEN);//"segments.gen"?
int version = genInput.readInt();//讀出版本號?
if (version == FORMAT_LOCKLESS) {//如果版本號正確?
??? long gen0 = genInput.readLong();//讀出第一個N?
??? long gen1 = genInput.readLong();//讀出第二個N?
??? if (gen0 == gen1) {//如果兩者相等則為genB?
??????? genB = gen0;?
??? }?
} - 其三，在上述得到的genA和genB中選擇最大的那個作為當前的N，方才打開segments_N文件。其基本邏輯如下：
if (genA > genB)?
??? gen = genA;?
else?
??? gen = genB;
?
如下圖是segments_N的具體格式：
?
- Format：
- 索引文件格式的版本號。
- 由于Lucene是在不斷開發過程中的，因而不同版本的Lucene，其索引文件格式也不盡相同，于是規定一個版本號。
- Lucene 2.1此值-3，Lucene 2.9時，此值為-9。
- 當用某個版本號的IndexReader讀取另一個版本號生成的索引的時候，會因為此值不同而報錯。
- Version：
- 索引的版本號，記錄了IndexWriter將修改提交到索引文件中的次數。
- 其初始值大多數情況下從索引文件里面讀出，僅僅在索引開始創建的時候，被賦予當前的時間，已取得一個唯一值。
- 其值改變在IndexWriter.commit->IndexWriter.startCommit->SegmentInfos.prepareCommit->SegmentInfos.write->writeLong(++version)
- 其初始值之所最初取一個時間，是因為我們并不關心IndexWriter將修改提交到索引的具體次數，而更關心到底哪個是最新的。IndexReader中常比較自己的version和索引文件中的version是否相同來判斷此IndexReader被打開后，還有沒有被IndexWriter更新。
| //在DirectoryReader中有一下函數。 public boolean isCurrent() throws CorruptIndexException, IOException {? |
- NameCount
- 是下一個新段(Segment)的段名。
- 所有屬于同一個段的索引文件都以段名作為文件名，一般為_0.xxx, _0.yyy,? _1.xxx, _1.yyy ……
- 新生成的段的段名一般為原有最大段名加一。
- 如同的索引，NameCount讀出來是2，說明新的段為_2.xxx, _2.yyy
- SegCount
- 段(Segment)的個數。
- 如上圖，此值為2。
- SegCount個段的元數據信息：
- SegName
- 段名，所有屬于同一個段的文件都有以段名作為文件名。
- 如上圖，第一個段的段名為"_0"，第二個段的段名為"_1"
- SegSize
- 此段中包含的文檔數
- 然而此文檔數是包括已經刪除，又沒有optimize的文檔的，因為在optimize之前，Lucene的段中包含了所有被索引過的文檔，而被刪除的文檔是保存在.del文件中的，在搜索的過程中，是先從段中讀到了被刪除的文檔，然后再用.del中的標志，將這篇文檔過濾掉。
- 如下的代碼形成了上圖的索引，可以看出索引了兩篇文檔形成了_0段，然后又刪除了其中一篇，形成了_0_1.del，又索引了兩篇文檔形成_1段，然后又刪除了其中一篇，形成_1_1.del。因而在兩個段中，此值都是2。
- SegName
| IndexWriter writer = new IndexWriter(FSDirectory.open(INDEX_DIR), new StandardAnalyzer(Version.LUCENE_CURRENT), true, IndexWriter.MaxFieldLength.LIMITED);? //文檔一為：Students should be allowed to go out with their friends, but not allowed to drink beer. //文檔二為：My friend Jerry went to school to see his students but found them drunk which is not allowed. writer.commit();//提交兩篇文檔，形成_0段。 writer.deleteDocuments(new Term("contents", "school"));//刪除文檔二? |
-
- DelGen
- .del文件的版本號
- Lucene中，在optimize之前，刪除的文檔是保存在.del文件中的。
- 在Lucene 2.9中，文檔刪除有以下幾種方式：
- IndexReader.deleteDocument(int docID)是用IndexReader按文檔號刪除。
- IndexReader.deleteDocuments(Term term)是用IndexReader刪除包含此詞(Term)的文檔。
- IndexWriter.deleteDocuments(Term term)是用IndexWriter刪除包含此詞(Term)的文檔。
- IndexWriter.deleteDocuments(Term[] terms)是用IndexWriter刪除包含這些詞(Term)的文檔。
- IndexWriter.deleteDocuments(Query query)是用IndexWriter刪除能滿足此查詢(Query)的文檔。
- IndexWriter.deleteDocuments(Query[] queries)是用IndexWriter刪除能滿足這些查詢(Query)的文檔。
- 原來的版本中Lucene的刪除一直是由IndexReader來完成的，在Lucene 2.9中雖可以用IndexWriter來刪除，但是其實真正的實現是在IndexWriter中，保存了readerpool，當IndexWriter向索引文件提交刪除的時候，仍然是從readerpool中得到相應的IndexReader，并用IndexReader來進行刪除的。下面的代碼可以說明：
- DelGen
| IndexWriter.applyDeletes() -> DocumentsWriter.applyDeletes(SegmentInfos) ???? -> reader.deleteDocument(doc) |
-
-
-
- DelGen是每當IndexWriter向索引文件中提交刪除操作的時候，加1，并生成新的.del文件。
-
-
| IndexWriter.commit() -> IndexWriter.applyDeletes() ??? -> IndexWriter$ReaderPool.release(SegmentReader) ???????? -> SegmentReader(IndexReader).commit() ???????????? -> SegmentReader.doCommit(Map) ????????????????? -> SegmentInfo.advanceDelGen() ?????????????????????? -> if (delGen == NO) {? |
| IndexWriter writer = new IndexWriter(FSDirectory.open(INDEX_DIR), new StandardAnalyzer(Version.LUCENE_CURRENT), true, IndexWriter.MaxFieldLength.LIMITED);? indexDocs(writer, docDir);//索引兩篇文檔，一篇包含"school"，另一篇包含"beer"? 形成的索引文件如下： ? |
?
-
- DocStoreOffset
- DocStoreSegment
- DocStoreIsCompoundFile
- 對于域(Stored Field)和詞向量(Term Vector)的存儲可以有不同的方式，即可以每個段(Segment)單獨存儲自己的域和詞向量信息，也可以多個段共享域和詞向量，把它們存儲到一個段中去。
- 如果DocStoreOffset為-1，則此段單獨存儲自己的域和詞向量，從存儲文件上來看，如果此段段名為XXX，則此段有自己的XXX.fdt，XXX.fdx，XXX.tvf，XXX.tvd，XXX.tvx文件。DocStoreSegment和DocStoreIsCompoundFile在此處不被保存。
- 如果DocStoreOffset不為-1，則DocStoreSegment保存了共享的段的名字，比如為YYY，DocStoreOffset則為此段的域及詞向量信息在共享段中的偏移量。則此段沒有自己的XXX.fdt，XXX.fdx，XXX.tvf，XXX.tvd，XXX.tvx文件，而是將信息存放在共享段的YYY.fdt，YYY.fdx，YYY.tvf，YYY.tvd，YYY.tvx文件中。
- DocumentsWriter中有兩個成員變量：String segment是當前索引信息存放的段，String docStoreSegment是域和詞向量信息存儲的段。兩者可以相同也可以不同，決定了域和詞向量信息是存儲在本段中，還是和其他的段共享。
- IndexWriter.flush(boolean triggerMerge, boolean flushDocStores, boolean flushDeletes)中第二個參數flushDocStores會影響到是否單獨或是共享存儲。其實最終影響的是DocumentsWriter.closeDocStore()。每當flushDocStores為false時，closeDocStore不被調用，說明下次添加到索引文件中的域和詞向量信息是同此次共享一個段的。直到flushDocStores為true的時候，closeDocStore被調用，從而下次添加到索引文件中的域和詞向量信息將被保存在一個新的段中，不同此次共享一個段(在這里需要指出的是Lucene的一個很奇怪的實現，雖然下次域和詞向量信息是被保存到新的段中，然而段名卻是這次被確定了的，在initSegmentName中當docStoreSegment == null時，被置為當前的segment，而非下一個新的segment，docStoreSegment = segment，于是會出現如下面的例子的現象)。
- 好在共享域和詞向量存儲并不是經常被使用到，實現也或有缺陷，暫且解釋到此。
| ????? IndexWriter writer = new IndexWriter(FSDirectory.open(INDEX_DIR), new StandardAnalyzer(Version.LUCENE_CURRENT), true, IndexWriter.MaxFieldLength.LIMITED);? ???? //flush生成segment "_0"，并且flush函數中，flushDocStores設為false，也即下個段將同本段共享域和詞向量信息，這時DocumentsWriter中的docStoreSegment= "_0"。 ????? indexDocs(writer, docDir);? //commit生成segment "_1"，由于上次flushDocStores設為false，于是段"_1"的域以及詞向量信息是保存在"_0"中的，在這個時刻，段"_1"并不生成自己的"_1.fdx"和"_1.fdt"。然而在commit函數中，flushDocStores設為true，也即下個段將單獨使用新的段來存儲域和詞向量信息。然而這時，DocumentsWriter中的docStoreSegment= "_1"，也即當段"_2"存儲其域和詞向量信息的時候，是存在"_1.fdx"和"_1.fdt"中的，而段"_1"的域和詞向量信息卻是存在"_0.fdt"和"_0.fdx"中的，這一點非常令人困惑。 如圖writer.commit的時候，_1.fdt和_1.fdx并沒有形成。
????? indexDocs(writer, docDir);? //段"_2"形成，由于上次flushDocStores設為true，其域和詞向量信息是新創建一個段保存的，卻是保存在_1.fdt和_1.fdx中的，這時候才產生了此二文件。
????? indexDocs(writer, docDir);? //段"_3"形成，由于上次flushDocStores設為false，其域和詞向量信息是共享一個段保存的，也是是保存在_1.fdt和_1.fdx中的 ????? indexDocs(writer, docDir);? //段"_4"形成，由于上次flushDocStores設為false，其域和詞向量信息是共享一個段保存的，也是是保存在_1.fdt和_1.fdx中的。然而函數commit中flushDocStores設為true，也意味著下一個段將新創建一個段保存域和詞向量信息，此時DocumentsWriter中docStoreSegment= "_4"，也表明了雖然段"_4"的域和詞向量信息保存在了段"_1"中，將來的域和詞向量信息卻要保存在段"_4"中。此時"_4.fdx"和"_4.fdt"尚未產生。 ????
????? indexDocs(writer, docDir);? //段"_5"形成，由于上次flushDocStores設為true，其域和詞向量信息是新創建一個段保存的，卻是保存在_4.fdt和_4.fdx中的，這時候才產生了此二文件。
????? indexDocs(writer, docDir);? //段"_6"形成，由于上次flushDocStores設為false，其域和詞向量信息是共享一個段保存的，也是是保存在_4.fdt和_4.fdx中的 |
-
- HasSingleNormFile
- 在搜索的過程中，標準化因子(Normalization Factor)會影響文檔最后的評分。
- 不同的文檔重要性不同，不同的域重要性也不同。因而每個文檔的每個域都可以有自己的標準化因子。
- 如果HasSingleNormFile為1，則所有的標準化因子都是存在.nrm文件中的。
- 如果HasSingleNormFile不是1，則每個域都有自己的標準化因子文件.fN
- NumField
- 域的數量
- NormGen
- 如果每個域有自己的標準化因子文件，則此數組描述了每個標準化因子文件的版本號，也即.fN的N。
- IsCompoundFile
- 是否保存為復合文件，也即把同一個段中的文件按照一定格式，保存在一個文件當中，這樣可以減少每次打開文件的個數。
- 是否為復合文件，由接口IndexWriter.setUseCompoundFile(boolean)設定。?
- 非符合文件同符合文件的對比如下圖：
- HasSingleNormFile
| 非復合文件：? | 復合文件：? ? |
?
-
- DeletionCount
- 記錄了此段中刪除的文檔的數目。
- HasProx
- 如果至少有一個段omitTf為false，也即詞頻(term freqency)需要被保存，則HasProx為1，否則為0。
- Diagnostics
- 調試信息。
- DeletionCount
- User map data
- 保存了用戶從字符串到字符串的映射Map
- CheckSum
- 此文件segment_N的校驗和。
| 讀取此文件格式參考SegmentInfos.read(Directory directory, String segmentFileName):
|
?
4.1.2. 域(Field)的元數據信息(.fnm)
一個段(Segment)包含多個域，每個域都有一些元數據信息，保存在.fnm文件中，.fnm文件的格式如下：
- FNMVersion
- 是fnm文件的版本號，對于Lucene 2.9為-2
- FieldsCount
- 域的數目
- 一個數組的域(Fields)
- FieldName：域名，如"title"，"modified"，"content"等。
- FieldBits:一系列標志位，表明對此域的索引方式
- 最低位：1表示此域被索引，0則不被索引。所謂被索引，也即放到倒排表中去。
- 僅僅被索引的域才能夠被搜到。
- Field.Index.NO則表示不被索引。
- Field.Index.ANALYZED則表示不但被索引，而且被分詞，比如索引"hello world"后，無論是搜"hello"，還是搜"world"都能夠被搜到。
- Field.Index.NOT_ANALYZED表示雖然被索引，但是不分詞，比如索引"hello world"后，僅當搜"hello world"時，能夠搜到，搜"hello"和搜"world"都搜不到。
- 一個域出了能夠被索引，還能夠被存儲，僅僅被存儲的域是搜索不到的，但是能通過文檔號查到，多用于不想被搜索到，但是在通過其它域能夠搜索到的情況下，能夠隨著文檔號返回給用戶的域。
- Field.Store.Yes則表示存儲此域，Field.Store.NO則表示不存儲此域。
- 倒數第二位：1表示保存詞向量，0為不保存詞向量。
- Field.TermVector.YES表示保存詞向量。
- Field.TermVector.NO表示不保存詞向量。
- 倒數第三位：1表示在詞向量中保存位置信息。
- Field.TermVector.WITH_POSITIONS
- 倒數第四位：1表示在詞向量中保存偏移量信息。
- Field.TermVector.WITH_OFFSETS
- 倒數第五位：1表示不保存標準化因子
- Field.Index.ANALYZED_NO_NORMS
- Field.Index.NOT_ANALYZED_NO_NORMS
- 倒數第六位：是否保存payload
- 最低位：1表示此域被索引，0則不被索引。所謂被索引，也即放到倒排表中去。
要了解域的元數據信息，還要了解以下幾點：
- 位置(Position)和偏移量(Offset)的區別
- 位置是基于詞Term的，偏移量是基于字母或漢字的。
- 索引域(Indexed)和存儲域(Stored)的區別
- 一個域為什么會被存儲(store)而不被索引(Index)呢？在一個文檔中的所有信息中，有這樣一部分信息，可能不想被索引從而可以搜索到，但是當這個文檔由于其他的信息被搜索到時，可以同其他信息一同返回。
- 舉個例子，讀研究生時，您好不容易寫了一篇論文交給您的導師，您的導師卻要他所第一作者而您做第二作者，然而您導師不想別人在論文系統中搜索您的名字時找到這篇論文，于是在論文系統中，把第二作者這個Field的Indexed設為false，這樣別人搜索您的名字，永遠不知道您寫過這篇論文，只有在別人搜索您導師的名字從而找到您的文章時，在一個角落表述著第二作者是您。
- payload的使用
- 我們知道，索引是以倒排表形式存儲的，對于每一個詞，都保存了包含這個詞的一個鏈表，當然為了加快查詢速度，此鏈表多用跳躍表進行存儲。
- Payload信息就是存儲在倒排表中的，同文檔號一起存放，多用于存儲與每篇文檔相關的一些信息。當然這部分信息也可以存儲域里(stored Field)，兩者從功能上基本是一樣的，然而當要存儲的信息很多的時候，存放在倒排表里，利用跳躍表，有利于大大提高搜索速度。
- Payload的存儲方式如下圖：
-
- Payload主要有以下幾種用法：
- 存儲每個文檔都有的信息：比如有的時候，我們想給每個文檔賦一個我們自己的文檔號，而不是用Lucene自己的文檔號。于是我們可以聲明一個特殊的域(Field)"_ID"和特殊的詞(Term)"_ID"，使得每篇文檔都包含詞"_ID"，于是在詞"_ID"的倒排表里面對于每篇文檔又有一項，每一項都有一個payload，于是我們可以在payload里面保存我們自己的文檔號。每當我們得到一個Lucene的文檔號的時候，就能從跳躍表中查找到我們自己的文檔號。
- Payload主要有以下幾種用法：
| //聲明一個特殊的域和特殊的詞? public static final String ID_PAYLOAD_FIELD = "_ID"; public static final String ID_PAYLOAD_TERM = "_ID"; public static final Term ID_TERM = new Term(ID_PAYLOAD_TERM, ID_PAYLOAD_FIELD); //聲明一個特殊的TokenStream，它只生成一個詞(Term)，就是那個特殊的詞，在特殊的域里面。 static class SinglePayloadTokenStream extends TokenStream {? ??? SinglePayloadTokenStream(String idPayloadTerm) {? ??? void setPayloadValue(byte[] value) {? ??? public Token next() throws IOException {? //對于每一篇文檔，都讓它包含這個特殊的詞，在特殊的域里面 SinglePayloadTokenStream singlePayloadTokenStream = new SinglePayloadTokenStream(ID_PAYLOAD_TERM);? long id = 0;? |
?
-
-
- 影響詞的評分
- 在Similarity抽象類中有函數public float scorePayload(byte [] payload, int offset, int length)? 可以根據payload的值影響評分。
- 影響詞的評分
-
- 讀取域元數據信息的代碼如下：
| FieldInfos.read(IndexInput, String)
|
?
4.1.3. 域(Field)的數據信息(.fdt，.fdx)
- 域數據文件(fdt):
- 真正保存存儲域(stored field)信息的是fdt文件
- 在一個段(segment)中總共有segment size篇文檔，所以fdt文件中共有segment size個項，每一項保存一篇文檔的域的信息
- 對于每一篇文檔，一開始是一個fieldcount，也即此文檔包含的域的數目，接下來是fieldcount個項，每一項保存一個域的信息。
- 對于每一個域，fieldnum是域號，接著是一個8位的byte，最低一位表示此域是否分詞(tokenized)，倒數第二位表示此域是保存字符串數據還是二進制數據，倒數第三位表示此域是否被壓縮，再接下來就是存儲域的值，比如new Field("title", "lucene in action", Field.Store.Yes, …)，則此處存放的就是"lucene in action"這個字符串。
- 域索引文件(fdx)
- 由域數據文件格式我們知道，每篇文檔包含的域的個數，每個存儲域的值都是不一樣的，因而域數據文件中segment size篇文檔，每篇文檔占用的大小也是不一樣的，那么如何在fdt中辨別每一篇文檔的起始地址和終止地址呢，如何能夠更快的找到第n篇文檔的存儲域的信息呢？就是要借助域索引文件。
- 域索引文件也總共有segment size個項，每篇文檔都有一個項，每一項都是一個long，大小固定，每一項都是對應的文檔在fdt文件中的起始地址的偏移量，這樣如果我們想找到第n篇文檔的存儲域的信息，只要在fdx中找到第n項，然后按照取出的long作為偏移量，就可以在fdt文件中找到對應的存儲域的信息。
- 讀取域數據信息的代碼如下：
| Document FieldsReader.doc(int n, FieldSelector fieldSelector)
|
4.1.3. 詞向量(Term Vector)的數據信息(.tvx，.tvd，.tvf)
詞向量信息是從索引(index)到文檔(document)到域(field)到詞(term)的正向信息，有了詞向量信息，我們就可以得到一篇文檔包含那些詞的信息。
- 詞向量索引文件(tvx)
- 一個段(segment)包含N篇文檔，此文件就有N項，每一項代表一篇文檔。
- 每一項包含兩部分信息：第一部分是詞向量文檔文件(tvd)中此文檔的偏移量，第二部分是詞向量域文件(tvf)中此文檔的第一個域的偏移量。
- 詞向量文檔文件(tvd)
- 一個段(segment)包含N篇文檔，此文件就有N項，每一項包含了此文檔的所有的域的信息。
- 每一項首先是此文檔包含的域的個數NumFields，然后是一個NumFields大小的數組，數組的每一項是域號。然后是一個(NumFields - 1)大小的數組，由前面我們知道，每篇文檔的第一個域在tvf中的偏移量在tvx文件中保存，而其他(NumFields - 1)個域在tvf中的偏移量就是第一個域的偏移量加上這(NumFields - 1)個數組的每一項的值。
- 詞向量域文件(tvf)
- 此文件包含了此段中的所有的域，并不對文檔做區分，到底第幾個域到第幾個域是屬于那篇文檔，是由tvx中的第一個域的偏移量以及tvd中的(NumFields - 1)個域的偏移量來決定的。
- 對于每一個域，首先是此域包含的詞的個數NumTerms，然后是一個8位的byte，最后一位是指定是否保存位置信息，倒數第二位是指定是否保存偏移量信息。然后是NumTerms個項的數組，每一項代表一個詞(Term)，對于每一個詞，由詞的文本TermText，詞頻TermFreq(也即此詞在此文檔中出現的次數)，詞的位置信息，詞的偏移量信息。
- 讀取詞向量數據信息的代碼如下：
| TermVectorsReader.get(int docNum, String field, TermVectorMapper)
|
4.2. 反向信息
反向信息是索引文件的核心，也即反向索引。
反向索引包括兩部分，左面是詞典(Term Dictionary)，右面是倒排表(Posting List)。
在Lucene中，這兩部分是分文件存儲的，詞典是存儲在tii，tis中的，倒排表又包括兩部分，一部分是文檔號及詞頻，保存在frq中，一部分是詞的位置信息，保存在prx中。
- Term Dictionary (tii, tis)
- –> Frequencies (.frq)
- –> Positions (.prx)
4.2.1. 詞典(tis)及詞典索引(tii)信息
在詞典中，所有的詞是按照字典順序排序的。
- 詞典文件(tis)
- TermCount：詞典中包含的總的詞數
- IndexInterval：為了加快對詞的查找速度，也應用類似跳躍表的結構，假設IndexInterval為4，則在詞典索引(tii)文件中保存第4個，第8個，第12個詞，這樣可以加快在詞典文件中查找詞的速度。
- SkipInterval：倒排表無論是文檔號及詞頻，還是位置信息，都是以跳躍表的結構存在的，SkipInterval是跳躍的步數。
- MaxSkipLevels：跳躍表是多層的，這個值指的是跳躍表的最大層數。
- TermCount個項的數組，每一項代表一個詞，對于每一個詞，以前綴后綴規則存放詞的文本信息(PrefixLength + Suffix)，詞屬于的域的域號(FieldNum)，有多少篇文檔包含此詞(DocFreq)，此詞的倒排表在frq，prx中的偏移量(FreqDelta, ProxDelta)，此詞的倒排表的跳躍表在frq中的偏移量(SkipDelta)，這里之所以用Delta，是應用差值規則。
- 詞典索引文件(tii)
- 詞典索引文件是為了加快對詞典文件中詞的查找速度，保存每隔IndexInterval個詞。
- 詞典索引文件是會被全部加載到內存中去的。
- IndexTermCount = TermCount / IndexInterval：詞典索引文件中包含的詞數。
- IndexInterval同詞典文件中的IndexInterval。
- SkipInterval同詞典文件中的SkipInterval。
- MaxSkipLevels同詞典文件中的MaxSkipLevels。
- IndexTermCount個項的數組，每一項代表一個詞，每一項包括兩部分，第一部分是詞本身(TermInfo)，第二部分是在詞典文件中的偏移量(IndexDelta)。假設IndexInterval為4，此數組中保存第4個，第8個，第12個詞。。。
- 讀取詞典及詞典索引文件的代碼如下：
| origEnum = new SegmentTermEnum(directory.openInput(segment + "." + IndexFileNames.TERMS_EXTENSION,readBufferSize), fieldInfos, false);//用于讀取tis文件
SegmentTermEnum indexEnum = new SegmentTermEnum(directory.openInput(segment + "." + IndexFileNames.TERMS_INDEX_EXTENSION, readBufferSize), fieldInfos, true);//用于讀取tii文件
|
4.2.2. 文檔號及詞頻(frq)信息
文檔號及詞頻文件里面保存的是倒排表，是以跳躍表形式存在的。
- 此文件包含TermCount個項，每一個詞都有一項，因為每一個詞都有自己的倒排表。
- 對于每一個詞的倒排表都包括兩部分，一部分是倒排表本身，也即一個數組的文檔號及詞頻，另一部分是跳躍表，為了更快的訪問和定位倒排表中文檔號及詞頻的位置。
- 對于文檔號和詞頻的存儲應用的是差值規則和或然跟隨規則，Lucene的文檔本身有以下幾句話，比較難以理解，在此解釋一下：
| For example, the TermFreqs for a term which occurs once in document seven and three times in document eleven, with omitTf false, would be the following sequence of VInts: 15, 8, 3 If omitTf were true it would be this sequence of VInts instead: 7,4 首先我們看omitTf=false的情況，也即我們在索引中會存儲一個文檔中term出現的次數。 例子中說了，表示在文檔7中出現1次，并且又在文檔11中出現3次的文檔用以下序列表示：15，8，3. 那這三個數字是怎么計算出來的呢？ 首先，根據定義TermFreq --> DocDelta[, Freq?]，一個TermFreq結構是由一個DocDelta后面或許跟著Freq組成，也即上面我們說的A+B？結構。 DocDelta自然是想存儲包含此Term的文檔的ID號了，Freq是在此文檔中出現的次數。 所以根據例子，應該存儲的完整信息為[DocID = 7, Freq = 1] [DocID = 11,? Freq = 3](見全文檢索的基本原理章節)。 然而為了節省空間，Lucene對編號此類的數據都是用差值來表示的，也即上面說的規則2，Delta規則，于是文檔ID就不能按完整信息存了，就應該存放如下： [DocIDDelta = 7, Freq = 1][DocIDDelta = 4 (11-7), Freq = 3] 然而Lucene對于A+B?這種或然跟隨的結果，有其特殊的存儲方式，見規則3，即A+B?規則，如果DocDelta后面跟隨的Freq為1，則用DocDelta最后一位置1表示。 如果DocDelta后面跟隨的Freq大于1，則DocDelta得最后一位置0，然后后面跟隨真正的值，從而對于第一個Term，由于Freq為1，于是放在DocDelta的最后一位表示，DocIDDelta = 7的二進制是000 0111，必須要左移一位，且最后一位置一，000 1111 = 15，對于第二個Term，由于Freq大于一，于是放在DocDelta的最后一位置零，DocIDDelta = 4的二進制是0000 0100，必須要左移一位，且最后一位置零，0000 1000 = 8，然后后面跟隨真正的Freq = 3。 于是得到序列：[DocDleta = 15][DocDelta = 8, Freq = 3]，也即序列，15，8，3。 如果omitTf=true，也即我們不在索引中存儲一個文檔中Term出現的次數，則只存DocID就可以了，因而不存在A+B?規則的應用。 [DocID = 7][DocID = 11]，然后應用規則2，Delta規則，于是得到序列[DocDelta = 7][DocDelta = 4 (11 - 7)]，也即序列，7，4. |
- 對于跳躍表的存儲有以下幾點需要解釋一下：
- 跳躍表可根據倒排表本身的長度(DocFreq)和跳躍的幅度(SkipInterval)而分不同的層次，層次數為NumSkipLevels = Min(MaxSkipLevels, floor(log(DocFreq/log(SkipInterval)))).
- 第Level層的節點數為DocFreq/(SkipInterval^(Level + 1))，level從零計數。
- 除了最高層之外，其他層都有SkipLevelLength來表示此層的二進制長度(而非節點的個數)，方便讀取某一層的跳躍表到緩存里面。
- 低層在前，高層在后，當讀完所有的低層后，剩下的就是最后一層，因而最后一層不需要SkipLevelLength。這也是為什么Lucene文檔中的格式描述為?NumSkipLevels-1?, SkipLevel，也即低NumSKipLevels-1層有SkipLevelLength，最后一層只有SkipLevel，沒有SkipLevelLength。
- 除最低層以外，其他層都有SkipChildLevelPointer來指向下一層相應的節點。
- 每一個跳躍節點包含以下信息：文檔號，payload的長度，文檔號對應的倒排表中的節點在frq中的偏移量，文檔號對應的倒排表中的節點在prx中的偏移量。
- 雖然Lucene的文檔中有以下的描述，然而實驗的結果卻不是完全準確的：
| Example: SkipInterval = 4, MaxSkipLevels = 2, DocFreq = 35. Then skip level 0 has 8 SkipData entries, containing the 3rd?, 7th?, 11th?, 15th?, 19th?, 23rd?, 27th?, and 31st?document numbers in TermFreqs. Skip level 1 has 2 SkipData entries, containing the 15th?and 31st?document numbers in TermFreqs. 按照描述，當SkipInterval為4，且有35篇文檔的時候，Skip level = 0應該包括第3，第7，第11，第15，第19，第23，第27，第31篇文檔，Skip level = 1應該包括第15，第31篇文檔。 然而真正的實現中，跳躍表節點的時候，卻向前偏移了，偏移的原因在于下面的代碼：
從代碼中，我們可以看出，當SkipInterval為4的時候，當docID = 0時，++df為1，1%4不為0，不是跳躍節點，當docID = 3時，++df=4，4%4為0，為跳躍節點，然而skipData里面保存的卻是lastDocID為2。 所以真正的倒排表和跳躍表中保存一下的信息： ? |
4.2.3. 詞位置(prx)信息
詞位置信息也是倒排表，也是以跳躍表形式存在的。
- 此文件包含TermCount個項，每一個詞都有一項，因為每一個詞都有自己的詞位置倒排表。
- 對于每一個詞的都有一個DocFreq大小的數組，每項代表一篇文檔，記錄此文檔中此詞出現的位置。這個文檔數組也是和frq文件中的跳躍表有關系的，從上面我們知道，在frq的跳躍表節點中有ProxSkip，當SkipInterval為3的時候，frq的跳躍表節點指向prx文件中的此數組中的第1，第4，第7，第10，第13，第16篇文檔。
- 對于每一篇文檔，可能包含一個詞多次，因而有一個Freq大小的數組，每一項代表此詞在此文檔中出現一次，則有一個位置信息。
- 每一個位置信息包含：PositionDelta(采用差值規則)，還可以保存payload，應用或然跟隨規則。
4.3. 其他信息
4.3.1. 標準化因子文件(nrm)
為什么會有標準化因子呢？從第一章中的描述，我們知道，在搜索過程中，搜索出的文檔要按與查詢語句的相關性排序，相關性大的打分(score)高，從而排在前面。相關性打分(score)使用向量空間模型(Vector Space Model)，在計算相關性之前，要計算Term Weight，也即某Term相對于某Document的重要性。在計算Term Weight時，主要有兩個影響因素，一個是此Term在此文檔中出現的次數，一個是此Term的普通程度。顯然此Term在此文檔中出現的次數越多，此Term在此文檔中越重要。
這種Term Weight的計算方法是最普通的，然而存在以下幾個問題：
- 不同的文檔重要性不同。有的文檔重要些，有的文檔相對不重要，比如對于做軟件的，在索引書籍的時候，我想讓計算機方面的書更容易搜到，而文學方面的書籍搜索時排名靠后。
- 不同的域重要性不同。有的域重要一些，如關鍵字，如標題，有的域不重要一些，如附件等。同樣一個詞(Term)，出現在關鍵字中應該比出現在附件中打分要高。
- 根據詞(Term)在文檔中出現的絕對次數來決定此詞對文檔的重要性，有不合理的地方。比如長的文檔詞在文檔中出現的次數相對較多，這樣短的文檔比較吃虧。比如一個詞在一本磚頭書中出現了10次，在另外一篇不足100字的文章中出現了9次，就說明磚頭書應該排在前面碼？不應該，顯然此詞在不足100字的文章中能出現9次，可見其對此文章的重要性。
由于以上原因，Lucene在計算Term Weight時，都會乘上一個標準化因子(Normalization Factor)，來減少上面三個問題的影響。
標準化因子(Normalization Factor)是會影響隨后打分(score)的計算的，Lucene的打分計算一部分發生在索引過程中，一般是與查詢語句無關的參數如標準化因子，大部分發生在搜索過程中，會在搜索過程的代碼分析中詳述。
標準化因子(Normalization Factor)在索引過程總的計算如下：
它包括三個參數：
- Document boost：此值越大，說明此文檔越重要。
- Field boost：此域越大，說明此域越重要。
- lengthNorm(field) = (1.0 / Math.sqrt(numTerms))：一個域中包含的Term總數越多，也即文檔越長，此值越小，文檔越短，此值越大。
從上面的公式，我們知道，一個詞(Term)出現在不同的文檔或不同的域中，標準化因子不同。比如有兩個文檔，每個文檔有兩個域，如果不考慮文檔長度，就有四種排列組合，在重要文檔的重要域中，在重要文檔的非重要域中，在非重要文檔的重要域中，在非重要文檔的非重要域中，四種組合，每種有不同的標準化因子。
于是在Lucene中，標準化因子共保存了(文檔數目乘以域數目)個，格式如下：
- 標準化因子文件(Normalization Factor File: nrm)：
- NormsHeader：字符串“NRM”外加Version，依Lucene的版本的不同而不同。
- 接著是一個數組，大小為NumFields，每個Field一項，每一項為一個Norms。
- Norms也是一個數組，大小為SegSize，即此段中文檔的數量，每一項為一個Byte，表示一個浮點數，其中0~2為尾數，3~8為指數。
4.3.2. 刪除文檔文件(del)
- 被刪除文檔文件(Deleted Document File: .del)
- Format：在此文件中，Bits和DGaps只能保存其中之一，-1表示保存DGaps，非負值表示保存Bits。
- ByteCount：此段中有多少文檔，就有多少個bit被保存，但是以byte形式計數，也即Bits的大小應該是byte的倍數。
- BitCount：Bits中有多少位被至1，表示此文檔已經被刪除。
- Bits：一個數組的byte，大小為ByteCount，應用時被認為是byte*8個bit。
- DGaps：如果刪除的文檔數量很小，則Bits大部分位為0，很浪費空間。DGaps采用以下的方式來保存稀疏數組：比如第十，十二，三十二個文檔被刪除，于是第十，十二，三十二位設為1，DGaps也是以byte為單位的，僅保存不為0的byte，如第1個byte，第4個byte，第1個byte十進制為20，第4個byte十進制為1。于是保存成DGaps，第1個byte，位置1用不定長正整數保存，值為20用二進制保存，第2個byte，位置4用不定長正整數保存，用差值為3，值為1用二進制保存，二進制數據不用差值表示。
五、總體結構
?
- 圖示為Lucene索引文件的整體結構：
- 屬于整個索引(Index)的segment.gen，segment_N，其保存的是段(segment)的元數據信息，然后分多個segment保存數據信息，同一個segment有相同的前綴文件名。
- 對于每一個段，包含域信息，詞信息，以及其他信息(標準化因子，刪除文檔)
- 域信息也包括域的元數據信息，在fnm中，域的數據信息，在fdx，fdt中。
- 詞信息是反向信息，包括詞典(tis, tii)，文檔號及詞頻倒排表(frq)，詞位置倒排表(prx)。
大家可以通過看源代碼，相應的Reader和Writer來了解文件結構，將更為透徹。
總結
以上是生活随笔為你收集整理的Lucene学习总结之三：Lucene的索引文件格式(1)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Lucene学习总结之二：Lucene的
- 下一篇： Lucene学习总结之四：Lucene索