clickhouse表TTL在21.8.4.51版本中不工作

Question

我使用spark streaming从kafka消费记录，并将它们写入带有ttl的clickhouse表，clickhouse版本是21.8.4.51，我的表ddl如下:

CREATE TABLE dataplugin.ods_stb_boot_up_delay_all_local ON CLUSTER '{cluster}'(
`evtTime` Int64,
`evtCode` String,
`pVer` String,
`stbID` String,
`bootUpDelay` Int64,
`provinceCode` String,
`writeTime` DateTime,
INDEX pattern_match stbID TYPE ngrambf_v1(3,256,2,0) GRANULARITY 3
)
ENGINE=ReplicatedMergeTree('/clickhouse/ods_stb_boot_up_delay_all_local/{shard}','{replica}') 
PARTITION BY toYYYYMMDD(writeTime) 
ORDER BY (stbID,evtTime) 
TTL writeTime + INTERVAL 3 MONTH 
SETTINGS 
merge_with_ttl_timeout = 86400,
index_granularity = 8192,
use_minimalistic_part_header_in_zookeeper=1

然而，在2022年11月30日，我仍然可以从我的查询中得到结果:

# Query:
select count(1) from dataplugin.ods_stb_boot_up_delay_all_local where writeTime <= '2022-07-01 00:00:00';
# Result:
_____count()______
|   37323403     |
|________________|

表中名为'writeTime'的字段表示记录放入表中的日期时间，理论上，查询结果应该是0，我尝试了ALTER table #{tableName} MATERIALIZE TLL,OPTIMIZE TABLE #{tableName} ON '{cluster}' FINAL,system start TTL MERGES，它们都不工作，所以我真的需要你的帮助，表中的数据太多导致zookeeper的副本节点中有很多znodes，这可能导致clickhouse server重启失败

Answer 1

TTL规则是在创建表时定义的，还是更新表后创建TTL ?

FWIW，是否有一个特定的原因划分表的toYYYYMMDD(writeTime)?这不仅降低了查询性能，因为您有更多的部分，即需要读取更多的文件，您还可以从DROP PARTITION特性中获益。

保留按天划分的分区，并简单地删除按天划分的分区，或者将表重新划分为按月划分的分区，并将按月划分的分区作为一个整体删除。

您需要手动执行此操作，或者使用cronjob或类似的方法更好。

TTL合并的另一个缺点是，它们在cpu和I/o资源使用方面非常昂贵，这取决于分区键的设计和分区中部件的大小。如果可能的话，应该选择删除分区而不是TTL特性。

部分阅读:https://clickhouse.com/docs/en/faq/operations/delete-old-data/#drop-partition