А долго храните?

Собственно 35 дней пока позволяет 8 нод)

фига се у вас данные

спасибо)

ноды могут быть разные. У нас где 7+ лярдов в день -  дневное, а остальные в основном месячные.

ну там суть в том что при большом количестве партиций, при обширных селектах может убиваться IO, и при увеличивается время перезапуска ClickHouse.
Но это конечно не про ту ситуацию когда у вас 35 партиций))

Другими словами текущая связка с дневными партициями это норма? Нет смысла делать по месяцам

Ну смотрите, тут по опыту многое зависит от дисков.
Если вы например будете хранить 1 год, то это уже будет 365 партиций, а если 3 года то 1095. На обычных HDD это уже может быть ощутимо. А те же SSD/NVME проглотят без вопросов.

А если вы планируете хранить например год, то уверены ли вы что дропать будете по дням? В масштабах года мне кажется уже можно смотреть в сторону недельных/месячных партиций. Но все конечно зависит от бизнеса. Кому то и полгода от года дропнуть не страшно)

а зачем хранить сами ответы в базе (да и еще и в разных форматах) вы по ним ищете?

Не много строим. Скорее для денежных расчётов в конце периода. А графики по большей части по count()

не очень понял сорри... сам текст ответа парсится по колонкам чтобы некоторые данные потом считать плюс хранится еще весь ответ на всякий случай?

Добрый день! подскажите плиз когда стоит дробить партиции, например по дням или часам? Что это дает и как влияет на производительность?

Привет всем, столкнулся с проблемой - использую CH через HTTP интерфейс (либа clickhouse для nodejs), у меня есть здоровенный по размеру селект (просто очень большое перечисление в WHERE состоящее из кучи конструкций OR/AND и автогенерируемое).
Проблема заключается в следующем - как только запрос достигает определенного размера сервер начинает сыпать 'CH  Error: 400: Bad Request'.
У меня стойкое ощущение что где-то упираюсь в лимит по размеру запроса, какую настройку пошатать?

У GET запроса http есть лимит у POST - нет, используй POST.

хм там вроде POST используется, но спасибо за идею, надо потрассировать - вдруг и правда GET

В основном для удаления. Чем больше партиций, тем тяжелее их все вместе читать. Плодится большое количество файлов. Но все это конечно сильно зависит от дисков.

Проверьте вот эту настройку
https://clickhouse.tech/docs/en/operations/settings/settings/#settings-max_query_size

Я не упоминал никаких «ответов» и текста парсящего в разных форматах. Вы наверное не того человека упомянули в чате

действительно оказалось что для SELECT либа почему-то использует GET. А нет возможности изменить предел GET в CH? Технически то разницы особо нет