Агрегации: $match и $group

Конвейер агрегации — список этапов, где выход одного становится входом следующего. В драйвере он выражается типом mongo.Pipeline — срезом bson.D: каждый элемент — упорядоченный документ с одним ключом-этапом, и именно упорядоченность делает bson.D здесь обязательным. Вызов coll.Aggregate(ctx, pipeline) возвращает знакомый *Cursor из седьмого урока — читается он теми же Next, All и Err, поэтому всё, что вы знаете о курсорах, работает. Порядок этапов значим: $match до $group — это WHERE до GROUP BY, $match после — аналог HAVING. Пришедшим из SQL с pgx карта соответствий знакома: фильтр — WHERE, группировка — GROUP BY, накопители — агрегатные функции SUM и AVG, сортировка этапа — ORDER BY. Ключевое отличие — место вычислений: свёртка происходит на сервере базы, поэтому конвейер проектируют от объёмов данных: сначала сузить, потом сворачивать и только в конце придавать форму отчёту. Тип mongo.Pipeline — псевдоним обычного среза bson.D: собрать конвейер можно и без псевдонима, разницы для драйвера нет — имя существует ради читаемости. На каждый документ конвейера действует правило одного ключа: попытка уложить два этапа в один bson.D упадёт с ошибкой сервера «этап обязан содержать ровно одно поле». Карту соответствий полезно держать в голове и при чтении чужих конвейеров: увидел $group с _id — это GROUP BY, увидел накопитель с долларом — вызов функции над группой.

Этап $match использует тот же синтаксис, что и фильтры из восьмого и четырнадцатого уроков: равенства, $gt, $in, $or — учить новый язык не надо. Разница в позиции и в последствиях. $match, поставленный первым, сужает выборку до группировки, и сервер может опираться на индексы — тот же план исполнения, что у обычного Find. Двигать фильтр после $group бессмысленно и дорого: сначала свернули миллион документов, потом отфильтровали итог — вся работа сделана впустую. Законен и второй $match после группировки — так выглядит HAVING из SQL: «только категории с выручкой больше ста тысяч». Практическое правило mongo aggregation go-кода: каждый $match в начале конвейера экономит работу всех последующих этапов, поэтому условия выносят как можно раньше — из всех оптимизаций агрегаций эта даёт самый предсказуемый эффект и не требует ничего, кроме перестановки этапов. Условия внутрь $match уезжают без изменений: $in, $or и $regex из прошлых уроков работают здесь же. «Только оплаченные за март» — один $match с $gte и $lt по дате и равенством статуса — и уже после него группировка считает в разы меньше. Оптимизатор сервера умеет сам протаскивать $match ближе к началу конвейера, когда это безопасно, но рассчитывать на это не стоит: перестановка этапов руками бесплатна и предсказуема.

Этап $group описывается документом, где _id — ключ группировки, а остальные поля — накопители. Ссылка на поле входного документа начинается с $: _id: "$category" сворачивает заказы по категориям. nil в _id — одна глобальная группа: все входные документы становятся единственным итогом, так считают общую выручку или средний чек по выборке. Накопители — операции свёртки: $sum и $avg для арифметики, $min и $max для границ, $push для сбора значений в массив. Конструкция $group в mongodb повторяет GROUP BY с одной оговоркой: накопитель с $sum: 1 — привычный счётчик документов, единица за каждый вход. Типовая ошибка — забыть $ перед именем поля: {"$sum": "price"} получает литеральную строку вместо ссылки, $sum игнорирует нечисловые значения, и отчёт молча печатает нули. Имя накопителя вы выбираете сами: revenue, avg, orders — оно станет ключом выходного документа и полем отчётной структуры. Порядок полей в этапе отражается в выходном документе: _id первым — удобно и в логах, и при просмотре в mongosh. Отдельный сахар — этап $count: {$count: "total"} заменяет связку $group с _id: nil и $sum: 1, когда нужно просто число совпадений. Это именно этап, а не накопитель: внутрь $group его не положишь. Родственник $push — $addToSet: собирает те же значения в массив, но дубликаты пропускает.

Aggregate возвращает (*Cursor, error) — живой курсор с батчами, как у Find. Для отчётов чаще хватает cursor.All: он декодирует весь результат в срез и закрывает курсор сам — механика седьмого урока без изменений. Форму результата задают этапы: _id несёт ключ группировки, накопители — свои имена. Для стабильных отчётов заводите структуру с bson-тегами из пятого урока: тег _id у поля Category, теги revenue и avg у накопителей — компилятор, автодополнение и типы вместо скролла по bson.M. Для разовых скриптов bson.M честнее: отчёт меняется каждую неделю, и структуры за ним не угоняются. Типы при декодировании стоят отдельного внимания: $avg возвращает float64 даже для целых входов, поэтому поле отчёта — float64, иначе Decode вернёт ошибку несовместимости; счётчик $sum: 1 сервер отдаёт целым числом, и поле int64 принимает его без потерь — драйвер декодирует и int32, и int64. Ошибка Decode при несовместимости типов поднимается из cursor.All и падает наружу с контекстом через fmt.Errorf. Для длинных отчётов курсор можно читать построчно через Next — механика седьмого урока: строка декодировалась, обработалась, забылась; для типовых панельных отчётов All проще и безопаснее.

Ключ _id: bson.M{"category": "$category", "day": "$day"} строит статистику по пересечению полей — отчёт по категориям за каждый день. Порядок полей составного ключа не меняет смысл группировки, но отражается в виде выходного документа. Двумя границами сервера стоит знать заранее. Первая: документ группы — обычный BSON-документ с лимитом 16 МБ; суммам и средним это не грозит, а вот $push, собирающий все sku огромной группы, до потолка доберётся. Промежуточные документы конвейера подчиняются тому же лимиту в 16 МБ, что и хранимые, — поэтому длинный $push доберётся до границы раньше, чем память этапа. Лечится гранулярностью: в группу агрегируйте числа, а списки режьте проекцией с $slice после группировки. Вторая: память конвейера по умолчанию ограничена сотней мегабайт на этап — крупные свёртки падают с ошибкой, и тогда включают разрешение на диск: options.Aggregate().SetAllowDiskUse(true). Это не «сделать быстрее», а «сделать возможным»: обмен с временными файлами медленнее памяти, и лучшее лечение — сузить $match, чтобы большие свёртки вообще не возникали.