Реляційна база даних зберігає записи в таблицях із фіксованою схемою і зв'язує їх зовнішніми ключами. Нереляційна база даних, її часто називають NoSQL, зберігає дані документами, парами ключ-значення, широкими стовпцями або графами і зазвичай не вимагає жорсткої схеми заздалегідь. Від вибору моделі залежить, як швидко зростає проект і які запити залишаються швидкими за збільшення обсягу даних.
Чим реляційна модель відрізняється від документної
У реляційній базі дані діляться на таблиці, у кожного рядка є передбачуваний набір стовпців, а зв'язки між таблицями описані зовнішніми ключами. Це зручно, коли дані добре структуровані і важлива цілісність зв'язків: замовлення завжди посилається на наявного клієнта, платіж — на наявне замовлення. Нереляційна база зберігає пов'язані дані одним документом чи записом, не розбиваючи їх на таблиці, і легше переживає зміну структури даних на ходу.
- реляційна база перевіряє цілісність зв'язків на рівні самої СУБД, а не лише в коді застосунку
- документна база зберігає вкладені структури одним шматком, без додаткових з'єднань таблиць
- обидві моделі підтримують реплікацію і резервне копіювання, різниця в устрої зберігання, а не в надійності
Покрокове налаштування реляційної СУБД на власному сервері описане у статті налаштування MariaDB на VDS.
Порівняння за практичними параметрами
Для конкретного проекту різниця найпомітніша у трьох речах: наскільки суворо перевіряється структура даних, як виконуються складні вибірки і як база зростає за збільшення навантаження.
| Параметр | Реляційна БД | Нереляційна БД |
|---|---|---|
| Схема даних | задана заздалегідь, змінюється міграцією | гнучка, у документів може відрізнятися набір полів |
| Зв'язки між даними | зовнішні ключі, перевіряються СУБД | зберігаються всередині документа або перевіряються в коді |
| Мова запитів | SQL, єдиний стандарт із діалектами | власний API або мова запитів у кожної СУБД |
| Порт за замовчуванням | 3306 у MySQL та MariaDB, 5432 у PostgreSQL | залежить від конкретної СУБД |
Налаштування альтернативної реляційної СУБД з окремим набором можливостей розібране у статті налаштування PostgreSQL на VDS.
Як виглядає типовий запит
Різниця в запитах помітна на простому прикладі: потрібно отримати перелік замовлень разом з іменем клієнта. У реляційній базі це з'єднання двох таблиць за зовнішнім ключем.
SELECT orders.id, customers.name
FROM orders
JOIN customers ON customers.id = orders.customer_id;У документній базі той самий результат частіше отримують без з'єднання: дані про клієнта або вже зберігаються всередині документа замовлення, або запитуються окремим зверненням за ідентифікатором. Це швидше за простого читання, але ускладнює зміну даних клієнта одразу в усіх його замовленнях.
Коли реляційна модель виправдана, а коли ні
Реляційна база підходить, якщо дані добре структуровані заздалегідь і важливі суворі зв'язки між сутностями: білінг, облік замовлень, бухгалтерія. Міграції схеми при цьому залишаються керованими, тому що структура змінюється рідко і передбачувано.
Нереляційна база виправдана, якщо структура даних змінюється часто, обсяг записів зростає швидше, ніж встигає зростати один сервер, або потрібно зберігати різнорідні документи без спільної схеми. Перенесення даних між різними СУБД за зміни моделі зберігання описане у статті перенесення бази даних.
Що робити під час вибору моделі даних
Рішення варто ухвалювати за даними проекту, а не за модою на конкретну технологію.
- опишіть на папері основні сутності проекту і зв'язки між ними
- перевірте, чи потрібна сувора перевірка цілісності зв'язків на рівні бази
- оцініть очікуваний обсяг даних і характер запитів — точкові вибірки чи складні з'єднання
- для суворо структурованих даних із частими з'єднаннями обирайте реляційну СУБД, для різнорідних документів — нереляційну
Рішення не зобов'язане бути єдиним на весь проект: частину даних можна зберігати в реляційній базі, а частину — поруч, у нереляційному сховищі під конкретне завдання.
Часті питання
Чи можна використовувати реляційну і нереляційну базу в одному проекті?
Так, такий підхід називають поліглот-персистентністю: основні сутності зберігаються в реляційній базі, а дані зі змінною структурою або високим навантаженням на читання — у нереляційному сховищі поруч.
Яка база даних швидша — реляційна чи нереляційна?
Швидкість залежить від характеру запитів, а не від типу бази: точкове читання за ідентифікатором зазвичай швидке в обох моделях, а складні з'єднання кількох таблиць швидше виконує реляційна СУБД.
Чи потрібно знати SQL, щоб працювати з нереляційною базою даних?
Ні, у більшості нереляційних СУБД власна мова або API запитів, але розуміння реляційної моделі допомагає швидше розібратися, як дані пов'язані між собою в будь-якій базі.