Database Vocabulary: SQL, NoSQL, Indexing, and Transactions Explained (англійською)

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

---

Реляційні бази даних та SQL

Реляційна база даних

** Реляційна база даних ** організовує дані у таблиці (зв’ язки) з рядками і стовпчиками. Зв’ язки між таблицями визначаються за допомогою зовнішніх ключів. Приклади: PostgreSQL, MySQL, SQLite, Oracle, SQL Server.

SQL (англ. Structured Query Language) — мова структурованих запитів

** SQL ** — це стандартна мова для запитів і керування реляційними базами даних. Вимовляється як «секель» або «С-К-Л» (обидва правильно). Основні операції SQL:

• SELECT — читання даних
• INSERT — додає дані
• UPDATE — змінити дані
• DELETE — вилучення даних
• JOIN — об’єднує дані з декількох таблиць

Основний ключ

** Основний ключ ** — це стовпчик (або комбінація стовпчиків), який унікальним чином ідентифікує кожен рядок у таблиці. У кожного столика має бути такий. Часто це ціле число з автоматичним збільшенням (id) або UUID.

Іноземний ключ

** зовнішній ключ ** — це стовпчик у одній таблиці, який посилається на первинний ключ у іншій таблиці. Це встановлює зв’ язок між двома таблицями.

«Таблиця orders має зовнішній ключ user_id, який посилається на users.id.»

Index

** індекс ** — це структура даних, яка прискорює виконання запитів на стовпчик. Замість перегляду кожного рядка база даних використовує індекс для переходу безпосередньо до відповідних рядків. Індекси прискорюють читання, але уповільнюють запис (оскільки їх слід оновлювати під час вставлення/ оновлення/ вилучення).

Без індексу на email, кожен запит на входження робить повне сканування таблиці — працює на мільйонах рядків

Оптимізація запитів / Query Plan

** План запиту ** (або план виконання) — це стратегія, яку вибрав рушій бази даних для виконання запиту. Команда EXPLAIN в PostgreSQL і MySQL показує план і допомагає ідентифікувати повільні запити.

Normalisation

** Нормалізація ** — це процес структурування бази даних з метою зменшення надлишку і поліпшення цілісності даних. Вона включає розділення даних на окремі таблиці і використання зовнішніх ключів. Нормальні форми: 1NF, 2NF, 3NF, BCNF.

Denormalisation

** Денормалізація ** навмисно додає надлишковість для швидкодії — наприклад, зберігаючи попередньо обчислену суму в таблиці orders замість обчислення її з окремих елементів при кожному читанні.

JOIN

** JOIN ** об’ єднує рядки з двох таблиць на основі пов’ язаного стовпчика. Типи:

• ** INNER JOIN ** — тільки рядки, які збігаються в обох таблицях
• ** LEFT JOIN ** — всі рядки з лівої таблиці і відповідні рядки з правої
• ** RIGHT JOIN ** — всі рядки з правої таблиці і відповідні рядки з лівої
• ** FULL OUTER JOIN ** — всі рядки з обох таблиць

---

Властивості ACID

ACID визначає властивості, які гарантують надійність операцій з базою даних:

Atomicity

Транзація є ** атомарною **: або всі операції завершуються успішно, або жодна з них не завершується. Якщо оплата не відбудеться на півдорозі, всі зміни буде відкинуто.

Consistency

База даних переходить з одного ** послідовного ** стану в інший — всі правила цілісності даних (обмеження, зовнішні ключі, каскади) підтримуються.

Isolation

** Ізоляція ** означає, що одночасні транзакції не перешкоджають одна одній. Результат паралельних транзакцій має бути таким самим, якби вони виконувалися послідовно.

Durability

Після того, як транзакція ** затверджена **, вона переживе системні помилки. Дані записуються у постійне сховище.

---

Transactions

Transaction

** транзакція ** — це група операцій, які виконуються як єдиний об’ єкт. Або всі успішно (завершення) або всі невдало (відновлення).

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

Перенесення/ відновлення

• ** Затвердити ** — зберегти транзакцію назавжди
• ** Відкинути ** — скасувати всі зміни, внесені з моменту початку транзакції

Deadlock

** Застопорення ** відбувається, коли дві транзакції, кожна з яких має ресурс, який потрібний іншій, і обидві чекають. Ніхто не може продовжувати. Бази даних виявляють застої і переривають одну транзакцію.

---

Бази даних NoSQL

NoSQL

** NoSQL ** (« Не тільки SQL ») відноситься до баз даних, які не використовують модель реляційної таблиці. Вони розроблені для масштабованості, гнучкості або спеціальних шаблонів доступу до даних.

Типи:

• ** Document ** — зберігає документи типу JSON. Приклади: MongoDB, Firestore
• ** Key- value ** — зберігає довільні значення за ключем. Приклади: Redis, DynamoDB
• ** Column- family ** — зберігає дані у групах стовпчиків. Приклади: Cassandra, HBase
• ** Графік ** — зберігає вузли і ребра. Приклади: Neo4j, ArangoDB

База даних документів

** База даних документів ** зберігає дані у вигляді документів (зазвичай, JSON або BSON). Кожен документ може мати різну структуру — не потрібна жодна фіксована схема.

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

Ключ-цінність магазину

Сховище ** ключ- значення ** пов’ язує ключ зі значенням — подібно до карти гешів, але у масштабі бази даних. Найкраще підходить для кешування, зберігання сеансів, таблиць найкращих результатів і простих сценаріїв пошуку.

---

Розширення та розповсюдження

Sharding

** Шарування ** — це горизонтальне розділення — розділення даних на декілька екземплярів бази даних (шарів) за допомогою ключа шару. Дозволяє масштабування за межі можливостей однієї машини.

«Ми розділяємо за user_id — користувачі 0-1M йдуть до розділу 1, 1M-2M йдуть до розділу 2»

Replication

** Реплікація ** копіює дані з однієї бази даних (основної) до однієї або декількох реплік (додаткових). Надає високу доступність і може розподіляти навантаження читання.

• ** Основний (лідер) ** — приймає записи
• ** Реплікація (наступник) ** — синхронізація з головного, обслуговування читання

Теорема КАП

Теорема ** CAP ** стверджує, що розподілена база даних може гарантувати лише дві з трьох властивостей одночасно:

• ** Послідовність ** — кожне читання відображає останній запис
• ** Доступність ** — кожен запит отримує відповідь
• ** Допуск розділів ** — система працює незалежно від мережевих розділів

На практиці, мережеві розділи відбуваються - тому справжній вибір між CP і AP.

Послідовність можлива

У системах, які ** врешті- решт є послідовними **, всі репліки збираються до одного стану * врешті- решт *, але може бути вікно, у якому різні репліки повертають різні дані. Використовується в багатьох розподілених системах NoSQL.

Пул з’ єднань

** Пул з’ єднань ** — це кеш з’ єднань з базою даних, які можна використовувати знову для вхідних запитів. Відкриття з’ єднання коштує дорого; пул зберігає набір готових з’ єднань.

---

Спостереження та аналіз

Виконання запиту / Повільний журнал запиту

Більшість баз даних можуть записувати повільні запити — запити, які перевищують налаштовуваний поріг часу. Визначення і оптимізація повільних запитів є звичайною задачею налаштування бази даних.

N+1 запитів

Проблема N+1 виникає, коли код отримує список з N елементів, а потім робить додатковий запит для кожного елемента — що призводить до N+1 загальних запитів. Розв’ язання: скористайтеся JOIN або завантаженням з ентузіазмом.

Caching

Результати бази даних можуть бути ** кешовані ** в пам’яті (за допомогою Redis або Memcached), щоб уникнути повторних дорогих запитів. Недійсність кешу — знання того, коли закінчується термін дії кешу — є однією з найскладніших проблем в інженерії програмного забезпечення.

---

Краткий справочник

Term	One-liner
Primary key	Unique identifier for each row
Foreign key	References a primary key in another table
Index	Data structure that speeds up queries
Normalisation	Reducing redundancy via related tables
Atomicity	All-or-nothing transaction execution
Transaction	Group of operations executed as one unit
Deadlock	Two transactions blocking each other indefinitely
Sharding	Splitting data across multiple database instances
Replication	Copying data from primary to replica(s)
CAP theorem	Consistency, Availability, Partition tolerance — choose two
N+1 problem	Fetching list then querying per item — too many queries