ты можешь сделать
set send_logs_level='trace'
в сессии

и там покажет, что и сколько нужно прочесть

Всем, привет!
Подскажите пожалуйста. Есть сценарий бд, в которой нет никого разумного обоснования использовать несколько партиций, т.е. все данные можно просто положить в одну партицию. Возникает вопрос, не возникнет ли в будещем проблем, в виду того, что на диске нужно будет резервировать больше свободного места для процессинга такой одной большой партиции? Возможно стоит искусственно разделить данные по нескольким партициям, что бы данные не сливались в один большой файл?

Предпологается использование ReplacingMergeTree и TTL для записей

Кликхаус и не будет сливать данные в 1 большой файл(на самом деле парт состоит из большого числа файлов), у него есть некоторые ограничения на максимальный размер парта

Но если вы хотите использовать TTL, то лучше делить на партиции, тогда можно будет дропать сразу целый парт-партицию, а не заниматся сканом ее и вычищению ненужных более строк

OPTIMIZE FINAL не будет учитывать это ограничение конечно

@unamedrus Спасибо. Как раз OPTIMIZE FINAL вызывает наибольшие сомнения, т.к. его вызов сливает партицию в один файл (с учетом отдельных колонок конечно). Просто педпологали, вызывать примерно раз в пару недель OPTIMIZE FINAL, для "схлопывания" записей и обработку TTL

Для TTL есть отдельно Materialize TTL емнип

у вас какой TTL будет?

видимо, все таки, стоит сделать "искусственное" партиционирования. Хотя бы на десяток партиций. Что бы не держать в резерве на дисках 50% свободного пространства.

TTL будет порядка одного года

Ну я если честно не вижу проблем в партицировании по месяцам тогда.

вдруг вы потом захотите воспользоваться storage_policy

Другой вопрос, если вам желательно схлопывать допустим все id = 3 за весь год в 1 строку, тогда это будет возможно немного не удобно

у нас будет большое количество "схлопывание" записей на интервале в 1 год. Если делать партиционирование по месяцам, то получится, что в каждом месяце будет практически полная копия данных, что грубо говоря, дает вплоть до x12 больше затрат на размер хранилища

а сколько вообще данных?

>100e9 записей

> если вам желательно схлопывать допустим все id = 3 за весь год в 1 строку
да, как раз такой кейс. Причем на один id может приходится до тысяч записей

Ну в голову в первую очередь приходит партицирование вида cityHash64(id) % 10 или id % 10
хотя бы потому что при OPTIMIZE клик по очереди прогоняет все партиции в цикле и мержит их парты

именно так, это как раз то, что я назвал "искуственным" партиционирования. Т.е. разбить данные мы можем, но для бизнеса какого-то выйгрыша от этого не будет