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