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 只需：
- 在每个分片内重新执行聚合；
- 跳过所有小于
after的文档； - 收集下
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. 常见坑与调优
- “after” 必须包含所有排序键
少传一个字段 ES 会当成null处理，导致跳页错位。 calendar_intervalvsfixed_interval
如果索引跨时区且要求物理 24×60×60 秒，请用fixed_interval=86400s，避免 DST 切换出现 23 h/25 h 桶。- 协调节点合并压力
单页size过大（> 50 000）会让协调节点需要合并全部分片返回，CPU 先打满；建议 5 000–10 000 之间折中。 - 字段类型升级
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 级堆即可稳定扫描全年的历史监控。
更多技术文章见公众号: 大城市小农民
