SpacetimeDB:横向扩展的真相与代价

Ok, but Does It Scale?

SpacetimeDB:横向扩展的真相与代价

横向扩展真的是万能药吗?很多人认为只要增加机器就能解决所有性能问题,但事实往往相反。文章深入剖析了计算、存储和网络这三个扩展维度,对比了 Postgres、Neon 和 CockroachDB 的架构差异。特别指出,像 CockroachDB 这样的分布式数据库虽然理论上能全维度扩展,但在面对高并发冲突时,巨大的协调开销反而导致性能断崖式下跌。有时候,单机方案在特定场景下比分布式集群更高效。SpacetimeDB 旨在通过工具帮助开发者在保持高性能的同时,轻松扩展可并行化的 OLTP 工作负载。

反直觉的是,在这种场景下,单线程解决方案的‘可扩展性’竟然是分布式集群的 300 倍!
  1. timssopomo

    Spacetime 听起来确实是一项非常有趣的技术,但我不确定它与 CRDB 的对比是否恰当。

    我曾在 Cockroach Labs 工作过。它要解决的问题在根本上是不同的。当你需要_保证_事务是可序列化的且持久化的,并且你的应用能在节点或区域故障时维持一致性并存活下来时,CRDB 作为一个解决方案才有意义。在朴素的部署中,它的速度明显慢于单核运行,但这就是你为“在节点丢失时不丢数据”这一能力所付出的代价。

    我没看到任何迹象表明 Spacetime 是如何解决 CRDB 所解决的核心问题的,即保证在单节点故障时能实现零数据丢失或零可用性损失。听起来默认情况下事务必须在完成前写入磁盘,这使其在单节点上是持久化的,但如果不接受网络开销并牺牲事务吞吐量(至少是写入方面),你就无法确保跨节点的一致性。

    另外,顺便提一下,在我负责处理几乎所有故障的几年里,我记不起见过哪个集群是受限于网络的。就像其他东西一样,这里存在权衡。你牺牲吞吐量,换来一致性和可用性,同时无需费力去设计如何避免节点故障导致的数据丢失或可用性丧失。除非我理解错了,否则 Spacetime 解决的完全是另一个问题。

  2. echohack5

    作为一个在侧项目中大量使用 Spacetime 的人(比如 https://heat.echohack.app),我对其运行速度始终印象深刻。

    我认为数据库领域正在发生许多有趣的事情。Vitess/Neki、向量数据库、Spacetime 都是非常好的进展。遗憾的是,数据库开发者似乎总有一段充满戏剧性的时间线。这……一切都很令人兴奋,而且是一起发生的。

    总之,有一些需要改进的地方(其中一些在本博客文章中已提及):

    1. 备份(快速恢复)和灾难恢复(慢速、持久化恢复)

    这是一个大问题,但有时速度并不是你唯一需要达成的目标。你需要确信,如果一切崩溃,你(最终)能够恢复上线。目前我还没有办法做到这一点。

    2. 对于分析型工作负载,读副本肯定会很实用

    3. 对于间歇性突发工作负载(如 CI 系统),能够持久化写入 S3 会很棒

    我认为 Spacetime 团队的任务艰巨,这未必是因为技术本身(那确实很难),而是因为 AI 模型似乎已经认定只有 Neon 和 Postgres 存在。

    我认为 Spacetime 前途光明,我祝愿团队在努力将新事物印刻在宇宙中时一切顺利。

  3. themgt

    > 你可以将服务器逻辑直接部署到数据库中

    > 只要你的应用或服务在生产环境中使用的 SpacetimeDB 实例不超过一个,且未将许可作品用于数据库服务,你就可以使用提供的许可作品。

    因此,作为一款开源产品,SpacetimeDB 无法扩展。

  4. AdamProut

    引言部分很好地总结了为什么分布式 SQL 数据库(Spanner、roach、Yugabyte、TiDB)未能像分布式数据仓库(Snowflake、Databricks、FabricDW、Clickhouse 等)那样在市场上普及。

    我会在扩展问题列表中再补充几点。某些 SQL 特性很难横向扩展(auto_increment/serial 列、唯一二级索引、外键等)。某些 SQL 查询算子对于追求低延迟和高吞吐量的 OLTP 查询来说也很难扩展(DISTINCT、LIMIT/TOP-N、非共置连接)。我推测 SpacetimeDB 是一个 NoSQL 数据库,所以这些问题对他们来说没那么重要?

    至于 SpacetimeDB 计划如何扩展,我没完全看懂。很难把 SpacetimeDB 团队的话当真(参见:https://strn.cat/posts/spacetime/)。

  5. chermi

    跑题了,但……我有一个朋友,他在 SEAS 项目期间参加哈佛迷你 MBA 时,得出的主要结论(半开玩笑地)是:只要在 VC 或科技导向的商务人士面前问这个问题,就能显得你很聪明。

    后来我们真的创办了一家初创公司,发现这其实不是一个愚蠢的问题。但也许当默认路径是 VC 融资时,这本身就有点循环论证了,嗯哼。

同日更多故事

2026-09-04