Spanner Omni 正式 GA：用软件替代原子钟与 Colossus

Google 已将 Spanner Omni 正式发布，这是其分布式 SQL 数据库的随处部署版本，可在客户自己的数据中心、其他云上或笔记本电脑上运行。要让 Spanner 脱离 Google 的基础设施，意味着必须替换它最依赖的两个组件：分布式文件系统 Colossus，以及基于原子钟和 GPS 构建的时钟服务 TrueTime。但它不附带可用性 SLA。

工程实现是 Google 描述得最直白的部分。Spanner Omni 用该公司所称的 类 Colossus 抽象层 取代了 Colossus，写入附加的本地文件系统，并使其通过网络对其他节点可用，分片拆分和再平衡自动处理。Google 直接说明了这一妥协：该文件层不是 Colossus，但对于大多数工作负载而言，它是一个足以与托管服务表现相当的替代品。

TrueTime 也得到了同样的处理。基于软件的替代方案 在服务器之间提供有误差界限的时间同步，正如原始方案使用原子钟和 GPS 所做的那样。Google 对其为何可行的解释取决于 Spanner 本身的行为方式：数据库将时间不确定性等待与其他工作重叠，因此它能容忍比 TrueTime 实际提供的更弱的不确定性界限。正是这种余量，使得在异构硬件上进行计时不会限制可用性或性能。

Paxos 共识、自动分片和同步复制原封不动地保留下来，Google 的内部基准测试声称在单一区域部署中可在数 PB 数据上实现每秒数百万次查询。

从业者的反应集中在这意味着什么样的运行负担。Q2BSTUDIO 的 CTO Carlos Pérez Martín 认为，这一变化主要不是设计问题：

有意思的转变是运营层面的，而不是架构层面的：一旦同一个引擎运行在你的机架上，故障域就变成了你自己的。

他列出了三个后果。法定人数和见证者拓扑必须根据本地延迟预算重新推导，而当整个数据中心成为故障单元时，应用程序感受到的是 p99 而不是平均值。打补丁、版本化升级和回滚不再是别人的工单队列，而变成了一个署着客户名字的变更管理问题。将数据驻留迁移到私有数据中心，也随之带来了备份、密钥管理和审计负担。

他推荐的测试比功能对比更聚焦：

与管理服务进行同类对比试点，以尾部延迟和运维负担而非功能对等来衡量，是为这一权衡定价的最便宜方式。

Google 自己的文档支持这一解读。由于 Spanner Omni 运行在客户管理的基础设施上，Google 不提供可用性 SLA，而是指向其声称有助于实现可比高可用性的参考架构。取代 SLA 的是一组 拓扑：单服务器，升级会导致停机；单区域，至少三台服务器；多区域，至少需要三个区域，每个区域三台服务器；以及多集群，跨两个或更多集群使用三个区域。

运维负担也落在工具上。日常维护、版本升级和基础设施监控都转为内部承担，监控通过 Prometheus 告警和 Grafana 仪表板而非 Cloud Monitoring 进行，还有一个收集日志、追踪和线程堆栈的诊断命令。

评估时还有另外两个边界很重要。依赖 Google Cloud 的集成被排除在外，包括 BigQuery、Knowledge Catalog 和 Gemini Enterprise，Google 也承认与管理服务相比仍存在功能差距，但没有指明是哪些差距或何时弥合。文档列出了 Google Cloud 和 Amazon 作为支持的公有云，以及本地部署和笔记本电脑；未提及 Azure。

真正保留下来的，是数据库本身。Spanner Omni 支持 GoogleSQL、PostgreSQL 和 Spanner Graph Language，并将关系、图、键值和向量模型与全文搜索及列式引擎相结合。通过 MCP Toolbox 提供的模型上下文协议支持，让智能体能够检查模式，并在各种部署中把数据库用作操作记忆层。正式发布还增加了 TLS 加密、身份验证和授权、审计日志、备份和恢复，以及 工作节点，即从主服务器卸载后台操作的无状态计算。

许可分为两个层级。开发者版对非生产用途免费，默认许可为 90 天，不包含备份和工作节点，不过 4 个 vCPU 或以下的单服务器部署不会过期，并且包含备份和恢复。超过该期限后，若要延长至 90 天以上，需要填写 Google 表单。商业版是基于 vCPU 的年度订阅，未公布价格。

Google 报告的早期采用者部署模式与运营框架相符。一种是将托管 Spanner 作为主数据库，在其他地方运行 Spanner Omni 作为热冷故障转移。另一种是在各环境中标准化一个数据库层。第三种是在现有硬件上对本地系统进行现代化改造。Google 还提到了在其仅运营一个数据中心但要求数据主权的司法管辖区实现多区域高可用性。

Mercado Libre 构建了一个内部开发者网关，提供由 Spanner 驱动的 NewSQL 服务，并在 预览版发布时 在 4 月给出了其韧性论证。高级技术经理 Diego Oscar Narducci 表示，该公司长期以来一直对内部威胁、勒索软件和云中断保持警惕，而 Spanner Omni 实现了跨云韧性，若使用其他云提供商来实现则会复杂得多。

如果这种反应具有代表性，那么决策并不是 Spanner Omni 与另一个数据库之间的对比。而是 Spanner Omni 与托管 Spanner 之间的对比，其代价以尾部延迟和运维负担而非功能来衡量。

一个实用提示。Spanner Omni 概述在 Google 的文档中，该内容最后更新于 9 月 28 日，也就是公告发布前两天，并且仍然带有预览版横幅，其中列出的限制在正式发布时已被移除，包括无 TLS 加密、无备份或恢复，以及部署在 90 天后停止接受写入。