Для чего используются NoSQL решения?
Что проверяют
Умеете ли вы выбирать хранилище под задачу и не считаете ли NoSQL просто «модной альтернативой SQL».
Как отвечать
Начните с того, что NoSQL это не одна технология, а несколько семейств под разные задачи:
- ключ-значение (Redis, etcd): кеш, сессии, счётчики, распределённые блокировки. Простейшая модель, максимальная скорость;
- документные (MongoDB): объект читается и пишется целиком, схема гибкая. Каталоги, профили, события;
- колоночные (Cassandra, ClickHouse): огромные объёмы записи и аналитические выборки по колонкам, линейное масштабирование;
- графовые (Neo4j): связи это главная сущность, обход в глубину по знакомствам или зависимостям;
- поисковые (Elasticsearch): полнотекстовый поиск, агрегации, ранжирование;
- временные ряды (Prometheus, InfluxDB): метрики и телеметрия.
Дальше назовите, ради чего их берут: горизонтальное масштабирование из коробки, высокая скорость записи, гибкая схема там, где структура данных меняется часто, специализированные операции, которых нет в реляционной модели.
И цена, без которой ответ неполон: слабые гарантии согласованности (обычно согласованность в конечном счёте), отсутствие соединений и внешних ключей, дублирование данных как норма, схема запросов определяется заранее, потому что произвольный отчёт написать негде.
Практический вывод: NoSQL берут как дополнение к основной базе под конкретный сценарий, а не как замену. Реляционная база с jsonb, полнотекстовым поиском и партиционированием закрывает многое из того, ради чего раньше сразу шли в NoSQL.
Где спотыкаются
Говорят «NoSQL быстрее». Быстрее в своём сценарии, а в чужом заметно медленнее.
Считают отсутствие схемы преимуществом без оговорок: схема просто переезжает в код приложения, где её никто не проверяет.
Не могут назвать ни одного случая, когда NoSQL брать не стоит.