Как профилировать и оптимизировать медленные конвейеры агрегации MongoDB

Конвейеры агрегации MongoDB легко разрастаются по одному этапу за раз. Отчет начинается с $match, затем кто-то добавляет $lookup, затем $group, затем сортировку, и через шесть месяцев конечная точка становится настолько медленной, что все боятся к ней прикасаться.

Исправление начинается с доказательств. Вам нужно знать, какой этап читает слишком много, расширяет слишком много, сортирует слишком много или присоединяет слишком поздно. MongoDB предоставляет два практических инструмента для этой работы: профилировщик базы данных для исторических медленных операций и .explain("executionStats") для детального изучения одного конвейера.

Понимание профилировщика MongoDB

Профилировщик MongoDB записывает детали выполнения операций базы данных, включая команды find, update, delete и, что наиболее важно для этого руководства, aggregate. Он записывает, сколько времени заняла операция, какие ресурсы она потребила и какие этапы внесли наибольший вклад в задержку.

Включение и настройка уровней профилирования

Прежде чем вы сможете профилировать, вы должны убедиться, что профилировщик активен и установлен на уровень, который захватывает необходимые данные. Уровни профилирования варьируются от 0 (выключен) до 2 (регистрируются все операции).

Уровень	Описание
0	Профилировщик отключен.
1	Регистрирует операции, которые выполняются дольше, чем настройка `slowOpThresholdMs`.
2	Регистрирует все операции, выполняемые в базе данных.

Чтобы установить уровень профилирования, используйте команду db.setProfilingLevel(). Обычно рекомендуется временно использовать Уровень 1 или 2 во время тестирования производительности, чтобы избежать чрезмерного ввода-вывода на диск.

Пример: Установка профилировщика на Уровень 1 (регистрация операций медленнее 100 мс)

// Подключитесь к вашей базе данных: use myDatabase
db.setProfilingLevel(1, { slowOpThresholdMs: 100 })

// Проверьте настройку
db.getProfilingStatus()

Лучшая практика: Никогда не оставляйте профилировщик на Уровне 2 в производственной системе на неопределенный срок, так как регистрация каждой операции может значительно повлиять на производительность записи.

Просмотр профилированных данных агрегации

Профилированные операции хранятся в коллекции system.profile в базе данных, которую вы профилируете. Вы можете запросить эту коллекцию, чтобы найти недавние медленные агрегации.

Чтобы найти медленные запросы агрегации, вы фильтруете результаты, где поле op равно 'aggregate', а время выполнения (millis) превышает ваш порог.

// Найти все медленные операции агрегации за последний час
db.system.profile.find(
  {
    op: 'aggregate',
    millis: { $gt: 100 } // Операции медленнее 100 мс
  }
).sort({ ts: -1 }).limit(5).pretty()

Анализ деталей выполнения конвейера агрегации

Вывод профилировщика имеет решающее значение. Когда вы изучаете документ медленной агрегации, обратите внимание на planSummary и, что более важно, на массив stages в результате.

Использование подробного вывода `.explain('executionStats')`

В то время как профилировщик захватывает исторические данные, запуск агрегации с .explain('executionStats') предоставляет в реальном времени детальную информацию о том, как MongoDB выполнила конвейер на текущем наборе данных, включая время выполнения каждого этапа.

Пример использования Explain:

db.collection('sales').aggregate([
  { $match: { status: 'A' } },
  { $group: { _id: '$customerId', total: { $sum: '$amount' } } }
]).explain('executionStats');

В выводе массив stages детализирует каждый оператор в конвейере. Для каждого этапа ищите:

executionTimeMillis: Время, затраченное на выполнение этого конкретного этапа.
nReturned: Количество документов, переданных на следующий этап.
totalKeysExamined / totalDocsExamined: Метрики, указывающие на стоимость ввода-вывода.

Этапы с очень высоким executionTimeMillis или этапы, которые просматривают гораздо больше документов (totalDocsExamined), чем возвращают, являются вашими основными целями для оптимизации.

Стратегии оптимизации медленных этапов агрегации

Как только профилирование определит узкое место (например, этапы $match, $lookup или сортировки), вы можете применить целевые методы оптимизации.

1. Оптимизация начальной фильтрации (`$match`)

Этап $match всегда должен быть первым этапом в вашем конвейере, если это возможно. Фильтрация на раннем этапе уменьшает количество документов, которые должны обрабатывать последующие ресурсоемкие этапы (например, $group или $lookup).

Роль индексирования: Если ваш начальный этап $match медленный, почти наверняка отсутствует индекс на полях, используемых в фильтре. Убедитесь, что индексы покрывают поля, используемые в $match.

Если этап $match включает поля, которые не индексированы, этап может выполнить полное сканирование коллекции, что будет явно видно в выводе explain как высокое totalDocsExamined.

2. Эффективное использование `$lookup` (Объединения)

Этап $lookup часто является самым медленным компонентом. Он эффективно выполняет анти-объединение с другой коллекцией.

Индексируйте внешний ключ: Убедитесь, что поле, по которому вы объединяетесь во внешней (просматриваемой) коллекции, индексировано. Это значительно ускоряет внутренний процесс поиска.
Фильтруйте перед объединением: Когда это возможно, применяйте этап $match перед $lookup, чтобы гарантировать, что вы объединяетесь только с необходимыми документами.

3. Решение проблемы дорогостоящей сортировки (`$sort`)

Сортировка документов требует больших вычислительных ресурсов, особенно для больших наборов результатов. MongoDB может использовать индекс для сортировки только в том случае, если префикс индекса соответствует фильтру запроса, а порядок сортировки соответствует определению индекса.

Ключевая оптимизация для $sort: Если этап $sort кажется дорогостоящим, попробуйте создать покрывающий индекс, который соответствует фильтру и требуемому порядку сортировки. Например, если вы фильтруете по { status: 1 }, а затем сортируете по { date: -1 }, индекс на { status: 1, date: -1 } позволит MongoDB извлекать документы в требуемом порядке без дорогостоящей сортировки в памяти.

4. Минимизация перемещения данных с помощью `$project`

Используйте этап $project стратегически, чтобы уменьшить объем данных, передаваемых по конвейеру. Если последующим этапам нужны только несколько полей, используйте $project на раннем этапе конвейера, чтобы отбросить ненужные поля и встроенные документы. Меньшие документы означают меньше данных, перемещаемых между этапами конвейера, и потенциально лучшее использование памяти.

5. Избегание дорогостоящих этапов, которые не могут использовать индексы

Такие этапы, как $unwind, могут создавать много новых документов, быстро увеличивая накладные расходы на обработку. Хотя иногда это необходимо, убедитесь, что входные данные для $unwind максимально малы. Аналогично, этапы, которые вынуждают полную переоценку набора данных, такие как те, которые полагаются на вычисления или сложные выражения без поддержки индекса, должны быть сведены к минимуму.

Реалистичный пример оптимизации

Представьте панель поддержки, которая показывает общую сумму возвратов по клиентам за последние 30 дней. Сначала она работала быстро, затем стала медленной после накопления заказов за год. Конвейер выглядит безобидно:

db.orders.aggregate([
  { $lookup: {
      from: "customers",
      localField: "customerId",
      foreignField: "_id",
      as: "customer"
  }},
  { $unwind: "$customer" },
  { $match: { status: "refunded", createdAt: { $gte: startDate } } },
  { $group: { _id: "$customerId", totalRefunded: { $sum: "$amount" } } },
  { $sort: { totalRefunded: -1 } },
  { $limit: 50 }
])

Дорогостоящая ошибка не очевидна, пока вы не посмотрите на порядок работы. Этот конвейер объединяет каждый заказ с клиентом, прежде чем отфильтровать возвращенные заказы за последние 30 дней. В большой коллекции это означает, что MongoDB выполняет много объединений для документов, которые будут отброшены позже.

Лучшая первая версия фильтрует рано:

db.orders.aggregate([
  { $match: { status: "refunded", createdAt: { $gte: startDate } } },
  { $group: { _id: "$customerId", totalRefunded: { $sum: "$amount" } } },
  { $sort: { totalRefunded: -1 } },
  { $limit: 50 },
  { $lookup: {
      from: "customers",
      localField: "_id",
      foreignField: "_id",
      as: "customer"
  }},
  { $unwind: "$customer" }
])

Теперь объединение происходит только для 50 лучших сгруппированных клиентов, а не для каждого заказа в коллекции. Это тот тип изменений, к которому должно приводить профилирование: меньше данных попадает в дорогостоящие этапы.

Для этой версии полезный индекс на orders может быть:

db.orders.createIndex({ status: 1, createdAt: -1, customerId: 1 })

Точный индекс зависит от ваших реальных фильтров и потребностей в сортировке, но идея стабильна: поддерживать ранний $match и включать поля, которые помогают конвейеру избегать лишнего чтения документов, когда это возможно. В коллекции customers _id уже индексирован, поэтому $lookup обычно в порядке. Если вы объединяетесь по другому полю, индексируйте это внешнее поле.

При просмотре .explain("executionStats") не смотрите только на общее время выполнения. Ищите разветвление. Если один этап возвращает 500 документов, а следующий возвращает 2 миллиона из-за $unwind, вы нашли этап, который изменил форму проблемы. Если totalDocsExamined намного больше, чем nReturned, индекс недостаточно селективен или используется не так, как вы ожидали. Если сортировка появляется поздно в конвейере после большой группы, подумайте, можете ли вы ограничить раньше или предварительно агрегировать в отдельную коллекцию для панелей, которым не нужна свежесть с точностью до секунды.

Также следите за поведением памяти. $group, $sort, $setWindowFields и некоторые шаблоны $lookup могут требовать много памяти. allowDiskUse: true может предотвратить сбой конвейера при превышении лимитов памяти, но сам по себе это не является исправлением производительности. Сброс на диск обычно означает, что конвейер выполняет слишком много работы за раз. Это может быть приемлемо для ночного отчета. Это редко приемлемо для конечной точки API, ориентированной на пользователя, которая выполняется при каждой загрузке страницы.

Одна практическая привычка — сохранять медленный конвейер, вывод explain и индексы вместе в заметках об инциденте. Следующий человек не должен заново открывать, почему существует индекс или почему $lookup был перемещен после $limit. Настройка агрегации намного проще, когда обоснование переживает сеанс отладки.

Индексы, которые помогают агрегациям, и индексы, которые только выглядят полезными

Конвейеры агрегации часто выявляют слабые составные индексы. Предположим, ваш API фильтрует по арендатору и дате, затем группирует по статусу:

db.orders.aggregate([
  { $match: { tenantId, createdAt: { $gte: start, $lt: end } } },
  { $group: { _id: "$status", count: { $sum: 1 } } }
])

Индекс на { createdAt: -1 } может немного помочь, но в мультитенантной системе он все равно может сканировать большой диапазон дат для каждого арендатора. Индекс на { tenantId: 1, createdAt: -1 } обычно лучше соответствует шаблону доступа, потому что он сначала сужает до арендатора, а затем проходит по диапазону дат. Если большинство запросов также включают статус, проверьте, не лучше ли { tenantId: 1, status: 1, createdAt: -1 } для этой рабочей нагрузки. Не гадайте. Запустите explain, сравните keysExamined, docsExamined и затраченное время на данных, похожих на производственные.

Будьте осторожны с полями низкой кардинальности в начале индекса. Индекс, начинающийся с { status: 1 }, может быть неселективным, если почти каждый заказ имеет статус complete. Он все еще может быть полезен в сочетании с другими полями, но должен отражать форму запроса. Лучший индекс — это не тот, у которого больше всего полей; это тот, который сокращает пространство поиска на раннем этапе, не создавая излишних накладных расходов на запись.

Когда прекращать оптимизацию конвейера

Иногда правильным решением является не очередное переписывание конвейера. Если панель запускает одну и ту же дорогостоящую агрегацию каждый раз, когда менеджер открывает страницу, предварительная агрегация может быть чище. Запланированное задание может записывать почасовые итоги в коллекцию order_stats_hourly, а панель может читать несколько небольших документов. Вы обмениваете свежесть на предсказуемую задержку.

Этот обмен часто приемлем, когда люди читают тренды. Это менее приемлемо, когда конвейер обеспечивает решение о checkout или правило обнаружения мошенничества. Сделайте требование к свежести явным. "В течение пяти минут" открывает предварительную агрегацию и кэширование. "Должен включать последний подтвержденный заказ", вероятно, оставляет вас ближе к чтению в реальном времени с более строгим поведением записи и чтения.

Оптимизация агрегации заключается не в том, чтобы сделать каждый конвейер умным. Речь идет об устранении работы, которую база данных не должна выполнять на пути запроса.

Резюме и следующие шаги

Профилирование и оптимизация конвейеров агрегации MongoDB требует систематического подхода, основанного на доказательствах. Используя встроенный профилировщик (db.setProfilingLevel) и запуская детальную статистику выполнения (.explain('executionStats')), вы можете превратить сложные проблемы производительности в решаемые шаги.

Рабочий процесс оптимизации:

Включите профилирование: Установите уровень 1 и определите slowOpThresholdMs.
Выполните запрос: Запустите медленный конвейер агрегации.
Проанализируйте профилированные данные: Определите конкретный этап, потребляющий больше всего времени.
Объясните подробно: Используйте .explain('executionStats') на проблемном конвейере.
Настройте: Создайте необходимые индексы, измените порядок этапов (сначала фильтрация) и упростите данные, передаваемые дорогостоящим операторам.

Непрерывный мониторинг гарантирует, что недавно добавленные функции или увеличенный объем данных не приведут к повторному появлению проблем с производительностью, которые вы решили.