Адміністрування MongoDB для веб-додатків
Уявіть: ваш веб-додаток починає гальмувати, сторінки завантажуються по 10 секунд, а в логах — повільні запити до MongoDB. Клієнти скаржаться, а ви не розумієте, чому. Найчастіше причина — відсутність правильних індексів або неоптимальне налаштування replica set. Ми допомагаємо компаніям уникати таких ситуацій вже багато років, виконуючи адміністрування 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?
У нас за плечима багаторічний досвід та понад 40 успішних проєктів з оптимізації MongoDB. Ми не просто налаштовуємо базу — ми гарантуємо, що вона витримає навантаження. У роботі використовуємо тільки стабільні версії (MongoDB 7.0+, WiredTiger), застосовуємо патерни Repository і BFF для зниження навантаження. Наші інженери мають сертифікати MongoDB.
Отримайте консультацію щодо вашого проєкту — оцінимо поточний стан і запропонуємо план робіт.