SQL или NoSQL: когда что выбирать
Это не «что лучше», а «что подходит под вашу нагрузку и модель данных».
SQL-базы хранят данные в таблицах со строгой схемой и связями, дают транзакции и JOIN. NoSQL — общее имя для нереляционных хранилищ, делающих ставку на гибкость схемы и горизонтальный масштаб.
Сильные стороны SQL
Реляционные базы (PostgreSQL, MySQL) десятилетиями оттачивались под целостность данных. Их козыри: ACID-транзакции (либо всё применилось, либо ничего), строгая схема (база не пустит мусор), мощные JOIN и сложные запросы. Это идеально для денег, заказов, связанных сущностей — там, где ошибка недопустима.
Сильные стороны NoSQL
NoSQL появился, когда данных стало столько, что одна SQL-машина не справлялась. Главные козыри: горизонтальный масштаб «из коробки», гибкая схема (можно дописать поле без миграции) и высокая скорость на простых операциях по ключу. Цена — обычно нет JOIN и часто нет строгих транзакций между записями.
Типы NoSQL
| Тип | Модель | Хорош для | Пример |
| Ключ-значение | словарь key → value | кэш, сессии, счётчики | Redis, DynamoDB |
| Документный | JSON-документы | гибкие сущности, профили, каталоги | MongoDB |
| Колоночный | колонки/семейства колонок | огромные объёмы записей, временные ряды | Cassandra, HBase |
| Графовый | узлы и рёбра | связи: соцсети, рекомендации | Neo4j |
Таблица выбора
| Критерий | Скорее SQL | Скорее NoSQL |
| Транзакции, деньги | да, нужны ACID | обычно избыточно |
| Связи и сложные запросы (JOIN) | сильная сторона | неудобно |
| Схема | стабильная, известная | меняется часто, разнородная |
| Объём и масштаб записи | до определённого предела | огромный, горизонтальный |
| Доступ | сложные выборки | в основном по ключу |
Полиглот-персистентность
В реальных системах редко выбирают «или-или». Заказы — в PostgreSQL (нужны транзакции), сессии — в Redis (скорость по ключу), лента активности — в Cassandra (объём записей), полнотекстовый поиск — в Elasticsearch. Это называется polyglot persistence: под каждую нагрузку — своё хранилище. На собеседовании это сильный ответ: «для платежей возьму SQL ради ACID, а для ленты — NoSQL ради масштаба».
Пример рассуждения
Задача: каталог товаров + корзина + заказы.
- Заказы и оплата → PostgreSQL (ACID, нельзя терять/задваивать).
- Корзина и сессии → Redis (быстро, временно, по ключу).
- Карточки товаров → MongoDB (поля у товаров разные).
- Поиск по каталогу → Elasticsearch.
Один тип на всё — почти всегда компромисс не в нашу пользу.Итог
- SQL — целостность, транзакции, связи; NoSQL — масштаб, гибкость схемы, скорость по ключу.
- У NoSQL четыре основных типа: ключ-значение, документный, колоночный, графовый.
- Зрелое решение — polyglot persistence: под каждую нагрузку своё хранилище.
