Когда SQL vs NoSQL
Выбор между SQL и NoSQL — это выбор под конкретные требования проекта, а не “что моднее”.
| Критерий | SQL (реляционная) | NoSQL |
|---|---|---|
| Структура данных | стабильная, заранее известная | часто меняется, гибкая |
| Связи между сущностями | много сложных связей | данные в основном самодостаточны |
| Согласованность | критична (деньги, заказы) | можно пожертвовать ради скорости |
| Масштабирование | вертикальное (мощнее сервер) | часто легче горизонтальное (больше серверов) |
| Запросы | сложные, с JOIN, агрегацией | простые, по ключу или плоской структуре |
Копнуть глубже
Типичные сценарии выбора:
- Банковская система, заказы интернет-магазина → SQL. Критична строгая согласованность (ACID), деньги не терпят “почти правильных” данных.
- Кэш сессий, счётчики, быстрый доступ по id → Redis (key-value).
- Профили пользователей с разной структурой данных, каталог товаров с разными атрибутами → MongoDB (документная).
- Логи, метрики, аналитика по огромным объёмам → колоночная (Cassandra) — см. тему «Типы NoSQL-хранилищ».
CAP-теорема — теоретическая основа выбора (подробный разбор — в теме «CAP-теорема»): распределённая система не может одновременно гарантировать согласованность (Consistency), доступность (Availability) и устойчивость к разделению сети (Partition tolerance) — приходится жертвовать чем-то одним. SQL-базы традиционно выбирают в сторону согласованности, многие NoSQL-базы — в сторону доступности.
На практике большинство реальных систем используют и то, и другое одновременно — основные транзакционные данные в PostgreSQL, кэш в Redis, возможно аналитику в отдельной колоночной базе. Это называется polyglot persistence — выбор правильного инструмента под каждую конкретную задачу, а не одна база на всё приложение.
• идею CAP-теоремы и что такое polyglot persistence (если дошёл до 2-го слоя).