Lucene中使用高效压缩来压缩stored fields

       fields存储在磁盘上，一切运行的很好，直到你的数据对于I/O缓存来说变得太大。在那之前，大多数磁盘访问实际上从来没有接触磁盘读取或写入，因此他如同访问内存一样快。你的数据变得太大，一切会突然变得非常慢。一旦数据变得那么大，有三种选择：要么你发现技术，以减少磁盘寻道（通常是通过加载在内存中的一些数据和/或更加依赖于顺序存取），买更多的RAM或更好的磁盘（SSD），但是性能依然会降低如果你的数据保持增长。

如果你有一个Lucene索引与一些storedfields，我不会感到惊讶，索引的大小大多数由FDT文件决定。例如，当从维基百科转储文件索引10M 麦克夜间基准麦坎德利斯，FDT文件的占索引大小的69.3％。

。FDT是Lucene的storedfields于两个存储文件扩展名之一。你可以阅读更多关于它们是如何工作在Lucene40StoredFieldsFormat的文档。重要的是要知道的是，从磁盘中加载文档需要两个磁盘寻道：

§  一个字段索引文件（FDX），

§  的字段中的数据文件（FDT）。

字段索引文件通常比较小（约8 * maxDoc字节），I / O缓存应该是能够为大多数磁盘寻求在这个文件中。然而field数据文件往往是大得多，因此寻求在这个文件中更容易转化为实际的磁盘寻求。在最坏的情况下，寻求在这个文件的目的，如果你的搜索引擎结果每页显示p转化为实际的磁盘，它不会是能够处理超过100 /第每秒请求（因为磁盘寻求对商品硬盘〜10毫秒）。其结果是这个文件的I / O缓存的命中率是非常重要的，您所查询的吞吐量。其中一个选项，以提高I / O的缓存命中率是压缩领域数据文件存储字段，以便较小的整体。

最多Lucene的2.9版本中，有一个选项来压缩存储领域，但它已被弃用，然后删除（见LUCENE-652获取更多信息）。在新版本中，用户仍然可以压缩文件，但有许多工作要做。然而，问题仍然是相同的：如果您使用的是小field，大多数的压缩算法是低效的。为了解决这个问题，ElasticSearch 0.19.5引入存储级别压缩：压缩大容量（64KB）固定大小的块数据，而不是单一的field，以提高压缩比。这可能是最好的方式来压缩小文档在Lucene 3.6版本中。

幸运的是，Lucene的4.0引入了灵活的索引，它可以让你定制Lucene的低层次的行为，尤其是索引文件格式。使用Lucene的4226，Lucene的得到了一个新的StoredFieldsFormat的高效压缩存储领域的。处理压缩编解码器相比ElasticSearch做了一些优化：

§  块可以有可变大小，使文件从来没有横跨两个块（所以，从磁盘中加载文档不需要解压缩多个块），

§  足够多的数据已经解压缩，解压缩，

§  需要更少的内存。

Lucene40StoredFieldsFormat vs CompressingStoredFieldsFormat

为了确保它真的是一场胜利来压缩stored fields，我跑了几个大型索引基准：

§  10M的文件，

§  每个文档有4个stored fields：

§  一个ID（几个字节），

§  标题（几个字节），

§  日期（几个字节），

§  一个机构（1KB）。

CompressingStoredFieldsFormat已经被实例化使用以下参数：

§  压缩模式= FAST（快速压缩及解压缩速度快，但高压缩比，使用LZ4引擎盖下）

§  CHUNKSIZE = 16K（意味着数据会被压缩成块〜16KB）

§  storedFieldsIndexFormat= MEMORY_CHUNK（最小巧的字段索引格式，需要最多12个字节的内存每块的压缩文件）。

索引大小

§  Lucene40StoredFieldsFormat

§  字段“索引：76M

§  场数据：9.4G

§  CompressingStoredFieldsFormat

§  字段“索引：1.7M

§  场数据：5.7G

索引速度

索引几乎在同一时间，花了两个StoredFieldsFormat秒（约37分钟）和摄食率都非常相似：

文件加载速度

我测得的平均时间从磁盘中加载一个文件使用随机文件标识符[0 - maxDoc的范围。据自由，我的I / O缓存〜5.2G，当我跑这些测试：

§  Lucene40StoredFieldsFormat：11.5ms，

§  CompressingStoredFieldsFormat：4.25ms。

在Lucene40StoredFieldsFormat的情况下，字段的数据文件是远远大于在I / O缓存，这么多的要求加载的文件翻译成实际磁盘寻道。相反，CompressingStoredFieldsFormat领域数据文件是只有一点点大于在I / O高速缓存，因此大多数的寻道供应I / O缓存。这就解释了为什么从磁盘加载文件快2倍以上，但它需要更多的CPU，因为解压缩。

在这种非常特殊的情况下，它可能会更快的切换到一个更积极的压缩模式或一个较大的块大小，使整个FDT文件可以放入I / O缓存。

结论

除非你的服务器有非常快的I / O，它通常是更快压缩领域的数据文件，以便它可以放入I / O缓存。CompressingStoredFieldsFormat相比Lucene40StoredFieldsFormat，允许高效的存储字段的压缩，因此，更好的性能。

http://blog.jpountz.net/post/33247161884/efficient-compressed-stored-fields-with-lucene