Диагностика и устранение медленных запросов в MongoDB: Практическое руководство

Медленные запросы MongoDB обычно появляются после роста данных, изменения паттернов доступа или когда индекс перестает соответствовать тому, как приложение читает данные. Вы можете заметить тайм-ауты API-эндпоинтов, медленную загрузку дашбордов или рост CPU и дискового ввода-вывода, даже если трафик выглядит нормальным.

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

Понимание причин замедления запросов

Прежде чем менять индексы, проверьте типичные причины:

1. Отсутствие или неэффективность индексов: Без полезного индекса MongoDB может выполнять сканирование коллекции и проверять каждый документ.
2. Сложность запроса: Операции, требующие этапов агрегации, больших сортировок или межколлекционных поисков, могут быть медленными, если не оптимизированы.
3. Объем данных: Даже индексированные запросы могут замедляться, если набор данных огромен и запросу все равно нужно обработать миллионы документов перед фильтрацией.
4. Аппаратные ограничения: Недостаточный объем ОЗУ (приводящий к активной подкачке на диск) или медленный дисковый ввод-вывод могут снижать производительность всех операций.

Шаг 1: Выявление медленных запросов с помощью профилирования

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

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

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

Для анализа медленных запросов обычно устанавливают уровень 1 с порогом, например, 50 миллисекунд:

// Переключитесь на базу данных, которую хотите профилировать
use myDatabase

// Захват операций, выполняющихся дольше 50 миллисекунд
db.setProfilingLevel(1, { slowms: 50 })

Просмотр результатов профилирования

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

// Поиск операций, выполняющихся дольше 50 мс
db.system.profile.find({ ns: "myDatabase.myCollection", millis: { $gt: 50 } }).sort({ ts: -1 }).limit(10).pretty()

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

Шаг 2: Анализ выполнения запроса с помощью explain()

Как только вы определили медленный запрос, используйте explain(), чтобы увидеть, как MongoDB его обрабатывает.

Использование explain('executionStats')

Уровень детализации executionStats предоставляет наиболее полный вывод, включая фактическое время выполнения и использование ресурсов.

Рассмотрим этот медленный запрос к коллекции users:

db.users.find({ status: "active", city: "New York" }).sort({ registrationDate: -1 }).explain('executionStats')

Интерпретация вывода

Ключевые поля для проверки в выводе explain():

Поле	Описание	Индикатор медлительности
winningPlan stages	План выполнения, выбранный оптимизатором.	Ищите COLLSCAN, блокирующую SORT или неожиданный индекс.
executionStats.nReturned	Количество документов, возвращенных операцией.	Большое число при ожидании малого результата часто указывает на плохую фильтрацию на раннем этапе.
executionStats.totalKeysExamined	Сколько ключей индекса было проверено.	Должно быть близко к nReturned, если индекс используется эффективно.
executionStats.totalDocsExamined	Сколько документов было фактически извлечено с диска/из памяти.	Большое число говорит о том, что индекс был недостаточно селективным.
executionStats.executionTimeMillis	Общее время выполнения.	Сравните с реальной задержкой.

Красный флаг: COLLSCAN

Если выигрышный план содержит COLLSCAN, MongoDB сканировала коллекцию. Это обычно означает, что запросу нужен лучший индекс, предикат не селективен или форма запроса не позволяет использовать индекс.

Шаг 3: Реализация стратегий индексирования

Устранение COLLSCAN обычно включает создание или настройку индексов в соответствии с паттерном запроса.

Создание составных индексов

Для запросов, включающих несколько полей, таких как проверки на равенство, фильтры диапазона или сортировка, часто необходим составной индекс. Распространенное правило ESR упорядочивает поля составного индекса: сначала предикаты равенства, затем поля сортировки, затем предикаты диапазона. Это руководство, а не замена тестированию с вашим реальным запросом и данными.

Пример сценария: Запрос: db.orders.find({ status: "PENDING", customerId: 123 }).sort({ orderDate: -1 })

Согласно ESR, индекс должен иметь следующую структуру:

1. Предикаты равенства (status, customerId)
2. Предикаты сортировки (orderDate)

Создание индекса:

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

Этот индекс позволяет MongoDB быстро фильтровать по статусу и ID клиента, а затем эффективно получать результаты, уже отсортированные по orderDate.

Обработка операций сортировки

Если explain() показывает блокирующий этап SORT после проверки многих документов, MongoDB не смогла использовать индекс для возврата результата в отсортированном порядке.

Большие сортировки могут потреблять память и сбрасываться на диск в зависимости от версии сервера и параметров команды. Лучшее решение — обычно индекс, который поддерживает как фильтр, так и сортировку.

Убедитесь, что поля, используемые в предложении .sort(), присутствуют в качестве завершающих элементов в соответствующем составном индексе.

Шаг 4: Продвинутые методы оптимизации

Если только индексирование не решает проблему медлительности, рассмотрите следующие продвинутые шаги:

Оптимизация проекции

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

// Возвращать только поля _id, name и email
db.users.find({ city: "Boston" }, { name: 1, email: 1, _id: 1 })

Покрывающие индексы

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

В выводе explain() покрывающий индекс приводит к тому, что этап показывает IXSCAN, а totalDocsExamined равно 0.

Проверка аппаратного обеспечения и конфигурации

Если totalKeysExamined и totalDocsExamined выглядят разумными, но задержка остается высокой, посмотрите дальше формы запроса. Проверьте, помещается ли рабочий набор в память, высока ли задержка диска, и испытывает ли сервер нагрузку на запись, конкуренцию блокировок или насыщение CPU.

Вывод

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

Контрольный список действий:

1. Временно включите профилировщик для захвата медленных запросов (slowms).
2. Выполните проблемный запрос с помощью explain('executionStats').
3. Проверьте наличие COLLSCAN или высокого totalDocsExamined.
4. Создайте или измените составные индексы на основе правила ESR для покрытия фильтров и сортировок.
5. Проверьте улучшение, повторно выполнив команду explain().