征服ES（ElasticSearch）的慢查询实战

在 Elasticsearch（ES）中，进行大数据查询时，常常会由于多种因素而导致性能显著下降。接下来，我们将深入探讨几种常见情况及其相应的解决方案。

一、常见问题分析

1. 深分页、大排序
   • 大量数据扫描与多分片上的多次排序会严重影响性能。
   • 深分页的性能问题源于 ES 需要扫描并排序大量数据，这一过程不仅要在每个分片上进行扫描排序，还需在主查询节点上进行召回汇总，涉及二次排序。
   • 大排序是指在大量数据上进行排序，同样会带来性能挑战。
2. 通配符查询与正则表达式查询
   • 这两种查询方式容易导致全表扫描，消耗大量资源。
3. 高基数字段聚合
   • 高基数排序可能耗尽内存和计算资源，例如按照玩家 ID 分组进行聚合。
4. 脚本查询
   • 脚本在每个文档上执行，消耗 CPU 和内存，且无法利用缓存。
5. 大字段全文搜索
   • 大字段的倒索引和存储极为耗费资源。

二、解决方案分类介绍

1. 深分页、大排序
   • 深分页：
     • 产品方面：
       • 采用虚拟滚动实现分页，提升用户体验的同时优化性能。
       • 限制总数 track_total_hits，控制在百万以内，例如将 totalCount 最多记录设置为 100 万，多余部分直接显示为 100w+。
     • 技术方面：
       • 使用 search_after 查询方式替代偏移量查询，能显著提升性能。需注意加入 id 或其他唯一字段，确保 after 的条件准确，以保证结果的准确性。
   • 大排序：
     • 多使用 filter 过滤，因为 ES 执行顺序是 query -> filter -> sort。若前两步能排除更多数据，sort 阶段处理的数据量就会减少。
     • 对于 keyword 类型的字段，不要关闭 doc_values，采用列存储。列存储的 keyword 对聚合和排序性能更优，以存储空间换取性能。
2. 通配符查询和正则查询
   • 用 prefix 实现查询，对字段创建正序和倒序两个值索引字段，利用 prefix 进行查询。
   • 使用 ngram 或者 edge gram 分词，虽然会占用更多索引空间，但能提高查询效率。需注意，模糊查询的字段无需评分，应放置在 filter 中，这也是一种以存储空间换性能的方案。
3. 高基数聚合查询
   • 产品和技术配合：在确定需求无误后，可以独立创建另一个粒度的索引。
   • 技术手段：使用 composite 多桶聚合，降低查询压力；预先用 cardinality 判断基数大小。
4. 脚本查询
   • 数据预处理：新建索引，在数据 reindex 时运行脚本，补全需要查询或排序的字段。
   • 脚本优化：尽量将脚本放在 filter 阶段，并且只保留一个脚本。脚本尽量使用 ES 官方的 Painless 开发，提高性能和可维护性。
5. 大字段全文搜索
   • 首先明确大文本的范围：小文本长度在 1KB 以下（约 1000 字符以内）；中等文本长度在 1KB 到 10KB 之间（约 1000 到 10000 字符）；大文本长度在 10KB 以上（约 10000 字符以上）。
   • 处理大文本的两种思路：
     • 分片分段：将大文本字段拆分为多个较小的字段或段落，分别进行索引和查询。
     • 语义搜索：引入 embedding 向量查询，摒弃传统的分词搜索，提升查询效率。