MongoDB. Часть 4. Database Profiler

Database Profiler

Продолжаем серию постов про #MongoDB, и сегодня остановимся на оптимизации запросов с помощью Database Profiler. Если вы ломаете голову над тем, как ускорить работу MongoDB, то можете найти ответ именно здесь :) Также пост будет полезен тем, кто никогда с MongoDB не работал: это расширит ваше понимание того, с какими интересностями можно столкнуться при работе с БД и, возможно, укажет куда копать :) (Кстати, еще можно задавать вопросы в комментариях к посту, получать ответы, и обогащаться знаниями ещё быстрее и качественнее :) )

Материал подготовил уже знакомый нам Даниил Кузнецов, техлид НГС.Авто и эксплуататор MongoDB с двухлетним стажем :)

MongoDB

Научиться работать с MongoDB достаточно просто. Для того, чтобы сделать первый запрос в уже развернутую базу достаточно 15 минут, а, может, и того меньше.

Очень часто в процессе разработки возникают ситуации, когда запросы в любую БД начинают тормозить - выполняться на порядок дольше, чем планировал разработчик. Это может быть связано с увеличением в разы размера датасета, по которому производится поиск, так и с увеличением нагрузки. Периодически возникает ситуация, когда все было учтено, но ваш проект работает достаточно медленно, и необходимо понять, какие запросы являются узким местом. MongoDB предоставляет достаточно много инструментов, для того чтобы найти узкое место в выполняемых запросах. Сегодня мы постараемся описать один из инструментов, которые необходимо использовать при поиске тормозящих запросов.

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

Примечание: в наших постах относительно MongoDB для доступа в эту БД мы будем использовать shell client.

Database Profiler

Эта система получила название Database Profiler. По умолчанию, система профилирования отключена. Для того, чтобы включить эту систему, необходимо включить profiling livel. Чтобы это сделать, необходимо выполнить в mongo shell следующую команду: db.setProfilingLevel(2) Выполнение этой команды включит профилировщик и будут логироваться абсолютно все запросы, которые выполняются. У системы профилирования есть несколько режимов работы: 0 - отключена, 2 - логировать все запросы, 1 - логирование только медленных запросов.

Что будет считаться медленным запросом - решает пользователь БД. У некоторых приложений запрос будет считаться долгим, если он выполняется дольше 5 секунд, а для других приложений запрос будет долгим, если он выполняется дольше 100 мс.

Чтобы включить необходимый уровень “медленности” запросов, нужно выполнить следующую команду: db.setProfilingLevel(1, 200) 2-й аргумент - количество миллисекунд, выполнения запроса.

Таким образом с помощью профилировщика БД можно найти запросы, которые выполняются достаточно долго и предпринять оптимизационные действия.

Статистика

Однако возникает вопрос, где же смотреть всю эту статистику? Хранилищем статистики выступает системная коллекция system.profile. Чтобы получить данные, необходимо просто выполнить запрос в эту коллекцию:

db.system.profile.find()

В результате у нас будет статистика либо по всем запросам, либо только по медленным, в зависимости от уровня профилирования. Осталось дело за малым - интерпретировать полученные данные. На что следует обратить внимание, ключевые поля: 1. “op” - поле с типом операции. Оно может принимать различные значения, например query - запрос, update - обновление документа, insert - операция вставки и т.д. 2. “ns” - коллекция, в которую была проведена операция 3. “query” - есть только в операциях выборки данных и обновления. Тут хранится запрос, который выполнялся. 4. “ntoreturned” - количество документов в качестве результата. Должно быть максимально приближено к “nscanned”. 5. “nscanned” - количество документов просканировано. Должно быть максимально приближено к “ntoreturned”. 6. “numYield” - блокировки коллекции на чтение и запись. Должно стремится к нулю. 7. “millis” - время выполнения запроса. Должно стремиться к нулю.

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