Spanner Omni 正式可用：把分布式多模型数据库部署到任意基础设施

预计阅读时间：11 分钟

Spanner Omni 现已进入正式可用阶段。它把 Spanner 的分布式 SQL、强一致性和多模型能力从 Google Cloud 扩展到企业自有数据中心、其他云、虚拟机与 Kubernetes 环境。对于受数据驻留、多云战略或本地开发约束的团队，这意味着应用可以围绕同一种数据库能力构建，而不必把运行环境限定在单一云平台上。

但需要明确：Spanner Omni 是自管理软件，而不是把托管版 Spanner 原样搬进私有网络。数据库的升级、监控、备份验证、容量规划和高可用架构，都需要由使用方负责。

一个数据库承载多种数据访问模式

Spanner 最初解决的是一个经典矛盾：既希望获得 NoSQL 式的水平扩展能力，又不愿放弃关系数据库的 ACID 事务与强一致性。如今，它进一步演变成多模型数据库，在同一系统中组合了：

关系型 SQL 与事务处理
图数据及关系遍历
键值访问
全文搜索
KNN 与 ANN 向量搜索
基于列式引擎的分析处理

这种组合对 Agent 应用尤其有价值。一个业务 Agent 往往需要同时读取账户、订单等结构化数据，按向量相似度检索文本上下文，再沿着客户、联系人和公司的关系图追踪实体。如果这些数据分散在关系数据库、向量数据库、搜索引擎和图数据库中，应用不仅要维护多套连接，还必须处理跨系统一致性、权限和故障恢复问题。

Spanner Omni 允许团队把向量嵌入与关系表放在一起，并将语义相似度查询与 SQL 过滤条件组合。Spanner Graph 则把属性图能力放入数据库引擎，使图遍历能够与关系查询、向量检索协同工作。它还可通过 MCP Toolbox 接入采用 Model Context Protocol 的 Agent，让 Agent 检查数据库模式、获取上下文，并把数据库作为跨环境的操作记忆层。

这不等于所有工作负载都应该塞进一个数据库。独立搜索引擎或专用向量系统在特定规模、排序算法和延迟目标下仍可能更合适。Spanner Omni 的核心价值，是让需要事务一致性的多种访问模式共享一份数据，减少同步链路，而不是消灭所有专用数据系统。

GA 版本补齐了哪些生产能力

正式版增加或完善了生产部署需要的企业能力：

安全与治理：支持 TLS、身份认证、授权和审计日志。
数据保护：提供高性能备份与恢复，用于应对误删除和数据损坏。
Worker 节点：使用专用、无状态的计算节点承接后台或资源密集型操作，让主要服务器集中处理核心数据库请求。
企业支持：商业版可以获得 Google Cloud Customer Care 支持。

许可分为两个主要层级。Developer Edition 面向非商业、非生产的开发、测试和原型验证。其默认许可期限为 90 天，功能与商业版大体一致，但通常不包含备份和 Worker 节点；当它以不超过 4 vCPU 的单服务器形式运行时，默认许可不会过期，并支持备份恢复。超过 4 vCPU 后，如需延长使用期限，需要另行申请。

Commercial Edition 面向商业生产负载，采用按 vCPU 计算的年度订阅模式，包含完整能力和企业支持。另外还有用于生产前评估的概念验证许可。

许可边界应在搭建测试环境之前确认。尤其不要因为 Developer Edition 能运行完整应用，就默认它可以承载内部生产服务；“技术上能运行”和“许可允许用于生产”是两件事。

可以这样实践：部署后做连接、TLS 与故障检查

来源信息没有给出具体镜像名称、安装清单、端口或驱动配置，因此不应凭空编写一份看似可用的安装命令。下面提供的是一个部署后的验证模板：假设你的 Spanner Omni 环境暴露了 PostgreSQL 兼容连接端点。请先根据实际安装文档替换主机、端口、数据库名、证书路径和认证信息。

安装客户端依赖：

python -m venv .venv
. .venv/bin/activate
pip install 'psycopg[binary]>=3.1,<4'

export DB_HOST='spanner-omni.example.internal'
export DB_PORT='5432'
export DB_NAME='appdb'
export DB_USER='app_healthcheck'
export DB_PASSWORD='CHANGE_ME'
export DB_SSLMODE='verify-full'

创建 check_database.py：

import os
import sys
import time

import psycopg

required = ["DB_HOST", "DB_PORT", "DB_NAME", "DB_USER", "DB_PASSWORD"]
missing = [name for name in required if not os.getenv(name)]
if missing:
    raise SystemExit(f"Missing environment variables: {', '.join(missing)}")

conninfo = " ".join(
    [
        f"host={os.environ['DB_HOST']}",
        f"port={os.environ['DB_PORT']}",
        f"dbname={os.environ['DB_NAME']}",
        f"user={os.environ['DB_USER']}",
        f"password={os.environ['DB_PASSWORD']}",
        f"sslmode={os.getenv('DB_SSLMODE', 'verify-full')}",
        "connect_timeout=5",
    ]
)

for attempt in range(1, 6):
    started = time.perf_counter()
    try:
        with psycopg.connect(conninfo, autocommit=True) as conn:
            with conn.cursor() as cur:
                cur.execute("SELECT 1")
                value = cur.fetchone()[0]
        elapsed_ms = (time.perf_counter() - started) * 1000
        print(f"database_ok value={value} latency_ms={elapsed_ms:.1f}")
        sys.exit(0)
    except Exception as exc:
        print(f"attempt={attempt} database_error={exc}", file=sys.stderr)
        time.sleep(min(2 ** attempt, 10))

sys.exit(1)

运行检查：

python check_database.py

在 Kubernetes 中，还应限制只有指定应用能够访问数据库 Pod。下面的策略只是可改造模板，假设数据库位于 database 命名空间、Pod 标签为 app=spanner-omni，应用位于带有 access=spanner-omni 标签的命名空间，并使用 TCP 5432 端口。所有值都要按实际部署调整：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-approved-apps-to-spanner-omni
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: spanner-omni
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              access: spanner-omni
      ports:
        - protocol: TCP
          port: 5432

应用并检查策略：

kubectl label namespace applications access=spanner-omni --overwrite
kubectl apply -f network-policy.yaml
kubectl -n database describe networkpolicy allow-approved-apps-to-spanner-omni

网络策略不能替代数据库认证、授权和 TLS。生产环境应同时使用最小权限账户、独立证书、Secret 管理系统和审计日志，避免把管理员密码直接写进 Deployment 或 ConfigMap。

自管理版与托管版不是同一种运维模型

Spanner Omni 的目标是逐步接近 Google Cloud 托管版 Spanner 的核心能力，但当前仍存在功能与运行方式上的差异。

部署 Omni 后，团队必须自行承担日常维护、版本升级、基础设施监控和故障处置。因为底层基础设施由客户管理，Google 不为 Omni 提供数据库可用性 SLA；参考架构可以帮助实现类似的高可用目标，却不能替代容量冗余、故障演练和组织值班机制。

为了能在任意环境运行，Omni 也不会包含依赖 Google Cloud 专有服务的原生集成，例如部分 BigQuery、Knowledge Catalog 或 Gemini Enterprise 集成。若应用依赖这些能力，应在迁移前建立功能清单，而不是只验证 SQL 是否兼容。

一个稳妥的采用流程可以是：

用不超过 4 vCPU 的单节点 Developer Edition 验证驱动、SQL 方言和应用行为。
列出托管版中使用的云专属集成，逐项确认 Omni 是否有替代方案。
在预生产环境测试 TLS、权限、审计、升级、备份与恢复，而不只是测试查询吞吐量。
模拟节点故障、网络分区和容量耗尽，记录恢复时间与人工操作步骤。
根据生产 vCPU、Worker 节点和支持需求评估商业许可成本。
只有在恢复演练、监控告警和升级回滚均通过后，再迁移关键流量。

Spanner Omni 最适合那些既需要 Spanner 的一致性和扩展能力，又因数据主权、多云或本地基础设施要求而不能完全采用托管服务的团队。它换来了部署自由，也把更多可靠性责任交还给平台工程团队。是否采用它，不应只比较数据库功能，还要衡量组织能否持续承担分布式数据库的运维成本。

Spanner Omni 正式可用：把分布式多模型数据库部署到任意基础设施

一个数据库承载多种数据访问模式

GA 版本补齐了哪些生产能力

可以这样实践：部署后做连接、TLS 与故障检查

自管理版与托管版不是同一种运维模型

相关推荐

建议反馈