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

[Engou]

主要有一个在 Leveldb 上的论文复现项目： https://github.com/WangTingZheng/Paperdb/tree/elasticbf-dev ，在 100GB 的 DB 上点查 1 千万次，读吞吐量提升了 23%。有兴趣的老哥也可以提提 pr 或者 issue ，看看代码还有哪些地方有问题，project 还有一些工作木有做完，大佬们也可以提提意见。整个项目是我一个人独立完成的。

主要负责：
一、对顶会论文的阅读、提炼、分析、讨论
二、根据论文的设计在 LeveLDB 复现相对应的功能
三、使用单元测试、Github CI 、Clang 的 Thread Safety Analysis 工具检查修复 bug
四、编写相对应的脚本进行 benchmark ，为 ElasticBF 适配 YCSB-cpp ，进行压测
五、编写入门文档、复现设计文档、注释，并注意代码命名规范
六、使用 Github Issue 、Project 管理项目

项目特点：
有比较完善的单元测试，跨平台跨编译器 CI 来保证代码质量
有详细的入门文档、设计文档，以及注释，函数命名尽可能地规范

[qieqie]

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

[Engou]

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

[Engou]

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

[Engou]

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