作者：腾讯云大数据 ES 团队

背景概述

日志场景一般具有明显的冷热特点，比如保留 7 天的日志数据，但 P90 查询都集中在近 12 小时，并且在查询日志时一般使用索引前缀查询，比如 filebeat-*，这种查询比指定索引名查询，耗时会长 3 倍以上。而日志场景一般具有近热远冷的特性，例如刚上报的日志数据，往往读写频率较高，而随着时间推移，频率则慢慢降低，因此，通配查询的必要性并不强，如果能根据该特性进行查询剪枝，将能够极大的提升查询效率。

Search 流程浅析

在 ES 中，客户端请求可以发送到集群的任何节点，每个节点都知道任意文档所处的位置，然后转发这些请求，收集数据并返回给客户端，接收客户端请求的节点称为协调节点。协调节点将请求转发给保存数据的数据节点，每个数据节点在本地执行请求，并将结果返回给协调节点，协调节点收集完数据后，将每个数据节点的结果合并为单个全局结果并进行排序，最终将该结果返回给客户端。

基于 search 的搜索操作，搜索任务会被分为两个阶段执行，即 query then fetch，这里需要两个阶段才能完成搜索的原因在于，通过 search 执行搜索任务，在查询的时候无法提前知道文档位于哪些分片，因此索引的所有分片（某个数据副本）都要参与搜素（query），然后协调节点将结果合并，再根据文档 ID 获取（fetch）文档内容。例如，有 10 个分片，我们需要查询返回前 10 个匹配度最高的文档，那么每个分片都需要查询出当前分片的 Top10，协调节点将 10✖️10 的结果再次排序，返回最终 Top10 的结果给客户端。我们可以简单的看下 query then fetch 的流程。

分布式搜索流程

查询裁剪概述

从对 search 流程的分析来看，我们发现耗时主要集中在 query 阶段，由于索引前缀查询匹配到的索引的分片数量大，遍历这些分片的网络请求总耗时很高。为了降低查询延迟，结合日志场景中查询行为冷热明显的特点，我们在自治索引上做了查询裁剪优化，在查询时，协调节点可根据查询条件中指定的时间范围，结合后备索引元数据中记录的时间范围信息，提前进行数据预过滤，降低分片发送请求的数量，使得 PB 级日志查询性能可提高 3 倍以上。

查询裁剪示意图

注：理论上，所需查询的时间范围与数据总的实际时间范围差距越大，查询裁剪优势越明显。 

使用介绍

通过 DSL range 命令执行查询任务，示例如下：

GET /index_name/_search{  "query" : {      "constant_score" : {          "filter" : {              "range" : {                  "@timestamp" : {                      "gte" : "2022-11-01T03:07:34.348+08:00",                      "lt" : "2022-11-02T03:07:34.348+08:00"                  }              }          }      }  }}

通过 SQL 方式执行查询任务，示例如下：

POST /_sql?format=txt{"query": "SELECT * FROM index_name WHERE @timestamp < '2022-11-01'"}

总结

本文从日志场景的查询特点出发，对 ES 的 search 流程进行了简单的分析，并介绍了查询裁剪的基本原理与使用方式。欢迎大家使用腾讯云 ES 与自治索引～