В каких случаях переход на NoSQL, скорее всего, не оправдан?
- Когда не стоит переходить на NoSQL?
Не оправдан при связанных данных, нужде в транзакциях между сущностями, произвольных запросах и отчётах, и когда масштаб одной реляционной базы ещё не исчерпан.
- Реляционная база держит очень большие нагрузки при нормальных индексах и репликах
- Переход переносит целостность и JOIN в код приложения
- «Гибкая схема» — не аргумент: схема всё равно есть, только неявная
А ещё Сначала оптимизация, кэш, реплики, партиционирование
Подробно
Главная плата за отказ от реляционной модели — перенос работы в приложение: соединения делаются кодом, целостность поддерживается вручную, а схема фиксируется под конкретные запросы, из-за чего новый сценарий требует новой таблицы или новой проекции. Это оправдано, когда паттерны доступа известны и стабильны, а объём или нагрузка на запись выходят за пределы одной машины. В остальных случаях современный PostgreSQL с репликами, партиционированием и JSONB закрывает задачу, оставляя транзакции и произвольные запросы. Разумная стратегия — не выбирать одно на всё, а держать реляционную базу источником истины и добавлять специализированные хранилища под конкретные сценарии.
Что хотят услышать
- Признаки, что NoSQL не нужен.
- Цена перехода.
- Что попробовать раньше.
Частые ошибки
- Выбирать NoSQL из-за «гибкости схемы» — она означает, что схему теперь поддерживает приложение.
- Оценивать масштаб по ожиданиям, а не по измеренной нагрузке.
Проверьте себя
Несколько верных вариантов. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Данные сильно связаны, и запросы требуют произвольных соединений между сущностями
- ✓Нужны транзакции с несколькими сущностями и строгие ограничения целостности
- ✓Объём данных умеренный, а нагрузка укладывается в одну реляционную СУБД с репликами
- ✗Требуется линейное горизонтальное масштабирование записи при простом доступе по ключу
Что спросят дальше
- Что означает моделирование от access patterns?
- Как выглядит связка реляционного источника истины со специализированными хранилищами?
Разбор темы
- NoSQL: семейства и когда их выбирать
Почему появился NoSQL, моделирование от access patterns, четыре семейства хранилищ, BASE против ACID и горизонтальное масштабирование.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.