本白皮书版权属于北京金融信息化研究所有限责任公司,并受法律保护。转载、编摘或利用其他方式使用本白皮书文字或观点的,应注明来源。违反上述声明者,将被追究相关法律责任。 主任: 潘润红 副主任: 黄程林、庄文君 编委会成员(排名不分先后,按姓氏拼音排序): 董晓杰、何东川、何佳佳、胡盼盼、黄涛、简丽荣、王鹏冲、杨传辉、张子鉴、朱鹏 编写组成员(排名不分先后,按姓氏拼音排序): 鲍思佳、陈灿荣、陈辉、程静、从平平、崔志伟、董里、金振山、李会亮、李云龙、李中原、梁燕、廖美东、刘常、刘方彪、刘昭、罗兰瑞婧、马攀、马涛、明玉琢、邵志杰、盛玉、万里、王爱国、王成、王帅强、王耀强、徐赞、杨尚、张刚、张羿、赵蒙 主编单位: 北京金融信息化研究所 中国农业银行股份有限公司 中国邮政储蓄银行股份有限公司平安银行股份有限公司 上海银行股份有限公司 深圳前海微众银行股份有限公司中国人寿财产保险股份有限公司中国人民人寿保险股份有限公司华为技术有限公司 北京奥星贝斯科技有限公司武汉达梦数据库股份有限公司 参编单位: 北京酷克数据科技有限公司阿里云(北京)科技有限公司 平凯星辰(北京)科技有限公司 中电科金仓(北京)科技股份有限公司北京海量数据技术股份有限公司 天津南大通用数据技术股份有限公司成都虚谷伟业科技有限公司 天津神舟通用数据技术有限公司 金融业作为信息技术应用的前沿阵地,展现出对新技术的较高敏锐度和快速响应能力。中国人民银行印发的《金融科技发展规划(2022-2025年)》中,强调打造数字绿色服务体系,建设绿色高可用数据中心,架设安全泛在的金融网络,布局先进高效的算力体系,夯实数字基础底座,助力数字金融高质量发展。 在创新发展和安全可控的双重驱动下,我国数据库作为金融信息系统的重要组成部分,在金融机构中的持续创新应用有效推动数字金融安全生态的构建。随着金融业数字化转型的深入,金融数据库架构正逐步从传统封闭走向创新开放。在此过程中,数据库存算一体架构可以有效满足金融新兴业务初期对快速和敏捷交付的需求,但随着金融业务的增长和基础设施规模的扩大,存算一体架构在可靠性和扩展性方面的局限性逐渐显现。因此,开放解耦的存算分离架构,不仅能够根据业务需求实现计算和存储资源的独立扩展,提供灵活的弹性扩缩容计算能力,还能利用存储的高可靠性优势,进一步提升整个集群处理海量数据的可靠性,重新成为数据库场景的架构选择。 本报告针对金融业务场景的特点和需求,深入剖析当前主流数据库存算分离技术架构方案,总结数据库存算分离架构选型评估指标体系,构建数据库存算分离架构实施路线,并总结金融机构的探索实践经验,为推动金融业数据库架构创新发展贡献力量。 1.金融业数据库技术架构演变历程1 2.金融业应用对数据库的需求现状3 2.1金融场景业务特性3 2.2金融业数据库应用的基础架构问题和需求5 3.主流数据库存算分离架构技术分析13 3.1集中式数据库存算分离技术14 3.2分布式数据库存算分离技术16 3.3云原生数据库存算分离技术22 4.数据库存算分离架构选型评估指标与建议28 4.1性能指标28 4.2可靠性指标29 4.3可用性指标31 4.4成本效益分析34 4.5能耗指标35 4.6扩展性指标37 4.7安全性要求38 4.8运维指标39 4.9演进能力41 4.10总结41 5.数据库存算分离架构演进方案42 5.1外置存储的存算分离架构43 5.2存算协同的存算分离架构44 6.金融业数据库存算分离架构应用实践46 6.1工商银行数据库存算分离架构实践46 6.2农业银行新一代存算分离数据库实践54 6.3平安银行MySQL数据库存算分离架构探索57 6.4上海银行数据库存算分离架构的应用试点实践61 6.5微众银行TDSQL+OceanDisk存算分离架构64 6.6人保寿险数据库存算分离架构转型升级71 7.总结76 金融业的数据库技术架构演变紧跟金融业务的发展步伐,同时与数据库和存储等技术的进步相互促进,共同推动金融业创新发展。在过去的半个世纪里,数据库技术架构的演变主要经历了以下三个阶段: 第一阶段(1960到1970年代):采用存算分离架构的文件 系统数据库,支持单体应用。 早期的数据管理系统主要以文件系统为基础,先后发展出网状数据库(IDS)和层次数据库(IMS)等形态。IBM于1966年推出的层次型数据库IMS,与该公司的服务器、存储和中间件等产品紧密结合,提供了一站式解决方案,有效满足核心业务交易和数据处理对高可用性的需求,被广泛应用于金融、航空和制造等领域。即便在互联网飞速发展的时代,这些行业依然在使用IBM的IMS数据库。然而,由于单一厂商的封闭系统带来昂贵的服务费用和有限扩展能力,这种解决方案成为仅在金融等少数行业应用。 第二阶段(1970年到2000年左右):关系型数据库蓬勃发 展,存算分离成为基础架构。 1970年代,IBM率先提出关系数据库模型并发布了SQL标准。 1979年,Oracle公司推出了首个商用关系型数据库,而IBM直到1983年才发布其关系型数据库DB2。此后,Sybase、SQLServer等其他商用关系型数据库也陆续进入市场,开启关系型数据库的繁荣时代。尽管如此,Oracle和DB2依然是市场最主流的商用 数据库产品。 与此同时,RAID磁盘专利和SCSI接口标准的发布,以及EMC推出的高端存储产品,都在吞吐性能、系统可靠性和容量扩展性等方面实现显著提升。由此,IT产业逐步形成以IBM小型机、Oracle数据库和EMC存储为核心的IOE架构。这一架构成为“开放”和“解耦”的存算分离架构的基石,推动金融业信息化应用的发展,并促进金融业集中业务处理的区域性数据中心建设。 第三阶段(2000年至今):数据库技术呈现多元化发展趋 势,存算分离架构依然是重要的架构方向。 2000年前后,随着互联网技术的广泛应用,数据库技术进入多元化混合发展的时代,数据库应用更加多样化。在此期间,X86服务器凭借其价格优势和通用性,一定程度上扩展了传统IOE架构的“开放性”,但由于x86服务器在吞吐性能上的局限性以及可靠性方面的不足,相较于传统IOE架构的服务器,新兴数据库应用被迫采用一主多副本、分库分片等存算一体的架构形态,以提升吞吐性能和可靠性。在金融互联网应用的初期,存算一体架构促进了互联网技术在金融业务场景中的迅速推广,成为金融业技术架构的重要补充。 但是,在存算一体架构下,上层应用对数据库不再是单一的数据访问,还需要考虑数据分布和可靠性等需求。这导致数据库架构设计对应用的侵入性增强,应用与数据库之间深度耦合,进而加剧了架构的“封闭性”。同时,随着金融新兴业务的扩张和基础设施规模的增大,存算一体架构在可靠性和扩展性方面的局限性逐渐显现,比如:存算一体架构中任意单节点的计算或存储 故障都可能引发数据丢失和业务中断,带来业务连续性风险;存算一体架构无法实现存储和计算资源的独立扩展,两者必须同步扩展,造成一定的资源浪费。 另外,随着NVMeOverFabric、RDMA和存储介质等技术的成熟应用,计算与存储之间的网络带宽得到显著提升,有效缓解了存算分离架构在吞吐性能上的瓶颈。通过利用存储的RAID和快照等高可靠特性,可以设计出多层次的容灾和备份方案,既简化了系统架构和运维,又提高了整体业务系统的可靠性。 2.1金融场景业务特性 金融业的业务场景多种多样,根据面向客户和内部管理的不同需求,可将业务系统主要分为两大类:生产交易系统(TP)和数据智能分析系统(AP)。 图1金融业主要业务场景 生产交易系统主要为客户提供一系列对外服务,覆盖支付与清算、核心交易、中间业务、银行卡、信贷管理、用户管理以及 3 渠道接入等关键领域。这类系统对实时数据处理、随机数据访问和业务连续性有着极高要求,因此通常采用本地双活加异地主备的容灾方案。 鉴于生产交易系统的联机事务处理(OLTP)特性,OLTP数据库因其出色的实时响应能力、高并发处理能力、强数据一致性以及高可用性等优点而受到青睐。根据金融信息化研究所《金融业数据库创新发展报告(2024)》数据显示,在金融业的数据库应用领域中,OLTP数据库实例数占比65%,充分体现了其在维护金融服务稳定性方面的核心地位。 数据智能分析系统虽不直接面向客户,但在辅助银行实现高效运营和管理方面发挥着重要作用。该平台支持多种业务系统,如反欺诈和反洗钱等风险管理系统、银行产品绩效管理、用户画像和精准营销等。 数据智能分析系统正逐步演进为支持准实时处理的系统,为关键业务提供及时的决策支持。这类系统具备批量数据处理和顺序数据访问的特点,因此容灾方案主要采用同城或者异地的主备容灾方案,鲜有本地双活方案。 在处理联机分析处理(OLAP)业务的数据智能分析平台中,OLAP数据库凭借其对复杂查询的高效处理、灵活的数据分析能力以及支持多维数据模型等优势,满足数据智能分析平台对数据处理和分析的需求。在金融业数据库应用中,OLAP数据库实例数占比约为21%。 近年来,随着大数据技术的迅猛发展,金融数据分析平台的数据湖和湖仓一体正逐步转向存算分离架构。然而,在生产交易场景中,数据库处理的业务不仅至关重要,而且结构极为复杂,使得从传统封闭架构向开放解耦架构转型的过程中面临诸多挑战,包括性能、可靠性、扩展性、成本和能耗等多个方面。因此,本文将着重分析生产交易场景下数据库处理的业务特性。 2.2金融业数据库应用的基础架构问题和需求 随着金融数字化转型的深入,金融业务形态发生显著变化,特别是面向客户提供服务的网上银行、手机银行和支付网关等新兴技术的应用,使得金融业务模式从传统的线下网点服务扩展到线上服务,从原来的5*8小时服务延长到7*24小时不间断业务服务。这些业务模式的变化,极大地推动了移动金融服务的快速发展,也正在深刻影响并重塑着金融业数据库应用的基础架构。 图2金融业生产交易场景的基础架构 从多数银行公布的年报来看,新兴金融服务交易量年均增长率超过50%,数据量年增长率约为30%。新兴业务模式拓宽金融服务的触达渠道,延长服务时间,同时也正在重塑金融业的数据中心基础架构。为适应未来业务发展,数据中心基础设施必须在性能、可靠性、扩展性、能耗和总成本之间寻求最优架构。具体表现如下: 2.2.1吞吐性能 业务量的激增对数据基础设施的性能和吞吐量提出更高要求,例如数据库读写时延需小于1ms。一般银行业务平均SQL请求数约为30-50次,每次SQL请求涉及约10次以上的存储IO读 写。以中等银行生产业务峰值交易量约5000笔/秒(即5000TPS)为例,峰值业务处理所需的存储IO请求能力约为每秒1.5-2.5百万次读写(IOPS)。这种吞吐性能对传统存算一体架构的服务器构成巨大挑战,因为服务器CPU算力不仅要负责业务处理,还要完成数据可靠性、数据加密和数据压缩等复杂的存储处理任务,导致CPU资源紧张。然而,通过采用存算分离架构,所有数据存储的IO请求可以卸载到外置存储系统中处理,从而减轻服务器CPU的负载,使其无需处理存储IO请求,进而提升服务器CPU在业务处理方面的能力。 2.2.2可靠性 服务时间的延长对整体架构的可用性提出更高要求,数据中心基础架构的可靠性需提升至99.9999%以上,以满足整体业务可用性99.999%的要求。 中等规模银行的核心系统交易量通常在1000-3000笔每秒, 每秒的系统中断和不可用都会导致1000笔以上的交易损失和用户流失。存算一体架构的x86服务器在可靠性上仅能达到99%。金融业统计显示,x86服务器使用超过5年,故障率超过0.5%。如果采用服务器本地磁盘作为数据库存储,服务器上的RAID卡或硬盘亚健康等故障都可能影响数据库的数据访问,给生产交易系统的业务连续性带来严峻挑战。而在存算分离架构下,服务器仅负责数据逻辑处理,数据的持久化和可靠性等能力则由存储设 备统一承担,且存储设备的可靠性远高于服务器,通过存储阵列RA