1背景

当前，随着数字化技术的发展以及基础软件设施等信息系统关键环节的自主可控要求，金融企业加速数字化转型升级并呈现出数智赋能、开放融合以及全面安全信任等全新发展态势。数据库作为金融行业中信息系统基础设施的关键组件，成为金融领域数字化转型和信创改造的一个难点。

2金融行业数据库信创技术路线分析

2.1 金融行业数据库国产化发展现状

近几年，金融业数据库根据可信的发展要求和创新的发展理念，有序的推进着多种类型的数据库在金融行业的应用实践。根据金融信息化研究所最新发布的《金融业数据库创新发展报告》显示，金融业数据库发展呈现4个特性：
1) 集中式分布式数据库应用占比较高，分布式数据库应用呈现增长趋势。根据2022年金融行业数据库供应链调研数据，金融业集中式数据库占比高达89%，其中银行80%、证券和保险行业占比均超90%。由此可以看到集中式数据库在金融机构中仍将发挥至关重要的作用，不过分布式数据库的使用占比也在不断增长，预期将会出现集中式和分布式并存发展的技术架构趋势。
2) OLTP类数据库应用占比较高，OLAP和HTAP类应用需求不断增加。在金融行业的业务类型中交易和账务类业务的业务比重，而随着海量数据的存储以及不同种类的业务发展需要，偏报表处理及分析的AP类业务需求不断增加。
3) 非关系型数据库在金融行业加快探索实践。针对一些大数据量的加工处理以及文本、图像等特殊场景的数据存储和加工，非关系型数据库在金融行业得到广泛应用，并结合机器学习和人工智能及大模型算法，赋能业务实现数据价值。
4) 开源数据库在金融行业得到广泛使用。以MySQL和PostgreSQL为代表的开源数据库由于其开放性和便捷性、功能丰富性受到开发人员的青睐，主要应用于非关键业务系统和内部管理类系统中。

同时金融行业作为关系国计民生的关键行业，在数据库的国产化信创改造方面也是有序稳步展开。以IBM大型机下移为代表的核心系统数据库国产化替换、传统Oracle和DB2数据库为代表的关系型替换工作以及办公管理类系统的信创改造在金融行业已经有不少成功的实施案例，并且在金融行业内部以及行业外的其它应用系统中逐步推广，积累了丰富的数据库国产化实施经验和标准化的建设规范。本文将重点关注关系型数据库的国产化技术路线。

2.2 金融行业数据库信创技术路线分析

2.2.1数据库信创的三种主流技术技术架构
关系型国产化数据库在传统的集中式数据库的基础之上，随着分布式技术的发展和应用，又演进出分布式数据库的技术架构。因此，国产化数据库的主流技术架构包括国产集中式数据库架构、基于中间件的类分库分表的分布式数据库架构以及原生的分布式数据库架构。三种技术架构如下图所示，各自具备以下特性：

• 基于国产集中式数据库构建数据库主备复制架构：该架构由一个主数据库实例和多个备数据库实例组成，主节点提供读写服务、备节点提供只读服务，数据集中存储在存储节点。通过主备节点保证数据库的高可用，另外备节点扩展了读请求服务能力。国产数据库中像达梦和OpenGauss等属于典型的集中式数据库架构。
• 基于分库分表的分布式架构：该架构将数据分成不同的分片，每个分片又存储在不同的存储节点，且单个分片是主备复制架构以保证高可用。业务请求经过数据库中间件（计算节点）解析和路由分发到不同的数据分片，实现分布式功能。同时通过全局事务协调节点来保证事务的全局一致性。这种架构满足业务增长的横向扩展需求、以及高并发的业务处理能力，缺点是应用需要指定分片信息对应用侵入较大，而且涉及到跨分片的事务访问性能较差。国产分布式数据库中TDSQL、GoldenDB等都属于这种架构。
• 原生的分布式架构：该架构是将数据以Region或分区的维度分布在不同的数据库实例上，每个实例都独立处理自己的请求。每一份数据基于Paxos或Raft一致性算法复制到不同的数据库实例上，保证了数据的高可用性和一致性。相比较分库分表的方案，数据库对应用来说是透明的，不需要修改应用增加分片信息等，应用像访问单个数据库一样，简化了应用的开发和维护成本。国产数据库中OceanBase、TiDB等都属于这种架构。
  
  图1 数据库国产化三种主流技术路线

以上几种国产数据库的技术架构各自有不同的特性，并且适合不同的应用场景，实际实施过程中根据不同的需求及场景进行选择。

2.2.2 国产化集中式数据库与分布式数据库特性对比分析
在国产数据库的选型中不得不提到集中式数据库和分布式数据库的技术特点以及优缺点。分布式数据库是在集中式数据库的基础上发展起来的，满足架构上的横向扩展需求，并且具备高可靠和高并发的特性。下表列举了国产化集中式数据库和分布式数据库的一些特性，主要从技术架构和扩展性、数据可靠性和服务可用性、应用性能及侵入性以及运维管理的复杂度进行对比分析：

• 产品架构的扩展性：集中式数据库只能在节点内横向扩展，最终会受到单个服务器的容量限制；而分布式数据库支持实例级别的横向扩展，满足业务增长的扩容需求。同时分布式架构下多个实例能够同时处理业务的访问请求，满足业务的高并发访问。
• 架构的可靠性及服务可用性：在架构上集中式数据库和分布式数据库都能通过一主多备的架构满足系统和数据的可用性。当集中式数据库整个实例不可用时，所有业务访问将中断，而在分布式数据库架构中当单个分片或者实例出现故障，只是局部业务受到影响，降低了故障影响范围，提高了服务的可用性。
• 应用性能和侵入性：分布式数据库由于涉及到分布式组件之间的访问调用以及网络开销，对于单条SQL语句来说性能不一定最优，而且对比基于中间件分库分表的数据库，应用需要对应修改分片键信息，增加了应用的改造成本。集中式数据库作为单个实例的数据库，无需额外的性能开销、也没有跨分片的事务一致性问题，对应用是透明的。

运维管理的复杂性：集中式数据库简单易管理，而分布式数据库整体架构变得更为复杂，在故障定位、统一监控采集分析以及问题排查上都增加了难度。

对比集中式和分布式数据库的特性能够看到，二者并不是非此即彼的关系，而是结合应用实际情况做最佳的选择。像分布式数据库也由互联网应用逐渐转向传统的关键性企业，国产化的集中式数据库也在进行传统集中式数据库Oracle和DB2等业务的迁移探索，在应用实践中不断的优化提升。国产集中式数据库有很多种，像达梦、人大金仓、OpenGauss等在金融行业也广泛使用，下文将重点介绍基于PostgreSQL系列的国产集中式数据库实现。

3、金融行业关系型数据库信创技术路线选型：基于PostgreSQL系列的技术路线分析

3.1 PostgreSQL技术路线的特点

PostgreSQL是开源免费的关系型数据库，最早从加州大学伯克利分校写的POSTGRES软件包发展而来，经过二十多年的发展，已经成为广为流行的开源数据库。PostgreSQL支持大部分的SQL标准，并且兼容ACID事务特性，同时支持多种语言开发如PL/pgSQL、C/C++、Python、Java、Go等。除此之外，PostgreSQL还具备以下特性：

• 支持复杂数据类型：除了常见的数据类型外，PostgreSQL还支持JSON、数组、范围、几何图形、全文搜索等多种复杂数据类型。
• 多版本并发控制（MVCC）：PostgreSQL使用多版本并发控制来管理事务，每个事务都可以看到一致的快照数据。
• 复杂查询：PostgreSQL支持复杂查询，包括联接、子查询、窗口函数等，因此能够灵活地查询和分析数据。同时内置了全文搜索功能，能够进行高效的文本搜索和分析。
• 复制和高可用性：PostgreSQL提供了复制和高可用性解决方案，包括流复制、逻辑复制和自动故障转移。

性能优化工具与度量信息丰富：PostgreSQL数据库中有大量的性能视图，可以方便地定位问题。设计了专门架构和进程用于收集性能数据，既有物理I/O方面的统计，也有表扫描及索引扫描方面的性能数据。

PostgreSQL是多进程单线程的架构，如图所示包括客户端进程、后端进程postgres和后台进程。作为一款企业级的数据库，PostgreSQL功能强大并且稳定可靠，相比于Oracle传统的集中式数据库来说，更为轻量级、安装和维护也更为简单，并且在功能上和性能上也满足大部分应用的需求。因此在数据库国产化的技术演变中，使用PostgreSQL数据库或者基于PostgreSQL开源改造的国产数据库也成长起来。

3.2 基于PostgreSQL的国产集中式数据库特性

基于PostgreSQL内核开发的国产集中式数据库系统，具备高可靠、高性能、高安全、易运维和全开放等特性。

• 高性能：面向多核架构的并发控制技术结合鲲鹏硬件优化，在两路鲲鹏下TPCC Benchmark达成性能150万tpmc。
• 高可靠：支持主备同步、异步和级联备机多种部署模式。数据页CRC校验，损坏数据页通过备机自动修复。备机并行恢复，10秒内可升主提供服务。
• 高安全：支持全密态计算、访问控制、加密认证、数据库审计和动态数据脱敏等安全特性，提供全方位端到端的数据安全保护。
• 运维管理便捷性：多维性能自监控视图，实时掌控系统的性能表现。

和原生的PostgreSQL数据库相比，二者在底层架构和数据存储方面类似，但国产数据库在性能和扩展性方面进行了优化。主要在以下方面：

• 执行模型：优化了线程池模型，满足高并发的访问需求
• NUMA改造：支持信创服务器的Numa适配，提升服务器的性能
• 存储引擎优化：支持列存和内存引擎，满足HTAP类业务场景需求
• 优化器优化：结合实际的应用场景支持CBO对复杂查询场景的优化能力

对比PostgreSQL可以看到，国产化数据库对数据库引擎的性能和架构做了适配性改造，更符合国产化的需求，以满足信创环境下大规模和复杂的数据处理请求。

3.3 基于PostgreSQL的国产集中式数据库架构

3.3.1 基于PostgreSQL的国产集中式数据库单节点架构介绍

基于PostgreSQL国产集中式数据库在逻辑架构上分为管理模块、数据库实例以及存储节点：

• 运维管理模块：提供数据库日常运维、配置管理的管理接口、工具等
• 数据库管理模块：管理和监控数据库系统中各个功能单元和物理资源的运行情况，确保整个系统的稳定运行。其提供数据库主备的状态监控、网络通信故障监控、文件系统故障监控、故障自动主备切换等能力。
• 数据库实例：负责存储业务数据、执行数据查询任务以及向客户端返回执行结果。在高可用架构下通常部署一主多备，并部署在不同的服务器上。
• 存储Storage：服务器的本地存储，用于数据持久化，支持集中式存储
• 客户端驱动：负责接收来自应用的访问请求，并向应用返回执行结果。客户端驱动负责与数据库实例通信，发送应用的SQL命令，接收数据库实例的执行结果。

3.3.2 基于PostgreSQL的国产集中式数据库高可用架构

1）本地1主1备和1主多备架构

基于PostgreSQL国产集中式数据库在本地AZ内1主1备和1主多备部署，至少保证一个备节点同步复制RPO=0，其它备节点可以采用异步复制的方式。主备节点是等价的，当主节点故障后自动切换到备节点对外提供服务。本地一主多备的高可用架构适合一般的业务系统。

2）同城双中心高可用架构

生产和同城双AZ部署，当生产站点故障时能够切换到同城站点继续提供服务，保证业务的连续性。生产和同城站点至少有一个备节点是同步复制，保证RPO=0。同时DN主节点多数派选主或者Paxos协议，两个站点主备节点配置为奇数。另外在应用的竖井式架构中，同城站点只有只读服务，如果想同步读写操作，需要应用交互式访问生产中心的数据库实例。生产同城双中心架构适合于有业务连续性质保障要求的一般重要系统。

3）多中心容灾架构

这种架构将生产同城站点和灾备站点分为两个独立的集群，灾备站点的集群会选出首备连接主集群的主DN，灾备集群内都以级联备方式连接首备，灾备集群RPO>0。主集群和灾备集群可以选择不同的组网，满足容灾切换的要求，同时也不会影响到应用性能。两地三中心的架构适合系统可靠性高的核心重要业务系统。

3.3.3 核心系统分布式数据库高可用架构对比

基于PostgreSQL国产集中式数据库基于1主多备多中心的高可用架构，满足金融行业重要业务系统的业务连续性要求，具备容灾切换和跨中心的访问能力。对比分布式数据库的多中心部署架构应用单元化改造、基础设施部署成本增加以及跨分片事务访问带来的性能问题，集中式数据库架构有以下优势：

• 应用改造成本低：应用不需要针对分布式进行单元化或者分片等改造，降低了开发成本以及开发难度。
• 交易链路更短：分布式架构下应用需要经过网关路由等组件，整个交易链路冗长，增加了应用的访问开销。在集中式数据库中，应用直接访问数据库，减少了中间的链路，提升了应用的性能。
• 分布式事务规避：分布式架构下涉及到跨中心的访问应用通过分布式事务算法保证事务的一致性，数据库内由分布式数据库实现数据的一致性。集中式数据库则规避了分布式访问，所有数据集中存储和访问。
• 基础设施部署成本：在分布式架构下多个分片和节点意味着更多的服务器（每个分片*N副本），同时计算节点的负载均衡需要额外的网络负载均衡设备实现。在集中式数据库中单个数据库实例满足业务需求，多份副本保证系统可用性，并且不需要额外的网络设备支撑。
• 数据存储的限制：核心系统分布式数据库单个数据库实例一般部署在PC物理机上，受限于单台服务器的存储限制，存储的数据量是有限制的，随着业务增长存在扩分片的需求。集中式数据库可以使用集中式存储设备，能够支撑更多的数据存储，不用担心数据增长横向扩容对业务的影响。
• 运维管理复杂性：分布式数据库管理组件和网元架构更为复杂，对运维监控、故障应急、问题定位等日常的运维管理也提出了更高的要求。集中式数据库继承了传统集中式数据库的运维管理经验，和现有的运维监控平台对接更为简便。

当然和分布式数据库对比，集中式数据库存在受限于单台服务器的处理能力不能支撑高并发的业务请求以及集群故障对业务的全局影响等缺点，在具体的应用实践过程中结合实际的业务场景和需求进行统筹分析。

4、基于PostgreSQL的国产集中式数据库应用场景分析

综合PostgreSQL数据库的特性、高可用部署架构以及处理性能，国产集中式数据库主要适合以下应用场景。

1）大数据量且并发不高的复杂查询应用
支持行列存储引擎，满足AP类场景的复杂查询需求，适合一些数据量大但是并发不高的复杂查询业务。当然和大数据量及高并发的数据加工和分析类大数据组件及数据仓库类数据库相比，集中式数据库受限于单个服务器的性能。在部署架构上没有强制要求异地灾备环境，只需要使用信创虚拟机本地部署最小集群一主一备，保证业务的高可用。同时利用集中式存储设备可以存放大量的数据。

2）非关键业务系统以及并发不高的混合型交易应用
对于一些联机和批量混合型的业务如下游的报表加工平台、历史查询等，一般使用存储过程执行复杂的业务访问，通常是运行在传统的Oracle或DB2等集中式数据库中。利用国产集中式数据库的高性能优势，进行Oracle或DB2数据库的国产化信创改造，在部署上也是使用信创虚拟机本地部署最小集群，同时能够利用集中式存储设备存放大量的数据。

3）一般重要业务系统且并发不高的联机交易类应用
对于一些联机交易比重较多的重要业务系统，使用国产集中式数据库进行国产化数据库信创改造的时候，在架构上需要建立同城或异地灾备环境，以满足系统架构的高可用和业务的连续性要求。部署的服务器选择信创虚拟机，结合集中式存储保存大量的数据。

4）重要业务系统且并发不高的联机交易类应用
对于金融行业内的中小机构来说，单台PC物理机的性能已经能够满足核心和账务类等关键业务系统的要求，因此使用国产集中式数据库进行国产化替换是最合适的。在高可用架构上采用多中心部署，满足容灾切换和业务连续性RPO和RTO要求。当然受限于物理服务器磁盘空间，这类业务数据量不能过大。如果是一些大中型的机构的核心系统，业务的TPS和数据量远超过单台物理机的性能和容量，必须使用分布式数据库的架构。

基于PostgreSQL国产集中式数据库的应用场景总结如下表所示：

注：对于单库的数据量尤其是单表的大小建议不能过大，比如单库超过100T等，因为库过大增加日常运维管理的复杂度，比如备份恢复时长、表结构和索引变更耗时更长等。

以上是金融行业基于PostgreSQL技术路线的国产化数据库替代方案分析，受限于个人的技术和理解，内容不当之处请指正。