Выбор БД: SQL против NoSQL

Как обоснованно ответить на коварный вопрос «какую БД возьмёте» — без cargo-cult.

SQL (реляционная БД) — строгая схема, JOIN и ACID-транзакции. NoSQL — зонтик для key-value, документных, колоночных и графовых хранилищ с гибкой схемой и упором на горизонтальный масштаб.

Когда что выбирать

Решение зависит от характера данных и доступа, а не от моды. Главный вопрос: нужны ли вам сложные связи и транзакции (SQL) или важнее простой доступ по ключу и линейное масштабирование (NoSQL)?

Виды NoSQL

• Key-value (Redis, DynamoDB) — быстрый доступ по ключу, сессии, кэш.
• Документные (MongoDB) — вложенные JSON-документы, гибкая схема.
• Колоночные (Cassandra) — огромные объёмы записей, временные ряды, лента.
• Графовые (Neo4j) — связи «друзья друзей», рекомендации.

Как работает под капотом

Реляционные БД масштабируются вертикально и через реплики для чтения, но запись традиционно упирается в один мастер. NoSQL вроде Cassandra изначально распределена: данные шардируются по ключу между узлами, поэтому запись масштабируется горизонтально, но за это платят отказом от JOIN и сильной согласованности. Поэтому вопрос «SQL или NoSQL» — это, по сути, «нужны мне связи и транзакции или линейный масштаб записи».

Сильный ответ на собеседовании

Не говорите «возьмём MongoDB, потому что она быстрая». Скажите: «Данные пользователей и заказов связаны, нужны транзакции -> PostgreSQL. А ленту событий с огромным потоком записей вынесу в Cassandra, JOIN там не нужен». Гибридный, обоснованный выбор — сильный сигнал.

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

• Выбирать БД «по привычке» без привязки к паттерну доступа.
• Считать, что NoSQL всегда быстрее и масштабируемее.
• Брать NoSQL туда, где нужны транзакции (платежи, баланс).

Итог

• SQL — связи, транзакции, сильная согласованность; NoSQL — масштаб записи и гибкость.
• NoSQL — это семейство: key-value, документные, колоночные, графовые.
• Сильный ответ почти всегда гибридный и привязан к паттерну доступа.