转载自 http://download.csdn.net/source/858994
源地址下是 Word 文档，这里转换成HTML 格式
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则没有大小限制。
