Lucene 源代码剖析-5 索引文件结构(4)

阅读更多
Lucene 源码剖析

 

 

 

 

3.3.6 Term向量文件

     
 

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文件中的偏移

        
结构如下图所示:        
 

 

Lucene 源代码剖析-5 索引文件结构(4)_第1张图片  

    

     

    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

 

        
结构如下图所示:        
 

 

Lucene 源代码剖析-5 索引文件结构(4)_第2张图片         

    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

 

        
结构如下图所示:        
 

 

Lucene 源代码剖析-5 索引文件结构(4)_第3张图片         

备注:


 

l Positions/Offsets 字节存储的条件是当该term向量含有存储的位置或偏移信息时。
 l Term Text prefixes文本前缀是共享的,表示根据前一个term的文本来初始化的字符串前缀长度,前一个term必须已经预设成后缀文本以便构成该term的文本。比如,如果前一个term为“bone”,而当前term为“boy”,则该PrefixLength值为2suffix值为“y”。
 l Positions存储为Delta编码的VInts,意思是我们只能存储当前位置与最后位置的差值。
 l Offsets存储为Delta编码的VInts,第一个VIntstartOffset,第二个VIntendOffset    
         

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取决于FormatBits中对每一个索引的文档均包含一个字节,当一个bit对应的一个文档编号被设置时,表示该文档被删除。Bit从最低(least)到最重要(significant)的文档排序。所以Bits包含两个字节,0×000×02,则文档9被标记为删除。DGaps表示松散(sparse)的bit-vector向量比Bits更有效率(efficiently)。DGaps由索引中非0Bits位生成,以及非0的字节数据本身。Bits中非0字节数目(NonzeroBytesCoun)不会存储。

Bit->Byte

ByteCount

Byte

 

DGaps->DGap

NonzeroBytesCount

VInt

 

DGaps-> NonzeroBytes

NonzeroBytesCount

Byte

 

  

     
 

结构如下图所示:  

     
 

    

 

Lucene 源代码剖析-5 索引文件结构(4)_第4张图片  

     
 

举例来说,如果有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则没有大小限制。  

http://www.cnblogs.com/eaglet/archive/2009/02/16/1391502.html

你可能感兴趣的:(Lucene)