Lucene的索引文件格式Word格式.docx
《Lucene的索引文件格式Word格式.docx》由会员分享，可在线阅读，更多相关《Lucene的索引文件格式Word格式.docx（42页珍藏版）》请在冰豆网上搜索。
o不同域的索引方式可以不同，在真正解析域的存储的时候，我们会详细解读。
∙词（Term）：
o词是索引的最小单位，是经过词法分析和语言处理后的字符串。
Lucene的索引结构中，即保存了正向信息，也保存了反向信息。
所谓正向信息：
∙按层次保存了从索引，一直到词的包含关系：
索引（Index）–>
段（segment）–>
文档（Document）–>
域（Field）–>
词（Term）
∙也即此索引包含了那些段，每个段包含了那些文档，每个文档包含了那些域，每个域包含了那些词。
∙既然是层次结构，则每个层次都保存了本层次的信息以及下一层次的元信息，也即属性信息，比如一本介绍中国地理的书，应该首先介绍中国地理的概况，以及中国包含多少个省，每个省介绍本省的基本概况及包含多少个市，每个市介绍本市的基本概况及包含多少个县，每个县具体介绍每个县的具体情况。
∙如上图，包含正向信息的文件有：
osegments_N保存了此索引包含多少个段，每个段包含多少篇文档。
oXXX.fnm保存了此段包含了多少个域，每个域的名称及索引方式。
oXXX.fdx，XXX.fdt保存了此段包含的所有文档，每篇文档包含了多少域，每个域保存了那些信息。
oXXX.tvx，XXX.tvd，XXX.tvf保存了此段包含多少文档，每篇文档包含了多少域，每个域包含了多少词，每个词的字符串，位置等信息。
所谓反向信息：
∙保存了词典到倒排表的映射：
词（Term）–>
文档（Document）
∙如上图，包含反向信息的文件有：
oXXX.tis，XXX.tii保存了词典（TermDictionary），也即此段包含的所有的词按字典顺序的排序。
oXXX.frq保存了倒排表，也即包含每个词的文档ID列表。
oXXX.prx保存了倒排表中每个词在包含此词的文档中的位置。
在了解Lucene索引的详细结构之前，先看看Lucene索引中的基本数据类型。
二、基本类型
Lucene索引文件中，用一下基本类型来保存信息：
∙Byte：
是最基本的类型，长8位（bit）。
∙UInt32：
由4个Byte组成。
∙UInt64：
由8个Byte组成。
∙VInt：
o变长的整数类型，它可能包含多个Byte，对于每个Byte的8位，其中后7位表示数值，最高1位表示是否还有另一个Byte，0表示没有，1表示有。
o越前面的Byte表示数值的低位，越后面的Byte表示数值的高位。
o例如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在反向索引中，要保存词典（TermDictionary）的信息，所有的词（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原来的值。
如果去读ApacheLucene-IndexFileFormats这篇文章，会发现很多符合这种规则的：
∙.frq文件中的DocDelta[,Freq?
]，DocSkip,PayloadLength?
∙.prx文件中的PositionDelta,Payload?
（但不完全是，如下表分析）
当然还有一些带?
的但不属于此规则的：
∙.frq文件中的SkipChildLevelPointer?
，是多层跳跃表中，指向下一层表的指针，当然如果是最后一层，此值就不存在，也不需要标志。
∙.tvf文件中的Positions?
Offsets?
o在此类情况下，带?
的值是否存在，并不取决于前面的值的最后一位。
o而是取决于Lucene的某项配置，当然这些配置也是保存在Lucene索引文件中的。
o如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存在时，格式应该变成如下：
PositionDelta,PayloadLength?
从而PositionDelta和PayloadLength一起适用或然跟随规则。
4.跳跃表规则（Skiplist）
为了提高查找的性能，Lucene在很多地方采取的跳跃表的数据结构。
跳跃表（SkipList）是如图的一种数据结构，有以下几个基本特征：
∙元素是按顺序排列的，在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在具体实现上，与理论又有所不同，在具体的格式中，会详细说明。
四、具体格式
上面曾经交代过，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。
∙
IndexInputgenInput=directory.openInput（IndexFileNames.SEGMENTS_GEN）;
//"
segments.gen"
intversion=genInput.readInt（）;
//读出版本号
if（version==FORMAT_LOCKLESS）{//如果版本号正确
longgen0=genInput.readLong（）;
//读出第一个N
longgen1=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：
o索引文件格式的版本号。
o由于Lucene是在不断开发过程中的，因而不同版本的Lucene，其索引文件格式也不尽相同，于是规定一个版本号。
oLucene2.1此值-3，Lucene2.9时，此值为-9。
o当用某个版本号的IndexReader读取另一个版本号生成的索引的时候，会因为此值不同而报错。
∙Version：
o索引的版本号，记录了IndexWriter将修改提交到索引文件中的次数。
o其初始值大多数情况下从索引文件里面读出，仅仅在索引开始创建的时候，被赋予当前的时间，已取得一个唯一值。
o其值改变在IndexWmit->
IndexWriter.startCommit->
SegmentInfos.prepareCommit->
SegmentInfos.write->
writeLong（++version）
o其初始值之所最初取一个时间，是因为我们并不关心IndexWriter将修改提交到索引的具体次数，而更关心到底哪个是最新的。
IndexReader中常比较自己的version和索引文件中的version是否相同来判断此IndexReader被打开后，还有没有被IndexWriter更新。
//在DirectoryReader中有一下函数。
publicbooleanisCurrent（）throwsCorruptIndexException,IOException{
returnSegmentInfos.readCurrentVersion（directory）==segmentInfos.getVersion（）;
∙NameCount
o是下一个新段（Segment）的段名。
o所有属于同一个段的索引文件都以段名作为文件名，一般为_0.xxx,_0.yyy,
_1.xxx,_1.yyy……
o新生成的段的段名一般为原有最大段名加一。
o如同的索引，NameCount读出来是2，说明新的段为_2.xxx,_2.yyy
∙SegCount
o段（Segment）的个数。
o如上图，此值为2。
∙SegCount个段的元数据信息：
oSegName
▪段名，所有属于同一个段的文件都有以段名作为文件名。
▪如上图，第一个段的段名为"
，第二个段的段名为"
oSegSize
▪此段中包含的文档数
▪然而此文档数是包括已经删除，又没有optimize的文档的，因为在optimize之前，Lucene的段中包含了所有被索引过的文档，而被删除的文档是保存在.del文件中的，在搜索的过程中，是先从段中读到了被删除的文档，然后再用.del中的标志，将这篇文档过滤掉。
▪如下的代码形成了上图的索引，可以看出索引了两篇文档形成了_0段，然后又删除了其中一篇，形成了_0_1.del，又索引了两篇文档形成_1段，然后又删除了其中一篇，形成_1_1.del。
因而在两个段中，此值都是2。
IndexWriterwriter=newIndexWriter（FSDirectory.open（INDEX_DIR）,newStandardAnalyzer（Version.LUCENE_CURRENT）,true,IndexWriter.MaxFieldLength.LIMITED）;
writer.setUseCompoundFile（false）;
indexDocs（writer,docDir）;
//docDir中只有两篇文档
//文档一为：
Studentsshouldbeallowedtogooutwiththeirfriends,butnotallowedtodrinkbeer.
//文档二为：
MyfriendJerrywenttoschooltoseehisstudentsbutfoundthemdrunkwhichisnotallowed.
mit（）;
//提交两篇文档，形成_0段。
writer.deleteDocuments（newTerm（"
contents"
"
school"
））;
//删除文档二
//提交删除，形成_0_1.del
//再次索引两篇文档，Lucene不能判别文档与文档的不同，因而算两篇新的文档。
//提交两篇文档，形成_1段
//删除第二次添加的文档二
writer.close（）;
//提交删除，形成_1_1.de
oDelGen
▪.del文件的版本号
▪Lucene中，在optimize之前，删除的文档是保存在.del文件中的。
▪在Lucene2.9中，文档删除有以下几种方式：
▪IndexReader.deleteDocument（intdocID）是用IndexReader按文档号删除。
▪IndexReader.deleteDocuments（Termterm）是用IndexReader删除包含此词（Term）的文档。
▪IndexWriter.deleteDocuments（Termterm）是用IndexWriter删除包含此词（Term）的文档。
▪IndexWriter.deleteDocuments（Term[]terms）是用IndexWriter删除包含这些词（Term）的文档。
▪IndexWriter.deleteDocuments（Queryquery）是用IndexWriter删除能满足此查询（Query）的文档。
▪IndexWriter.deleteDocuments（Query[]queries）是用IndexWriter删除能满足这些查询（Query）的文档。
▪原来的版本中Lucene的删除一直是由IndexReader来完成的，在Lucene2.9中虽可以用IndexWriter来删除，但是其实真正的实现是在IndexWriter中，保存了readerpool，当IndexWriter向索引文件提交删除的时候，仍然是从readerpool中得到相应的IndexReader，并用IndexReader来进行删除的。
下面的代码可以说明：
IndexWriter.applyDeletes（）
->
DocumentsWriter.applyDeletes（SegmentInfos）
->
reader.deleteDocument（doc）
o
▪
▪DelGen是每
升级会员 