SQL или NoSQL: как выбрать
↑ 4.1 Redis и MongoDB · ← Предыдущая · → Следующая
Зачем это на собесе
Ответ «зависит» должен сопровождаться критериями. Проверяют умение аргументировать выбор хранилища.
Категории NoSQL
| Тип | Примеры | Модель | Сильная сторона |
|---|---|---|---|
| Ключ–значение | Redis, DynamoDB, Memcached | key → value | скорость, простота, кэш |
| Документная | MongoDB, Couchbase, Firestore | JSON-документы | гибкая схема, агрегаты «всё вместе» |
| Колоночная семейств | Cassandra, HBase, ScyllaDB | wide-column | запись огромных объёмов, распределённость |
| Колоночная аналитическая | ClickHouse, BigQuery | столбцы | аналитика |
| Граф | Neo4j, ArangoDB | вершины и рёбра | связи, рекомендации, пути |
| Поисковые | Elasticsearch, OpenSearch | инвертированный индекс | полнотекстовый поиск |
| Временные ряды | TimescaleDB, InfluxDB, VictoriaMetrics | time-series | метрики |
| Объектное | S3, MinIO | blob | файлы |
Сравнение
| SQL (реляционные) | NoSQL | |
|---|---|---|
| Схема | строгая, миграции | гибкая |
| Связи и JOIN | сильные | слабые/отсутствуют |
| Транзакции | полноценный ACID | ограниченные (зависит от БД) |
| Масштабирование | вертикальное, репликация; шардирование сложнее | горизонтальное встроено (часто) |
| Запросы | SQL, ad-hoc | под конкретный доступ к данным |
| Согласованность | сильная | часто eventual, настраиваемая (CAP) |
| Зрелость экосистемы | очень высокая | зависит |
Критерии выбора
- Модель данных и связи: много связей и инвариантов → реляционная.
- Шаблоны доступа: известны заранее и простые (по ключу) → key-value/документы; непредсказуемые отчёты → SQL.
- Консистентность: деньги, склады, бронирования → ACID.
- Объём и нагрузка: масштаб записи за пределы одного узла → шардируемые БД, но сначала исчерпайте оптимизацию PostgreSQL (партиционирование, реплики, кэш).
- Гибкость схемы: часто меняющиеся полуструктурированные данные → документы или
jsonb. - Команда и эксплуатация: опыт, инструменты, стоимость поддержки.
- Латентность: sub-ms → Redis.
Практический подход
- По умолчанию — PostgreSQL: реляционная модель +
jsonb, полнотекстовый поиск, расширения покрывают большинство задач; - добавляйте специализированные хранилища под конкретную проблему:
- кэш и очереди → Redis;
- аналитика → ClickHouse;
- поиск → Elasticsearch/OpenSearch;
- файлы → S3/MinIO;
- документная модель с гибкой схемой → MongoDB;
- polyglot persistence: разные хранилища под разные задачи с одним источником истины (обычно транзакционная БД) и синхронизацией (CDC, события).
Типичные сценарии
| Задача | Выбор |
|---|---|
| Интернет-магазин: заказы, платежи | PostgreSQL |
| Сессии, кэш, счётчики, лимиты | Redis |
| Каталог с переменными атрибутами | PostgreSQL jsonb или MongoDB |
| События и аналитика | ClickHouse |
| Полнотекстовый поиск с фасетами | Elasticsearch/OpenSearch |
| Рекомендации по связям | граф-БД или SQL с рекурсивными CTE |
| Загрузка файлов | S3-совместимое хранилище + метаданные в БД |
| Логи и метрики | ClickHouse / Loki / Prometheus |
Ловушки
- выбор NoSQL «потому что модно» или «для масштаба» без нужды;
- перенос реляционных данных в документы с потерей целостности;
- «синхронизация вручную» нескольких хранилищ без источника истины;
- игнорирование стоимости эксплуатации новой технологии.
Вопросы с ответами
Как выбрать между SQL и NoSQL?
По модели данных и связям, шаблонам доступа, требованиям к консистентности и масштабу. Если сомневаетесь — PostgreSQL, а специализированные хранилища добавляйте под конкретные задачи.
Что такое polyglot persistence?
Использование разных типов хранилищ под разные задачи внутри одной системы, обычно с одним источником истины и синхронизацией остальных через события или CDC.