CN110287212A

CN110287212A - 一种数据业务处理方法、系统及相关组件

Info

Publication number: CN110287212A
Application number: CN201910569477.4A
Authority: CN
Inventors: 李松青; 杨刚
Original assignee: Inspur Power Commercial Systems Co Ltd
Current assignee: Inspur Power Commercial Systems Co Ltd
Priority date: 2019-06-27
Filing date: 2019-06-27
Publication date: 2019-09-27

Abstract

本申请公开了一种数据业务处理方法，应用于数据库集群系统的主库服务器，包括接收数据业务请求并判断所述数据业务请求是否为SELECT SQL语句；若是，则利用GPU执行所述数据业务请求对应的数据处理操作；若否，则利用CPU执行所述数据业务请求对应的数据处理操作。本申请能够降低SELECT SQL语句对于数据库服务器联机交易类业务的影响。本申请还公开了一种数据业务处理系统、一种计算机可读存储介质及一种电子设备，具有以上有益效果。

Description

一种数据业务处理方法、系统及相关组件

技术领域

本发明涉及数据存储技术领域，特别涉及一种数据业务处理方法、系统、一种计算机可读存储介质及一种电子设备。

背景技术

在传统关系型数据库(RDBMS)产品及方案中，当数据库系统中复杂查询或统计分析类业务需求较多时，复杂的SELECT SQL语句会消耗较多的数据库服务器CPU、内存和IO资源，处理时长经常会不能满足用户业务要求。这类SQL消耗资源过多时，同时又会影响到联机交易类业务的响应时间和并发能力。

因此，如何降低SELECT SQL语句对于数据库服务器联机交易类业务的影响是本领域技术人员目前需要解决的技术问题。

发明内容

本申请的目的是提供一种数据业务处理方法、系统、一种计算机可读存储介质及一种电子设备，能够降低SELECT SQL语句对于数据库服务器联机交易类业务的影响。

为解决上述技术问题，本申请提供一种数据业务处理方法，应用于数据库集群系统的主库服务器，该数据业务处理方法包括：

接收数据业务请求并判断所述数据业务请求是否为SELECT SQL语句；

若是，则利用GPU执行所述数据业务请求对应的数据处理操作；

若否，则利用CPU执行所述数据业务请求对应的数据处理操作。

可选的，接收数据业务请求并判断所述数据业务请求是否为SELECT SQL语句包括：

接收数据业务请求，并利用PostgreSQL数据库解析所述数据业务请求；

根据解析结果判断所述数据库应用请求是否为所述SELECT SQL语句。

可选的，还包括：

在所述PostgreSQL数据库中加载PGStrom扩展组件，并激活PGStrom加速功能。

可选的，还包括：

当所述数据业务请求为所述SELECT SQL语句时，判断所述数据业务请求是否为只读SQL查询任务；

若是，则将预设数量个所述只读SQL查询任务转发至所述数据库集群系统的备库服务器，以便所述备库服务器执行只读SQL查询操作。

可选的，所述备库服务器为配置有GPU且激活PGStrom加速功能的服务器。

可选的，还包括：

当检测到所述主库服务器故障时，向所述备库服务器发送切换指令，以便将所述备库服务器设置为新的主库服务器。

可选的，利用CPU执行所述数据业务请求对应的数据处理操作包括：

利用所述CPU执行所述数据业务请求对应的OLTP联机交易处理类业务数据归档业务、数据备份业务或数据恢复业务。

本申请还提供了一种数据业务处理系统，应用于数据库集群系统的主库服务器，该系统包括：

请求判断模块，用于接收数据业务请求并判断所述数据业务请求是否为SELECTSQL语句；

OLTP处理模块，用于当所述数据业务请求为SELECT SQL语句时，利用GPU执行所述数据业务请求对应的数据处理操作；

OLAP处理模块，用于当所述数据业务请求不为SELECT SQL语句时，利用CPU执行所述数据业务请求对应的数据处理操作。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序执行时实现上述数据业务处理方法执行的步骤。

本申请还提供了一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时实现上述数据业务处理方法执行的步骤。

本申请提供了一种数据业务处理方法，包括接收数据业务请求并判断所述数据业务请求是否为SELECT SQL语句；若是，则利用GPU执行所述数据业务请求对应的数据处理操作；若否，则利用CPU执行所述数据业务请求对应的数据处理操作。

本申请在接收到数据业务请求时，首先判断该数据业务请求是否为SELECT SQL语句，若为SELECT SQL语句则利用GPU数据业务请求进行相应的处理。由于联机分析处理业务通常为SELECT SQL语句，本申请能够利用GPU处理联机分析业务，利用CPU处理联机交易业务。因此本申请能够降低SELECT SQL语句对于数据库服务器联机交易类业务的影响。本申请同时还提供了一种数据业务处理系统、一种计算机可读存储介质和一种电子设备，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例所提供的一种数据业务处理方法的流程图；

图2为本申请实施例所提供的一种数据业务处理方法的流程图；

图3为一种主/备集群架构示意图；

图4为一种分布式集群架构示意图；

图5为本申请实施例所提供的一种数据业务处理系统的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面请参见图1，图1为本申请实施例所提供的一种数据业务处理方法的流程图。

具体步骤可以包括：

S101：接收数据业务请求并判断所述数据业务请求是否为SELECT SQL语句；若是，则进入S102；若否，则进入S103；

其中，本实施例可以应用于数据库集群系统的主库服务器，在主库服务器接收到数据业务请求后，首先判断该数据业务请求是否为SELECT SQL语句，若是，则说明该业务请求为联机分析处理业务请求。由于SELECT SQL语句会消耗较多的数据库服务器CPU、内存和IO资源，因此本实施例首先判断是否为SELECT SQL语句，根据对应的情况区分处理，以便GPU执行SELECT SQL语句的业务请求，CPU执行非SELECT SQL语句的业务请求。

联机分析处理业务指联机分析处理过程(On-Line Analytical Processing，OLAP)涉及的业务。

S102：利用GPU执行所述数据业务请求对应的数据处理操作；

其中，本实施例中的主库服务器为设置有GPU的服务器，当然在主库服务器所在的数据库集群系统中还可已存在设置有GPU的备库服务器，可以存在主库服务器将SELECTSQL语句的数据业务请求发送至备库服务器，利用备库服务器执行相关处理操作的方案。

作为一种可行的实施方式，本实施例可以在判定所述数据业务请求为所述SELECTSQL语句时，判断所述数据业务请求是否为只读SQL查询任务；若是，则将预设数量个所述只读SQL查询任务转发至所述数据库集群系统的备库服务器，以便所述备库服务器执行只读SQL查询操作。通过设置备库服务器执行相应的数据业务可以降低主库服务器的业务压力，以便主库服务器正常提供联机交易类业务。进一步的，上述提到的备库服务器可以为配置有GPU且激活PGStrom加速功能的服务器。作为一种可行的实施方式，当检测到所述主库服务器故障时，向所述备库服务器发送切换指令，以便将所述备库服务器设置为新的主库服务器。

S103：利用CPU执行所述数据业务请求对应的数据处理操作。

其中，本步骤建立在数据业务请求不为SELECT SQL语句的基础上，此时可以判定该数据业务请求可以为OLTP业务或涉及增、删、改的数据处理业务。OLTP(On-lineTransaction Processing)即联机事务交易处理过程设计的业务。

本实施例在接收到数据业务请求时，首先判断该数据业务请求是否为SELECT SQL语句，若为SELECT SQL语句则利用GPU数据业务请求进行相应的处理。由于联机分析处理业务通常为SELECT SQL语句，本实施例能够利用GPU处理联机分析业务，利用CPU处理联机交易业务。因此本实施例能够降低SELECT SQL语句对于数据库服务器联机交易类业务的影响。

若将上述实施例应用于主/备数据库集群，则可以存在至少以下三种实施方案：方案1：主/备数据库集群配置两台服务器，分别做主库服务器和备库服务器。其中，主库服务器配置GPU，激活开源PGStrom加速功能，利用GPU实现对复杂查询SQL性能加速；备库服务器不配置GPU，不激活开源PGStrom加速功能，备库服务器可以选择是否承接部分只读查询SQL应用，增强集群性能和可用性。方案2：集群配置两台服务器，分别做主库服务器和备库服务器。主库服务器和备库服务器都配置GPU，并激活开源PGStrom加速功能，实现对复杂查询SQL性能加速。备库服务器可以选择是否承接部分只读查询SQL应用，增强集群性能和可用性。方案3：集群配置3台及以上服务器，其中两台服务器分别做主库服务器和第一备库服务器，主库服务器和第一备库服务器都配置GPU，并激活开源PGStrom加速功能，实现对复杂查询SQL性能加速。其余备库服务器可以选择配置GPU与否，如果配置GPU则激活开源PGStrom加速功能，如果不配置GPU则不激活开源PGStrom加速功能。所有备库服务器可以选择是否承接部分只读查询SQL应用，增强集群性能和可用性。

若将上述实施例应用于PostgreSQL关系型数据库的分布式数据库集群，则可以存在至少以下两种实施方案：方案1：分布式集群中各数据分片只配置主库服务器，不配置备库服务器。各数据分片的主库服务器都配置GPU，激活开源PGStrom加速功能，实现对复杂查询SQL性能加速。方案2：分布式集群中各数据分片配置主库服务器和备库服务器。各数据分片的主库服务器和备库服务器都配置GPU，激活开源PGStrom加速功能，实现对复杂查询SQL性能加速，并增强集群可用性。

下面请参见图2，图2为本申请实施例所提供的一种数据业务处理方法的流程图。

具体步骤可以包括：

S201：在所述PostgreSQL数据库中加载PGStrom扩展组件，并激活PGStrom加速功能。

其中，PGStrom扩展组件时一种PostgreSQL数据库的扩展组件，PGStrom扩展组件可以利用GPU和NVME SSD加速查询类数据分析工作负载，实现数据业务的快速处理。

S202：接收数据业务请求，并利用PostgreSQL数据库解析所述数据业务请求；

S203：根据解析结果判断所述数据库应用请求是否为所述SELECT SQL语句；若是，则进入S204；若否，则进入S205；

S204：利用GPU执行所述数据业务请求对应的数据处理操作；

S205：利用所述CPU执行所述数据业务请求对应的OLTP联机交易处理类业务数据归档业务、数据备份业务或数据恢复业务。

本实施例旨在基于传统关系型数据库(RDBMS)构建高性能、高可用的数据库系统方案，使得它既能对OLTP联机交易类业务提供快速响应和高并发能力，又能对OLAP类业务实现海量数据实时在线分析能力。本实施例将复杂的SELECT SQL语句自动转到具有强大并行计算处理能力的GPU处理，实现海量数据实时在线分析。本实施例可以大大降低减少查询统计分析类SQL的CPU资源开销，确保集群内服务器有充足CPU资源能同时为OLTP类联机交易业务提供快速响应和高并发。

下面通过在实际应用中的两个实施例说明上述实施例描述的流程。

实例一：一种主/备集群架构

请参见图3，图3为一种主/备集群架构示意图。在主/备数据库集群中，主库服务器为可读可写数据库，数据库中所有涉及增/删/改的DML和DML SQL均由主库完成。所有备库服务器可以仅用于只读SQL查询。对于前端数据库应用请求，可以通过中间件进行读/写分离和负载均衡分发，可以将部分只读SQL查询应用传输至备库服务器进行处理。

需要说明的是，在本实施例中在本实施例中可以包括多个备库服务器，为了进行区分，可以将其命名为第一备库服务器、第二备库服务器......第N备库服务器，本实施例不对备库服务器的数量进行限定。作为一种可行的实施方式，本实施例中主库服务器和第一备库服务器可以配置GPU。图3中第二备库服务器至第N备库服务器为虚线框，表示可以选择这些备库，也可以选择不配置，也就是说本实施例可以根据实际应用场景选择是否选配这些备库。具体的，如果选择配置第二备库服务器至第N备库服务器中一台或多台服务器，这些备库服务器也可以选择配置或者不配置GPU，在此不进行具体的限定。

本实施例提供的数据库集群中任一配有GPU的服务器节点上可以安装有NVIDIAGPU CUDA驱动，以便在PostgreSQL数据库配置中加载PGStorm扩展组件模块(动态库)并激活PGStrom扩展功能。

作为一种可行的实施方式，当SQL语句的数据业务请求发送到已激活PGStrom的数据库节点时，如果PostgreSQL数据库解析发现是SELECT查询SQL且SQL包含目标特征中一个或多个。目标特征包括：(1)进行表/表分区/索引/索引分区的全部或部分扫描；(2)需要进行2个或2个以上表的HASH JOIN/NEST LOOP/OUTER JOIN；(3)数值预算、数学运算；(4)排序运算；(5)分组运算、聚合运算。当包括一个或多个目标特征时，本实施例可以自动将SQL转到GPU处理，利用GPU强大的处理能力对这些SQL语句实现性能加速。

当主库服务器发生故障时，第一备库服务器可以接管主库服务器成为新的主库服务器，并暂停主/备库服务器之间数据复制。当主库服务器的故障恢复后，原主库服务器可以成为新的第一备库服务器，并自动恢复新的主/备库之间数据复制。作为一种可行的实施方式，当第二备库服务器至第N备库服务器中任一服务器发生故障时，可以不执行不发生上述角色转换，可以暂停存在故障的备库服务器的数据复制，直至故障恢复再自动恢复数据复制；

当然，在集群正常运行过程中，主库服务器和第一备库服务器之间可以按需随时进行角色互换，以确保整个集群可持续服务的高可用性。

实例二：分布式集群架构

请参见图4，图4为一种分布式集群架构示意图。分布式数据库集群可以按用户业务/数据特点，由业务/数据分发模块按照数据分片规则在N台(N≥3)数据库集群服务器上尽可能均衡的存/取数据。本实施例可以对每个数据分片都配置一台带GPU的服务器用作该数据分片的主库服务器，也可以为整个集群的各主库服务器构建统一视图的数据存储。存储媒介可以采用SAN共享存储，每台主库服务器可以查看和操作所有数据分片；存储媒介也可以采用非SAN共享存储，每份数据分片的数据保留2-3份数据拷贝，将数据分散到2-3台不同的主库服务器上。这样不管是采用共享存储还是非共享存储，都能保证数据本身的高可用性。

本实施例可以选择为集群中每台主库服务器选配一台对应的带GPU的备库服务器(对应架构中各虚线框部分)。当任一数据分片的主库服务器发生故障，备库服务器可以接管故障主库成为该数据分片的新的主库服务器，并暂停该数据分片的主/备库之间数据复制。原主库服务器恢复后，可以将原主库服务器设置为该数据分片的新的备库服务器，并自动恢复新的主/备库之间数据复制。这样在任一节点故障情况下，整个分布式集群能维持原有的均衡状态，确保整个数据库集群持续服务能力和高可用性。

作为一种可行的实施方式，本实施例可以选择不给各主库服务器配置备库服务器。当任一数据分片的主库服务器发生故障，由集群选取其它数据分片的一台或多台主库服务器接管该数据分片原主库服务器的负载。当故障主库恢复后，将该数据分片应分担的负载接管回来，通过上述方式也可以为整个集群保持持续服务能力的高可用性。

本实施例中的每个数据分片的主库服务器可以为可读可写数据库，数据库中所有涉及增/删/改的DML和DML SQL均由主库服务器完成，所有备库服务器可以仅用于只读SQL查询。需要说明的是，本实施例中主库服务器和选配的备库服务器都可以配置GPU，数据库集群中各台配有GPU的服务器节点上，安装NVIDIA GPU CUDA驱动,在PostgreSQL数据库配置中加载PGStorm扩展组件模块(动态库)，并激活PGStrom组件功能。当SQL语句的数据业务请求发送到已激活PGStrom的数据库节点时，如果PostgreSQL数据库解析发现是SELECT查询SQL，且SQL包含目标特征中一个或多个。具体的目标特征包括：(1)进行表/表分区/索引/索引分区的全部或部分扫描；(2)需要进行2个或2个以上表的HASH JOIN/NEST LOOP/OUTERJOIN；(3)数值预算、数学运算；(4)排序运算；(5)分组运算、聚合运算。当包括一个或多个目标特征时，本实施例可以将SQL语句转到GPU处理，利用GPU强大的处理能力对这些SQL实现性能加速。

上述两种数据库集群方案基于传统成熟的开源PostgreSQL关系型数据库，利用开源PGStrom组件实现，无需额外使用软件。数据库集群中CPU与GPU自动分工协作，GPU自动接管复杂查询SELECT SQL语句，完成对海量数据的大部分OLAP类查询统计/实时分析业务功能，CPU则专注于处理OLTP联机交易处理类业务及其它(如：数据/日志归档、备份/恢复)应用。数据库应用开发无需做任何更改，用户不用进行额外的应用开发，亦不改变数据库维护方式，不会给用户增加额外维护成本。对于用户构建单套数据库集群既能处理各种业务场景，上述两种数据库集群方案不用分别建设OLTP联机交易和OLAP在线分析多套数据库系统，也可省去多套数据库间数据同步的麻烦。方案具有成本低效率高的优势。相对于传统PostgreSQL关系型数据库的主/备数据库集群方案或者分布式数据库集群方案，上述两种数据库集群方案能为用户提供持续可靠的数据库服务。本实施例是对传统方案进行部分改进，给集群配置带有GPU的服务器，为PostgreSQL数据库激活PGStrom组件，将消耗CPU/IO/内存资源最多耗时最长的复杂查询SQL转到GPU处理，依靠GPU的强大并行处理能力，能大大缩短复杂查询SQL耗时，达到几倍至几百倍的性能加速。同时它能降低服务器CPU资源消耗，从而使整个集群能提供更强的联机交易并发能力，确保更高的可用性。进一步的，硬件平台如果采用OpenPower的GPU服务器，则可以利用上Power CPU与NVidia GPU独有的NVLink高速互联，带宽远高于通过PCIe连接CPU与GPU的服务器，可以进一步缩短复杂查询SQL耗时。

请参见图5，图5为本申请实施例所提供的一种数据业务处理系统的结构示意图；

该系统可以应用于数据库集群系统的主库服务器，该系统可以包括：

请求判断模块100，用于接收数据业务请求并判断所述数据业务请求是否为SELECT SQL语句；

OLTP处理模块200，用于当所述数据业务请求为SELECT SQL语句时，利用GPU执行所述数据业务请求对应的数据处理操作；

OLAP处理模块300，用于当所述数据业务请求不为SELECT SQL语句时，利用CPU执行所述数据业务请求对应的数据处理操作。

进一步的，请求判断模块100包括：

解析单元，用于接收数据业务请求，并利用PostgreSQL数据库解析所述数据业务请求；

语句判断单元，用于根据解析结果判断所述数据库应用请求是否为所述SELECTSQL语句。

进一步的，还包括：

加速功能激活模块，用于在所述PostgreSQL数据库中加载PGStrom扩展组件，并激活PGStrom加速功能。

进一步的，还包括：

进一步的，所述备库服务器为配置有GPU且激活PGStrom加速功能的服务器。

进一步的，还包括：

主备切换模块，用于当检测到所述主库服务器故障时，向所述备库服务器发送切换指令，以便将所述备库服务器设置为新的主库服务器。

进一步的，OLAP处理模块300具体为利用所述CPU执行所述数据业务请求对应的OLTP联机交易处理类业务数据归档业务、数据备份业务或数据恢复业务的模块。

由于系统部分的实施例与方法部分的实施例相互对应，因此系统部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

本申请还提供了一种计算机可读存储介质，其上存有计算机程序，该计算机程序被执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请还提供了一种电子设备，可以包括存储器和处理器，所述存储器中存有计算机程序，所述处理器调用所述存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然所述电子设备还可以包括各种网络接口，电源等组件。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的状况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims

1.一种数据业务处理方法，其特征在于，应用于数据库集群系统的主库服务器，包括：

2.根据权利要求1所述数据业务处理方法，其特征在于，接收数据业务请求并判断所述数据业务请求是否为SELECT SQL语句包括：

3.根据权利要求2所述数据业务处理方法，其特征在于，还包括：

4.根据权利要求1所述数据业务处理方法，其特征在于，还包括：

5.根据权利要求4所述数据业务处理方法，其特征在于，所述备库服务器为配置有GPU且激活PGStrom加速功能的服务器。

6.根据权利要求4所述数据业务处理方法，其特征在于，还包括：

7.根据权利要求1所述数据业务处理方法，其特征在于，利用CPU执行所述数据业务请求对应的数据处理操作包括：

8.一种数据业务处理系统，其特征在于，应用于数据库集群系统的主库服务器，包括：

请求判断模块，用于接收数据业务请求并判断所述数据业务请求是否为SELECT SQL语句；

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述数据业务处理方法的步骤。

10.一种电子设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述数据业务处理方法的步骤。