D
я бы на самом деле не заморачивался с таким условием в ORDER BY и сделал бы через UNION двух таблиц с TTL
не совсем понял суть идеи
Size: a a a
2020 May 30
EM
О мудрейшие. Доступна ли в кх функциональность по написанию своих функций, точки расширения (плагины) и подобное?
В данный момент только путём написания функций прямо в исходниках и сборки сервера с нужной функцией. Хотя в некоторых выступлениях разработчики обсуждали что в перспективе, такое может быть появится через какие нибудь скриптовые языки. А какую функцию вы хотели написать ?
DT
не совсем понял суть идеи
будет две таблицы, одна с агрегацией по месяцам, другая по дням(либо использовать базовую твою таблицу)
данные старше месяца будут браться из первой таблицы, данные младше из второй.
данные старше месяца будут браться из первой таблицы, данные младше из второй.
D
а ttl для случая если я буду выносить данные за последние два месяц в отдельную таблицу как я понял
D
но даже с таким подходом придется использовать runningAccumulate
DT
но даже с таким подходом придется использовать runningAccumulate
можно через массивы :)
E
В данный момент только путём написания функций прямо в исходниках и сборки сервера с нужной функцией. Хотя в некоторых выступлениях разработчики обсуждали что в перспективе, такое может быть появится через какие нибудь скриптовые языки. А какую функцию вы хотели написать ?
Постоянно возникает желание какой-нибудь хитрой обработки данных (шифрования например)
Если б такое можно было реализовать на какомнить lua, подписавшись на события или иным образом - это бы решило некоторые бизнес задачи без приседаний.
Если б такое можно было реализовать на какомнить lua, подписавшись на события или иным образом - это бы решило некоторые бизнес задачи без приседаний.
D
ну тоже как вариант
а мой первый вариант не очень жизнеспособный я так понял?
а мой первый вариант не очень жизнеспособный я так понял?
DT
ну тоже как вариант
а мой первый вариант не очень жизнеспособный я так понял?
а мой первый вариант не очень жизнеспособный я так понял?
ну ты же сказал, что данные агрегирует правильно, так что возможно работоспособный.
но кмк лучше делать проще.
но кмк лучше делать проще.
E
щас пилят возможность UDF
но желающие могут уже попробовать накостылять через cache словарь.
но желающие могут уже попробовать накостылять через cache словарь.
Через кеш имеется в виду - построить свой метаязык в виде кодирования запроса в ключ и получения значения по ключу через внешний сервис? Который будет ключ декодировать правильно и выдавать ответ
DT
Через кеш имеется в виду - построить свой метаязык в виде кодирования запроса в ключ и получения значения по ключу через внешний сервис? Который будет ключ декодировать правильно и выдавать ответ
зачем метаязык?
словари поддерживают нескольких колонок как комплексный ключ.
а больше ведь никаких данных в таблицах и не существует.
а так да, потом либо по URL, либо по exec источнику словаря доставать данные
словари поддерживают нескольких колонок как комплексный ключ.
а больше ведь никаких данных в таблицах и не существует.
а так да, потом либо по URL, либо по exec источнику словаря доставать данные
D
ну ты же сказал, что данные агрегирует правильно, так что возможно работоспособный.
но кмк лучше делать проще.
но кмк лучше делать проще.
спасибо за совет 🙂 попробую и если что - отпишу)
Можешь еще подсказать на счет index_granularity? Как правильно его расчитать? Если оставлять дефолтный 8192, то тогда очень много данных кх левых читает
Можешь еще подсказать на счет index_granularity? Как правильно его расчитать? Если оставлять дефолтный 8192, то тогда очень много данных кх левых читает
E
зачем метаязык?
словари поддерживают нескольких колонок как комплексный ключ.
а больше ведь никаких данных в таблицах и не существует.
а так да, потом либо по URL, либо по exec источнику словаря доставать данные
словари поддерживают нескольких колонок как комплексный ключ.
а больше ведь никаких данных в таблицах и не существует.
а так да, потом либо по URL, либо по exec источнику словаря доставать данные
E
Спасибо
DT
ну если у тебя точечные запросы по айди, то можно примерно почувствовать так:
получаем максимальное число id в 1 партиции (но помним, что данные хранятся в партах, которые есть только некая часть партиции) прикидываем в какой размер гранулы попадет это число
получаем максимальное число id в 1 партиции (но помним, что данные хранятся в партах, которые есть только некая часть партиции) прикидываем в какой размер гранулы попадет это число
DT
но слишком частые гранулы тоже ничего хорошего, ведь PK сидит в оперативной памяти всегда
DT
По поводу очень много, нужно возможно чуть подождать, что бы данные после инсерта смержились, скорее всего ситуация была бы лучше
D
Если я правильно понял, то у меня гранула должна охватывать максимальное количество записей для конкретного _id в рамках партиции.
Начал играть с гранулами после того как увидел вот это:
Начал играть с гранулами после того как увидел вот это:
На исходной таблице dynamic, если верить табиксу, получаются такие затраты:
0.01 sec.| 407,073 rows.| 14 MB
При том что размер самой таблицы 16793961 rows
И для конкретного _id +- 152 rowsDT
ну у тебя месячные партиции, те кликхаус должен прочитать 12(месяцев)*8192*2(может быть такая ситуация, что попало между двух гранул)*N(число партов в партициях)
DT
если допустить, что число партов где то 3-4, то выходит нужно прочесть 600к строк)