HydraDB：图数据库住在 S3 里，计算节点用完即弃

GitHub: hydra-db/hydradb ｜ Rust 1.91+ ｜ AGPL-3.0 ｜ OpenCypher TCK 通过

数据库领域这几年有一个明显的趋势——存储和计算 disaggregation（解耦）。Snowflake 把这个理念带火了：数据存在 S3 上，计算节点按需启动，用完就扔。但这个理念一直没真正渗透到图数据库领域——Neo4j 是存算一体的，TigerGraph 也是，图数据库似乎天然需要"数据在本地 SSD 上才能快速遍历"。

HydraDB 想做的事情是证明：图数据库也可以存算分离，而且不牺牲查询性能。

场景：图遍历为什么"需要"本地存储

先说为什么图数据库一直没做存算分离。

关系型数据库的查询是"扫描一批行"，顺序读为主，S3 的吞吐完全够用。图数据库的查询是"从一个节点出发，沿着边跳 N 跳"——每跳一次都是一次随机访问。S3 的随机访问延迟在 10-50ms 级别，而本地 NVMe 是 0.1ms 级别。差两个数量级。

这意味着如果图数据存在 S3 上，每次图遍历都会被 S3 的延迟拖死。这就是为什么 Neo4j 要求数据在本地磁盘上——不是设计偏好，是性能刚需。

HydraDB 的解法是预构建不可变遍历索引。不是在查询时做随机访问，而是在写入时就构建好遍历用的稀疏矩阵索引（CSC 格式），存在 S3 上。查询时计算节点把索引拉到本地 SSD 缓存，遍历在本地完成——速度接近原生图数据库。

两种角色：Data Node 和 Indexer

HydraDB 的架构有两个独立的计算角色：

Data Node（graph-node） 负责查询和写入。它从 S3 读取数据块和索引到本地缓存，查询在本地缓存上执行。Data Node 的本地状态是"可丢弃的"——关掉一个 Data Node 不会丢数据，因为 S3 才是 source of truth。重启后从 S3 重建缓存即可。

Indexer（graph-indexer） 负责在后台构建遍历索引。当新数据写入后，Indexer 把最新的图结构编译成不可变 CSC 矩阵，推到 S3 上。查询时 Data Node 会同时读取"已编译的索引"和"尚未编译的 WAL 增量"，合并后给出一致的结果。

这个设计的关键在于——Indexer 也是可丢弃的。Indexer 挂了不影响查询，只是新写入的数据暂时不会被编译进索引。Indexer 重启后从上次的位置继续。

两个角色独立扩展：查询密集时多起 Data Node，写入密集时多起 Indexer。S3 上存的是同一份数据。

SlateDB：对象存储上的 LSM-Tree

HydraDB 底层用了 SlateDB——一个把 LSM-Tree 跑在对象存储上的存储引擎。传统 LSM-Tree 的 WAL 和 SSTable 都在本地磁盘上，SlateDB 把它们放到 S3 上。

这带来一个直接好处——写入的持久性不依赖本地磁盘。Data Node 接收写入后，WAL 直接写 S3，本地只保留内存中的 MemTable。Data Node 崩溃时，未刷盘的数据在 S3 的 WAL 里，不会丢。

SlateDB 的 writer epoch 机制解决了"多个 Data Node 同时写"的问题——通过对象存储的 CAS（Compare-And-Swap）租约选举当前活跃 writer，旧 writer 被 fence 住无法继续写。这和 Spanner 的 Paxos 组机制类似，但跑在 S3 上而非分布式共识协议上。

GraphBLAS：图遍历的线性代数化

HydraDB 的遍历引擎用了 SuiteSparse GraphBLAS——把图遍历转化为稀疏矩阵运算。

图遍历的本质是矩阵乘法：邻接矩阵 A 乘以向量 v（起点向量），得到的就是"一跳邻居"。再乘一次就是"两跳邻居"。GraphBLAS 把这个数学事实变成了工程实现——图遍历不用 follow edge pointer，而是做矩阵乘法。

好处是：矩阵乘法有成熟的优化库（SIMD、GPU 加速），比指针追踪快得多。而且 GraphBLAS 的稀疏矩阵格式（CSC/CSR）天然适合压缩存储在 S3 上——稀疏图的矩阵本身就是稀疏的，压缩比很高。

HydraDB 的查询规划器会根据查询模式选择策略：属性索引、反向邻接、稀疏遍历、GraphBLAS 矩阵运算，按需组合。

OpenCypher 和 Bolt 协议兼容

HydraDB 支持两种查询接口：

• OpenCypher：Neo4j 的查询语言标准，通过了 OpenCypher TCK（Technology Compatibility Kit）测试。这意味着现有 Cypher 查询可以直接跑在 HydraDB 上
• Bolt 协议：Neo4j 的二进制协议，5.x 版本。现有 Neo4j 驱动可以直接连 HydraDB

兼容性的价值在于迁移成本——一个跑着 Neo4j 的应用，改个连接字符串就能指向 HydraDB，查询语句不用改。对于想从 Neo4j 迁移到云原生架构的团队来说，这是最低成本路径。

和其他图数据库的定位差异

• Neo4j：存算一体，单机或因果集群。适合中小规模图，本地性能最强
• TigerGraph：MPP 架构，分布式但存算一体。适合大规模图，运维复杂
• Memgraph：内存图数据库，亚毫秒延迟但容量受内存限制
• HydraDB：存算分离，S3 持久化，计算节点可丢弃。适合云原生部署和弹性扩展

HydraDB 的定位不是"比 Neo4j 快"——在单机场景下 Neo4j 仍然更快。HydraDB 切的是另一个维度：当你的图数据量大到一台机器装不下，且查询负载有明显波峰波谷时，存算分离的弹性比单机性能更重要。

一个 100 亿条边的图，Neo4j 需要一个昂贵的集群来存，扩容时要搬数据。HydraDB 存在 S3 上，查询时按需起 Data Node，不用时关掉——只付 S3 存储费。

谁该关注

• 图数据库重度用户：如果图的规模在增长，且运维 Neo4j 集群的成本在上升，HydraDB 的存算分离模型值得评估
• 云原生架构师：HydraDB 是"数据库存算分离"理念在图领域的实践，架构设计（Data Node + Indexer + S3）值得研究
• Rust 基础设施开发者：HydraDB 用 Rust 1.91+ 写的，SlateDB + GraphBLAS 的组合是 Rust 在基础设施领域的又一个案例
• 需要合规审计的团队：S3 上的数据天然支持版本化（S3 Object Versioning），审计需求可以靠对象存储的原生能力满足

一个值得注意的细节：HydraDB 的 benchmark 页面是 live 的（https://hydra-db.github.io/benchmark/），不是论文里的静态图。这意味着团队在持续维护性能数据，而不是发完论文就不管了。

GitHub: https://github.com/hydra-db/hydradb