@qieqie 论文里给了不同 bit 配置的实验效果，从结果上来看是好的，但是不同的配置肯定性能会有差距，而且这个性能很可能和 kv 的长度的分布有关系，很难调整，因为会影响到 bitmap 的长度，和读取 bitmap 的 IO 数量，总的来说，书面上是有性能优势，但是实际上，我个人偏向来说，可能不一定会有优势。至于和 ribbon filter 的对比，我还没有仔细研究，但是我更倾向于 ribbon 更好，理由如下：1.rocksdb 团队肯定也试过 elasticbf ，最终木有放入，肯定是有原因，一般论文会有水分（毕竟要和工业界竞争），但是工业界的项目水分不大，因为是要实实在在产生效益的，第二是 elasticbf 破坏了 sst 的只读性质，导致 get 的时候需要考虑更多的并发安全问题，就需要加锁或者使用原子变量，这里会有额外的性能开销，而且动态调整所使用的 mq 是一个全局的 cache ，不能像普通的 lru 那样使用分片机制来减少锁的开销，所以这一块开销会比较大，但是 ribbon filter 可能对整体的系统改变较小，需要加锁的地方更少，读性能，尤其是在多线程环境下的性能可能回更好。第三是 ribbon filter 可能更具备通用性，elasticbf 是利用数据的局部性原理来优化读性能的，这依赖与 LSM Tree 的分层结构，像 B+ tree 那种所有的数据都在叶子节点的，各个 block 的访问频率差异就小很多，这种思路就很难再起到效果。