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的标准定义如下： 

Xml代码  

1. <filterCache  
2.     class="solr.FastLRUCache"  
3.     size="16384"  
4.     initialSize="4096"  
5.     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 
    然而，光有配置是不够的，我们还需要让查询能够使用它。请看下面的例子： 

Url代码  

1. q=name:solr+AND+category:ksiazka+AND+section:ksiazki  

初看起来，查询语句是正确的。但是有个问题：它并没有用到filterCache。所有的请求将会绑定到queryResultCache中并创建一个单独的条目。我们来作一下修改： 

Url代码  

1. q=name:solr&fq=category:ksiazka&fq=section:ksiazki  

有什么变化呢？在这个例子中，一个条目会写入到queryResultCache中；另外，还会有两个条目会写入到filterCache中。现在看一下下面的语句： 

Url代码  

1. q=name:lucene&fq=category:ksiazka&fq=section:ksiazki  

这个查询会创建一个条目到queryResultCache中，但是会使用filterCache中两个已经存在的条目。这样查询的执行时间会降低，IO的使用也会节省。 

然而，对于下面的查询： 

Url代码  

1. q=name:lucene+AND+category:ksiazka+AND+section:ksiazki  

solr不能使用任何cache并且需要从lucene索引中收集所有的信息。 

Last few words 
就像你所看到的，配置cache 的正确方法不是如何保证solr能够使用它，而是如何构建查询语句来提升性能。当考虑查询的时候，请考虑这一点。