HydraDB：图数据库住在S3里，计算节点用完即弃
GitHub: hydra-db/hydradb ｜ Rust 1.91+ ｜ AGPL-3.0 ｜ OpenCypher TCK 通过
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：存算一体，单机或因果集群。适合中小规模图，本地性能最强
- TigerGraph：MPP 架构，分布式但存算一体。适合大规模图，运维复杂
- Memgraph：内存图数据库，亚毫秒延迟但容量受内存限制
- HydraDB：存算分离，S3 持久化，计算节点可丢弃。适合云原生部署和弹性扩展
一个 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），审计需求可以靠对象存储的原生能力满足
*GitHub: https://github.com/hydra-db/hydradb*