信创替代背景： 2020 年以来，国家大力推进信息技术应用创新（信创），数据库作为基础软件的核心环节，替代需求最为迫切。 替代路径： • Oracle → TiDB / OceanBase（分布式替代） • Oracle → openGauss / 达梦（单机/主备替代） • MySQL → TiDB（无缝兼容迁移） • PostgreSQL → openGauss（高度兼容迁移） 三款主流国产数据库概览： TiDB（PingCAP，39k+ Stars） 定位：分布式 HTAP 数据库 兼容：MySQL 协议 架构：计算存储分离（TiDB + TiKV + PD） 开源协议：Apache-2.0 OceanBase（蚂蚁集团，9k+ Stars） 定位：金融级分布式数据库 兼容：MySQL + Oracle 双模 架构：Shared-Nothing 对等架构 开源协议：MulanPSL-2.0 openGauss（华为，7k+ Stars） 定位：企业级关系数据库 兼容：PostgreSQL 架构：主备架构（支持分布式扩展） 开源协议：MulanPSL-2.0 选型核心考量： • 业务场景：OLTP / OLAP / HTAP • 现有技术栈：MySQL 系还是 PG 系 • 团队能力：分布式运维经验 • 合规要求：信创目录、等保测评 • 生态成熟度：工具链、社区支持

架构解析： TiDB 采用计算存储分离架构，三大核心组件： • TiDB Server：SQL 计算层（无状态，可水平扩展） • TiKV：分布式 KV 存储引擎（基于 Raft 协议） • PD（Placement Driver）：元数据管理和调度中心 • TiFlash（可选）：列存引擎，加速 OLAP 查询 MySQL 兼容性（★★★★☆） • 兼容 MySQL 5.7/8.0 协议 • 大部分 MySQL 语法直接可用 • 支持 MySQL 驱动和 ORM 框架 • 注意事项：自增 ID 非严格递增、部分函数行为差异、不支持存储过程和触发器 核心优势： 1. HTAP 能力（★★★★★） • 同一集群同时处理 OLTP 和 OLAP • TiFlash 列存实时同步，分析查询加速 10-100 倍 • 无需 ETL 到独立数仓 2. 弹性扩缩容（★★★★★） • 在线扩缩容，业务无感知 • 计算和存储独立扩展 • 分钟级扩容 3. 运维工具（★★★★☆） • TiUP：一键部署/升级/扩缩容 • Dashboard：可视化监控和诊断 • DM（Data Migration）：MySQL 全量+增量迁移 • Lightning：大数据量快速导入 生态与社区（★★★★★） • GitHub 39k+ Stars，国产数据库最活跃 • 完善的中英文文档 • AskTUG 社区（20w+ 用户） • 丰富的企业实践案例 适用场景： • MySQL 分库分表替代（数据量大、跨库 JOIN 多） • 实时报表和分析（HTAP 场景） • 弹性扩展需求（业务增长快）

架构解析： OceanBase 采用 Shared-Nothing 对等架构： • 每个节点（OBServer）同时承担计算和存储 • 数据按 Partition 分布，Paxos 协议保证一致性 • 支持多租户（Multi-Tenant）资源隔离 兼容性（★★★★★） • MySQL 模式：高度兼容 MySQL 5.6/5.7/8.0 • Oracle 模式：兼容大部分 Oracle 语法（PL/SQL、存储过程、包） • 双模切换：创建租户时选择模式 • Oracle 替代方面，OceanBase 是兼容度最高的国产数据库之一 核心优势： 1. 金融级可靠性（★★★★★） • 城市级容灾：三地五中心部署 • RPO = 0：基于 Paxos 的强一致 • 支付宝双十一核心交易系统验证 • 银行核心系统替代案例最多 2. 多租户（★★★★★） • 物理资源池化，租户间隔离 • CPU/内存/存储按需分配 • 适合 DBaaS 和 SaaS 场景 3. LSM-Tree 存储引擎（★★★★☆） • 高压缩比（通常 3-5 倍） • 适合写密集型场景 • 合并（Compaction）需要关注调优 运维工具： • OBD（OceanBase Deployer）：部署管理 • OCP（OceanBase Cloud Platform）：企业级管控平台 • OMS（OceanBase Migration Service）：数据迁移 • ODC（OceanBase Developer Center）：开发者工具 适用场景： • 金融核心系统（银行、保险、证券） • Oracle 替代（Oracle 模式兼容度高） • 多租户 DBaaS 平台 • 写密集型高压缩场景

架构解析： openGauss 基于 PostgreSQL 早期版本开发，由华为开源： • 内核基于 PG 9.2 深度改造 • 支持主备部署和分布式扩展（ShardingSphere 集成） • MOT（Memory-Optimized Table）内存引擎 PostgreSQL 兼容性（★★★★☆） • 兼容大部分 PG 语法和数据类型 • 支持 PG 驱动和工具 • 注意事项：部分扩展不兼容、系统表有差异、PG 新版本特性可能缺失 核心优势： 1. 高性能（★★★★☆） • NUMA-Aware 架构优化 • MOT 内存引擎（纯内存场景性能优异） • AI 自调优（openGauss AI4DB） • 鲲鹏芯片深度优化 2. 安全特性（★★★★★） • 全密态计算（数据加密计算，不解密即可查询） • 防篡改账本数据库 • 动态数据脱敏 • 细粒度审计 3. 华为生态集成（★★★★☆） • 鲲鹏 + 欧拉 OS 深度优化 • GaussDB（华为云商业版）无缝升级 • 华为 ICT 项目捆绑 运维工具： • gs_om：集群管理 • gs_basebackup：备份恢复 • gs_dump / gs_restore：逻辑备份 • DataKit：可视化运维平台 生态说明： • 商业发行版：华为 GaussDB、海量数据 Vastbase、云和恩墨 MogDB • 社区相比 TiDB 和 OceanBase 较小 • 文档以中文为主 适用场景： • 华为/鲲鹏生态项目 • PG 系替代需求 • 安全合规要求高的场景（政务、军工） • 需要内存数据库能力的场景

┌──────────────────┬──────────────────┬──────────────────┬──────────────────┐ │ 对比维度 │ TiDB │ OceanBase │ openGauss │ ├──────────────────┼──────────────────┼──────────────────┼──────────────────┤ │ 核心定位 │ 分布式 HTAP │ 金融级分布式 │ 企业级单机/主备 │ │ 兼容协议 │ MySQL │ MySQL + Oracle │ PostgreSQL │ │ 架构模型 │ 计算存储分离 │ Shared-Nothing │ 主备 + 分布式 │ │ HTAP 能力 │ ★★★★★ │ ★★★☆☆ │ ★★☆☆☆ │ │ 金融级容灾 │ ★★★★☆ │ ★★★★★ │ ★★★☆☆ │ │ Oracle 兼容 │ ☆☆☆☆☆ │ ★★★★★ │ ☆☆☆☆☆ │ │ 弹性扩缩容 │ ★★★★★ │ ★★★★☆ │ ★★★☆☆ │ │ 运维复杂度 │ 中等 │ 较高 │ 较低 │ │ 社区活跃度 │ ★★★★★ │ ★★★★☆ │ ★★★☆☆ │ │ 文档完善度 │ ★★★★★ │ ★★★★☆ │ ★★★☆☆ │ │ 学习曲线 │ 中等 │ 较陡 │ 平缓（PG 基础） │ │ 信创目录 │ ✔ │ ✔ │ ✔ │ │ 开源协议 │ Apache-2.0 │ MulanPSL-2.0 │ MulanPSL-2.0 │ │ 最低部署规格 │ 3 节点 │ 3 节点 │ 单节点 │ └──────────────────┴──────────────────┴──────────────────┴──────────────────┘ 性能参考（TPC-C 类场景）： • TiDB：线性扩展，节点越多性能越高 • OceanBase：TPC-C 世界纪录保持者（7.07 亿 tpmC） • openGauss：单机性能优异（MOT 引擎 150 万 tpmC） 注意：性能数据仅供参考，实际表现取决于硬件配置、数据模型和查询类型。

迁移策略总则： 1. 评估阶段 • 梳理现有数据库的表结构、数据量、SQL 特征 • 使用兼容性评估工具检查语法兼容性 • 识别不兼容的功能点（存储过程、触发器、特有函数） 2. 测试阶段 • 搭建目标数据库测试环境 • 全量数据迁移测试 • 核心 SQL 回放和性能对比 • 压力测试验证 3. 迁移工具： MySQL → TiDB： • DM（Data Migration）：全量 + 增量同步 • TiDB Lightning：大数据量快速导入 • Dumpling：逻辑导出工具 • 注意：检查自增 ID 使用方式、分区表兼容性 Oracle → OceanBase： • OMS（OceanBase Migration Service） • 支持结构迁移 + 全量 + 增量 + 数据校验 • Oracle 模式兼容大部分 PL/SQL • 注意：检查 DBMS_* 包、自定义类型使用 PostgreSQL → openGauss： • gs_dump / gs_restore • Chameleon 迁移工具 • 注意：检查扩展依赖、系统表引用 4. 灰度切换 • 双写过渡期：新旧库同时写入，读新库 • 回滚方案：保持旧库可用至少 2 周 • 监控指标：响应时间、错误率、数据一致性 与 ora100 生态的配合： • 迁移前：使用 DBCheck 对源库做全面巡检，了解当前状态 • 迁移中：使用 Archery 管理目标库的 Schema 变更 • 迁移后：使用 DBCheck 对目标库做健康检查，确认迁移质量