Будь-які дані десь зберігаються. Проаналізуємо схеми основні типи баз даних, щоб наочно уявити відмінності між ними.
Типами баз даних, які називаються також моделями БД або сімействами БД, є шаблони і структури, які використовуються для організації даних в системі управління базами даних (СУБД). Вибір типу вплине на те, які операції зможе виконувати додаток та як будуть представлені дані.
Найпростіші типи баз даних
Почнемо з трьох типів БД, які все ще можуть зустрічатися в спеціалізованих середовищах, але в основному замінені надійними і продуктивними альтернативами.
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
Реляційні БД
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
Комбіновані типи
NewSQL і багатомодельні БД є різними типами баз даних, але вирішують одну групу проблем, викликаних полярними підходами SQL або NoSQL-стратегії. Чому б не об'єднати переваги обох груп?
10. NewSQL бази даних
NewSQL бази даних успадковують реляційну структуру і семантику, але побудовані з використанням більш сучасних, масштабованих конструкцій. Мета - забезпечити більшу масштабованість, ніж реляційні БД, і більш високі гарантії узгодженості, ніж в NoSQL. Компроміс між узгодженістю і доступністю є фундаментальною проблемою розподілених баз даних, описаних теоремою CAP.
Наслідки:
- можливість горизонтального масштабування;
- висока доступність;
- велика продуктивність і реплікація;
- невеликий функціонал і гнучкість;
- чимале споживання ресурсів і необхідність спеціалізованих знань для роботи з базою даних.
Приклади:
- MemSQL
- VoltDB
- Spanner
- Calvin
- CockroachDB
- FaunaDB
- yugabyteDB
11. Багатомодельні бази даних
Багатомодельні бази даних - бази, які поєднують функціональні можливості кількох видів БД. Переваги такого підходу очевидні - одна і та ж система може використовувати різні уявлення для різних типів даних.
Спільне розміщення даних з декількох типів БД в одній системі дозволяє виконувати нові операції, які в іншому випадку були б ускладнені або неможливі. Наприклад, багатомодельні бази можуть дозволити користувачам отримати доступ до даних, що зберігаються в різних типах БД, і управляти ними в рамках одного запиту, а також підтримують узгодженість даних при виконанні операцій, що змінюють інформацію відразу в декількох системах.
Наслідки:
- допомагають зменшити навантаження на СУБД;
- дозволяють розширюватися до нових моделей у міру зміни потреб без внесення змін до базової інфраструктури;
- забезпечують безперервний доступ і простий розподіл даних;
- мають лінійну масштабованість і прості для розробки.
Приклади:
- ArangoDB
- OrientDB
- Couchbase
Висновок
Зміна типів даних, що зберігаються, вимоги до швидкості і продуктивності привели до триваючого розширення типів баз даних. При цьому кожен з них продовжує бути потрібним у своїй ніші, де взаємозв'язки між даними асоціюються з певною схемою будови бази даних.
0 комментариев
Добавить комментарий