本文共 1730 字,大约阅读时间需要 5 分钟。
默认情况下,Elasticsearch 用 JSON 字符串来表示文档主体保存在 _source
字段中。像其他保存的字段一样,_source
字段也会在写入硬盘前压缩。The _source is stored as a binary blob (which is compressed by Lucene with deflate or LZ4) 其实就是多个_source合并到一个chunk里进行LZ4压缩!
对于Solr来说:Solr4.8.0里面使用的fdt和fdx的格式是lucene4.1的。为了提升压缩比,StoredFieldsFormat以16KB为单位对文档进行压缩,使用的压缩算法是LZ4,由于它更着眼于速度而不是压缩比,所以它能快速压缩以及解压。
具体参考Lucene41StoredFieldsFormat.html (见Lucene4.2.0的docs)
fdt文件结构:
上图理解起来也不难,<Header>和PackedIntsVersion略过,我们重点关注<Chunk>,Chunk的中文意思是”大块”,我们可以理解为数据的存储区域。在内存中表现为缓存。一个Chunk由5个部分组成:DocBase表示当前的Chunk块的起始DocId;ChunkDocs表示当前Chunk中的doc个数;DocFieldCounts是一个数组,表示每个doc中Field的个数;DocLengths也是一个数组,表示每个doc占用byte的个数,即doc的长度;<CompressedDocs>即doc的内容,用LZ4算法压缩存储。FieldNumAndType是把FieldNumber和FieldType合并到一个VLong字段里面,整个<CompressedDocs>就是FieldNumAndType和Value的交替序列。
fdx文件结构:
fdx文件重点关注的是<Block>,一个Block由三个部分组成:BlockChunks表示当前Block中Chunk的个数;<DocBases>表示当前Block中每个Chunk的doc个数,可以看作一个数组;<StartPointers>表示当前Block中每个Chunk在fdt文件中的起始位置,其结构与<DocBases>相同。
尽管fdx/fdt文件只是Lucene的正向文件,并不是Lucene的核心。但是还是有干货的。在Lucene4中引入了LZ4算法对fdt的doc进行了实时压缩/解压。而且用SPI(Service Provider Interface)技术对架构进行了重构。
fdx/fdt文件的写入操作非常清晰。逻辑上都在CompressingStoredFieldsWriter类中完成,而CompressingStoredFieldsIndexWriter则作为其成员变量。其写入的顺序与上面的格式一致,只是有些名字不一样。在写入docs的过程中,用GrowableByteArrayDataOutput作为缓存,直到缓存满了,才flush到硬盘上去。用LZ4算法压缩就是在flush时处理的。(关于LZ4算法会在另外的博文中描述)
fdt文件的基本单位是Chunk,这一点需要牢记。一个Chunk写入到文件中的代码如下:
通过观察flush函数,我们会发现fdt文件的写入非常简单,就两句代码:
前面一句代码记录整个chunk中的docBase(最小docID),numBufferedDocs(doc数量),numStoredFields(每个doc的Field个数),lengths(每个doc的长度),一共四种信息.在记录numStoredFields和lengths时,用PackedInts及其它的方式对内容进行了压缩。后面一句代码记录整个chunk中的doc的完整内容(用LZ4算法进行压缩).
本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/7724285.html,如需转载请自行联系原作者