Как спроектировать таблицу в ClickHouse
Вопрос
Вам нужно хранить в ClickHouse события продукта (300 млн в день) для дашбордов по проектам и времени. Как спроектируете таблицу и загрузку?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Движок MergeTree (Replicated в кластере), ORDER BY по частым фильтрам: проект, затем время
PARTITION BY по месяцу или дню для управления данными, не мельче
Типы: LowCardinality для строк с малым числом значений, точные типы дат и чисел
Загрузка пачками или из Kafka через Kafka engine и MV, async_insert
Предагрегаты в AggregatingMergeTree через материализованные представления
TTL для старых данных, дедупликация при необходимости
Что могут спросить следом
- Что делать с повторной доставкой событий?
- Как добавить колонку в ORDER BY позже?
Разбор
Образцовый ответ: «Беру ReplicatedMergeTree, если кластер, иначе MergeTree. Сортировочный ключ под основные запросы: сначала project_id, затем дата и время события, возможно тип события. Партиционирую по месяцу: при 300 миллионах в день можно и по дню, но не мельче, это для удаления и перезаливки. Типы аккуратные: LowCardinality(String) для типа события и страны, DateTime64 при необходимости, без Nullable там, где можно обойтись. Загрузку делаю из Kafka через движок Kafka и материализованное представление, либо приложением пачками, но не по строке. Для дашбордов строю предагрегаты по часу через MV в AggregatingMergeTree с uniqState и sumState, а дашборды читают их с -Merge. Старые сырые события удаляю TTL через N месяцев. Повторы событий гасил бы ReplacingMergeTree по ключу с event_id или дедупликацией вставок».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.