да

всем здравствуйте, подскажите, пожалуйста, в КХ реализована возможность работы с динамическими запросами, не увидел нигде в инструкциях?

Добрый день, такой вопрос по ТТЛ и merge_with_timeout_ttl.
ttl_only_drop_parts=1

у нас где-то 40-50 партов в час...  КХ проверяет каждый интервал, но дропает только один парт за одну проверку. Решается более частыми проверками чтобы количество проверок было больше количества партов которые будут дропатся.
Это норма или можно как-то увеличить число партов, что будут дропаться по ТТЛ за одну итерацию проверки? а то приходится чуть ли не в минуту выставлять merge_with_timeout_ttl чтобы он успевал дропать...

логично предположить что он должен дропать все что expired

Нет, стринги, но они очень сильно low cardinality

очень ready. проблем не возникало. Правда надо осторожней смотреть в system.column_parts там размер uncompressed не строковый а уже переведенный в цифры

Ну вокруг записи и консистентного чтения у нас велосипеды накручены, они даже работают в проде. Я просто попробовала low cardinality на строковых колонках, перф на чтение улучшился в 3 раза, мне такое очень надо

Круто! Спасибо!

а что конкретно вы в них храните то?

Там недлинные строки типа «тип энтити»

Тип сорс системы и тп

а, тогда норм

По ним фильтр в основном и иногда группировка

Куль, спасибо, ребята!

А для развития - где может быть не норм?

ну допустим числовые типы какие то, (вы там написали про деньги я вот и напрягся)
либо уникальные строки

Аа

ну 100500мильенов строк лучше не хранить... хотя мы не пробовали, у нас есть колонка под 200 тыс, и ниче, работает... думаю оно влияет на память

Вы имеете в виду 100500 разных видов строк? То есть не low cardinality?

У меня 50 типов энтити на 5 млрд, казалось бы прямой кейс

да, не храните не lowcardinality