深入浅出Solr Cache

Josh_Persistence

浏览: 1631043 次
性别:
来自: 上海

最近访客更多访客>>

reshinder

maxuanzhao

yh4s

依然任逍遥

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Solr

Solr Cache documentCache FilterCache FiledValueCache queryResultCache

前言

Solr在Lucene之上开发了很多Cache功能，目前提供的Cache类型有：

(1) filterCache

(2) documentCache

(3) fieldvalueCache

(4) queryresultCache

一、Cache的生命周期

Solr查询的核心类是SolrIndexSearcher，每个core通常在同一时刻只由当前的SolrIndexSearcher供上层的handler使用（但当切换SolrIndexSearcher时可能会有两个同时提供服务），Solr的各种Cache正是依附于SolrIndexSearcher的，SolrIndexSearcher在则Cache生，SolrIndexSearcher亡则Cache被清空close掉。

从上面前言中可知，Solr中的应用Cache有filterCache、queryResultCache、documentCache等，这些Cache都是SolrCache的实现类，并且是SolrIndexSearcher的成员变量，各自有着不同的逻辑和使命，后面分别予以介绍和分析。

二、Cache的配置介绍

要使用Solr的四种Cache，只需要在SolrConfig中配置如下内容即可：

<query>
...
<filterCache class="solr.FastLRUCache"
                 size="512"
                 initialSize="512"
                 autowarmCount="0"/>

<queryResultCache class="solr.LRUCache"
                      size="512"
                      initialSize="512"
                      autowarmCount="0"/>

<documentCache class="solr.LRUCache"
                   size="512"
                   initialSize="512"
                   autowarmCount="0"/>

// 是否能使用到filtercache关键配置  
<useFilterForSortedQuery>true</useFilterForSortedQuery>

// queryresult的结果集控制  
 <queryResultWindowSize>20</queryResultWindowSize>

// 是否启用懒加载field
<enableLazyFieldLoading>true</enableLazyFieldLoading>
...

</query>

三、Solr Cache的命中监控

当启动Solr后，可通过Solr Admin来查看Solr中每个Cache的命中情况。

其中 lookups 为当前cache 查询数， hitratio 为当前cache命中率，inserts为当前cache插入数，evictions为从cache中踢出来的数据个数,size 为当前cache缓存数， warmuptime为当前cache预热所消耗时间，而cumulative都为该类型Cache累计的查询，命中，命中率，插入、踢出的数目。

四、Solr Cache接口实现类

1、Solr提供了两种SolrCache接口实现类：solr.search.LRUCache和solr.search.FastLRUCache。FastLRUCache是1.4版本中引入的，其速度在普遍意义上要比LRUCache更快些。

下面是对SolrCache接口主要方法的注释：

public interface SolrCache {
  /**
   * Solr在解析配置文件构造SolrConfig实例时会初始化配置中的各种CacheConfig，
   * 在构造SolrIndexSearcher时通过SolrConfig实例来newInstance SolrCache，
   * 这会调用init方法。参数args就是和具体实现（LRUCache和FastLRUCache）相关的
   * 参数Map，参数persistence是个全局的东西，LRUCache和FastLRUCache用其来统计
   * cache访问情况（因为cache是和SolrIndexSearcher绑定的，所以这种统计就需要个
   * 全局的注入参数），参数regenerator是autowarm时如何重新加载cache，
   * CacheRegenerator接口只有一个被SolrCache warm方法回调的方法：
   * boolean regenerateItem(SolrIndexSearcher newSearcher,
   * SolrCache newCache, SolrCache oldCache, Object oldKey, Object oldVal)
   */
  public Object init(Map args, Object persistence, CacheRegenerator regenerator);
  /** :TODO: copy from Map */
  public int size();
  /** :TODO: copy from Map */
  public Object put(Object key, Object value);
  /** :TODO: copy from Map */
  public Object get(Object key);
  /** :TODO: copy from Map */
  public void clear();
  /**
   * 新创建的SolrIndexSearcher autowarm方法，该方法的实现就是遍历已有cache中合适的
   * 范围（因为通常不会把旧cache中的所有项都重新加载一遍），对每一项调用regenerator的
   * regenerateItem方法来对searcher加载新cache项。
   */
  void warm(SolrIndexSearcher searcher, SolrCache old) throws IOException;
  /** Frees any non-memory resources */
  public void close();

1.1、solr.search.LRUCache

什么是LRU算法，对于什么是LRU算法，如果感兴趣，可以查看另一篇博客：http://josh-persistence.iteye.com/blog/2247280

LRUCache可配置参数如下：

1）size：cache中可保存的最大的项数，默认是1024

2）initialSize：cache初始化时的大小，默认是1024。

3）autowarmCount：当切换SolrIndexSearcher时，可以对新生成的SolrIndexSearcher做autowarm（预热）处理。autowarmCount表示从旧的SolrIndexSearcher中取多少项来在新的SolrIndexSearcher中被重新生成，如何重新生成由CacheRegenerator实现。

查看Solr源码可以发现，在实现上，LRUCache直接使用LinkedHashMap来缓存数据，由initialSize来限定cache的大小，淘汰策略也是使用LinkedHashMap的内置的LRU方式，读写操作都是对map的全局锁，所以并发性效果方面稍差。

1.2、solr.search.FastLRUCache

在配置方面，FastLRUCache除了需要LRUCache的参数，还可有选择性的指定下面的参数：

1）minSize：当cache达到它的最大数，淘汰策略使其降到minSize大小，默认是0.9*size。该值的大小应该至少等于我们使用的过滤字段的大小。举个例子说明：如果在某个时间内，你的应用程序使用了2000个查询参数，则minimum的大小应该最小设为2000。

2）acceptableSize：当淘汰数据时，期望能降到minSize，但可能会做不到，则可勉为其难的降到acceptableSize，默认是0.95*size，也可以这么理解，如果没有设置minSize，那么改值会替代之。

3）cleanupThread：相比LRUCache是在put操作中同步进行淘汰工作，FastLRUCache可选择由独立的线程来做，也就是配置cleanupThread的时候。当cache大小很大时，每一次的淘汰数据就可能会花费较长时间，这对于提供查询请求的线程来说就不太合适，由独立的后台线程来做就很有必要。

实现上，FastLRUCache内部使用了ConcurrentLRUCache来缓存数据，它是个加了LRU淘汰策略的ConcurrentHashMap，所以其并发性要好很多，这也是多数Java版Cache的极典型实现。

2、filterCache

2.1 概述：

filterCachef中存储了无序的lucene document id集合，即FilterCache存储了一些无序的文档标识号(ID)，这些ID并不是我们在schema.xml里配置的unique key，而是solr内部的一个文档标识。

该cache有3种用途：

1）filterCache存储了filter queries(“fq”参数)得到的document id集合结果 Solr中的query参数有两种，即q和fq。如果fq存在，Solr是先查询fq（因为fq可以多个，所以多个fq查询是个取结果交集的过程)，之后将fq结果和q结果取并。在这一过程中，filterCache就是key为单个fq（类型为Query），value为document id集合（类型为DocSet）的cache。从后面的分析你将会看到对于fq为range query来说，filterCache将表现出其更有价值的一面。

2）filterCache还可用于facet查询

facet查询中各facet的计数是通过对满足query条件的document id集合（可涉及到filterCache）的处理得到的。因为统计各facet计数可能会涉及到所有的doc id，所以filterCache的大小需要能容下索引的文档数。

3）如果solfconfig.xml中配置了<useFilterForSortedQuery/>，即设置该参数为true的时候，那么还可以进行排序。

对于是否使用filterCache及如何配置filterCache大小，需要根据应用特点、统计、效果、经验等各方面来评估。对于使用fq、facet的应用，对filterCache的调优是很有必要的。

2.2 有效的使用filterCache

光有上面的配置是不够的，我们还需要让查询能够使用它，如下面的例子：

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索引中收集所有的信息。

小结：

就像你所看到的，配置cache 的正确方法不是如何保证solr能够使用它【因为默认都会有solrconfig.xml的配置】，而是如何构建查询语句来提升性能。

2.3、filterCached的实例分析

从上面的分析可以看出，solr应用中为了提高查询速度有可以利用几种cache来优化查询速度，分别是fieldValueCache，queryResultCache，documentCache，filtercache，在日常使用中最为立竿见影，最有效的应属filtercache。谈到filterCache的作用，可以从一段Solr的查询日志开始说起，下面是截取的其中一段Solr的查询日志：

[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 2                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A1+AND+class_id%3A1+AND+%28group_id%3A411%29&sort=gmt_create+desc&start=0&rows=20,queryTime_is ==> 2                  
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 2                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A1+AND+class_id%3A1+AND+%28group_id%3A8059%29&sort=gmt_create+desc&start=0&rows=20,queryTime_is ==> 0                 
[search4alive-0] Request_is ==> debugQuery=on&group=true&group.field=group_id&group.ngroups=true&group.sort=gmt_create+desc&q=status%3A0++AND+biz_type%3A1+AND+class_id%3A1+AND+ha
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=30&rows=30,queryTime_is ==> 4                                    
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 1                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A1+AND+class_id%3A1+AND+%28group_id%3A375%29&sort=gmt_create+desc&start=0&rows=20,queryTime_is ==> 3                  
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 1                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=30,queryTime_is ==> 4                                     
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 1                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=30,queryTime_is ==> 4                                     
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=30,queryTime_is ==> 3

看到这段查询日志之后，我们开始考虑如何提升查询的rt（查询速度），因为在参数q中的查询是要有磁盘IO开销的，很自然的思路是将整个查询的参数q作为key，对应的结果作为value，这样做是可以的，但是查询的命中率会很低，会占用大量内存空间。

分析日志可知：查询参数q基本上每次都会出现status,biz_type,class_id 对于这样的查询，可以把整个查询条件分成两部分：一部分是以status,biz_type,class_id 这几个条件组成的子查询条件，另外一部分是除这三个条件之外的子查询。在进程查询的时候，先将status,biz_type,class_id 条件组成的条件作为key，对应的结果作为value进行缓存，然后再和另外一部分查询的结果进行求交运算。

通过上面这幅图明白了filtercache的意义是，将原先一个普通查询分割成两个组合查询的与运算，两个子查询至少有一个使用缓存，这样既减少了查询过程的IO操作，又控制了缓存的容量不会消耗过多的内存。

客户端API调用：

下面是原先的客户端端查询代码：

SolrQuery query = new SolrQuery();

query.setQuery("status:0 AND biz_type:1 AND class_id:1 AND xxx:123");

QueryResponse response = qyeryServer.query(query);

使用filterQuery之后的查询代码：

SolrQuery query = new SolrQuery();

query.addFilterQuery("status:0 AND biz_type:1 AND class_id:1");
query.setQuery("xxx:123");

QueryResponse response = qyeryServer.query(query);

经过测试这样优化之后，查询的RT会明显减小，QPS会有明显提升。

使用filterquery过程中需要注意点：

1）不能在filterQuery 上重复出现query中的查询参数，如果上面的filterquery调用方法如下所示：

query.addFilterQuery("status:0 AND biz_type:1 AND class_id:1 AND xxx:123");
query.setQuery("xxx:123");

如上，条件xxx:123 在filterQuery和query上都出现了，这样的写法非但起不到查询优化的目的，而且还会增加查询的性能开销。

2）尽量减少调用addFilterQuery方法的次数

query.addFilterQuery("status:0 ");
query.addFilterQuery("biz_type:1 ");
query.addFilterQuery("class_id:1 ");
query.setQuery("xxx:123");

如上，将status:0 AND biz_type:1 AND class_id:1 这个组合查询条件，分三次调用filterQuery方法来完成，这样的调用方法虽然是正确的，并且能起到性能优化的效果，优化性能没有调用一次addFilterQuery方法来得高，原因是多调用了两次addFilterQuery，就意味着最后需要多进行两次结果集的求交运算，虽然结果集求交运算速度很快，但毕竟是有性能损耗的。

不过从内存开销的角度来说，调用三次addfilterQuery方法这样可以有效降低内存的使用量，这个是肯定的。所以在是否调用多次addFilterQuery方法的原则是，在内存开销允许的前提下，将量将所有filterQuery条件，通过调用有限次数的addFilterQuery方法来完成。

2.3、queryResultCache

顾名思义，queryResultCache是对查询结果的缓存（SolrIndexSearcher中的cache缓存的都是document id set），这个结果就是针对查询条件的完全有序的结果。缓存的key是个什么结构呢？就是下面的类（key的hashcode就是QueryResultKey的成员变量hc）：

public QueryResultKey(Query query, List<Query> filters, Sort sort, int nc_flags) {
    this.query = query;
    this.sort = sort;
    this.filters = filters;
    this.nc_flags = nc_flags;
    int h = query.hashCode();
    if (filters != null) h ^= filters.hashCode();
    sfields = (this.sort !=null) ? this.sort.getSort() : defaultSort;
    for (SortField sf : sfields) {
      // mix the bits so that sortFields are position dependent
      // so that a,b won't hash to the same value as b,a
      h ^= (h << 8) | (h >>> 25);   // reversible hash
      if (sf.getField() != null) h += sf.getField().hashCode();
      h += sf.getType();
      if (sf.getReverse()) h=~h;
      if (sf.getLocale()!=null) h+=sf.getLocale().hashCode();
      if (sf.getFactory()!=null) h+=sf.getFactory().hashCode();
    }
    hc = h;
  }

因为查询参数是有start和rows的，所以某个QueryResultKey可能命中了cache，但start和rows却不在cache的document id set范围内。当然，document id set是越大命中的概率越大，但这也会很浪费内存，这就需要个参数：queryResultWindowSize来指定document id set的大小。Solr5.x中默认取值为20,可配置，WIKI上的解释很深简单明了：

<!-- An optimization for use with the queryResultCache.  When a search
         is requested, a superset of the requested number of document ids
         are collected.  For example, of a search for a particular query
         requests matching documents 10 through 19, and queryWindowSize is 50,
         then documents 0 through 50 will be collected and cached.  Any further
         requests in that range can be satisfied via the cache.
    -->
    <queryResultWindowSize>50</queryResultWindowSize>

相比filterCache来说，queryResultCache内存使用上要更少一些，但它的效果如何就很难说。就索引数据来说，通常我们只是在索引上存储应用主键id，再从数据库等数据源获取其他需要的字段。这使得查询过程变成，首先通过solr得到document id set，再由Solr得到应用id集合，最后从外部数据源得到完成的查询结果。如果对查询结果正确性没有苛刻的要求，可以在Solr之外独立的缓存完整的查询结果（定时作废），这时queryResultCache就不是很有必要，否则可以考虑使用queryResultCache。当然，如果发现在queryResultCache生命周期内，query重合度很低，也不是很有必要开着它。

2.4、 documentCache

又顾名思义，documentCache用来保存<doc_id,document>对的。如果使用documentCache，就尽可能开大些，至少要大过<max_results> * <max_concurrent_queries>，否则因为cache的淘汰，一次请求期间还需要重新获取document一次。也要注意document中存储的字段的多少，避免大量的内存消耗。

2.5、 User/Generic Caches

Solr支持自定义Cache，只需要实现自定义的regenerator即可，下面是配置示例：

<!-- Example of a generic cache.  These caches may be accessed by name
         through SolrIndexSearcher.getCache(),cacheLookup(), and cacheInsert().
         The purpose is to enable easy caching of user/application level data.
         The regenerator argument should be specified as an implementation
         of solr.search.CacheRegenerator if autowarming is desired.
    -->
    <!--
    <cache name="yourCacheNameHere"
      class="solr.LRUCache"
      size="4096"
      initialSize="2048"
      autowarmCount="4096"
      regenerator="org.foo.bar.YourRegenerator"/>
    -->

2.6、 The Lucene FieldCache

lucene中有相对低级别的FieldCache，Solr并不对它做管理，所以，lucene的FieldCache还是由lucene的IndexSearcher来搞。

2.7、 autowarm

上面有提到autowarm，autowarm触发的时机有两个，一个是创建第一个Searcher时（firstSearcher），一个是创建个新Searcher（newSearcher）来代替当前的Searcher。在Searcher提供请求服务前，Searcher中的各个Cache可以做warm处理，处理的地方通常是SolrCache的init方法，而不同cache的warm策略也不一样。

1）filterCache：filterCache注册了下面的CacheRegenerator，就是由旧的key查询索引得到新值put到新cache中。

solrConfig.filterCacheConfig.setRegenerator(
              new CacheRegenerator() {
                public boolean regenerateItem(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache, Object oldKey, Object oldVal) throws IOException {
                  newSearcher.cacheDocSet((Query)oldKey, null, false);
                  return true;
                }
              }
      );

2）queryResultCache：queryResultCache的autowarm不在SolrCache的init（也就是说，不是去遍历已有的queryResultCache中的query key执行查询），而是通过SolrEventListener接口的void newSearcher(SolrIndexSearcher newSearcher, SolrIndexSearcher currentSearcher)方法，来执行配置中特定的query查询，达到显示的预热lucene FieldCache的效果。

queryResultCache的配置示例如下：

<listener event="newSearcher" class="solr.QuerySenderListener">
      <arr name="queries">
        <!-- seed common sort fields -->
        <lst> <str name="q">anything</str> <str name="sort">name desc price desc populartiy desc</str> </lst>
      </arr>
    </listener>
    <listener event="firstSearcher" class="solr.QuerySenderListener">
      <arr name="queries">
        <!-- seed common sort fields -->
        <lst> <str name="q">anything</str> <str name="sort">name desc, price desc, populartiy desc</str> </lst>
        <!-- seed common facets and filter queries -->
        <lst> <str name="q">anything</str> 
              <str name="facet.field">category</str> 
              <str name="fq">inStock:true</str>
              <str name="fq">price:[0 TO 100]</str>
        </lst>
      </arr>
    </listener>

3）documentCache：因为新索引的document id和索引文档的对应关系发生变化，所以documentCache没有warm的过程。尽管autowarm很好，也要注意autowarm带来的开销，这需要在实际中检验其warm的开销，也要注意Searcher的切换频率，避免因为warm和切换影响Searcher提供正常的查询服务。

查看图片附件

1
顶

1
踩

分享到：

Solr中的Field、CopyField、DynamicField | LRU算法

2015-10-06 00:50
浏览 4808
评论(0)
分类:行业应用
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论