- 主题:flink的布隆表达式的问题
用布隆过滤器做去重
但是因为keyBy比较细，所以导致会生成很多的布隆过滤器
直接就oom了
这种情况有什么比较好的办法来处理吗
--
FROM 180.167.95.*
就是keyby之后，会分出很多个组
比如按用户来keyby
【 在 eventvwr (精光互撸娃) 的大作中提到: 】
: keyBy比较细是啥意思？
--
FROM 180.167.95.*
是啊，本来就是每个keyby维护自己的状态
【 在 archmind (archmind) 的大作中提到: 】
: 每个key一个bloomfilter？
--
FROM 180.167.95.*
是啊，所以很头疼，加资源也是无底洞
这种情况是不是就不该用布隆过滤器啊
【 在 archmind (archmind) 的大作中提到: 】
: 那key多了肯定爆，只能加资源
--
FROM 180.167.95.*
为了去重
【 在 sayinger (言者) 的大作中提到: 】
: 过滤什么玩意，直接用状态不行？
--
FROM 180.167.95.*
就是因为要保存状态，所以内存吃紧
【 在 sayinger (言者) 的大作中提到: 】
: 去重完全可以直接用状态吧，如果有时效性因素的话，状态的过期也比较好控制
--
FROM 180.167.95.*
我的理解
rocksdb只是用来备份的
实际执行还是用的内存的数据
如果每次读状态，都是从rocks里面读
用完就丢，那么照道理应该不会oom
我这边其实并发量很小的
【 在 sayinger (言者) 的大作中提到: 】
: 状态后端用的啥，rocksdb都扛不住？
--
FROM 180.167.95.*
我这边是用rocksdb来做checkpoints的持久化的
我以为你说的是这个
我研究一下你说的这个方案
谢谢
【 在 sayinger (言者) 的大作中提到: 】
: 1、你所谓的备份是指故障恢复吧，那不是rocksdb的作用，checkpoint才是。
: 2、rocksdb做状态后端的时候，如果所有状态仍然在内存中，那跟memory做状态后端有啥区别，如何能实现:
: Note that the amount of state that you can keep is only limited by the amount of disk space available. This allows keeping very large state, compared to the HashMapStateBackend that keeps state in memory.
: ...................
--
FROM 180.167.95.*