MongoDB медленные запросы как найти и оптимизировать

[ksenia1921]

Приложение на MongoDB 6.0 начало тормозить под нагрузкой. Коллекция events около 80 млн документов. Запросы по полям userId + createdAt иногда выполняются секундами. Как найти проблемные запросы и понять что именно тормозит?

[mark9640]

Первым делом включи профилировщик MongoDB: db.setProfilingLevel(1, { slowms: 100 }) — это запишет в system.profile все запросы медленнее 100мс. Потом смотри db.system.profile.find().sort({millis:-1}).limit(10) — найдёшь самых злодеев. Ищи поле docsExamined: если оно в разы больше nReturned — индекс либо отсутствует, либо неэффективен.

[yaroslav_hex13]

На 80 млн документов составной индекс обязателен. Создай db.events.createIndex({userId: 1, createdAt: -1}) — порядок полей важен. Если запросы всегда фильтруют по userId и сортируют по createdAt desc — именно такой индекс покроет оба условия и избежит in-memory sort.

[sqlreact9621]

explain() твой лучший друг. db.events.find({userId: 'xxx'}).sort({createdAt: -1}).explain('executionStats') покажет: используется ли индекс (IXSCAN vs COLLSCAN), сколько документов просканировано, есть ли этап SORT в памяти. Если видишь totalDocsExamined >> nReturned или стадию SORT — есть что оптимизировать.

[appdaemon9597]

Подробно про индексную стратегию для вашего случая: правило ESR (Equality, Sort, Range) — сначала поля по которым делаешь точное равенство (userId =), потом поля сортировки (createdAt), потом поля диапазонов. Для запросов вида find({userId: X, createdAt: {$gte: Y}}).sort({createdAt: -1}) оптимальный индекс {userId: 1, createdAt: -1}. Также проверь через db.events.stats() и db.events.totalIndexSize() — если индексы не влезают в RAM (wiredTiger кэшируется через parameter storage.wiredTiger.engineConfig.cacheSizeGB, по умолчанию 50% RAM), то производительность деградирует из-за постоянных page fault. Ещё: если поле createdAt типа string а не Date — сортировка будет лексикографической и индекс не поможет как ожидается. Всегда храни даты как Date.

[kira_api82]

Mongostat и mongotop запускай во время нагрузки — mongostat покажет количество операций в секунду, page faults, очереди на чтение/запись. Если qr|qw растут — это признак нехватки ресурсов или локов.

[makar3270]

Кстати, для аналитики по events с фильтрами за большие диапазоны дат MongoDB не самый лучший выбор. Если это логи или события — посмотри на ClickHouse или TimescaleDB, они для таких сценариев значительно быстрее.