⚙️ Теория
🧩 SQL (реляционная модель)
Сильные стороны SQL-систем (например PostgreSQL):
- строгая схема и ACID-транзакции;
- мощные join/aggregation запросы;
- зрелые механизмы консистентности и индексации.
🧱 NoSQL (документные и другие модели)
Сильные стороны NoSQL (например MongoDB):
- гибкая схема и быстрые изменения модели;
- горизонтальное масштабирование на больших объемах;
- удобство для полуструктурированных данных.
⚖️ Как выбирать
Ключевые вопросы:
- нужна ли строгая транзакционная целостность между сущностями;
- как часто меняется схема;
- критичны ли сложные аналитические запросы;
- какие SLO по latency и доступности.
⚠️ Анти-паттерны
- выбирать "по тренду", а не по workload;
- переносить OLTP-модель 1:1 в документную БД без пересмотра запросов;
- игнорировать операционную стоимость (backup, observability, failover).
❓ Что нужно уметь объяснить
Почему "NoSQL быстрее" не универсально?
Скорость зависит от паттерна запросов, индексов, размера рабочих наборов и модели консистентности.
Почему SQL часто остается лучшим выбором для core-транзакций?
Из-за предсказуемой консистентности и зрелых транзакционных гарантий.
Когда гибкая схема действительно полезна?
Когда доменная модель быстро эволюционирует и нагрузка лучше описывается денормализованными документами.
🧪 Практика
1. Decision checklist
- транзакции: обязательны или локальны;
- чтение/запись: профиль и пиковые нагрузки;
- эволюция схемы: частота и стоимость миграций;
- требования к репликации/геораспределению.
2. Proof-of-concept критерии
- p95/p99 latency на реальных запросах;
- поведение при failover;
- стоимость эксплуатации day-2.
🧾 Вывод
Выбор SQL vs NoSQL должен исходить из модели данных и SLO, а не из предпочтений команды. Часто оптимальна гибридная архитектура, где каждая БД обслуживает подходящий ей workload.