缓存

ES 内针对不同阶段，设计有不同的缓存。以此提升数据检索时的响应性能。主要包括节点层面的 filter cache 和分片层面的 request cache。下面分别讲述。

filter cache

ES 的 query DSL 在 2.0 版本之前分为 query 和 filter 两种，很多检索语法，是同时存在 query 和 filter 里的。比如最常用的 term、prefix、range 等。怎么选择是使用 query 还是 filter 成为很多用户头疼的难题。于是从 2.0 版本开始，ES 干脆合并了 filter 统一归为 query。但是具体的检索语法本身，依然有 query 和 filter 上下文的区别。ES 依靠这个上下文判断，来自动决定是否启用 filter cache。

query 跟 filter 上下文的区别，简单来说：

  • query 是要相关性评分的，filter 不要；
  • query 结果无法缓存，filter 可以。

所以，选择也就出来了：

  • 全文搜索、评分排序，使用 query；
  • 是非过滤，精确匹配，使用 filter。

不过我们要怎么写，才能让 ES 正确判断呢？看下面这个请求：

  1. # curl -XGET http://127.0.0.1:9200/_search -d '
  2. {
  3.     "query": {
  4.         "bool": {
  5.             "must_not": [
  6.                 { "match": { "title": "Search" } }
  7.             ],
  8.             "must": [
  9.                 { "match": { "content": "Elasticsearch" } }
  10.             ],
  11.             "filter": [
  12.                 { "term":  { "status": "published" } },
  13.                 { "range": { "publish_date": { "gte": "2015-01-01" } } }
  14.             ]
  15.         }
  16.     }
  17. }'

在这个请求中，

  1. ES 先看到一个 query，那么进入 query 上下文。
  2. 然后在 bool 里看到一个 must_not，那么改进入 filter 上下文，这个有关 title 字段的查询不参与评分。
  3. 然后接着是一个 must 的 match，这个又属于 query 上下文，这个有关 content 字段的查询会影响评分。
  4. 最后碰到 filter，还属于 filter 上下文，这个有关 status 和 publish_date 字段的查询不参与评分。

需要注意的是，filter cache 是节点层面的缓存设置，每个节点上所有数据在响应请求时，是共用一个缓存空间的。当空间用满，按照 LRU 策略淘汰掉最冷的数据。

可以用 indices.cache.filter.size 配置来设置这个缓存空间的大小，默认是 JVM 堆的 10%，也可以设置一个绝对值。注意这是一个静态值，必须在 elasticsearch.yml 中提前配置。

shard request cache

ES 还有另一个分片层面的缓存，叫 shard request cache。5.0 之前的版本中，request cache 的用途并不大，因为 query cache 要起作用，还有几个先决条件：

  1. 分片数据不再变动，也就是对当天的索引是无效的(如果 refresh_interval 很大，那么在这个间隔内倒也算有效)；
  2. 使用了 "now" 语法的请求无法被缓存，因为这个是要即时计算的；
  3. 缓存的键是请求的整个 JSON 字符串，整个字符串发生任何字节变动，缓存都无效。

以 Elastic Stack 场景来说，Kibana 里几乎所有的请求，都是有 @timestamp 作为过滤条件的，而且大多数是以最近 N 小时/分钟这样的选项，也就是说，页面每次刷新，发出的请求 JSON 里的时间过滤部分都是在变动的。query cache 在处理 Kibana 发出的请求时，完全无用。

而 5.0 版本的一大特性，叫 instant aggregation。解决了这个先决条件的一大阻碍。

在之前的版本，Elasticsearch 接收到请求之后，直接把请求原样转发给各分片，由各分片所在的节点自行完成请求的解析，进行实际的搜索操作。所以缓存的键是原始 JSON 串。

而 5.0 的重构后，接收到请求的节点先把请求的解析做完，发送到各节点的是统一拆分修改好的请求，这样就不再担心 JSON 串多个空格啥的了。

其次，上面说的『拆分修改』是怎么回事呢？

比如，我们在 Kibana 里搜索一个最近 7 天(@timestamp:["now-7d" TO "now"])的数据，ES 就可以根据按天索引的判断，知道从 6 天前到昨天这 5 个索引是肯定全覆盖的。那么这个横跨 7 天的 date range query 就变成了 5 个 match_all query 加 2 个短时间的 date_range query。

现在你的仪表盘过 5 分钟自动刷新一次，再提交上来一次最近 7 天的请求，中间这 5 个 match_all 就完全一样了，直接从 request cache 返回即可，需要重新请求的，只有两头真正在变动的 date_range 了。

注1：match_all 不用遍历倒排索引，比直接查询 `@timestamp:要快很多。* *注2：判断覆盖修改为match_all并不是真的按照索引名称，而是 ES 从 2.x 开始提供的field_stats接口可以直接获取到@timestamp` 在本索引内的 max/min 值。当然从概念上如此理解也是可以接受的。*

field_stats 接口

  1. curl -XGET "http://localhost:9200/logstash-2016.11.25/_field_stats?fields=timestamp"

响应结果如下：

  1. {
  2.     "_shards": {
  3.         "total": 1,
  4.         "successful": 1,
  5.         "failed": 0
  6.     },
  7.     "indices": {
  8.         "logstash-2016.11.25": {
  9.             "fields": {
  10.                 "timestamp": {
  11.                     "max_doc": 1326564,
  12.                     "doc_count": 564633,
  13.                     "density": 42,
  14.                     "sum_doc_freq": 2258532,
  15.                     "sum_total_term_freq": -1,
  16.                     "min_value": "2008-08-01T16:37:51.513Z",
  17.                     "max_value": "2013-06-02T03:23:11.593Z",
  18.                     "is_searchable": "true",
  19.                     "is_aggregatable": "true"
  20.                 }
  21.             }
  22.         }
  23.     }
  24. }

和 filter cache 一样，request cache 的大小也是以节点级别控制的，配置项名为 indices.requests.cache.size，其默认值为 1%。