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

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 和查询语句的性能影响：

// ❌ 问题 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 = 列式存储，聚合极快 } } }

查询语句层面的优化：

// ❌ 问题 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 功能可以在写入时预计算降采样结果：

// 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 倍：

// 查询 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 万文档：

# 查看当前分片数量和文档分布 curl -s 'localhost:9200/_cat/shards/logs-*?v&s=shard' # 分片大小黄金法则：单个分片 10~50GB（JVM 堆的 1/20） # 按日均 5GB 新数据计算 → 30 天 = 150GB # 150GB / 30GB + 20% 缓冲 ≈ 6 个主分片

优化后的配置与效果：

五、总结

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

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

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