诊断和修复 Elasticsearch 搜索查询缓慢问题

Elasticsearch 搜索缓慢通常源于宽泛的查询、昂贵的聚合、映射选择、分片布局或集群资源压力。如果您的搜索 API 开始超时，或者随着索引增长延迟飙升，您需要确定是查询、索引还是集群承担了过多工作。

使用慢查询日志和 Profile API 来定位耗时部分，然后根据证据调整查询、映射、分片策略或硬件。

Elasticsearch 搜索缓慢的常见原因

多种因素可能导致搜索查询缓慢。在您的环境中确定具体原因对于有效故障排除至关重要。

1. 低效查询

查询设计通常是影响搜索性能最直接的因素。复杂或结构不良的查询会迫使 Elasticsearch 做大量工作，导致延迟增加。

• 宽泛查询： 扫描大量文档或字段且没有充分过滤的查询。
  • 示例： 在大型索引上执行 match_all 查询。
• 深度分页： 使用 from 和 size 请求非常大的页面。对于面向用户的深度分页，建议使用带有稳定排序和时间点搜索的 search_after。滚动查询主要用于批处理或重新索引类工作负载。
• 复杂聚合： 过于复杂或资源密集的聚合，尤其是与宽泛查询结合使用时。
• 通配符查询： 前导通配符（例如 *term）效率特别低，因为它们无法有效利用倒排索引查找。尾随通配符通常更好，但在大数据集上仍然可能很慢。
• 正则表达式查询： 这些查询计算成本可能很高，应谨慎使用。

2. 映射问题

数据的索引方式（由映射定义）深刻影响搜索速度。错误的映射选择可能导致索引效率低下和搜索速度变慢。

• 动态映射： 虽然方便，但动态映射有时会导致意外的字段类型或创建不必要的 analyzed 字段，从而增加索引大小和搜索开销。
• text 与 keyword 字段： 在需要精确匹配、排序或聚合时使用 text 字段，而 keyword 字段更合适。text 字段经过分析用于全文搜索，而 keyword 字段按原样索引，非常适合精确匹配、排序和聚合。
  • 示例： 如果您需要按产品 ID (PROD-123) 进行过滤，则应将其映射为 keyword，而不是 text。

  PUT my-index
  {
    "mappings": {
      "properties": {
        "product_id": {
          "type": "keyword"
        }
      }
    }
  }
  

• 旧的 _all 字段假设： 较旧版本的 Elasticsearch 有一个 _all 字段，用于索引其他字段的内容。现代版本已移除它，因此当您需要组合搜索文本时，请使用显式字段或 copy_to。
• 嵌套数据结构： 使用 nested 数据类型对于维护关系非常强大，但如果查询不当，与 flattened 或 object 类型相比，它在查询时可能更消耗资源。

3. 硬件和集群配置

底层基础设施以及 Elasticsearch 的配置方式对性能起着关键作用。

• 硬件资源不足：
  • CPU： 高 CPU 使用率可能表明查询效率低下或索引/搜索负载过重。
  • RAM： RAM 不足会导致磁盘 I/O 增加，因为操作系统会进行内存交换。Elasticsearch 也严重依赖 JVM 堆和操作系统文件系统缓存。
  • 磁盘 I/O： 慢速磁盘（尤其是 HDD）是主要瓶颈。建议在生产 Elasticsearch 集群中使用 SSD。
• 分片大小和数量：
  • 过多小分片： 每个分片都有开销。大量小分片可能会压垮集群。
  • 过少大分片： 大分片可能导致恢复时间过长和负载分布不均。
  • 一般指导原则： 对于许多日志和搜索工作负载，分片大小在几十 GB 是常见的，但合适的大小取决于数据量、查询模式、恢复目标和节点资源。
• 副本： 虽然副本提高了可用性和读取吞吐量，但它们也增加了索引开销和磁盘空间使用。过多的副本可能会消耗资源。
• JVM 堆大小： 配置不当的 JVM 堆可能导致垃圾回收暂停。一个常见的起点是不超过系统 RAM 的一半，同时为操作系统文件系统缓存留出足够的内存。请遵循您 Elasticsearch 版本的堆指导。
• 网络延迟： 在分布式环境中，节点间的网络延迟会影响节点间通信和搜索协调。

4. 影响搜索的索引性能问题

虽然本文重点讨论搜索，但索引过程中的问题可能会间接影响搜索速度。

• 高索引负载： 如果集群难以跟上索引请求，可能会影响搜索性能。这通常是由于硬件不足或索引策略优化不佳造成的。
• 大量段： 频繁索引而不定期合并段会导致大量小段。虽然 Elasticsearch 会自动合并段，但此过程消耗资源，并可能暂时减慢搜索速度。

诊断慢查询

在实施修复之前，您需要确定哪些查询慢以及为什么慢。

1. Elasticsearch 慢查询日志

配置 Elasticsearch 以记录慢查询。这是识别问题搜索请求最直接的方法。

• 配置： 按索引设置慢查询阈值。使用 Elasticsearch 期望的日志级别后缀，例如 warn、info、debug 或 trace。

  PUT _settings
  {
    "index": {
      "search": {
        "slowlog": {
          "threshold": {
            "query": {
              "warn": "1s"
            },
            "fetch": {
              "warn": "1s"
            }
          }
        }
      }
    }
  }
  

  • query：记录执行查询阶段超过指定阈值的查询。
  • fetch：记录执行获取阶段（检索实际文档）超过指定阈值的查询。
• 日志位置： 慢查询日志通过 Elasticsearch 日志记录写入，并且根据您的包、部署平台和日志配置，通常出现在单独的搜索慢查询日志文件中。

2. Elasticsearch 监控工具

利用监控工具深入了解集群健康和性能。

• Elastic Stack 监控： 配置后，提供 CPU、内存、磁盘 I/O、JVM 堆使用率、查询延迟、索引速率等仪表板。
• APM（应用程序性能监控）： 可以帮助跟踪从应用程序到 Elasticsearch 的请求，识别应用程序或 Elasticsearch 级别的瓶颈。
• 第三方工具： 许多外部工具提供高级监控和分析功能。

3. Analyze API

_analyze API 可以帮助理解文本字段如何被分词和处理，这对于调试全文搜索问题至关重要。

• 示例： 查看查询字符串是如何处理的。

  GET my-index/_analyze
  {
    "field": "my_text_field",
    "text": "Quick brown fox"
  }
  

4. Profile API

对于非常具体的查询性能调优，Profile API 可以提供搜索请求每个组件的详细计时信息。

• 示例：

  GET my-index/_search
  {
    "profile": true,
    "query": {
      "match": {
        "my_field": "search term"
      }
    }
  }
  

修复慢查询：解决方案和优化

一旦确定了根本原因，就可以实施有针对性的解决方案。

1. 优化查询

• 过滤上下文： 对于不需要评分的条件，使用 filter 子句。Elasticsearch 可以将这些作为是/否过滤器执行，并且可能会缓存常用过滤器。

  GET my-index/_search
  {
    "query": {
      "bool": {
        "must": [
          { "match": { "title": "elasticsearch" } }
        ],
        "filter": [
          { "term": { "status": "published" } },
          { "range": { "publish_date": { "gte": "now-1M/M" } } }
        ]
      }
    }
  }
  

• 避免前导通配符： 如果可能，重写查询以避免前导通配符（*term）。考虑使用 ngram 分词器或替代搜索方法。
• 限制字段扫描： 在查询和响应的 _source 过滤中，仅指定您需要的字段。
• 使用 search_after 进行深度分页： 对于浅层页面之外的交互式分页，请使用带有确定性排序的 search_after。对于大型导出，根据您的 Elasticsearch 版本和工作负载，使用滚动查询或时间点加 search_after。
• 简化聚合： 审查并优化复杂聚合。考虑使用 composite 聚合进行聚合的深度分页。
• 使用 keyword 进行精确匹配/排序： 确保用于精确匹配、排序或聚合的字段映射为 keyword。

2. 改进映射

• 显式映射： 为索引定义显式映射，而不是仅仅依赖动态映射。这确保字段以正确的类型进行索引。
• 谨慎使用 _source 和 doc_values： 禁用 _source 可能会破坏更新、重新索引、高亮显示和调试工作流程。在用于排序或聚合的字段上禁用 doc_values 会损害这些工作负载。将这些视为存储优化，而不是默认的搜索修复。
• index_options： 对于 text 字段，微调 index_options 以仅存储必要的信息（例如，短语查询的位置）。

3. 硬件和集群调优

• 升级硬件： 投资更快的 CPU、更多 RAM，尤其是 SSD。
• 优化分片策略： 审查您的分片数量和大小。如有必要，考虑将数据重新索引到具有优化分片策略的新索引中。使用索引生命周期管理 (ILM) 等工具管理基于时间的索引及其分片。
• 调整 JVM 堆： 确保 JVM 堆大小正确（例如，RAM 的 50%，最大 30-32GB）并监控垃圾回收。
• 节点角色： 将角色（主节点、数据节点、摄取节点、协调节点）分布到不同的节点，以防止资源争用。
• 增加副本（适用于读取密集型工作负载）： 如果瓶颈是读取吞吐量而不是索引，请考虑添加更多副本，但需监控对索引的影响。

4. 索引优化

• 强制合并： 仅对只读索引运行 _forcemerge，因为较少的段有助于搜索和存储。此操作资源密集，并且可能创建非常大的段，如果索引持续接收写入，重写这些段的成本很高。

  POST my-index/_forcemerge?max_num_segments=1
  

• 索引生命周期管理 (ILM)： 使用 ILM 自动管理索引，包括对较旧的非活动索引进行强制合并等优化阶段。

保持性能的最佳实践

• 定期监控： 持续监控是及早发现性能回退的关键。
• 测试更改： 在将重大更改部署到生产环境之前，先在预发布环境中进行测试。
• 了解您的数据和查询： 最佳优化是特定于上下文的。了解您拥有什么数据以及如何查询它。
• 保持 Elasticsearch 更新： 较新版本通常包含性能改进和错误修复。
• 合理调整集群规模： 避免过度配置或配置不足资源。定期评估集群的需求。

要点

通过先测量来修复 Elasticsearch 搜索缓慢问题。慢查询日志告诉您哪些请求有问题，Profile API 显示时间花在哪里，集群指标显示查询是否与堆压力、磁盘 I/O、索引或分片开销竞争。进行一次更改，重新运行相同的查询，并且仅在延迟和资源使用改善时保留结果。