В целом, да, вы правы. Данную таблицу использую для двух основных целей:
1) Сбор данных для графиков по используемым устройствам и т.п
2) Предоставление информации об определенных пользователях, которые как - то посещали страницы.

Сейчас проблема со второй целью. Под "возможно надо не так", вы подразумевали иной подход в получении данных (то есть при поиске использовать доп. параметры для фильтрации, к примеру дату) или в структуре их хранения?

created_at это что

Дата записи лога, данные разбиты по дням

то есть у вас есть username, он источник последовательности action, дата округлена до даты почему-то, вы делаете аналитику и смотрите логи по username?

Да

тогда по идее переставить индекс, добавить фильтры по дате где можно, не селектить лишние колонки если не нужны, ну и с event_time DateTime чуть более понятно что происходит.

Хорошо, спасибо, попробую

хороший способ оптимизации -- не использовать КХ для таких запросов

>вроде бы все было хорошо

не было никогда хорошо, ни в какой версии. Исправили вчера буквально, видимо ждать следующую 20.4

а нет, еще не вмержено https://github.com/ClickHouse/ClickHouse/pull/12548

:-D ну под «хорошо» я подразумевал что кое-как да работало, а тут похоже вообще от слова совсем встало.

Спасибо за ссылку, будем ждать релиза с фиксом!

видимо оно чистило(ит) один парт за запуск (раз в сутки), если партов много, например подневное партиционирование и остается 3-4 парта в каждой партиции, то очистить оно не может ну никак.

Да, похоже на наш кейс очень

ну можно поставить merge_with_ttl_timeout поменьше , чтобы например 4 раза в сутки запускалось

Спасибо, попробуем завтра

да у нас в 20.3 на эту тему баг был
https://github.com/ClickHouse/ClickHouse/issues/11576

да там штук 15 тикетов про одно и тоже "TTL doen't work"

и кстати всем кто использует "частое" партиционирование и у кого кол-во партов в тысячах стоит прочитать https://github.com/ClickHouse/ClickHouse/issues/11933

TLDR однажды когда партов станет например 7000 у Replicated у вас сломаются мутации (Connection loss. Len error ) и соотвественно все alter и придется увеличить -Djute.maxbuffer в зукипере (перегрузив все ноды ЗК)

чорд, увеличим заранее... так как партов уже больше )

В КХ поставлено максимум 256МБ, в ЗК jute.maxbuffer 1МБ по дефолту, видел что в доках lucene/solr ставят 50МБ
правда разработчики ЗК считают что даже 1МБ безумие и ought to be enough for anybody