Elasticsearch RequestCache和Fielddata Cache

背影：
上篇分析了QueryCache，再把RequestCache和Fielddata Cache也分析一下吧。

RequestCache

1、RequestCache参与Cache条件

从源码上看RequestCache默认是开启的，只对size=0的查询进行Cache，那么就需要在查询时加入参数"size": 0, 但这样会缓存命中总数，aggregations， suggestions。

2、RequestCache配置

1）index.requests.cache.enable 默认为true，启动RequestCache配置。
2）indices.requests.cache.size RequestCache占用JVM的百分比。
3）indices.requests.cache.expire 配置过期时间，单位为分钟。

3、RequestCache作用域

RequestCache作用域为Node，在Node中的Shard共享这个Cache空间。

4、RequestCache 失效

当有索引refresh时就会失效，所以这块需要注意一些 如果实时索引，查询量比较大时最好先测试下生成DocIdSet的耗时，避免缓存产生耗时高的情况。

5、RequestCache key

RequestCache 是以查询的DSL整个串为key的，修改一个字符和顺序都需要重新生成Cache。

总结：
1）默认被开启，ES6.71版本。
2）是Node级，由本Node的Shard共享。
3）缓存的key是查询DSL字符串，顺序或字符不一至会重新Cache。
4）缓存失效是索引的refresh操作，也可以设置失效时间。
5）缓存的默认大小是JVM堆内存的1%，可以通过手动设置。

Fielddata Cache

FielddataCache是什么，开始做搜索就用ES5.0以后的朋友对这个Cache应该没什么概念了，因为早期版本，Lucene没有doc values这样的数据结构。 做数据聚合和排序的时候，需要将倒排索引的数据读取出来，重新组织成一个数组缓存，也就是从倒排索引中生成出来的要自己维护这段Cache， 之后才能够高效的做排序和聚合计算。后来ES中有了FielddataCache，但转换工作很耗资源，转换好的列表就会被缓存到fielddata cache，提升速度。 但是因为这个cache是在heap内部的，海量数据聚合的时候，生成的这些fielddata可能heap都放不下，很容易引起性能问题，甚至JVM OOM(还没有熔断保护的时候)。
默认Elasticsearch2.0 开始，在非 text 字段开启 doc_values，基于 doc_values 做排序和聚合，可以减少对FielddataCache的依赖，减少内存消耗，减少节点 OOM 的概率，由于doc_values的特性性能上也不会有多少损失，doc_value是一种正向索引结构以顺序预读的方式进行获取，所以随机获取就很慢了。
5.0 开始，text 字段默认关闭了 Fielddata 功能， Fielddata Cache 应当只用于 global ordinals。

FielddataCache失效和Node QueryCache 失效机制相同，当 segment 被合并后，才会失效。

Fielddata Cache大家做了解吧，使用它的也非常的少了，基本可以用doc_value代替了，doc_value使用不需要全部载入内存，有时间和大家分析下doc_value。

如果喜欢搜索技术请关注我的公众号吧
每天会持续更新搜索相关技术