rocksdb对比filestatebackend

[yidan zhao <hi...@gmail.com>]

如题，我生产中目前一直都是使用的FileStateBackend，然后使用一个对象存储服务作为后端。

按照我的理解，这种方式下，状态的操作性能很高，都是在内存内部，只有检查点时候才会输出到对象存储中。但是，不支持增量检查点。

RocksDB支持增量检查点，但是缺点是每个状态的操作都是需要序列化/反序列化，至于是文件还是内存操作可能还和rocksdb的块大小，多久刷新等有关。
不过我现在在想，既然我的任务的状态当前使用内存存储，也就是内存存储是能够容纳我的全状态的。
那么是否我从FileStateBackend切换到RocksDB其实性能也不会降低很多呢？ 就是牺牲很少性能，换来增量检查点。

此外，还有个点。RocksDB的增量检查点在每次检查点时候，输出到对象存储的部分也是增量？还是全量。
只是rocksdb自身使用增量状态，然后检查点存储的时候是全量到对象存储吗？
还是说，对象存储中存储的ckpt-1，ckpt-2，ckpt-3等也是增量的，即ckpt-3可能依赖ckpt-2等这样。

Re: rocksdb对比filestatebackend

[Yun Tang <my...@live.com>]

Hi Yidan,


  1.  是否我从FileStateBackend切换到RocksDB其实性能也不会降低很多呢？
  2.  这个涉及到RocksDB这种LSM架构的DB读写路径了，即使逻辑数据量可以全部存储在内存中，由于RocksDB的write buffer默认会存储相同key的不同value，而且checkpoint时候仍然会触发flush，很难避免数据落盘，数据落盘之后的读路径肯定没有Flink的内存state backend性能好，二者性能还是有些差异的，不过实际生产中可能不需要 FsStateBackend 那么高的性能。

  1.  RocksDB本地的checkpoint其实是全量的，只是上传远程存储的时候是增量的，ckpt-3有可能会依赖ckpt-2中的部分文件。

祝好
唐云
________________________________
From: yidan zhao <hi...@gmail.com>
Sent: Tuesday, June 22, 2021 11:55
To: user-zh <us...@flink.apache.org>
Subject: rocksdb对比filestatebackend

如题，我生产中目前一直都是使用的FileStateBackend，然后使用一个对象存储服务作为后端。

按照我的理解，这种方式下，状态的操作性能很高，都是在内存内部，只有检查点时候才会输出到对象存储中。但是，不支持增量检查点。

RocksDB支持增量检查点，但是缺点是每个状态的操作都是需要序列化/反序列化，至于是文件还是内存操作可能还和rocksdb的块大小，多久刷新等有关。
不过我现在在想，既然我的任务的状态当前使用内存存储，也就是内存存储是能够容纳我的全状态的。
那么是否我从FileStateBackend切换到RocksDB其实性能也不会降低很多呢？ 就是牺牲很少性能，换来增量检查点。

此外，还有个点。RocksDB的增量检查点在每次检查点时候，输出到对象存储的部分也是增量？还是全量。
只是rocksdb自身使用增量状态，然后检查点存储的时候是全量到对象存储吗？
还是说，对象存储中存储的ckpt-1，ckpt-2，ckpt-3等也是增量的，即ckpt-3可能依赖ckpt-2等这样。