Bucket aggregations
Тема дорожной карты · Elasticsearch
Бакетные агрегации в Elasticsearch разбивают документы на группы (бакеты) по значениям полей, диапазонам или другим критериям и при необходимости вычисляют вложенные агрегации внутри каждого бакета. Среди распространённых типов бакетных агрегаций — terms (группировка по значению поля), date_histogram (группировка по временному интервалу), range (группировка по числовым диапазонам) и filter (группировка по произвольному условию Query DSL). По умолчанию каждый бакет содержит счётчик документов, а внутри бакетных агрегаций можно вкладывать метрические или конвейерные агрегации для вычисления статистики — например, средних значений или сумм по каждой группе. Бакетные агрегации отправляются внутри ключа aggs в теле запроса POST /<index>/_search и лежат в основе дашбордов Kibana, отображающих графики и таблицы по данным Elasticsearch. Поскольку бакетные агрегации могут генерировать большие результирующие наборы, Elasticsearch предоставляет параметры size и параметры на уровне шардов для управления потреблением памяти и производительностью таких запросов.
Как это работает
Bucket aggregations: суммируйте + группируйте документы во время query. Bucket aggregations группируют docs (terms = group by field, date_histogram = group by time, range = группы по диапазонам). Metric aggregations считают статы (sum, avg, min/max, percentiles, cardinality). Pipeline aggregations считают над другими aggregations (cumulative sums, moving averages, derivatives). Aggregations — основа Kibana dashboards + log аналитики, но дороги на high-cardinality полях.
Когда применять
Всегда aggregations с filtered query — aggregations по всему индексу дорого. Тюньте size на terms aggregations (дефолт 10 — больше = больше памяти + медленнее). cardinality (HyperLogLog++) для unique counts на масштабе — exact counts квадратичны. Для high-cardinality terms (user IDs) — composite agg + paging вместо одной огромной terms agg.
Типичные ошибки
Ловушки Bucket aggregations: aggregating без фильтра (сканирует весь индекс); огромный size на terms agg (memory blow-up); aggregating на text поле (используйте keyword subfield); не используют shard_size для контроля intra-shard accuracy vs cost trade-off.