2025年区域性银行核心数据库转型实践白皮书-

白皮书1.1

区域性银行数据库改造趋势031.2

区域性银行业务现状调研032.1数据库技术路线选择052.2数据库部署架构路线选择082.3数据存储选型112.4容灾高可用133.1

区域性银行数据库方案部署架构153.2数据库迁移实践174.1苏州农商行存贷汇业务数据库转型实践224.2广发银行支付业务国产化数据库实践244.3江南农商行国产化数据库实践25编制委员会主

任：倪正华副主任：陈九昌

蒋

蔚

徐小峰程启旭编委会成员（排名不分先后）：孔

伟

韩春龙

沈剑宇张成诚唐

浩王美钧龚

涛陈二威

郭海龙李毕生刘

洋

穆

豪

王

佳

彭成云宋华林苏东明

方

博

王焕好

许关征徐

铭杨

勐

岳爱菊

赵经纬

王彦旌朱小涛陶友胜李建祥

苏积辉

江

帆刘

东李佳玲目录01

编制委员会目录

02在金融行业加速变革的当下，区域银行在我国金融体系中占据着重要地位。其地域性特点使得区域银行的业务模式通常相对集中，虽然随着市场需求的变化，部分区域银行已开始向外拓展业务，进入其他地域市场，业务体量也不断上升，但其整体用户量和交易频繁程度与大型全国性银行仍有差距。例如，单一小微企业贷款服务的数据量通常在10TB以内，这与大型银行在同类业务中处理的数据量相比有一定差距。此外，区域银行的客户基础主要集中在本地企业和个人客户，其业务虽然更贴近客户，但非结构化特点突出（如农产品收成、商户流水等），且数据通常分布在不同的政府部门，缺乏相对规范的财务数据。因此，尽管这些银行在服务本地客户方面具备优势，但其业务的多样性和复杂性相对较低，导致数据生成速度也相对缓慢。在可预见的未来几年中，区域银行的数据量趋向平稳，预计不会出现大幅增长，主要受限于市场需求和客户群体的规模。当前在数据库创新的时代背景下，国有大行、股份制银行核心业务已陆续完成创新改造，为匹配创新目标，区域银行正大力加速数据库创新改造。区域银行积极进行数据库转型创新，一方面是出于自身安全可控的考量，降低对单一技术的依赖；另一方面，也是顺应金融科技发展趋势，提升自身技术实力的契机。然而，数据库创新之路困难重重。首当其冲的是技术难题。区域银行85%以上长期依赖传统IOE架构，在向创新技术栈迁移时，面临着新旧技术难以兼容的困境。例如，传统架构下的业务系统与新的国产数据库、服务器等可能存在适配问题，导致系统运行不稳定，影响日常业务开展。并且，新技术整体成熟度仍有待考证，在性能、稳定性等关键指标上可能难以完全满足银行复杂业务的高要求，因此选择合适的厂家非常关键。同时，在转型过程中，技术债务是关键挑战。多数区域银行核心系统平均使用年限超10年，78%未完成分布式改造（据IDC2024年金融行业IT架构调研），难以快速响应市场变化，对接新兴业务场景。而且历史遗留的“系统烟囱”问题严重，平均每家区域银行存在15-20个独立业务系统，数据打通和整合成本平均高达数千万，数据价值难以充分发挥，制约了基于数据的创新应用，如通过精准营销、智能风控等数字化的手段来提升其竞争力、拓展业务边界。总体而言，区域性银行交易型数据库正处于快速发展与变革时期。在政策护航、行业趋势推动与技术创新引领下，银行需正视挑战，通过加强技术研发、优化人才培养体系、深化产学研合作等方式，稳步推进交易型数据库的升级与转型，为金融业务的高质量发展提供坚实的数据支撑。区域性银行作为金融体系的重要组成部分，在支持地方经济发展与产业升级、服务中小微经济、普惠金融与乡村振兴、促进金融生态稳定方面发挥着不可替代的作用。从2019年开始，国有大型银行和股份制银行率先启动包括数据库在内的信息技术应用创新工作，部分区域性银行也逐步开展了数据库改造探索与实践，国内银行数据库改造已从“试点”进入“全面攻坚”阶段，预计未来两三年将全面完成数据库改造工作。区域性银行因为业务规模、成本效益、运维复杂度或技术熟悉度等因素，传统商业集中式数据库以其优秀的系统稳定性、良好的软硬适配能力受到青睐，集中式数据库在中小金融机构仍占据主导地位，其实例数占比仍有80%（数据来源于《金融业数据库创新发展报告（2024）》）

，展现出不可替代的优势。03

区域性银行数据库改造需求现状区域性银行数据库改造需求现状

041.1

区域性银行数据库改造趋势1.2

区域性银行业务现状调研·

上限容量有限，一般来说集中式数据库单库的数据量在40TB-100TB。该能力满足大多数核心交易业务的诉求，但较难应对更高容量的敏态应用或者历史数据量很大的交易库场景。·

上限性能有限：高并发读写集中在一台机器上，可能成为系统的瓶颈，性能规格在100万tpmC。集中式数据库的典型代表有：MySQL,

PostgreSQL,

Oracle,

SQL

Server，

openGauss，GaussDB集中式。分布式数据库将数据拆分多分片分散存储在多个服务器（节点）上，这些节点通过网络连接协同工作，通过增加机器数量来扩展。其特点为在架构上采用多节点集群方式，数据被分片（Sharding）存储在不同的节点上，通过扩展分片和服务器节点来提升整体性能和容量。分布式数据库的优势主要为以下几个方面：·扩展能力，分布式数据库理论上可以通过不断增加分片和节点来线性提升系统的存储容量和处理能力。·高可用性与容错性：数据通常有多个副本存放在不同节点上，单个或多个节点故障不会导致整个服务宕机，自动故障恢复能力强。·高并发性能：将负载分散到多个节点上，可应对极高的并发读写请求。分布式数据库的缺点主要为以下几个方面：·复杂性高，引入了协调节点、数据节点、事务节点、管理节点等各类节点。部署、运维、监控和故障诊断的难度增加。·

一致性挑战大，在分布式环境下，强一致性会严重影响性能。因此很多分布式数据库采用最终一致性（BASE理论），可能读到旧数据，需要应用层处理一致性问题。·跨节点的分布式事务访问时延开销大，甚至有些数据库直接不支持或支持得很差。·

单笔交易来看，时延较大，分布式数据库节点间需要频繁跨节点转发，增加了协调/代理节点-数据节点的转发，网络延迟和稳定性对数据库性能影响较大。分布式数据库的典型代表为：TiDB、OceanBase、TDSQL、GoldenDB、GaussDB分布式。基于集中式数据库和分布式数据库在架构上的差异，区域性银行需结合业务特点来进行数据库的技术路线选型。主要考察的业务指标如下：1）数据一致性。应用要求强一致性的（如：核心交易系统、银行账户系统）建议选择集中式数据库。应用可以接受最终一致性的（如：社交网络点赞、评论、用户画像）可选择分布式数据库。2）基于数据容量和性能评估，数据容量<40TB，评估性能大小，普遍没触及集中部署的性能瓶颈，建议选择集中式数据库，数据量>40TB可考虑选用数据库分布式部署，或者通过对应用进行单元化拆分，对应的数据库子库采用集中式部署。区域性银行对数据库技术路线的选择，需要对两种架构进行理性分析。集中式数据库是将所有数据存储在一套集群上，通过提升单机性能（更强的CPU、更大的内存、更快的磁盘）来扩展。其特点为：单机或主从架构，为防止单点故障，生产系统一般按一主多从架构建设。集中式数据库所采用的数据存储，所有数据在一套存储系统上（一套存储可能采用双活方式保障系统可用性）其扩展方式为通过升级硬件（CPU、内存、扩展存储系统等）来提升性能和容量。集中式数据库的优点主要有以下几点：·

单库解决问题，不需要拆分成多个子库或者多分片，避免了分布式事务跨分片访问的问题，适合银行交易核心应用等稳态场景。·单笔交易时延低，避免了频繁跨节点转发。·

简单易用，技术成熟，生态完善，开发、运维、管理的工具链和人才都非常丰富。·事务支持，对复杂事务（如跨表事务）的支持完善。集中式数据库的潜在不足如下：数据库是信息系统的核心，从技术路线上可分为集中式数据库和分布式数据库。集中式数据库在过去几十年中一直是企业数据存储的主流解决方案。其经典的客户端-数据库-计算-交换机-存储模型简单、成熟且稳定。分布式数据库通过将数据拆成多分片分散存储到多个物理节点，并通过网络同步协同工作，旨在满足敏态应用对数据库容量和性能有高弹性扩展的诉求。05

区域性银行数据库改造技术路线选择

区域性银行数据库改造技术路线选择

062.1数据库技术路线选择节点1分片2副本...节点2分片n副本...节点n分片1副本

...数据分片2数据分片n主节点备节点

数据副本

中间件或协调节点APPAPP分布式数据库集中式数据库读写读读写读写全量数据数据分片1全量数据日志同步读写...数据库系统的架构选择一直是企业技术决策中的核心问题，尤其是存算一体与存算分离两种架构模式的抉择。随着数据规模的爆炸式增长和业务需求的日益复杂，这一选择变得尤为关键。从历史演进角度看，数据库架构经历了多次存算一体与存算分离的反复。早期的IT系统由于体量小，多以存算一体为主，1961年通用电气公司开发的第一款数据库管理系统IDS（Integrated

DataStore，集成数据存储），只能运行在通用电气的主机上，且只有一个文件存储在本地盘上，由本机的CPU、内存依据手工编码的指令来读写。当时的数据库属于高端应用，和各种大型机、中型机紧密绑定在一起，数据量也相对较小（如当时银行信贷管理系统的数据量只有10GB左右），使用大型机的本地存储空间绰绰有余。随着互联网技术的兴起，数据库系统的数据量开始激增，传统的单机数据库服务器无法满足不断增长的大量数据的存储和访问，

UNIX系统也开始大行其道，而几乎所有的UNIX主机都具备了连接外置存储的能力。在这一时期，存储区域网络（SAN）和网络附加存储（NAS）方案开始占据主导，数据库架构由存算一体转向了存算分离架构，数据库+计算+外置企业存储存算分离架构开始流行，至今已经3

0年+。商业数据库巨头Oracle从9i版本开始，推出了基于共享存储的RAC（RealApplication

Clusters），各计算节点与共享存储分离，计算节点支持横向扩展2,4,8节点等提升并发处理能力，存储也支持横向扩展2节点，4节点，8节点，甚至更多，提升并发性能和容量，整体架构解决了数据库算力横向扩展和容量扩展。外置存储除了解决容量横向扩展，更重要的是通过企业存储软件操作系统和硬件的协同实现了数据存储空间的极致高可靠、高可用，对众多的硬盘进行统一池化管理，

RAID冗余管理，部件故障快速隔离，品控质量管理等，大幅减少故障概率，达成99.9999%可靠性要求。同时集群内数据库节点实现单副本数据的共享访问，避免的频繁跨节点同步数据带来的性能和时延损耗。进入21世纪10、20年代，伴随着web2.0、3.0的飞速发展，越来越多的业务成为互联网业务，业务访问并发量的升级带来了数据量指数级激增。这使得存算一体架构再次受到关注，尤其是在大数据和实时分析场景中。然而，随着云计算技术的成熟和金融行业数字化转型的深入，存算分离架构因其独特的优势又重新成为许多企业的选择。3）考虑业务的增长情况，比如某个系统预期年业务未来增长很快，未来5年，数据量会超过40T，优先考虑选用分布式。4）考虑业务复杂度，业务系统有大量的多表关联的复杂SQL、或者存储过程、package、函数等对象，这类系统分布式改造难度大，优先选用集中式，可帮助应用平滑迁移，改造工作量小。5）读写并发，

TPS一般在20000左右，超过该业务负载，考虑选用数据库分布式部署或者通过应用单元化拆分。6）IT团队技能，如果IT团队熟悉传统SQL，缺乏分布式系统运维经验，建议从集中式数据库开始。团队拥有深厚的分布式系统开发和运维能力，可以考虑使用分布式数据库。总之，要加强分布式架构转型的统筹管理，明确分布式架构的适用范围，基于业务规模、应用场景、数据容量等维度，合理选择系统架构，要统筹规划重要系统和一般系统的转型方向和推进节奏。对于性能、容量要求较小的系统，要加强集中式和分布式技术路线选择评估，控制好系统复杂度，实事求是，技术架构精简为美。下面以某行的营销管理系统为例，提供用户方案设计建议：系统特点：·

数据量大（平均每个省大约5TB），系统总数据量超过100TB。·

高负载高吞吐（平均每个省大约2W），系统总TPS超过50W。·

业务逻辑比较复杂，即有TP类的实时交易业务，对交易响应时延要求较高，又有复杂的分析类查询的业务，还有批处理业务，包含大量的存储过程。方案设计建议：·

大数据量，大并发高吞吐的系统从特点上看更适合选用分布式，用户也有意向做这方面探索和尝试。但是该业务系统存在较多的复杂查询的AP类SQL，以及大量的存储过程，选用分布式不仅应用改造难度很大，而且可能很难充分发挥分布式本身的能力，反而会限制系统的性能和吞吐量。综业务特征集中式支撑能力选型建议存储过程或复杂SQL使用量基本未用影响较大不影响有需求对稳定性、备份等运维高要求无需求是并发性能/单库容量指标满足否是可拆库/瘦身否评估分布式改进难度集中式部署（优先）分布式部署合考虑，建议用户采用集中式。·无论从数据量还是吞吐量来说，单个集中式实例很难承载整个业务的业务量，建议应用系统采用微服务进行单元化改造，按省的粒度进行分库，把业务进行拆分。·应用考虑采用读写分离架构，把包含复杂查询在内的只读业务放到备库，降低主库的压力。·跑批类业务建议放到晚上进行，避开白天的业务高峰期，避免对关键的交易类业务产生影响。07

区域性银行数据库改造技术路线选择

区域性银行数据库改造技术路线选择

082.2数据库部署架构路线选择存量较大分片、分布式事务影响性能指标当今企业面临的技术环境更加复杂，数据规模、业务需求和技术生态都在快速变化。存算一体架构在自主创新方案不足的情况下，已逐渐暴露弹性与可靠性短板。而存算分离架构则通过共享企业存储隔离硬件故障，结合虚拟化技术，将物理服务器切换时间从分钟缩短至秒级，显著提升了业务连续性。这种演进使得架构选择不再是简单的技术决策，而是关系到企业长期发展的战略决策。一、技术深度分析：存算一体vs存算分离1、存算一体架构的技术特点存算一体架构是一种传统但成熟的数据库设计模式，其核心特点是数据存储与计算处理紧密耦合在相同的物理节点上。在这种架构中，每个数据库节点都配备了自己的计算资源和存储资源，数据分布式存储在各个节点的本地磁盘上，计算任务也尽可能在数据所在的节点上执行。存算一体架构的主要优势体现在以下几个方面：1)部署简易，不需要依赖类似外部共享存储，仅依赖物理服务器部署前端和后端进程即可完成集群的搭建。2)

执行计算时，计算节点可直接访问本地存储数据，充分利用机器的IO、减少不必要的网络开销、获得更极致的查询性能。然而，存算一体架构也存在明显的局限性。首先计算服务器部件随着年限增加，故障率上升，任何部件带来的节点故障都会殃及本地盘存储的数据，新换节点带来数据重构时间长。本地盘的故障、慢盘、超时等会导致节点频繁切换，业务hang住几十秒甚至数分钟后，带来交易失败，切换后恢复重建节点数据带来复杂的运维操作。其次，存储与计算绑定，容量不够，扩容需扩计算节点和存储资源，操作不灵活，成本反而高。最后，温冷数据成本偏高，历史数据仍需占用CPU和内存要求高的计算节点，成本高，但是业务量其实很小，CPU利用率低。此外，存算一体架构在故障恢复和搬迁时都要全量恢复数据，不仅降低了可靠性，也增加了运维工作量和成本，同时迁移扩容时间不可控，需要更多资源冗余来弥补。2、存算分离架构的技术特点3)

降低成本，存储介质分层分级，冷数据存储在低廉的介质上，成本下降70%。4)

快速故障恢复，节点宕机后，新节点直接挂载共享存储，无需全量数据重构。3、性能表现对比分析在实际性能表现上，两种架构各有特点。存算一体架构由于数据本地化存储，尤其NVMeSSD通常具有几十us级的超低延时优势。而存算分离架构通过FC/ROCE高速时延网络，

IO读写到存储缓存，实现极低的IO时延，接近存算一体。但是数据库主备是要写本地节点，同时同步要跨网络写备节点，甚至同城网络同步写备节点，而这个时延占比很大，大量的时延消耗在网络传输上。如下图，数据库事务的时延是CN计算节点到数据库节点1+同步写数据库从节点2或者3的时延累加，都是Xms级，而盘时延4的0.1ms的时延占比就很小了，主备同步写网络消耗时延更大。存算分离架构是一种现代且灵活的数据库设计模式，其核心思想是将计算处理与数据存储解耦，使它们能够独立扩展和管理。在这种架构中，数据持久化到共享存储，计算节点无状态化，实现存储与计算独立伸缩。存算分离架构的主要优势包括：1)

企业存储的可靠性高于服务器本地盘，盘的故障不会导致节点切换，减少数据库节点切换概率。存储统一管理硬盘的可靠性、RAID管理、冗余管理，慢盘、超时盘、故障盘等快速隔离，硬盘的品控质量管理，盘的FW质量和升级管理。2)

独立弹性伸缩，计算扩容可以快速增加节点应对流量高峰，存储扩容可以使存储容量按需扩展，无需数据迁移。时期主导架构推动因素典型技术1960s-1980s存算一体硬件限制、数据量小IDS、IBM大型机1990s-2010s存算分离数据量增长、网络技术Oracle

RAC、SAN/NAS2010s-2020s存算一体再现互联网爆发、大数据技术Hadoop、NoSQL2020s存算分离复兴云计算、金融数字化云原生数据库、共享存储4

,

SSD

…SSD…数据库Node2SSD…数据库Node1数据库Node314

SSD

…Data

Node12

同步从节点4

,

SSD

…SSD…Data

Node2Data

Node3从某用户数据库性能测试数据看，数据库低并发压力下，存算一体有优势，但是随着并发压力增大，存算分离性能更好，时延也更稳定，因为外置存储是几十甚至上百块SSD盘池化，多盘提供性能上限更高，再加上存储缓存技术，时延更稳定。09

区域性银行数据库改造技术路线选择

区域性银行数据库改造技术路线选择

103表：存算一体与存算分离架构的历史演进同步同城从节点CN计算节点CN计算节点内存内存内存内存内存内存由上述交易业务量，测算所需存储系统性能如下。1)存储响应时间：存储设备对请求的响应时间，包括读取数据、写入数据等操作的响应时间。存储可支撑部署多套数据库实例，提供稳定时延小于0.1ms的存储性能。2)

存储吞吐量：存储设备在一定时间内处理的数据量，包括读取数据、写入数据等操作的吞吐量。全读场景，提供不低于20GB/s的存储性能。3)

存储并发数：同时访问存储设备的用户数量。2.3.2可靠性指标银行重要系统对系统可用性提出了高要求，区域银行要求业务可用性99.999%，因此数据中心基础架构中的存储可靠性需提升至99.9999%以上。1.数据可靠性1)数据正确性：数据库记录的信息始终保持与描述对象一致，在多个实例间不会出现数据冲突或矛盾。2)

数据一致性：在多个副本和不同节点之间，数据保持一致的程度。3)

数据完整性：数据在存储、处理和传输过程中保持其正确性和一致性。4)

数据持久性：存储设备故障或其他异常情况下，避免出现数据丢失，数据保持不变且可恢复。2.系统可靠性1)冗余设计：存储节点故障不会影响整系统运行。2)

自动故障切换：在存储节点发生故障时，系统自动切换到备用节点，以保障数据库服务的连续性。3)

网络链路冗余：链路端到端故障秒级切换，存储IO不归零，数据库业务不中断。综合读写测试结果(本地盘NVMe,Do-rado存储)类型并发TPSQPS平均时延(ms)95%时延(ms)本地盘484165.2366643.7411.5231.94965247.2183955.3318.2939.651929465.85151453.5720.2841.1038411915.89190654.3232.2253.8576813889.05222224.7555.2889.16存储盘483048.4548775.2615.7422.69965180.5382888.4718.5326.681928382.18134114.9322.9032.5338413415.28214644.4928.6240.3776818056.45288903.1542.5261.08二、适用场景分析基于技术特点和性能表现，两种架构各有其适用场景。存算一体架构适合以下场景：.简单使用/快速使用数据库。.业务场景无需弹性扩缩容。存算分离架构则适合以下场景：.高可靠、高可用、高性能要求的重要生产系统。·是多个业务使用共享同一份数据，并且有隔离计算的需求。·需要极致的弹性扩缩容，随着业务规模的增长，算力、存力可分别灵活扩容，提升资源利用率。区域性银行交易性数据库场景下对存储的要求，具体如下。2.3.1吞吐性能区域性银行生产业务峰值交易量约几百~5000TPS，单次交易平均SQL请求数约为30-50次，每次SQL请求涉及约10次以上的存储IO读写，时延0.5ms，峰值业务处理所需的存储IO请求能力约为每秒1.5-2.5百万次读写，时延1ms。11

区域性银行数据库改造技术路线选择

区域性银行数据库改造技术路线选择

122.3数据存储选型中国标准准《信息系统灾难恢复规范》国际标准英国Share78RPORTO等保2.0技术要求Tier6-0数据丢失，自动拉起业务Tier7-0数据丢失，自动拉起业务0<15

min四级本地备份+异地备份+本地高可用+异地业务高可用Tier5-0数据丢失Tier6-0数据丢失0~30min<

2

HrTier4-电子传输和完整设备支持Tier5-灾备中心有实时的状态更新2~12Hr<

24

Hr三级本地备份+异地实时备份+本地业务高可用Tier4-活动状态的灾备中心2~24Hr<

24

HrTier3-电子传输和部分设备支持Tier3-电子链接12Hr~24Hr24Hr二级本地备份+异地定时备份Tier2-备用场地支持Tier2-PTAM卡车运送+热备份中心24

Hr~数天24

Hr~数天Tier

1-基本支持Tier

1-PTAM卡车

运送数天数天一级本地备份Tier0-No

off-siteData数天~?数天~?同城双集群数据库强同步，实现

RPO=0，RTO＜120S。（2）两地三中心：支持同城双数据中心，多地容灾，实例可以在多个地域间进行迁移。实例跨地域故障切换指标，两地三中心异地高可用方案实现RPO＜1分钟，RTO＜10分钟。备份与恢复（1）备份效率：支持

LanFree

级备份，数据备份流量走存储网络，降低对主机的影响，备份速率可达2GB/s。（2）恢复时间：数据恢复所需的时间。支持任意时间点恢复，百TB级数据库分钟级恢复。（3）数据丢失点：数据恢复时允许的数据丢失量。支持分钟级最小保护周期，通过备份数据恢复数据库实例允许丢失的数据量最小可达到5分钟。3.硬盘可靠性1)SSD盘寿命提升：具备SSD盘磨损均衡和全局反磨损均衡能力。2)

最大可容忍3盘同时故障，3盘故障业务不归零，性能无明显影响。避免一个RAID组内3块SSD同时失效导致的数据丢失，提高系统整体硬盘的可靠性。3)

故障预防：硬盘故障提前识别，提前告警，提醒用户进行更换。4)

故障检测&容错：提供硬盘在线诊断能力，检测硬盘潜在故障，识别盘故障，主动启动数据拷贝。避免慢盘进行写操作，尽量不读慢盘。出现慢盘后，业务不归零，性能无明显影响。5)

盘故障修复：单盘故障数据重构速度高于5TB/h。图2-4：中国和国际的信息系统灾备恢复标准区域性银行核心业务对应5-6级核心类业务，除了要求数据本身的高可用外，对业务连续性也有极高要求，具体要求如下：容灾能力要求：（1）同城双集群：基于共享存储的高可用方案，提供性能

更高，可靠性更强的高可用方案。支持金融业对系统业务连续性有着严格要求，其中数据库集群尤为重要，用户通常按照灾备建设的两大标准和两大衡量指标来规划总体容灾架构，具体参考如下标准：13

区域性银行数据库改造技术路线选择

区域性银行数据库改造技术路线选择

142.4容灾高可用类别型号具体描述数量计算服务器64Core@2.6HZ，内存512GB，系统盘

2*960SATA（raid10）6网格业务&管理交换机48*10Gb/25Gb以太网络8存储交换机48*25Gb以太网络448*25Gb，36*100Gb以太网络4存储全闪存存储四控（总计1TB缓存），21*7.68TBNVMe

SSD，（支持双活/复制）2备份备份服务器（含备份软件）裸容量400TB或者按需配置1区域性银行数据库存算分离解决方案是指基于数据库+计算+网络+存储+备份为基础构建RPO=0的高可靠解决方案，该方案采用数据库存算分离及双数据中心架构部署，双数据中心之间采用存储双活/同步复制保证RPO=0，主数据库中心提供读写业务，灾备数据中心提供查询业务，提高数据中心的整体服务能力和系统资源利用率，同时采用存储本地快照+备份软件（Lan-free方式）双重备份，保证数据完整性。区域银行数据库存算分离解决方案部署架构该方案采用数据库存算分离双数据中心部署，数据中心之间首次部署初始化通过数据库跨集群全量building，后续业务主集群节点写xlog共享日志，通过存储同步复制将xlog日志数据同步到备集群xlog共享卷，备集群各节点将日志回放实现跨集群容灾两个数据中心均处于运行状态，逻辑架构图如图3-1所示。图3-1：区域银行数据库存算分离解决方案逻辑架构图快照备份生产集群快照T0快照T1…快照激活快照Tn

该方案备份采用了存储无损快照+备份软件进行备份，本地备份采用全存储无损快照进行备份，在误操作情况下，可以通过存储快照快速进行恢复，百TB数据分钟级恢复；备份软件采用LAN-FREE方式进行备份，通过访问存储及数据卷快照间的差异数据，从存储读取备份数据，生成数据副本性能可达2GB/s。如图3-2所示。图3-2

区域银行数据库存算分离解决方案备份逻辑架构图生产/灾备/测试集群主生产中心

Region

同城生产中心

Region主集群

备集群13.1

区域性银行数据库方案部署架构鲲鹏服务器

鲲鹏服务器鲲鹏服务器5读GaussDB备节点鲲鹏服务器4GaussDB

备节点GaussDB

备节点GaussDB

主节点GaussDB

主节点GaussDB

备节点GaussDB

备节点日志备份备份

代理TPOPSTPOPSNoF+交换机NoF+交换机Region

1Region2读写GaussDB主节点鲲鹏服务器读GaussDB备节点鲲鹏服务器数据卷RedoLogDataFile

Share

Redo

Log日志卷区域性银行数据库改造实践

1615

区域性银行数据库改造实践副本复制3增量日志存储同步复制数据库系统硬件推荐配置：读

读

读OceanStor

Dorado存储池OceanStor

Dorado存储池GaussDB备节点GaussDB备节点GaussDB备节点NoF+存储交换机*NoF+存储交换机*NoF+存储交换机*NoF+存储交换机*副本T0首次全量buildingRedoLog

DataFileOceanProtectShareRedo

Log副本恢复副本归档2图3-3：数据库迁移最佳实践一个应用系统发展到一定程度后，可能应用开发人员或DBA无法完全了解数据库中包含哪些对象，以及应用代码中有多少SQL。迁移前进行迁移评估可以帮助用户梳理数据库对象和应用代码SQL，并识别其中需要进行改造的对象，给出改造建议，让业务做到心中有数，降低应用改造成本。迁移过程中配合迁移工具将数据库对象、数据进行完整迁移，并进行数据校验、仿真验证、业务验证，保证迁移前后的一致性。迁移完成后将应用流量切换到新的数据库中。提供的数据库迁移工具集，主要包含两个工具，分为别UGO和DRS。其中UGO是专注于异构数据库对象和应用迁移的专业化工具，包含四大核心功能：预迁移评估、结构迁移、应用迁移和SQL审核。

DRS用于数据库实时迁移和实时同步，支持在线迁移、离线迁移、数据校验、录制回放等功能。结合UGO和DRS迁移工具，实现主流数据库到某厂商数据库的自动化搬迁。图3-4：数据库迁移整体解决方案及工具集数据库迁移是一项复杂的系统工程，不仅需要高效和成熟的专业迁移工具和迁移方法论，面对迁移场景复杂、缺乏专业人员等问题，还需要专业服务保障用户完成数据库迁移。3.2.1数据库对象迁移从业务视角看数据库迁移，考虑的是整个业务系统的搬迁过程中有哪些环节需要迁移和改造。展现层不包含数据库对象，因此不需要考虑改造和迁移。业务逻辑层作为业务逻辑和数据库交互的模块，最常见的使用持久层框架如MyBatis等，或者直接使用SQL语句，其中包含了大量的SQL语句，因此需要进行改造。存储层包含了数据库对象和数据，需要进行完整迁移。3

正式迁移2

迁移演练迁移实施时间轴业务验证普通索引/视图/函数/存储过程全量开始前，就启动增量数据抽取，保证数据绝对完整用户点击任务完

成，进行触发器

和事件的迁移任务结束随着国内金融业数据库升级改造进程的不断加速，越来越多金融机构的存量业务系统亟需迁移到国产数据库平台上。对已经稳定运行的业务系统进行跨数据库迁移，是一项工作量巨大的工程，具有较高的复杂度和风险，这不仅要求数据库厂商不断完善其数据库产品与存量数据库之间的兼容性，也要求数据库升级改造责任主体仔细评估存量业务所采用的SQL语句和数据库相关配置，确保应用成功上线。提供一站式迁移解决方案、一系列完整的迁移改造工具和迁移专业服务，从调研评估、方案制定、应用改造、迁移演练和实施等方面帮助用户完成应用适配和数据库迁移。迁移实施时间轴普通索引/视图/函数/存储过程用户点击任务完

任务结束成，进行触发器和事件的迁移√

无需修改√√√

数据迁移√

集成验证

数据

对象采集对象转换兼容性评估

对象迁移JDBC协议C++PythongoCshellJava…JDBC17

区域性银行数据库改造实践

区域性银行数据库改造实践18对象评估/迁移(UGO)评估+转换+迁

移数据库对象应用迁移评估(UGO)扫描+评估+

转换应用sql数据迁移(DRS)基于日志的实时

变化数据捕捉数据校验(DRS)基于日志的增量数据实时校验1

实施前准备信息调研迁移评估工具部署3.2数据库迁移实践4

应用上线商业数据库华为云数据库业务验证SQL审核(UGO)录制回放(DRS)业务仿真验证，保证迁移后业务稳定高效运行对象迁移转换后对象对象对比源代码中的sql脚本中的sql…Mybatis配置文件…程序运行时，实际存在的sql对象迁移1

全量迁移

对象迁移2增量迁移对象迁移3增量数据抽取增量数据抽取HTMLCSSJavascript代码中SQL配置文件SQL动态JDBCSQL全量开始前，就启动增量数据抽取，保证数据绝对完整MybatisPlusHibernateSpringDataMybatisTopLinkopenJPA一致性校验

(行数/内容)业务验证一致性校验

(行数/内容)业务验证应用SQL转化对象迁移1

全量迁移对象迁移2图3-5：数据库迁移业务视角迁移规划灰度并线割接上线持久化业务逻辑对象数据主流商用数据库开源数据库展现层存储业务逻辑持久化协议提前识别SQL规范、设计、性能问题触发器/事件/作业触发器/事件/作业表结构/主键/唯一键表结构/主键/唯一键持续运行，实时同步数据

改造点分析

云上RDS3RD自研内核增量迁移（短期）门禁集成兼容评估PLSQL迁移改造建议DDL迁移应用改写流量捕获数据同步应用扫描列级比对行级比对SQL采集在线迁移实时转换流量仿真内容比对SQL转换组合校验DML迁移数据订阅一键审核迁移评估多活灾备性能分析

业务系统持续采集应用SQL对象初始化时执行一次初始化时执行一次比对数据准确性门禁化持续运行 OpenAPI

转换后sql对象迁移3应用迁移改造后

ODBC

展现层PostgreSQLMySQLGaussDB线下DDS云上……图3-9：应用迁移围绕业务逻辑和数据库连接开展在某大型银行的应用改造实践中，数据库工具成功支撑了对该银行上亿行SQL语句的改造，其中超过95%的SQL语句为数据库自身兼容或通过迁移工具转换而兼容，极大降低了人力投入，提升了兼容性转换效率和准确率。3.3.3数据库数据迁移对象迁移完成后进行业务数据迁移，数据迁移分为存量数据迁移和增量数据实时同步。相关工具可解决如何在业务近乎不停机的情况下快速将用户的存量数据和增量数据迁移过来，并保证数据在任何情况下不丢、不错、不乱，同时提供灵活、多样的数据比对和修复能力，降低数据库之间数据流通的复杂性，有效地帮助用户减少数据传输的成本。图3-7：对象迁移图示3.2.2应用改造迁移应用迁移可以提取并分析应用程序中的SQL语句，用户在需要改造业务应用时可以使用迁移工具的应用迁移功能。借助迁移工具，数据库升级改造责任主体可以快速评估应用改造工作量及改造难度，以工具评估结果为基础合理安排应用改造计划和资源投入，可以确保应用改造有序开展并取得最终的成功。迁移工具需采集业务代码Mybatis

XML、Java代码、SQL脚本等文件中的SQL语句，对采集到的SQL语句进行评估和转换。图3-8：应用迁移图示针对应用改造，主要围绕整个业务系统的业务逻辑层和数据库连接层来开展，重点审视三类对象中的SQL语句：·代码中内嵌的SQL语句·配置文件中的SQL语句·动态生成的SQL语句预迁移评估循环校正转换计划持续验证图3-6：数据库评估图示对象迁移可以根据评估结果用户自行迁移方案的配置，且转换前可以过滤对象，因为并非所有采集出来的对象都需要进行迁移，用户可以结合业务进行过滤，然后进行自动转换。这也是异构数据库迁移的核心诉求，用户在要进行实际的数据库对象迁移时可以使用相关工具的对象迁移功能。目标库选型GaussDB改造工作量评估测试&上线工作量(人天)

20数据库评估可以评估异构数据库语法转换率，提前识别迁移风险，可以连接源库进行数据库对象采集，性能采集等，基于采集的信息分析语法兼容性和到各个目标库之间的兼容性，用户可以结合评估出来的数据进行目标库类型和规格的选型以及迁移人力安排，能帮助用户决策与工作规划。SQL采集动态采集

静态采集…

…应用迁移源代码中的sql脚本中的sql…Mybatis配置文件…程序运行时，实际存在的sql…19

区域性银行数据库改造实践

区域性银行数据库改造实践

20SQL评估…ObjectTypeValueCountModificationSuggestionTableREVERSE100XXXXXXXFunctionxxx90xxxTableBITMAP80XXXXXXXSQL转换…源码改造…目标数据库云数据库本地数据库源数据库云数据库本地数据库JDBC数据源库画像

需要改造SQL列表

需要改造源码列表

C

C++Pythongo shell

Java…

对象兼容性

HTMLCSSJavascriptMybatisPlusHibernateSpringDataMybatisTopLinkopenJPA动态JDBC

SQL配置文件SQL代码中SQLDBA工作量(人天)20开发工作量(人天)5评估报告不兼容语法点TomcatJBossSQL改造位置Spring-boot

C#源、目标对比SQL改造列表转换报告MybatisxmlJAVA改造提示改造确认辅助人工改造自动改造展现层业务逻辑存储持久化协议TOP不兼容特性目标库确认…MYSQLPGGAUSS验证上线对象校正源库采集语法转换语法差异分析OpenAPIODBC对象语法解析DBDBDBDBUGO◆发展现状简介：总部位于苏州市吴江区，截至2025年上半年资产总额2232亿元，拥有95家网点，是服务地方的区域性银行。战略愿景：推动规模、效益与质量均衡发展，“5年再造一个苏州农商银行”。科技投入：截至2025年6月，全行员工1953人，科技员工157人，年科技投入高于行业3%平均水平（24年，5.4%）。◆业务挑战业务挑战：面临大行/股份制

“数字化”下沉业务渠道、同区域其他城商/农信激烈竞争。科技挑战：核心系统承载在老旧的Power小机+IBM存储，性能和稳定性存在风险。存贷汇业务是银行最核心、最基础的三项业务，是银行生存和发展的根基，也被形象地称为银行业的“三大基石”，负责全行存贷款业务，对于数据库的性能、高可用性、稳定性等方面都有严格的要求。系统建设目标及挑战：1.平滑替换DB2，提升性能及安全等级，持续推动业务稳定运行。双集群强一致方案规避数据丢失风险、提升了管理效率、联机响应时间缩短至30毫秒，日终批处理时间由80分钟压缩至18分钟，关键性能指标稳居同业前列。2.

热点数据冲突，突破热点账户并发控制、历史数据迁移校验等技术难题，日均交易承载能力提升10倍。3.

极简运维，业务长稳测试TPS峰值抖动率<6%，容灾演练及高可用（RTO<90s）要求通过核心业务高峰模拟指标要求。◆转型实践早在2020年，该行便以敏捷交付模式启动分布式技术布局；2023年，在人行支付系统率先应用国产高斯数据库，并通过银联业务系统、核心历史库系统等样板工程验证国产技术可行性。这场核心系统升级并非一蹴而就，而是历经3年，在渠道服务、风险管理、基础设施等领域实现阶梯式跃迁：云原生分布式架构打破数据孤岛，

A类超网系统创新实践积累适配经验，最终形成“试点验证—流程优化—图3-10：数据迁移图示整个迁移过程需提供向导式迁移，进入数据库复制服务控制台->开始创建迁移任务->选择迁移链路和类型->配置源库、目标库和任务配置信息->预检查及任务确认->查看迁移任务状态。数据库迁移工具可提供在线迁移能力，通过全量数据迁移和增量数据迁移帮助用户实现在线迁移，减少业务停机时间。全量数据迁移通过查询源库表数据，并将查询结果写入目标库实现数据迁移，增量数据迁移通过CDC技术实时解析数据库日志，并将解析到的数据实时写入目标库。21

区域性银行数据库改造实践

区域性银行数据库改造案例

224.1苏州农商行存贷汇业务数据库转型实践日均交易量承载能力(万笔)100010倍100现网

GaussDB日终批处理时间(分钟)3倍10030现网

GaussDB◆发展现状随着科技转型的不断提速，行里重要系统数据库需进行创新改造，以应对业务发展对于数据库平台提出的更高级别的性能、可靠性要求。◆业务挑战随着国内数据库改造的持续演进，金融重要交易系统对数据库整体架构提出了明确要求。首先，数据库架构要求极致的高可靠，稳定、可靠的软硬件架构，硬件冗余，各个组件故障能够快速隔离，不能导致业务受影响，敏感数据不能丢失，数据安全得到保障。其次，算力资源和存储资源可要独立便捷扩容，提升资源利用率，节省成本。第三，交易时延低而且稳定均衡。第四，运维简单高效，硬件的故障，比如盘的故障不切数据库节点，业务无感，数据重建业务无感。◆转型实践GaussDB数据库作为数据库创新改造的主路线，采用GaussDB+OceanStor

Dorado的数据库存算分离方案进行数据库系统的创新改造。数据库架构采用生产中心和同城1主3备+1仲裁单集群拉远部署，各节点的存储资源采用OceanStor

Dorado存储池划分的LUN资源，生产到同城实现数据库集群内双活，数据库主备节点同步复制，确保RPO=0。生产中心同城中心灾备中心全量切换”的成熟升级路径，为行业创新转型提供实践指南。核心库采用集中式存算分离强一致方案部署，备节点开启只读模式，提供读写分离，下游取数库通过存储快照快速构建近实时数据（生产库）供下游数据库读取数据。·

生产库主、备集群都有完整的数据，主集群异常情况下可实现自动容灾切换，保障业务连续性。·核心库采用集中式一主两备部署方案。主集群与备集群之间采用同步复制进行数据同步，保证RPO=0。·下游取数库通过存储快照快速构建近实时数据（生产库）供下游数据库读取数据，分摊主库的负载。◆转型效果通过与华为GaussDB+企业存储存算分离整体方案的合作，苏州农商行在存贷汇核心系统上取得了显著的成果。从硬件服务器到高斯数据库，再到应用层，实现全栈创新替代，搭建起自主可控的金融科技底层架构。基于GaussDB的分布式架构，新系统性能实现跨越式提升：日均交易量承载能力从100万笔跃升至1000万笔，系统交易峰值处理能力从200笔/秒到可达6800笔/秒，联机响应时间缩短至30毫秒，日终批处理时间由80分钟压缩至18分钟，关键性能指标稳居同业前列。主集群主

备

ETCD

备

备GaussDB

GaussDBGaussDB

GaussDB

GaussDB23

区域性银行数据库改造案例

区域性银行数据库改造案例

244.2广发银行支付业务数据库创新实践OceanStor

Dorado

OceanStor

Dora