Привет! Как опытный инженер баз данных, я много лет работал над развертыванием MongoDB. В этом подробном руководстве я дам вам главные советы по анализу и настройке производительности MongoDB на основе проверенных методов, которые я применял в различных производственных средах.
Мониторинг показателей использования должен быть краеугольным камнем любых усилий по настройке. Итак, давайте начнем с изучения некоторых ключевых инструментов MongoDB Cloud, которые обеспечивают беспрецедентную прозрачность использования и поведения базы данных.
Использование MongoDB Cloud для мониторинга и отладки производительности
MongoDB Atlas предоставляет надежные функции мониторинга, оповещения и устранения неполадок, которые чрезвычайно полезны для упреждающего управления производительностью. Вот некоторые возможности Atlas, которые я регулярно использую для проверки и улучшения производственных развертываний:
Отслеживание использования диска
Емкость диска и количество операций ввода-вывода в секунду часто являются узкими местами для производительности базы данных. Atlas позволяет легко визуализировать потребление хранилища в вашем кластере с помощью интерактивных диаграмм с разбивкой по базе данных, коллекции, индексу и т. д.
Мне нравится наблюдать за диаграммой тепловой карты использования диска с течением времени, чтобы выявить всплески использования. Например, вы можете увидеть скачок использования с 50% до 90% в течение нескольких часов при выполнении большого аналитического задания, а затем вернуться к нормальному значению. Эти пики могут увеличить задержку запросов и даже вывести из строя кластеры, если они исчерпают доступное пространство.
По умолчанию Atlas отправляет оповещение по электронной почте, когда загрузка диска достигает 75 %, чтобы обеспечить раннее предупреждение. Я рекомендую настроить этот порог на основе типичных шаблонов рабочей нагрузки. Atlas также позволяет легко масштабировать диски по вертикали без простоев, когда это необходимо.
Совет для профессионалов: если использование диска остается стабильно высоким, включите профилирование базы данных, чтобы определить возможности оптимизации и способы уменьшения ненужного объема данных.
Сокращение времени ответа
Высокая задержка запросов — один из первых индикаторов возникающих проблем с производительностью в MongoDB. С помощью Atlas вы получаете в режиме реального времени информацию о тенденциях времени отклика при операциях чтения, записи, командах и т. д.
Страница диаграмм позволяет визуально заметить увеличение задержки до того, как она станет серьезной проблемой. Вы даже можете проверить конкретные медленные запросы, чтобы понять основную причину, о которой я расскажу подробнее в разделе профилирования ниже.
По умолчанию Atlas предупреждает о замедлении обработки запросов по сравнению с базовыми показателями за 24 часа. Но я предлагаю настроить пороговые значения в зависимости от вашей терпимости, например, выдавать оповещения, если задержка чтения 99-го процентиля превышает 50 миллисекунд.
Мониторинг всех показателей
Помимо времени отклика и использования диска, Atlas сразу же предоставляет графики временных рядов для всех ключевых показателей базы данных, в том числе:
- Запросов и записей в секунду
- Соединения и курсоры
- Темпы роста документов
- Ошибки страницы
- И многое другое
Мне нравится прокручивать диаграммы при настройке производительности, чтобы выявить аномалии и тенденции по всем показателям вместе. Например, увеличение количества ошибок страниц может указывать на проблемы с рабочим набором, а повышенные очереди могут подразумевать ограничения пропускной способности.
Вы также можете настроить панель мониторинга с помощью диаграмм для пользовательских метрик, создаваемых командами базы данных, и установить подробные оповещения для любой метрики. Этот гибкий мониторинг имеет неоценимое значение для раннего выявления проблем.
Использование профилировщиков базы данных для глубокого анализа запросов
Теперь, когда Atlas настроен для комплексного мониторинга, профилировщики баз данных позволяют сделать следующий шаг — детализацию конкретных запросов для диагностики проблем с производительностью. Профилировщики собирают детальные метрики по каждому запросу, операции записи и команде, выполняемой в вашем развертывании.
Включение встроенного профилировщика
MongoDB включает уровень профилирования, который можно включить по требованию, чтобы начать сбор детальных данных о производительности. Он предоставляет возможности фильтрации профилирования только для медленных операций или определенных баз данных, коллекций или клиентов.
Я часто включаю профилирование на короткий период времени, чтобы получить репрезентативную выборку использования, что минимизирует накладные расходы. Просто имейте в виду, что встроенный профилировщик может потреблять значительные системные ресурсы, если оставить его работать на неопределенный срок.
Профилировщик запросов для непрерывного анализа
Для непрерывного профилирования Atlas предоставляет услугу профилирования управляемых запросов. Он автоматически профилирует любой запрос, превышающий настроенные пороговые значения длительности, и сохраняет показатели для анализа.
Графический интерфейс профилировщика позволяет визуально фильтровать, проверять и сравнивать запросы с течением времени. Вы также можете экспортировать полный набор захваченных запросов, чтобы копнуть глубже. Это упрощает идентификацию самых медленных запросов для оптимизации.
Линза контроля командования
Мониторинг команд базы данных дает вам мгновенный обзор производительности каждой операции, выполняемой вашим кластером, объединяя такие показатели, как:
- Время выполнения
- Документы возвращены
- Используемые индексы
Вкладка «Линзы» в Atlas предоставляет готовые диаграммы для визуализации данных этой команды, выявляя выбросы и тенденции. Я регулярно просматриваю их, чтобы выявить возникающие «горячие точки».
Теперь давайте посмотрим, как использовать данные профилировщика для систематического устранения медленных запросов и неэффективных шаблонов доступа к данным.
Ускорение чтения с помощью целевой оптимизации
Чтобы настроить производительность запросов на чтение, вам необходимо создать комплексные индексы, которые соответствуют шаблонам запросов и эффективно извлекают документы.
Просмотр планов запросов
Если при профилировании обнаруживается медленный запрос, я сначала проверяю его план запроса. В плане показано, использовался ли индекс и привел ли запрос к полному сканированию коллекции из-за отсутствия индекса.
Если вы часто видите полное сканирование коллекции, это часто является явным признаком низкой производительности запросов и местом для начала оптимизации.
Создание индексов – осторожно!
Добавление индексов, предназначенных для часто выполняемых запросов, может дать огромные преимущества. В составные индексы включают как поля фильтра, так и порядок сортировки, используемые вместе.
Однако ключевым моментом является балансирование избирательности и размера индекса: слишком широкие индексы могут увеличить потребности в хранилище и увеличить накладные расходы на запись. Я рекомендую следовать принципам гибкости схемы и индексировать только часто фильтруемые или сортируемые поля.
Atlas предоставляет советник по индексам, основанный на фактических данных об использовании, который предлагает отсутствующие индексы для медленных запросов, которые вы профилировали. Это автоматизирует большую часть процесса оптимизации!
Оптимизация конвейеров агрегации
Для сложных агрегатов ищите $sorts, которые не используют индекс. Также проверьте этапы, на которых сканируются излишне большие части набора данных. Здесь помогает добавление индексов и стадий $limit.
Разгрузка аналитики
Если у вас значительные аналитические рабочие нагрузки, рассмотрите возможность их изоляции на вторичных узлах, чтобы избежать конкуренции за ресурсы. Но имейте в виду, что второстепенные компании могут отставать от первичных.
Есть еще много нюансов эффективного индексирования и моделирования данных – об этом написаны книги! Но сама по себе тщательная индексация часто может обеспечить ускорение в 10–100 раз.
Масштабирование записи с помощью шардинга и других приемов
Далее давайте обсудим, как преодолеть узкие места записи/обновления. Хотя чтение часто можно ускорить с помощью индексации, запись требует масштабирования аппаратной мощности.
Шардинг для горизонтального масштаба
Для коллекций, содержащих более 1 миллиарда документов, сегментирование обеспечивает прозрачное секционирование между распределенными серверами. Это позволяет почти линейно масштабировать пропускную способность записи по мере добавления узлов.
Но сегментирование — это не автоматическое волшебство: вам нужно выбрать хороший сегментный ключ, который равномерно распределяет записи по разделам. Я также предлагаю включить разделение на основе хэша для равномерно случайных распределений.
Настройка оплога
В oplog хранятся события изменений для поддержки репликации MongoDB. Выбирайте консервативный размер — не менее 24 часов операций — чтобы обеспечить достаточно большое окно для наборов реплик.
Оптимизация построений индексов
Я стараюсь планировать создание индексов во время периодов обслуживания, чтобы они не влияли на производственную нагрузку. Создание индексов только на вторичных серверах предотвращает конфликты за ресурсы.
Регулирование частоты обновления
Если чрезвычайно высокая частота обновлений превышает возможности, попробуйте ограничить трафик обновлений, чтобы сгладить пики. Вы также можете перенаправить обновления на дополнительный узел, чтобы облегчить ситуацию.
Пакетная запись
По возможности группируйте операции вставки и обновления в более крупные транзакции, чтобы сократить накладные расходы. Большинство драйверов MongoDB предоставляют вспомогательные методы, которые решают эту проблему автоматически.
Существует также множество шагов по настройке инфраструктуры, таких как оптимизация памяти, использование пула соединений и устранение других узких мест, которые у меня нет места для полного описания здесь.
Объединение всего этого с помощью непрерывного профилирования
Я надеюсь, что этот обзор даст вам методологию подхода к настройке развертываний MongoDB. Ключевым моментом является постоянный мониторинг моделей использования и профилирование производительности запросов по мере появления изменений.
Atlas предоставляет необходимые инструменты для этой работы со встроенными функциями профилирования, визуализации и оповещения. Моя команда еженедельно просматривает диаграммы Atlas и данные профилировщика, чтобы заранее выявить возможности оптимизации.
Путем постепенной оптимизации индексов, моделей данных, запросов и емкости на основе эмпирических данных профилирования вы можете добиться замечательной производительности MongoDB в любом масштабе. Дайте мне знать, если у вас есть еще вопросы!
