Solr Cache使用介绍及分析

本文将介绍Solr查询中涉及到的Cache使用及相关的实现。Solr查询的核心类就是SolrIndexSearcher，每个core通常在同一时刻只由当前的SolrIndexSearcher供上层的handler使用（当切换SolrIndexSearcher时可能会有两个同时提供服务），而Solr的各种Cache是依附于SolrIndexSearcher的，SolrIndexSearcher在则Cache生，SolrIndexSearcher亡则Cache被清空close掉。Solr中的应用Cache有filterCache、queryResultCache、documentCache等，这些Cache都是SolrCache的实现类，并且是SolrIndexSearcher的成员变量，各自有着不同的逻辑和使命，下面分别予以介绍和分析。

1、SolrCache接口实现类

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

下面是对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

LRUCache可配置参数如下：

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

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

3）autowarmCount：当切换SolrIndexSearcher时，可以对新生成的SolrIndexSearcher做autowarm（预热）处理。autowarmCount表示从旧的SolrIndexSearcher中取多少项来在新的SolrIndexSearcher中被重新生成，如何重新生成由CacheRegenerator实现。在当前的1.4版本的Solr中，这个autowarmCount只能取预热的项数，将来的4.0版本可以指定为已有cache项数的百分比，以便能更好的平衡autowarm的开销及效果。如果不指定该参数，则表示不做autowarm处理。

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

1.2、solr.search.FastLRUCache

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

1）minSize：当cache达到它的最大数，淘汰策略使其降到minSize大小，默认是0.9*size。

2）acceptableSize：当淘汰数据时，期望能降到minSize，但可能会做不到，则可勉为其难的降到acceptableSize，默认是0.95*size。

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

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

2、filterCache

filterCache存储了无序的lucene document id集合，该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查询（http://wiki.apache.org/solr/SolrFacetingOverview），facet查询中各facet的计数是通过对满足query条件的document id集合（可涉及到filterCache）的处理得到的。因为统计各facet计数可能会涉及到所有的doc id，所以filterCache的大小需要能容下索引的文档数。

3）如果solfconfig.xml中配置了<useFilterForSortedQuery/>，那么如果查询有filter（此filter是一需要过滤的DocSet，而不是fq，我未见得它有什么用），则使用filterCache。

下面是filterCache的配置示例：

复制代码

<!-- Internal cache used by SolrIndexSearcher for filters (DocSets),

unordered sets of *all* documents that match a query.

When a new searcher is opened, its caches may be prepopulated

or "autowarmed" using data from caches in the old searcher.

autowarmCount is the number of items to prepopulate. For LRUCache,

the prepopulated items will be the most recently accessed items.

-->

<filterCache

class="solr.LRUCache"

size="16384"

initialSize="4096"

复制代码

autowarmCount="4096"/>

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

3、queryResultCache

顾名思义，queryResultCache是对查询结果的缓存（SolrIndexSearcher中的cache缓存的都是document id set），这个结果就是针对查询条件的完全有序的结果。下面是它的配置示例：

复制代码

<!-- queryResultCache caches results of searches - ordered lists of

document ids (DocList) based on a query, a sort, and the range

of documents requested.

-->

<queryResultCache

class="solr.LRUCache"

size="16384"

initialSize="4096"

autowarmCount="1024"/>

复制代码

缓存的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的大小。Solr中默认取值为50,可配置，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.

-->

复制代码

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

4、documentCache

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

下面是documentCache的配置示例：

<!-- documentCache caches Lucene Document objects (the stored fields for each document).

-->

<documentCache

class="solr.LRUCache"

size="16384"

initialSize="16384"/>

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"/>

-->

复制代码

6、The Lucene FieldCache

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

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的配置示例如下：

复制代码

<lst> <str name="q">anything</str> <str name="sort">name desc price desc populartiy desc</str> </lst>

</arr>

</listener>

<lst> <str name="q">anything</str> <str name="sort">name desc, price desc, populartiy desc</str> </lst>

<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提供正常的查询服务。

8、参考文章

http://wiki.apache.org/solr/SolrCaching

本文转自Phinecos(洞庭散人)博客园博客，原文链接：http://www.cnblogs.com/phinecos/archive/2012/05/24/2517018.html，如需转载请自行联系原作者

Solr Cache使用介绍及分析相关推荐

简单的DPDK介绍与分析
DPDK介绍及分析什么是DPDK Intel® DPDK 全称 __Intel Data Plane Development Kit__,是intel提供的数据平面开发工具集,为Intel arch ...
组播MSDP-原理介绍+报文分析+配置示例
个人认为,理解报文就理解了协议.通过报文中的字段可以理解协议在交互过程中相关传递的信息,更加便于理解协议. 因此本文将在MSDP协议(Multicast Source Discovery Protoc ...
mos 多路模拟电子开关_【原创】单火线智能开关技术介绍及分析
文章来自电子星球APP--<单火线智能开关技术介绍及分析> 作者:leo.zhao 单火线智能开关的概念众所周知,国内220V电网市电有两根线:一根火线和一根零线,此外为了保护人身安全有 ...
经验：Library Cache Lock之异常分析-云和恩墨技术通讯精选
亲爱的读者朋友: 为了及时共享行业案例,通知共性问题,达成共享和提前预防,我们整理和编辑了<云和恩墨技术通讯>,通过对过去一段时间的知识回顾,故障归纳,以期提供有价值的信息供大家参考.同时 ...
libnet介绍与分析
libnet介绍与分析当前,基于socket的网络编程已成为当今不可替代的编程方法,它将网络通讯当作文件描述符进行处理,把对这个"网络文件"(即socket套接字)的操作抽象成一 ...
组播IGMP-原理介绍+报文分析+配置示例
个人认为,理解报文就理解了协议.通过报文中的字段可以理解协议在交互过程中相关传递的信息,更加便于理解协议. 因此本文将在IGMPv2协议报文的基础上进行介绍,以详细介绍主机-路由器IGMP组播协议.I ...
typecpd协议规范 C语言,USB-C(USB Type-C)规范的简单介绍和分析
USB-C(USB Type-C)规范的简单介绍和分析作者:wowo 发布于:2017-12-18 16:18 分类:USB 1. 前言从1996年1月USB1.0正式发布至今(2017年9月 U ...
[智能座舱]小鹏G9语音新功能介绍与分析
自从2020年小鹏P7上市后,其搭载的全场景语音交互系统就成为车载语音交互产品的标杆.小鹏G9发布也带来了语音系统的升级.因为目前市面上还没办法体验到最新的系统,本文根据B站的体验视频,对小鹏G9上的 ...
国内外数据安全治理框架介绍与分析
本文将介绍和分析:微软 DGPC框架,Gartner 数据安全治理框架 DSG,数据安全能力成熟度模型 DSMM 数据治理与数据安全治理系列文章 https://luozhonghua.blog.cs ...

Solr Cache使用介绍及分析

Solr Cache使用介绍及分析相关推荐

最新文章

热门文章