Какие виды хранилищ данных кроме реляционных существуют и с какими вы работали

Что проверяют

Знаете ли вы, что бывает за пределами PostgreSQL, и выбирали ли хранилище осознанно. Интервьюер смотрит не на список названий, а на пары «задача, свойство хранилища». Следом почти всегда идёт уточнение: «а почему не Postgres с JSONB?», потому что за половиной внедрений MongoDB стояла мода, а не требования.

Как отвечать

Разложите по типам и для каждого назовите, что делали руками:

• ключ-значение: Redis и Valkey, кэш, счётчики, распределённые блокировки, TTL из коробки, в Go обычно через go-redis;
• документные: MongoDB, гибкая схема, вложенные документы вместо джойнов, транзакции есть, но с оговорками по стоимости;
• широкие колонки: Cassandra и ScyllaDB, LSM-дерево, запись дешевле чтения, таблица проектируется под конкретный запрос, согласованность настраивается кворумами;
• колоночные аналитические: ClickHouse, сжатие и сканирование по колонкам, миллиарды строк в агрегатах, но точечный UPDATE это боль;
• поисковые: Elasticsearch и OpenSearch, полнотекст, фасеты, обратный индекс;
• временные ряды: VictoriaMetrics, TimescaleDB, метрики с retention и прореживанием;
• графовые: Neo4j, обход связей на несколько уровней без каскада джойнов;
• встраиваемые: bbolt, badger, pebble, SQLite, локальное состояние без отдельного сервера;
• объектное: S3 и MinIO, файлы, выгрузки и бэкапы, а не строки.

Сильный ход: рассказать, где вы обошлись без нового хранилища. JSONB, GIN-индексы, pg_trgm, pgvector и партиционирование закрывают многое, а лишний сервис это ещё одна репликация, бэкап и дежурство.

Где спотыкаются

Называют Cassandra «колоночной базой для аналитики». Это wide-column store под запись, а колоночная OLAP это ClickHouse, задачи у них разные.

Говорят «NoSQL быстрее». Быстрее в конкретном сценарии доступа, за счёт денормализации и более слабых гарантий, а не вообще.

Не могут описать модель согласованности того, что внедрили: сколько реплик подтверждает запись и что увидит читатель сразу после неё.