Lucene文件格式

生成的文件如下:
_21.f1,_21.f2,依次类推,扩展名根据文件排序;
_21.fdt;
_21.fdx; *.fdt和*.fdx构成了域值存储表;
_21.fnm; 记录了域集合信息;
_21.frq; 记录了项的位置;
_21.prx; 记录了项频数;
_21.tii;
_21.tis; *.tii和*.tis构成了项字典;
segment1.nrm 记录了标准化因子;
segment1.del 记录了本删除的文档;
segments(无扩展名) 用来保存所有的段的记录;
deletable(无扩展名) 用来保存已删除文件的记录
lock(无扩展名) 用来控制读写的同步

Lucene索引index由若干段(segment)组成,每一段由若干的文档(document)组成,每一个文档由若干的域(field)组成,每一个域由若干的项(term)组成。
项是最小的索引概念单位,它直接代表了一个字符串以及其在文件中的位置、出现次数等信息。
域是一个关联的元组,由一个域名和一个域值组成,域名是一个字串,域值是一个项,比如将“标题”和实际标题的项组成的域。
文档是提取了某个文件中的所有信息之后的结果,这些组成了段,或者称为一个子索引。子索引可以组合为索引,也可以合并为一个新的包含了所有合并项内部元素的子索引。我们可以清楚的看出,Lucene的索引结构在概念上即为传统的倒排索引结构。
从概念上映射到结构中,索引被处理为一个目录(文件夹),其中含有的所有文件即为其内容,这些文件按照所属的段不同分组存放,同组的文件拥

有相同的文件名,不同的扩展名。此外还有三个文件,分别用来保存所有的段的记录、保存已删除文件的记录和控制读写的同步,它们分别是segments,deletable和lock文件,都没有扩展名。每个段包含一组文件,它们的文件扩展名不同,但是文件名均为记录在文件segments中段的名字每个段的文件中,主要记录了两大类的信息：域集合与项集合。由于索引信息是静态存储的,域集合与项集合中的文件组采用了一种类似的存储办法：一个小型的索引文件,运行时载入内存；一个对应于索引文件的实际信息文件,可以按照索引中指示的偏移量随机访问；索引文件与信息文件在记录的排列顺序上存在隐式的对应关系,即索引文件中按照“索引项1、索引项2…”排列,则信息文件则也按照“信息项1、信息项2…”排列。比如在图3.2所示文件中,segment1.fdx与segment1.fdt之间,segment1.tii与segment1.tis、segment1.prx、segment1.frq之间,都存在这样的组织关系。而域集合与项集合之间则通过域的在域记录文件(比如segment1.fnm)中所记录的域记录号维持对应关系,segment1.fdx与segment1.tii中就是通过这种方式保持联系。这样,域集合和项集合不仅仅联系起来,而且其中的文件之间也相互联系起来。此外,标准化因子文件和被删除文档文件则提供了一些程序内部的辅助设施(标准化因子用在评分排序机制中,被删除文档是一种伪删除手段)。这样,整个段的索引信息就通过这些文档有机的组成。 以上所阐述的,就是Lucene所采用的索引文件格式。基本上而言,它是一个倒排索引,但是Lucene在文件的安排上做了一些努力,比如使用索引/信息文件的方式,从文件安排的形式上提高查找的效率。这是一种数据库之外的处理方法,其有其优点(格式平台独立、速度快),也有其缺点(独立性带来的共享访问接口问题等等),

 

 

segments文件，用来表示索引文件的名字和Document的个数。

文件头中的第1个4Byte是SegmentName，在Lucene中，SegmentName是一个16进制的数字，是上面的如*.fnm中的*部分，每新增加一个Document，SegmentName会加1（做的是SegmentName++的动作），所以此部分的值会比实际的SegmentName大1。
文件头中的第2个4Byte是索引文件的个数，Lucene支持在一个目录中存放多个索引文件（这一部分我也不是十分清楚，不知道哪位大哥可以解惑）。
文件体中 是一个可重复的部分，重复的次数由文件头中的第2部分的大小决定。
可重复的部分包括2个部分：SegmentName和该索引文件中包含的Document个数。（从这里可以看出，在Lucene中，单个索引文件最多可以包含2的32方个文件（4个byte）

*.frm文件，用来保存FieldName，注意，此文件只保存非切分部分的Field，如通过Filed.text()方法进行切分后的Field保存在*.tii, *.tis中。
文件头中的FieldNum代表索引的Field的个数。
文件体中描述每个Field的信息，个数与文件体中的FieldNum相同。
每个Field的信息包括2个部分：FieldName，索引的Field的名字，Flag表示该Field是否是索引的（indexed）。0x00表示未索引，0x01表示索引。

 

 *.fdt文件，用于存放Field的值，每个Document是连续存放的，

头部中的FieldNum是该Document中选择了存储的Field的个数（field.isStroed()==true），
内容体中每个Filed中包括3个部分。
Pos：该Field在Document的顺序，是第几个Field
Flag：该Field是否是一个Token（field.isToken()==true），）0x00，否  0x01 是
Value：该Field的值

 

*.fdx文件，用于存放每个Document在fdt文件中的偏移。

 

*.tis文件，用于存放切分过的Field中的值。

文件头中的TermNum是一个4byte的Int，代表Term的个数
文件体是每个Term的重复。每个Term包括7个域。
Start：该Term的偏移
Content：该Term的值
FieldPos：该Term出现的顺序，即是第几个Field
Freq：该Term出现的频率
FreqPointer：Rreq在*.frq文件中的偏移
ProxPointer：Prox在*.prx文件中的偏移

 

 

lucene倒排索引原理:

Lucene是一个高性能的java全文检索工具包，它使用的是倒排文件索引结构。该结构及相应的生成算法如下：

0）设有两篇文章1和2
文章1的内容为：Tom lives in Guangzhou,I live in Guangzhou too.
文章2的内容为：He once lived in Shanghai.

1)由于lucene是基于关键词索引和查询的，首先我们要取得这两篇文章的关键词，通常我们需要如下处理措施
a.我们现在有的是文章内容，即一个字符串，我们先要找出字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理。
b.文章中的”in”, “once” “too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉
c.用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。
d.用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live”
e.文章中的标点符号通常不表示某种概念，也可以过滤掉
在lucene中以上措施由Analyzer类完成

经过上面处理后
文章1的所有关键词为：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有关键词为：[he] [live] [shanghai]

2) 有了关键词后，我们就可以建立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。文章1，2经过倒排后变成
关键词 文章号
guangzhou 1
he 2
i 1
live 1,2
shanghai 2
tom 1

通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：a)字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；b)关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene中记录的就是这种位置。

加上“出现频率”和“出现位置”信息后，我们的索引结构变为：
关键词 文章号[出现频率] 出现位置
guangzhou 1[2] 3，6
he 2[1] 1
i 1[1] 4
live 1[2],2[1] 2，5，2
shanghai 2[1] 3
tom 1[1] 1

以live 这行为例我们说明一下该结构：live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2,5,2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2,5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第 2个关键字。

以上就是lucene索引结构中最核心的部分。我们注意到关键字是按字符顺序排列的（lucene没有使用B树结构），因此lucene可以用二元搜索算法快速定位关键词。

实现时 lucene将上面三列分别作为词典文件（Term Dictionary）、频率文件(frequencies)、位置文件 (positions)保存。其中词典文件不仅保存有每个关键词，还保留了指向频率文件和位置文件的指针，通过指针可以找到该关键字的频率信息和位置信息。

Lucene中使用了field的概念，用于表达信息所在位置（如标题中，文章中，url中），在建索引中，该field信息也记录在词典文件中，每个关键词都有一个field信息(因为每个关键字一定属于一个或多个field)。

为了减小索引文件的大小，Lucene对索引还使用了压缩技术。首先，对词典文件中的关键词进行了压缩，关键词压缩为<前缀长度，后缀>，例如：当前词为“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压缩为<3，语>。其次大量用到的是对数字的压缩，数字只保存与上一个值的差值（这样可以减小数字的长度，进而减少保存该数字需要的字节数）。例如当前文章号是16389（不压缩要用3个字节保存），上一文章号是16382，压缩后保存7（只用一个字节）。

下面我们可以通过对该索引的查询来解释一下为什么要建立索引。
假设要查询单词 “live”，lucene先对词典二元查找、找到该词，通过指向频率文件的指针读出所有文章号，然后返回结果。词典通常非常小，因而，整个过程的时间是毫秒级的。
而用普通的顺序匹配算法，不建索引，而是对所有文章的内容进行字符串匹配，这个过程将会相当缓慢，当文章数目很大时，时间往往是无法忍受的。

Lucene是一个高性能的java全文检索工具包，它使用的是倒排文件索引结构。该结构及相应的生成算法如下：

0）设有两篇文章1和2
文章1的内容为：Tom lives in Guangzhou,I live in Guangzhou too.
文章2的内容为：He once lived in Shanghai.

1)由于lucene是基于关键词索引和查询的，首先我们要取得这两篇文章的关键词，通常我们需要如下处理措施
a.我们现在有的是文章内容，即一个字符串，我们先要找出字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理。
b.文章中的”in”, “once” “too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉
c.用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。
d.用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live”
e.文章中的标点符号通常不表示某种概念，也可以过滤掉
在lucene中以上措施由Analyzer类完成

经过上面处理后
文章1的所有关键词为：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有关键词为：[he] [live] [shanghai]

2) 有了关键词后，我们就可以建立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。文章1，2经过倒排后变成
关键词 文章号
guangzhou 1
he 2
i 1
live 1,2
shanghai 2
tom 1

通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：a)字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；b)关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene中记录的就是这种位置。

加上“出现频率”和“出现位置”信息后，我们的索引结构变为：
关键词 文章号[出现频率] 出现位置
guangzhou 1[2] 3，6
he 2[1] 1
i 1[1] 4
live 1[2],2[1] 2，5，2
shanghai 2[1] 3
tom 1[1] 1

以live 这行为例我们说明一下该结构：live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2,5,2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2,5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第 2个关键字。

以上就是lucene索引结构中最核心的部分。我们注意到关键字是按字符顺序排列的（lucene没有使用B树结构），因此lucene可以用二元搜索算法快速定位关键词。

实现时 lucene将上面三列分别作为词典文件（Term Dictionary）、频率文件(frequencies)、位置文件 (positions)保存。其中词典文件不仅保存有每个关键词，还保留了指向频率文件和位置文件的指针，通过指针可以找到该关键字的频率信息和位置信息。

Lucene中使用了field的概念，用于表达信息所在位置（如标题中，文章中，url中），在建索引中，该field信息也记录在词典文件中，每个关键词都有一个field信息(因为每个关键字一定属于一个或多个field)。

为了减小索引文件的大小，Lucene对索引还使用了压缩技术。首先，对词典文件中的关键词进行了压缩，关键词压缩为<前缀长度，后缀>，例如：当前词为“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压缩为<3，语>。其次大量用到的是对数字的压缩，数字只保存与上一个值的差值（这样可以减小数字的长度，进而减少保存该数字需要的字节数）。例如当前文章号是16389（不压缩要用3个字节保存），上一文章号是16382，压缩后保存7（只用一个字节）。

下面我们可以通过对该索引的查询来解释一下为什么要建立索引。
假设要查询单词 “live”，lucene先对词典二元查找、找到该词，通过指向频率文件的指针读出所有文章号，然后返回结果。词典通常非常小，因而，整个过程的时间是毫秒级的。
而用普通的顺序匹配算法，不建索引，而是对所有文章的内容进行字符串匹配，这个过程将会相当缓慢，当文章数目很大时，时间往往是无法忍受的。