SpacetimeDB 的禅意理解一切皆表等五大核心设计原则【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDBSpacetimeDB 是一套数据库即应用服务器的实时后端方案你的业务逻辑作为模块运行在数据库内部客户端通过订阅与调用 reducer 与数据库直接交互中间不再有传统应用服务器与缓存层。这篇技术指南以官方文档《The Zen of SpacetimeDB》为主体逐条拆解驱动 SpacetimeDB 设计的五大核心原则——一切皆表、一切皆持久化、一切皆实时、一切皆事务、一切皆可编程——并结合仓库内的 TypeScript 客户端实现、Rust 服务端绑定与核心概念文档讲清每个原则背后的实现机制与实战含义。读完你会掌握如何用表组织应用状态、事务如何保证一致性、订阅如何替代轮询以及为什么这些原则能带来无后端可部署、无缓存可管理、无同步代码可写的极简架构。一、一切皆表Everything is a Table数据库即你的全部状态SpacetimeDB 的第一条原则最彻底整个应用状态都放在表里。用户、消息、游戏实体、会话——全部是表。没有独立的缓存层没有 Redis没有需要与数据库同步的内存态。数据库就是你的状态全部的状态。这一点的意义远超用数据库存数据本身。传统架构下热数据常驻内存缓存、冷数据落库应用层代码需要小心翼翼地维护两层之间的同步而 SpacetimeDB 把所有数据常驻内存供快速访问并自动落盘保持久化应用层心智模型被大幅简化——要存储就定义一张表要查询就查一张表要更新就更新一张表要限制谁能读就为表创建 a view。原文档用一张 ASCII 图直观对比了两种架构的差异Traditional stack: SpacetimeDB: ┌─────────────────┐ ┌─────────────────┐ │ Application │ │ │ ├─────────────────┤ │ │ │ Cache │ → │ Tables │ ├─────────────────┤ │ │ │ Database │ │ │ └─────────────────┘ └─────────────────┘右侧的应用层、缓存层、数据库三层在 SpacetimeDB 中被压缩为一层 Table。这一设计还带来一个传统架构难以想象的副产品SpacetimeDB 可以在不断开客户端连接的情况下热替换服务端代码hot-swap server code。因为所有状态都在表里模块逻辑本身是无状态的下文一切皆事务与 reducer 隔离性会进一步解释升级模块时数据库数据原地保留新逻辑无缝接管。从源码结构看这套表即一切的理念贯穿整个仓库核心的数据表实现在 crates/table/src 与 crates/datastore/src 中而服务端绑定如 Rust 的#[spacetimedb::table]宏、TypeScript 的table()构造器负责把语言级声明编译成数据库可执行的表定义具体示例可见 key-architecture 文档 中的四语言对照声明。二、一切皆持久化Everything is Persistent持久化是默认不是选项SpacetimeDB 默认持久化一切包括任何行曾经变化的完整历史。文档直接引出了一个常见疑虑难道每样东西都需要持久化吗那数据量会不会很大原文档给出了量级估算假设一个百万并发玩家的游戏每秒更新 100 万份玩家变换player transforms10 次持续一年未压缩数据量约为 10 PB。SpacetimeDB 对此类数据可压缩 5–10 倍即每年约 1–2 PB。把这些数据放进 Amazon S3月成本约在 $2,300 至 $5,600 之间——文档强调这比雇佣一位工程师或数据科学家的成本低得多。当然历史数据完全可以删——但应该是你的选择而不是数据库替你做的决定。SpacetimeDB 把是否删除数据的选择权交给你。那么持久化一切会不会拖慢性能原文档的回答是不会。SpacetimeDB 的设计保证持久化只增加延迟、绝不降低吞吐。现代 SSD 可以每秒写入 15 GB 以上而 DRAM 大约只快 4 倍那就用好这份三星给我们的带宽原文语。实现上这正是内存数据库 自动落盘的组合数据常驻内存以获得极速访问同时自动持久化到磁盘。你得到的是内存计算的速度加上传统数据库的持久性。这引出了原文档中一个重要的反向劝诫你会忍不住想要临时状态ephemeral state。这是个错误。持久化一切让你的应用可以恢复到精确的先前状态。原则上你甚至可以用时间旅行调试器在过去的某个状态下调试生产环境应用。因此写代码时应把内存当作无限且永久的来写放心地插入行放心地查询持久化交给 SpacetimeDB逻辑交给你。三、一切皆实时Everything is Real-Time客户端是服务器的副本把客户端想成服务器的一个副本。当客户端订阅数据时SpacetimeDB 把数据镜像到客户端并自动保持同步。你不轮询poll、不拉取fetch你订阅然后数据自己流动——正如原文档引用的那句格言The data must flow.。原文档给出了 TypeScript 客户端的示例// Subscribe once const [messages] useTable(tables.message); // messages updates automatically when the server state changes // No polling. No refetching. Just reactive data.这改变了你对客户端-服务端通信的思考方式不要再想请求-响应而是想同步状态在实时更新。你的用户永远不需要点刷新按钮。深入 TypeScript 客户端源码可以看到这套订阅即副本机制的实现。useTable是 React 侧的核心 Hook位于 crates/bindings-typescript/src/react/useTable.ts它接收一个 query builder 表达式如tables.user或带过滤条件的tables.user.where(r r.online.eq(true))内部通过toSql(query)把查询翻译成 SQL交给connection.subscriptionBuilder().subscribe(querySql)见 useTable.ts订阅生效后客户端维护一份本地缓存副本并通过table.onInsert/onDelete/onUpdate监听行级变更事件把变更合并进 React 的 external storeuseSyncExternalStore从而驱动组件自动重渲染见 useTable.ts订阅句柄本身支持onApplied订阅成功回调、onError订阅出错回调与unsubscribe()/unsubscribeThen()且同一连接不能混用subscribe与subscribeToAllTables相关实现见 crates/bindings-typescript/src/sdk/subscription_builder_impl.ts。也就是说数据自动流动不是黑魔法客户端建立 WebSocket 连接后向服务器注册一组 SQL 查询subscription服务器持续推送这些查询结果的增量变更客户端在本地缓存上增量应用并通知 UI。正是因为有一切皆表 一切皆持久化作地基一切皆实时才能以订阅-增量推送这样干净的方式落地。四、一切皆事务Everything is Transactional每个 reducer 都是原子事务每个 reducer 都在一个事务中运行。事务是原子的要么完整完成要么完全不执行。一旦出错只需抛出错误或返回Err所有更改自动回滚——没有部分更新、没有损坏状态、不需要清理代码。原文档给出了 Rust 版的资金转账示例#[spacetimedb::reducer] fn transfer_funds(ctx: ReducerContext, from: u64, to: u64, amount: u64) - Result(), String { let sender ctx.db.account().id().find(from).ok_or(Sender not found)?; if sender.balance amount { return Err(Insufficient funds.to_string()); // Everything rolls back } // ... rest of transfer Ok(()) }余额不足时返回Err(Insufficient funds)此前任何对表的写入都会一并回滚数据库始终处于一致状态。这意味着你可以大胆地写业务逻辑放手尝试失败也不会破坏一致性。文档的结语是完美的一致性始终如此。从 reducers 核心概念文档 可以看到更完整的语义reducer 是修改数据库状态的唯一途径所有客户端请求对表的变更都必须经过 reducer。事务提供了三条保证隔离性Isolationreducer 看不到其他并发 reducer 的变更原子性Atomicity要么全部成功要么全部回滚一致性Consistency失败的 reducer 让数据库保持原样。该文档还强调了一个与一切皆表互相印证的约束reducer 在隔离环境中运行不能发起网络请求、不能访问文件系统、不能做系统调用只能操作数据库。任何需要跨模块保留的全局状态都应放进表里——依赖全局变量或静态变量跨 reducer 调用保持状态属于未定义行为模块可能被热替换、崩溃恢复、甚至为回放而重放执行详见 reducers 文档中的警告章节。这正说明一切皆表不只是一条组织数据的建议而是由事务隔离与执行环境语义共同决定的架构必然。五、一切皆可编程Everything is Programmable模块就是在数据库里运行的真正代码SpacetimeDB 不把你限制在声明式规则或配置文件里。你的模块是跑在数据库内部的真正的代码——Rust、C#、TypeScript 或 C——你拥有过程式、常规编程语言的完整能力。需要自定义授权逻辑写个函数。需要校验复杂业务规则写个函数。需要在存储前转换数据写个函数。连访问控制都是可编程的SpacetimeDB 提供合理的默认值公开表 vs. 私有表但任何你能用代码表达出来的访问模式都能实现——包括管理、控制应用部署本身的元权限。原文档引用了一句企业客户需要越来越细粒度的权限分形般精细。原文Enterprise clients require increasingly granular permissions, fractal-like in nature.结语很直白一切可编程意味着一切强大。永远不要满足于低于图灵完备Turing complete的方案。从仓库看可编程的具体形态是模块module与数据库的边界被抹平。按照 key-architecture 文档模块是用 C#、C、Rust 或 TypeScript 编写的一段软件定义了数据库导出的表与 reducer技术底层它编译为 WebAssembly 模块或 JavaScript bundle导入一套低层 WebAssembly ABI并导出少量特殊函数但服务端库把这些细节全部隐藏写模块就像写普通应用。可编程的典型例子就是前文反复提到的 Views视图是只读函数用来计算派生数据、聚合或连接多张表后再下发客户端。它们声明为public并带显式name返回值可以是至多一行如 Rust 的OptionT、TS 的t.option(...)或多行VecT、t.array(...)。视图还有两类上下文值得注意ViewContext能读到调用者的Identity适合我的消息我的背包这类按用户区分的场景AnonymousViewContext不提供调用者信息结果对所有订阅者相同因此数据库可以把视图物化一次、共享给所有订阅者性能显著更好——全局排行榜、商店库存就属于这一类。这与一切皆表 一切皆实时一脉相承视图可以被订阅底层表变化时视图自动更新并推送客户端。用 Rust 定义一个高分段排行榜视图全部逻辑都是普通代码#[spacetimedb::table(accessor player, public)] pub struct Player { #[primary_key] #[auto_inc] id: u64, name: String, #[index(btree)] score: u64, } // Shared: same high scorers for all clients #[view(accessor high_scorers, public)] fn high_scorers(ctx: AnonymousViewContext) - VecPlayer { // Get all players with score 1000 using the btree index ctx.db.player().score().filter(1000..).collect() }完整的多语言对照版见 views 文档。六、五大原则合流之后The Result当你拥抱这些原则构建实时应用会变得异常简单。原文档用五条无总结了最终效果没有需要部署的后端服务器——你的逻辑跑在数据库里没有需要管理的缓存层——数据库本身就在内存中没有需要编写的同步代码——订阅自动处理没有需要维护的回滚逻辑——事务自动处理逻辑没有能力限制——它只是代码。这就是 SpacetimeDB 的禅意一种更简单的构建方式也是一种更简单的活法。延伸阅读围绕本文提到的概念仓库内还有以下文档与源码可供继续深挖服务端语言支持总览language-support核心架构词汇Host / Database / Table / Reducerkey-architectureReducer 的定义、事务语义与隔离性警告reducers 文档视图View的定义、两类上下文与性能取舍views 文档TypeScript 客户端订阅实现useTable.ts、subscription_builder_impl.tsRust 服务端绑定宏与 Table 特征crates/bindings-macro/src、crates/sdks/rust/src【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SpacetimeDB 的禅意：理解“一切皆表“等五大核心设计原则
SpacetimeDB 的禅意理解一切皆表等五大核心设计原则【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDBSpacetimeDB 是一套数据库即应用服务器的实时后端方案你的业务逻辑作为模块运行在数据库内部客户端通过订阅与调用 reducer 与数据库直接交互中间不再有传统应用服务器与缓存层。这篇技术指南以官方文档《The Zen of SpacetimeDB》为主体逐条拆解驱动 SpacetimeDB 设计的五大核心原则——一切皆表、一切皆持久化、一切皆实时、一切皆事务、一切皆可编程——并结合仓库内的 TypeScript 客户端实现、Rust 服务端绑定与核心概念文档讲清每个原则背后的实现机制与实战含义。读完你会掌握如何用表组织应用状态、事务如何保证一致性、订阅如何替代轮询以及为什么这些原则能带来无后端可部署、无缓存可管理、无同步代码可写的极简架构。一、一切皆表Everything is a Table数据库即你的全部状态SpacetimeDB 的第一条原则最彻底整个应用状态都放在表里。用户、消息、游戏实体、会话——全部是表。没有独立的缓存层没有 Redis没有需要与数据库同步的内存态。数据库就是你的状态全部的状态。这一点的意义远超用数据库存数据本身。传统架构下热数据常驻内存缓存、冷数据落库应用层代码需要小心翼翼地维护两层之间的同步而 SpacetimeDB 把所有数据常驻内存供快速访问并自动落盘保持久化应用层心智模型被大幅简化——要存储就定义一张表要查询就查一张表要更新就更新一张表要限制谁能读就为表创建 a view。原文档用一张 ASCII 图直观对比了两种架构的差异Traditional stack: SpacetimeDB: ┌─────────────────┐ ┌─────────────────┐ │ Application │ │ │ ├─────────────────┤ │ │ │ Cache │ → │ Tables │ ├─────────────────┤ │ │ │ Database │ │ │ └─────────────────┘ └─────────────────┘右侧的应用层、缓存层、数据库三层在 SpacetimeDB 中被压缩为一层 Table。这一设计还带来一个传统架构难以想象的副产品SpacetimeDB 可以在不断开客户端连接的情况下热替换服务端代码hot-swap server code。因为所有状态都在表里模块逻辑本身是无状态的下文一切皆事务与 reducer 隔离性会进一步解释升级模块时数据库数据原地保留新逻辑无缝接管。从源码结构看这套表即一切的理念贯穿整个仓库核心的数据表实现在 crates/table/src 与 crates/datastore/src 中而服务端绑定如 Rust 的#[spacetimedb::table]宏、TypeScript 的table()构造器负责把语言级声明编译成数据库可执行的表定义具体示例可见 key-architecture 文档 中的四语言对照声明。二、一切皆持久化Everything is Persistent持久化是默认不是选项SpacetimeDB 默认持久化一切包括任何行曾经变化的完整历史。文档直接引出了一个常见疑虑难道每样东西都需要持久化吗那数据量会不会很大原文档给出了量级估算假设一个百万并发玩家的游戏每秒更新 100 万份玩家变换player transforms10 次持续一年未压缩数据量约为 10 PB。SpacetimeDB 对此类数据可压缩 5–10 倍即每年约 1–2 PB。把这些数据放进 Amazon S3月成本约在 $2,300 至 $5,600 之间——文档强调这比雇佣一位工程师或数据科学家的成本低得多。当然历史数据完全可以删——但应该是你的选择而不是数据库替你做的决定。SpacetimeDB 把是否删除数据的选择权交给你。那么持久化一切会不会拖慢性能原文档的回答是不会。SpacetimeDB 的设计保证持久化只增加延迟、绝不降低吞吐。现代 SSD 可以每秒写入 15 GB 以上而 DRAM 大约只快 4 倍那就用好这份三星给我们的带宽原文语。实现上这正是内存数据库 自动落盘的组合数据常驻内存以获得极速访问同时自动持久化到磁盘。你得到的是内存计算的速度加上传统数据库的持久性。这引出了原文档中一个重要的反向劝诫你会忍不住想要临时状态ephemeral state。这是个错误。持久化一切让你的应用可以恢复到精确的先前状态。原则上你甚至可以用时间旅行调试器在过去的某个状态下调试生产环境应用。因此写代码时应把内存当作无限且永久的来写放心地插入行放心地查询持久化交给 SpacetimeDB逻辑交给你。三、一切皆实时Everything is Real-Time客户端是服务器的副本把客户端想成服务器的一个副本。当客户端订阅数据时SpacetimeDB 把数据镜像到客户端并自动保持同步。你不轮询poll、不拉取fetch你订阅然后数据自己流动——正如原文档引用的那句格言The data must flow.。原文档给出了 TypeScript 客户端的示例// Subscribe once const [messages] useTable(tables.message); // messages updates automatically when the server state changes // No polling. No refetching. Just reactive data.这改变了你对客户端-服务端通信的思考方式不要再想请求-响应而是想同步状态在实时更新。你的用户永远不需要点刷新按钮。深入 TypeScript 客户端源码可以看到这套订阅即副本机制的实现。useTable是 React 侧的核心 Hook位于 crates/bindings-typescript/src/react/useTable.ts它接收一个 query builder 表达式如tables.user或带过滤条件的tables.user.where(r r.online.eq(true))内部通过toSql(query)把查询翻译成 SQL交给connection.subscriptionBuilder().subscribe(querySql)见 useTable.ts订阅生效后客户端维护一份本地缓存副本并通过table.onInsert/onDelete/onUpdate监听行级变更事件把变更合并进 React 的 external storeuseSyncExternalStore从而驱动组件自动重渲染见 useTable.ts订阅句柄本身支持onApplied订阅成功回调、onError订阅出错回调与unsubscribe()/unsubscribeThen()且同一连接不能混用subscribe与subscribeToAllTables相关实现见 crates/bindings-typescript/src/sdk/subscription_builder_impl.ts。也就是说数据自动流动不是黑魔法客户端建立 WebSocket 连接后向服务器注册一组 SQL 查询subscription服务器持续推送这些查询结果的增量变更客户端在本地缓存上增量应用并通知 UI。正是因为有一切皆表 一切皆持久化作地基一切皆实时才能以订阅-增量推送这样干净的方式落地。四、一切皆事务Everything is Transactional每个 reducer 都是原子事务每个 reducer 都在一个事务中运行。事务是原子的要么完整完成要么完全不执行。一旦出错只需抛出错误或返回Err所有更改自动回滚——没有部分更新、没有损坏状态、不需要清理代码。原文档给出了 Rust 版的资金转账示例#[spacetimedb::reducer] fn transfer_funds(ctx: ReducerContext, from: u64, to: u64, amount: u64) - Result(), String { let sender ctx.db.account().id().find(from).ok_or(Sender not found)?; if sender.balance amount { return Err(Insufficient funds.to_string()); // Everything rolls back } // ... rest of transfer Ok(()) }余额不足时返回Err(Insufficient funds)此前任何对表的写入都会一并回滚数据库始终处于一致状态。这意味着你可以大胆地写业务逻辑放手尝试失败也不会破坏一致性。文档的结语是完美的一致性始终如此。从 reducers 核心概念文档 可以看到更完整的语义reducer 是修改数据库状态的唯一途径所有客户端请求对表的变更都必须经过 reducer。事务提供了三条保证隔离性Isolationreducer 看不到其他并发 reducer 的变更原子性Atomicity要么全部成功要么全部回滚一致性Consistency失败的 reducer 让数据库保持原样。该文档还强调了一个与一切皆表互相印证的约束reducer 在隔离环境中运行不能发起网络请求、不能访问文件系统、不能做系统调用只能操作数据库。任何需要跨模块保留的全局状态都应放进表里——依赖全局变量或静态变量跨 reducer 调用保持状态属于未定义行为模块可能被热替换、崩溃恢复、甚至为回放而重放执行详见 reducers 文档中的警告章节。这正说明一切皆表不只是一条组织数据的建议而是由事务隔离与执行环境语义共同决定的架构必然。五、一切皆可编程Everything is Programmable模块就是在数据库里运行的真正代码SpacetimeDB 不把你限制在声明式规则或配置文件里。你的模块是跑在数据库内部的真正的代码——Rust、C#、TypeScript 或 C——你拥有过程式、常规编程语言的完整能力。需要自定义授权逻辑写个函数。需要校验复杂业务规则写个函数。需要在存储前转换数据写个函数。连访问控制都是可编程的SpacetimeDB 提供合理的默认值公开表 vs. 私有表但任何你能用代码表达出来的访问模式都能实现——包括管理、控制应用部署本身的元权限。原文档引用了一句企业客户需要越来越细粒度的权限分形般精细。原文Enterprise clients require increasingly granular permissions, fractal-like in nature.结语很直白一切可编程意味着一切强大。永远不要满足于低于图灵完备Turing complete的方案。从仓库看可编程的具体形态是模块module与数据库的边界被抹平。按照 key-architecture 文档模块是用 C#、C、Rust 或 TypeScript 编写的一段软件定义了数据库导出的表与 reducer技术底层它编译为 WebAssembly 模块或 JavaScript bundle导入一套低层 WebAssembly ABI并导出少量特殊函数但服务端库把这些细节全部隐藏写模块就像写普通应用。可编程的典型例子就是前文反复提到的 Views视图是只读函数用来计算派生数据、聚合或连接多张表后再下发客户端。它们声明为public并带显式name返回值可以是至多一行如 Rust 的OptionT、TS 的t.option(...)或多行VecT、t.array(...)。视图还有两类上下文值得注意ViewContext能读到调用者的Identity适合我的消息我的背包这类按用户区分的场景AnonymousViewContext不提供调用者信息结果对所有订阅者相同因此数据库可以把视图物化一次、共享给所有订阅者性能显著更好——全局排行榜、商店库存就属于这一类。这与一切皆表 一切皆实时一脉相承视图可以被订阅底层表变化时视图自动更新并推送客户端。用 Rust 定义一个高分段排行榜视图全部逻辑都是普通代码#[spacetimedb::table(accessor player, public)] pub struct Player { #[primary_key] #[auto_inc] id: u64, name: String, #[index(btree)] score: u64, } // Shared: same high scorers for all clients #[view(accessor high_scorers, public)] fn high_scorers(ctx: AnonymousViewContext) - VecPlayer { // Get all players with score 1000 using the btree index ctx.db.player().score().filter(1000..).collect() }完整的多语言对照版见 views 文档。六、五大原则合流之后The Result当你拥抱这些原则构建实时应用会变得异常简单。原文档用五条无总结了最终效果没有需要部署的后端服务器——你的逻辑跑在数据库里没有需要管理的缓存层——数据库本身就在内存中没有需要编写的同步代码——订阅自动处理没有需要维护的回滚逻辑——事务自动处理逻辑没有能力限制——它只是代码。这就是 SpacetimeDB 的禅意一种更简单的构建方式也是一种更简单的活法。延伸阅读围绕本文提到的概念仓库内还有以下文档与源码可供继续深挖服务端语言支持总览language-support核心架构词汇Host / Database / Table / Reducerkey-architectureReducer 的定义、事务语义与隔离性警告reducers 文档视图View的定义、两类上下文与性能取舍views 文档TypeScript 客户端订阅实现useTable.ts、subscription_builder_impl.tsRust 服务端绑定宏与 Table 特征crates/bindings-macro/src、crates/sdks/rust/src【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考