Основні відмінності MongoDB від реляційних баз даних

Привіт, друзі! Ми вже встигли поринути у світ NoSQL і познайомитися з MongoDB, поглянули на її архітектуру та можливості, і навіть почали робити асинхронні запити через FastAPI. Тепер настав час поговорити про фундаментальні відмінності між MongoDB і реляційними базами даних (SQL). Це тонка, але дуже важлива тема. Розуміння цих відмінностей допомагає нам вибирати правильні інструменти для кожної конкретної задачі. Бо, як каже народна мудрість програмістів: "Якщо все, що у вас є — молоток, все навколо здаватиметься цвяхом".

---

Нагадування: реляційні і нереляційні бази даних

У реляційній моделі дані організовуються в таблиці з чітко визначеними колонками (з іменами й типами даних). Наприклад, якщо ми проєктуємо базу даних для зберігання інформації про користувачів і їхні замовлення, структура може виглядати так:

Таблиця users:

Таблиця orders:

Тут зв'язок між користувачами (users) і їхніми замовленнями (orders) здійснюється через зовнішній ключ user_id. Це явний, строгий зв'язок між сутностями.

У MongoDB же дані зберігаються в колекціях, а кожен документ може мати довільну структуру. Наприклад, для того ж сценарію з користувачами і замовленнями можна представити дані у вигляді:

Колекція users:

{
  "name": "Іван",
  "email": "ivan@test.ru",
  "orders": [
    { "product": "Книга", "amount": 500 },
    { "product": "Лампа", "amount": 1200 }
  ]
}

Документи MongoDB не вимагають явного зв'язку через зовнішні ключі. Замість цього ми можемо вбудувати (embed) пов'язані дані прямо в документ. Такий підхід називається денормалізацією даних і значно спрощує доступ до даних у деяких випадках.

Порівняння підходів

---

Продуктивність та масштабованість

MongoDB і реляційні бази даних по-різному підходять до обробки даних, масштабування та забезпечення продуктивності, особливо під великими навантаженнями.

Реляційні бази даних спочатку створювалися з урахуванням вертикального масштабування. Це означає, що для збільшення продуктивності серверні ресурси (CPU, пам'ять, диски) треба посилювати. Однак цей підхід втратив актуальність із зростанням вимог сучасного світу.

MongoDB підтримує горизонтальне масштабування "з коробки". Горизонтальне масштабування означає додавання нових серверів у кластер замість поліпшення одного сервера. Завдяки механізму шардінгу MongoDB розподіляє дані між кількома вузлами (шардами), що робить її ідеальною для роботи з великими обсягами даних.

Реляційні бази даних часто швидші для операцій, пов'язаних зі складними зв'язками (наприклад, JOIN запитами). Вони оптимізовані для таких сценаріїв, як створення звітів або складних аналітичних запитів. MongoDB швидша при роботі з великими обсягами документів, наприклад для читання даних, якщо ключ індексований.

Приклад: підготовка звіту

Робота зі звітами, де потрібно агрегувати дані з кількох таблиць у SQL, виглядає елегантно за допомогою JOIN. MongoDB цього не підтримує в тому ж вигляді, але надає потужний механізм агрегацій, який дозволяє виконувати складні обчислення безпосередньо в базі.

Приклад агрегатного запиту в MongoDB:

pipeline = [
    {"$unwind": "$orders"},
    {"$group": {"_id": "$name", "total_spent": {"$sum": "$orders.amount"}}}
]
result = db.users.aggregate(pipeline)

Цей запит збирає підсумкові суми, витрачені кожним користувачем на товари.

---

Специфіка транзакцій та управління цілісністю даних

Реляційні бази даних підтримують транзакції, що відповідають ACID-принципам (атомарність, узгодженість, ізоляція, надійність). Це робить їх вибором номер один, коли важлива строгість узгодженості даних, наприклад при банківських операціях. Ви можете бути впевнені, що або всі зміни в базі завершаться успішно, або жодні зміни не будуть застосовані.

Приклад транзакції в SQL:

BEGIN TRANSACTION;
UPDATE bank_account SET balance = balance - 100 WHERE id = 1;
UPDATE bank_account SET balance = balance + 100 WHERE id = 2;
COMMIT;

Транзакції в MongoDB

До версії 4.0 MongoDB вважалася базою даних без транзакцій. Це було пов'язано з тим, що дані всередині одного документа завжди вважалися консистентними (тобто MongoDB гарантувала цілісність на рівні документа). Однак починаючи з версії 4.0, MongoDB підтримує багатодокументні транзакції.

Приклад транзакції в MongoDB:

with client.start_session() as session:
    with session.start_transaction():
        db.bank_account.update_one(
            {"id": 1}, {"$inc": {"balance": -100}}, session=session
        )
        db.bank_account.update_one(
            {"id": 2}, {"$inc": {"balance": 100}}, session=session
        )

Хоча транзакції тепер доступні, їх використовують рідше, оскільки архітектура MongoDB розрахована на часті вставки й запити, а не на складні масові зміни.

Порівняння

---

Коли обрати MongoDB, а коли — SQL?

Реляційні бази даних підходять, якщо:

• Потрібна сувора схема і складні зв'язки між даними.
• Ваші запити містять багато JOIN операцій.
• Ви розробляєте застосунок, де важлива фінансова точність (наприклад, бухгалтерські системи).

MongoDB актуальна, якщо:

• Працюєте з великим об'ємом даних, що вимагає горизонтального масштабування.
• Дані погано структуровані (логи, JSON, документи).
• Важливо працювати з гнучкими схемами і швидкими операціями читання/запису.

Отже, вибір бази даних залежить від специфіки проєкту. Пам'ятайте, що SQL і NoSQL — це не конкуренти, а інструменти для різних ситуацій. Як майстер вибирає викрутку чи молоток за задачею, так і ви маєте усвідомлено підходити до вибору технології!