我使用Spark流从Kafka消耗记录,并使用TTL将其写入ClickHouse表,ClickHouse版本为21.8.4.51,我的表DDL如下: 创建表Dataplugin.ods_stb_boot_up_up_delay_all_local on cluster'{cluster}'(cluster}'( `evtTime` int64, `evtCode`字符串, `pver`字符串, `stbid`字符串, `bootupdelay` int64, `profincode`字符串, `writeTime`DateTime, 索引模式_Match stbid类型ngrambf_v1(3,256,2,0)粒度3 ) 引擎= replicatedMergetree('/clickhouse/ods_stb_boot_up_up_delay_all_local/{shard}','{replica}') Toyyymmdd的分区(writetime) 订购(stbid,evttime) ttl writtime +间隔3个月 设置 merge_with_ttl_timeout = 86400, index_granularity = 8192, use_minimalistic_part_header_in_zookeeper = 1 但是,在2022年11月30日,我仍然可以从查询中获得结果: # 询问: 从dataplugin.ods_stb_boot_up_up_delay_all_local中选择计数(1),其中writetime <='2022-07-01 001 00:00:00'; # 结果: _____数数()______ |37323403 | | ________________ | 该表的字段称为“ writeTime”是指将记录放入表中的日期时间,从理论上讲,查询结果应为0,我尝试了Alter Table#{tablename} potitalize tll,优化表#{tablename} on'''{cluster}'final,系统启动ttl合并,它们都没有起作用,因此我确实需要您的帮助,并且表中有很多数据导致Zookeeper的副本节点中有很多Znodes,这可能会导致Clickhouse Server重新启动失败 TTL规则是在创建表格期间定义的,还是您更新表并之后创建了TTL? fwiw,toyyymmdd(writetime)对桌子进行了特定原因?不仅要较低的查询性能,因为您有更多的零件,即必须读取更多的文件,还可以从Drop分区功能中受益。 每天都保留分区,只需将每日分区放置,或者将桌子重新分配到每月分区,然后每月分区。 您需要用cronjob或类似的方式手动或更好地执行此操作。 TTL合并的另一个缺点是它们可以非常,我的意思是,根据CPU和I/O资源的使用非常昂贵,具体取决于分区密钥设计和分区中零件的大小。如果可能的话,人们应该更喜欢将分区置于TTL功能。 阅读:https://clickhouse.com/docs/en/faq/operations/delete old-data/#drop-partition
Clickhouse表TTL在版本21.8.4.51中不起作用
最新推荐文章于 2024-08-18 23:38:10 发布