随着区块链逐渐成熟，性能挑战也在发生变化。早期阶段，系统优化通常集中在共识、执行与网络层。但随着吞吐量不断提升，系统进入真实世界中的持续运行阶段后，新的瓶颈开始显现，并逐渐成为主要限制因素。

在 Sui 中，我们经常在私有集群环境下进行大规模压力测试，以确保随着协议演进，系统仍然能够达到性能目标。这些测试不仅用于衡量峰值吞吐量，也用于提前发现未来可能出现的系统瓶颈信号。其中一个信号变得越来越明显：即使在配备多块 SSD 并采用 RAID-0 配置的高性能验证节点硬件上，磁盘 IO 利用率也比其他系统资源更早接近饱和。

虽然磁盘当时还未成为真正的限制因素，但这一趋势十分清晰。如果 Sui 要在长时间运行中持续支持高吞吐量，就必须提升存储效率。因此，我们没有等到磁盘成为硬性瓶颈，而是选择提前构建新的存储基础设施。

这一基础设施就是 Tidehunter —— 一个专为现代区块链的性能边界、数据访问模式以及实际运行需求而设计的存储引擎，并有望成为未来 Sui 验证节点与全节点所采用的新一代数据库系统。

为区块链量身打造的架构设计

与大多数区块链系统一样，Sui 最初采用 RocksDB 作为主要的键值数据库。这是一个务实的选择。RocksDB 被广泛使用、成熟可靠，也让团队能够将精力集中在协议本身的开发与落地上。

 RocksDB：https://rocksdb.org/

然而，随着 Sui 不断扩展并增加新功能，我们逐渐遇到一些问题，这些问题并非通过参数调整或简单优化就能解决，而是源于通用 LSM-tree 数据库架构与区块链工作负载之间的结构性不匹配。我们花了大量时间优化 RocksDB 参数，团队中也有成员对其内部机制拥有深入经验，但即便如此，一些效率问题仍然无法避免。

此时我们意识到，如果想持续领先真实世界的性能需求，就需要采取不同的路径。与其继续受限于现有开源数据库设计的框架，我们决定探索一种专为区块链工作负载打造的定制存储引擎应该是什么样子。

Tidehunter 正是在这一探索过程中诞生的。

核心限制：写入放大

我们在 RocksDB 中观察到的最严重问题是写入放大。在接近 Sui 生产环境的负载下，我们测得写入放大倍数大约在 10–12 倍之间。换句话说，应用层每秒写入约 40 MB 数据时，磁盘实际需要写入 400–500 MB/s。虽然这个数字看起来很夸张，但对于基于 LSM-tree 的数据库系统来说并不罕见，其他部署环境中甚至常见更高的放大倍数。

LSM-tree：https://en.wikipedia.org/wiki/Log-structured_merge-tree

其影响很直接，但也十分严重：写入放大会让机器性能“缩水”。当写入放大达到 10 倍时，只有约 10% 的磁盘带宽用于真正的业务数据写入，剩余 IO 带宽都被内部数据重写和 压缩消耗，并与读取操作争夺 SSD 带宽资源。

而区块链系统的负载通常以写入为主，或者读写接近 50/50，随着吞吐量提升，这种权衡带来的成本会迅速放大。

来自压力测试集群的早期信号

在深入 Tidehunter 的设计之前，有必要先看一下我们在真实测试中的观察结果。即使在配置高端硬件的测试集群中，在持续负载情况下，磁盘 IO 利用率也接近饱和。应用层的写入量其实并不算高，但操作系统报告的磁盘写入吞吐量却高出一个数量级，这正是写入放大的直接体现。

这些早期信号促使我们开始重新思考并重构整个存储层架构。

Sui 及类似区块链中的存储模式

Tidehunter 的设计围绕着少数几种主导 Sui 以及许多区块链系统的访问模式展开。

首先，许多数据表使用均匀分布的随机键，并存储相对较大的数据值。交易、执行结果以及对象通常以加密哈希值作为键，这虽然消除了数据局部性，但在一致性与正确性方面更容易保证。

其次，区块链高度依赖顺序或半顺序的日志型结构，例如共识区块和检查点数据。这类数据通常以追加写入（append-only）为主，而读取则通过单调递增的索引进行定位。

最后，区块链工作负载通常是写入密集型，同时关键路径上仍存在显著的读取压力。在这种环境中，过高的写入放大不仅浪费磁盘带宽，还会直接削弱系统提供低延迟读取的能力。高吞吐、低争用的写入路径Tidehunter 的核心之一，是一条能够充分利用现代 SSD 性能、同时避免资源争用的写入路径设计。所有写入都会通过一个超高速、无锁（lock-free）的预写日志（write-ahead log ，WAL），其处理能力可达到每秒约百万级操作。

写入流程被拆分为三个阶段：空间分配、数据复制和确认。其中只有空间分配阶段会产生轻微争用，而且成本仅限于一次原子计数器更新。数据复制则在多个写入线程间并行执行，使吞吐量能够随并发度线性扩展。

为了减少关键路径上的系统开销，Tidehunter 使用可写内存映射文件（memory-mapped files）替代每次写入都进行系统调用。数据持久化则由后台服务线程异步完成，负责文件扩展与周期性同步。最终形成的写入路径具有高度并行性，在持续负载下性能可预测，并且能够充分利用磁盘吞吐能力，同时避免 CPU 成为瓶颈。通过架构设计从根本上减少写入放大在 Tidehunter 中，降低写入放大是首要设计目标，而不是事后优化。不同于将预写日志仅作为临时缓冲区，Tidehunter 将预写日志直接复用为永久存储。数据值只写入一次，之后不再复制；索引仅引用日志中的偏移位置。这一设计本身就消除了大量重复写入。

随后，索引空间被高度分片处理，每个数据表默认包含数千个分片。这不仅显著降低了单个分片的写入放大，还实现了高效的读写并行。在实践中，这也使系统不再需要依赖 LSM-tree 结构。

对于以追加写入为主的数据表，例如检查点和共识数据，Tidehunter 采用专门的分片策略，将最新写入数据集中放入少量分片中。由此带来一个关键特性：即使历史数据不断增长，写入放大也不会随数据规模扩大而增加。用于低延迟读取的均匀查找索引对于使用均匀分布哈希作为键的数据表，Tidehunter 使用一种专门设计的均匀查找索引来降低关键路径上的读取延迟。与执行多次随机、小规模索引读取不同，该索引利用均匀分布键的统计特性，预测目标数据最可能所在的位置，并读取稍大的一段连续索引区域，从而在单次磁盘访问中几乎总能找到所需数据。

这种设计有意以读取吞吐量为代价换取更低的读取延迟。在区块链负载中，这种权衡通常是合理的。由于 Tidehunter 大幅消除了写入放大，原本被内部数据重写占用的磁盘带宽可以释放出来用于读取操作，从而允许通过略微增加单次读取数据量来显著降低尾部延迟。

对于延迟敏感路径，例如交易执行、对象访问以及状态验证，启用均匀查找索引可以减少磁盘往返次数，并在持续高负载情况下保持读取延迟的稳定性。Direct IO 与用户空间缓存为了在大规模运行环境下减少读取延迟，Tidehunter 结合使用 Direct IO 与应用层感知缓存，而不是依赖操作系统的页面缓存。

Direct IO 允许 Tidehunter 在读取大型历史数据集时绕过操作系统缓存，从而减少缓存污染，并提升延迟的可预测性。同时，Tidehunter 为近期数据维护自身的用户空间缓存，在这里系统能够更好地理解访问模式，并做出更合理的数据淘汰决策。

这种方式与 Tidehunter 的索引策略形成良好配合，能够减少查询所需的磁盘往返次数。在实际运行中，这带来了更低的尾延迟，并更高效地利用可用磁盘带宽。高效清理历史数据验证节点通常只保留有限时间窗口内的历史数据，例如最近若干个 epoch 的交易记录。Tidehunter 让这些历史数据的清理过程变得简单而高效。

由于数据直接存储在预写日志日志段中，当数据不再需要时，只需删除整个日志文件即可。这避免了 LSM-tree 数据库中为了回收空间而进行复杂且 IO 开销巨大的压缩过滤操作。

因此，即使数据规模非常庞大，大规模数据删除也可以变得快速、可预测，并且在运维上更加简单。

性能结果

在一系列模拟 Sui 实际访问模式的工作负载测试中，Tidehunter 相比 RocksDB 持续展现出更高吞吐量和更低延迟，同时显著减少磁盘带宽消耗。最直观的提升来自几乎消除写入放大效应：磁盘写入吞吐量与应用层写入量基本保持一致，为读取操作释放出大量 IO 空间。随着负载提升，这意味着性能更加稳定、尾延迟更低，同时因 IO 饱和导致的停顿显著减少。

这些性能提升不仅体现在可控环境下的基准测试中，也同样体现在完整的 Sui 验证节点运行中，说明这些改进并非来自合成测试环境的偶然结果，而是在端到端系统运行中同样有效。

人工基准测试

为了在可控且可重复的环境中评估 Tidehunter，我们构建了一系列专用数据库负载测试，用以模拟 Sui 中真实出现的访问模式。测试目标并非单独评估某些底层操作，而是通过插入、删除、点查询以及迭代等操作的组合，模拟验证节点与持久化状态交互的真实场景。

该基准测试框架与具体数据库无关：任何实现一组核心操作接口的存储引擎都可以在相同负载下接入并进行评估。借助这一框架，我们在多种配置下将 Tidehunter 与 RocksDB 进行比较，包括启用和未启用 blob store 的 RocksDB 配置，从而能够分别观察写入放大、数据存放方式以及索引策略等设计差异带来的影响。

虽然测试负载为人工生成，但参数设置参考了 Sui 的真实特征，包括读写比例、键分布以及数据大小等。同时，所有测试均在接近 Sui 推荐验证节点配置的硬件环境上运行，以确保测试结果贴近生产环境，而不是理想化实验室条件。

在这些工作负载下，Tidehunter 持续表现出比 RocksDB 更高的吞吐量与更低延迟，同时消耗的磁盘写入带宽显著更低。这种优势在写密集或读写均衡的场景中尤为明显，因为写入放大的减少为读取操作释放出更多 IO 资源。

Sui 验证节点基准测试

为了验证这些性能改进能够在真实环境中发挥作用，我们将 Tidehunter 直接集成到 Sui 中，并在持续交易负载下运行验证节点基准测试。

所有验证节点在实验开始时均使用 RocksDB，并在 12:30 时切换至 Tidehunter。在使用 RocksDB 运行 Sui 时，我们观察到，当吞吐量达到约每秒 6,000 笔交易时，随着磁盘利用率升高，延迟开始上升，系统性能出现明显下降。而在相同条件下，Tidehunter 能够维持稳定吞吐量与更低延迟，同时磁盘压力更小，CPU 利用率也更加稳定。

对比运行结果清晰显示出磁盘读写吞吐量、持续 TPS 以及交易最终确认延迟方面的差异。特别是，在相似负载条件下，Tidehunter 能够避免 RocksDB 配置中因 IO 饱和而导致的性能崩溃问题。

展望未来

Tidehunter 并非一项学术实验，而是针对高性能区块链长期运行现实需求所作出的实际工程回应。

随着吞吐量持续提升，负载模式从突发型转向长期持续运行，存储效率将成为协议层面的关键因素。通过 Tidehunter，我们相信 Sui 已经为下一阶段的规模扩展提前做好准备，拥有专为未来规模需求打造的存储基础设施。

Tidehunter 的设计目标正是面向区块链的下一阶段规模发展，在这一阶段，持续性能将取决于存储效率。