编者按
随着国产化战略持续推进，核心系统“去 O”成为金融行业国产化升级的关键任务。本文将深入介绍平安科技如何完成从 Oracle 向 TiDB 的大规模迁移实践，涵盖选型背景、架构设计、迁移流程、性能优化与业务切换等关键环节，分享一线实践经验与教训，助力行业国产数据库替代进程提速增效。以下内容来自平安科技云数据库技术专家冼业钊在 TiDB 社区活动（深圳站）的现场分享。
作者： 冼业钊｜平安科技云数据库技术专家
一、为什么要去 O ？
Oracle 多年来支撑着平 安保 险的核心系统，但随着业务高速发展，Oracle 的劣势日益明显。以平安保险某 BU 的核心业务系统为例，该系统承载所有相关业务， 日调用量超 1.4 亿，日业务吞吐量超 3000 万 ，具有明显的高并发、大数据量的互联网特性，随着业务快速增长，Oracle 逐渐难以支撑如此高并发与大数量的场景。具体表现为：
1. 数据库容量大、单表体量大，异常隐患多。全库容量接近 100T，单表数据量已超 260 亿行，多次因硬解析堵塞、执行计划突变、时间索引分裂等数据库原因引发生产异常；单台主机异常引发业务异常，影响大。
2. 无法支持业务大促活动：业务需要支持大促活动，在双 11 大促活动前在线扩容，活动支持在线缩容，不影响业务。现有 Oracle 架构无法满足。
3. 成本问题：Oracle 本身缺乏数据压缩机制，叠加数据增长速度快，导致存储成本持续上升。同时，Oracle 的版权费用较高，高端存储使用 EMC 等产品，进一步加重了企业负担。
4. 国产化安全合规要求替代日益增加：作为金融行业关键基础设施单位，系统“去 O”已成为政策和业务双重驱动下的必然选择。
二、脱 O 数据库选型
在平安科技的“去 O”实践中，数据库选型是首要的关键环节。针对不同业务系统的架构特点与兼容性需求，平安科技制定了一套相对明确的选型规则：
- 如果原系统使用的是 Oracle RAC，且对高可用性有较高要求，则通常优先选择 TiDB，作为具备分布式、高可用特性的数据库替代方案 。
- 当业务对 Oracle 兼容性依赖较强、且短期内又无法进行系统重构时，也会评估使用 PostgreSQL 的可行性。需要注意的是，PostgreSQL 更适用于单库容量小于 10 TB 的场景，如超出数据容量需要先行拆库。
- 对于计划进行系统重构的项目，先根据业务模型重新评估数据库选型，采用新建的关系型数据库架构。
- 在个别监管强度高、去 O 时间紧迫、业务系统无法改造或重构的场景下，才会考虑兼容性较高的分布式数据库作为补充选项。
三、新建数据库选型
在新建数据库的选型上，平安科技主要围绕 TiDB、PostgreSQL（PG）和 MySQL 三款数据库进行评估与落地。选型时，重点参考了系统的恢复能力、扩展性以及业务兼容性等关键指标。
- 在灾备能力方面， TiDB 的 RPO（恢复点目标）可以做到 0 分钟，RTO（恢复时间目标）控制在 1 分钟以内，具备更强的业务连续性保障 。PG 和 MySQL 的 RTO 预设为 15 分钟，但在实际双模切换中，通常也能控制在 1 分钟以内，15 分钟是面向业务方的兜底承诺。MySQL 的 RPO 目标为 1 分钟，主要考虑典型部署架构模式为异步复制场景。
- 从扩展性角度看，TiDB 是三者中唯一原生支持分布式和横向扩展的数据库，在应对大规模数据、高并发访问时更具优势。基于存储容量的实际考量，平安科技内部推荐： 数据量小于 1TB 可选 MySQL，10TB 以下适用 PG，若超出或有 OLTP/OLAP 混合需求，优先考虑 TiDB 。
- 在兼容性方面，PG 在支持存储过程和 Oracle 部分语法方面表现更好，适用于 Oracle 兼容性要求较高但暂不重构的系统。而 TiDB 在 HTAP 场景下支持事务与分析一体，适用于对实时数据处理有一定要求的业务系统。
四、TiDB 在平安科技的部署架构
在业务系统从 Oracle 向 TiDB 迁移的过程中，系统性能和可用性是平安科技优先考虑的关键指标。为了满足高并发、高可用和强一致性的要求，平安科技在架构设计上采用了以下两种部署方式：
同城三机房单集群+远程容灾集群部署
这一架构下，TiDB 在平安科技内部被封装为名为 UbiSQL 的服务形态，对外提供统一的访问入口。应用系统通过负载均衡和 F5 接入 UbiSQL 后，底层数据被同步部署在三个数据中心，每个中心均配备相同的计算与存储资源。通过 Raft 协议实现三副本强一致性复制，确保数据在同城多个机房间同步一致。
此外，平安科技在重庆部署了一个远程单副本节点，用于提供容灾能力。该远程节点通过 TiCDC 与主集群建立同步链路，构成逻辑上的“四副本”架构，形成完整的“同城三副本 + 异地一副本”的高可用容灾体系。
目前已有 7 套平安产险核心系统采用该架构，实践证明其具备良好的稳定性与成本效益 。一方面，不同机房间数据完全一致，支持云原生多活部署；另一方面，相较于传统三活架构，该方案的整体成本控制更为合理。每台物理机在部署时，会统一配置如 ECU、RPO、Home 等标签参数，用于数据副本的调度与定位。
需要注意的是，该架构对网络稳定性有一定要求。如果同城机房之间网络质量波动较大，可能会在数据同步或事务延迟上产生一定影响。因此在部署前需充分评估网络环境，确保其满足强一致性的传输保障。
同城双机房双集群部署七副本
在该架构下，第一个机房内部集成了完整的应用体系，包括应用层、负载均衡、F5、TiDB 计算与存储节点，形成一个全功能的主集群。另一个同城机房通过 TiCDC 实现对主集群数据的逻辑复制，保持数据同步。此外，为进一步提升可用性，我们仍在重庆部署了一个单副本节点，用于远程容灾。
这种模式的主要优势在于： 业务访问与数据存储集中在同一个集群和机房中，数据访问路径短，网络延迟低，性能更为稳定 。特别是在大批量读取或本地事务密集的业务场景下，可以有效降低网络开销。不过，这一架构在处理双集群间的事务同步时存在一定局限。总的来说，该架构适用于对访问性能要求更高、对数据一致性要求稍弱的业务系统。
五、从 Oracle 到 TiDB，整体费用降低 10 %
谈及“去 O”的核心动因之一， 成本优化无疑是企业最关注的关键因素。平安科技在实际项目中也进行了详细的成本测算和对比分析（可供参考）。
以某核心系统为例，原 Oracle 数据库整体容量约为 96 TB。在迁移到 TiDB 之后，受益于其更优的数据压缩机制，实际使用容量约为 57.6 TB，远程容灾部分单副本约 20 TB， 整体存储占用减少近 40% 。这一压缩能力直接带来了存储层的成本下降。
进一步看服务端投入，Oracle 架构中高昂的授权费用和对高端存储（如 EMC）设备的依赖，是成本居高不下的重要因素。平安科技在 TiDB 的实际部署中使用了中低端存储设备（如 MMB），在满足性能需求的同时显著压缩了成本开销。虽然 TiDB 的主机成本相对略高，但综合计算，整体 TCO（总拥有成本）仍然具备明显优势。
综合评估之下，测算出系统迁移后 整体成本降低幅度在 10%–11% 左右 ，这对于金融级核心系统这样资源密集型场景而言，是一个非常可观的优化成果。
结语
从整体来看，由于涉及产险、车险业务，稳定性是至关重要的。平安的产险在国内占据了市场高地，用户数以千万计，那么多的业务数据，我们必须要保证稳定性和高效性。TiDB 带来的稳定性和高效性，以及成本优化的价值都非常明显。未来，平安科技将继续携手 TiDB，为业务的持续稳健发展保驾护航。