Composite Aggregation — 집계 버킷도 스크롤하듯 페이지네이션한다
Elasticsearch term/match 쿼리 구분 및 Composite Aggregation 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(query-dsl-term-query, search-aggregations-bucket-composite-aggregation) Elastic 공식문서 Composite aggregation
이 모듈을 다 읽으면
- Composite Aggregation이 elasticsearch-learn-24의 search_after와 같은 발상을 집계 버킷에 적용한 것임을 설명할 수 있다
- after_key 커서가 어떻게 다음 페이지의 시작점을 지정하는지 설명할 수 있다
elasticsearch-learn-24에서 다룬 search_after(문서를 커서 기반으로 페이지네이션)와 같은 원리를, 이번엔 '문서'가 아니라 '집계 결과 버킷' 전체를 스트리밍하듯 순회하는 데 적용한 Composite Aggregation을 정리한다.
왜 필요한가 — 버킷 수가 많은 다단계 집계
일반 집계는 결과 버킷 전체를 한 응답에 담아 반환한다 — 그런데 group-by 기준이 여러 필드(다단계)라 조합 가능한 버킷 수 자체가 매우 많아지면, 한 번에 다 담아 보내는 방식은 메모리·응답 크기 면에서 비효율적이다. Composite Aggregation은 elasticsearch-learn-24에서 다룬 search_after가 '문서'를 스크롤하듯 순회했던 것과 같은 발상을, 이번엔 '집계 버킷' 전체를 스트리밍하듯 순회하는 데 적용한다.
핵심 포인트
- 다단계 group-by로 조합 가능한 버킷 수가 많아지면 한 번에 전체 반환은 비효율적
- elasticsearch-learn-24의 search_after(문서 스크롤)와 같은 발상을 '집계 버킷' 순회에 적용한 것
after_key — 다음 페이지의 시작점을 지정하는 커서
Composite Aggregation의 각 버킷은 지정한 소스(source)들의 값 조합으로 만들어지고, 항상 그 소스 키 순서로 정렬된다. 다음 페이지를 가져오려면, 이전 응답에서 받은 after_key(소스마다 값 하나씩 담긴)를 다음 요청의 after 파라미터에 그대로 넣으면 된다 — 이 커서 방식 덕분에, 전체 버킷을 메모리에 다 올려두지 않고도(고정된 메모리 사용량으로) 버킷 수와 무관하게 순회할 수 있다. 소스의 순서가 정렬 순서 자체를 결정하므로, 소스 순서를 바꾸면 페이지네이션 결과도 달라진다는 점에 유의해야 한다.
핵심 포인트
- 각 버킷은 지정한 source들의 값 조합, 항상 그 source 키 순서로 정렬 — 이전 응답의 after_key를 다음 요청의 after에 그대로 넣어 다음 페이지 조회
- 커서 방식이라 전체 버킷을 메모리에 안 올려도 됨(고정 메모리 사용량) — source 순서를 바꾸면 정렬·페이지네이션 결과도 달라짐