换掉 RocksDB：81 万行 C++ 换成 2MB Rust crate，新建快 26.8 倍

一、同一个开关，一边掉 70 倍，一边只掉 1.4 倍

2026 年 10 月 13 日，SurrealDB 放出 SurrealKV 1.0——Apache 2.0 许可、纯 Rust 写的嵌入式存储引擎。官方博客的副题毫不含糊：它将成为 SurrealDB 4 里唯一的持久化存储引擎。也就是说，跑了多年的 RocksDB 要退场。

先看一组对照，它比"快几倍"更值得琢磨。官方口径是 50 万个键、48 个写入线程、128 个并发客户端，只改测试工具上的一个开关——要不要同步落盘（每次提交返回之前，数据必须已经落到盘上）：

• RocksDB 打开它，新建吞吐从 603,452 OPS 掉到 8,568 OPS，掉了 70.4 倍

• SurrealKV 打开它，新建吞吐从 321,715 OPS 掉到 229,376 OPS，只掉 1.4 倍

这不是给两个引擎排先后，是两种引擎对"落盘"这件事的态度差了一个数量级。而站着被换掉的那一位，是嵌入式存储里的事实标准：facebook/rocksdb 仓库 32,198 星、6,961 个 fork、14,200 次提交，从 MySQL 到 TiKV 的底座里都藏着它。

接棒的那位还很年轻：surrealdb/surrealkv 仓库目前 600 星、45 个 fork、477 次提交，Apache 2.0 协议，免费开源，在 crates.io 上累计下载 114 万次。

引擎

点读 OPS

新建 OPS

更新 OPS

删除 OPS

扫描 OPS

SurrealKV

6,804,864

229,376

221,341

264,089

905,132

RocksDB

855,851

8,568

36,263

32,043

852,661

SlateDB

92,303

8,257

8,122

8,242

17,985

上面这张表是官方 README 里的同步落盘口径——三家都在返回前刷盘，是唯一能横向比的一张表。测试机是一台 AMD Ryzen Threadripper 9970X，32 核 64 线程，128 GB 内存，4 TB 的 PCIe 4.0 固态盘；对比的 RocksDB 是 11.0.0。换算一下：6,804,864 次点读分摊到 50 万个键上，等于每秒把整个库从头到尾点读 13.61 遍；RocksDB 是 1.71 遍。差 7.95 倍，和官方口径一致。

二、换掉之后，那个 C++ 库去哪儿了官方给的理由只有一句

SurrealDB 说得很干脆：RocksDB 是一个非常好的引擎，我们在它上面跑了很多年；但它同时是一个我们控制不了的、巨大的 C++ 库。而 SurrealKV 是一个能从第一行读到最后一行、需要改就改、还能作为 Rust crate 发出去的引擎。

"控制不了"这四个字，在依赖树上是能称出重量的。把两个 crate 从 crates.io 上拉下来解包，逐个数字对一遍，就能看到官方博客里没有的那部分。

口径

surrealkv 1.0.0

rocksdb 0.25.0 那条路

crate 下载体积

2,083,523 字节

7,810,821 字节

解包后占用

7.9 MB

40 MB

直接运行期依赖

23 个

2 个（libc、librocksdb-sys）

构建脚本

无（Cargo.toml 里 build = false）

build.rs 534 行

构建设备要求

只需 Rust 工具链

需要 bindgen、cc、rustflags、C/C++ 编译器

随包的 C/C++ 源码

0

1,294 个文件 / 819,789 行

语言语法层代码

190 个 .rs 文件

2 个 .rs 文件 / 126 行

最后两行是这篇文章里最值得盯的一对数：Rust 侧那层封装只有 126 行，而它背后跟着 81 万行 C/C++。这就是"控制不了"的物理形态——你的构建能不能过，取决于对面那 81 万行在新编译器、新架构上能不能编过。

那 26.8 倍是怎么来的

官方给了三条设计决定，每一条都在从热路径上拿掉一处"共享的活"或"共享的等"。

一是 memtable 换成自适应基数树。写入落在并发基数树里，内存从一个固定的 arena 分配。RocksDB 和 Pebble 在这一层用的是跳表。

二是提交环。大量提交者同时做事务校验，然后由一个 flusher 任务把攒下来的东西归成一组、编号、一次性追加到预写日志（最多一次 fsync）、应用到 memtable、再按序发布。一串并发提交，只付一次日志追加的代价。官方给的量级是：环上 65,536 个槽位，同时在飞的最多 32,768 笔提交，一组最大 4 MiB。

三是读便宜。一次读只 pin 住一个序列号，除此之外什么都不占。

对照组

点读

新建

更新

删除

扫描

RocksDB（同步落盘）

7.95×

26.77×

6.10×

8.24×

1.06×

SlateDB（同步落盘）

73.72×

27.78×

27.25×

32.04×

50.33×

RocksDB（不同步落盘）

8.26×

0.53×

0.45×

0.42×

1.05×

表里的倍数是 SurrealKV 除以对方，大于 1 是 SurrealKV 快，小于 1 是对方快。最后一行先记住，辩证那节要用。

顺手带上的四件事

除了换引擎，这个版本还把几件过去要自己搭的东西做进了引擎里。

按时间读。打开版本化之后，每次写入带上自己的时间戳，get_at 能读某个键在某时刻的值，history 能把这个键的全部版本按时间倒序列出来，compaction 按你设的保留期决定留多久——设 0 就是永久保留。官方强调它不需要额外的时间索引，也不占值日志，代价是每个版本多 8 个字节。

值与键分离。打开这个选项之后，超过 1 KiB 的值会搬到独立的日志里，compaction 只搬键和指针，不用一遍遍重写大值。这是 WiscKey 那篇论文的做法，默认关闭。另有一项默认开启：清单文件、SSTable、值日志、预写日志全部透明加密，算法可选 AES-256-GCM 或 XChaCha20-Poly1305。

每次 CI 都跑一遍差分测试。引擎和一个内存里的参考模型接受同一串动作——开始事务、写入、删除、范围删除、保存点、回滚、读、提交、范围扫描、刷日志、重启——任何一次读、扫描、提交判定或重启后的完整状态对不上，整轮就判失败。每一轮跑 500 个随机种子、每个种子 5,000 步，合计 250 万次操作。

这些设计写在一份 14 页的论文里，题为《A Versioned LSM Engine with Radix-Tree Memtables and a Commit Ring》。论文开头就自己划清界限：底层技术都不算新，贡献在于怎么把它们拼在一起、这个组合要付什么代价、以及测了什么没测什么。

自己跑一遍要敲的命令

官方把这些数字压缩成了一条命令。想在自己机器上复现，去 github.com/surrealdb/crud-bench 拉下测试工具：

CRUD_BENCH_CONFIG=config/memory.toml ./run.sh -d surrealkv --no-build --optimised --sync -s 500000 -c 128 -t 48

把 -d 后面的名字换掉就跑对照组，去掉 --sync 就是不同步落盘那一轮。想在自己的 Rust 工程里用它，只要一行：

cargo add surrealkv

use surrealkv::TreeBuilder;#[tokio::main]async fn main() -> Result<(), Box> {// 打开或新建一个库let tree = TreeBuilder::new().with_path("data/mydb".into()).build()?;// 写事务let mut tx = tree.begin()?;tx.set(b"user:001", b"Alice")?;tx.set(b"user:002", b"Bob")?;tx.commit().await?;// 读事务let tx = tree.begin()?;if let Some(val) = tx.get(b"user:001")? {println!("Value: {}", String::from_utf8_lossy(&val));tree.close().await?;Ok(())

有一个默认值要先改，才会拿到上面那些数字：提交默认走 Durability::Eventual，也就是交给操作系统但不 fsync。要每次提交返回前就落盘，得在 commit() 之前调一次 tx.set_durability(Durability::Immediate)。

三、官方自己写下来的坏消息，比成绩单更值得读

这篇发布最特别的地方，是它把自家引擎的短处一条条列了出来。

第一件：不开同步落盘时，RocksDB 写得更快。新建 0.53 倍、更新 0.45 倍、删除 0.42 倍——RocksDB 是 SurrealKV 的近两倍到两倍半。官方的解释是：没有 fsync 可以摊薄，那套分组管线就没有东西可省了；而 flusher 仍然只有一个人在往 memtable 里插，插入这一环只跑在一个核上。官方还补了一句：我们没测过这就是上限。

第二件：26.8 倍这个数字，官方自己不肯拿它当标题。RocksDB 同步落盘的新建是 8,568 OPS，但它自己同步落盘的更新是 36,263 OPS——同一个引擎、同一份负载，新建比更新慢 4.23 倍，这在存储引擎里是不正常的。官方的处理方式值得所有写技术稿的人学：他们说"RocksDB 的同步新建远低于它自己的同步更新速率，我们没有解释为什么，所以这篇文章不把它放进标题"。一个连自己都解释不了的数字，宁可不当卖点。

第三件：扫描不是它的地盘。在整条数据的 limit 扫描上，LMDB 快 1.33 倍；跳 5,000 条再取 100 条的扫描，LMDB 快 5.70 倍；全量 count，LMDB 快 2.24 倍。原因是结构性的：LMDB 是写时复制的 B+ 树，一次扫描只走一棵树；LSM 树要合并好几个有序 run。这条差距官方在论文里写进了"哪里不合适"。

第四件：静息内存最低，峰值内存不是。官方给了一张七家对照表：

引擎

静息内存

峰值内存

SurrealKV

221 MiB

1.79 GiB

RocksDB

590 MiB

1.02 GiB

SlateDB

265 MiB

2.73 GiB

Fjall

627 MiB

1.71 GiB

ReDB

257 MiB

2.17 GiB

LMDB

776 MiB

826 MiB

静息 221 MiB 是七家里最低的，比 RocksDB 的 590 MiB 少 62.5%；但峰值 1.79 GiB 高过 RocksDB 的 1.02 GiB——官方归因于并发提交要缓冲活跃批次。同一份表里还有个失控数字：libmdbx 在完全不同步的模式下峰值吃到 117.71 GiB，官方的措辞是"这是测试工具量到的，我们没有去查"。

最该被记住的一段在论文的局限清单里，一共十一条。摘几条：只有快照隔离，没有串行化模式，扫描不参与校验，因此跨键的写偏斜是可能的；应用到一个组是单线程，日志追加也跑在 flusher 上；同一时间只跑一个 compaction；版本化树一项基准都没做过；值日志只能按文件前缀回收空间，一个长期存活的大值会拖住它后面所有文件；加密只能在建库时选，已经存在的库加不上；段中间出现损坏就打不开，唯一出路是"抢救模式"——保留有效前缀、丢弃后面全部内容。

还有一条最朴素：所有数字都是单次运行。论文自己写着，跑动之间的波动没有被测量，小的差距不应该被读成排序。这句自陈，应该贴在每一张性能对照表的下面。

四、对一个写 Rust 的人来说，这条路的成本变了

过去在 Rust 里要一个嵌入式 KV 引擎，绕不开那个 C++ 依赖：为了 126 行 Rust 封装，得把 bindgen、cc、一群 -sys 包和 81 万行 C/C++ 一起拖进构建流程，还要盯着新架构、新编译器能不能编过。现在多了一条纯 Rust 的路，包的体积是 2.08 MB 对 7.81 MB，构建脚本是零行对 534 行。

迁移这件事它想得比多数引擎周全：打开一个旧的 SurrealKV 0.20 / 0.21 库，或者一个 SurrealDB 写出来的 RocksDB 8 到 11 库，它会自动转换——读 RocksDB 那部分是纯 Rust 实现的，不需要链接 RocksDB。但转换是单向的：原文件只是移进库里的备份目录，那个备份不是回滚点（值日志是共用的），而且被这个版本打开过的库，旧版本再也打不开。要留后路，先自己拷一份目录。

你的场景

判断

点读为主 + 大量小的并发持久写

它的主场，分组管线就是为这个建的

需要按键读到某个时间点的历史版本

版本化树自带，不用额外索引

需要串行化隔离级别

不合适，只有快照隔离

整个负载都不开同步落盘

不合适，RocksDB 写得更快

扫描为主

不合适，LMDB 更快

构建链要极简、不想碰 C++

主要收益就在这儿

五、最后一问

SurrealDB 这次换引擎，逻辑上最硬的一句不是"快 26.8 倍"，而是"这是一个我们能从头读到尾的引擎"。性能可以靠硬件和参数追，编译不过的库追不回来。

所以留一个问题：如果你手上有 81 万行你读不完、也改不动的第三方 C++ 代码，你会等到它哪天在新编译器上编不过才动手，还是提前准备一条自己的路？