Elasticsearch 缓存机制深度解析：Fielddata、Query、Request Cache 详解与优化实践

Elasticsearch 缓存机制深度解析：Fielddata、Query、Request Cache 详解与优化实践

大家好，我是你们的码农朋友“搬砖小王”。今天咱们来聊聊 Elasticsearch (ES) 的缓存机制，这可是性能优化的一把利器。对于需要进行查询优化的你来说，理解并合理利用 ES 的缓存，能让你的查询速度“嗖嗖”地提升！

很多刚接触 ES 的朋友，可能会觉得 ES 查询已经很快了。没错，ES 的倒排索引确实牛，但如果在高并发、大数据量的场景下，不注意缓存的使用，性能瓶颈还是会出现的。想象一下，成千上万的请求同时涌向你的 ES 集群，如果没有缓存，每个请求都去磁盘上“翻箱倒柜”，那场面……简直不敢想！

所以，咱们今天就来好好扒一扒 ES 的三种主要缓存：Fielddata Cache、Query Cache 和 Request Cache，看看它们各自的特点、适用场景，以及如何配置和监控，最后再分享一些实战经验。

一、Fielddata Cache：排序、聚合的幕后英雄

Fielddata Cache，顾名思义，主要用于字段数据的缓存。当你对 text 类型的字段进行排序、聚合或者使用脚本访问这些字段时，ES 就会用到 Fielddata Cache。

1.1 为什么需要 Fielddata Cache？

咱们知道，ES 的倒排索引对于快速查找包含特定词条的文档非常高效。但是，当我们需要对字段进行排序或聚合时，倒排索引就力不从心了。因为排序和聚合需要访问每个文档的字段值，而倒排索引是面向词条的，不是面向文档的。

为了解决这个问题，ES 引入了 Fielddata。Fielddata 是一种“列式存储”结构，它将每个文档的字段值加载到内存中，以便快速访问。这样，排序、聚合等操作就可以直接在内存中进行，大大提高了效率。

1.2 Fielddata 的“双刃剑”

Fielddata 虽好，但它也是一把“双刃剑”。因为它会将所有文档的字段值加载到内存，所以如果你的字段值很大，或者文档数量很多，Fielddata Cache 很容易就会把你的内存撑爆，导致 OOM (Out Of Memory) 错误。

1.3 如何“驾驭” Fielddata？

既然 Fielddata 这么“危险”，那我们该如何“驾驭”它呢？这里有几个建议：

• 尽量避免对 text 类型的字段进行排序或聚合。 如果确实需要，可以考虑使用 keyword 类型。keyword 类型默认使用 doc values，这是一种磁盘上的列式存储结构，比 Fielddata 更省内存。
• 控制 Fielddata Cache 的大小。 ES 默认允许 Fielddata Cache 无限制地使用内存，这显然是不合理的。我们可以通过 indices.fielddata.cache.size 参数来限制 Fielddata Cache 的最大大小。例如，设置为 30% 表示最多使用 JVM 堆内存的 30%。
• 监控 Fielddata Cache 的使用情况。 我们可以通过 ES 的监控 API (如 _cat/fielddata) 来查看 Fielddata Cache 的使用情况，及时发现潜在的内存问题。
• 使用 Doc Values. Doc Values 是一种在索引时构建的磁盘上的列式存储数据结构,与Fielddata有相同目的。但是其存储在磁盘上，不消耗堆内存。Doc Values在大多数场景下是更优的选择。text类型默认不开启doc_values，keyword类型默认开启了doc_values。

1.4 Fielddata 的加载方式

Fielddata 的加载方式有两种：

• Eager (预加载)： 在索引刷新时，将所有文档的字段值都加载到内存中。这种方式的优点是查询速度快，缺点是占用内存多，刷新时间长。
• Lazy (延迟加载)： 在第一次查询时，将需要的字段值加载到内存中。这种方式的优点是占用内存少，刷新时间短，缺点是第一次查询速度慢。

我们可以通过 fielddata.loading 参数来控制 Fielddata 的加载方式。例如，设置为 eager 表示预加载，设置为 lazy 表示延迟加载。

二、Query Cache：查询结果的“时光机”

Query Cache，顾名思义，用于缓存查询的结果。当一个查询命中 Query Cache 时，ES 可以直接返回缓存的结果，而不需要重新执行查询，大大提高了查询速度。

2.1 Query Cache 的工作原理

Query Cache 的工作原理很简单：ES 会将每个查询的请求和结果作为一个键值对存储在缓存中。当一个查询请求到来时，ES 会先检查 Query Cache 中是否已经存在相同的查询请求。如果存在，就直接返回缓存的结果；如果不存在，就执行查询，并将结果存入缓存。

2.2 哪些查询可以被缓存？

并不是所有的查询都可以被 Query Cache 缓存。只有满足以下条件的查询才会被缓存：

• 查询类型必须是 bool 查询。
• 查询中不能包含 now、random 等不确定性函数。
• 查询中不能包含 size 参数。 （因为只缓存 filter 的结果，不缓存 hits）
• 查询必须使用过滤器上下文（filter context）。

2.3 Query Cache 的“坑”

Query Cache 虽然能提高查询速度，但它也有一些“坑”需要注意：

• 缓存失效问题。 当索引发生变化（如添加、删除、更新文档）时，Query Cache 中相关的缓存就会失效。如果索引变化频繁，Query Cache 的命中率就会很低，甚至可能起到反作用。
• 缓存占用问题。 Query Cache 也会占用内存。如果缓存的查询结果过多，或者查询结果很大，Query Cache 也会导致内存问题。

2.4 如何“避坑”？

为了避免 Query Cache 的“坑”，我们可以采取以下措施：

• 控制 Query Cache 的大小。 我们可以通过 indices.queries.cache.size 参数来限制 Query Cache 的最大大小。例如，设置为 10% 表示最多使用 JVM 堆内存的 10%。
• 监控 Query Cache 的使用情况。 我们可以通过 ES 的监控 API (如 _cat/indices) 来查看 Query Cache 的使用情况，及时发现潜在的问题。
• 合理设计查询。 尽量使用过滤器上下文，避免使用 now、random 等不确定性函数。避免不必要的缓存。
• 手动清除缓存。 当我们明确知道索引发生了较大的变更，导致Query Cache中大量缓存失效，可以手动清除全部缓存或指定索引的缓存，避免无效缓存占用过多资源。 POST /_cache/clear 或 POST /my-index/_cache/clear

三、Request Cache：请求级别的“缓存加速器”

Request Cache，顾名思义，用于缓存整个请求的结果。与 Query Cache 不同，Request Cache 缓存的是整个请求的结果，包括 hits、aggregations 等。Request Cache 缓存的是 JSON 格式的响应结果。

3.1 Request Cache 的工作原理

Request Cache 的工作原理与 Query Cache 类似：ES 会将每个请求的请求体和结果作为一个键值对存储在缓存中。当一个请求到来时，ES 会先检查 Request Cache 中是否已经存在相同的请求体。如果存在，就直接返回缓存的结果；如果不存在，就执行请求，并将结果存入缓存。

3.2 哪些请求可以被缓存？

只有满足以下条件的请求才会被 Request Cache 缓存：

• 请求类型必须是 GET 或 HEAD。
• 请求中不能包含 now、random 等不确定性函数。
• 请求必须指定 size: 0。 （因为只希望缓存 hits 为0时的结果）
• 请求中不能包含 profile 参数。

3.3 Request Cache 的“坑”

Request Cache 也有一些“坑”需要注意：

• 缓存失效问题。 与 Query Cache 类似，当索引发生变化时，Request Cache 中相关的缓存也会失效。
• 缓存占用问题。 Request Cache 也会占用内存。如果缓存的请求结果过多，或者请求结果很大，Request Cache 也会导致内存问题。

3.4 如何“避坑”？

为了避免 Request Cache 的“坑”，我们可以采取以下措施：

• 控制 Request Cache 的大小。 我们可以通过 indices.requests.cache.size 参数来限制 Request Cache 的最大大小。例如，设置为 1% 表示最多使用 JVM 堆内存的 1%。
• 监控 Request Cache 的使用情况。 我们可以通过 ES 的监控 API (如 _nodes/stats) 来查看 Request Cache 的使用情况，及时发现潜在的问题。
• 手动控制是否开启请求缓存。 GET /my-index/_search?request_cache=true 或 GET /my-index/_search?request_cache=false

四、总结与实战经验

好了，关于 ES 的三种缓存机制，我们就聊到这里。总结一下：

• Fielddata Cache 主要用于字段数据的缓存，适用于排序、聚合等操作。但要注意内存占用问题，尽量避免对 text 类型的字段进行排序或聚合，或者使用 keyword 类型和 doc values。
• Query Cache 用于缓存查询的结果，适用于过滤器上下文中的 bool 查询。要注意缓存失效问题，合理设计查询，避免不必要的缓存。
• Request Cache 用于缓存整个请求的结果，适用于 size: 0 的 GET 或 HEAD 请求。要注意缓存失效问题，控制缓存大小。

最后，分享一些实战经验：

• 缓存虽好，但不要滥用。 缓存是把“双刃剑”，用得好可以提高性能，用不好反而会降低性能。要根据实际情况，合理选择和配置缓存。
• 监控是关键。 要时刻监控缓存的使用情况，及时发现潜在的问题。ES 提供了丰富的监控 API，可以帮助我们做到这一点。
• 多测试，多调优。 缓存的配置没有“银弹”，需要根据实际的业务场景和数据特点进行调整。多测试，多调优，才能找到最佳的缓存配置。
• 了解你的数据和查询模式。 优化缓存使用的最佳方式是深入理解你的数据和查询模式。思考哪些查询经常执行，哪些字段经常用于排序和聚合，哪些索引更新频繁。根据这些信息调整你的缓存策略。

希望今天的分享能对你有所帮助。如果你有任何问题，或者有更好的实践经验，欢迎在评论区留言交流！咱们下期再见！