一位开发者分享了历时两年多打造的嵌入式 KV 存储引擎 Mace，项目已在 GitHub 开源。该引擎采用 Rust 编写，设计目标是同时获得 B+ Tree 读延迟可预测与 LSM Tree 写吞吐高的优点。核心特性包括：Bw-Tree 风格的有序索引搭配 MVCC 快照隔离、append-only WAL 日志与异步 checkpoint、大 value 分离存储至 blob 文件、bucket 粒度管理与懒加载、merge operator 支持、可选 zstd 压缩，以及 CRC 校验保障数据完整性。项目目前仍处早期阶段，但存储格式和公开 API 已基本稳定，崩溃恢复经过测试。该项目起源于开发者此前用 Rust 编写的文件系统 junkfs，因元数据管理需要事务支持却找不到合适的存储方案，在研读 leanstore 与 photondb 的源码及相关论文后决定自行实现。性能方面，在 relaxed durability、16 字节键/128 字节值、100 万条数据的测试条件下，Mace 与 RocksDB 对比：读多写少场景达到每秒 294 万次操作，约为 RocksDB 的 2.67 倍；zipf 分布下达 2.88 倍；均衡读写为 1.97 倍；写密集场景为 1.49 倍；纯 scan 场景为 1.62 倍。作者坦言在读多写少和扫描场景优势明显，写密集场景优势缩小。后续规划包括自定义 comparator，重点将转向稳定性与细节打磨。
事件分析
从技术路线看，Mace 选择 Bw-Tree 作为索引结构，试图绕开 B+ Tree 与 LSM Tree 的传统取舍，这一思路与微软数据库内核的探索一脉相承，配合 MVCC 与 value 分离等工业界成熟设计，架构选择较为稳健。性能数据需注意测试前提：relaxed durability 模式下读性能领先 2 到 3 倍具有参考价值，但写密集场景差距收窄至 1.5 倍，且缺少与其他主流方案的交叉对比。产业层面，该项目折射出 Rust 在系统级存储软件中的持续渗透——随着 sled 停止维护、RocksDB 绑定笨重难嵌，社区确有对轻量原生方案的需求。挑战在于存储引擎的价值验证周期极长，空间回收、故障处理、运维生态等细节往往决定生产可用性，单作者项目的可持续投入是最大变数。短期内更适合作为学习参考与特定场景选型，长期前景取决于能否形成社区反馈循环。
核心观点：当 sled 沉寂、RocksDB 臃肿难嵌，独立开发者正用 Rust 在存储引擎的缝隙处证明单点性能突围的可能。
原文链接：V2EX 分享发现
