Типы баз данных: реляционные, NoSQL и другие модели

Урок 1.2 · Время чтения: ~20 мин · Задачи для практики ↓

Существует много типов баз данных, каждый из которых оптимизирован под определённый вид данных, шаблон запросов или требования к масштабируемости. В этом уроке вы узнаете об основных моделях БД - реляционных, ключ-значение, документных, широкостолбцовых, графовых, базах временных рядов и колоночных базах данных - с их ключевыми отличиями, типичными сценариями применения и примерами реальных систем. Для каждого типа вы увидите, как в нём выглядят одни и те же данные интернет-магазина.

В предыдущем уроке мы познакомились с общей идеей базы данных и СУБД. На практике не все базы данных устроены одинаково. Разные типы БД оптимизированы под разные виды данных, шаблоны запросов, требования к масштабируемости и потребности в согласованности.

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

Почему существуют разные типы баз данных?

Ни одна модель базы данных не является идеальной для всех приложений.

Например:

• Банковской системе необходимы высокая согласованность и надёжные транзакции.
• Системе кэширования нужен чрезвычайно быстрый поиск по ключу.
• Социальная сеть может нуждаться в гибком документном хранилище и анализе связей в стиле графов.
• Аналитической платформе может потребоваться эффективно обрабатывать миллиарды значений для отчётности.

Поскольку разные системы решают разные задачи, со временем появилось несколько моделей баз данных.

Основные типы баз данных: сравнительная таблица

Краткое сравнение перед подробным разбором каждого типа:

Реляционные базы данных

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

Эта модель особенно хорошо подходит, когда данные хорошо структурированы и важны точность, согласованность и сложные запросы.

Основные свойства реляционных баз данных

1. Структурированная схема

Реляционные БД обычно требуют чётко определённой схемы. Перед сохранением данных задаются таблицы, столбцы, типы данных, ограничения и связи. Это делает структуру предсказуемой и удобной для проверки.

2. Связи между таблицами

Одна из главных сильных сторон реляционных систем - возможность явно моделировать связи между сущностями.

Например:

• Таблица customers может быть связана с таблицей orders.
• Таблица orders - с таблицей order_items.

3. Поддержка SQL

Реляционные БД запрашиваются с помощью SQL (Structured Query Language) - стандартного языка для фильтрации, соединения, агрегации, сортировки и изменения структурированных данных.

4. ACID-транзакции

Реляционные БД хорошо известны поддержкой свойств ACID:

• Атомарность: транзакция либо полностью выполняется, либо полностью откатывается.
• Согласованность: данные остаются корректными согласно заданным правилам.
• Изолированность: параллельные транзакции не влияют некорректно друг на друга.
• Долговечность: после фиксации данные сохраняются даже после сбоев.

Эти свойства критически важны в банковских системах, биллинге, бронировании и управлении запасами.

5. Ограничения целостности данных

Реляционные БД могут применять правила на уровне базы: первичные ключи, внешние ключи, ограничения уникальности, NOT NULL, CHECK. Это предотвращает некорректные или несогласованные данные.

6. Мощные соединения и отчётность

Реляционные БД отлично подходят для объединения информации из нескольких таблиц - именно поэтому они остаются центральными для отчётности, аналитики и финансовых систем.

7. Нормализация и снижение избыточности

Реляционное проектирование часто использует нормализацию: организацию данных в связанных таблицах для уменьшения дублирования. Например, информация о клиенте хранится один раз в customers, а не повторяется в каждом заказе.

Типичные сценарии использования реляционных БД

Реляционные базы данных - лучший выбор, когда:

• данные структурированы и чётко определены
• связи между сущностями важны
• транзакции должны быть надёжными
• согласованность важнее гибкости схемы
• приложению нужны сложные запросы и отчётность

Примеры реляционных баз данных

• PostgreSQL: Мощная open-source СУБД с расширенными возможностями.
• MySQL: Популярная СУБД для веб-приложений.
• MariaDB: Форк MySQL, развиваемый сообществом.
• SQLite: Лёгкая встроенная СУБД, хранящаяся в одном файле.
• Oracle Database: СУБД корпоративного уровня.
• Microsoft SQL Server: СУБД для корпоративных сред.

Базы данных типа ключ-значение

Базы данных ключ-значение хранят данные как простую пару: ключ и связанное с ним значение. Доступ идёт непосредственно по ключу - модель очень простая и очень быстрая.

Ключевые особенности

• Доступ по одному ключу, а не через сложные соединения.
• База не понимает внутреннюю структуру значения.
• Оптимизированы для сверхбыстрых чтений и записей.

Типичные сценарии

• кэширование результатов запросов
• хранение пользовательских сессий
• корзины покупок
• feature flags, rate limiting
• таблицы лидеров и счётчики

Примеры: Redis, Amazon DynamoDB, Riak

Документные базы данных

Документные БД хранят данные в виде документов в формате, похожем на JSON. Каждый документ может содержать поля, массивы и вложенные объекты. Структура документов может различаться.

{
  "_id": 1,
  "order_date": "2026-03-14",
  "customer": { "id": 42, "name": "Ann", "city": "Lisbon" },
  "items": [
    { "product": "Keyboard", "qty": 1, "price": 79.50 },
    { "product": "Mouse pad", "qty": 2, "price": 10.00 }
  ],
  "total": 99.50
}

{
  "_id": 2,
  "order_date": "2026-04-02",
  "customer": { "id": 42, "name": "Ann" },
  "items": [ { "product": "Gift card", "qty": 1, "price": 15.00 } ],
  "gift_message": "Happy birthday!",
  "total": 15.00
}

Ключевые особенности

• Гибкая или полугибкая схема.
• Связанные данные часто хранятся вместе в одном документе.
• Удобны для приложений с часто меняющейся структурой.

Типичные сценарии

• системы управления контентом
• товарные каталоги
• профили пользователей
• мобильные и веб-приложения

Примеры: MongoDB, Couchbase, Google Firestore

Широкостолбцовые базы данных

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

customer:42
    info:name    = Ann
    info:city    = Lisbon
    orders:1     = 99.50
    orders:2     = 15.00
customer:43
    info:name    = Bob
    orders:3     = 12.00

Ключевые особенности

• Схема гибче, чем в реляционных БД.
• Оптимизированы для крупномасштабного распределённого хранения.
• Хорошо справляются с огромными объёмами данных и интенсивной записью.

Типичные сценарии

• журналирование событий, IoT-телеметрия
• системы сообщений с интенсивной записью
• географически распределённые системы

Примеры: Apache Cassandra, Apache HBase, ScyllaDB

Колоночные аналитические базы данных

Хранение по строкам:
[1, 42, 2026-03-14, 99.50] [2, 42, 2026-04-02, 15.00] [3, 43, 2026-04-02, 12.00]

Хранение по столбцам:
id:          1, 2, 3
customer_id: 42, 42, 43
order_date:  2026-03-14, 2026-04-02, 2026-04-02
total:       99.50, 15.00, 12.00

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

Ключевые особенности

• Оптимизированы для сканирования и агрегации больших объёмов.
• Высокоэффективны для отчётности и аналитики.
• Хуже подходят для транзакционных нагрузок с частыми обновлениями строк.

Типичные сценарии

• business intelligence, дашборды
• хранилища данных и OLAP
• аналитика логов в большом масштабе

Примеры: ClickHouse, DuckDB, Amazon Redshift, Google BigQuery

Графовые базы данных

Графовые БД предназначены для данных, где связи - самая важная часть модели. Хранят узлы (сущности) и рёбра (связи).

(Ann:Customer)-[:PLACED]->(Order 1 { total: 99.50 })-[:CONTAINS]->(Mouse pad:Product)
(Ann:Customer)-[:PLACED]->(Order 1 { total: 99.50 })-[:CONTAINS]->(Keyboard:Product)
(Bob:Customer)-[:PLACED]->(Order 3 { total: 12.00 })-[:CONTAINS]->(Mouse pad:Product)
(Bob:Customer)-[:FOLLOWS]->(Ann:Customer)

Ключевые особенности

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

Типичные сценарии

• социальные сети, обнаружение мошенничества
• рекомендательные системы, графы знаний

Примеры: Neo4j, Amazon Neptune, ArangoDB

Базы данных временных рядов

Специализированы для данных, связанных со временем. Оптимизированы для высокой скорости загрузки, политик хранения, сжатия и агрегации по временным окнам.

Ключевые особенности

• Каждая запись содержит временную метку.
• Запросы часто сосредоточены на диапазонах: последний час, день, месяц.

Типичные сценарии

• мониторинг серверов и приложений
• IoT-датчики, биржевые данные

Примеры: InfluxDB, TimescaleDB, OpenTSDB

Базы данных в памяти

Хранят большую часть или все данные в RAM, а не на диске. Это обеспечивает сверхнизкую задержку, хотя память дороже дискового хранилища.

top_customers
    customer:42    114.5
    customer:43    12

Типичные сценарии

• кэширование, хранение сессий
• счётчики реального времени, игровые таблицы лидеров

Примеры: Redis, Memcached, SAP HANA

Как выбрать подходящий тип базы данных

При выборе БД задайте себе эти вопросы:

• Данные строго структурированы или гибкие?
• Нужны ли строгие ACID-транзакции?
• Будут ли сложные соединения таблиц?
• Является ли быстрый поиск по ключу главным приоритетом?
• Нагрузка транзакционная или аналитическая?
• Будет ли система масштабироваться на множество серверов?
• Связи между сущностями - центральная часть приложения?

Во многих реальных системах используется более одного типа БД:

• реляционная БД - для основных бизнес-данных
• Redis - для кэширования
• документная БД - для гибкого контента
• колоночное хранилище - для аналитики

Такой подход называют polyglot persistence (полиглотная персистентность).

Краткое резюме: ключевые различия между типами БД

Ключевые выводы:

• Разные типы БД существуют потому, что разные приложения имеют разные технические и бизнес-требования.
• Реляционные БД - лучший выбор для структурированных данных со связями, ACID-транзакциями и SQL.
• Ключ-значение - для быстрого поиска и кэширования.
• Документные - когда структура данных гибкая или часто меняется.
• Широкостолбцовые - для распределённых, крупномасштабных нагрузок с интенсивной записью.
• Колоночные аналитические - для отчётности и аналитики в большом масштабе.
• Графовые - для данных, богатых связями.
• Временных рядов - для метрик и событий, привязанных ко времени.
• Многие современные системы используют несколько типов БД одновременно.

Часто задаваемые вопросы

В чём разница между реляционными и NoSQL базами данных?

Реляционные БД используют фиксированную табличную схему, обеспечивают ACID-транзакции и запрашиваются через SQL. NoSQL - зонтичный термин для ключ-значение, документных, широкостолбцовых и графовых моделей: они жертвуют частью гарантий согласованности ради гибкости схемы или горизонтального масштабирования. Правильный выбор зависит от данных и нагрузки.

Когда использовать документную БД вместо реляционной?

Используйте документную БД, когда данные имеют вложенную переменную структуру (например, каталог товаров с разными атрибутами) и соединения между коллекциями редки. Используйте реляционную БД, когда данные структурированы, сущности взаимосвязаны и нужны надёжные транзакции с многотабличными запросами.

Может ли одно приложение использовать несколько типов БД?

Да - это называется polyglot persistence. Типичный пример: PostgreSQL для транзакционных данных, Redis для кэширования, ClickHouse для аналитики. Каждый тип БД используется там, где он показывает лучшую производительность.

Вопросы для собеседования

Какой тип базы данных вы выберете для конкретного сценария и почему?

Начните с требований к нагрузке: структура данных, требования к согласованности, тип запросов, целевая задержка и масштаб. Например, реляционная БД подходит для ACID-транзакций, документная БД - для гибких JSON-подобных структур, а БД временных рядов - для метрик с временными метками.

Какие плюсы и минусы у одного типа БД по сравнению с другим?

Каждая модель - это компромисс. Реляционные БД дают строгую согласованность, соединения и зрелую SQL-экосистему, но изменения схемы могут быть более жёсткими на большом масштабе. Модели NoSQL часто дают больше гибкости или горизонтального масштабирования, но могут ограничивать соединения и требовать более внимательного проектирования согласованности.

Можно ли использовать разные типы баз данных в одном приложении?

Да. Это называется polyglot persistence: в одной системе используются несколько БД, каждая под свой профиль нагрузки. Типичный вариант: PostgreSQL для транзакций, Redis для кэширования и ClickHouse (или другое колоночное хранилище) для аналитики.