Elasticsearch 缓存机制

迷南。 2023-01-02 08:23 423阅读 0赞

## 1. 节点查询缓存（Node Query Cache） ##

### 官方文档简介 ###

查询缓存负责缓存查询的结果。每个节点有一个查询缓存，由所有分片共享。缓存执行LRU回收策略:当缓存满时，将回收最近最少使用的数据，为新数据让路。无法查看正在缓存的内容。

查询缓存只缓存在`filter`上下文中使用的查询。

### 详细介绍 ###

#### 缓存数据结构 ####

缓存分为两个级别，分别为`Query`和`Segment`，所以使用的数据结构是一个Map`<Query, Map<Segment, DocIdSet>>`，`DocIdSet`则使用的是`BitSet`

#### 参数说明 ####

`indices.queries.cache.size`: 控制`Filter`缓存的内存大小，默认为`10%`。接受百分比值(如`5%`)或精确值(如`512mb`)。

`indices.queries.cache.count`: 在官方文档并没有写，这是一个节点级别的配置，可以在`elasticsearch.yml`中配置，控制缓存的总数量。如果缓存文档数量达到了该值，即使缓存大小还没有达到上限，也没有办法再利用了。值得注意的是，如果一个查询在本节点涉及到多个Segment，那么实际的cache\_size将会是本值与Segment数量的乘积。

`indices.queries.cache.all_segments`: 用于是否在所有`Segment`上启用缓存，默认是`false`，不会对文档数小于`100000`并且小于整个索引大小的`3%`的Segment进行缓存。

`index.queries.cache.enabled`: 控制是否启用查询缓存。接受`true`(默认值)或`false`。

#### 可以被缓存的查询语句要求 ####

*  对于`TermQuery`、`MatchAllDocsQuery`等这种查询都不被缓存。当`BooleanQuey`的字节点为空时不会被缓存，当`Dis Max Query`的`Disjuncts`为空时不会被缓存。
 *  对于历史查询次数有要求，对于消耗高昂的`Query`只需要`2`次就加入缓存，其他的默认是`5`次，对于`BooleanQuery`和`DisjunctionMaxQuery`次数为`4`次。

#### 什么样的Segment会被缓存 ####

`Segment`中文档数大于`100000`或者大于整个所以大小的`3%`。如果想要索引所有段，可以设置`indices.queries.cache.all_segments`

#### 新索引的文档，缓存会失效或者重新构建吗 ####

缓存不会失效，而是通过判断文档是否符合`Query`的条件，如果符合条件的话则会将文档加入到`BitSet`中。

### 案例 ###

查看ES查询缓冲情况

curl 'http://es.zjw.cn:9200/_stats/query_cache?pretty&human'

返回结果query\_cache部分

"query_cache": { 
      "memory_size": "2.5gb",
      "memory_size_in_bytes": 2690321531,
      "total_count": 83881663356,
      "hit_count": 37834074368,
      "miss_count": 46047588988,
      "cache_size": 118427,
      "cache_count": 42784311,
      "evictions": 42665884
    }

从当前的`query_cache`看，`evictions`是`cache_size`的360倍，说明`cache_size`过小，导致缓存倍频繁淘汰，导致缓存命中比例较小，可以适当调大`indices.queries.cache.size`大小和`indices.queries.cache.count`。

## 2. 字段数据缓存（Field data Cache） ##

主要用于`sort`以及`aggs`的字段。这会把字段的值加载到内存中，以便于快速访问。`field data cache`的构建非常昂贵，因此最好能分配足够的内存以保障它能长时间处于被加载的状态。或者在创建索引时预见到某字段会被用于排序和聚合，而设置文档值，避免使用`field data cache`。

一定要注意数据建模，对于不合理的字段启用`field data cache`代价非常大，而且性能特别差！

`indices.fielddata.cache.size`: 用来控制缓存的大小，支持两种格式，一种是百分数（代表占节点`heap`的百分比），另一种是精确值（如`10gb`），默认是无限。

## 3. 分片请求缓存（Shard Request Cache） ##

`Shard`级别的缓存。默认的主要用于缓存`size=0`的请求（`aggs`和`suggestions`，还有就是`hits.total`）。

每当分片索引`refresh`的时候，如果数据发生了实际变化，那么缓存就会自动失效。所以`refresh`时间越长，那么缓存的时间也就越长。缓存采用的也是`LRU`淘汰策略。

> 缓存是以请求的`JSON`为`Key`来进行存储的，那么也就是说，当同样含义的不同形式的请求将无法识别缓存。

### 索引级别禁用缓存 ###

`index.requests.cache.enable`: 这个参数用来控制是否启用分片级别的缓存，默认是`false`

### 请求时禁用缓存 ###

通过`url`传参方式`request_cache=false`

### 主要的缓存配置 ###

`indices.requests.cache.size` 用来控制缓存在`heap`中的大小，默认是`1%`。