SQL vs NoSQL: критерии выбора

Не битва

SQL и NoSQL — не конкуренты. Это инструменты для разных задач.

Правило: выбор — под данные и паттерны доступа, а не «по моде».

Критерий 1. Структура данных

Реляционная:

• Сущности + связи.
• Нормализация.
• JOIN естественен.
• SQL.

Документная:

• Иерархия, вложенность.
• Aggregate = один документ.
• MongoDB.

Key-Value:

• Простые пары.
• Кэш, сессии.
• Redis, Memcached.

Граф:

• Узлы + связи.
• Обходы.
• Neo4j.

Time-series:

• Метрики, события.
• InfluxDB, TimescaleDB.

Правило: если данные — сущности + связи, SQL. Если документы — Mongo. Если граф — Neo4j.

Критерий 2. Схема

Фиксированная (SQL):

• Плюс: гарантия структуры.
• Плюс: типы проверены.
• Минус: миграции при изменениях.

Гибкая (NoSQL):

• Плюс: быстрая разработка.
• Плюс: разные поля.
• Минус: рассинхрон данных.

Правило:

• Схема стабильна → SQL.
• Часто меняется → MongoDB.
• Гибрид → Postgres + JSONB.

Критерий 3. Транзакции

ACID критичен:

• Финансы.
• Заказы.
• Платежи.
• SQL или MongoDB 4.0+.

Eventually consistent:

• Метрики.
• Соцсети.
• Логи.
• Cassandra, DynamoDB.

Правило: если данные не могут быть «неправильные» — SQL.

Критерий 4. Связи

Простая 1:N:

• Любая БД.
• Postgres, Mongo — ок.

N:N, сложные связи:

• SQL через junction.
• Graph через edges.

Много JOIN в одном запросе:

• SQL.
• MongoDB $lookup — медленнее.

Правило: сложные связи → SQL. Граф → Neo4j.

Критерий 5. Объёмы

Мало данных (< 100 GB):

• Любая.
• Postgres по умолчанию.

Средние (100 GB – 1 TB):

• Postgres + партиции.
• Mongo.

Большие (1-10 TB):

• Cassandra, ScyllaDB.
• ClickHouse для аналитики.

Огромные (> 10 TB):

• Distributed only.

Правило: до 100 GB — не думать о NoSQL.

Критерий 6. Нагрузка

Read-heavy:

• Реплики + кэш.
• Любая БД.

Write-heavy:

• Cassandra, ScyllaDB.
• InnoDB или Postgres — тоже ок до предела.

Смешанная:

• Postgres, MySQL.

Правило: write-heavy → сначала проверить настройку, потом менять БД.

Критерий 7. Запросы

Точечные по ключу:

• KV (Redis), InnoDB.

Диапазонные:

• SQL (B-tree), Cassandra.

Агрегаты:

• SQL, ClickHouse.

Полнотекст:

• Elasticsearch, Meilisearch.

Семантический:

• Vector DB.

Правило: под паттерн доступа — своя БД.

Критерий 8. Команда

Знают SQL:

• Postgres, MySQL, Mongo.

Знают документы:

• MongoDB.

Знают Go/Java:

• Cassandra.

Правило: не выбирать технологию, которую команда не знает.

Матрица решений

Что важнее

Не «SQL или NoSQL», а:

• Одна БД для 90%.
• Вторая — если конкретно нужно.
• Третья — только с обоснованием.

Правило:

• Начни с PostgreSQL.
• Redis для кэша/сессий.
• Остальное — по факту боли.

Anti-patterns

1. MongoDB для всего:

Финансы без ACID

Решение: Postgres для транзакций.

2. Postgres для всего:

Полнотекст на миллиардах строк

Решение: Elasticsearch.

3. «SQL не масштабируется»:

Postgres+Citus, партиции, реплики

Решение: изучить.

4. «NoSQL быстрее»:

На сложных запросах медленнее

Решение: свой workload.

5. Миграция ради моды:

Все на MongoDB

Решение: только по боли.

6. Игнорирование команды:

Cassandra, а разработчики знают SQL

Решение: обучать или выбирать другое.

7. Много БД сразу:

Postgres + Mongo + Cassandra + Neo4j

Решение: минимум.

8. Managed vs self-hosted без плана:

Своя Cassandra без DevOps

Решение: managed.

Правила выбора

5 правил:

1. PostgreSQL по умолчанию.
2. Redis для кэша и сессий.
3. Добавляй БД только если есть конкретная боль.
4. Managed > self-hosted на старте.
5. Тестируй на своих данных.

Как принимать решение

Чек-лист:

• Какой тип данных? (реляционные / документы / граф / KV / время)
• Какие запросы? (точечные / диапазонные / агрегаты / полнотекст / вектор)
• Какие объёмы? (< 100 GB / 1 TB / 10 TB+)
• Какая нагрузка? (read / write)
• Нужен ли ACID?
• Какие гарантии по доступности?
• Что знает команда?
• Managed или self-hosted?
• Как тестировать?

Правило: если на 3+ вопросов нет ответа — не менять БД.

Примеры решений

Стартап (MVP):

• Postgres.
• Redis.
• Больше ничего.

Растущий SaaS:

• Postgres + реплики.
• Redis (кэш, очереди).
• Meilisearch (поиск).
• pgvector (AI).

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

• Postgres (заказы).
• MongoDB (каталог).
• Elasticsearch (поиск).
• Redis (кэш, сессии).
• ClickHouse (аналитика).

Соцсеть:

• Postgres (пользователи, посты).
• Neo4j (граф друзей).
• Redis (лента-кэш).
• Cassandra (если лента огромная).

High-frequency trading:

• Специализированные (kdb+, ClickHouse).
• Не Postgres.

Логи:

• Elasticsearch или Loki.
• Не Postgres.

Практика

1. Определите тип данных в своём проекте.

2. Определите паттерны доступа.

3. Определите объёмы и нагрузку.

4. Выберите по матрице.

5. Обоснуйте выбор.

6. Не добавляйте БД «на всякий случай».

Частые ошибки

1. «Модно»:

MongoDB, потому что стартап

Решение: под данные.

2. «Быстро»:

Redis для заказов

Решение: Redis не персистентный.

3. «Просто»:

Всё в одном Redis

Решение: источник правды — Postgres.

4. «Масштабируется»:

Cassandra на 10 GB

Решение: Postgres до 100 GB.

5. Игнорирование команды:

Технология, которую никто не знает

Решение: обучение или другое.

6. Нет плана синхронизации:

Postgres + Mongo без CDC

Решение: CDC / очереди.

7. Одна БД для всего:

Postgres + JSONB + full-text + vector + очереди

Решение: иногда это правильно — до предела.

8. Нет метрик:

Не знаем, где узкое место

Решение: мониторинг до выбора БД.

Практика: анализируйте свой проект

Шаг 1. Выпишите все сущности и их связи.

Шаг 2. Для каждой определите:

• Размер.
• Нагрузку (read/write).
• Гарантии (ACID?).
• Запросы.

Шаг 3. Сгруппируйте по паттернам:

• Транзакционные → Postgres.
• Документные → Mongo / Postgres JSONB.
• Кэш → Redis.
• Поиск → Elasticsearch.
• Аналитика → ClickHouse.

Шаг 4. Начните с Postgres. Добавляйте только по факту.

Шаг 5. Замеряйте. Ошибайтесь, но осознанно.

Итог

• Не битва, а инструменты.
• Data → pattern → engine.
• 5 правил: Postgres, Redis, по боли, managed, тест.
• Матрица решений — помощь.
• Не выбирать «по моде».
• Учитывать команду.
• Начинать с одной БД.
• Добавлять осознанно.

Дальше — MongoDB vs PostgreSQL: на примерах.