企业官网建设流程全解析

4.2 Elasticsearch-时间序列：date_histogram、composite 分页不爆内存

1. 背景：时间序列聚合的“内存黑洞”

在上一节我们提到，用terms做深度分页时，ES 需要把全局序数（global ordinals）与每个桶的优先级队列常驻堆内，导致 O(N*M) 的内存复杂度（N = 字段基数，M = 分页深度）。把时间维度换成date_histogram后，问题并没有消失，反而因为“时间戳无限可分”变得更隐蔽：

• 如果interval=1s，一年的桶数就是 31 536 000 个；
• 为了支持order by _count desc取第 100 001 页，每个分片仍要维护 Top-K 队列；
• 客户端用size+from翻页时，ES 无法提前释放早期结果，堆内存随页码线性上涨，最终触发 Full GC 甚至 OOM。

官方把这种用法称为“深度堆聚合（deep stacking agg）”，直接打上“not recommended”标签。本节给出两条官方推荐的替代路径——date_histogram+composite以及分区键滚动，保证在 100% 精准排序的前提下，内存占用从“随页码线性”降到“随并发分片数常数”。

2. 核心原理：composite 把“Top-N”变成“Next-N”

composite聚合本质上是“可序列化的排序游标”。它会一次性对所有排序键做多字段前缀排序（date+terms+…），并把当前页最后一条的键值编码成after_key返回。下一次查询带上after参数，ES 只需：

1. 在每个分片内重新执行聚合；
2. 跳过所有小于after的文档；
3. 收集下size个桶。

由于不再需要全局 Top-K 队列，堆内存只与单次size成正比，和页码无关；同时因为after_key是确定性编码，同一游标重复执行得到的结果完全一样，实现“可重放”的分页。

3. 实战：秒级监控数据按天滚动

索引metric-YYYY-MM保存 CPU 利用率，每秒 1 条，字段{ "@timestamp": date, "host": keyword, "cpu": double }。需求：按天统计平均 CPU，并支持后台任务逐天下载，每页 10 000 天。

步骤 1 建立复合桶

GETmetric-2025-*/_search{"size":0,"aggs":{"days":{"composite":{"size":10000,// 每页条数"sources":[{"day":{"date_histogram":{"field":"@timestamp","calendar_interval":"1d"}}},{"host":{"terms":{"field":"host"}}}]},"aggs":{"avg_cpu":{"avg":{"field":"cpu"}}}}}}

返回示例（省略无关字段）：

"aggregations":{"days":{"buckets":[{"key":{"day":1704067200000,"host":"es01"},"avg_cpu":{"value":42.3}},...],"after_key":{"day":1704153600000,"host":"es03"}}}

步骤 2 循环拉取
把after_key原封不动地塞进下一请求：

"composite":{"size":10000,"sources":[...],"after":{"day":1704153600000,"host":"es03"}}

直到返回桶数< 10000即结束。整个过程中堆内存占用 ≈ 10000 × 平均字段基数，与总天数无关。

4. 再进一步：纯时间维度降内存

若只按date_histogram不需要terms，可以把sources压缩成单字段，内存再降一个量级：

"sources":[{"day":{"date_histogram":{"field":"@timestamp","calendar_interval":"1d"}}}]

此时每个桶仅 16 B（long 时间戳 + long doc_count），10 000 桶 ≈ 160 KB，可在协调节点直接缓存，GC 压力几乎为零。

5. 并行导出：利用分区键拆分

当单客户端吞吐不足时，可在composite里追加一个恒定分区键，把流量拆到多进程：

"sources":[{"day":{"date_histogram":{"field":"@timestamp","calendar_interval":"1d"}}},{"_shard":{"terms":{"script":{"source":"doc['_shard'].value & 3"}}}}// 4 分区]

每个进程固定传"after": { "_shard": 0/1/2/3 }，即可线性扩展导出带宽，且仍然保证结果全局有序。

6. 常见坑与调优

1. “after” 必须包含所有排序键
   少传一个字段 ES 会当成null处理，导致跳页错位。
2. calendar_intervalvsfixed_interval
   如果索引跨时区且要求物理 24×60×60 秒，请用fixed_interval=86400s，避免 DST 切换出现 23 h/25 h 桶。
3. 协调节点合并压力
   单页size过大（> 50 000）会让协调节点需要合并全部分片返回，CPU 先打满；建议 5 000–10 000 之间折中。
4. 字段类型升级
   6.x 之前date默认int毫秒，7.x 改为long；跨版本迁移时注意after_key的数值范围，否则会出现 “search_after must be > 0” 异常。

7. 小结

• date_histogram深度分页 +from/size是内存黑洞，生产禁用；
• composite把“Top-N”改“Next-N”，内存复杂度 O(size×并发分片)，与总页码无关；
• 纯时间维度聚合可把sources压到单字段，内存降至百 KB 级；
• 通过脚本分区键可把导出任务横向扩展，单 GB 级堆即可稳定扫描全年的历史监控。
  更多技术文章见公众号: 大城市小农民