$lookup и $unwind: joins в MongoDB

Документная база подталкивает к вложению: позиции заказа можно положить массивом прямо в документ заказа — и связывание не понадобится вовсе. Так и стоит делать, когда данные живут и умирают вместе: элементы корзины бессмысленны без заказа, и читаются они всегда рядом с ним. У вложения есть границы: позиции растут непредсказуемо, их читают отдельно от заказа — товарные отчёты, поставки, остатки на складе, — или сам документ приближается к лимиту в 16 МБ. Тогда данные разъезжаются по коллекциям, и связывать их приходится этапом $lookup. Отдельное правило, которое удивляет после SQL: Find соединить коллекции не умеет — join в MongoDB существует только внутри конвейера агрегации, и никакая опция вызова это не меняет. Поэтому выборку со связыванием собирают Aggregate, даже если фильтр кажется простым. Форма результата тоже непривычна: этап добавляет к каждому документу поле-массив со всеми совпавшими документами, а не плоские колонки соединённой таблицы. Плоскость возвращает отдельный этап $unwind, и это два решения вместо одного JOIN: сначала собрать связанное, потом решить, что с массивом делать — оставить как поле, развернуть в строки или свернуть счётчиком.

Простая форма описывается четырьмя полями. from — имя коллекции в той же базе: сервер не соединяет коллекции из разных баз. localField — поле входного документа, foreignField — поле документа в чужой коллекции, as — имя массива с результатом; связь проверяется на равенство, как JOIN ON a.id = b.order_id. Если совпадений нет, массив останется пустым, а документ не исчезнет: заказ без позиций доедет до выхода с пустым items. Поле as перезаписывается целиком — если имя занято, прежнее значение пропадёт без предупреждения; точечная запись вида items.docs кладёт результат во вложенный документ. Подводный камень после SQL: отсутствующее поле на любой стороне ведёт себя как null, а null совпадает с null — документы без localField найдут чужие документы без foreignField, и связка окажется ложной. Лечение простое: поставить перед $lookup этап $match, который отсеет записи без ключа, или договориться на уровне записи, что поле связи присутствует всегда. Сверять ожидания удобнее в mongosh: тот же конвейер, что уйдёт из Go, выполняется поэтапно, и промежуточный вывод каждого этапа виден глазами. Отдельная мелочь, которая экономит часы отладки: имена полей в описании этапа пишутся строками, и опечатка в foreignField не вызовет ошибку — сервер просто соберёт пустые массивы, поэтому этап связывания проверяют на двух документах раньше, чем вешают на живой трафик.

Этап $unwind принимает ссылку на массив и разворачивает его: по одному выходному документу на каждый элемент, с копией всех остальных полей родителя. Заказ с тремя позициями превращается в три документа с одинаковым номером и разными items; до полей элемента ссылка дотягивается точечной записью — $items.sku работает так же, как в $group. Правило, на котором ломаются отчёты: документ с пустым массивом или вовсе без поля выбрасывается из конвейера. Заказ, оформленный до добавления позиций, из отчёта молча пропадёт — это не ошибка, а семантика этапа. Опция preserveNullAndEmptyArrays: true сохраняет такие документы: массивное поле в выход не попадает, но сам документ продолжает путь по конвейеру и участвует в последующих этапах. После разворота меняется смысл группировки: $group по sku считает позиции по отдельности, и $sum: 1 даёт число строк, а не заказов — счётчик заказов собирается до разворота или через $addToSet с подсчётом уникальных идентификаторов. Понимание того, что unwind mongodb-этап именно разворачивает, а не сплющивает, экономит часы споров с отчётами: каждая цифра после $unwind отвечает за элементы массива, а не за исходные документы. Если в отчёте нужны и заказы, и позиции одновременно, делают два прохода: связка с разворотом для товарной статистики и отдельный конвейер без разворота для заказной — у каждого своя семантика счётчиков.

Простая форма проверяет только равенство двух полей. Как только условие становится сложнее — позиции за период, совпадение по двум полям сразу, агрегат по чужой коллекции, — включается форма с let и pipeline. let объявляет переменные из входного документа: let: bson.M с парой order и $_id. Внутренний pipeline — настоящий конвейер над чужой коллекцией, и переменные доступны в нём через двойной доллар: $order. Первым этапом внутри обычно стоит $match с $expr — оператор сравнивает поля чужого документа с объявленными переменными, потому что обычный синтаксис фильтров переменные не видит. Дальше — что угодно: $project отрежет лишние поля до пересылки, $group свернёт позиции прямо внутри связки и вернёт по одной строке на заказ вместо тысячи элементов массива. Экономия ощутимая на обоих концах: меньше памяти на выходе и меньше работы на последующих этапах. Ограничения той же природы, что у простой формы: from в текущей базе, граница 16 МБ на документ-результат, а сложные сравнения $expr оптимизатор исполняет не всегда предсказуемо — профиль лучше проверить explain-ом, чем угадывать на глаз. Переменные let принимают любые выражения над входным документом: дату из поля, элемент массива по индексу, результат конкатенации — всё, что сервер умеет вычислить до запуска внутреннего конвейера.

$lookup стоит дороже, чем выглядит в коде. На каждый входной документ сервер выполняет запрос в чужую коллекцию, поэтому сотни тысяч заказов превращаются в сотни тысяч подзапросов; без индекса на foreignField каждый подзапрос сканирует чужую коллекцию целиком. Первое лечение — индекс из семнадцатого урока; второе — сузить вход до связывания: $match и $limit перед $lookup режут число подзапросов, потому что оптимизатор не вынесет джойн наверх, как это делает планировщик SQL. Память конвейера та же, что в пятнадцатом уроке: сотня мегабайт на этап, и тяжёлым формам с pipeline включают разрешение на временные файлы через allowDiskUse. Отдельная граница — 16 МБ на сам выходной документ: массив items с тысячами позиций добирается до потолка BSON, и отчёт падает с ошибкой вместо результата. Лечится свёрткой внутри формы с pipeline — считать сумму и среднее по позициям можно ещё в связке, — либо переносом связывания на этап записи, то есть вложением, когда жизненные циклы данных это позволяют. Джойн в документной базе реален, просто оплачивается в другом месте — и лучше до продакшена. Число для калибровки простое: подзапрос с индексом стоит спуск по дереву, без — чтение всей чужой коллекции; на сотне документов разницы нет, на миллионе она измеряется секундами.