标签：src numa bsp http 需要 docid point interface solr4
默认情况下，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算法进行压缩).
lucene LZ4 会将doc存储在一个chunk里进行Lz4压缩 ES的_source便如此
标签：src numa bsp http 需要 docid point interface solr4
原文地址：http://www.cnblogs.com/bonelee/p/7724285.html
