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 列式存储聚合极快 } } }查询语句层面的优化// ❌ 问题 2terms 聚合 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-*?vsshard # 分片大小黄金法则单个分片 10~50GBJVM 堆的 1/20 # 按日均 5GB 新数据计算 → 30 天 150GB # 150GB / 30GB 20% 缓冲 ≈ 6 个主分片优化后的配置与效果配置项优化前优化后原因主分片数54每个分片 -10GB聚合并行度提升refresh_interval1s30s减少段合并频率写入吞吐 40%translogasyncasync不变但将 sync_interval 从 5s 改为 30smapping fielddata2 个 text 字段0 个释放约 4GB JVM 堆Rollup无按小时历史查询减少 98% 扫描指标优化前优化后聚合查询 P998.2s120ms搜索线程池拒绝率12%0.3%JVM 堆使用率72%48%写入吞吐35K docs/s52K docs/s五、总结Elasticsearch 查询性能优化的优先顺序先改 Mappingtext → 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 落地。