рекламные события постоянно пишутся - (много и часто). группировка времени - час. думаю что-то в духе
summingmergetree(
dt datetime
client_id UInt32
остальные поля
)
ENGINE = SummingMergeTree
PARTITION BY toYYYYMMDD(dt)
PRIMARY KEY (dt, client_id)
ORDER BY (client_id,....dt)
Вроде как видел тут рекомендации утащить dt вконец списка order by если партиции по дате. Это так или я напутал?
Примари кей мне не особо нужен, но читал в доке что без него он будет равным ORDER BY - а там с десяток полей - они в примари точно не нужны. Не устарели данные?
Стоит ли добавить client_id в PARTITION BY toYYYYMMDD(dt? client_id).
Клиентов ну штук 1000 наверно. Или партиции лопнут от такого количества?
Стоит ли партировать по дню - в день 10-20 ярдов строк - или сразу по месяцу
Вот ))
>Стоит ли добавить client_id в PARTITION BY toYYYYMMDD(dt? client_id). >Клиентов ну штук 1000 наверно. Или партиции лопнут от такого количества? лопнут >PRIMARY KEY (dt, client_id) >ORDER BY (client_id,....dt) так нельзя PRIMARY KEY это префикс, вам точно dt в индексе надо? вы будете фильтровать кверяя меньше суток? логично в индес все таки полезные поля положить, типа id баннера или криэтива или tag >Стоит ли партировать по дню - в день 10-20 ярдов строк - или сразу по месяцу неправильные критерии. Сколько лет вы собираетесь данные в этой таблице хранить? Надо кол-во партиций сделать небольшим. Плюс если вы данные будете кверять по диапазону месяц или год, то дневные партиции убьют перформанс, потому что надо будет ходить по индексам в куче партиций
"Хранить вечно" ну неск лет точно
дата нужна в order by, чтоб схлопывать данные,
значит partition by toYYYYMM(dt) PRIMARY KEY ( channel_id, что-то_блин_полезное, toStartOfHour(dt)) ORDER BY ( channel_id, что-то_блин_полезное, toStartOfHour(dt), мусор, dt) хотя если у вас dt уже округлен до часа то partition by toYYYYMM(dt) PRIMARY KEY ( channel_id, что-то_блин_полезное, toStartOfHour(dt)) ORDER BY ( channel_id, что-то_блин_полезное, toStartOfHour(dt), мусор)
Обсуждают сегодня