Когда NoSQL база может быть лучше реляционной?
- Когда выбрать MongoDB вместо PostgreSQL?
- Какие бывают NoSQL-базы?
NoSQL выбирают под конкретный паттерн доступа: документы, читаемые целиком; доступ по ключу с огромной нагрузкой; запись временных рядов; горизонтальное масштабирование записи. Цена — меньше JOIN и транзакций, схему проектируют под запросы.
- Виды: документные (MongoDB), ключ-значение (Redis, DynamoDB), колоночные (Cassandra), графовые (Neo4j), поисковые (Elasticsearch)
- Реляционная база — хороший выбор по умолчанию: транзакции, связи, произвольные запросы
- PostgreSQL с JSONB закрывает многие «документные» сценарии
А ещё Часто не «или», а «и»: основная база плюс специализированные хранилища
Подробно
Сильные стороны реляционной базы: ACID-транзакции на много строк и таблиц, ограничения целостности, JOIN и произвольные запросы, которые оптимизатор выполнит без заранее заложенной модели доступа. Отличный выбор по умолчанию.
Когда NoSQL выигрывает:
- документная (MongoDB) — данные естественно иерархичны и читаются целиком (профиль с настройками, карточка товара с вариантами), схема часто меняется;
- ключ-значение (Redis, DynamoDB) — доступ строго по ключу с предсказуемой задержкой на огромной нагрузке: сессии, корзины, кэш;
- wide-column (Cassandra, ScyllaDB) — огромный поток записи, данные по ключу партиции с сортировкой: сообщения, события, временные ряды;
- графовая — запросы по связям произвольной глубины (рекомендации, социальный граф);
- поисковая — полнотекстовый поиск и фасеты.
Цена: обычно нет произвольных JOIN, транзакции — в пределах документа или партиции, согласованность часто итоговая, модель данных проектируют под запросы и дублируют данные под разные запросы. Ответственность за целостность переходит к приложению.
На практике — основная реляционная база и специализированные хранилища рядом (поиск, кэш, аналитика), заполняемые через CDC или события.
Что хотят услышать
- Виды NoSQL и их сценарии.
- Сильные стороны реляционных баз.
- Цена NoSQL: JOIN, транзакции, моделирование под запросы.
- Комбинация хранилищ — плюс.
Частые ошибки
- «NoSQL быстрее и масштабируется, значит лучше».
- Выбирать MongoDB только из-за «гибкой схемы».
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Всегда, когда данных больше миллиона строк
- ✗Когда нужны сложные произвольные запросы с JOIN и транзакциями между многими сущностями
- ✗Когда нужна строгая схема данных
- ✓Под конкретный паттерн доступа: документ целиком, ключ под огромной нагрузкой, масштаб записи
Что спросят дальше
- Что такое eventual consistency?
- Когда MongoDB документ лучше нормализованных таблиц?
Разбор темы
- NoSQL: семейства и когда их выбирать
Почему появился NoSQL, моделирование от access patterns, четыре семейства хранилищ, BASE против ACID и горизонтальное масштабирование.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.