Добрый день. Подскажите где почитать принцип работы TTL для таблицы? Навесили на

таблицу TTL
ALTER TABLE table MODIFY TTL ActionDate + toIntervalMonth(6) и получил высокую загрузку диска + кучу дополнительных system.merges
В таблице данных только за последние 4 месяца, TTL выставлен на 6 месяцев, логично было бы предположить, что ничего не будет происходить, однако клик загружен 💯

https://clickhouse.com/docs/en/operations/settings/settings#ttl_only_drop_parts

Кажется, проблема в чем-то другом, у меня SETTINGS ttl_only_drop_parts = 1 и кажется это должно снижать нагрузку в процессе удаления, но у меня TTL 6 месяцев, а данных только 4, т.е. ничего не должно происходить. Создается впечатление как буд-то кликхаус помечает каждую строку в отдельности в исторических данных когда ей надо быть удаленной; Я только сегодня установил ТТЛ

он не помечает строку, но он проверяет условие TTL и фильтрует строки, либо удаляет парт целиком... при мерже партов SELECT * FROM system.merges FORMAT Vertical что показывает ?

вот таких примерно 10 строк elapsed: 8126.720571642 progress: 0.5164301050749575 num_parts: 1 source_part_names: ['202306_6_6_0'] result_part_name: 202306_6_6_0_68 source_part_paths: [‘/XXX/202306_6_6_0/'] result_part_path: /XXX/202306_6_6_0_68/ partition_id: 202306 is_mutation: 1 total_size_bytes_compressed: 131193953627 total_size_marks: 77684 bytes_read_uncompressed: 346867230903 rows_read: 328335360 bytes_written_uncompressed: 346813428453 rows_written: 328335360 columns_written: 0 memory_usage: 490956444 thread_id: 97 merge_type: merge_algorithm:

progress: 0.51 rows_read: 328 335 360 total_size_bytes_compressed: 131 193 953 627 ну то есть у вас мерж по 0.6 милларда строк в результирующем парте, с необходимостью прочитать под нагрузкой 130 гигабайт (и записать примерно столько же) и вы жалетутесь почему у вас 10 потоков которые должны суммарно переписать 2.6 (1.3+1.3) терабайта, работают уже целых 2.5 часа? по моему все ок... можно ограничить максимальный размер парта в 50 гигов... наверное https://clickhouse.com/docs/en/operations/settings/merge-tree-settings#max-bytes-to-merge-at-max-space-in-pool парты будут чуть меньше... но 50 гигов тоже нормальный размер...

Но почему? Почему? Надо прочитать и записать все данные чтобы установить TTL? Я просто не понимаю как это работает, казалось бы зачем трогать данные которые младше чем TTL?

еще раз, TTL это декларативное условие применямое для фильрации строк в background merge background merge итак сделается с чего вы решили вообще что ваш этот конкретный merge из-за TTL?

Потому что мержи начались сразу после того как я выполнил ALTER TABLE table MODIFY TTL ActionDate + INTERVAL 6 MONTH и только на этой шарде, на остальных такого нет, никто не обращается к 202306 партиции, отсюда и вывод что это MODIFY TTL как-то что-то делает с данными. Он кстати не завершился еще is_initial_query: 1 user: default query_id: 5fd23a3d-a5eb-4fd9-8097-c9cceb68b985 address: ::ffff:172.17.0.1 port: 52398 initial_user: default initial_query_id: 5fd23a3d-a5eb-4fd9-8097-c9cceb68b985 initial_address: ::ffff:172.17.0.1 initial_port: 52398 interface: 1 client_name: ClickHouse client_revision: 54461 client_version_major: 23 client_version_minor: 1 client_version_patch: 3 http_method: 0 http_user_agent: http_referer: forwarded_for: quota_key: distributed_depth: 0 elapsed: 9076.79912438 is_cancelled: 0 is_all_data_sent: 0 read_rows: 0 read_bytes: 0 total_rows_approx: 0 written_rows: 0 written_bytes: 0 memory_usage: 8388630 peak_memory_usage: 8388630 query: ALTER TABLE table MODIFY TTL ActionDate + INTERVAL 6 MONTH; thread_ids: [6503] ProfileEvents: {'Query':1,'ArenaAllocChunks':27,'ArenaAllocBytes':110592,'FunctionExecute':36,'ZooKeeperTransactions':27206,'ZooKeeperList':2,'ZooKeeperCreate':4,'ZooKeeperExists':18126,'ZooKeeperGet':9068,'ZooKeeperMulti':6,'ContextLock':347,'RWLockAcquiredReadLocks':31} Settings: {'max_query_size':'2621440','distributed_connections_pool_size':'2048','use_uncompressed_cache':'1','distributed_directory_monitor_sleep_time_ms':'300000','distributed_directory_monitor_max_sleep_time_ms':'3600000','distributed_directory_monitor_batch_inserts':'1','load_balancing':'random','distributed_aggregation_memory_efficient':'1','log_queries':'1','joined_subquery_requires_alias':'0','max_bytes_before_external_group_by':'5000000000','max_bytes_before_external_sort':'5000000000','max_ast_elements':'500000','readonly':'0','max_memory_usage':'15000000000','background_pool_size':'64'} current_database: default

видимо у вас MATERIALIZE TTL происходит... Тем боле что у вас он уже было, надо вашу ActionDate пересчитать для этого... для всех партов...

Спасибо! #ttl применение MATERIALIZE TTL вызвало ошибку latest_fail_reason: Code: 47. DB::Exception: Missing columns: 'Number1' 'ActionAt' 'AppID' 'Number2' 'Action' 'ComID' 'Datacenter' 'AfID' while processing query: 'SELECT ActionDate, Action, toStartOfFiveMinute(ActionAt), AfID, ComID, AppID, Datacenter, count(), sum(Number1), sum(Number2) GROUP BY ActionDate, Action, toStartOfFiveMinute(ActionAt), AfID, ComID, AppID, Datacenter', required columns: 'ActionDate' 'AfID' 'Datacenter' 'ComID' 'Action' 'Number2' 'AppID' 'ActionAt' 'Number1' 'ActionDate' 'AfID' 'Datacenter' 'ComID' 'Action' 'Number2' 'AppID' 'ActionAt' 'Number1'. (UNKNOWN_IDENTIFIER) (version 22.8.15.23 (official build)) ошибка возникла при SETTING materialize_ttl_recalculate_only=1 если поставить materialize_ttl_recalculate_only=0 и заново выполнить ALTER то процесс продолжается Спасибо! Теперь более менее понятно что происходит в целом, жаль что не работает materialize_ttl_recalculate_only=1