当前,随着数字化技术的发展以及基础软件设施等信息系统关键环节的自主可控要求,金融企业加速数字化转型升级并呈现出数智赋能、开放融合以及全面安全信任等全新发展态势。数据库作为金融行业中信息系统基础设施的关键组件,成为金融领域数字化转型和信创改造的一个难点。
近几年,金融业数据库根据可信的发展要求和创新的发展理念,有序的推进着多种类型的数据库在金融行业的应用实践。根据金融信息化研究所最新发布的《金融业数据库创新发展报告》显示,金融业数据库发展呈现4个特性:
1) 集中式分布式数据库应用占比较高,分布式数据库应用呈现增长趋势。根据2022年金融行业数据库供应链调研数据,金融业集中式数据库占比高达89%,其中银行80%、证券和保险行业占比均超90%。由此可以看到集中式数据库在金融机构中仍将发挥至关重要的作用,不过分布式数据库的使用占比也在不断增长,预期将会出现集中式和分布式并存发展的技术架构趋势。
2) OLTP类数据库应用占比较高,OLAP和HTAP类应用需求不断增加。在金融行业的业务类型中交易和账务类业务的业务比重,而随着海量数据的存储以及不同种类的业务发展需要,偏报表处理及分析的AP类业务需求不断增加。
3) 非关系型数据库在金融行业加快探索实践。针对一些大数据量的加工处理以及文本、图像等特殊场景的数据存储和加工,非关系型数据库在金融行业得到广泛应用,并结合机器学习和人工智能及大模型算法,赋能业务实现数据价值。
4) 开源数据库在金融行业得到广泛使用。以MySQL和PostgreSQL为代表的开源数据库由于其开放性和便捷性、功能丰富性受到开发人员的青睐,主要应用于非关键业务系统和内部管理类系统中。
同时金融行业作为关系国计民生的关键行业,在数据库的国产化信创改造方面也是有序稳步展开。以IBM大型机下移为代表的核心系统数据库国产化替换、传统Oracle和DB2数据库为代表的关系型替换工作以及办公管理类系统的信创改造在金融行业已经有不少成功的实施案例,并且在金融行业内部以及行业外的其它应用系统中逐步推广,积累了丰富的数据库国产化实施经验和标准化的建设规范。本文将重点关注关系型数据库的国产化技术路线。
2.2.1数据库信创的三种主流技术技术架构
关系型国产化数据库在传统的集中式数据库的基础之上,随着分布式技术的发展和应用,又演进出分布式数据库的技术架构。因此,国产化数据库的主流技术架构包括国产集中式数据库架构、基于中间件的类分库分表的分布式数据库架构以及原生的分布式数据库架构。三种技术架构如下图所示,各自具备以下特性:
以上几种国产数据库的技术架构各自有不同的特性,并且适合不同的应用场景,实际实施过程中根据不同的需求及场景进行选择。
2.2.2 国产化集中式数据库与分布式数据库特性对比分析
在国产数据库的选型中不得不提到集中式数据库和分布式数据库的技术特点以及优缺点。分布式数据库是在集中式数据库的基础上发展起来的,满足架构上的横向扩展需求,并且具备高可靠和高并发的特性。下表列举了国产化集中式数据库和分布式数据库的一些特性,主要从技术架构和扩展性、数据可靠性和服务可用性、应用性能及侵入性以及运维管理的复杂度进行对比分析:
运维管理的复杂性:集中式数据库简单易管理,而分布式数据库整体架构变得更为复杂,在故障定位、统一监控采集分析以及问题排查上都增加了难度。
对比集中式和分布式数据库的特性能够看到,二者并不是非此即彼的关系,而是结合应用实际情况做最佳的选择。像分布式数据库也由互联网应用逐渐转向传统的关键性企业,国产化的集中式数据库也在进行传统集中式数据库Oracle和DB2等业务的迁移探索,在应用实践中不断的优化提升。国产集中式数据库有很多种,像达梦、人大金仓、OpenGauss等在金融行业也广泛使用,下文将重点介绍基于PostgreSQL系列的国产集中式数据库实现。
PostgreSQL是开源免费的关系型数据库,最早从加州大学伯克利分校写的POSTGRES软件包发展而来,经过二十多年的发展,已经成为广为流行的开源数据库。PostgreSQL支持大部分的SQL标准,并且兼容ACID事务特性,同时支持多种语言开发如PL/pgSQL、C/C++、Python、Java、Go等。除此之外,PostgreSQL还具备以下特性:
性能优化工具与度量信息丰富:PostgreSQL数据库中有大量的性能视图,可以方便地定位问题。设计了专门架构和进程用于收集性能数据,既有物理I/O方面的统计,也有表扫描及索引扫描方面的性能数据。
PostgreSQL是多进程单线程的架构,如图所示包括客户端进程、后端进程postgres和后台进程。作为一款企业级的数据库,PostgreSQL功能强大并且稳定可靠,相比于Oracle传统的集中式数据库来说,更为轻量级、安装和维护也更为简单,并且在功能上和性能上也满足大部分应用的需求。因此在数据库国产化的技术演变中,使用PostgreSQL数据库或者基于PostgreSQL开源改造的国产数据库也成长起来。
基于PostgreSQL内核开发的国产集中式数据库系统,具备高可靠、高性能、高安全、易运维和全开放等特性。
和原生的PostgreSQL数据库相比,二者在底层架构和数据存储方面类似,但国产数据库在性能和扩展性方面进行了优化。主要在以下方面:
对比PostgreSQL可以看到,国产化数据库对数据库引擎的性能和架构做了适配性改造,更符合国产化的需求,以满足信创环境下大规模和复杂的数据处理请求。
3.3.1 基于PostgreSQL的国产集中式数据库单节点架构介绍
基于PostgreSQL国产集中式数据库在逻辑架构上分为管理模块、数据库实例以及存储节点:
3.3.2 基于PostgreSQL的国产集中式数据库高可用架构
基于PostgreSQL国产集中式数据库在本地AZ内1主1备和1主多备部署,至少保证一个备节点同步复制RPO=0,其它备节点可以采用异步复制的方式。主备节点是等价的,当主节点故障后自动切换到备节点对外提供服务。本地一主多备的高可用架构适合一般的业务系统。
生产和同城双AZ部署,当生产站点故障时能够切换到同城站点继续提供服务,保证业务的连续性。生产和同城站点至少有一个备节点是同步复制,保证RPO=0。同时DN主节点多数派选主或者Paxos协议,两个站点主备节点配置为奇数。另外在应用的竖井式架构中,同城站点只有只读服务,如果想同步读写操作,需要应用交互式访问生产中心的数据库实例。生产同城双中心架构适合于有业务连续性质保障要求的一般重要系统。
这种架构将生产同城站点和灾备站点分为两个独立的集群,灾备站点的集群会选出首备连接主集群的主DN,灾备集群内都以级联备方式连接首备,灾备集群RPO>0。主集群和灾备集群可以选择不同的组网,满足容灾切换的要求,同时也不会影响到应用性能。两地三中心的架构适合系统可靠性高的核心重要业务系统。
基于PostgreSQL国产集中式数据库基于1主多备多中心的高可用架构,满足金融行业重要业务系统的业务连续性要求,具备容灾切换和跨中心的访问能力。对比分布式数据库的多中心部署架构应用单元化改造、基础设施部署成本增加以及跨分片事务访问带来的性能问题,集中式数据库架构有以下优势:
当然和分布式数据库对比,集中式数据库存在受限于单台服务器的处理能力不能支撑高并发的业务请求以及集群故障对业务的全局影响等缺点,在具体的应用实践过程中结合实际的业务场景和需求进行统筹分析。
综合PostgreSQL数据库的特性、高可用部署架构以及处理性能,国产集中式数据库主要适合以下应用场景。
1)大数据量且并发不高的复杂查询应用
支持行列存储引擎,满足AP类场景的复杂查询需求,适合一些数据量大但是并发不高的复杂查询业务。当然和大数据量及高并发的数据加工和分析类大数据组件及数据仓库类数据库相比,集中式数据库受限于单个服务器的性能。在部署架构上没有强制要求异地灾备环境,只需要使用信创虚拟机本地部署最小集群一主一备,保证业务的高可用。同时利用集中式存储设备可以存放大量的数据。
2)非关键业务系统以及并发不高的混合型交易应用
对于一些联机和批量混合型的业务如下游的报表加工平台、历史查询等,一般使用存储过程执行复杂的业务访问,通常是运行在传统的Oracle或DB2等集中式数据库中。利用国产集中式数据库的高性能优势,进行Oracle或DB2数据库的国产化信创改造,在部署上也是使用信创虚拟机本地部署最小集群,同时能够利用集中式存储设备存放大量的数据。
3)一般重要业务系统且并发不高的联机交易类应用
对于一些联机交易比重较多的重要业务系统,使用国产集中式数据库进行国产化数据库信创改造的时候,在架构上需要建立同城或异地灾备环境,以满足系统架构的高可用和业务的连续性要求。部署的服务器选择信创虚拟机,结合集中式存储保存大量的数据。
4)重要业务系统且并发不高的联机交易类应用
对于金融行业内的中小机构来说,单台PC物理机的性能已经能够满足核心和账务类等关键业务系统的要求,因此使用国产集中式数据库进行国产化替换是最合适的。在高可用架构上采用多中心部署,满足容灾切换和业务连续性RPO和RTO要求。当然受限于物理服务器磁盘空间,这类业务数据量不能过大。如果是一些大中型的机构的核心系统,业务的TPS和数据量远超过单台物理机的性能和容量,必须使用分布式数据库的架构。
基于PostgreSQL国产集中式数据库的应用场景总结如下表所示:
注:对于单库的数据量尤其是单表的大小建议不能过大,比如单库超过100T等,因为库过大增加日常运维管理的复杂度,比如备份恢复时长、表结构和索引变更耗时更长等。
以上是金融行业基于PostgreSQL技术路线的国产化数据库替代方案分析,受限于个人的技术和理解,内容不当之处请指正。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞8
添加新评论7 条评论
2024-04-01 16:37
2024-02-26 19:16
2024-02-26 17:17
2024-02-22 15:28
2024-02-22 15:20
2024-02-22 13:06
2024-02-21 17:55