Налаштування MongoDB: індекси, реплікація, оптимізація

Проблема: каталог з довільними атрибутами «ламає» реляційну модель

Ми налаштовували MongoDB для інтернет-магазину електроніки: кожна категорія має унікальний набір характеристик (діагональ, кількість ядер, об'єм пам'яті). У PostgreSQL довелося б городити EAV або JSON-поля — складні запити та падіння продуктивності при 500 товарах. MongoDB вирішила це без болю: схема не фіксована, а BSON-документи ідеально лягають на структуру товару. Наш клієнт — магазин з 5000 товарів у 20 категоріях — отримав час відповіді запитів під 10 мс без спеціальної оптимізації. Розповімо, як налаштувати таку базу під ключ.

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

• N+1 запитів при роботі з документами — типова помилка, коли замість вкладених масивів дістають пов'язані документи окремими запитами. Рішення: використовувати $lookup в агрегації або зберігати вкладені підмасиви.
• Повільний запис без реплікації — при падінні єдиного вузла втрачаються дані за хвилини. Replica Set з трьох серверів дає RPO=0 та автоматичне перемикання.
• Індекси не покривають запити — без часткових та складених індексів агрегації за статусом і датою виконуються за секунди замість мілісекунд. З правильно налаштованими індексами продуктивність запитів зростає в 10–100 разів.

Як ми налаштовуємо MongoDB: кейс з Replica Set

Для того ж інтернет-магазину ми розгорнули кластер на трьох серверах (MongoDB 7.0, Ubuntu 22.04). Налаштували Replica Set з двома звичайними вузлами та одним прихованим для бекапів. Connection string застосунку: mongodb://myapp:password@mongo1:27017,mongo2:27017/myapp?replicaSet=rs0&readPreference=secondaryPreferred. У результаті — відмовостійкість та балансування читання на вторинні вузли. Навантаження 10 000 запитів на секунду тримається без затримок.

Встановлення та конфігурація

# Установка MongoDB 7.0
curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | gpg --dearmor -o /usr/share/keyrings/mongodb-server-7.0.gpg
echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" > /etc/apt/sources.list.d/mongodb-org-7.0.list
apt update && apt install -y mongodb-org
systemctl enable mongod && systemctl start mongod

# /etc/mongod.conf (основные настройки)
net:
  port: 27017
  bindIp: 127.0.0.1  # для продакшена замените на внутренний IP
security:
  authorization: enabled
storage:
  dbPath: /var/lib/mongodb
  wiredTiger:
    engineConfig:
      cacheSizeGB: 2  # 50% RAM
replication:
  replSetName: "rs0"
operationProfiling:
  slowOpThresholdMs: 100
  mode: slowOp

Індекси під типові запити

// Создаём индексы сразу при проектировании схемы
// Уникальный индекс по email
  db.users.createIndex({ email: 1 }, { unique: true, background: true })

// Составной для сортировки заказов пользователя
  db.orders.createIndex({ userId: 1, createdAt: -1 })

// Частичный — только активные сессии
  db.sessions.createIndex(
    { userId: 1, expiresAt: 1 },
    { partialFilterExpression: { revokedAt: { $exists: false } } }
  )

// TTL-индекс — автоудаление логов через 30 дней
  db.logs.createIndex({ createdAt: 1 }, { expireAfterSeconds: 2592000 })

// Текстовый поиск с русским языком
  db.articles.createIndex({ title: "text", body: "text" }, { default_language: "russian" })

// Wildcard для каталога с произвольными атрибутами
  db.products.createIndex({ "attributes.$**": 1 })

Агрегація: виручка за категоріями

db.orders.aggregate([
  {
    $match: {
      createdAt: { $gte: ISODate("2024-01-01"), $lt: ISODate("2024-04-01") },
      status: "paid"
    }
  },
  { $unwind: "$items" },
  {
    $lookup: {
      from: "products",
      localField: "items.productId",
      foreignField: "_id",
      as: "product"
    }
  },
  { $unwind: "$product" },
  {
    $group: {
      _id: "$product.category",
      revenue: { $sum: { $multiply: ["$items.price", "$items.quantity"] } },
      orders: { $addToSet: "$_id" }
    }
  },
  {
    $project: {
      category: "$_id",
      revenue: { $round: ["$revenue", 2] },
      orderCount: { $size: "$orders" }
    }
  },
  { $sort: { revenue: -1 } }
])

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

Чому Replica Set обов'язковий для продакшену?

Replica Set — мінімальна конфігурація для production. Одиночний вузол не забезпечує відмовостійкість: при збої в роботі сервера дані недоступні до відновлення. Replica Set з трьох вузлів гарантує автоматичне перемикання на вторинний вузол протягом секунд. RPO (точка відновлення) прямує до нуля. Для більшості застосунків це оптимальний баланс надійності та вартості. Зв'яжіться з нами — ми проведемо аудит вашої поточної схеми та запропонуємо оптимальну топологію.

Процес роботи

Що входить в роботу

• Конфігурація сервера та мережі (авторизація, TLS)
• Налаштування Replica Set або шардованого кластера
• Створення індексів під навантаження (часткові, TTL, текстові)
• Оптимізація агрегаційних запитів
• Інтеграція з Mongoose/Node.js (схеми, хуки, віртуальні поля)
• Налаштування моніторингу (MongoDB Atlas, Prometheus + Grafana)
• Резервне копіювання (mongodump + автоматизація)
• Документація та інструкції для команди

Строки та вартість

Базове налаштування Replica Set з індексами та моніторингом — від 2 до 5 днів. Вартість розраховується індивідуально і залежить від складності схеми та кількості вузлів. Зв'яжіться з нами для оцінки вашого проекту — ми підготуємо комерційну пропозицію за один робочий день. Замовте налаштування MongoDB у сертифікованих спеціалістів з 10-річним досвідом.

Чому варто замовити налаштування у нас?

Ми сертифіковані спеціалісти MongoDB (понад 10 років досвіду в адмініструванні NoSQL). За цей час налаштували понад 50 кластерів для проектів з навантаженням до 100 000 запитів на секунду. Надаємо гарантію на всі роботи — від 3 до 12 місяців залежно від SLA. Отримайте консультацію прямо зараз — ми безкоштовно оцінимо вашу поточну архітектуру.

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