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

Типами баз даних, які називаються також моделями БД або сімействами БД, є шаблони і структури, які використовуються для організації даних в системі управління базами даних (СУБД). Вибір типу вплине на те, які операції зможе виконувати додаток та як будуть представлені дані.

1. Найпростіші типи баз даних

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

1. Прості структури даних

Перший і найпростіший спосіб зберігання даних - текстові файли. Метод застосовується і сьогодні для роботи з невеликими обсягами інформації. Для поділу полів використовується спеціальний символ: кома або крапка з комою в csv-файлах датасета, двокрапка або пробіл в * nix-подібних системах:

/ Etc / passwd в * nix системі

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
syslog:x:102:106::/home/syslog:/usr/sbin/nologin
bob:x:1000:1000:Bob Smith,,,:/home/bob:/bin/bash 

Наслідки:

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

Приклади:

• /etc/passwdі /etc/fstab в * nix-системах
• csv-файли

2. Ієрархічні бази даних

На відміну від текстових таблиць, в наступному типі БД з'являються зв'язки між об'єктами. В ієрархічних базах даних кожен запис має одного «батька». Це створює деревоподібну структуру, в якій записи класифікуються за їхніми стосункам з ланцюжком батьківських записів.

Приклад побудови ієрархічних зв'язків

Наслідки:

• інформація організована у вигляді дерева з відносинами «предок-нащадок»;
• кожен запис може мати не більше одного з батьків;
• зв'язки між записами виконані у вигляді фізичних покажчиків;
• неможливо реалізувати відносини «багатьох до багатьох».

Приклади:

• файлові системи
• DNS
• LDAP

3. Мережеві бази даних

Мережеві бази даних розширюють функціональність ієрархічних: записи можуть мати більше одного батька. А значить, можна моделювати складні відносини.

Приклад зв'язків в мережевій базі даних

Наслідки:

• мережеві бази даних подаються не деревом, а загальним графом
• обмежені тими ж шаблонами доступу, що ієрархічні БД

Приклади:

• IDMS

1. Реляційні БД

4. SQL бази даних

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

Наслідки:

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

Приклади:

• MySQL
• MariaDB
• PostgreSQL
• SQLite

III. NoSQL бази даних

NoSQL - група типів БД, що пропонують підходи, відмінні від стандартного реляційного шаблону. Говорячи NoSQL, мають на увазі або "не-SQL», або «не тільки SQL», щоб уточнити, що іноді допускається SQL-подібний запит.

5. Бази даних «ключ-значення»

У базах даних «ключ-значення» для зберігання інформації ви предоставляте ключ і об'єкт даних, який потрібно зберегти. Наприклад, JSON-об'єкт, зображення або текст. Щоб зробити запит, відправляєте ключ і отримуєте blob-об'єкт .

Наслідки:

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

Приклади:

• Redis
• memcached
• etcd

6. Документні бази даних

Документні бази даних (також документоорієнтовані БД або сховища документів), спільно використовують базову семантику доступу і пошуку сховищ ключів і значень. Такі БД також використовують ключ для унікальної ідентифікації даних. Різниця між сховищами «ключ-значення» і документними БД полягає в тому, що замість зберігання blob-об'єктів, документоорієнтовані бази зберігають дані в структурованих форматах - JSON, BSON або XML.

Наслідки:

• база даних не виділяє окремий формат або схему;
• кожен документ може мати свою внутрішню структуру;
• документні БД є хорошим вибором для швидкої розробки;
• в будь-який момент можна змінювати властивості даних, не змінюючи структуру або самі дані.

Приклади:

• MongoDB
• RethinkDB

7. Графові бази даних

Замість зіставлення зв'язків з таблицями і зовнішніми ключами, графові бази даних встановлюють зв'язки, використовуючи вузли, ребра і властивості.

Графові бази представляють дані у вигляді окремих вузлів, які можуть мати будь-яку кількість пов'язаних з ними властивостей.

Наслідки:

• виглядають аналогічно мережевим;
• фокусуються на зв'язках між елементами;
• явно відображають зв'язки між типами даних;
• не вимагають покрокового обходу для переміщення між елементами;
• немає обмежень в типах зв'язків.

Приклади:

• Neo4j
• JanusGraph
• Dgraph

8. Стовбчикові бази даних

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

У реляційних БД всі рядки повинні відповідати фіксованій схемою. Схема визначає, які стовпчики будуть в таблиці, типи даних та інші критерії. У стовпчикових базах замість таблиць є структури - «стовпчик сімейства». Сімейства містять рядки, кожна з яких визначає власний формат. Рядок складається з унікального ідентифікатора, що використовується для пошуку, за яким слідують набори імен та значень стовпців.

Наслідки:

• БД зручні при роботі з додатками, що вимагають високої продуктивності;
• дані та метадані доступні по одному ідентифікатору;
• гарантоване розміщення всіх даних з рядка в одному кластері, що спрощує сегментацію і масштабування даних.

Приклади:

• Cassandra
• HBase

9. Бази даних часових рядів

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

Наслідки:

• орієнтовані на запис;
• призначені для обробки постійного потоку вхідних даних;
• продуктивність залежить від кількості відслідковуваних елементів, інтервалу опитування між записом нових значень і фактичного корисного навантаження даних.

Приклади:

• OpenTSDB
• Prometheus
• InfluxDB
• TimescaleDB

1. Комбіновані типи

NewSQL і багатомодельні БД є різними типами баз даних, але вирішують одну групу проблем, викликаних полярними підходами SQL або NoSQL-стратегії. Чому б не об'єднати переваги обох груп?

10. NewSQL бази даних

NewSQL бази даних успадковують реляційну структуру і семантику, але побудовані з використанням більш сучасних, масштабованих конструкцій. Мета - забезпечити більшу масштабованість, ніж реляційні БД, і більш високі гарантії узгодженості, ніж в NoSQL. Компроміс між узгодженістю і доступністю є фундаментальною проблемою розподілених баз даних, описаних теоремою CAP.

Наслідки:

• можливість горизонтального масштабування;
• висока доступність;
• велика продуктивність і реплікація;
• невеликий функціонал і гнучкість;
• чимале споживання ресурсів і необхідність спеціалізованих знань для роботи з базою даних.

Приклади:

• MemSQL
• VoltDB
• Spanner
• Calvin
• CockroachDB
• FaunaDB
• yugabyteDB

11. Багатомодельні бази даних

Багатомодельні бази даних - бази, які поєднують функціональні можливості кількох видів БД. Переваги такого підходу очевидні - одна і та ж система може використовувати різні уявлення для різних типів даних.

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

Наслідки:

• допомагають зменшити навантаження на СУБД;
• дозволяють розширюватися до нових моделей у міру зміни потреб без внесення змін до базової інфраструктури;
• забезпечують безперервний доступ і простий розподіл даних;
• мають лінійну масштабованість і прості для розробки.

Приклади:

• ArangoDB
• OrientDB
• Couchbase

Висновок

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

Джерело перекладу