Какую базу данных выбрать для денормализации данных просмотров видео для быстрой выборки
Что проверяют
Умеете ли вы идти от запросов к хранилищу, а не наоборот. Просмотры это поток событий с частыми агрегациями и почти без изменений, и интервьюер ждёт, что вы это заметите. Следом обычно спрашивают, как данные туда попадают и что будет с популярным видео под нагрузкой.
Как отвечать
Сначала назовите запросы: просмотры видео за период, разрезы по странам и устройствам, топ за день, история пользователя. От них и выбор:
- ClickHouse для аналитики: колоночное хранение, одна широкая таблица событий, куда сразу положены атрибуты видео и зрителя, так что JOIN не нужен.
MergeTreeс сортировкой по(video_id, event_date), предагрегация через materialized view вSummingMergeTreeилиAggregatingMergeTree. Из Python черезclickhouse-connect; - Redis для счётчика на странице:
INCRна просмотр,PFADDиPFCOUNT(HyperLogLog) для приблизительного числа уникальных зрителей, периодический сброс в основное хранилище; - Cassandra или ScyllaDB для истории пользователя: таблица под запрос, ключ партиции
user_id, кластеризация по времени; - PostgreSQL: честный вариант на старте, с секционированием по дате и материализованными представлениями.
Путь записи: события идут в Kafka, оттуда пачками в ClickHouse. По одной строке вставлять нельзя, нужны батчи или async_insert.
Назовите и цену денормализации: название видео или категория могут измениться. Либо старые события хранят старое значение, либо изменяемые атрибуты подтягиваются при чтении через словари ClickHouse.
Где спотыкаются
Отвечают «MongoDB, потому что NoSQL быстрый», не назвав ни одного запроса. Выбор без паттерна чтения интервьюер не засчитывает.
Считают просмотры через UPDATE videos SET views = views + 1. На популярном видео все запросы встают в очередь на блокировку одной строки.
Пишут в ClickHouse каждый просмотр отдельным INSERT. Каждая вставка создаёт новый кусок данных, слияния не успевают, и сервер начинает отклонять запись с ошибкой о слишком большом числе кусков.