Работал ли ты с Cassandra, MongoDB, Redis, ElasticSearch, ClickHouse

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

Тот же вопрос-инвентарь, но от джависта ждут разговора через призму Spring Data и драйверов: понимаете ли вы, что общий репозиторный интерфейс не делает хранилища взаимозаменяемыми, и выбираете ли базу под нагрузку, а не по привычке.

Как отвечать

Сначала честно разложите список на «было в проде», «трогал», «знаю теорию». По каждому пункту первой группы скажите, что именно решали:

• Cassandra: драйвер DataStax или Spring Data Cassandra, модель под запрос, подготовленные запросы, уровень согласованности на операцию;
• MongoDB: шаблон доступа или репозитории Spring Data, гибкая схема не отменяет продуманных индексов;
• Redis: клиент Lettuce под абстракцией Spring Data Redis, кэш через аннотации кэширования, сессии, ограничители частоты запросов;
• Elasticsearch: явное описание полей вместо динамического, переиндексация при смене схемы, поиск и агрегации;
• ClickHouse: драйвер JDBC, аналитические витрины, пакетная вставка.

Сильный ответ заканчивается критерием выбора: профиль нагрузки, объём, требования к согласованности, кто это потом эксплуатирует. Если из пяти реально было две, скажите об этом прямо и добавьте, что остальное разбирали по документации.

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

Переносят реляционное мышление в Cassandra: строят таблицу как в PostgreSQL, а потом добавляют ALLOW FILTERING, чтобы заработал фильтр по неключевой колонке. В бою это скан по всему кластеру, и такой ответ сразу показывает отсутствие опыта.

Кладут в Redis объекты стандартной сериализацией Java. Кэш ломается при первом же изменении класса, читатель получает ошибку разбора. Хранить нужно нейтральный формат, обычно JSON.

Вешают аннотацию кэширования и считают тему закрытой, не отвечая, откуда берётся срок жизни записи и кто её сбрасывает. Дальше живут с устаревшими данными и не понимают, почему правка в базе не видна приложению.