背影:
上篇分析了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。
如果喜欢搜索技术请关注我的公众号吧
每天会持续更新搜索相关技术