Lucene 源码剖析 五 索引文件结构(4)
2010-07-08 16:31
309 查看
3.3.6Term向量文件
Term向量(vector)的支持是field基本组成中对一个field来说的可选项,它包含如下4种文件:
1. 文档索引或.tvx文件:对每个文档来说,它把偏移(offset)存储进文档数据(.tvd)文件和域field数据(.tvf)文件
结构如下图所示:
2. 文档或.tvd文件:对每个文档来说,它包含fields的数目,有term向量的fields的列表,还有指向term向量域文件(.tvf)中的域信息的指针列表。该文件用于映射(map out)出那些存储了term向量的fields,以及这些field信息在.tvf文件中的位置。
结构如下图所示:
3. 域field或.tvf文件:对每个存储了term向量的field来说,该文件包含了一个term的列表,及它们的频率,还有可选的位置和偏移信息。
结构如下图所示:
备注:
l Positions/Offsets 字节存储的条件是当该term向量含有存储的位置或偏移信息时。
l Term Text prefixes文本前缀是共享的,表示根据前一个term的文本来初始化的字符串前缀长度,前一个term必须已经预设成后缀文本以便构成该term的文本。比如,如果前一个term为“bone”,而当前term为“boy”,则该PrefixLength值为2,suffix值为“y”。
l Positions存储为Delta编码的VInts,意思是我们只能存储当前位置与最后位置的差值。
l Offsets存储为Delta编码的VInts,第一个VInt是startOffset,第二个VInt是endOffset。
3.3.7删除的文档 (.del)
删除的文档(.del)文件是可选的,而且仅当一个segment存在有被删除的文档时才存在。即使对每一单个segment,它也是维护复合segment的外部数据(exterior)。
对Lucene 2.1及以前版本,它的格式为:Deletions (.del) –> ByteCount,BitCount,Bits
对2.2及以上版本,格式如下:
结构如下图所示:
举例来说,如果有8000 bits,并且只有bits 10, 12, 32 被设置,DGaps将会存储如下数据:
(VInt) 1 , (byte) 20 , (VInt) 3 , (Byte) 1
3.3.8局限性(Limitations)
有几个地方这些文件格式会让terms和文档的最大数目受限于32-bit的大小,大约最大40亿。这在今天不是一个问题,长远来看(in the long term)可能会成为个问题。因此它们应该替换为UInt64类型或者更好的类型,如VInt则没有大小限制。
Term向量(vector)的支持是field基本组成中对一个field来说的可选项,它包含如下4种文件:
1. 文档索引或.tvx文件:对每个文档来说,它把偏移(offset)存储进文档数据(.tvd)文件和域field数据(.tvf)文件
版本 | 包含的项 | 数目 | 类型 | 描述 |
全部版本 | TVXVersion | 1 | Int | 在Lucene 2.4中为3 (TermVectorsReader.FORMAT_VERSION2) |
DocumentPosition | NumDocs | UInt64 | 在.tvd文件中的偏移 | |
FieldPosition | NumDocs | UInt64 | 在.tvf文件中的偏移 |
2. 文档或.tvd文件:对每个文档来说,它包含fields的数目,有term向量的fields的列表,还有指向term向量域文件(.tvf)中的域信息的指针列表。该文件用于映射(map out)出那些存储了term向量的fields,以及这些field信息在.tvf文件中的位置。
版本 | 包含的项 | 数目 | 类型 | 描述 |
全部版本 | TVDVersion | 1 | Int | 在Lucene 2.4中为3 (TermVectorsReader.FORMAT_VERSION2) |
NumFields | NumDocs | VInt | ||
FieldNums | NumDocs | FieldNums | ||
FieldNums->FieldNumDelta | NumFields | VInt | ||
FieldPositions | NumDocs | FieldPositions | ||
FieldPositions->FieldPositionDelta | NumField-1 | VLong |
3. 域field或.tvf文件:对每个存储了term向量的field来说,该文件包含了一个term的列表,及它们的频率,还有可选的位置和偏移信息。
版本 | 包含的项 | 数目 | 类型 | 描述 |
全部版本 | TVFVersion | 1 | Int | 在Lucene 2.4中为3 (TermVectorsReader.FORMAT_VERSION2) |
NumTerms | NumFields | VInt | ||
Position/Offset | NumFields | Byte | ||
TermFreqs | NumFields | TermFreqs | ||
TermFreqs->TermText | NumTerms | TermText | ||
TermText->PrefixLength | NumTerms | VInt | ||
TermText->Suffix | NumTerms | String | ||
TermFreqs->TermFreq | NumTerms | VInt | ||
TermFreqs->Positions? | NumTerms | Positions | ||
Positions->Position | TermFreq | VInt | ||
TermFreqs->Offsets? | NumTerms | Offsets | ||
Offsets->StartOffset | TermFreq | VInt | ||
Offsets->EndOffset | TermFreq | VInt |
备注:
l Positions/Offsets 字节存储的条件是当该term向量含有存储的位置或偏移信息时。
l Term Text prefixes文本前缀是共享的,表示根据前一个term的文本来初始化的字符串前缀长度,前一个term必须已经预设成后缀文本以便构成该term的文本。比如,如果前一个term为“bone”,而当前term为“boy”,则该PrefixLength值为2,suffix值为“y”。
l Positions存储为Delta编码的VInts,意思是我们只能存储当前位置与最后位置的差值。
l Offsets存储为Delta编码的VInts,第一个VInt是startOffset,第二个VInt是endOffset。
3.3.7删除的文档 (.del)
删除的文档(.del)文件是可选的,而且仅当一个segment存在有被删除的文档时才存在。即使对每一单个segment,它也是维护复合segment的外部数据(exterior)。
对Lucene 2.1及以前版本,它的格式为:Deletions (.del) –> ByteCount,BitCount,Bits
对2.2及以上版本,格式如下:
版本 | 包含的项 | 数目 | 类型 | 描述 |
2.2之后版本 | [Format] | 1 | UInt32 | 可选,-1表示为DGaps,非负数(negative)值表示为Bit,并且此时不存储Format |
ByteCount | 1 | UInt32 | 代表Bit里的字节数目,而且一般值为(SegSize/8)+1 | |
BitCount | 1 | UInt32 | 表示Bit里当前设置的字节数目 | |
Bit|DGaps | 1 | Bit还是DGaps取决于Format。Bits中对每一个索引的文档均包含一个字节,当一个bit对应的一个文档编号被设置时,表示该文档被删除。Bit从最低(least)到最重要(significant)的文档排序。所以Bits包含两个字节,0×00和0×02,则文档9被标记为删除。DGaps表示松散(sparse)的bit-vector向量比Bits更有效率(efficiently)。DGaps由索引中非0的Bits位生成,以及非0的字节数据本身。Bits中非0字节数目(NonzeroBytesCoun)不会存储。 | ||
Bit->Byte | ByteCount | Byte | ||
DGaps->DGap | NonzeroBytesCount | VInt | ||
DGaps-> NonzeroBytes | NonzeroBytesCount | Byte |
举例来说,如果有8000 bits,并且只有bits 10, 12, 32 被设置,DGaps将会存储如下数据:
(VInt) 1 , (byte) 20 , (VInt) 3 , (Byte) 1
3.3.8局限性(Limitations)
有几个地方这些文件格式会让terms和文档的最大数目受限于32-bit的大小,大约最大40亿。这在今天不是一个问题,长远来看(in the long term)可能会成为个问题。因此它们应该替换为UInt64类型或者更好的类型,如VInt则没有大小限制。
相关文章推荐
- Lucene 源码剖析 二 索引文件结构(1)
- Lucene 源代码剖析-6 索引文件结构(3)
- Lucene 源代码剖析-7 索引文件结构(4)
- jQuery源码剖析-框架结构简述
- jdk源码剖析一:OpenJDK-Hotspot源码包目录结构
- Lucene 源代码剖析-4 索引文件结构(1)
- Lucene 源码剖析 六
- Solr4.8.0源码分析(8)之Lucene的索引文件(1)
- Redis源码剖析--源码结构解析
- caffe源码剖析(一)--整体目录结构
- Lucene 源码剖析-转载
- Nodejs事件引擎libuv源码剖析之:请求(request)结构的设计剖析
- Lucene 源码剖析 七
- beanstalk源码剖析——文件结构和启动程序
- Redis源码剖析(三)字典结构的设计与实现
- vxworks源码剖析- 数据结构篇一(双向链表)-转
- MFC单文档/视图结构源码剖析
- 开放源代码的全文检索引擎Lucene――介绍、系统结构与源码实现分析
- Redis源码剖析--源码结构解析
- Lucene 源码剖析 八