openGauss/GaussDB 与高可用灾备

• Ustore 原地更新
• 行级 MVCC
• 相比 Astore 的优势

openGauss 默认提供 Astore（追加更新）与 Ustore（原地更新）两种存储引擎。Ustore 采用"原地更新 + 行级 MVCC"：更新时直接在原数据页上修改，通过行级版本信息（xmin/xmax、undo 链）实现多版本并发控制，而不是像 Astore 那样靠元组新旧版本追加（append 产生版本链）。Ustore 的优势：消除 / 减小版本链带来的页膨胀与索引膨胀，减少扫描时的版本来回，提升更新密集场景的读性能与空间利用率；undo 基于日志管理，支持更高效的回滚与快照。它特别适合大量更新、高并发事务的 OLTP 场景。

MVCC 的核心是"快照隔离"，Ustore 以"行内原地更新 + undo 版本"实现，比"追加新版本"更省空间、索引更稳定。相比 Astore 的元组版本链，Ustore 减少膨胀与回看成本，是 openGauss 存算演进的关键。

• WAL 写前日志
• Plog（并行日志）多副本同步
• 高可用与一致性

openGauss 的 WAL（Write-Ahead Logging）保证事务原子性：修改数据前先写日志，崩溃后通过 WAL 重放恢复，确保"先有日志再落数据"。在分布式/多副本场景，openGauss 引入 Plog（Parallel log，并行日志）机制：Plog 是主备之间同步的日志，主库把修改以 Plog 形式多副本同步到备库，保证副本一致性。Plog 支持并行/流水线同步，减少同步延迟，配合 WAL 的持久化，实现强一致（同步复制）或准同步（异步复制）的副本体系。WAL 管"崩溃恢复"，Plog 管"多副本同步"，二者结合支撑高可用与数据不丢失。

WAL 是本地崩溃恢复的基石，Plog 是主备同步的载体。多副本同步通过 Plog 把主库日志流式复制到备库，同步模式决定 RPO（同步复制 RPO=0，异步复制有丢数据风险）。Plog 的角度偏向"日志即数据"。

• 全密态计算
• 密文等值/聚合
• 合规与安全价值

openGauss 的全密态计算（Full Encryption）使数据在数据库中始终以密文存储，敏感字段（如证件号、手机号）在服务端不可见（密钥由客户端持有），但数据库仍能对密文执行部分计算。全密态等值查询：通过确定性加密（保序/保等值）让数据库能对密文做等值比较（=）并返回正确结果；全密态聚合：支持对密文做 SUM/COUNT 等聚合运算（通过同态性质或加密算法）。原理是客户端加密、服务端在密文上运算、客户端解密，密钥不落到服务端。合规价值：满足"数据不出域""最小化明文暴露""等保/个保法"等高安全要求，即使数据库被攻破或 DBA 越权，也无法直接读取明文。

全密态的价值在于"防内鬼 + 防拖库"：服务端只存密文，密钥在客户端，数据在服务端始终是密文。代价是可行的运算受限（等值、部分聚合），且性能有开销，适用于高敏感字段场景。

• NUMA 绑核
• Gazelle 用户态网络
• 性能优化

openGauss 针对高性能 X86/ARM 服务器做了 NUMA 优化：NUMA 绑核（numa binding）把数据库线程/进程绑定到特定 NUMA 节点与 CPU 核，使内存访问尽量在该节点本地，避免跨 NUMA 访问的远程内存延迟，提升缓存命中与吞吐。Gazelle 是 openGauss 引入的用户态网络栈（基于 DPDK 等）：绕过操作系统内核网络协议栈，在用户态直接处理网络包，减少中断、拷贝与系统调用开销，显著降低网络延迟与 CPU 开销，适合高并发短连接场景。二者结合：NUMA 优化内存局部性，Gazelle 优化网络 IO，共同提升高并发数据库性能。

性能优化从"内存局部性"与"网络路径"两个瓶颈入手。NUMA 绑核避免跨节点内存访问，Gazelle/DPDK 用用户态轮询绕过内核网络栈，减少上下文切换与拷贝，是国产数据库在硬件级优化上的典型手段。

• KingbaseES 与 PostgreSQL 兼容
• 生态与工具
• 信创替代能力

人大金仓 KingbaseES 是国内主流的国产关系型数据库，其内核高度兼容 PostgreSQL（基于 PostgreSQL 演进），并针对 Oracle 兼容做了增强。KingbaseES 兼容 PostgreSQL 的 SQL 语法、数据类型、PL/pgSQL、扩展与工具（psql、pg_dump 等），因此从 PostgreSQL 迁移到 KingbaseES 成本较低；同时提供 Oracle 兼容模式（存储过程、包、函数、dual、序列等）以承接 Oracle 迁移。生态上，KingbaseES 支持主流 JDBC/ODBC、连接池、中间件（Tomcat、WebLogic）、BI 工具与国产硬件（鲲鹏、飞腾、统信/麒麟），并配套迁移工具、运维架构与文档，是信创（国产化替代）数据库的主流选择之一。

兼容性决定迁移成本。KingbaseES 以 PostgreSQL 兼容为基石（降低从 PG 迁移成本），叠加 Oracle 兼容模式（承接 Oracle 存量），配合完整工具链与国产生态，实现"低门槛、可落地"的信创替代。

• GBase 8a 定位（OLAP）
• GBase 8s 定位（OLTP）
• 场景适配

GBase（南大通用）有两类产品：GBase 8a 面向 OLAP/分析（数据仓库/数据集市），采用列式存储 + MPP 分布式架构，支持大规模并行、列存压缩、向量化与大表分析，适合海量数据统计分析、决策支持；GBase 8s 面向 OLTP 事务（在线交易），采用行式存储与高可用架构，支持标准 SQL、事务、约束、索引，适合高并发交易、核心业务系统。两者定位互补：8a 管"分析/报表"，8s 管"交易/事务"，在信创大库建设中常分别用于分析库与业务库。

"8a 分析、8s 事务"是核心。区分依据是负载特性：OLAP 需列存 + MPP + 分析算子，OLTP 需行存 + 事务 + 索引 + 高并发。选型时按业务类型（分析 vs 交易）选择对应产品，避免用错导致性能与功能不匹配。

• Oracle 存储过程/包/同义词兼容
• 兼容层与兼容模式
• 迁移评估

国产库（如达梦、KingbaseES、openGauss、OceanBase 等）普遍提供 Oracle 兼容模式，但对 Oracle 特性的兼容程度不一：存储过程（PL/SQL 语法、变量、游标、异常、动态 SQL）大多兼容，但复杂特性（嵌套集合、%TYPE/%ROWTYPE、自治事务、外部过程）兼容度需个案评估；包（PACKAGE）多数支持，但包体内的高级特性（重载、初始化块、私有函数）可能需改写；同义词（SYNONYM）多数支持公有/私有同义词，但跨库同义词与权限模型有差异。评估方法是：用 SCT/迁移工具 + 静态脚本扫描 + 实际运行测试，统计"可转换/需改写/不支持"的对象比例，并针对关键业务（如核心存储过程）做专项验证。

兼容程度决定迁移工作量。Oracle 的 PL/SQL 与包、同义词是高频特性，但"可用"不等于"完全兼容"，需分层评估：语法兼容、语义兼容、性能兼容。用工具扫描 + 实测近似，避免想当然认为"兼容模式=无需改造"。

• 语法差异
• 类型映射
• 函数改写

从 Oracle/MySQL/PostgreSQL 迁移到国产库需处理三类差异：1) 语法差异：如 SELECT ... FROM dual（Oracle 专用）、SELECT TOP vs LIMIT、ROWNUM vs 窗口函数、MERGE 兼容性、CONNECT BY 层次查询（Oracle 特有，国产库需改写为递归 CTE）、分页与字符串拼接（|| vs concat）。2) 类型映射：Oracle 的 NUMBER/VARCHAR2/DATE/CLOB 映射到国产库的 numeric/varchar/timestamp/clob，MySQL 的 int/varchar/datetime 同理，注意精度、长度、时区与默认值差异。3) 函数改写：Oracle 的 NVL/TO_DATE/SUBSTR 等，国产库可能需替换为对应函数或改写为 CASE WHEN。改写通过迁移工具 + 静态扫描 + 测试验证完成。

迁移的实质是"语义等价改写"。类型映射保证数据不丢，语法差异保证可执行，函数改写保证逻辑等价。三者都需用工具辅助 + 人工复核 + 实机验证，重点处理 Oracle 特有语法（CONNECT BY、ROWNUM、dual）与函数。

• 主备复制高可用
• 共享存储高可用
• 分布式架构

国产库高可用方案主要有三类：1) 主备复制：主库写、备库复制（同步/异步），故障时主备切换，实现 RPO=0（同步）或较小 RPO（异步），RTO 由切换时间决定，是主流方案（如达梦 DM 主备、openGauss 主备、GaussDB 同城热备）；2) 共享存储：多实例共享同一存储（如 SAN/卷），共享存储故障转移，避免复制延迟，但存储本身是单点，通常配合存储级高可用；3) 分布式：通过多副本 + 一致性协议（如 OceanBase 的 Paxos、TiDB 的 Raft）实现多副本强一致与自动故障转移，RPO=0、RTO 秒级，并能跨区域容灾。方案选型取决于 RPO/RTO 要求、成本与部署复杂度。

高可用的本质是"故障时数据不丢、业务快速恢复"。主备最简单但同步延迟权衡，共享存储避免复制但依赖存储，分布式用多副本协议换强一致与自动切换。选型依据 RPO/RTO 目标与容灾半径。

• 兼容性挑战
• 应用改造
• 性能与稳定性

信创替代中 Oracle/MySQL → 国产库的挑战包括：1) 兼容性：Oracle 特有语法（PL/SQL、包、CONNECT BY、同义词、ROWNUM、高级 SQL）与 MySQL 特性（存储引擎差异、自增、JSON、分区）在国产库的兼容程度不一，导致大量改写；2) 应用改造：JDBC/驱动、SQL、存储过程、ORM 映射、端到端联调需改造验证；3) 性能与稳定性：国产库在复杂查询、高并发、长事务、优化器上的表现需验证，可能存在性能抖动或功能缺失；4) 工具链：监控、备份、运维、中间件生态成熟度；5) 迁移本身的停机窗口、数据一致性、双写校验。挑战是"迁移不只是换库，而是换生态"，需系统化评估与充分测试。

信创替代的难点在"兼容性深度 + 生态成熟度 + 风险控制"。迁移前需用兼容性评估量化改造量，迁移中做双写验证与回滚方案，迁移后做性能回归与长期观察，把"换库"当作"换平台"系统工程。

• 应用改造范围
• 驱动/连接/ORM
• SQL 与存储过程

应用改造范围包括：1) 驱动与连接：更换/适配 JDBC/ODBC 驱动、连接串、连接池配置（国产库驱动差异）；2) SQL 与存储过程：改写不兼容的 SQL（ROWNUM、CONNECT BY、dual、函数、分页、类型）、存储过程/包/触发器改写；3) ORM 与数据访问层：调整 ORM 映射、方言（dialect）、主键策略、批量操作；4) 应用配置：数据源、事务管理、序列、字符集/时区；5) 运维与监控脚本：备份、监控、初始化脚本适配。改造量取决于兼容度评估，通常"数据访问层 + SQL + 存储过程"是主要工作量，需测试回归。

改造范围由"兼容度"决定。兼容度高的部分（标准 SQL、基础驱动）改动小，不兼容部分（Oracle 专用语法、存储过程）改动大。清晰列出改造范围并分类（需改/可改/不需改）是迁移计划的关键。

• JDBC 驱动兼容性
• 连接池配置适配
• 驱动与连接池协同

国产库（达梦、KingbaseES、openGauss、GBase、OceanBase 等）大多提供兼容 JDBC 的驱动，通常兼容 PostgreSQL/MySQL 的 JDBC 接口（如 openGauss 兼容 PostgreSQL 驱动、KingbaseES 兼容 PG 驱动），但 URL、驱动类名、参数名与行为存在差异。适配要点：1) 驱动类名与连接串：按各库规范配置驱动名（如 com.opengauss.Driver、dm.jdbc.driver.DmDriver）与 URL 格式（含端口、schema、参数）；2) 连接池：将连接池（HikariCP/Druid/Tomcat）的 driverClassName、jdbcUrl、验证查询、连接超时、最大/最小连接数按国产库调整；3) 特性差异：国产库对预处理语句、批量、事务、元数据、字符集/时区的支持与 PG/MySQL 略有差异，需在驱动层验证；4) 版本匹配：驱动版本与数据库版本需匹配，避免协议不兼容。适配后需做连接池负载、连接断开恢复、并发获取的回归测试。

驱动与连接池是应用访问数据库的第一层。适配的关键是"驱动类名/URL/参数"与"连接池行为"双侧对齐，并处理国产库在预处理、批量、事务、元数据上的差异，避免"能连上但不稳定"。

• 备份类型（全量/增量/日志）
• PITR 时间点恢复
• 恢复演练与一致性

国产库（openGauss、GaussDB、达梦、KingbaseES、OceanBase 等）普遍支持全量备份、增量备份与日志（WAL/归档）备份，并基于"全量 + 归档日志/redo 重放"实现 PITR（Point-in-Time Recovery）：恢复到指定时间点，用于误操作、数据损坏后的精确回滚。PITR 的原理是用某个时间点的全量备份作为基线，再重放该时间点之后的归档日志到目标时间点。能力评估需关注：备份粒度（库/表/表空间）、备份工具（gaussdb 的 gs_basebackup、达梦的 dmrman、OB 的物理备份）、是否支持增量与压缩、归档是否完整、恢复时间点精度、以及一致性保证（物理一致性/逻辑一致性）。需定期做恢复演练验证 PITR 可用。

备份恢复的核心是"能恢复、能恢复到一个准确时间点"。PITR 依赖"全量基线 + 完整归档日志"，因此归档策略与恢复演练决定恢复能力。评估国产库时需验证备份工具、粒度、PITR 精度与恢复演练的可行性。

• 分布式事务（XA/2PC）
• 两阶段提交协议
• 协调者与参与者

国产库在多库/跨节点事务中通常提供分布式事务支持，常见实现是两阶段提交（2PC）与 XA 协议。2PC 分两个阶段：准备阶段（prepare），协调者向所有参与者发送 prepare，各参与者执行事务并写日志、锁定资源、返回 ready/abort；提交阶段（commit/abort），若所有参与者都 ready，协调者广播 commit，各参与者提交并释放资源；否则广播 abort 回滚。分布式事务管理器（如 XA 接口、应用层 TM）协调各库。代表性实现如 OceanBase 的 RPC 事务协调、达梦的分布式事务、GaussDB 的 2PC 与全局事务。2PC 的代价是阻塞风险（协调者故障时参与者可能悬挂）与性能开销，需配合超时与故障恢复。

2PC 是分布式事务的经典方案，保证跨库原子性。关键在"两阶段"的协调与故障处理：prepare 后锁定资源，commit 阶段统一提交。国产库会用 XA/2PC 或自研协调，评估时关注协调者高可用、超时与悬挂恢复。

• LSM-Tree 分层（memtable/transient/sstable）
• minor dump（转储）与 major merge（合并）
• 写放大、查询性能与调度影响

OceanBase 采用 LSM-Tree 存储，写入先进入内存的 memtable（每租户每分区一个），达到阈值后触发 minor dump（转储）：把 memtable 落盘为 frozen（可读的临时 sstable），此时数据仍在内存可读，转储是轻量操作。周期性（如每日）执行 daily major merge（合并）：把所有 minor 产生的 sstable 与已有数据合并、去重、压缩，生成新的 sstable，并清理旧版本。major merge 的影响：1) 写放大：合并会把大量数据重写，产生写放大，消耗 IO 与磁盘；2) 查询性能：合并后数据更紧凑、块更少，减少扫描与读放大，提升查询性能；3) 集群调度：daily major merge 集中在特定时段，会占用大量 CPU/IO/磁盘资源，需错峰调度、控制并发，避免影响在线业务。OceanBase 通过"合并调度"（如合并窗口、分区并行、限流）平衡。

LSM 的核心是"写内存、读多版本 + 合并"。minor dump 是轻量落盘（快速释放内存），major merge 是深度合并（压缩、去重、调优读性能）。合并是"写放大换读性能"的权衡，且在海量分区下合并调度本身成为集群规划的关键约束。

• clog 日志复制与 Paxos
• 多副本强同步与 leader 选举
• 三地五中心容灾与 RPO=0

OceanBase 用 Paxos 协议在副本间同步 clog（commit log）：写入先写 leader 的 clog，leader 把 clog 复制到多数派（quorum）副本并确认后提交，保证多数派已持久化，从而不论哪些副本故障都能保证数据不丢（强同步）。leader 由 Paxos 选举产生，负责读写；leader 故障时，副本基于日志按序竞选，选出日志最新的副本成为新 leader，实现自动故障转移。RPO=0 来自"多数派持久化"：只要多数派副本存活，提交的事务就不会丢。三地五中心部署（如 3 个城市、5 个机房/副本）把副本分布在多个城市，任何时候至少一个中心存活并持有多数派，实现城市级容灾：单城故障不影响多数派，数据不丢（RPO=0）、业务快速恢复（秒级 RTO）。

Paxos 的多数派（quorum）是"强一致 + 高可用"的基石：多数派持久化保证 RPO=0，多数派存活保证继续可用。三地五中心通过跨城分布副本，使任一城市故障仍有多数派，实现城市级容灾。

• PD 调度与 Region 心跳
• balance-region / balance-leader / hot-region
• Region 分裂/合并

TiDB 数据按 Region 分片，每个 Region 有多个副本并选举 leader。PD（Placement Driver）通过每个 Region 的 leader 周期性上报的心跳（含 Region 大小、行数、读写热点、副本分布）汇总全局状态，并据此执行调度：balance-region（按存储大小均衡各 TiKV 的 Region 数量）、balance-leader（均衡各节点的 leader 数量，分散读写负载）、hot-region（识别读写热点 Region 并迁移/分裂以分散热点）。Region 分裂：当 Region 大小超过阈值（默认约 96MB）或访问热点导致分裂，触发分裂为两个 Region，通过 Raft 分裂流程完成；Region 合并：当 Region 过小（远低于阈值）且适合合并时，相邻 Region 合并以减少元数据与管理开销。分裂/合并都通过 Raft 与 PD 协调保证一致性。

Region 心跳是 PD 的"全局视图"来源，调度策略（大小均衡、leader 均衡、热点）让集群负载均衡、热点分散。分裂解决"Region 过大/过热"，合并解决"Region 过小"，二者动态维持 Region 规模合理，是"弹性扩缩容"的基础。

• Percolator 分布式事务模型
• 乐观事务与悲观事务
• 悲观预加锁的取舍

TiDB 的事务基于 Percolator 模型：通过在 KV 上写主键（primary）与次级键（secondary）的锁（lock->write 记录）、两阶段提交（写阶段、提交阶段）与 TSO 时间戳实现快照隔离与原子性。乐观事务：提交时才检测冲突（写冲突按版本/锁检测），冲突则重试，适合冲突少的场景，但高冲突下重试多、性能差。悲观事务：在 SELECT ... FOR UPDATE 时即对目标行加锁（预加锁），把锁持有到事务结束，避免乐观模式的"提交时才发现冲突"——解决了乐观模式在高冲突下的重试惩罚与"活锁/饥饿"问题（如先到先得、避免反复重试）。代价：悲观锁引入锁开销（锁管理、死锁检测、锁等待）、更长持锁时间可能降低并发度、以及加锁的额外网络/协调开销。TiDB 通过锁与调度器（lock manager）协调。

乐观"先做后查冲突"，悲观"先锁后做"。悲观预加锁把冲突检测提前到写时，减少重试与抢占，适合高冲突/热点更新；代价是持锁与锁管理开销。TiDB 支持两种模式按需选择，平衡并发与冲突处理。

• OceanBase 行列混合与并行执行
• TiDB TiFlash Raft learner 列存
• 分析查询数据新鲜度

HTAP 是"同一库同时支撑 OLTP 与 OLAP"。OceanBase 在进程内实现行列混合：同一张表可同时建行存与列存（列存副本），对 OLAP 查询用列存 + 并行执行引擎（并行 DOP、向量化），OLTP 用行存，通过事务实时更新两种形态，保证分析查询读到最新数据（强新鲜度）。TiDB 通过 TiFlash 列存副本实现：TiFlash 作为 Raft learner（学习者，不参与投票）通过 Raft 协议实时同步 TiKV 的变更，把数据以列存存储，OLAP 查询路由到 TiFlash 并行执行；TiFlash 用 Raft 同步保证数据接近实时（通常是秒级，读己之写/强一致可配置）。两者都以"多副本 + 实时同步"保证分析数据新鲜度：OB 用行/列双写同事务，TiDB 用 Raft learner 同步。新鲜度取决于复制延迟与一致性设置。

HTAP 的核心是"一份数据、两种访问形态"。OB 用行列混合 + 并行执行，TiDB 用列存 learner 副本。新鲜度都靠"实时同步/复制"保证，OB 基本强一致，TiDB 接近实时（可调强一致），二者在新鲜度与性能间权衡。

• 多租户与 Unit/Resource Pool
• 租户间资源与数据隔离
• 单机分布式一体化与资源售卖

OceanBase 采用多租户架构：一个集群划分为多个租户，每个租户拥有独立的资源（Unit/Resource Pool）与数据。Unit 是资源的最小分配单元（CPU、内存、磁盘等），Resource Pool 由多个 Unit 组成并映射到租户；租户通过"资源池"获得资源配额，租户间资源隔离（CPU/内存/IO 配额）与数据隔离（逻辑隔离，数据不互通）。这套模型支撑"单机分布式一体化"：同一套架构既能单机部署（小规模），也能水平扩展为分布式集群（多台），业务只是在租户资源上伸缩。对资源售卖（云数据库/DBaaS）：可按租户售卖资源（按 CPU/内存/存储计费），租户间弹性伸缩，实现多租户共享集群资源、按需售卖，是云原生数据库的经典形态。

多租户的本质是"资源共享 + 资源/数据隔离"。Unit/Resource Pool 把物理资源抽象为可分配、可售卖的资源池，租户独立配额与隔离。单机分布式一体化让同一内核从单机到分布式平滑扩展，配合多租户实现按需售卖与弹性伸缩。

• auto analyze 统计信息收集
• 查询计划质量
• TSO 全局授时与事务吞吐

TiDB 有一套统计信息自动收集机制（auto analyze）：定期/按需对表做 ANALYZE 收集行数、基数、直方图等统计，供优化器估算成本、选择 join 顺序与索引，统计过期会导致行数估算偏差、选错执行计划（性能退化）。因此 auto analyze 的及时性直接影响查询计划质量。TSO（Timestamp Oracle）是 PD 提供的全局单调时间戳，用于事务的 start_ts/commit_ts 与 MVCC 快照。TSO 分配是串行（PD 单点发放批次时间戳），高并发下 TSO 请求会成为事务吞吐的瓶颈：若 TSO 分配延迟高，事务获取时间戳变慢，吞吐受限。因此 PD 的 TSO 性能（批次发放、缓存、跨 DC 同步）决定全局事务吞吐上限。两者分别卡"查询计划质量"与"事务吞吐"。

auto analyze 影响"查询有多快"（计划质量），TSO 影响"事务能多密集"（吞吐）。统计及时性避免计划回归，TSO 的批次发放与低延迟避免事务瓶颈。二者是 TiDB 分布式查询与写入性能的关键。

• 大事务处理
• Oracle 兼容
• 稳定性与性能抖动

金融核心系统（银行账务、支付、证券）对数据库要求极高，OceanBase/TiDB 落地时遇到的内核级难题包括：1) 大事务：金融常有批量/长事务（如批量结息、对账），分布式库的分布式事务在超大事务下会放大锁、日志、协调开销，需优化大事务处理（分片、事务拆分、内存/日志管理）；2) Oracle 兼容：金融存量大量使用 Oracle PL/SQL、包、序列、dual、高级 SQL，需在兼容层逐项实现，成本高、周期长；3) 稳定性与性能抖动：在重负载下出现偶发性能抖动（如 GC/合并、排查、热点、调度导致的延迟尖峰），需做内核级优化（限流、优先级、合并调度、资源隔离）与大量压测；4) 高可用、数据一致性、两地三中心容灾也是硬指标。这些难题通过内核迭代、参数调优、业务适配与持续压测逐步解决。

金融核心是"最高的可靠性/性能/兼容性门槛"。大事务挑战分布式事务能力，Oracle 兼容挑战迁移成本，性能抖动挑战稳定性，均需内核级优化与业务侧适配结合，并通过严格压测与灰度验证。

• 在线 DDL 需求
• TiDB F1 schema 版本渐进变更
• OceanBase 并行 DDL

在线 DDL 目标是"变更表结构时不阻塞业务读写"。TiDB 借鉴 Google F1 的 schema 版本渐进变更（schema version / state machine）协议：把一次 DDL 分解为多个 schema 状态（如 absent、delete only、write only、write reorg、public），各节点按版本逐步迁移，DDL 期间数据重写（reorg）与业务读写并发进行，通过版本号协调避免锁表，且 DDL 可中断恢复。OceanBase 采用并行 DDL：把 DDL 的数据任务（如加列重建、改类型）并行化执行，多个 worker 并行扫描/重写数据，配合在线 schema 变更机制，减少阻塞窗口、提升大表 DDL 效率。两者都避免"传统锁表式 DDL"，实现"变更不阻塞、可并行、可恢复"。

在线 DDL 的核心是"把 schema 变更与数据重写从阻塞中解放"。TiDB 用版本状态机渐进推进（类似 F1），OceanBase 用并行化重写，二者都让 DDL 与业务并发、可中断恢复，避免大表 DDL 锁表长时间阻塞。

• MPP 单机/分布式架构
• 线程池模型
• 高并发处理

openGauss 支持单机与分布式（MPP）两种形态：单机形态是高性能关系库；分布式（MPP）形态通过多节点并行计算，把查询拆分、并行执行，适合大表分析，但会引入分布式事务与协调开销。openGauss 采用线程池（thread_pool）模型处理高并发：为减少频繁创建/销毁进程（或线程）的开销，采用"线程池 + 队列"模型，多个 worker 线程复用处理连接请求，会话通过队列分配线程，避免连接数高时的进程/线程开销与上下文切换，提升高并发下的吞吐与稳定性。线程池模型（_thread_pool 相关参数）配合 NUMA 绑核，成为 openGauss 高并发优化的关键。

单机/分布式双形态让 openGauss 按需扩展，MPP 面向分析并行。线程池复用线程替代传统"一连接一线程"，降低高并发下的创建/调度开销，是提升并发吞吐与稳定性的核心模型。

• oGRAC 多读多写
• 全局一致性
• 共享存储集群

oGRAC（openGauss RAC，类 Oracle RAC）是 openGauss 的共享存储集群架构：多个只读/读写节点共享同一份存储（SAN/共享卷），实现多读多写（即多个节点可同时读写），用于高可用与横向扩展。多节点并发读写需要全局一致性协调：openGauss 通过资源管理（缓存一致、锁管理、全局 MVCC/事务协调）保证各节点看到一致的快照与全局状态，例如共享缓存一致性、全局锁、事务与日志的全局协调。oGRAC 相比单节点，提供故障转移与扩展，但共享存储是依赖与潜在单点，需存储级高可用保障。全局一致性是实现"多节点像一个库"的关键。

共享存储多节点（RAC 式）的核心是"多节点共享数据 + 全局一致"。oGRAC 通过缓存协调、全局锁与事务协调实现多读多写的一致视图，提升可用性与扩展，同时也把依赖集中在共享存储上。

• DataVec 向量引擎
• 向量检索与相似度
• 四模融合查询

openGauss 的 DataVec 是向量数据引擎，支持向量数据类型、向量索引（HNSW/IVF 等）与相似度检索（余弦、欧式、内积），用于 AI/大模型应用中的向量检索（语义搜索、RAG）。其特色是"四模融合"：在同一数据库内融合标量（关系数据）、向量（embedding）、全文（文本检索）与图（图结构）四种查询能力，做到"一个查询同时混合标量过滤 + 向量相似度 + 全文关键词 + 图关系"的混合检索，无需多套系统。例如"找文本相关且向量相似且满足 JSON 过滤的记录"。四模融合让单一数据库支撑复杂 AI 检索场景，减少系统集成成本。

向量引擎解决"语义相似度检索"，四模融合把它与标量/全文/图统一在一个查询里。DataVec 的价值是"多模态检索一体化"，契合 AI 应用对混合检索的需求，减少多库集成。

• GaussDB 与 openGauss 关系
• 内核同源
• 云上形态与商业化

openGauss 是华为开源的关系型数据库（open source），GaussDB 是华为云上的商业数据库产品。二者的内核同源：openGauss 是 GaussDB 的开源内核，GaussDB 在 openGauss 内核基础上进行商业化增强（企业级特性、云服务、安全、运维、性能优化），并作为云数据库（GaussDB for MySQL/GaussDB 等）提供服务。openGauss 面向社区与开源生态，GaussDB 面向企业/云上商业化场景，两者共享内核、生态与迁移适应性。云上形态：GaussDB 提供云托管、弹性伸缩、高可用、备份恢复、监控等 DBaaS 服务，支持多种兼容模式（MySQL/PostgreSQL/Oracle）。从 openGauss 到 GaussDB 迁移成本低。

"openGauss 开源内核，GaussDB 商业化云服务"是核心关系。同源内核保证迁移兼容，GaussDB 在云上形态提供企业级托管与增强，openGauss 贡献开源社区与普惠，二者互补。

• 达梦 DM Oracle 兼容
• 兼容模式与语法
• 迁移适配点

达梦 DM 是国内主流国产数据库，提供 Oracle 兼容模式（兼容 Oracle 的 SQL 语法、PL/SQL、数据类型、函数、dual、序列、同义词、包等），让 Oracle 应用能以较低成本迁移。迁移适配点：1) 语法差异：ROWNUM、CONNECT BY、DUAL、层次查询、PL/SQL 包/存储过程等部分兼容，复杂特性需改写；2) 类型映射：NUMBER、VARCHAR2、DATE、CLOB 等映射到 DM 类型；3) 函数与运算符：Oracle 专用函数（NVL、TO_DATE、DECODE）需核对是否存在对应实现；4) 工具与生态：DM 提供迁移工具（DM 迁移工具、DTS）、兼容 psql 的工具与 JDBC/ODBC 驱动；5) 高可用与运维：DM 提供主备、集群、备份恢复。适配需用工具扫描 + 实测，重点验证存储过程与高级 SQL。

达梦的 Oracle 兼容模式是"承接 Oracle 存量"的关键，但"兼容"不等于"完全一致"。迁移适配要落实到语法、类型、函数、建模与工具链，用工具 + 实测评估改造量，重点处理 Oracle 特有语法与存储过程。

• License 与订阅模式
• 开源（openGauss 系）模式
• 选型与成本

国产库在商业模式上分两类：商业授权（License/订阅）与开源（openGauss 系等）。商业模式（如达梦、GaussDB、KingbaseES、OceanBase 商业版）通过 License（按核/按节点/按功能）或订阅（云上按量/包年）收费，提供企业级支持、商业特性、安全合规与售后，适合有合规与支持要求的核心系统。开源模式（openGauss 系、部分开源发行版）以开源许可（如 Mulan/木兰）提供社区版，可自由使用、自研改造，配合社区/商业发行版（海量、Vastbase、openGauss 官方企业版）获得支持。选型需权衡：商业版有保障与契约，开源版更灵活低成本、但需自建运维；openGauss 系开源 + 商业发行版并存，兼顾开放与商业化。License 审计与合规（开源许可、商业授权）也是选型要点。

商业模式决定"成本与保障"。商业 License/订阅提供支持与合规，开源（openGauss 系）提供灵活与低成本。选型需结合业务重要性、支持需求、预算与合规，评估商业授权或开源许可的约束。

• 数据类型映射
• SQL 方言兼容层
• 兼容层实现

异构数据库迁移会用到"兼容层"（compatibility layer）：在一套数据库里实现另一套数据库的语法与类型，降低迁移成本。数据类型映射：把源库类型映射到目标库等价类型（如 Oracle NUMBER到numeric、VARCHAR2到varchar、DATE到timestamp，MySQL int到integer、datetime到timestamp），并处理精度、长度、默认值、时区差异。SQL 方言映射：在兼容层识别并转换源库的方言语法（如 Oracle 的 ROWNUM、CONNECT BY、dual、NVL、字符串拼接 ||，MySQL 的 LIMIT、json 函数），把不兼容语法改写为目标库等价实现。兼容层通过"语法解析 + 改写（rewrite）+ 类型/函数映射"在解析或执行阶段转换，使应用几乎不改代码即可运行。实现难度在于方言的广度与语义微妙差异。

兼容层是"异构迁移的润滑剂"。核心是类型映射（保证数据不丢）+ 方言转换（保证可执行），通过解析改写程序实现。目标是"应用少改、兼容度高"，但复杂方言与语义差异仍需人工处理。

• 存量同步（全量）
• DataKit/DTS 工具
• 同步一致性与性能

数据迁移的"存量同步"指把源库现有数据一次性全量复制到目标库。常用工具：DataKit（openGauss 的迁移工具箱）、DTS（国产云/各家数据传输服务，如 GaussDB DTS、DM DTS）、以及自研脚本。存量同步流程：1) 结构迁移（schema/DDL 先建表）；2) 数据全量并发读取源（分片/并行扫描）到类型转换再到批量写入目标（COPY/批量 INSERT）；3) 一致性校验（行数、关键字段、checksum）。存量同步的关键：性能（并发、分片、批量）、一致性（源在同步期间可能变化，需与增量/CDC 配合先存量后增量追平）、断点续传（失败重试）。DataKit/DTS 提供 GUI/命令行、调度、断点续传与校验，自研则需自行实现分片与并发。

存量同步是"把存量搬过去"，核心是"快、对、可续"。工具通过分片并发 + 批量写入提速，通过校验保证正确，配合后续增量追平实现平滑迁移。选择工具（DataKit/DTS）还是自研，取决于复杂度与可控性。

• DataKit 运维平台
• 监控与告警
• 运维能力

openGauss 的 DataKit 是官方运维平台，提供数据库的安装部署、运维监控、告警与调优能力。监控方面：DataKit 采集实例的 CPU、内存、磁盘、连接数、慢查询、锁、复制、备份等指标，通过仪表盘可视化，并结合阈值告警（如连接数、磁盘、慢 SQL）通知运维。运维能力：实例管理（启停、参数配置、日志）、备份恢复、迁移、巡检、性能分析（慢 SQL、执行计划）、高可用管理（主备/集群）。DataKit 面向规模化部署，提供集中管理、自动化运维与告警闭环，降低 openGauss 集群的运维成本，是"国产库可观测性/运维平台"的典型。

DataKit 是"openGauss 的运维大脑"：把监控（指标、告警、可视化）与运维操作（管理、备份、调优、迁移）整合到一个平台，实现集中化、自动化运维，是国产库运维体系的重要组成。

• 中间件兼容
• BI/数据集成适配
• 生态成熟度评估

国产库生态成熟度是选型与迁移的关键考量，主要评估几类：1) 中间件：应用服务器（Tomcat、WebLogic、东方通）、连接池（Druid、HikariCP）、消息/AOP 等是否适配国产库驱动；2) BI/报表：主流 BI（Tableau、FineBI、帆软、润乾、Power BI）是否支持国产库的连接与函数；3) 数据集成：ETL（Kettle、DataX、DataWorks）、同步工具（CDC、DTS）、数据仓库对接是否兼容；4) 开发工具：IDE（Datagrip、Navicat）、ORM（MyBatis、Hibernate、JPA）方言适配；5) 国产软硬件生态：鲲鹏/飞腾、统信/麒麟、国产中间件适配。评估方法：查询各厂商《兼容性互认证列表》、做试点对接测试、验证典型应用（报表、ETL、ORM）能否跑通。成熟度决定"能否低门槛落地、需要多少补丁适配"。

生态成熟度决定"能不能用、好不好用"。评估不只看数据库本身，还要看周边工具链（中间件/BI/ETL/ORM/开发工具）是否兼容。成熟度高的库迁移障碍小，成熟度低则需大量适配与自研。

• 社区发行版
• 商业发行版（海量/Vastbase）
• 选型差异

国产库存在"社区发行版 + 商业发行版"的双轨模式，尤其 openGauss 系：社区发行版（openGauss 官方社区版）开源免费，供学习、自研与基础使用；商业发行版由厂商基于开源内核二次开发，提供增强特性、企业级支持与运维，如海量数据（Vastbase，基于 openGauss）、云和恩墨、以及其他 openGauss 商业发行版。商业发行版的价值：企业级稳定性、安全合规、专业支持、性能优化、工具链与信创适配，适合生产核心；社区版则灵活、低成本、可深度定制。选型差异：预算与支持（商业 vs 开源）、合规与等级保护（商业更完善）、二次开发自由度（社区更开放）、长期维护（商业有保障）。需结合业务与合规要求选择。

社区版与商业版是"开源内核 + 商业增值"的生态。社区版追求开放与低成本，商业版（海量/Vastbase 等）提供支持与合规保障。选型要权衡成本、支持、合规与可控性。

• ARM（鲲鹏）适配
• RISC-V 适配
• 信创硬件生态

信创背景下国产库需适配国产/自主指令集硬件。ARM：鲲鹏（华为）是主流国产服务器 CPU，国产库（openGauss、GaussDB、达梦、KingbaseES、OceanBase 等）普遍提供鲲鹏 ARM 版本，做架构优化（NUMA 绑核、指令集优化、内存屏障、并发原子操作适配），性能与 x86 相当。RISC-V：新兴开源指令集，国产库对其适配处于探索/早期阶段，需移植编译、处理指令集差异、做性能调优，生态相对不成熟。适配要点：编译（交叉编译/原生构建）、依赖库（如特定的汇编/原子操作）、性能优化（针对 ARM 的缓存、内存、SIMD）、测试（跨架构回归）。选型时需确认国产库是否提供目标架构（鲲鹏/飞腾 ARM、RISC-V）的正式支持版本与性能验证。

架构适配是信创落地的硬要求。ARM（鲲鹏）适配成熟、有性能优化，RISC-V 处于早期。评估需确认国产库的目标架构版本、优化程度与性能基准，避免"能装但性能不达标"。

• 双写（dual write）
• 数据校验
• 回滚方案

生产迁移常采用"双写 + 校验 + 回滚"策略降低风险。双写（dual write）：在切换前，应用同时把写入发给源库与目标库（或通过 CDC 把源库变更同步到目标库），让目标库持续追上源库，作为切换前的数据对准。校验：对源与目标做一致性校验（行数、累计、关键字段、抽样比对、checksum），确认两边数据一致。回滚方案：切换后若发现问题，可回切到源库——双写阶段保留源库现状，回滚即把流量切回源库并停止目标写入，或回滚到某个已确认的一致点。关键：双写保证目标与源接近一致以便回滚，校验确认一致性，回滚预案明确"何时回滚、如何回滚、回滚后是否丢数据"。双写的代价是应用改造与双倍写入开销。

双写校验回滚是"低风险迁移"的核心。双写让目标与源对准，校验确认一致，回滚预案提供兜底。它把"一次性切换"变成"可观察、可回退"的渐进过程，降低迁移事故风险。

• 性能基线对比
• 回归测试
• 迁移后验证

迁移后需做性能基线对比与回归测试，验证目标库是否达标。性能基线对比：迁移前在源库录制性能基线（关键 SQL 的延迟、吞吐、QPS、p99、资源利用率），迁移后在目标库用相同负载重测，对比延迟/吞吐/资源，确认目标库性能不劣于源（或达到 SLO）。回归测试：覆盖功能（SQL 结果、存储过程、事务、约束）、性能（关键路径、批处理、并发）、兼容性（应用全流程、报表、ETL）的回归，确保迁移后行为一致。注意：对比需同负载、同数据量、同并发，考虑目标库配置差异（列存/索引/统计优化）。发现性能退化需针对性调优（索引、统计、参数、查询改写）。

迁移后的验证是"闭环收尾"。性能基线对比用"前后同负载"量化是否达标，回归测试保证功能与性能不回归。任何退化都需先分析根因（计划、索引、配置）再优化，避免"迁移成功但性能变差"。

• 停机窗口
• 增量追平（追数）
• 平滑切换

迁移的停机窗口指业务暂停（或只读）的时间段，用于最终切换。尽量缩短停机窗口是迁移目标之一。策略：先做存量全量同步，再开启增量（CDC/日志）持续把源库的新变更同步到目标库，让目标库"追平"源库（增量追平）。当增量追平到接近实时（目标与源差距很小或追平）时，进入停机窗口：暂停写入（或切换流量）、做最终一致性校验、把读写切到目标库、关闭增量。停机窗口越短，业务影响越小。增量追平的关键：增量同步性能（能否追上升源）、追平判断（延迟/位点）、最终校验与切换。用"存量 + 增量追平 + 短窗口切换"可把停机从小时级降到分钟级甚至更短。

"存量 + 增量追平 + 短停机切换"是标准迁移节奏。增量追平让目标库在切换前已接近实时，停机窗口只用于最终校验与切换，大幅降低业务中断。追平速度决定能否缩短窗口。

• 信创目录
• 自主可控
• 选型约束

信创（信息技术应用创新）对数据库选型有明确约束：1) 信创目录：选型需在信创产品目录（工信部/各地方信创目录、党政采购目录）内，有目录内认证的产品才可用于信创项目；2) 自主可控：优先选择拥有自主知识产权、源码可控、不依赖国外特定技术栈的国产数据库，满足"自主可控、安全可靠"要求；3) 合规与生态：需满足等保、密码合规、国产软硬件适配（CPU/OS/中间件），并评估长期演进可控性；4) 供应链与风险：避免依赖单一供应商、评估开源许可与商业风险。选型约束意味着"不只是技术选型，更是合规与自主可控的决策"，需在信创目录内选择有自主可控能力、生态完善、有长期存续保障的国产库。

信创选型是"合规优先"的决策。目录内、自主可控、生态适配、供应链安全是硬约束，技术性能是次要考量。选型需结合信创政策、目录与自身替代需求，确保满足合规与自主可控要求。

• 数据库审计
• 等保三级
• 合规能力

等保三级（国家信息安全等级保护 3 级）对数据库有明确要求，国产库需提供相应能力：1) 审计：数据库审计功能（记录谁在何时对哪些对象做了什么操作——登录、DDL、DML、权限变化——保留审计日志，支持审计策略、查询、导出），满足"安全审计"要求；2) 访问控制与控制策略：身份鉴别、权限最小化、访问控制、三权分立（超级管理员/安全员/审计员分离）；3) 数据安全：加密存储、传输加密、数据完整性、备份恢复；4) 日志与监控：运行日志、告警、安全事件记录；5) 合规证明：通过等保测评，提供合规能力文档。国产库（openGauss、达梦、GaussDB 等）普遍提供审计日志、权限管理、加密、等保适配等能力，满足金融/政务等关键系统的等保三级要求。

等保三级是安全合规的硬指标。国产库需提供审计、访问控制、加密、日志等能力支撑，配合等保测评。审计尤其关键——记录安全事件、可追溯，是满足"安全审计"要求的核心。

• 金融核心落地案例
• 可用性指标
• 实践成效

国产库（OceanBase、GaussDB、达梦、TiDB 等）在金融核心系统已有大量落地案例：OceanBase 支撑多家银行核心账务系统（如网商银行、若干城市商业银行核心系统），GaussDB 支撑银行/证券核心，达梦、KingbaseES 用于政务/金融内部系统，TiDB 用于金融互联网/核心周边。落地成效体现可用性：核心系统要求高可用（99.99%+）、RPO=0、RTO 秒级、多地多中心容灾、大并发事务吞吐、强一致性，国产库通过"多副本强一致（Paxos/Raft）+ 分布式事务 + 高可用演练 + 性能调优"实现。典型实践：核心库 + 分布式架构（OB 三地五中心）、金融级安全与合规、迁移与双跑验证。这些案例证明国产库在金融核心的可用性已达到生产级，但需严格压测、灰度与运维保障。

"金融核心落地"是国产库可用性的最高验证。案例表明国产库能达到高可用（99.99%+、RPO=0、秒级 RTO）、强一致与高并发，但成功依赖"架构设计 + 严格压测 + 运维保障"。可用性不仅是产品能力，更是工程与运维能力。