4.2 Elasticsearch-时间序列：date_histogram、composite 分页不爆内存-优快云博客

在这里插入图片描述

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 建立复合桶

GET metric-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_interval vs fixed_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” 异常。