Lucene 源码剖析 五 索引文件结构(4)

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

        
结构如下图所示：        
 

 

  

    

     

    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则没有大小限制。