Тюнінг MongoDB: WiredTiger, індекси, запити

Уявіть: сервер з 32 ГБ RAM, MongoDB використовує 16 ГБ під кеш WiredTiger, але запити все одно виконуються за секунди. Причина — неефективні індекси та неправильна конфігурація. Ми стикалися з таким не раз: COLLSCAN замість IXSCAN, кеш витісняється сторінками з диска, а агрегації з'їдають всю пам'ять. Оптимізація MongoDB — комплексне завдання, що включає налаштування двигуна WiredTiger, проєктування індексів і профілювання повільних запитів. Без системного підходу навіть потужні сервери працюють неефективно. Наші інженери мають сертифікати MongoDB та 10+ років досвіду в цій галузі. У цій статті ділимося практичними прийомами, які допомогли нашим клієнтам скоротити час відповіді до 50%. Розглянемо типові помилки та способи їх усунення. Особливу увагу приділимо правилу ESR для індексів та налаштуванню кешу WiredTiger — ці два моменти дають найбільший ефект.

Проблеми, які ми вирішуємо

Неефективне налаштування кешу WiredTiger

За замовчуванням MongoDB виділяє 50% RAM під кеш. На сервері з 32 ГБ це 16 ГБ. Але без явної установки cacheSizeGB кеш може бути витіснений іншими процесами. Ми завжди задаємо його вручну, залишаючи запас для ОС та дискового кешу.

# /etc/mongod.conf
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 12  # Для сервера 32 GB
      journalCompressor: snappy
    collectionConfig:
      blockCompressor: snappy
    indexConfig:
      prefixCompression: true

Моніторинг: db.serverStatus().wiredTiger.cache. Якщо pages evicted by application threads > 0, кеш під тиском — збільште cacheSizeGB.

Індекси: відсутність або неправильний порядок

Без індексу будь-який запит перетворюється на COLLSCAN. Головне правило — ESR (Equality, Sort, Range). Ось як будувати складовий індекс:

// Запит: знайти активні замовлення користувача, відсортувати за датою
db.orders.find({ user_id: ObjectId("..."), status: "active" }).sort({ created_at: -1 })
// Правильний індекс: equality → sort → range
db.orders.createIndex({ user_id: 1, status: 1, created_at: -1 })

Повільні агрегації з $lookup

Найчастіша помилка — $match після $lookup. Оптимальний порядок:

db.orders.aggregate([
  { $match: { status: "completed", created_at: { $gte: ISODate(new Date().getFullYear() + '-01-01') } } },
  { $lookup: { from: "users", localField: "user_id", foreignField: "_id", as: "user",
      pipeline: [{ $match: { country: "UA" } }, { $project: { name: 1, email: 1 } }]
  }},
  { $project: { _id: 1, total: 1, "user.name": 1 } }
])

Для паралельних пайплайнів використовуйте $facet.

Як налаштувати кеш WiredTiger?

Ключовий параметр — cacheSizeGB. Встановіть його в 60–70% від доступної RAM, але не більше 20 ГБ на сучасних версіях (згідно з офіційною документацією MongoDB). Решту пам'яті віддайте ОС та дисковому кешу. Для сервера 64 ГБ оптимально cacheSizeGB: 40, але з урахуванням інших процесів — зазвичай 35–40.

Індекси: проєктування та догляд

Використовуйте правило ESR для складових індексів. Регулярно перевіряйте невикористовувані індекси: db.aggregate([{ $indexStats: {} }]). Індекси з accesses.ops == 0 — мертвий вантаж, їх варто видаляти. Це економить до 20% ОЗУ.

Коли варто шардувати MongoDB?

Шардування виправдане, якщо дані перевищують 200 ГБ або навантаження на запис більше 10 000 RPS на один сервер. Ключ шардування обирайте з високою кардинальністю, наприклад хеш від user_id.

Як ми це робимо: кейс

З нашої практики: оптимізували MongoDB для інтернет-магазину (наш клієнт) з каталогом у 5 млн товарів. Час запитів за категоріями та ціною — 2-3 секунди. Рішення:

• Складові індекси по (category, price, created_at).
• cacheSizeGB = 20 на сервері 64 ГБ.
• Аналітичні запити на secondary (readPreference: secondaryPreferred).
• Замінили $lookup з пост-фільтрацією на pipeline.

Результат: час відповіді впав до 50 мс, навантаження на CPU знизилося на 30%. Наші клієнти в середньому отримують зниження часу відповіді в 2-3 рази після оптимізації. Наприклад, один клієнт зекономив 450 000 грн за перший рік. Наша команда гарантує, що такий підхід до індексації скорочує час відповіді вдвічі порівняно з типовою конфігурацією. Середня економія клієнтів за перший рік — 200 000–500 000 грн на утриманні серверів. Для термінових завдань доступна експрес-діагностика за 1 день — зв'яжіться з нами.

Регулярна перевірка невикористовуваних індексів

Індекси з accesses.ops == 0 займають пам'ять і уповільнюють запис. Раз на місяць запускайте $indexStats і видаляйте невикористовувані. Це економить до 20% оперативної пам'яті на індексах. Правильний cacheSizeGB дає приріст швидкості на 40% проти стандартних налаштувань.

Процес роботи та вартість

1. Аудит: профайлер, explain, аналіз індексів.
2. Проєктування: розрахунок cacheSizeGB, індекси за ESR.
3. Реалізація: налаштування конфігурації, створення/видалення індексів, оптимізація запитів.
4. Тестування: навантажувальне тестування, порівняння метрик.
5. Деплой: застосування змін, моніторинг.

Строки оптимізації — від 3 до 10 робочих днів. Вартість розраховується індивідуально після безкоштовного аудиту. Економія на серверній інфраструктурі може сягати 30% за рахунок зниження навантаження. Наша оптимізація окупається за 2-3 місяці.

Що входить в оптимізацію MongoDB

• Повний аудит поточної конфігурації та продуктивності.
• Проєктування схеми індексів з урахуванням бізнес-логіки.
• Налаштування WiredTiger (cacheSizeGB, компресія, журнал).
• Оптимізація повільних запитів та агрегацій.
• Документація змін та рекомендації з експлуатації.
• Навчання команди та передача доступів.
• Підтримка протягом 30 днів після впровадження.

Чеклист тюнінгу

Порівняння поширених підходів до індексації

Приклад включення профайлера

db.setProfilingLevel(1, { slowms: 50 });
db.getProfilingStatus();
db.system.profile.aggregate([
  { $group: { _id: "$ns", avgMillis: { $avg: "$millis" }, count: { $sum: 1 } } },
  { $sort: { avgMillis: -1 } },
  { $limit: 10 }
])

Замовте аудит продуктивності 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% без втрати продуктивності.