Администрирование базы данных MongoDB для веб-приложения
Представьте: ваше веб-приложение начинает тормозить, страницы загружаются по 10 секунд, а в логах — медленные запросы к MongoDB. Клиенты жалуются, а вы не понимаете, почему. Чаще всего причина — отсутствие правильных индексов или неоптимальная настройка replica set. Мы помогаем компаниям избежать таких ситуаций уже более 7 лет, выполняя администрирование MongoDB под ключ. Свяжитесь с нами для аудита вашей MongoDB — мы оценим текущее состояние и предложим план работ.
Недавно к нам обратился интернет-магазин с 50 000 товаров. База на MongoDB 6.0, replica set из трех узлов. После аудита мы обнаружили, что 30% индексов не используются, а размер oplog всего 1 ГБ — при интенсивной записи лаг репликации достигал 2 часов. Мы оптимизировали индексы, увеличили oplog до 10 ГБ и настроили мониторинг. Время ответа базы сократилось в 10 раз.
Как проходит аудит MongoDB?
Начинаем с диагностики. Собираем статистику по базам, коллекциям и индексам, используя db.stats() и db.collection.stats(). Выявляем неиспользуемые или неэффективные индексы через $indexStats. Проверяем конфигурацию replica set и размер oplog. В результате получаем карту узких мест.
Вот типичный скрипт для первичного сбора данных:
// mongosh use mydb // Статистика базы db.stats({ scale: 1024 * 1024 }) // Статистика коллекций db.runCommand({ listCollections: 1 }).cursor.firstBatch.forEach(c => { const stats = db[c.name].stats({ scale: 1024 }) printjson({ name: c.name, docs: stats.count, size_kb: stats.size, storageSize_kb: stats.storageSize, totalIndexSize_kb: stats.totalIndexSize, nindexes: stats.nindexes }) }) // Индексы коллекции с размерами db.orders.stats().indexSizes // Операции, выполняющиеся прямо сейчас (> 1 секунды) db.currentOp({ "secs_running": { $gt: 1 } }) Как мы оптимизируем запросы?
Первый шаг — создание правильных индексов. Используем составные индексы для типичных запросов, частичные — для фильтрации активных записей, TTL — для автоудаления устаревших данных. Примеры:
// Составной индекс для типичного запроса по пользователю и дате db.orders.createIndex( { user_id: 1, created_at: -1 }, { background: true, name: "idx_user_date" } ) // Частичный индекс — только для активных заказов db.orders.createIndex( { created_at: -1 }, { partialFilterExpression: { status: { $in: ["pending", "processing"] } }, name: "idx_active_orders_date" } ) // TTL индекс для автоудаления устаревших сессий db.sessions.createIndex( { expires_at: 1 }, { expireAfterSeconds: 0, name: "ttl_sessions" } ) Проверяем использование индексов через $indexStats и анализируем планы запросов с .explain("executionStats"). Если видим COLLSCAN при большом количестве документов — срочно нужен индекс. Подробнее о создании индексов читайте в официальной документации MongoDB.
Составной индекс может ускорить запросы в 100 раз по сравнению с полным сканированием коллекции, а частичные индексы занимают на 60% меньше места и ускоряют запись.
Как настроить replica set и мониторинг?
Настройка replica set состоит из 4 шагов:
- Инициализация набора с заданием идентификатора.
- Добавление членов: primary, secondary, arbiter.
- Настройка приоритетов для управления выборами primary.
- Проверка состояния и тестирование failover.
Вот пример инициализации:
rs.initiate({ _id: "rs0", members: [ { _id: 0, host: "mongo1:27017", priority: 2 }, { _id: 1, host: "mongo2:27017", priority: 1 }, { _id: 2, host: "mongo3:27017", arbiterOnly: true } ] }) Почему важен правильный размер oplog?
Oplog — это журнал операций, который позволяет вторичным узлам синхронизироваться с primary. Если размер oplog слишком мал, вторичные узлы могут не успевать применять операции и выпадать из синхронизации. Мы рекомендуем размер oplog, покрывающий не менее 6 часов пиковой записи. Для расчета можно использовать формулу: размер oplog = (средняя скорость записи в байтах/с) × 3600 × 6. В нашем кейсе с интернет-магазином увеличение oplog с 1 до 10 ГБ решило проблему лага репликации.
Как мы делаем бэкапы и восстанавливаем?
Для баз до нескольких ГБ используем mongodump с secondary и --oplog для консистентности. Для больших баз (>100 ГБ) применяем снапшоты файловой системы (LVM, EBS). Восстановление тестируем ежемесячно, чтобы быть уверенными в сохранности данных.
Сравнение методов бэкапа:
| Метод | Подходит для | Время восстановления | Консистентность |
|---|---|---|---|
| mongodump | < 100 ГБ | Зависит от размера | Point-in-time с --oplog |
| Файловый снэпшот | > 100 ГБ | Быстрое (минуты) | Требует остановки записи |
Резюме: что входит в работу
| Этап | Что делаем | Результат |
|---|---|---|
| Аудит | Сбор метрик, анализ индексов и запросов | Отчёт с рекомендациями |
| Проектирование | Схема, индексы, replica set, шардирование | Документация архитектуры |
| Настройка | Индексы, replica set, мониторинг, бэкапы | Рабочая конфигурация |
| Тестирование | Нагрузочное тестирование, проверка failover | Протокол испытаний |
| Деплой | Развёртывание в production, передача доступов | Настроенная система |
| Поддержка | Мониторинг 24/7, реагирование на алерты | Гарантия стабильности |
Сколько это занимает?
Сроки зависят от сложности: базовый аудит — 2–3 дня, полная настройка replica set с индексами и мониторингом — 5–7 дней. Мы оцениваем проект индивидуально — пишите, и мы подготовим точную смету.
Почему стоит доверить нам администрирование MongoDB?
У нас за плечами 7+ лет опыта и более 40 успешных проектов по оптимизации MongoDB. Мы не просто настраиваем базу — мы гарантируем, что она выдержит нагрузку. В работе используем только стабильные версии (MongoDB 7.0+, WiredTiger), применяем паттерны Repository и BFF для снижения нагрузки. Наши инженеры имеют сертификаты MongoDB.
Получите консультацию по вашему проекту — оценим текущее состояние и предложим план работ.