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