Hi

我觉得你的担心是在TTL尚未过期的周期内,数据就已经写满磁盘了,这个肯定不是TTL能涵盖的问题,从作业规模上尝试限制写入量,或者增大并发,降低单个rocksDB需要承担的数据量(前提是你的所有机器的磁盘空间是大于你的数据量的)。另外如果真的很担心的话,换一个压缩率更小的算法
 也有一些帮助(代价是更耗时更耗CPU, rocksDB 官方推荐ZTSD或者Zlib)[1],设置compression type可以参考rocksdb 
ColumnFamilyOptions的setCompressionType 方法 [2]

[1] https://github.com/facebook/rocksdb/wiki/Compression#configuration
[2] 
https://github.com/facebook/rocksdb/blob/bc8b05cb779a578b5f5acf8d9390af1d17e65ff5/java/src/main/java/org/rocksdb/ColumnFamilyOptions.java#L282

祝好
唐云

________________________________
From: claylin <1012539...@qq.com>
Sent: Friday, October 11, 2019 16:16
To: user-zh <user-zh@flink.apache.org>
Subject: 关于使用RocksDBStateBackend 
启用state.backend.rocksdb.ttl.compaction.filter.enabled 配置的问题

在使用RocksDBStateBackend时,为了防止state状态过大导致资源不够用(磁盘),采用了state.backend.rocksdb.ttl.compaction.filter.enabled配置,使得每次rocksdb每次进行compact时候判断状态的ttl时间,然后删除过期的state,https://github.com/facebook/rocksdb/wiki/Time-to-Live里面也有说明,但是有没有这种情况,rocksdb每次compact时候,有些状态并没有compact到,那这个时候已经过期的state就不会被删除。而且flink中的ttl刷新策略只有OnCreateAndWrite和OnReadAndWrite,没有那种指定生存时间,不用刷新,譬如说ttl为1天,那在一天后肯定过期,否则就可能出现state的ttl一直刷新,永远不过期,这样最终导致磁盘打满,看有解决方案使用定时任务自己删除,但是这样会严重损耗性能。请问大家还有其他方案吗

Reply via email to