Solr4.4 优化之 Filter Cache配置
本文描述solr的cache类型之一:filter cache。接下来,我会解释它是什么、怎么配置它以及如何更好的使用它。
What it is used for?
先从内部机制开始。FilterCache存储了一些无序的文档标识号(ID)。这些ID并不是我们在schema.xml里配置的unique key,而是solr内部的一个文档标识。请记住这个。
FilterCache的任务是保持与用户过滤的结果关联。另外,cache可以辅助facet机制(在使用TermEnum时),在solrconfig.xml中的<useFilterForSortedQuery/>参数设为true时,还可以进行排序。
FilterCache的标准定义如下:
- <filterCache
- class="solr.FastLRUCache"
- size="16384"
- initialSize="4096"
- autowarmCount="4096" />
有以下的配置可供选择:
class:实现类。建议使用solr.FastLRUCache,它能在大量的GET、PUT操作下,提供更好的性能。
size:cache的最大值。
initialSize:cache的初始化值。
autowarmCount:从旧的cache到新的cache时,需要被复制的数量。
minSize:在full restoraton的情况下,将cache减小后的值
acceptableSize:如果minSize没有设置,则该值会替代之
cleanupThread:默认false,如果设为true则会使用一个分离的topic来清理cache。
大部分情况下,设置initialSize和autowarmCount就已经足够了。
How to configure?
cache的大小,需要根据基本的查询语句而定;maximum大小应该至少等于我们使用的过滤字段的大小。举个例子说明:如果在某个时间内,你的应用程序使用了2000个查询参数,则minimum的大小应该最小设为2000。
Efficient use
然而,光有配置是不够的,我们还需要让查询能够使用它。请看下面的例子:
- q=name:solr+AND+category:ksiazka+AND+section:ksiazki
初看起来,查询语句是正确的。但是有个问题:它并没有用到filterCache。所有的请求将会绑定到queryResultCache中并创建一个单独的条目。我们来作一下修改:
- q=name:solr&fq=category:ksiazka&fq=section:ksiazki
有什么变化呢?在这个例子中,一个条目会写入到queryResultCache中;另外,还会有两个条目会写入到filterCache中。现在看一下下面的语句:
- q=name:lucene&fq=category:ksiazka&fq=section:ksiazki
这个查询会创建一个条目到queryResultCache中,但是会使用filterCache中两个已经存在的条目。这样查询的执行时间会降低,IO的使用也会节省。
然而,对于下面的查询:
- q=name:lucene+AND+category:ksiazka+AND+section:ksiazki
solr不能使用任何cache并且需要从lucene索引中收集所有的信息。
Last few words
就像你所看到的,配置cache 的正确方法不是如何保证solr能够使用它,而是如何构建查询语句来提升性能。当考虑查询的时候,请考虑这一点。
推荐阅读
-
Ocelot简易教程(六)之重写配置文件存储方式并优化响应数据
-
Solr4.4 优化之 Filter Cache配置
-
Solr4.4 优化之 Filter Cache配置
-
mysql优化之query_cache_limit参数说明
-
MySql优化之InnoDB,4GB内存,多查询的my.ini中文配置方案详解
-
项目重构之数据源配置与优化:log4j 配置数据库连接池Druid,并
-
项目重构之数据源配置与优化:log4j 配置数据库连接池Druid,并
-
MySQL数据库优化技术之配置技巧总结_MySQL
-
MySQL性能优化之table_cache配置参数浅析_MySQL
-
Redis(开发与运维):58---开发运维的陷阱之(Linux配置优化:内存分配控制(overcommit、swappiness)、THP、OOM killer、NTP、TCP backlog