Annotated Lucene：第三节 索引文件结构(8)
3.2.3.8 删除的文档 （.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 局限性（Limitations）
有几个地方这些文件格式会让terms和文档的最大数目受限于32-bit的大小，大约最大40亿。这在今天不是一个问题，长远来看（in the long term）可能会成为个问题。因此它们应该替换为UInt64类型或者更好的类型，如VInt则没有大小限制。
