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

目 录 1.1 区域性银行数据库改造趋势1.2 区域性银行业务现状调研0303 2.1 数据库技术路线选择2.2 数据库部署架构路线选择2.3 数据存储选型2.4 容灾高可用05081113 编制委员会 主 任：倪正华 3.1 区域性银行数据库方案部署架构3.2 数据库迁移实践1517 副主任：陈九昌 蒋蔚 徐小峰 程启旭 编委会成员（排名不分先后）：孔伟 韩春龙 沈剑宇 张成诚唐浩王美钧 龚涛 陈二威 郭海龙 李毕生刘洋 穆豪 王佳 彭成云 宋华林苏东明 方博 王焕好 许关征徐铭杨勐 岳爱菊 赵经纬 王彦旌 朱小涛陶友胜 李建祥 苏积辉 江帆 刘东李佳玲 4.1 苏州农商行存贷汇业务数据库转型实践4.2 广发银行支付业务国产化数据库实践4.3 江南农商行国产化数据库实践222425 编制单位：江苏苏州农村商业银行股份有限公司华为技术有限公司 然而，数据库创新之路困难重重。首当其冲的是技术难题。区域银行85%以上长期依赖传统IOE架构，在向创新技术栈迁移时，面临着新旧技术难以兼容的困境。例如，传统架构下的业务系统与新的国产数据库、服务器等可能存在适配问题，导致系统运行不稳定，影响日常业务开展。并且，新技术整体成熟度仍有待考证，在性能、稳定性等关键指标上可能难以完全满足银行复杂业务的高要求，因此选择合适的厂家非常关键。 同时，在转型过程中，技术债务是关键挑战。多数区域银行核心系统平均使用年限超10年，78%未完成分布式改造（据IDC 2024年金融行业IT架构调研），难以快速响应市场变化，对接新兴业务场景。而且历史遗留的“系统烟囱”问题严重，平均每家区域银行存在15-20个独立业务系统，数据打通和整合成本平均高达数千万，数据价值难以充分发挥，制约了基于数据的创新应用，如通过精准营销、智能风控等数字化的手段来提升其竞争力、拓展业务边界。 1.1 区域性银行数据库改造趋势 区域性银行作为金融体系的重要组成部分，在支持地方经济发展与产业升级、服务中小微经济、普惠金融与乡村振兴、促进金融生态稳定方面发挥着不可替代的作用。 从2019年开始，国有大型银行和股份制银行率先启动包括数据库在内的信息技术应用创新工作，部分区域性银行也逐步开展了数据库改造探索与实践，国内银行数据库改造已从“试点”进入“全面攻坚”阶段，预计未来两三年将全面完成数据库改造工作。 总体而言，区域性银行交易型数据库正处于快速发展与变革时期。在政策护航、行业趋势推动与技术创新引领下，银行需正视挑战，通过加强技术研发、优化人才培养体系、深化产学研合作等方式，稳步推进交易型数据库的升级与转型，为金融业务的高质量发展提供坚实的数据支撑。 区域性银行因为业务规模、成本效益、运维复杂度或技术熟悉度等因素，传统商业集中式数据库以其优秀的系统稳定性、良好的软硬适配能力受到青睐，集中式数据库在中小金融机构仍占据主导地位，其实例数占比仍有80%（数据来源于《金融业数据库创新发展报告（2024）》），展现出不可替代的优势。 1.2 区域性银行业务现状调研 在金融行业加速变革的当下，区域银行在我国金融体系中占据着重要地位。其地域性特点使得区域银行的业务模式通常相对集中，虽然随着市场需求的变化，部分区域银行已开始向外拓展业务，进入其他地域市场，业务体量也不断上升，但其整体用户量和交易频繁程度与大型全国性银行仍有差距。例如，单一小微企业贷款服务的数据量通常在10TB以内，这与大型银行在同类业务中处理的数据量相比有一定差距。 此外，区域银行的客户基础主要集中在本地企业和个人客户，其业务虽然更贴近客户，但非结构化特点突出（如农产品收成、商户流水等），且数据通常分布在不同的政府部门，缺乏相对规范的财务数据。因此，尽管这些银行在服务本地客户方面具备优势，但其业务的多样性和复杂性相对较低，导致数据生成速度也相对缓慢。在可预见的未来几年中，区域银行的数据量趋向平稳，预计不会出现大幅增长，主要受限于市场需求和客户群体的规模。 当前在数据库创新的时代背景下，国有大行、股份制银行核心业务已陆续完成创新改造，为匹配创新目标，区域银行正大力加速数据库创新改造。区域银行积极进行数据库转型创新，一方面是出于自身安全可控的考量，降低对单一技术的依赖；另一方面，也是顺应金融科技发展趋势，提升自身技术实力的契机。 上限容量有限，一般来说集中式数据库单库的数据量在40TB-100TB。该能力满足大多数核心交易业务的诉求，但较难应对更高容量的敏态应用或者历史数据量很大的交易库场景。 上限性能有限：高并发读写集中在一台机器上，可能成为系统的瓶颈，性能规格在100万tpmC。 集中式数据库的典型代表有：MySQL, PostgreSQL, Oracle, SQL Server，openGauss，GaussDB集中式。 分布式数据库将数据拆分多分片分散存储在多个服务器（节点）上，这些节点通过网络连接协同工作，通过增加机器数量来扩展。其特点为在架构上采用多节点集群方式，数据被分片（Sharding）存储在不同的节点上，通过扩展分片和服务器节点来提升整体性能和容量。分布式数据库的优势主要为以下几个方面： 2.1 数据库技术路线选择 数据库是信息系统的核心，从技术路线上可分为集中式数据库和分布式数据库。 集中式数据库在过去几十年中一直是企业数据存储的主流解决方案。其经典的客户端-数据库-计算-交换机-存储模型简单、成熟且稳定。分布式数据库通过将数据拆成多分片分散存储到多个物理节点，并通过网络同步协同工作，旨在满足敏态应用对数据库容量和性能有高弹性扩展的诉求。 扩展能力，分布式数据库理论上可以通过不断增加分片和节点来线性提升系统的存储容量和处理能力。 高可用性与容错性：数据通常有多个副本存放在不同节点上，单个或多个节点故障不会导致整个服务宕机，自动故障恢复能力强。 高并发性能： 将负载分散到多个节点上，可应对极高的并发读写请求。 分布式数据库的缺点主要为以下几个方面： 复杂性高，引入了协调节点、数据节点、事务节点、管理节点等各类节点。部署、运维、监控和故障诊断的难度增加。 一致性挑战大，在分布式环境下，强一致性会严重影响性能。因此很多分布式数据库采用最终一致性（BASE理论），可能读到旧数据，需要应用层处理一致性问题。 跨节点的分布式事务访问时延开销大，甚至有些数据库直接不支持或支持得很差。 区域性银行对数据库技术路线的选择，需要对两种架构进行理性分析。 单笔交易来看，时延较大，分布式数据库节点间需要频繁跨节点转发，增加了协调/代理节点-数据节点的转发，网络延迟和稳定性对数据库性能影响较大。 集中式数据库是将所有数据存储在一套集群上，通过提升单机性能（更强的CPU、更大的内存、更快的磁盘）来扩展。其特点为：单机或主从架构，为防止单点故障，生产系统一般按一主多从架构建设。集中式数据库所采用的数据存储，所有数据在一套存储系统上（一套存储可能采用双活方式保障系统可用性） 其扩展方式为通过升级硬件（CPU、内存、扩展存储系统等）来提升性能和容量。 分布式数据库的典型代表为：TiDB、OceanBase、TDSQL、GoldenDB、GaussDB分布式。 集中式数据库的优点主要有以下几点： 基于集中式数据库和分布式数据库在架构上的差异，区域性银行需结合业务特点来进行数据库的技术路线选型。主要考察的业务指标如下： 单库解决问题，不需要拆分成多个子库或者多分片，避免了分布式事务跨分片访问的问题，适合银行交易核心应用等稳态场景。 1）数据一致性。应用要求强一致性的（如：核心交易系统、银行账户系统）建议选择集中式数据库。应用可以接受最终一致性的（如：社交网络点赞、评论、用户画像）可选择分布式数据库。 单笔交易时延低，避免了频繁跨节点转发。 2）基于数据容量和性能评估，数据容量<40TB，评估性能大小，普遍没触及集中部署的性能瓶颈，建议选择集中式数据库，数据量>40TB可考虑选用数据库分布式部署，或者通过对应用进行单元化拆分，对应的数据库子库采用集中式部署。 简单易用， 技术成熟，生态完善，开发、运维、管理的工具链和人才都非常丰富。 事务支持，对复杂事务（如跨表事务）的支持完善。 集中式数据库的潜在不足如下： 合考虑，建议用户采用集中式。 无论从数据量还是吞吐量来说，单个集中式实例很难承载整个业务的业务量，建议应用系统采用微服务进行单元化改造，按省的粒度进行分库，把业务进行拆分。 应用考虑采用读写分离架构，把包含复杂查询在内的只读业务放到备库，降低主库的压力。 跑批类业务建议放到晚上进行，避开白天的业务高峰期，避免对关键的交易类业务产生影响。 2.2 数据库部署架构路线选择 数据库系统的架构选择一直是企业技术决策中的核心问题，尤其是存算一体与存算分离两种架构模式的抉择。随着数据规模的爆炸式增长和业务需求的日益复杂，这一选择变得尤为关键。 3）考虑业务的增长情况，比如某个系统预期年业务未来增长很快，未来5年，数据量会超过40T，优先考虑选用分布式。 从历史演进角度看，数据库架构经历了多次存算一体与存算分离的反复。早期的IT系统由于体量小，多以存算一体为主，1961年通用电气公司开发的第一款数据库管理系统IDS（IntegratedDataStore，集成数据存储），只能运行在通用电气的主机上，且只有一个文件存储在本地盘上，由本机的CPU、内存依据手工编码的指令来读写。当时的数据库属于高端应用，和各种大型机、中型机紧密绑定在一起，数据量也相对较小（如当时银行信贷管理系统的数据量只有10GB左右），使用大型机的本地存储空间绰绰有余。 4）考虑业务复杂度，业务系统有大量的多表关联的复杂SQL、或者存储过程、package、函数等对象，这类系统分布式改造难度大，优先选用集中式，可帮助应用平滑迁移，改造工作量小。 5）读写并发，TPS一般在20000左右，超过该业务负载，考虑选用数据库分布式部署或者通过应用单元化拆分。 6）IT团队技能，如果IT团队熟悉传统SQL，缺乏分布式系统运维经验，建议从集中式数据库开始。团队拥有深厚的分布式系统开发和运维能力，可以考虑使用分布式数据库。 随着互联网技术的兴起，数据库系统的数据量开始激增，传统的单机数据库服务器无法满足不断增长的大量数据的存储和访问，UNIX系统也开始大行其道，而几乎所有的UNIX主机都具备了连接外置存储的能力。在这一时期，存储区域网络（SAN）和网络附加存储（NAS）方案开始占据主导，数据库架构由存算一体转向了存算分离架构，数据库+计算+外置企业存储存算分离架构开始流行，至今 已 经 3 0 年 + 。 商 业 数 据 库 巨 头 O r a c l e 从 9 i 版 本 开 始 ， 推 出 了 基 于 共 享 存 储 的 R A C （ R e a lApplication Clusters），各计算节点与共享存储分离，计算节点支持横向扩展2,4,8节点等提升并发处理能力，存储也支持横向扩展2节点，4节点，8节点，甚至更多，提升并发性能和容量，整体架构解决了数据库算力横向扩展和容量扩展。外置存储除了解决容量横向扩展，更重要的是通过企业存储软件操作系统和硬件的协同实现了数据存储空间的极致高可靠、高可用，对众多的硬盘进行统一池化管理，RAID冗余管理，部件故障快速隔离，品控质量管理等，大幅减少故障概率，达成99.9999%可靠性要求。同时集群内数据库节点实现单副本数据的共享访问，避免的频繁跨节点同步数据带来的性能和时延损耗。 总之，要加强分布式架构转型的统筹管理，明确分布式架构的适用范围，基于业务规模、应用场景、数据容量等维度，合理选择系统架构，要统筹规划重要系统和一般系统的转型方向和推进节奏。对于性能、容量要求较小的系统，要加强集中式和分布式技术路线选择评估，控制好系统复杂度，实事求是，技术架构精简为美。 下面以某行的营销管理系统为例，提供用户方案设计建议：系统特点： 数据量大