ElasticSearch使用CompositeAggregation实现桶的分页查询功能

官方文档

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-composite-aggregation.html#_pagination

概述

先聊点实在的：当我们需要分页查询大量桶（bucket）的时候，composite 聚合是当前最优雅的解法。它允许我们通过分页的方式，逐步把桶结果“挤”出来，而不是一口气把所有数据全部砸给你——这在数据量大的场景下简直是救命稻草。

注意，它和传统分页的思路完全不同。传统玩法依赖偏移量（offset）来控制页码，而 composite aggregation 使用的是游标机制。简单说，它不跟你纠结“从第几条开始”，而是直接告诉你“从上一个桶之后接着拿”。这就从根本上绕过了经典分页的性能瓶颈，越往后翻数据效率越稳。

Composite Aggregation 概览

说白了，composite aggregation 是 ES 专门为分页展示聚合结果设计的一种玩法。你去翻翻看，传统的聚合方式大多是一次性返回所有数据，但 composite 不一样——它通过 after 参数来标注“分页锚点”，而不是依赖 from 和 size 来硬算偏移量。这种基于游标的分页模型，在处理大量数据时优势非常明显。

实战：基本的分页查询

假设你有一个索引叫 your_index_name，里面每篇文档都有一个字段 your_field_name。现在你要按这个字段分组，并且每次只取 10 个聚合结果来看。看看下面这个基础查询：

GET /your_index_name/_search{  "size": 0,  "aggs": {    "my_composite_agg": {      "composite": {        "size": 10,         "sources": [          {            "my_terms_agg": {              "terms": {                "field": "your_field_name"              }            }          }        ]      }    }  }}

几个要点值得细说一下：

• size: 0：我们只关心聚合结果，不想要原始文档内容。这能省下不少传输开销。
• composite 聚合：这是分页的关键构造，它会按你指定的聚合规则返回一个分页桶结果集。
• size: 10：控制每页返回多少桶，相当于传统分页里的“每页条数”。
• sources：定义分组逻辑的地方。上面这个例子就是用 terms 按字段值分组。

翻页：获取下一页

分页的核心在于，你得告诉 ES：“我已经看到这个位置了，接下来从这儿往后翻。” 这个“位置”就是上一页返回的最后一个桶的 key 值，用法是通过 after 参数传进去。

来看第二页怎么查：

GET /your_index_name/_search{  "size": 0,  "aggs": {    "my_composite_agg": {      "composite": {        "size": 10,        "after": ["bucket_key_from_first_page"],          "sources": [          {            "my_terms_agg": {              "terms": {                "field": "your_field_name"              }            }          }        ]      }    }  }}

这个小细节很关键：

• after 参数的值就是上一页返回结果中的 after_key。你可以在查询响应的聚合信息里直接找到它。

举个例子，假设第一次查询的返回结果长这样：

{  "aggregations": {    "my_composite_agg": {      "buckets": [        {          "key": { "your_field_name": "value1" },          "doc_count": 10        },        {          "key": { "your_field_name": "value2" },          "doc_count": 15        }      ],      "after_key": { "your_field_name": "value2" }    }  }}

那么第二页查询时，你就把 after 设为 { "your_field_name": "value2" }，ES 就知道从这儿接着往下查了。

官方案例

GET /_search{  "size": 0,  "aggs": {    "my_buckets": {      "composite": {        "size": 2,        "sources": [          { "date": { "date_histogram": { "field": "timestamp", "calendar_interval": "1d" } } },          { "product": { "terms": { "field": "product" } } }        ]      }    }  }}

返回结果：

{  "aggregations": {    "my_buckets": {      "after_key": {        "date": 1494288000000,        "product": "mad max"      },      "buckets": [        {          "key": {            "date": 1494201600000,            "product": "rocky"          },          "doc_count": 1        },        {          "key": {            "date": 1494288000000,            "product": "mad max"          },          "doc_count": 2        }      ]    }  }}

下次查询直接带着 after 走起：

GET /_search{  "size": 0,  "aggs": {    "my_buckets": {      "composite": {        "size": 2,        "sources": [          { "date": { "date_histogram": { "field": "timestamp", "calendar_interval": "1d", "order": "desc" } } },          { "product": { "terms": { "field": "product", "order": "asc" } } }        ],        "after": { "date": 1494288000000, "product": "mad max" }       }    }  }}

什么场景最适用？

说白了，composite aggregation 的强项就是解决下面这几类痛点：

• 海量数据分页：桶的数量越多，传统偏移量方案越吃力。用 composite 可以彻底绕开这类性能陷阱。
• 按字段分组后的分页展示：如果你的场景是先分组、再翻页，那它就是最趁手的工具。
• 防止数据丢或重：传统分页如果遇上数据变动，容易导致翻页时出现数据丢失或重复。而 composite aggregation 的游标机制天然免疫这类问题。

几点需要特别注意

• after 参数的类型必须和 sources 中定义的字段类型保持一致。字符串字段就传字符串，数值字段就传数值，类型对不上可是会报错的。
• 分页顺序依赖于聚合字段的排序规则。如果数据分布不够均匀，每一页返回的桶数可能会略有波动，这点在初始化设计时需要心里有数。
• 虽然 size 可以控制每页桶数，但 composite aggregation 单次最多只能返回 10,000 个桶。如果你覆盖的数据范围超出了这个上限，就需要考虑数据分片或其他优化策略了。

篇幅有限，我们就说到这儿。记住一点：掌握好 composite aggregation，你就能轻松应对大规模桶数据的高效分页查询。