SpacetimeDB：简短技术评测

# SpacetimeDB：简短的技术回顾 来源：https://strn.cat/posts/spacetime/ 2026年2月26日 数据库市场环境严苛，对新入局者尤甚。推出新产品并脱颖而出已属不易，要想获得长期市场认可更是难上加难。本周早些时候，SpacetimeDB 推出了其数据库的 2.0 版本，采取了一种独特的方式——据我所知，这种做法前所未有：一段略带超现实（梗图风格）的视频，嘲讽竞争对手（喝着“对手的泪水”），以及一组好得令人难以置信（实际上确实不真实）且同样嘲讽其他数据库的性能基准测试。看看那个基准测试里“大输家”旁边可爱的小放大镜。你得“放大”才能看出他们有多差！干得漂亮。 对手的泪水！哈哈！这些家伙太差了！哈哈！ 坦率地说，我认为这种做法令人不快。但尽管如此，我认为这个产品有一些有趣的想法，我想在尽可能公平的前提下，对其做一次简短的技术回顾。 ## 基准测试 (https://strn.cat/posts/spacetime/#benchmarks) 数据库领域的新入局者常犯的一个错误，是相信可以通过拥有“最佳性能”来取胜。实践中我从未见过如此成功案例。（极少数）建立了可持续数据库服务的公司，是通过提供良好、扎实且经得起检验的技术工作来取胜的。当然，基准测试对展示技术实力*确实*有帮助。但基准测试本身*必须*是良好、扎实的技术工作。 SpacetimeDB 提供的测试不符合任何一项。它们在测量内容上存在相当多的技术缺陷。你可以在这里 (https://github.com/clockworklabs/SpacetimeDB/pull/4432) 看到另一组基准测试，在那里 SpacetimeDB 表现得*非常糟糕*。 尽管如此，这些基准测试最根本的问题在于其不诚实。我理解他们的想法，确实理解：他们不诚实是因为他们的数据库产品与竞争对手截然不同，这使得编写这样的基准测试极具诱惑力。他们的产品处于数据库领域的不同细分市场，却选择与采用不同权衡方案的数据库进行比较。这种比较很吸引人，但并不公平。 我举个我亲身经历的例子：几年前我在 PlanetScale 工作，我们发布了一个用于向量相似性搜索的 MySQL 扩展。我们的实现有非常特定的目标；它与市面上其他所有产品都不同，因为它完全支持事务，并且向量数据存储在磁盘上，由 MySQL 的缓冲池管理。这与更简单的、使用 HNSW 且要求相似性图必须完全加载到内存中的方法（如 `pgvector`）形成对比。这是一个非常不同的产品，采用了非常不同的权衡。当时，用一台拥有 32GB 内存的 EC2 实例，向我们的数据库中导入 64GB 的向量数据，极具诱惑力。然后对运行 `pgvector` 的 Postgres 实例做同样的操作。完全相同的机器，相同的数据集！执行相同的查询！但 PlanetScale 每秒能处理数万次查询，而 `pgvector` 完成单个查询就需要超过 3 秒，因为 HNSW 图不断在磁盘和内存之间分页交换。 在基准测试中展示这样的结果确实很吸引人。“我们比 `pgvector` 快 10000 倍！”。但是得了吧。这不诚实。是的，机器相同、数据集相同、查询也相同，但情况并不相同。我们没有发布那些基准测试；相反，我们发布了一份 (https://planetscale.com/blog/larger-than-ram-vector-indexes-for-relational-databases) 关于实现的详细技术分析，没有不公平的比较，这份分析获得了非常好的反响。 你不需要“疯狂的基准测试”才能在这一行取胜。你只需要扎实的技术工作和扎实的技术文档来解释你产品的权衡与限制。你可以看看 Turbopuffer (https://turbopuffer.com/) 的另一个例子。他们的基准测试并不特别亮眼，尤其是在与竞争对手比较时。他们的文档中讨论数据库*不能*做的事情的篇幅，比讨论它*能*做的事情的篇幅还要多。但所有人都知道，如果你的用例符合他们的产品，他们就是市场上最好的搜索产品。远超竞争对手。他们不喝竞争对手的泪水，只是默默地赢走客户。 总之，回到 SpacetimeDB 和他们的基准测试。他们的产品与竞争对手有**很大**不同！这是一个集数据库与应用服务器于一体的平台，你部署一个数据库实例，*你的应用程序代码就在数据库内部运行*。我认为这是一个非常有趣的想法。你可以说它就像关系型数据库中的存储过程，但拥有更好的开发者体验。没错。但这确实可以构建一个可行的产品！ 然而，你得承认，这与它进行基准测试所针对的多区域、高可用性分布式数据库几乎没什么关系。如果你的应用程序代码*在数据库内部*运行，而你的竞争对手有一个单独的应用程序，必须为每次查询执行单独的网络请求，那么是的，在测量 QPS（每秒查询数）的基准测试中，你应该领先。但这些是诚实的基准测试吗？*这种*比较是你想展示给评估你技术产品的潜在客户的吗？ 我认为这并非一个很好的亮点。从内存中访问数据比通过网络访问数据快，而你构建了一个基准测试工具来证明这一点。作为一个潜在用户，我*并未*留下深刻印象。我认为从营销角度来看，展示你能从内存中访问数据的速度，然后*解释*你为达到这些速度所做的权衡，会有趣得多。 据我了解，他们的网站上没有清晰的技术分析来解释这一点。那么让我们在这里尝试一下。 ## 存储 (https://strn.cat/posts/spacetime/#storage) SpacetimeDB 在他们发布的合成基准测试中显示出如此好的写入性能，有几个原因。显而易见的是，应用程序逻辑在数据库本地运行，以这种方式写入数据存储可以极其高效。他们还通过其他技巧（如批量写入）进一步提升了这种效率，但要达到他们展示的性能数字，你必须在*某些地方*走捷径：数据存储是内存型的，这与传统的 RDBMS 截然不同。 好消息是：对内存存储的写入是线性一致的。然而，也有一些坏消息。证明系统的线性一致性通常是一项艰巨的任务；我在这里不需要动用 TLA+ 就能证明。这里证明起来轻而易举。因为这个系统，嗯，就是一个前面加了锁的哈希表。 存储实现示意图 这听起来可能有些夸张，但请相信我，这确实相当准确地描述了该存储引擎的设计。SpacetimeDB 实例中整个数据库的已提交状态被包装在一个单独的读写互斥锁中。所有写操作都是顺序执行的，这确实是线性一致性的简单证明。两个写操作不能同时发生，因此它们不会冲突或竞争。但*读*和*写*也不能同时发生！ 如果写操作过多会发生什么？读者会饿死吗？在单一全局锁和读/写语义之上构建数据存储是一个有效的技术选择。将其宣传为“数据库”可能有点值得商榷。但在我看来，如果你打算全身心投入这种方法，如果这个锁将为整个数据库提供并发控制，你需要有非常明确、可定制的语义来优先处理读者和写者，以确保服务器在任何工作负载下都能保持响应。 在这种情况下，这种行为是一个实现细节，并没有被特别定义或解释。这个互斥锁是来自 `parking_lot` crate 的现成 `parking_lot::RWMutex`。它具有最终公平性，这意味着即使在高写入吞吐量场景下，读取者*最终*也会获得锁。不过，它们可能会被随机延迟，最多 0.5 毫秒。`parking_lot` crate 是 WebKit 原始 `WTF::Lock` 的 Rust 移植版——这个 2024 年的变更集 (https://trac.webkit.org/changeset/203350/webkit) 展示了那里是如何实现最终公平性的。你应该读读它，它有很多关于互斥锁竞争的真知灼见。把它当作这篇博客的清口菜吧。现在回到哈希表和锁。 那么，在这个系统中，写操作期间会发生什么？嗯，*任何事情*都可能发生。这确实非常神奇。当全局锁被持有时，Wasmtime (https://github.com/bytecodealliance/wasmtime) 运行时被用来执行“reducer”（编译为 WebAssembly 的任意用户代码）。当 reducer 执行时，其他 reducer 不能执行，也不能写入数据库。其他代码也不能*读取*数据库。根据他们的官方文档，reducer “无法执行 HTTP 请求”。是的。废话。对这个数据库所有写操作的临界区是排他的、串行化的，并且执行任意用户代码。你最好别在中间做 HTTP 请求。 这里有一个小小的逃生通道：你可以使用服务器中的“过程 (https://spacetimedb.com/docs/functions/procedures)”。截至本周发布时，它们仍处于 Beta 版（文档警告 API 未来可能会更改）。它们允许你运行耗时代码，包括 HTTP 请求，这是一件好事。从过程内部，你可以打开一个事务，这再次获取全局互斥锁，不允许任何其他并发写入*或*读取数据库，所以请确保你非常非常快地提交它，否则整个系统会停滞不前。 对于读取，情况非常相似。它们应该通过“视图 (https://spacetimedb.com/docs/functions/views)”进行，视图是 reducer 的只读等价物。因为它们在全局互斥锁上获取读锁，所以多个视图可以并发运行，但当视图执行时，数据库不能被写入。与 reducer 一样，视图也是编译为 WebAssembly 的任意用户代码。 ## 持久性 (https://strn.cat/posts/spacetime/#durability) 这种单一互斥锁设计的数据库一个明显的后果是，你需要在事务的临界路径中做尽可能少的工作。HTTP 请求绝对是不允许的。但你也不能做其他一些“耗时”的事情，就像其他 RDBMS 经常做的那样，比如，你知道的，将事务持久化到磁盘（嘻嘻）。 持久化管道示意图 这个完全基于内存的数据库*确实*有预写日志（WAL）支持，但 WAL 不是作为写事务的一部分提交到磁盘的。WAL 是异步的，*在后台*定期刷新到磁盘（默认每 50 毫秒一次）。 你真的能让它完全一致吗？“单一互斥锁设计”的限制使这变得复杂，因为 WAL 永远无法被同步写入（那将完全阻塞应用程序中的所有其他写入*和*读取）。系统确实提供了一个**在读取时**的选项，具有特定的语义。`withConfirmedReads` 标志允许读取仅返回已同步到磁盘的数据，方法是在服务器上休眠，直到最终看到查询结果的 WAL 条目被刷新到磁盘。这可能是一次长达 50 毫秒的休眠，对于一个请求来说是很长的时间。这不是一个非常符合人体工程学的行为，但这里的假设是这是一个用于“大多是临时性”数据的数据库，你的普通查询不需要这种高度一致的保证。 这一切都给人一种强烈的 MongoDB-2011 年的感觉。在很多方面确实如此。Mongo 团队最初推出了一个相当糟糕的数据库，却有着令人印象深刻的基准测试，最终被网络舆论（见：MongoDb is Web Scale (https://www.youtube.com/watch?v=b2F-DItXtZs)）迫使他们实现了真正的存储引擎。他们收购了 WiredTiger，那*确实*是一个像样的存储引擎。十五年后，他们已成为一家严肃且可行的数据库公司。然而，仍有很多技术人员记得 MongoDB 的早期，拒绝在生产环境中使用它或推荐它。他们的信息过时了。现代 MongoDB 是一个严肃且可用的数据库。但糟糕的技术声誉挥之不去，并将永远存在。 我认为这里有一个重要的教训：在 2026 年，如果我要推出一个数据库产品，而它只是一个前面加了单锁的哈希表，我会悄悄地做。因为在推出数据库产品时走捷径已被证明是一种可行的方法（我自己不会这么做，但 MongoDB 进行得非常成功）。但一旦产品流行起来，如果它真的流行了，你需要尽快偿还技术债务*和*声誉债务。一个带有激光束和“一瓶泪水”的营销视频会让这一切变得复杂得多。 ## 权衡取舍 (https://strn.cat/posts/spacetime/#tradeoffs) 我们已经看到了使 SpacetimeDB 在特定基准测试（即，测量我们的应用程序可以多快地写入数据库的基准测试；前提是我们的应用程序*就是*数据库）中表现出色的技术选择。这些选择在文档中没有提前说明，同样遗憾的是，这些选择所隐含的权衡也*没有*明确列出。 简要概述一下：这不是一个分布式系统，在可扩展性或可用性方面有非常硬性的限制。你可以部署一个“SpacetimeDB 集群”，意味着一个主实例和几个采用最终一致性复制的从实例（强调最终一致性；WAL 是最终一致的，复制也是，这里出错的余地很大），但你的整个系统受限于主 SpacetimeDB 实例所在机器的 CPU *和* 内存容量。你需要足够的 CPU 来让数据库执行所有查询，*同时*也需要足够的 CPU 来让整个应用程序执行其应用逻辑，因为应用程序再次说明，是运行在数据库内部的。你需要足够的内存来将所有数据库数据存放在内存中。SpacetimeDB 完全不依赖磁盘存储；它只是将 WAL 刷新到磁盘（并定期创建快照，以便在重启时加快从 WAL 恢复的速度）。如果你的数据集增长超过内存大小，你的数据库（以及你的应用程序，它们是同一回事）将会宕机。这里唯一的扩展选择是*垂直扩展*：购买更大的机器来运行你的数据库。 这些权衡取舍再次说明，完全合理。但它们明确地将 SpacetimeDB 定位为*“更强大的 Redis”*，而不是*“性能更好的关系型数据库”*。作者选择以这种方式进行基准测试，实在令人费解。 ## 使用场景 (https://strn.cat/posts/spacetime/#use-cases) SpacetimeDB 的最初版本是作为一款 MMORPG（一款你目前可以在 Steam 上玩的真实游戏 (https://store.steampowered.com/app/3454650/BitCraft_Online/)）的后端开发的。我认为这很合理。我觉得数据库中所有的技术选择都符合这个用例。你可以异步地将一条 WAL 条目刷新到磁盘，记录 `xXxPussyHunter420xXx` 掠夺了[逐风者之剑·逐风者的祝福之刃]。50 毫秒的延迟在这里是可以接受的。如果实例恰好在那一刻崩溃，他会很不高兴，但最终会接受的。 当然，现在开发 MMORPG 的工作室并不多，而那些开发任何类型多人游戏的工作室，往往更倾向于使用自己的内部后端。他们都是大公司，