Пошук уроків, статей та іншого контенту
Порівняєте реляційні та нереляційні бази даних, їхні моделі, переваги, обмеження й типові сценарії використання.
База даних зберігає дані так, щоб застосунок міг:
швидко знаходити потрібні записи;
додавати, змінювати й видаляти дані;
забезпечувати узгодженість даних;
працювати з багатьма запитами одночасно.
У системному дизайні часто потрібно обрати тип бази даних. Один із найпоширеніших виборів — SQL або NoSQL.
SQL-бази даних, або реляційні бази даних, зберігають дані у вигляді:
таблиць;
рядків;
стовпців;
зв’язків між таблицями.
Кожна таблиця зазвичай описує окрему сутність. Наприклад:
users — користувачі;
orders — замовлення;
products — товари.
Таблиці можуть бути пов’язані між собою за допомогою ключів.
Таблиця users:
id | name
---|------
1 | Олена
2 | АндрійТаблиця orders:
id | user_id | total
---|---------|------
10 | 1 | 1200
11 | 2 | 800Поле user_id посилається на користувача з таблиці users. Так утворюється зв’язок між таблицями.
Для роботи з реляційною базою використовують SQL — Structured Query Language.
Приклад із SQLite:
CREATE TABLE users (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL
);
CREATE TABLE orders (
id INTEGER PRIMARY KEY,
user_id INTEGER NOT NULL,
total_cents INTEGER NOT NULL,
FOREIGN KEY (user_id) REFERENCES users(id)
);
INSERT INTO users (name)
VALUES
('Олена'),
('Андрій');
INSERT INTO orders (user_id, total_cents)
VALUES
(1, 120000),
(2, 80000),
(1, 45000);
SELECT
users.name,
SUM(orders.total_cents) AS total_spent
FROM users
JOIN orders ON orders.user_id = users.id
GROUP BY users.id, users.name
ORDER BY total_spent DESC;Останній запит:
об’єднує таблиці users і orders;
групує замовлення за користувачем;
обчислює загальну суму покупок;
сортує користувачів за витратами.
У реляційній базі структура таблиць зазвичай визначена заздалегідь. Наприклад, у стовпці name очікується текст, а в total_cents — число.
Така структура називається схемою.
Схема допомагає:
виявляти помилки під час запису;
підтримувати однаковий формат даних;
чітко описувати зв’язки;
полегшувати аналіз і підтримку системи.
Зміна схеми зазвичай потребує міграції. Наприклад, щоб додати нове поле до великої таблиці, потрібно виконати спеціальну операцію зміни структури.
NoSQL — це загальна назва для баз даних, які не використовують класичну реляційну модель як основну.
NoSQL не означає «база даних без SQL» у буквальному сенсі. Зазвичай це означає, що база має іншу модель зберігання даних.
Основні типи NoSQL-баз:
документні;
ключ-значення;
ширококолонкові;
графові.
Документна база зберігає записи у вигляді документів, часто схожих на JSON.
Наприклад, замовлення можна представити так:
{
"id": 10,
"user": {
"id": 1,
"name": "Олена"
},
"items": [
{
"productId": 101,
"name": "Клавіатура",
"quantity": 1,
"priceCents": 120000
}
],
"totalCents": 120000
}Усі дані конкретного замовлення можуть зберігатися в одному документі. Не обов’язково створювати окремі таблиці для користувача, замовлення та позицій замовлення.
Це зручно, коли застосунок найчастіше отримує весь об’єкт цілком.
У базі ключ-значення кожен запис має ключ і значення:
"session:abc123" -> {
"userId": 42,
"expiresAt": "2026-09-02T12:00:00Z"
}Такі бази добре підходять для:
сесій користувачів;
кешу;
лічильників;
простих налаштувань.
Головна операція — отримати значення за ключем.
Ширококолонкові бази оптимізовані для дуже великих обсягів даних і розподіленого зберігання.
Вони можуть бути корисними для:
потоків подій;
телеметрії;
історії показників;
систем, які записують багато даних на великій кількості серверів.
Графові бази представляють дані як:
вузли;
зв’язки між вузлами;
властивості вузлів і зв’язків.
Наприклад, соціальна мережа може зберігати:
користувачів як вузли;
підписки як зв’язки;
рекомендації як результат аналізу зв’язків.
SQL:
таблиці та рядки;
явні зв’язки;
нормалізовані дані;
запити через SQL.
NoSQL:
документи, ключі, колонки або графи;
структура залежить від типу бази;
дані часто зберігаються разом із пов’язаним об’єктом;
запити залежать від конкретної технології.
У SQL схема зазвичай сувора. Поля, їхні типи та зв’язки визначаються заздалегідь.
У NoSQL схема часто гнучкіша. Два документи в одній колекції можуть мати різний набір полів.
Гнучкість не означає відсутність правил. Якщо застосунок не контролює структуру документів, дані можуть стати непослідовними. Тому правила структури все одно потрібно визначати на рівні застосунку або самої бази, якщо вона це підтримує.
SQL добре працює зі складними зв’язками:
один до одного;
один до багатьох;
багато до багатьох.
Для цього використовують зовнішні ключі та JOIN.
У NoSQL зв’язки часто реалізують одним із двох способів:
Вкладенням — пов’язані дані зберігаються всередині документа.
Посиланням — документ містить ідентифікатор іншого документа.
Вкладення зменшує кількість запитів, але може призвести до дублювання даних. Посилання зменшує дублювання, але для отримання повної інформації може знадобитися кілька запитів.
Транзакція — це група операцій, яка виконується як єдине ціле.
Наприклад, під час переказу грошей потрібно:
зменшити баланс одного рахунку;
збільшити баланс іншого рахунку.
Якщо друга операція не виконалася, перша також не повинна залишитися застосованою.
Реляційні бази традиційно сильні в таких операціях і широко використовують властивості ACID:
Atomicity — усі операції виконуються або жодна;
Consistency — дані залишаються коректними;
Isolation — паралельні транзакції не заважають одна одній;
Durability — підтверджені дані не губляться після збою.
Багато сучасних NoSQL-баз також підтримують транзакції, але їхні можливості й вартість потрібно перевіряти для конкретної технології. Не можна вважати, що кожна NoSQL-база автоматично має такі самі гарантії, як реляційна база.
Реляційні бази часто починають масштабувати вертикально:
збільшують пам’ять сервера;
використовують потужніший процесор;
швидше сховище.
За потреби SQL-бази також можуть масштабуватися горизонтально за допомогою реплік, розподілення даних та інших підходів. Це не означає, що SQL-бази масштабуються лише на одному сервері.
NoSQL-бази часто проєктувалися з урахуванням розподіленої роботи. Їх може бути простіше розподілити між багатьма серверами для певного типу навантаження.
Однак горизонтальне масштабування не є автоматичною перевагою. Воно залежить від:
способу доступу до даних;
ключів розподілення;
характеру запитів;
вимог до узгодженості.
Реляційна база часто є хорошим вибором, коли:
дані мають чітку структуру;
між сутностями є багато зв’язків;
потрібні складні запити та агрегації;
важлива цілісність даних;
необхідні надійні транзакції;
команда добре знає SQL.
Типові приклади:
банківські операції;
облік товарів;
замовлення в інтернет-магазині;
системи бухгалтерського обліку;
CRM-системи;
адмінпанелі та звіти.
SQL-бази можуть створювати складнощі, коли:
структура даних часто змінюється;
записи мають дуже різні поля;
потрібно швидко розподіляти величезний обсяг даних між багатьма серверами;
основний сценарій полягає у простому доступі за ключем, а реляційні можливості майже не використовуються.
Це не означає, що SQL не можна застосовувати в таких системах. Просто в конкретному випадку інша модель може бути зручнішою.
NoSQL-база може бути хорошим вибором, коли:
структура даних змінюється або має багато варіантів;
об’єкт зручно зберігати одним документом;
потрібен дуже швидкий доступ за ключем;
система працює з великим потоком записів;
дані природно представлені графом;
горизонтальне масштабування є основною вимогою.
Типові приклади:
кеш і сесії;
каталоги товарів із різними характеристиками;
стрічки подій;
дані IoT-пристроїв;
профілі з різними наборами полів;
соціальні зв’язки.
NoSQL-бази можуть бути менш зручними, коли:
потрібні складні зв’язки між багатьма сутностями;
необхідні складні аналітичні запити;
дані часто оновлюються в кількох місцях;
важливі суворі обмеження цілісності;
команда не має чіткого плану доступу до даних.
У документній базі структуру даних часто проєктують не від абстрактних сутностей, а від запитів застосунку.
Наприклад, якщо застосунок завжди отримує замовлення разом із його позиціями, їх можна зберігати в одному документі. Але якщо позиції потрібно часто шукати незалежно від замовлень, таке вкладення може бути незручним.
Починайте не з назви технології, а з вимог до системи.
Поставте такі запитання:
Які дані потрібно зберігати?
Наскільки стабільна їхня структура?
Які запити виконуватимуться найчастіше?
Чи є складні зв’язки між сутностями?
Чи потрібні транзакції між кількома об’єктами?
Який очікується обсяг даних?
Які вимоги до затримки відповіді?
Як система має масштабуватися?
Які гарантії узгодженості потрібні?
Які технології добре знає команда?
Для інтернет-магазину часто підходить SQL-база для:
користувачів;
замовлень;
оплат;
залишків товарів.
Ці дані мають зв’язки та потребують транзакцій.
Окремо можна використати NoSQL-базу або кеш для:
швидкого збереження кошика;
сесій;
кешованого каталогу;
подій перегляду товарів.
Це називається поліглотним зберіганням — використанням різних типів баз даних для різних задач. Але такий підхід додає складності, тому не варто використовувати кілька баз без чіткої потреби.
Швидкодія залежить від:
структури даних;
індексів;
запитів;
обсягу даних;
конфігурації;
характеру навантаження.
NoSQL не є автоматично швидшою за SQL.
Реляційні бази використовують у дуже великих і навантажених системах. Їхні можливості масштабування можуть бути складнішими, але SQL сам по собі не обмежує систему малим розміром.
Навіть якщо база дозволяє зберігати документи різної структури, застосунку все одно потрібні правила. Інакше різні частини системи можуть по-різному трактувати одні й ті самі дані.
Популярність технології не замінює аналіз вимог. Спочатку потрібно визначити модель даних і запити, а вже потім вибирати конкретний інструмент.
Дублювання може прискорити читання в NoSQL, але створює ризик розбіжностей. Потрібно заздалегідь визначити:
яке поле є основним джерелом;
де оновлюються дані;
як синхронізуються копії.
SQL-бази зберігають дані в таблицях і добре працюють зі зв’язками, транзакціями та складними запитами.
NoSQL — це група різних моделей: документна, ключ-значення, ширококолонкова та графова.
SQL зазвичай має строгу схему, а NoSQL часто дозволяє гнучкішу структуру.
NoSQL може бути зручнішою для доступу за ключем, документів, великих потоків даних і розподілених систем.
Обидва підходи можуть масштабуватися, забезпечувати високу швидкодію та підтримувати транзакції — залежно від конкретної технології.
Вибір потрібно робити на основі структури даних, запитів, вимог до узгодженості, транзакцій і масштабування.
Найкраща база даних — не та, що популярніша, а та, чия модель відповідає задачам системи.