AN
для партционирования, мы просто взяли substr(id, 1, 1)
Size: a a a
2020 May 30
DT
вообще строго говоря, партицирование нужно для удобно манипуляции данными, те не речь идет не про бизнес цели, кмк а а административно-обслуживающие.
DT
для партционирования, мы просто взяли substr(id, 1, 1)
я не уверен, что кликхаус сумеет в этом случае в partition elimination
хотя за мой cityhash64 тоже нужно такое проверить
хотя за мой cityhash64 тоже нужно такое проверить
AN
@unamedrus понял, еще раз спасибо 👍
DT
@unamedrus понял, еще раз спасибо 👍
там щас как раз либо идут либо уже есть результаты поползновений в оптимизации GROUP BY LIMIT BY с учетом распределения данных(по sharding key правда, про партиции непонятно)
DT
надо посмотреть будут
D
Ну в голову в первую очередь приходит партицирование вида cityHash64(id) % 10 или id % 10
хотя бы потому что при OPTIMIZE клик по очереди прогоняет все партиции в цикле и мержит их парты
хотя бы потому что при OPTIMIZE клик по очереди прогоняет все партиции в цикле и мержит их парты
Нельзя так в кх. Кх держит минмакс самой колонки в парте и использует её при прунинге... Можно интдив например. А вообще нужно по месяцам по любому если данные устаревают, id уже в дополнение.
DT
Нельзя так в кх. Кх держит минмакс самой колонки в парте и использует её при прунинге... Можно интдив например. А вообще нужно по месяцам по любому если данные устаревают, id уже в дополнение.
Да, тогда только интдив, хотя его сложнее конечно посчитать, что бы было поровну.
впрочем вариант с substr(id, 1, 1) тоже тогда подойдет.
впрочем вариант с substr(id, 1, 1) тоже тогда подойдет.
D
Да, тогда только интдив, хотя его сложнее конечно посчитать, что бы было поровну.
впрочем вариант с substr(id, 1, 1) тоже тогда подойдет.
впрочем вариант с substr(id, 1, 1) тоже тогда подойдет.
Не подойдет )
D
id=10, id=100
попадут в один парт.. мин будет 1, макс 10000000... будет сканироваться
попадут в один парт.. мин будет 1, макс 10000000... будет сканироваться
DT
id=10, id=100
попадут в один парт.. мин будет 1, макс 10000000... будет сканироваться
попадут в один парт.. мин будет 1, макс 10000000... будет сканироваться
Мне лично показалось, что там idшник не числовой, а строковой
тогда будет ('aa','az') ('ba','bz')
тогда будет ('aa','az') ('ba','bz')
DT
Вообще, что бы это избежать всей этой боли проще тогда вынести это дело в отдельную колонку.
(если у них вообще есть запросы по конкретным айди, что вопрос на самом деле)
(если у них вообще есть запросы по конкретным айди, что вопрос на самом деле)
D
Мне лично показалось, что там idшник не числовой, а строковой
тогда будет ('aa','az') ('ba','bz')
тогда будет ('aa','az') ('ba','bz')
WHERE _id = '1045'
—-
цифровой в строке, а может просто query generator недоделанный... если цифровой в строке можно тогда по substr учитывая что строки сортируются по префиксу... но это очень тонкий лед.
и по мере роста данных будет глобальная порча распределения.
—-
цифровой в строке, а может просто query generator недоделанный... если цифровой в строке можно тогда по substr учитывая что строки сортируются по префиксу... но это очень тонкий лед.
и по мере роста данных будет глобальная порча распределения.
D
но все равно лучше месяц+subpart...
DT
WHERE _id = '1045'
—-
цифровой в строке, а может просто query generator недоделанный... если цифровой в строке можно тогда по substr учитывая что строки сортируются по префиксу... но это очень тонкий лед.
и по мере роста данных будет глобальная порча распределения.
—-
цифровой в строке, а может просто query generator недоделанный... если цифровой в строке можно тогда по substr учитывая что строки сортируются по префиксу... но это очень тонкий лед.
и по мере роста данных будет глобальная порча распределения.
это другой товарищ был
DT
но все равно лучше месяц+subpart...
у них похоже каждый айдишник будет присутствовать в почти каждом месяце, а нужен только последний, те умножение данных минимум в 12 раз, что неприятно
D
это другой товарищ был
D
у них похоже каждый айдишник будет присутствовать в почти каждом месяце, а нужен только последний, те умножение данных минимум в 12 раз, что неприятно
т.е. апдейт будет? а данные будут жить вечно?
DT
т.е. апдейт будет? а данные будут жить вечно?
те айдишки, что не обновлялись в течении года -> в утиль
D
просто если через год они все равно будут удаляться, лучше сдуплицировать и на уровне запроса optimize делать