ksxz
数据库分布式系统架构设计

数据库到底该怎么选？TDSQL 用一套内核给出了三个答案

InfoQ··原文链接
收录于 2026/6/24 09:56:36

背景：数据库需求的三类分化

企业对数据库的需求正在裂成两端，并出现第三股力量：

  • 轻量端：中小型业务、被集成的 SaaS、行业垂直应用，关心"开箱即用、一台服务器跑起来、运维不烧人"。
  • 重负载端：金融核心、政企关键系统、交易分析一体化业务，要"扩得动、扛得住、查得快"，还要金融级容灾与合规。
  • 一体化数据底座：业务希望 TP 与 AP 不再二选一，且能与 AI、信创栈协同演进。

传统选型在这三类场景之间被反复撕扯：MySQL 8.0 今年 4 月正式停更，"够用就行"的方案突然失去了官方兜底；换商业库要面对语法迁移和高昂改造；自建分布式数据库又对中小型业务是过度设计。"用什么数据库"已经从技术题变成了成本、合规、长期演进的综合题。

TDSQL 的解法是：同一套金融级内核，按真实业务需求拆三档。

TDSQL 的统一内核与三种形态

三档形态对应三类业务，但底层共享同一份内核与运维介质：

  • 基础版：单机部署，完全兼容 MySQL 语法，自带白屏化运维平台，最低 1C2G 起步，10 分钟一条 install 完成交付，底层与企业版同源。定位是"让中小型业务也能用金融级内核，但不必为高可用付费"。
  • 企业版：计算、存储、元数据、管控全栈自研，金融级高可用、计算存储分离、HTAP 一次给齐，MySQL/PG 全覆盖，特定场景下 Oracle 兼容性号称可达 98%。强调"统一"——MySQL、PG、Libra、DBBrain 共用一份介质、一套界面、一组 API。
  • 全新计算引擎：用协程框架重写的 TDSQL MySQL 计算引擎，解决老 Proxy 在 MySQL 8.0 主流能力（CTE、窗口函数、存储过程、触发器）、Oracle 兼容、Reactor 多连接互扰、缺分布式优化器等方面的代际短板。

关键能力点

  • HTAP：企业版以 Libra AP 引擎作为可插拔模块挂到原 TDSQL 架构上，对业务代码零入侵，可表级开启（一个库 8 张表只给其中 4 张开 HTAP）。
  • 分布式：新引擎同时支持分区表与分库分表，物理拓扑和 DDL 路由由计算引擎统一屏蔽。
  • 容灾：异构多芯支持主实例非信创、灾备实例信创共存；DCN 跨架构实时同步、一键切主备；"黑匣子容灾"在同城稳网区放一份强同步日志副本，第一次让异地 RPO=0 真正落地。
  • 兼容性：Oracle 侧补齐全局临时表、CONNECT BY、ROW_NUMBER、PL/SQL 等语法。
  • 安全合规：密钥管理与加密模块拿到商密局二级资质，首批通过安可与政府采购标准。

架构与工程亮点

计算引擎重写：从 Reactor 多线程模型迁到协程框架，大量协程映射到少量系统线程，避免线程级开销。执行路径分层判断：

  • Fast Query Shipping：简单 SQL 直接下推到 TDSQL 节点，性能对齐原 Proxy。
  • Parallel Query MPP：复杂 SQL 并发执行。
  • Libra 列存引擎：大数据量分析路由进来，与 TP 资源彻底隔离。

优化器侧引入 JoinElim、子查询消除、基于代价的分布式改造，并跨分片聚合多维统计信息——"选执行计划这件事，不再靠经验、而是靠代价"。

三层全局索引（分库分表查询变慢的核心解药）：

  • 分区内索引：保留 MySQL 原生用法。
  • Set 内全局索引：单分片内跨分区，无需影子表，使用成本最低。
  • 跨 Set 全局索引：基于隐式影子表，提供全实例维度唯一性约束，DML 自动维护、查询自动回表。

DDL 三种模式：

  • Physical DDL：直接下推，适合简单变更。
  • 两阶段 DDL：每个分片先 prepare 再统一 commit，保多 Set 原子性。
  • Logical OSC：基于 binlog 的在线表结构变更，搭配影子表加增量回放，对写入零干扰，任一步出错均能无损回滚。整个任务拆 DAG 并行推进，状态落 metadb，宕机可恢复。

智能运维：DBbrain 完整融入 TDSQL，提供 7×24 实时监控、按天按周自动巡检、基于审计日志的全链路可观测分析，弱化对 DBA 个人经验的依赖。

国产化性能调优：NUMA 绑核让信创服务器就近访问内存性能最高提升 176%，PGO 编译优化再提升约 18%——调优后鲲鹏、海光、TencentOS 等环境与英特尔+Linux 持平甚至反超。

落地与案例

  • 基础版已为 4000+ 客户提供稳定服务。
  • 当前主推 LTS 版本 22.1 / 22.6 / 22.8；创新版 22.9 支持参数模板、秒级闪回、指定 set 回档等新能力。
  • 典型 HTAP 场景：金融跑批的复杂事务变更、监管报送多维实时校验、实时数据看板、ERP 类多源汇聚分析。

文章未给出具体客户名称与端到端 QPS/TPS 等硬指标，主要是产品线与能力面的陈述。

我的判断

  1. "同一内核三档形态"的产品策略是认真的，但更多是商业表达。从工程上看，基础版与企业版"同源"更多体现在 SQL 兼容层和运维介质，真正的分布式事务、HTAP 列存、跨地域容灾这些重资产能力，并不能真正"无损下放"到 1C2G 单机上。对一线工程师而言，别被"同一套内核"误导，选型仍要按 SLA、容灾要求和团队运维能力分档评估。
  2. 协程重写计算引擎、三层全局索引、Logical OSC 是真硬货。这几块是国内分布式 MySQL 兼容数据库的长期痛点：连接模型、跨分片索引、在线 DDL 三件事任意一件没做好都会在生产上崩，TDSQL 这次给出的方案在工程化完备度上是可信的——但实际表现取决于 binlog 回放与影子表的边界 case，需要在自己业务的高写入场景里压测，不要轻信 PPT 数据。
  3. "Oracle 兼容 98%" 与 "性能反超 Intel+Linux" 都属于强营销话术。98% 大概率是 TPC-C/特定 benchmark 的语法覆盖率，不等于真实迁移 PL/SQL 业务的成功率；信创性能"反超"是 NUMA + PGO 极限调优后的结果，常规部署能拿到的红利远没那么夸张。读这类材料时，要把"特定场景下"四个字补上。
  4. HTAP 表级开关、"该重的地方重，该轻的地方轻"是好工程理念。对前端/中台同学的启示是：在为 BI 看板、ERP 汇聚类需求出方案时，不必再默认"加 ClickHouse / Doris"，可以推动 DBA 评估同实例 HTAP 的运维成本是否更低——这件事直接影响接入链路与数据一致性边界。
  5. MySQL 8.0 EOL 才是这篇文章真正的潜在卖点。对存量 MySQL 8.0 的中后台业务，未来 3 年内的合规与漏洞兜底问题是真实存在的；与其等内部决策，不如提前评估迁移路径（无论选 TDSQL、PolarDB、OceanBase 还是 PostgreSQL 生态），这是后端架构组今年应该立项的事，前端同学在涉及到数据接口与权限的改造里也要保留迁移弹性。
返回首页