Реляционные БД vs Нереляционные БД

Сравнение реляционных (SQL) и нереляционных (NoSQL) баз данных. Реляционные: таблицы, фиксированная схема (schema-on-write), ACID, вертикальное масштабирование, строгие связи через внешние ключи — для финансов, бронирования, учёта. Нереляционные: документы, ключ-значение, графы, гибкая схема (schema-on-read), BASE, горизонтальное масштабирование — для каталогов, логов, кешей, высоких нагрузок. Примеры, критерии выбора и гибридный подход.

Введение: Две философии хранения данных

Представьте, что вам нужно хранить информацию о клиентах банка. Можно завести толстую тетрадь, где на каждой странице ровные колонки: имя, паспорт, адрес, телефон. Все записи одинаковы. Это аккуратно, строго, но если у клиента три телефона, придётся заводить три строки или добавлять колонку “телефон2”. Это реляционный подход.

А можно завести картотеку, где у каждого клиента своя папка. В папке могут быть любые документы: паспорт, выписки, фотографии. У одного клиента три телефона — в папке три листочка с телефонами. У другого — только один. Папки не обязаны быть одинаковыми. Это нереляционный подход.

Реляционные базы данных (SQL) — это строгие таблицы с фиксированной схемой, связанные через внешние ключи. Данные нормализованы, целостность на высоте. Это фундамент транзакционных систем.

Нереляционные базы данных (NoSQL) — это гибкие модели: документы, ключ-значение, графы, колонки. Схема не фиксирована, данные могут быть разной структуры. Это основа масштабируемых и высоконагруженных систем.

Для системного аналитика выбор между реляционной и нереляционной базой — это не вопрос “что лучше”. Это вопрос “что подходит для вашей задачи”. Как выбрать между грузовиком и легковым автомобилем: оба ездят, но для разных целей.

Основные различия

Характеристика	Реляционные (SQL)	Нереляционные (NoSQL)
Модель данных	Таблицы, строки, колонки	Документы, ключ-значение, графы, колонки
Схема	Фиксированная (schema-on-write)	Гибкая (schema-on-read)
Язык запросов	SQL	Специфический (MQL, CQL, Cypher)
ACID	Полная поддержка	Частичная (BASE)
Масштабирование	Вертикальное (горизонтальное сложно)	Горизонтальное (из коробки)
Связи	Через внешние ключи (JOIN)	Вложенные документы или ссылки
Целостность	Строгая (ограничения, транзакции)	Мягкая (на уровне приложения)
Производительность	Хорошая (с индексами)	Очень хорошая для специализированных сценариев
Зрелость	Десятилетия (стабильно)	Современные (быстро развиваются)
Примеры	PostgreSQL, MySQL, Oracle	MongoDB, Cassandra, Redis, Neo4j

Реляционные БД (SQL): Порядок и строгость

Основные принципы

Таблицы и строки: Все данные организованы в таблицы. Каждая таблица имеет фиксированный набор колонок. Каждая строка — одна запись.

Нормализация: Данные разбиваются на связанные таблицы, чтобы избежать дублирования. Информация о клиенте хранится в таблице “клиенты”, а заказы — в таблице “заказы”. Связь через внешний ключ.

Схема на запись (schema-on-write): Прежде чем вставить данные, вы должны определить структуру таблицы. База данных проверяет, что вы вставляете данные правильного типа и структуры.

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

Когда реляционные БД незаменимы

Сценарий	Почему
Финансовые транзакции	Нужны ACID, строгая целостность, откат при ошибках
Системы бронирования	Нельзя продать одно место дважды
Сложные отчёты	SQL с JOIN, GROUP BY, оконными функциями
Данные с чёткой схемой	Структура известна и стабильна
Ссылочная целостность	Внешние ключи гарантируют, что заказ не может существовать без клиента

Пример: Банковская система

Таблица "Клиенты":
  - client_id (PRIMARY KEY)
  - name
  - passport

Таблица "Счета":
  - account_id (PRIMARY KEY)
  - client_id (FOREIGN KEY)
  - balance

Таблица "Транзакции":
  - transaction_id (PRIMARY KEY)
  - from_account_id (FOREIGN KEY)
  - to_account_id (FOREIGN KEY)
  - amount
  - timestamp

Почему реляционная:
  - Деньги не должны теряться (ACID)
  - Сложные запросы (отчёты, выписки)
  - Ссылочная целостность (нет транзакции без счёта)

Нереляционные БД (NoSQL): Гибкость и масштаб

Основные принципы

Схема на чтение (schema-on-read): Вы можете вставлять данные любой структуры. База данных не проверяет их заранее. При чтении вы сами знаете, какие поля ожидать.

Денормализация: Данные часто дублируются, чтобы ускорить чтение. Вместо JOIN данные хранятся вместе с родительским объектом.

BASE: Basically Available, Soft state, Eventual consistency. Вместо строгих гарантий ACID — доступность и масштабируемость.

Горизонтальное масштабирование: Данные распределяются между множеством серверов (шардирование). Добавление нового сервера увеличивает ёмкость.

Типы NoSQL

Тип	Модель	Примеры	Когда использовать
Документо-ориентированные	JSON-документы	MongoDB, Couchbase	Каталоги, CMS, логи
Ключ-значение	Пары ключ-значение	Redis, DynamoDB	Кеширование, сессии
Колоночные	Данные по колонкам	Cassandra, HBase	Аналитика, временные ряды
Графовые	Вершины и рёбра	Neo4j, ArangoDB	Социальные сети, рекомендации

Когда NoSQL — лучший выбор

Сценарий	Почему
Гибкая схема	Данные меняются со временем, структура непредсказуема
Высокая нагрузка на запись	Миллионы операций в секунду
Горизонтальное масштабирование	Тысячи серверов, петабайты данных
Событийная архитектура	Хранение событий, временные ряды
Простота и скорость	Кеширование, сессии, счётчики
Сложные связи (графы)	Социальные сети, рекомендации

Пример: Каталог товаров интернет-магазина

Документ в MongoDB:
  {
    "_id": "123",
    "name": "iPhone 15",
    "type": "phone",
    "specs": {
      "screen": "6.1 inch",
      "camera": "48MP",
      "storage": "256GB"
    },
    "price": 79999
  }

Другой документ (другой тип товара):
  {
    "_id": "456",
    "name": "Футболка",
    "type": "clothing",
    "specs": {
      "size": "L",
      "color": "red",
      "material": "cotton"
    },
    "price": 1999
  }

Почему NoSQL:
  - Разные товары имеют разные характеристики
  - Не нужны JOIN
  - Горизонтальное масштабирование

Ключевые различия в деталях

1. Схема

Реляционные: Схема фиксирована. Чтобы добавить новое поле, нужен ALTER TABLE. Это может занять время и заблокировать таблицу.

NoSQL: Схемы нет. Можно вставлять документы разной структуры в одну коллекцию. Новое поле появляется автоматически.

2. Связи

Реляционные: Через внешние ключи и JOIN. Сложные запросы с несколькими JOIN работают, но могут быть медленными на больших объёмах.

NoSQL: Вложенные документы или ссылки. JOIN отсутствуют или ограничены. Связи обычно проектируются заранее под запросы.

3. Транзакции

Реляционные: Полная ACID. Можно откатить транзакцию, если что-то пошло не так.

NoSQL: Часто только на уровне одного документа (или одной записи). Распределённые транзакции сложны или отсутствуют.

4. Масштабирование

Реляционные: Вертикальное (более мощный сервер). Горизонтальное (шардирование) возможно, но требует ручного управления и часто болезненно.

NoSQL: Горизонтальное из коробки. Добавляете новый сервер — данные автоматически перераспределяются.

5. Производительность чтения

Реляционные: Хорошая, если есть индексы. JOIN могут быть медленными на больших объёмах.

NoSQL: Очень хорошая для точечных запросов (по ключу). Аналитические запросы (агрегации) часто медленнее.

6. Производительность записи

Реляционные: Хорошая, но ограничена транзакциями и блокировками.

NoSQL: Очень хорошая, особенно для колоночных и key-value. Пакетная запись, асинхронность.

Когда что выбирать

Выбирайте реляционную БД, если

Признак	Пример
Строгая целостность данных критична	Деньги, билеты, бронирования
Сложные запросы с JOIN	Отчёты, аналитика
Схема данных стабильна	Классический учёт: клиенты, заказы, товары
Нужны транзакции	Перевод денег между счетами
Команда знает SQL	Низкий порог входа

Выбирайте нереляционную БД, если

Признак	Пример
Схема данных гибкая или меняется	Каталог товаров, пользовательские настройки
Высокая нагрузка на запись	Логи, метрики, IoT
Нужно горизонтальное масштабирование	Большие данные, миллиарды записей
Простые запросы по ключу	Кеш, сессии, счётчики
Сложные связи между данными (граф)	Социальные сети, рекомендации

Гибридный подход: Лучшее из двух миров

Современные системы часто используют оба типа баз данных.

Архитектура:
  - PostgreSQL: заказы, клиенты, транзакции (ACID, целостность)
  - MongoDB: каталог товаров (гибкая схема)
  - Redis: корзина покупок, сессии (скорость)
  - ClickHouse: аналитика продаж (высокая нагрузка)

Результат:
  - Каждая задача решается лучшим инструментом

Пример: Интернет-магазин

Компонент	База данных	Почему
Заказы и клиенты	PostgreSQL	ACID, целостность, сложные отчёты
Каталог товаров	MongoDB	Разные характеристики товаров
Корзина	Redis	Временные данные, высокая скорость
Аналитика	ClickHouse	Большие объёмы, агрегации

Распространённые ошибки

Ошибка 1: Реляционная БД для логов

Миллионы строк логов в PostgreSQL. Медленно, место кончается.

Решение: ClickHouse, Elasticsearch или MongoDB.

Ошибка 2: NoSQL для финансов

Попытка хранить деньги в MongoDB без транзакций.

Решение: PostgreSQL с ACID.

Ошибка 3: Нет схемы, где она нужна

Данные имеют чёткую структуру, но выбрали MongoDB. JOIN эмулируются в коде, всё медленно.

Решение: Реляционная БД.

Ошибка 4: Реляционная БД для миллиардов записей

PostgreSQL не справляется с петабайтами.

Решение: Cassandra, HBase или ClickHouse.

Ошибка 5: “NoSQL — это всегда быстро”

NoSQL быстр для своих сценариев (точечные запросы, запись). Для сложных агрегаций может быть медленнее SQL.

Решение: Выбирать под сценарий.

Резюме

Реляционные БД (SQL) — строгие таблицы, ACID, сложные запросы. Для финансов, бронирования, учёта.
Нереляционные БД (NoSQL) — гибкая схема, горизонтальное масштабирование, высокая производительность. Для каталогов, логов, кешей, графов.
Главные различия: схема (фиксированная vs гибкая), масштабирование (вертикальное vs горизонтальное), целостность (ACID vs BASE).
Нет “лучшего” — есть “подходящий”. Выбирайте инструмент под задачу.
Гибридные архитектуры — норма. Используйте разные базы для разных задач.

Основы проектирования БД Масштабирование БД