[24 届秋招求职] 对 Leveldb 有一些了解，有对口的公司吗？

粗略看了下 paper ，请教几个问题
文章中只测试了 4 bits/key 的对比，是否意味着声称的性能提升基本来自于 baseline 在这个设置下 filter 失效带来的性能降级？如果设置为 8 bits/key 或者更高，是否还有论文声称的性能优势？
从内存节省方面，同样 workload 下与 RocksDB 团队提出的 Ribbon filter 相比是否具有优势？

@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 的访问频率差异就小很多，这种思路就很难再起到效果。

@qieqie 大佬有没有工作机会呀 5555

@qieqie 不好意思，我项目里写是 2018 年的版本，这篇论文还有一个 2019 年的版本： https://www.usenix.org/conference/atc19/presentation/li-yongkun ，内容会更多一些