Lucene4.2源码解析之fdt和fdx文件的读写(续)——fdx文件存储一个个的Block，每个Block管理着一批Chunk，通过docID读取到document需要完成Segment、Bloc...

2       索引读取阶段

  当希望通过一个DocId得到Doc的全部内容，那么就需要对fdx/fdt文件进行读操作了。具体的代码在CompressingStoredFieldsReader类里面。与CompressingStoredFieldsWriter一样，这些操作都是建立在fdx/fdt文件格式理解的基础上。

       既然前面有一个比喻：如果fdt是一本书的正文，那么fdx则是书的目录。那么通过docID来得到doc全部内容的这个过程则是需要两个文件联合起来发挥作用。

       具体的过程如下：

第一步：在CompressingStoredFieldsIndexReader的构造函数中加载所有的”目录信息”

 

第二步：确定docID所在Segment，由于starts数组记录了每个Segment的docID的起始值，所以通过二分查找，很快就能定位到对应的Segment.并进入到相应的SegmentReader去读取doc内容。

通过docID确定所在Segment

第三步：确定docID所在的Block

 

第四步：确定docID所在的Chunk

第五步：根据docID确定的Chunk找到chunk在fdt文件中的起始位置

第六步：读取fdt文件中的Chunk信息，通过<DocLengths>和给定的docID确定整个Chunk存储的所有doc的总长度totalLength和从baseDoc到docID的doc长度length。并用LZ4解压Chunk中的doc内容。当然，并不需要整个chunk的doc都解压，只需要解压到length的长度就可以了。

得到length和totalLength后，就可以解压了。并读取解压后文本的内容，生成Document

 

这样的话，就通过docID得到了存储到索引中document的所有内容了。

3       总结

fdx/fdt文件不涉及Lucene的核心，只是对索引内容本身的读写操作。而且fdx/fdt的文件格式相当简单明了：fdt文件存储着一个个的Chunk；fdx文件存储一个个的Block，每个Block管理着一批Chunk 。

fdt/fdx在Lucene中最有价值的地方在于：

1、给定一个DocId，如何快速还原一个Document。

2、索引内容本身的实时压缩/解压，也就是LZ4算法。这其实是为上一条服务。

3、通过SPI机制，允许用户自定义存储格式。这是Lucene在架构上面的进步。

通过这个过程的解析，也能了解到通过docID读取到document需要完成Segment、Block、Chunk、document四级查询。Segment、Block、Chunk的查找都是二分查找，速度很快，但是Chunk中定位document则是顺序查找，所以Chunk的大小直接影响着读取的性能。

 

转载于:https://www.cnblogs.com/bonelee/p/6395215.html