Что такое key-value базы данных
Что проверяют
Понимаете ли вы, когда хранилище по ключу уместнее реляционной базы, и умеете ли выбирать хранилище под профиль нагрузки. Для инженера данных вопрос не про определение, а про место key-value в конвейере: онлайн-выдача признаков, состояние стриминга, кэш ответов модели.
Как отвечать
Key-value хранилище держит пары «ключ, значение» и умеет три операции: положить, прочитать по ключу, удалить. Значение для базы непрозрачно, это просто байты, поэтому фильтровать и агрегировать по его содержимому она не умеет.
Отсюда следует всё остальное. Данные шардируются по хэшу ключа, запрос попадает в один узел, задержка предсказуема и почти не растёт с объёмом. Плата за это: нет соединений, нет произвольных выборок по значению, обычно нет транзакций между разными ключами.
Дальше покажите, что реализации разные. Redis ближе к серверу структур данных в памяти: списки, множества, счётчики, время жизни ключа. RocksDB и LMDB встраиваются прямо в процесс. Управляемые базы вроде DynamoDB дают составной ключ из раздела и сортировки плюс вторичные индексы, то есть шаг в сторону от чистой модели.
Для data-ml назовите применение своими словами: онлайн-хранилище признаков, куда пакетный расчёт раскладывает вектор по идентификатору пользователя, а сервис инференса забирает его по ключу за единицы миллисекунд; состояние оконных агрегатов в стриминге; кэш эмбеддингов.
Где спотыкаются
Отвечают «NoSQL быстрее» и на этом останавливаются. Скорость здесь следствие отказа от вторичных индексов, соединений и общей схемы, а не свойство самой технологии.
Не думают про распределение ключей. Равномерный хэш не спасает от одного популярного ключа: узел с ним упрётся в потолок раньше остальных, и лечится это разбиением ключа на части или кэшем перед базой.
Считают такое хранилище исключительно кэшем и не могут ответить, что произойдёт при перезапуске. Стоит знать про режимы персистентности, политику вытеснения и то, что единственная копия данных в памяти без снимков и реплики теряется вместе с процессом.