DevOps知识中心
DevOps知识中心

优化缓慢的 Elasticsearch 查询：性能调优的最佳实践

解锁 Elasticsearch 查询的巅峰性能。本指南提供可操作的策略来解决搜索性能不佳的问题，涵盖从优化查询结构和利用强大的缓存机制（节点、分片和文件系统）到使用 Profile API 精准识别瓶颈等基本技术。了解如何构建高效的查询、利用 `_source` 过滤、实现 `search_after` 分页以及解释 profile 结果，以便在生产环境中诊断和解决性能问题。提升您的 Elasticsearch 专业知识，确保闪电般快速的用户体验。

40 浏览量

优化慢速 Elasticsearch 查询：性能调优的最佳实践

Elasticsearch 是一个功能强大、分布式的搜索和分析引擎，能够处理海量数据。然而，即使拥有其健壮的架构，低效的查询仍可能导致性能迟缓，影响用户体验和应用程序响应速度。识别并解决这些瓶颈对于维护一个健康、高性能的 Elasticsearch 集群至关重要。

本文深入探讨了改善慢速搜索性能的实用策略。我们将探讨如何优化查询结构，有效利用各种缓存机制，并使用 Elasticsearch 内置的 Profile API 来精确查明性能问题的根源。通过应用这些最佳实践，您可以显著降低查询延迟，并确保您的 Elasticsearch 集群以最佳效率运行。

理解查询性能瓶颈

在深入解决方案之前，了解导致 Elasticsearch 查询变慢的常见原因会有所帮助。这些原因通常包括：

  • 复杂查询：带有多个 bool 子句、嵌套查询，或在大型数据集上执行 wildcard 或 regexp 等昂贵操作的查询。
  • 低效数据检索：不必要地获取 _source，或为分页检索大量文档。
  • 资源限制：数据节点上的 CPU、内存或磁盘 I/O 不足。
  • 次优映射：使用不正确的数据类型或未充分利用聚合的 doc_values。
  • 分片不平衡或过载：分片过多、分片过少或分片/数据分布不均。
  • 缺乏缓存：未利用 Elasticsearch 内置的缓存机制或外部应用程序级缓存。

优化查询结构

构建查询的方式对其性能有着深远的影响。微小的改变就能带来显著的改进。

1. 仅检索必要的字段 (_source 过滤 & stored_fields)

默认情况下，Elasticsearch 会为每个匹配的文档返回完整的 _source 字段。如果您的应用程序只需要少数几个字段，那么获取整个 _source 会浪费网络带宽和解析时间。

  • _source 过滤：使用 _source 参数指定要包含或排除的字段数组。

    json GET /my-index/_search { "_source": ["title", "author", "publish_date"], "query": { "match": { "content": "Elasticsearch performance" } } }

  • stored_fields：如果您在映射中显式存储了特定字段（例如，"store": true），则可以使用 stored_fields 直接检索它们。这会绕过 _source 解析，如果 _source 很大，速度会更快。

    json GET /my-index/_search { "stored_fields": ["title", "author"], "query": { "match": { "content": "Elasticsearch performance" } } }

2. 优先选择高效的查询类型

某些查询类型本身就比其他类型更占用资源。

  • 避免前导通配符和正则表达式：wildcard、regexp 和 prefix 查询计算成本高昂，尤其是在使用前导通配符（例如，*test）时。它们必须扫描整个词项字典以查找匹配的词项。如果可能，请重新设计您的应用程序以避免使用这些查询，或者使用 completion suggesters 进行前缀匹配。

    ```json

    低效 - 避免前导通配符

    {
    "query": {
    "wildcard": {
    "name.keyword": {
    "value": "*search"
    }
    }
    }
    }

    更好 - 如果您知道前缀

    {
    "query": {
    "prefix": {
    "name.keyword": {
    "value": "Elastic"
    }
    }
    }
    }
    ```

  • 对于短语，使用 match_phrase 而非多个 match 子句：对于精确短语匹配，match_phrase 比在 bool 查询中组合多个 match 查询更高效。

  • 过滤时使用 constant_score：当您只关心文档是否匹配某个过滤器而不关心其评分时，请将查询封装在 constant_score 查询中。这会跳过评分计算，从而节省 CPU 周期。

    json GET /my-index/_search { "query": { "constant_score": { "filter": { "term": { "status": "active" } } } } }

3. 优化布尔查询

  • 子句顺序：将限制性最强的子句（过滤掉最多文档的子句）放在 bool 查询的开头。Elasticsearch 从左到右处理查询，早期剪枝可以显著减少后续子句需要处理的文档数量。
  • minimum_should_match：在 bool 查询中使用 minimum_should_match 来指定必须匹配的 should 子句的最小数量。这有助于早期剪枝结果。

4. 高效分页 (search_after 和 scroll)

传统的 from/size 分页对于深层页面（例如，from: 10000, size: 10）变得非常低效。Elasticsearch 必须在每个分片上检索并排序 from + size 之前的所有文档，然后丢弃 from 个文档。

  • search_after：对于实时深层分页，推荐使用 search_after。它使用前一页最后一个文档的排序顺序来查找下一组结果，类似于传统数据库中的游标。它是无状态的，并且扩展性更好。

    ```json

    第一次请求

    GET /my-index/_search
    {
    "size": 10,
    "query": {"match_all": {}},
    "sort": [{"timestamp": "asc"}, {"_id": "asc"}]
    }

    后续请求使用第一次请求中最后一个文档的排序值

    GET /my-index/_search
    {
    "size": 10,
    "query": {"match_all": {}},
    "search_after": [1678886400000, "doc_id_XYZ"],
    "sort": [{"timestamp": "asc"}, {"_id": "asc"}]
    }
    ```

  • scroll API：对于批量检索大型数据集（例如，用于重新索引或数据迁移），scroll API 是理想的选择。它会创建索引的快照并返回一个滚动 ID，然后用于检索后续批次。它不适用于实时面向用户的分页。

5. 优化聚合

聚合可能会占用大量资源，尤其是在高基数字段上。

  • 预计算聚合：考虑在索引期间或按计划运行复杂的非实时聚合，以预先计算结果并将其存储在单独的索引中。
  • doc_values：确保用于聚合的字段已启用 doc_values（这对于大多数非文本字段是默认设置）。这允许 Elasticsearch 高效地加载用于聚合的数据，而无需加载 _source。
  • eager_global_ordinals：对于频繁用于 terms 聚合的 keyword 字段，在映射中设置 eager_global_ordinals: true 可以通过预先构建全局序数来提高性能。这会在索引刷新时产生开销，但会加快查询时的聚合速度。

利用缓存技术

Elasticsearch 提供了多个缓存层，可以显著加快重复查询的速度。

1. 节点查询缓存

  • 机制：缓存 bool 查询中常用过滤器子句的结果。它是节点级别的内存缓存。
  • 效果：对于在许多查询中保持不变且匹配文档数量相对较少（少于 10,000 个文档）的过滤器最有效。
  • 配置：默认启用。您可以通过 indices.queries.cache.size（默认堆内存的 10%）来控制其大小。

2. 分片请求缓存

  • 机制：在每个分片的基础上缓存搜索请求的整个响应（包括命中、聚合和建议）。它仅适用于 size=0 的请求以及仅使用过滤器子句（无评分）的请求。
  • 效果：非常适合仪表板查询或分析应用程序，在这些场景中，相同的请求（包括聚合）会以相同的参数重复执行。

  • 如何使用：在查询中通过 "request_cache": true 显式启用它。

    json GET /my-index/_search?request_cache=true { "size": 0, "query": { "bool": { "filter": [ {"term": {"status.keyword": "active"}}, {"range": {"timestamp": {"gte": "now-1h"}}} ] } }, "aggs": { "messages_per_minute": { "date_histogram": { "field": "timestamp", "fixed_interval": "1m" } } } }

  • 注意事项：每当分片刷新（索引新文档或更新现有文档）时，缓存就会失效。仅对频繁返回相同结果的查询有用。

3. 文件系统缓存（操作系统级别）

  • 机制：操作系统的文件系统缓存扮演着关键角色。Elasticsearch 严重依赖它来缓存频繁访问的索引段。
  • 效果：对查询性能至关重要。如果索引段在 RAM 中，则完全绕过磁盘 I/O，从而大大加快查询执行速度。
  • 最佳实践：至少将服务器 RAM 的一半分配给文件系统缓存，另一半分配给 Elasticsearch JVM 堆。例如，如果您有 64GB RAM，则将 32GB 分配给 Elasticsearch 堆，并留下 32GB 给操作系统文件系统缓存。

4. 应用程序级缓存

  • 机制：在您的应用程序层实现缓存（例如，使用 Redis、Memcached 或内存缓存）以缓存频繁请求的搜索结果。
  • 效果：可以通过完全绕过 Elasticsearch 来为重复请求提供最快的响应时间。最适合静态或缓慢变化的搜索结果。
  • 注意事项：缓存失效策略是关键。需要仔细设计以确保数据一致性。

使用 Profile API 进行瓶颈识别

Profile API 是一个宝贵的工具，用于精确理解 Elasticsearch 如何执行查询以及时间花费在哪里。它会分解查询和聚合中每个组件的执行时间。

如何使用 Profile API

只需在搜索请求正文中添加 "profile": true。

GET /my-index/_search
{
  "profile": true,
  "query": {
    "bool": {
      "must": [
        {"match": {"title": "Elasticsearch"}},
        {"term": {"status.keyword": "published"}}
      ],
      "filter": [
        {"range": {"publish_date": {"gte": "2023-01-01"}}}
      ]
    }
  },
  "aggs": {
    "top_authors": {
      "terms": {
        "field": "author.keyword",
        "size": 10
      }
    }
  }
}

解析 Profile API 结果

响应将包含一个 profile 部分，详细说明每个分片上的查询和聚合执行情况。需要关注的关键指标包括：

  • description：特定的查询或聚合组件。
  • time_in_nanos：执行此组件所花费的时间。
  • breakdown：详细的子指标，如查询的 build_scorer_time、collect_time、set_weight_time，以及聚合的 reduce_time。
  • children：嵌套组件，显示时间在复杂查询中的分布情况。

示例解读：

如果您看到 WildcardQuery 的 time_in_nanos 很高，则证实这是查询中开销大的一部分。如果 collect_time 很高，则表明匹配后检索和处理文档是一个瓶颈，可能是由于 _source 解析或深层分页。聚合中 reduce_time 较高可能表明在最终合并阶段负载很重。

通过检查这些指标，您可以精确查明消耗最多资源的特定查询子句或聚合字段，然后应用前面讨论的优化技术。

通用性能最佳实践

除了特定于查询的优化之外，一些集群范围和索引级别的最佳实践也有助于提升整体搜索性能。

1. 最佳索引映射

  • text 与 keyword：将 text 用于全文搜索，将 keyword 用于精确值匹配、排序和聚合。类型不匹配可能导致查询效率低下。
  • doc_values：确保用于排序或聚合的字段已启用 doc_values。它默认用于 keyword 和数值类型，但如果稍后需要对 text 字段进行聚合，则显式禁用它会以聚合性能为代价节省磁盘空间。
  • norms：对于不需要文档长度归一化的字段（例如，ID 字段），禁用 norms（"norms": false）。这可以节省磁盘空间并提高索引速度，对非评分查询的查询性能影响最小。
  • index_options：对于 text 字段，如果您只需要知道文档中是否存在某个词项，请使用 index_options: docs；如果您需要短语查询和邻近搜索，请使用 index_options: positions（默认值）。

2. 监控集群健康状况和资源

  • 绿色集群状态：确保您的集群始终处于绿色状态。黄色或红色状态表示分片未分配或缺失，这会严重影响查询可靠性和性能。
  • 资源监控：定期监控数据节点上的 CPU、RAM、磁盘 I/O 和网络使用情况。这些指标的飙升通常与慢速查询相关。
  • JVM 堆内存：密切关注 JVM 堆内存使用情况。高利用率可能导致频繁的垃圾回收暂停，使查询变慢。优化查询以减少堆内存压力。

3. 正确的分片分配

  • 分片过多：每个分片都会消耗资源（CPU、RAM、文件句柄）。节点上分片过多会导致开销。目标是使分片大小合理（例如，大多数用例为 10GB-50GB）。
  • 分片过少：限制并行性。针对分片过少的索引进行的查询将无法有效利用所有可用的数据节点。

4. 索引策略

  • 刷新间隔：较低的 refresh_interval（默认 1 秒）可以更快地使数据可见，但会增加索引开销。对于搜索密集型工作负载，可以考虑稍微增加它（例如，5-10 秒）以减少刷新压力。

总结

优化慢速 Elasticsearch 查询是一个持续的过程，需要理解您的数据、访问模式以及 Elasticsearch 的内部工作原理。通过应用深思熟虑的查询构建、有效利用 Elasticsearch 的缓存机制以及利用 Profile API 等强大的诊断工具，您可以显著提高搜索应用程序的性能和响应能力。

定期监控，并结合使用 Profile API 深入分析特定的慢查询，将使您能够持续完善 Elasticsearch 的设置，确保为您的用户提供快速高效的搜索体验。请记住，结构良好的索引和健康的集群是所有查询优化赖以建立的基础。