这两年做了一个嵌入式 KV 存储引擎，叫 Mace https://github.com/abbycin/mace，分享一下。
它是什么
嵌入式、事务性 KV 数据库，设计上想同时拿到 B+ Tree 读延迟可预测和 LSM Tree 写吞吐高的优点。主要特性：
- Bw-Tree 风格的有序索引 + MVCC snapshot isolation
- append-only WAL + 异步 checkpoint
- 大 value 分离（ blob 文件）
- bucket 粒度管理，懒加载
- merge operator 支持
- 可选 zstd 压缩
- CRC 校验保证数据完整性
目前状态
还非常年轻，功能应该大差不差了，但还有很多细节需要打磨（比如：空间满了或许应该转为只读而不是打日志然后崩溃，诸如此类的细节）。不过好消息是，存储格式和公开 API 基本稳定，crash recovery 经过测试
为什么要做这个
两年多前看过内核和用户态文件系统的实现，就想着自己也写一个练练手，于是用 Rust 写了一个 junkfs ，其中 kv 存储负责元数据管理（ super block, inode ，dentry 什么的），当时有一个关注点是：rename 这类操作应该是原子的，所以元数据管理要有事务才行，挑选了一圈没发现合适的。机缘巧合，同一时间在知乎上看到 leanstore 和 photondb ，发现这两个源码也不是很多，于是读了代码和相关的 paper 、书籍，虽然这两个都不适合 junkfs ，但思想有了，就感觉我上我也行，于是就有了 mace
和同类的对比
在选型的时候有看过 sled 和 rocksdb 的 Rust 绑定，前者很久不更新了，后者没能把它跑起来（非常的重），但后续来看 mace 其实一直在向 rocksdb 看齐，以至于一直没有和其他 kv 存储对比过，下面是和 rocksb 对比的结果的一小部分（ relaxed durability ，snapshot reads ，16B key / 128B value ，1M keys ）：
| 工作负载 | Mace ops/s | RocksDB ops/s | 倍数 |
|---|---|---|---|
| W1 （ 95%读 5%写，8 线程） | 2,941,301 | 1,100,399 | 2.67x |
| W2 （ 95%读 5%写 zipf ，8 线程） | 4,156,555 | 1,442,814 | 2.88x |
| W3 （ 50%读 50%写，8 线程） | 1,306,037 | 662,721 | 1.97x |
| W4 （ 5%读 95%写，8 线程） | 707,002 | 473,584 | 1.49x |
| W6 （ 100% scan ，8 线程） | 460,125 | 284,069 | 1.62x |
诚实的讲：在读多写少和 scan 场景下表现相对好一些，写密集场景优势缩小。 benchmark 工具和完整结果:
后续如何演化
目前规划的特性就剩下：自定义 comparator 。但这个不急（因为没有人催）。因此后续主要放在稳定性和细节的打磨上，以及一些遗留问题的解决
Select Language