- 主题:flink的布隆表达式的问题
就是因为要保存状态,所以内存吃紧
【 在 sayinger (言者) 的大作中提到: 】
: 去重完全可以直接用状态吧,如果有时效性因素的话,状态的过期也比较好控制
--
FROM 180.167.95.*
状态后端用的啥,rocksdb都扛不住?
【 在 guestking (无) 的大作中提到: 】
: 就是因为要保存状态,所以内存吃紧
--
FROM 222.128.87.*
我的理解
rocksdb只是用来备份的
实际执行还是用的内存的数据
如果每次读状态,都是从rocks里面读
用完就丢,那么照道理应该不会oom
我这边其实并发量很小的
【 在 sayinger (言者) 的大作中提到: 】
: 状态后端用的啥,rocksdb都扛不住?
--
FROM 180.167.95.*
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.
3、flink的内存模型比较复杂,特别是rocksdb有自己的内存管理机制(而且目前实现上有问题,某些时候控制不住超用),所以需要针对具体场景调优。
【 在 guestking (无) 的大作中提到: 】
: 我的理解
: rocksdb只是用来备份的
: 实际执行还是用的内存的数据
: 如果每次读状态,都是从rocks里面读
: 用完就丢,那么照道理应该不会oom
: 我这边其实并发量很小的
--
FROM 222.128.87.*
我这边是用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.*