Типи баз даних: особливості, відмінності та приклади

Сучасні компанії зберігають величезну кількість інформації: дані про операції, працівників, клієнтів, товар та інші важливі дані. Щось можна зберегти в Google Sheets, файлах Excel або навіть у друкованому вигляді в папках.

Однак якщо йдеться про велику компанію з мільйонами операцій на день, то в онлайн-документі інформація вже не вміститься. Для цього потрібні бази даних. У них можна зберігати, змінювати та швидко шукати інформацію.

DOU розповідає про типи баз даних і їхні відмінності.

Прості типи баз даних

Це бази даних із простою структурою. Наприклад, список дозволених IP-адрес для доступу до мережі, налаштування оточення проєкту, список підписників на розсилку компанії тощо.

Текстові файли

Інформація збирається в простих за структурою файлах різних форматів — txt, csv тощо. Для поділу полів застосовують пробіли, табуляцію, коми, крапку з комою та двокрапку.

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

Однак у таких базах важко встановити зв’язок між компонентами даних. Крім того, вони підходять не для всіх типів інформації.

Приклади: csv-файли, ini-файли.

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

Тут між збереженими об’єктами встановлюються зв’язки. Об’єкти поділяються на «пращурів» (основні класи чи категорії об’єктів) та «нащадків» (примірники цих класів чи категорій). При цьому кожен «нащадок» може мати не більше ніж одного «пращура». Графічним втіленням такої бази даних є деревоподібна структура.

Приклади: організація файлових систем; DNS та LDAP-з’єднання.

Відносини між об’єктами реалізовані як фізичні покажчики. Наприклад, у файловій системі шлях до папки або файлу будується з імен кореневих та вкладених каталогів. Ще однією особливістю є моделювання відносин вкладеності та підпорядкованості.

Але ієрархічна організація не передбачає зв’язку «багато-до-багатьох», через що система зберігання даних досить обмежена — забезпечує повільний доступ до сегментів даних нижніх рівнів ієрархії та орієнтується суто на певні типи запитів.

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

Ця технологія розширює функціональність ієрархічного підходу за допомогою моделювання складних відносин між об’єктами. Тут «нащадки» можуть мати більше, ніж одного «пращура», проте обмеження ієрархічного підходу зберігаються.

Приклад: IDMS — спеціалізована система управління базами даних для мейнфреймів.

Мережеві бази даних подаються не деревом, а загальним графом (сукупністю двох кінцевих множин).

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

Цей тип баз даних є найстарішим: теоретичні основи підходу заклав британський учений Едгар Кодд у 1970 році. Тут дані формуються у таблиці з рядків та стовпців. У рядках наводяться відомості про об’єкти (значення властивостей), а стовпці є властивостями об’єктів (поля).

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

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

Такий підхід дає змогу:

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

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

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

Використання денормалізації має бути ретельно осмислене. Потрібно бути впевненим у тому, що нормалізована структура, оптимізовані запити та правильно налаштовані індекси більше не здатні відповідати критерію швидкодії.

Переваги реляційного підходу:

  • Визначення складних відносин між об’єктами.
  • Нормалізація та денормалізація даних.
  • Структурована мова запитів.
  • Багата історія розвитку та широке поширення (основний інструмент розробки різних застосунків і сервісів).

Недоліки підходу: жорстка структура відомостей про об’єкти.

Приклади: MySQL, MariaDB, PostgreSQL, SQLite.

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

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

Для боротьби з цими обмеженнями розробили сімейство нереляційних БД.

Документоорієнтовані БД

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

Ці бази даних добре підходять для швидкої розробки систем та сервісів, що працюють з по-різному структурованими даними. Вони легко масштабуються та змінюють структуру за потреби.

Приклади: MongoDB, RethinkDB, CouchDB, DocumentDB.

Бази даних «Ключ-значення»

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

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

Крім того, вони мають високу швидкість доступу даних завдяки адресному зберіганню.

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

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

Приклади: DynamoDB, Redis, Riak, LevelDB, різні сховища кешу — наприклад, Memcached тощо.

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

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

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

Також технологія може використовуватися для аналізу економічної активності контрагентів для виявлення різних схем шахрайства. Наприклад, можна відстежити використання певних рахунків, карт чи реквізитів контрагентів у різних операціях.

Особливістю є висока продуктивність, оскільки обхід ребер і вершин значно швидший за аналіз безлічі зовнішніх і внутрішніх таблиць в реляційних БД.

Приклади: Neo4J, JanusGraph, Dgraph, OrientDB.

Стовпчикові, або колонкові бази даних

Записи в таких базах зберігаються не рядками, а стовпцями (колонками). Замість таблиць тут використовуються колонкові сімейства. Вони містять ключі, які вказують на формат рядка запису інформації про об’єкт. Кожен рядок має свій набір властивостей, що дозволяє зберігати у межах однієї родини по-різному структуровані дані.

Технологію активно використовують при побудові аналітичних систем та сервісів, що працюють з великими обсягами даних.

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

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

Приклади: Cassandra, HBase, ClickHouse.

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

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

Особливістю цієї БД є те, що можливо обробляти постійний потік вхідних даних.

Продуктивність залежить від обсягу інформації, що надходить, і кількості метрик, що відстежуються.

Приклади БД: OpenTSDB, Prometheus, InfluxDB, TimescaleDB

Бази даних NewSQL

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

Термін запропонував у 2011 році аналітик компанії 451 Group Метью Аслет. Він відзначав високу потребу в таких системах для сфер, що працюють з критичними даними, — охорона здоров’я, FinTech тощо. Характерними ознаками цих рішень є використання алгоритмів консенсусу (алгоритм Paxos, Raft тощо), шардування і заточування під горизонтальне масштабування.

Особливостями цього типу БД є широкі можливості масштабування та велика продуктивність і доступність даних. Однак є високі вимоги до апаратних ресурсів розробників.

Застосування такої БД має сенс за умови розробки продукту, який можна характеризувати як високонавантажену систему.

Приклади: MemSQL, VoltDB, Spanner та ін.

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

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

Особливості:

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

Приклад рішення такого типу: ArangoDB.

Найпоширенішими базами даних є MySQL, Oracle Database, PostgreSQL, Microsoft SQL Server та MongoDB.


Джерела: Prisma’s Data Guide; Навчальний посібник «Основи баз даних», І.О. Завадський

Все про українське ІТ в Телеграмі — підписуйтеся на канал редакції DOU

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному10
LinkedIn



4 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Нормальний огляд, було б корисно побільше картинок і реальних простеньких прикладів, аби візуально показати, наприклад в ч.2!

Як на мене, цьому шкільному реферату не місце на ДОУ

ти написав ще менше

Чекатимемо на шанс торкнутись твоїх знань в БД, прометей

Найпоширенішими базами даних є MySQL, Oracle Database, PostgreSQL, Microsoft SQL Server та MongoDB.

db-engines.com/en/ranking

Підписатись на коментарі