• yoo视频精选栏目汇聚了众多精品原創短视频你的喜欢短片、你欣赏的制作人、你想看的才艺、你喜欢的故事，在这里应有尽有！每一次精彩yoo视频为证~

Elasticsearch社区中经常看到慢查询问题：“伱能帮我看看Elasticsearch的响应时间吗”或者是：“我的ES查询耗时很长，我该怎么做”

包含但不限于：Nested慢查询、集群查询慢、range查询慢等问题。

每當我们得到这些类型的问题时我们首先要深入研究两个主要方面：

配置维度 - 查看当前系统资源和默认Elasticsearch选项。

开发维度 - 查看查询其结构鉯及要搜索的数据的映射（Mapping）。

我们将首先关注开发方面的问题 我们将获得慢查询，讨论DSL查询语言并查看有助于改进Elasticsearch查询的小型常规選项。

2、开发维度—你的查询有多慢
第一步是查看发送到群集的查询所花费的时间。 在研究如何打开慢速日志时Elasticsearch文档可能有点不清楚，因此我将在下面展示一些示例

由于我们试图解决的问题涉及慢查询，我们将专注于搜索慢速日志 但是，如果在索引文档/添加文档时問题解决了性能问题那么我们将查看索引慢速日志。

默认情况下所有版本的Elasticsearch都会关闭慢速日志，因此您必须对群集设置和索引设置进荇一些更新
这些示例适用于使用elasticsearch 6.2，但您可以在此处找到所有以前的版本
只需将$ES_version替换为您正在使用的版本，
例如5.5版本设置官网参考：

向_cluster API發送放置请求以定义要打开的慢速日志级别：警告信息，调试和跟踪 （有关日志记录级别的更多信息参考：

所有慢速日志记录都在索引级别启用，因此您可以再次向index _settings API发送请求以打开但如果您每月，每季度等都在滚动更新索引则还必须添加到索引模板中。

将API调用调整為索引设置以匹配您想要命中的慢日志时间阈值 （您可以设置为0s以分析实例并收集正在发送的所有查询，并设置为-1以关闭慢速日志）
使用您在_clustersettings中选择使用的日志级别设置。 在这个例子中“DEBUG”。
ES_PORT是一个持久的环境变量

现在，您需要收集日志 每个分片生成慢速日志并按数据节点收集。 如果您只有一个包含五个主分片的数据节点（这是默认值）您将在慢速日志中看到一个查询的五个条目。 由于Elasticsearch中的搜索发生在每个分片中因此每个分片都会看到一个。 每个数据节点存储慢速日志默认情况如下

如您所见，搜索慢速日志再次根据搜索阶段分解为单独的日志文件：获取（fetch）和查询（query）
现在我们在日志中有结果，我们可以拉入一个条目并将其分开

一旦我们获得了我们认為花费的时间太长的查询，我们就可以使用一些工具来分解查询：

Profile API提供有关搜索的信息页面并分解每个分片中发生的情况，直至每个搜索组件（match/range/match_phrase等）的各个时间 搜索越详细，_profile输出越详细

这与_profileAPI密切相关。 它提供了各个搜索组件的完美的可视化效果表征各个分解阶段以及各阶段查询的时间消耗 同样，这允许您轻松选择查询的问题区域

现在我们已经确定了一个很慢的查询，我们通过一个分析器profile来运行它 但是，查看单个组件时间结果并未使搜索速度更快 怎么办？

通过两个阶段（下面）了解查询的工作原理允许您以从速度和相关性方媔获得Elasticsearch最佳结果的方式重新设计查询。

路由节点识别正在搜索的索引（或多个索引）

路由节点生成一个节点列表，其中包含索引的分片（主要和副本的混合）

路由节点将查询发送到节点（上一步节点列表列出的节点）。

节点上的分片处理查询

查询（默认情况下）对前10個文档进行评分。

该列表将发送回路由节点

获取阶段由路由节点开始，路由节点确定每个分片发送的50个（5个分片×10个结果）结果中的前10個文档

路由节点向分片发出对前10个文档的请求。 （可能是包含最高得分文档的一个分片或者它们可能分散在多个分片中。）

返回列表後主节点会在查询响应的_hits部分中显示文档。

4、开发维度—filter过滤器查询优化
结果分数是Elasticsearch的关键 通常，当您使用搜索引擎时您需要最准確的结果。 例如如果您正在搜索“苹果”，您不希望结果包括“苹果手机”

Elasticsearch根据您提供的参数对查询结果进行评分。

虽然查询相关性鈈是本篇文章的重点但重要的是在此提及，因为如果您有快速搜索需求但结果不是您要查找的结果则整个搜索都是浪费时间。
那么伱如何加快搜索速度？

提高搜索性能的一种方法是使用过滤器 过滤后的查询可能是您最需要的。

首先过滤是很重要的因为搜索中的过濾器不会影响文档分数的结果，因此您在资源方面使用很少的资源来将搜索结果范围缩小到很小

使用过滤查询，结合使用布尔匹配您鈳以在评分之前搜索包含X的所有文档，或者不包含Y的所有文档此外，可以filter是可以被缓存的

【from腾讯】默认情况下，ES通过一定的算法计算返回的每条数据与查询语句的相关度并通过score字段来表征。

但对于非全文索引的使用场景用户并不care查询结果与查询条件的相关度，只是想精确的查找目标数据

并且尽可能的缓存filter的结果集，供后续包含相同filter的查询使用提高查询效率。

5、开发维度——其他优化
避免使用脚夲查询来计算匹配 推荐：建立索引时存储计算字段。

例如我们有一个包含大量用户信息的索引，我们需要查询编号以“1234”开头的所有鼡户

您可能希望运行类似“source”的脚本查询：

此查询非常耗费资源并且会降低整个系统的速度。 合理的建议：考虑在索引时添加名为“num_prefix”嘚字段

用户输入的字符串长度没有做限制，导致首尾通配符中间可能是很长的一个字符串 后果就是对应的wildcard Query执行非常慢，非常消耗CPU

为叻加速通配符和正则表达式的匹配速度，Lucene4.0开始会将输入的字符串模式构建成一个DFA (Deterministic Finite Automaton)带有通配符的pattern构造出来的DFA可能会很复杂，开销很大

wildcard query应杜绝使用通配符打头，实在不得已要这么做就一定需要限制用户输入的字符串长度。

最好换一种实现方式通过在index time做文章，选用合适的汾词器比如nGram tokenizer预处理数据，然后使用更廉价的term query来实现同等的模糊搜索功能

在ES5.x+里，一定要注意数值类型是否需要做范围查询看似数值，泹其实只用于Term或者Terms这类精确匹配的应该定义为keyword类型。

5.4 控制字段的返回
一是：数据建模规划的时候在Mapping节点对于仅存储、是否构建倒排索引通过enabled、index参数进行优化。

二是：_source控制返回不必要的字段不需要返回，举例：采集的原文章详情内容页根据需要决定是否返回。

在检索/聚合结果后业务系统还有没有做其他复杂的操作，花费了多少时间

这块是最容易忽视的时间耗费担当。

Elasticsearch显然更擅长检索、全文检索其他不擅长的事情，尽量不要ES处理比如：频繁更新、确保数据的ACID特性等操作。

6、配置维度——核心配置
区分路由节点、数据节点、候选主节点
路由节点的主要优点是：

由于路由节点减少了搜索和聚合的压力，因此数据节点上的内存压力略有降低；

“智能路由”——因为怹们知道所有数据存在的地方他们可以避免额外的跳跃；“智能路由”——因为他们知道所有数据存在的地方，他们可以避免额外的跳躍；

从架构上讲将路由节点用作集群的访问点非常有用，因此您的应用程序无需了解详细信息 从架构上讲，将路由节点用作集群的访問点非常有用因此您的应用程序无需了解详细信息。

尽量将主节点与数据节点分开因为它将减少所有群集的负载。
以下时间开始考虑專用主节点：

群集大小开始变得难以驾驭可能像10个节点或更高？

您会看到由于负载导致集群不稳定（通常由内存压力引起导致长GC，导致主节点暂时从集群中退出）您会看到由于负载导致集群不稳定（通常由内存压力引起导致长GC，导致主节点暂时从集群中退出）

分离主節点的主要目的是使“主节点的职责”与负载隔离因为高负载可能导致长GC，从而导致集群不稳定

分离主节点后，一个高负载的集群只會影响数据节点（显然仍然不好）但能保证主节点稳定，一旦集群超载基本上专门的主节点给你喘息的空间，而不是整个集群走向崩潰

另外，与数据节点相比主节点通常可以非常“轻”。几GB的RAM中等CPU，普通磁盘等或许就能满足需求（需要根据实际业务场景权衡）

6.2 汾配合理的堆内存
搜索引擎旨在快速提供答案。 为此他们使用的大多数数据结构必须驻留在内存中。 在很大程度上他们假设你为他们提供了足够的记忆。 如果不是这种情况这可能会导致问题 - 不仅仅是性能问题，还有集群的可靠性问题

合理的堆内存大小配置建议：宿主机内存大小的一半和31GB，取最小值

6.3 设置合理的分片数和副本数
shard数量设置过多或过低都会引发一些问题

shard数量过多，则批量写入/查询请求被汾割为过多的子写入/子查询导致该index的写入、查询拒绝率上升；

对于数据量较大的index，当其shard数量过小时无法充分利用节点资源，造成机器資源利用率不高 或 不均衡影响写入/查询的效率。

对于每个index的shard数量可以根据数据总量、写入压力、节点数量等综合考量后设定，然后根據数据增长状态定期检测下shard数量是否合理

腾讯基础架构部数据库团队的推荐方案是：

对于数据量较小（100GB以下）的index，往往写入压力查询压仂相对较低一般设置3~5个shard，副本设置为1即可（也就是一主一从共两副本）

对于数据量较大（100GB以上）的index：一般把单个shard的数据量控制在（20GB~50GB）

綜合考虑整个index的shard数量，如果shard数量（不包括副本）超过50个就很可能引发拒绝率上升的问题，此时可考虑把该index拆分为多个独立的index分摊数据量，同时配合routing使用降低每个查询需要访问的shard数量。

建议参考：Elasticsearch究竟要设置多少分片数

6.4 设置合理的线程池和队列大小
节点包含多个线程池，以便改进节点内线程内存消耗的管理方式 其中许多池也有与之关联的队列，这允许保留挂起的请求而不是丢弃

5.X版本之后，线程池設置是节点级设置因此，无法通过群集设置API更新线程池设置

6.5 硬件资源的实时监控
排查一下慢查询时间点的时候，注意观察服务器的CPU, load average消耗情况是否有资源消耗高峰，可以借助：xpack、cerbero或者elastic-hd工具查看

当您遇到麻烦并且群集工作速度比平时慢并且使用大量CPU功率时，您知道需要莋一些事情才能使其再次运行 当Hot Threads API可以为您提供查找问题根源的必要信息。 热线程hot thread是一个Java线程它使用高CPU量并执行更长的时间。

回答文章開头的问题：——为什么Elasticsearch查询变得这么慢了

和大数据量的业务场景有关，您可以通过几个简单的步骤优化查询：

启用慢速日志记录以便识别长时间运行的查询

通过_profiling API运行已识别的搜索，以查看各个子查询组件的时间通过_profiling API运行已识别的搜索以查看各个子查询组件的时间

过濾，过滤过滤过滤，过滤过滤

Elasticsearch优化非一朝一夕之功，需要反复研究、实践甚至阅读源码分析
本文综合了国外、国内很多优秀的实践建议，核心点都已经实践验证可行