Elasticsearch 查询性能优化：从 8 秒聚合到 120ms 的全链路调优复盘

一、聚合查询的慢如蜗牛：日均 200 万文档的实时聚合为何卡死

业务日志系统的 ES 集群在文档数突破 2 亿后，关键聚合查询（按小时统计错误分布）的耗时从上线初的 800ms 逐步恶化到 8.2s。_cat/tasks 显示大量的 search 任务堆积，_cat/thread_pool 中的 search 线程池拒绝率高达 12%。

常规排查思路会指向"文档太多，需要扩容"，但 ES 集群已经是 6 个热节点 + 4 个暖节点，总内存 256GB。瓶颈不在硬件而在查询设计：这个聚合查询覆盖了过去 7 天的全部文档，触发了每个分片的全局扫描。ES 的聚合默认不走缓存，每次点击都重新计算。

二、查询索引设计：从 Mapping 到查询语句的全面审视

第一步排查是查看 Mapping 和查询语句的性能影响：

json 复制代码

// ❌ 问题 1：使用 text 类型做聚合
// text 字段会触发 fielddata 加载全部词典到 JVM 堆，是 ES 的经典性能陷阱
PUT /logs
{
  "mappings": {
    "properties": {
      "level": {
        "type": "text",        // ❌ 聚合字段不应该是 text 类型
        "fielddata": true      // ❌ fielddata 会消耗大量堆内存
      },
      "service_name": {
        "type": "text",        // ❌ 同上
        "fields": {
          "keyword": {"type": "keyword"}  // ✅ keyword 子字段可用于聚合
        }
      }
    }
  }
}

// ✅ 修复：聚合字段统一使用 keyword 类型
{
  "mappings": {
    "properties": {
      "level": {"type": "keyword"},         // keyword 直接使用 doc_values
      "service_name": {"type": "keyword"}   // doc_values = 列式存储，聚合极快
    }
  }
}

查询语句层面的优化：

json 复制代码

// ❌ 问题 2：terms 聚合 + wildcard 查询叠加
// terms 聚合本身就是重操作，加上 wildcard 扫描性能进一步恶化
POST /logs/_search
{
  "query": {
    "bool": {
      "filter": [
        {"range": {"@timestamp": {"gte": "now-7d", "lte": "now"}}},
        {"wildcard": {"message": {"value": "*timeout*"}}}  // ❌ wildcard 全扫描
      ]
    }
  },
  "aggs": {
    "errors_by_hour": {
      "date_histogram": {"field": "@timestamp", "fixed_interval": "1h"}
    }
  },
  "size": 0  // 不关心命中文档，只要聚合结果
}

// ✅ 优化：用 term 查询替代 wildcard，将过滤条件推入索引
POST /logs/_search
{
  "query": {
    "bool": {
      "filter": [
        {"range": {"@timestamp": {"gte": "now-7d", "lte": "now"}}},
        {"term": {"error_type": "timeout"}}  // ✅ 在写入时预分类
      ]
    }
  },
  "aggs": {
    "errors_by_hour": {
      "date_histogram": {
        "field": "@timestamp",
        "fixed_interval": "1h",
        "min_doc_count": 0  // ⚠️ 保留无数据的小时，填 0
      }
    }
  },
  "size": 0
}

三、Rollup 预聚合：将 7 天的计算量降到 1/60

对于历史数据的聚合，ES 的 Rollup 功能可以在写入时预计算降采样结果：

json 复制代码

// Rollup Job：按小时预聚合错误分布
PUT _rollup/job/error_logs_hourly
{
  "index_pattern": "logs-*",
  "rollup_index": "logs_rollup_hourly",
  "cron": "*/5 * * * * ?",     // 每 5 分钟执行一次
  "page_size": 1000,
  "groups": {
    "date_histogram": {
      "field": "@timestamp",
      "fixed_interval": "1h"    // 按小时聚合
    },
    "terms": {
      "fields": ["error_type", "service_name"]
    }
  },
  "metrics": [
    {"field": "response_time", "metrics": ["avg", "max", "percentiles"]},
    {"field": "error_count", "metrics": ["sum", "min", "max", "value_count"]}
  ]
}

Rollup 索引的文档数约为原始索引的 1/60（每条记录聚合了一小时内的所有文档），查询速度提升了 60 倍：

json 复制代码

// 查询 Rollup 索引（120ms）
POST /logs_rollup_hourly/_rollup_search
{
  "size": 0,
  "aggs": {
    "errors_by_hour": {
      "date_histogram": {
        "field": "@timestamp",
        "fixed_interval": "1h"
      }
    }
  }
}

四、分片规划与刷新间隔

ES 分片数量不当会严重影响聚合性能。默认 5 主分片 + 1 副本 = 10 分片，在 2 亿文档下每个分片约 2000 万文档：

bash 复制代码

# 查看当前分片数量和文档分布
curl -s 'localhost:9200/_cat/shards/logs-*?v&s=shard'

# 分片大小黄金法则：单个分片 10~50GB（JVM 堆的 1/20）
# 按日均 5GB 新数据计算 → 30 天 = 150GB
# 150GB / 30GB + 20% 缓冲 ≈ 6 个主分片

优化后的配置与效果：

配置项	优化前	优化后	原因
主分片数	5	4	每个分片 -10GB，聚合并行度提升
refresh_interval	1s	30s	减少段合并频率，写入吞吐 +40%
translog	async	async	不变，但将 sync_interval 从 5s 改为 30s
mapping fielddata	2 个 text 字段	0 个	释放约 4GB JVM 堆
Rollup	无	按小时	历史查询减少 98% 扫描

指标	优化前	优化后
聚合查询 P99	8.2s	120ms
搜索线程池拒绝率	12%	0.3%
JVM 堆使用率	72%	48%
写入吞吐	35K docs/s	52K docs/s

五、总结

Elasticsearch 查询性能优化的优先顺序：

先改 Mapping：text → keyword 是最高 ROI 的单点优化，释放 fielddata 占用的 JVM 堆，聚合延迟降低 50~70%；
再改查询：wildcard → term、减少扫描范围、善用 filter context（自动缓存）；
预聚合（Rollup）是历史数据查询的终极方案：将 7 天的全量扫描降为汇总数据的定点查询，延迟降低 60~100 倍；
分片规划随着数据量增长需要定期 review：单分片 30~50GB 是最佳区间，过大的分片会增加 GC 压力，过多的小分片会降低聚合并行效率。

通用排查路径 ：_cat/thread_pool（看拒绝率）→ _nodes/hot_threads（看 CPU 热点）→ _profile（看查询内部耗时分布）→ Mapping 审查 → Rollup 落地。