Що таке MongoDB і коли варто її обирати
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: MongoDB — це документна база даних: вона зберігає інформацію у структурах, схожих на об’єкти JSON, а не лише в таблицях із рядками та стовпцями. Вона підходить, зокрема, для застосунків, у яких дані мають вкладену структуру або різні набори характеристик. Однак це не означає, що вона завжди швидша чи простіша за бази SQL: вибір залежить насамперед від того, як дані записують і читають.
Як MongoDB зберігає дані
MongoDB належить до баз NoSQL — групи систем, які не спираються виключно на традиційну реляційну модель. Основна одиниця даних — документ: набір полів і значень, що описує, наприклад, товар, користувача або замовлення. Документи об’єднують у колекції, які виконують роль, подібну до таблиць, але не вимагають однакового набору полів у всіх записах.
Документ можна подати у зрозумілому для читання форматі JSON:
{
"_id": "tovar-101",
"nazva": "Міський рюкзак",
"tsinaHroshi": 18900,
"kolory": ["чорний", "темно-синій"],
"parametry": {
"mistkistLitry": 20,
"vodonepronyknyi": true
}
}
Поле _id — це унікальний ідентифікатор документа. Якщо застосунок його не задає, під час стандартного додавання документа зазвичай буде призначено ідентифікатор типу ObjectId. Інші поля можуть містити, зокрема, текст, числа, списки та вкладені документи.
Для внутрішнього зберігання MongoDB використовує BSON — бінарний формат документів, який також підтримує типи даних, безпосередньо не представлені в JSON, наприклад дати. Тож твердження, що MongoDB «зберігає JSON», — корисне спрощення, а не точний опис формату зберігання.
Чим MongoDB відрізняється від бази SQL
Реляційні бази даних, як-от PostgreSQL чи MySQL, організовують дані в таблицях і дають змогу поєднувати їх за спільними полями. Наприклад, таблиця замовлень може посилатися на таблицю клієнтів. SQL — це мова, яку використовують, зокрема, для запитів до таких баз.
У MongoDB пов’язану інформацію часто розміщують в одному документі. Замовлення може містити список позицій і адресу доставки, актуальну на момент покупки. Завдяки цьому застосунок отримує всі потрібні дані, не збираючи їх із багатьох окремих структур.
| Аспект | MongoDB | Реляційна база даних |
|---|---|---|
| Основна структура | Документи в колекціях | Рядки в таблицях |
| Модель даних | Природна підтримка вкладених структур і списків | Явно визначені стовпці та зв’язки |
| Зв’язки | Вбудовування даних або посилання | Зовнішні ключі та з’єднання |
| Запити | Операції з документами та конвеєри агрегації | Запити SQL |
Це порівняння не означає жорсткого розмежування можливостей. Реляційні бази можуть підтримувати JSON, а MongoDB дає змогу поєднувати дані з колекцій, зокрема за допомогою операції $lookup. Вона також підтримує транзакції, що охоплюють кілька документів, хоча витрати на їх виконання та вимоги до розгортання потрібно врахувати в проєкті.
Гнучка схема не означає відсутності правил
Документи в одній колекції можуть мати різні поля. У каталозі магазину рюкзак може мати місткість у літрах, а монітор — діагональ екрана й роздільну здатність. Не потрібно створювати для кожного типу товару однаковий набір порожніх стовпців.
Однак гнучкість не звільняє від проєктування моделі даних. Якщо одна частина застосунку записує ціну як число, а інша — як текст, фільтрування й обчислення ускладнюються. MongoDB пропонує валідацію схеми — правила, які перевіряють, зокрема, наявність обов’язкових полів та їхні типи.
Також потрібно визначити, які дані вбудовувати в документ, а для яких зберігати посилання. Адресу доставки в замовленні зазвичай варто залишати як копію, що відображає стан на момент покупки. Актуальний профіль клієнта краще зберігати окремо, а не оновлювати його копії в усіх замовленнях.
Не варто без обмежень додавати дані до одного документа. У MongoDB максимальний розмір документа BSON становить 16 MiB, тому історія подій, яка постійно зростає, зазвичай потребує окремої колекції.
Коли обирати MongoDB, а коли розглянути PostgreSQL
MongoDB варто розглянути, якщо застосунок працює зі складними об’єктами, вміст яких часто читають разом. Приклади — каталог товарів із різними атрибутами, система керування вмістом або конфігурації пристроїв. Самого факту, що застосунок використовує JavaScript, недостатньо для такого вибору.
Реляційну базу варто розглянути насамперед тоді, коли найважливішими є численні зв’язки, обмеження цілісності між таблицями та звіти, що об’єднують багато видів даних. Це стосується, наприклад, системи розрахунків, у якій зручність контролю залежностей може бути важливішою за свободу структури документів.
Перш ніж ухвалити рішення, запишіть три найчастіші операції застосунку, наприклад пошук товару, отримання вмісту кошика та збереження замовлення. Потім підготуйте приклад моделі в обох базах. Перевірте, скільки операцій читання й оновлення потребує кожна дія та де виникають копії тієї самої інформації.
Як почати й що врахувати під час розгортання
MongoDB можна запустити на власній інфраструктурі або скористатися MongoDB Atlas — керованим хмарним сервісом. Для роботи з даними використовують, зокрема, графічний інструмент MongoDB Compass, оболонку mongosh і драйвери для мов програмування. Актуальні ціни, ліміти та умови резервного копіювання в Atlas потрібно перевірити в офіційній документації й тарифах обраного плану.
Для початку створіть тестову колекцію, додайте десяток із лишком документів і виконайте типові запити. Потім доберіть індекси — додаткові структури, що прискорюють пошук, — відповідно до фактичних фільтрів і сортування. Надмірна кількість індексів займає місце та збільшує витрати на запис даних.
Перед розгортанням у робочому середовищі налаштуйте автентифікацію, обмеження мережевого доступу й резервне копіювання, а також перевірте відновлення даних. Перший прототип використайте для перевірки моделі та запитів: лише вимірювання їхньої роботи на репрезентативних даних дасть змогу оцінити, чи підходить MongoDB для конкретного застосунку.
Дивіться також: Що таке 2FA?
Читайте також
