Hi Hangxiang, Thanks for bringing this discussion. I have a few questions about the Proposal you mentioned in the FLIP.
The current conclusion is to use proposal 2, which is okay for me. My point is whether we should retain the potential of proposal 1 in the design. There are the following reasons: 1. No JNI overhead, just like the Performance Part mentioned in Flip 2. RocksDB currently also provides an interface for Env, and there are also some implementations, such as HDFS-ENV, which seem to be easily scalable. 3. The RocksDB community continues to support LSM for different storage media, such as Tiered Storage <https://github.com/facebook/rocksdb/wiki/Tiered-Storage-%28Experimental%29> And some optimizations have been made for this scenario, such as Per Key Placement Comparison <https://rocksdb.org/blog/2022/11/09/time-aware-tiered-storage.html>. *Secondary cache <https://github.com/facebook/rocksdb/wiki/SecondaryCache-%28Experimental%29>*, similar to the Hybrid Block Cache mentioned in Flip-423 If we use proposal1, we can easily reuse these optimizations .It is even possible to discuss and review the solution together in the Rocksdb community. In fact, we have already implemented some production practices using Proposal1 internally. We have integrated HybridEnv, Tiered Storage, and Secondary Cache on RocksDB and optimized the performance of Checkpoint and State Restore. It seems work well for us. -- Best, Yue
