这两年做了一个嵌入式 KV 存储引擎，叫 Mace /ai-market-guide/ ，分享一下。它是什么 嵌入式、事务性 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 工具和完整结果: /ai-market-guide/ /ai-market-guide/ 后续如何演化 目前规划的特性就剩下：自定义 comparator 。但这个不急（因为没有人催）。
因此后续主要放在稳定性和细节的打磨上，以及一些遗留问题的解决