Адміністрування MongoDB для веб-додатків

Адміністрування 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 кроків:

1. Ініціалізація набору із заданням ідентифікатора.
2. Додавання членів: primary, secondary, arbiter.
3. Налаштування пріоритетів для управління виборами primary.
4. Перевірка стану та тестування 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). Відновлення тестуємо щомісяця, щоб бути впевненими у збереженні даних.

Порівняння методів бекапу:

Резюме: що входить у роботу

Скільки це займає?

Терміни залежать від складності: базовий аудит — 2–3 дні, повне налаштування replica set з індексами та моніторингом — 5–7 днів. Ми оцінюємо проєкт індивідуально — пишіть, і ми підготуємо точний кошторис.

Чому варто довірити нам адміністрування MongoDB?

У нас за плечима багаторічний досвід та понад 40 успішних проєктів з оптимізації MongoDB. Ми не просто налаштовуємо базу — ми гарантуємо, що вона витримає навантаження. У роботі використовуємо тільки стабільні версії (MongoDB 7.0+, WiredTiger), застосовуємо патерни Repository і BFF для зниження навантаження. Наші інженери мають сертифікати MongoDB.

Отримайте консультацію щодо вашого проєкту — оцінимо поточний стан і запропонуємо план робіт.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.