OpenTenBase 深度解读

“在 PG 内核里做手术 – 腾讯出品的 PostgreSQL 分布式 HTAP 改造方案”

一句话定位

OpenTenBase 是腾讯开源的基于 Postgres-XL 架构的分布式 HTAP 数据库，保持 PostgreSQL 完整内核的同时，通过 GTM（全局事务管理器）+ Coordinator-Datanode 架构实现分布式事务和水平扩展。

设计哲学上最精彩的地方

OpenTenBase 最精彩的决策是“在 PG 内核里做手术而不是在外面包一层”。

想象你要把一辆轿车改装成越野车 – Citus 的做法是给轿车加一个拖车挂件（extension），Vitess 的做法是在轿车前面放一个导航台（中间件），而 OpenTenBase 的做法是直接打开发动机盖，换更强的引擎、加底盘护甲（内核改造）。这带来了更深层的能力（分布式 DDL、全局事务、全局序列），但也意味着每次 PG 升级都要重新做一遍”手术”。

源码结构清晰展示了这个设计。src/gtm/ 是全局事务管理器的完整实现，src/backend/pgxc/ 是核心分布式扩展层。#ifdef __OPENTENBASE__ 条件编译标记清晰标注了对 Postgres-XL 基线的所有增强，这让代码考古变得容易 – 你可以精确看到哪些是 OpenTenBase 自己加的。

GTM：全局一致性的代价

GTM（Global Transaction Manager）是 OpenTenBase 架构的核心也是最大瓶颈。src/gtm/main/gtm_txn.c（4029 行）处理全局事务 ID 分配和状态管理，gtm_snap.c 管理全局快照，gtm_seq.c 管理全局序列。所有分布式事务都必须经过 GTM，这让它天然成为性能瓶颈。

为此，OpenTenBase 设计了 GTM Proxy（src/gtm/proxy/）来缓解 – Coordinator 本地聚合事务请求后批量发往 GTM，减少网络往返。这是一个务实的工程优化，但没有从根本上消除单点限制。

犀牛鸟 2026 的参与价值

OpenTenBase 的 star 数（约 2K）远低于头部项目，但这恰恰意味着社区贡献者少、每个 PR 的可见度高。可以做有影响力贡献的方向包括：GTM 性能优化（src/gtm/main/gtm_txn.c 的事务分配路径）、查询优化器增强（src/backend/optimizer/util/pgxcship.c 的可下推判断）、列存引擎完善、向量搜索增强（contrib/pgvector/ 集成还处于早期）。

C 语言 + 约 3,000 文件的代码量，比 CockroachDB 或 YugabyteDB 小得多，入门门槛相对友好。

局限性与场景边界

GTM 单点是已知瓶颈 – 高并发场景下 GTM 的事务 ID 分配和快照获取可能成为吞吐量天花板。PG 内核 fork 模式意味着每次 PG 大版本升级都是一次”再手术”，版本跟进滞后。社区生态和文档成熟度不如头部项目。但在腾讯内部（微信支付等）有大规模生产验证，技术可靠性有保障。

本地代码结构

OpenTenBase/OpenTenBase (C)
  src/
    gtm/
      main/
        gtm_txn.c       # 全局事务管理（4029行）
        gtm_snap.c       # 全局快照管理
        gtm_seq.c        # 全局序列管理
        gtm_xlog.c       # GTM WAL 日志
        replication.c    # GTM 主备复制
      proxy/             # GTM Proxy（批量聚合优化）
    backend/
      pgxc/
        locator/
          locator.c      # 数据分片定位（2775行）
        pool/
          execRemote.c   # 远程查询执行（12835行，最大文件）
        plan/
          planner.c      # 分布式查询计划生成
      optimizer/
        util/
          pgxcship.c     # 可下推判断逻辑
  contrib/
    opentenbase_ai/      # AI 扩展
    pgvector/            # 向量搜索扩展

本地关键文件