数据请求处理方法、装置、服务器、系统及存储介质

技术领域

本说明书涉及数据库技术领域，尤其涉及数据请求处理方法、装置、服务器、系统及存储介质。

背景技术

业务方面临用户发起的数据请求，这些数据请求可能有不同类型，不同类型的数据请求的执行效率不同，基于此需要提供处理效率更好的数据请求处理方案。

发明内容

为克服相关技术中存在的问题，本说明书提供数据请求处理方法、装置、服务器、系统及存储介质。

根据本说明书实施例的第一方面，提供一种数据请求处理方法，所述方法应用于代理服务端，所述方法包括：

获取请求端发起的数据请求；

将所述数据请求发送给数据库服务集群中的第一类数据库节点，以由所述第一类数据库节点识别所述数据请求的类别并执行识别出的第一类数据请求；

将所述第一类数据库节点识别出的第二类数据请求发送给数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

根据本说明书实施例的第二方面，提供一种数据请求处理方法，所述数据请求处理方法应用于数据库服务集群中的第一类数据库节点，所述方法包括：

接收代理服务端发送的数据请求；

识别所述数据请求的类别；

若所述数据请求为第一类数据请求，则执行所述第一类数据请求；

若所述数据请求为第二类数据请求，通知所述代理服务端，以使所述代理服务端将所述第二类数据请求发送给所述数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

根据本说明书实施例的第三方面，提供一种分布式系统，包括代理服务端以及数据库服务集群；所述数据库服务集群包括：至少一个第一类数据库节点和至少一个第二类数据库节点；

所述代理服务端用于：获取请求端发起的数据请求；将所述数据请求发送给所述第一类数据库节点；将所述第一类数据库节点识别出的第二类数据请求发送给所述第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销；

所述第一类数据库节点用于：识别数据请求的类别，并执行识别出的第一类数据请求，以及识别出所述数据请求为第二类数据请求后通知所述代理服务端；

所述第二类数据库节点用于：执行所述第二类数据请求。

根据本说明书实施例的第三方面，提供一种数据请求处理装置，所述装置应用于代理服务端，所述装置包括：

获取模块，用于：获取请求端发起的数据请求；

发送模块，用于：将所述数据请求发送给数据库服务集群中的第一类数据库节点，以由所述第一类数据库节点识别所述数据请求的类别并执行识别出的第一类数据请求；将所述第一类数据库节点识别出的第二类数据请求发送给数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

根据本说明书实施例的第四方面，提供一种数据请求处理装置，所述数据请求处理装置应用于数据库服务集群中的第一类数据库节点，所述装置包括：

接收模块，用于：接收代理服务端发送的数据请求；

识别模块，用于：识别所述数据请求的类别；

执行模块，用于：在所述数据请求为第一类数据请求的情况下，执行所述第一类数据请求；在所述数据请求为第二类数据请求的情况下，通知所述代理服务端，以使所述代理服务端将所述第二类数据请求发送给所述数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

根据本说明书实施例的第五方面，提供一种代理服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

获取请求端发起的数据请求；

将所述数据请求发送给数据库服务集群中的第一类数据库节点，以由所述第一类数据库节点识别所述数据请求的类别并执行识别出的第一类数据请求；

将所述第一类数据库节点识别出的第二类数据请求发送给数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

根据本说明书实施例的第六方面，提供一种数据库节点，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

接收代理服务端发送的数据请求；

识别所述数据请求的类别；

若所述数据请求为第一类数据请求，则执行所述第一类数据请求；

若所述数据请求为第二类数据请求，通知所述代理服务端，以使所述代理服务端将所述第二类数据请求发送给所述数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

根据本说明书实施例的第七方面，提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述数据请求处理方法的实施例。

根据本说明书实施例的第八方面，提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述数据请求处理方法的实施例。

本说明书的实施例提供的技术方案可以包括以下有益效果：

本说明书实施例中，配置有第一类数据库节点和第二类数据库节点，基于执行开销来区分第一类数据请求和第二类数据请求，由代理服务端将未能识别出类别的数据库请求发送给第一类数据库节点进行识别，若第一类数据库节点识别出是第一类数据库请求，则可以直接执行，若识别出是第二类数据请求则可通知代理服务端，由代理服务端发送给第二类数据库节点。本实施例实现了第一类数据请求和第二类数据请求的物理隔离，执行开销较大的第二类数据请求不会影响第一类数据请求的执行效率，并且由第一类数据库节点进行请求类型的识别，执行效率较快。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。

图1是本说明书根据一示例性实施例示出的一种数据请求处理方法的应用场景示意图。

图2是本说明书根据一示例性实施例示出的另一种数据请求处理方法的应用场景示意图。

图3是本说明书根据一示例性实施例示出的一种数据请求处理方法的流程图。

图4是本说明书根据一示例性实施例示出的另一种数据请求处理方法的流程图。

图5是本说明书根据一示例性实施例示出的一种数据请求处理装置所在计算机设备的一种硬件结构图。

图6是本说明书实施例提供的一种数据请求处理装置的结构框图。

图7是本说明书实施例提供的另一种数据请求处理装置的结构框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

根据数据的使用特征，数据处理大致可以分成两大类：联机事务处理OLTP（On-Line Transaction Processing）、联机分析处理OLAP（On-Line Analytical Processing）。

OLTP，联机事务处理是指透过信息系统、电脑网络及数据库，以在线交易的方式处理一般即时性的作业数据，和更早期传统数据库系统大量批量的作业方式并不相同。OLTP是传统的关系型数据库的主要应用，是事件驱动、面向应用的，也称为面向交易的处理过程，通常被运用于自动化的数据处理工作，如订单输入、金融业务…等反复性的日常性交易活动。也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。

其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作的快速响应。例如银行类、电子商务类的交易系统就是典型的OLTP系统。

OLTP具备以下特点：直接面向应用，数据在系统中产生。基于交易的处理系统。每次交易牵涉的数据量很小；对响应时间要求非常高。用户数量非常庞大，其用户是操作人员，并发度很高。数据库的各种操作主要基于索引进行。通常以SQL作为交互载体。总体数据量相对较小。

和其相对的是属于决策分析层次的联机分析处理（OLAP）。

OLAP，联机分析处理，是计算机技术中快速解决多维分析问题（MDA）的一种方法。OLAP是更广泛的商业智能范畴的一部分，它还包括关系数据库、报告编写和数据挖掘。OLAP的典型应用包括销售业务报告、市场营销、管理报告、业务流程管理（BPM）、预算和预测、财务报表以及类似领域。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLAP是面向数据分析的，也称为面向信息分析处理过程。它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。其特点是应对海量数据，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果，例如数据仓库是其典型的OLAP系统。

OLAP具备以下特点：本身不产生数据，其基础数据来源于生产系统中的操作数据。基于查询的分析系统；复杂查询经常使用多表联结、全表扫描等，牵涉的数量往往十分庞大。每次查询设计的数据量很大，响应时间与具体查询有很大关系。用户数量相对较小，其用户主要是业务人员与管理人员。由于业务问题不固定，数据库的各种操作不能完全基于索引进行。以SQL为主要载体，也支持语言类交互。总体数据量相对较大。

一些业务方提供了多样化的服务，提供了基于OLTP和OLAP两种数据库架构的整合HTAP（Hybrid Transaction and Analytical Process，混合事务分析引擎）服务。HTAP既可以应用于事务型数据库场景，亦可以应用于分析型数据库场景，能实现实时业务决策，能提升资源利用率以及提升数据库的使用便利性。

在HTAP数据库架构下，业务方面临用户发起的数据请求，可能是OLTP类型的数据请求，也可以是OLAP类型的数据请求。由前述分析可知，基于OLTP和OLAP的特点，业务方面临的数据请求大部分是属于OLTP类型、单个语句开销较小的数据请求，少部分是分析型的、即OLAP类型的数据请求。这些少量的OLAP类型的数据请求，通常会扫描大量的数据行造成对数据表的锁争抢，在执行过程中也会占用非常大的资源，并且由于执行较长，也会降低用于存放数据请求的缓冲池的整体吞吐，甚至一些数据请求还有可能造成数据库实例瘫痪。

基于此，有必要提供一种数据请求处理方案以解决上述问题。本实施例的数据请求处理方案适用于包括有第一类数据请求和第二类数据请求的应用场景。在本实施例中，所述的第一类数据请求和第二类数据请求是基于数据请求的执行开销而区分的，其中第一类数据请求的执行开销小于第二类数据请求。作为例子，本实施例的数据请求处理方案可应用于前述的HTAP数据库架构中，第一类数据请求可以是前述的OLTP请求，第二数据请求可以是前述的OLAP请求。当然，本实施例方案还可根据需要应用于其他业务场景。

如图1所示，图1是本说明书根据一示例性实施例示出的一种数据请求处理方法的应用场景示意图，图1中的数据请求处理系统包括：配置于业务方侧的代理服务端以及数据库服务集群；

本实施例的图1中还示出了用户侧的请求端，请求端可以向业务方发起数据请求。

本实施例的代理服务端可以获取数据请求；此处的获取，可以是指请求端的数据请求直接发送至代理服务端，也可以是客户端的数据请求发送至业务方配置的其他功能的服务端（例如负载均衡服务器），通过其他功能的服务端获取。本实施例的代理服务端可以是配置于一台独立的服务器中，也可以配置于服务器集群中的每台服务器中。

本实施例的数据服务器集群，包括至少两类数据库节点，分别用于处理两类数据请求。其中，第一类数据库节点处理第一类数据请求，第二类数据库节点处理第二类数据请求。其中，第一类数据请求的执行开销小于第二类数据请求。作为例子，第一类数据请求可以是前述的OLTP请求，第二数据请求可以是前述的OLAP请求。

由上述实施例可见，本实施例方案中配置有第一类数据库节点和第二类数据库节点，基于执行开销来区分第一类数据请求和第二类数据请求，由代理服务端将未能识别出类别的数据库请求发送给第一类数据库节点进行识别，若第一类数据库节点识别出是第一类数据库请求，则可以直接执行，若识别出是第二类数据请求则可通知代理服务端，由代理服务端发送给第二类数据库节点。本实施例实现了第一类数据请求和第二类数据请求的物理隔离，执行开销较大的第二类数据请求不会影响第一类数据请求的执行效率，并且由第一类数据库节点进行请求类型的识别，执行效率较快。

在一些例子中，考虑到第一类数据请求具有的高并发特征，以及数量多、执行开销较小等特点，第一类数据库节点采用串行计算模式，串行处理数据请求，使得数据库节点的资源可以集中处理每条数据请求，使每条数据请求得以快速执行。

而第二类数据请求具有数量较少和执行开销较长等特点，因此第二类数据库节点采用并行计算模式，从而在面临第二数据请求执行过程中涉及的大量的数据计算，因此可以利用并行计算的方式使得数据请求得到快速执行。

本实施例不限定第一类数据库节点和第二类数据库节点的数量或比例，具体可根据需要而灵活配置。作为例子，第一类数据请求具有高并发特征，第一类数据库节点的数量可以大于第二类数据库节点的数量。在另一些例子中，也可以是用户划定第一类数据库节点的数量和第二类数据库节点的数量。

根据数据请求是否需要涉及数据表的更新操作，数据请求还可以分为只读请求和读写请求。本实施例中的第二类数据请求涉及数据分析，属于只读数据请求，不涉及对数据表的写操作。而第一类数据请求可能是只读请求，也可能是读写请求。其中，对于如何确定所接收的数据请求是读写请求还是只读请求，可以通过根据实际业务中所具体采用的数据库查询和程序设计语言，通过分析接收的数据请求的语句即可确定。

对于HTAP架构的业务方来说，其向用户提供了OLTP服务和OLAP服务，因此对于业务方来说，面对客户端发起的数据请求需要区分所接收的数据请求是第一类数据请求还是第二类数据请求。对于前述分析可知，若接收到的数据请求是读写请求，则可以确定该数据请求是第一类数据请求，并非第二类数据请求。若接收到的数据请求是只读请求，需要识别该只读请求是第一类数据请求还是第二类数据请求。

本实施例以数据请求的执行开销进行识别。在一些例子中，所述执行开销可以包括：执行所述数据请求所需要扫描的数据行的数量。通常，第二类数据请求是基于数据分析的需求而发起的，因此需要从数据表中扫描很多行数据，以读取数据进行分析，因此若该数据请求需要扫描的数据行的数量较多，则可以确定该数据请求为第二类数据。

本实施例中，由于第一类数据请求的数量较多，因此本实施例中，所述代理服务端还可用于：将获取的数据请求发送给所述第一类数据库节点，获取由所述第一类数据库节点识别出的第二类数据请求后，将所述第二类数据请求发送给所述第二类数据库节点。也即是，数据请求可以先发至第一类数据库节点，由于第一类数据请求通常较多，而第一类数据库节点数量也较多具有较强的处理能力，因此本实施例将未能识别出类别的数据库请求直接发送给第一类数据库节点进行识别，若第一类数据库节点识别出是第一类数据库请求，则可以直接执行，若识别出是第二类数据请求则可通知代理服务端，由代理服务端发送给第二类数据库节点。

在一些例子中，代理服务端可以通过负载均衡的方式将数据库请求分发给第一类数据库节点进行识别。

在一些例子中，代理服务端发送数据库请求给第一类数据库节点进行识别的方式，可以是在本端保留该数据库请求，当接收到第一类数据库节点的第二类数据请求的通知消息时，可以将本端的保留该数据库请求发送给第二类数据库节点。在另一些例子中，处理方式还可以是代理服务端直接将待识别的数据库请求发送给第一类数据库节点，第一类数据库节点识别出是第二类数据请求后将该请求再次发送给代理服务端，由代理服务端发送给第二类数据库节点。

数据请求在被执行前，其实际需要扫描的数据行的数量是未知的，因此本实施例通过预估的方式确定执行所述数据请求所需要扫描的数据行的数量。可选的，预估方式由数据库节点的CBO（Cost-Based Optimization，基于代价的优化器）优化器执行。在另一些例子中，也可以是代理服务端配置有预估模块，由代理服务端进行执行开销的预估。在其他例子中，还可以是配置有其他服务端对数据请求的执行开销进行预估。作为例子，CBO优化器可以根据SQL语句生成一组可能被使用的执行计划，估算出每个执行计划的代价，并调用计划生成器（Plan Generator）生成执行计划，比较执行计划的代价，最终选择选择一个代价最小的执行计划。

本实施例中，具体的第一类数据请求与第二类数据请求的执行开销的界定，可以是由业务方界定，也可以是用户方界定。本实施例将第一类数据请求与第二类数据请求的执行开销的界定称为预设执行开销阈值，该预设执行开销阈值可以是一具体数值，也可以是一数值范围。

基于此，根据预设执行开销阈值，第一类数据库节点用于预估数据请求的执行开销，通过对比预估的执行开销与预设执行开销阈值，识别所述数据请求是否属于第二类数据请求。本实施例通过第一类数据库节点的CBO模块预估出执行开销后，可以确定接收的只读请求是否为第二类数据请求。例如，若预估的执行开销大于预设执行开销阈值，则可确定是第二类数据请求。第一数据库节点可以将识别结果发送给代理服务端，由代理服务端将该识别出的第二类数据请求发送至第二类数据库节点进行执行。

本实施例中，对于识别出的第二类数据请求，代理服务端还可用于：在获取由所述第一类数据库节点识别出的第二类数据请求后，确定所述识别出的第二类数据请求的特征并存储为所述历史第二类数据请求的特征。本实施例通过记录第二类数据请求的特征，可以在后续获取到相同的数据请求时，代理服务端可以直接确定并发送至第二类数据库节点。具体的，在代理服务端记录有历史第二类数据请求的特征的情况下，所述代理服务端在接收到数据请求后，可以先将获取的数据请求与历史第二类数据请求的特征进行匹配，根据匹配结果确定数据请求的类别。对于与历史第二类数据请求的特征匹配的数据请求，则可确定属于第二类数据请求，可以直接发送至第二类数据库节点，不需要进行执行开销的预估，因此可以提高处理效率。

本实施例中，历史第二类数据请求的特征可以包括：历史第二类数据请求中包含的请求参数。本实施例可以读取历史第二类数据请求中所包含的一个或多个请求参数，并将读取的请求参数作为该历史第二类数据请求的特征，后续接收到数据请求时，通过读取接收的数据请求中的请求参数，与该历史第二类数据请求的特征进行匹配。例如，历史第二类数据请求中涉及的参数包括4个参数：A参数、B参数、C参数和D参数，若接收的数据请求中的请求参数也包括这4个参数，则可认为两者匹配。

可选的，代理服务端记录的历史第二类数据请求的特征可以采用多种方式实现，例如可以是历史第二类数据请求的特征的哈希值，则匹配过程可以是接收的数据请求中的请求参数的哈希值，与历史第二类数据请求的特征的哈希值的匹配。

本实施例中，代理服务端处于请求端与数据库服务集群之间，数据库服务集群中的数据库节点在执行所述数据请求后，可以将执行结果通过所述代理服务器发送给所述请求端。

基于此，代理服务器可以获取到每条数据请求的执行结果。考虑到前述的本实施例中执行开销的预估可能有误，本实施例还可以采取事后补偿模式进行修正。作为例子，所述代理服务端还可用于：根据所述第一类数据请求的执行结果，确定所述第一类数据请求的实际执行开销，通过对比所述实际执行开销与预设执行开销阈值，确定对所述第一类数据请求的执行开销是否预估错误。

基于此，第一类数据请求的执行开销是否预估错误的结果可以用于对前述预估功能的改进。在另一些例子中，对于预估错误的情况，其表示一个第二类数据请求未被识别出、被当做第一类数据请求进行处理，因此若代理服务端发现，第一类数据请求的实际执行开销大于预设执行开销阈值，则该第一类数据请求应该是第二类数据请求，因此可以该第一类数据请求的特征并存储为所述历史第二类数据请求的特征；因此与前述提及的一样，基于此可以补充历史第二类数据请求的特征，后续对于与历史第二类数据请求的特征匹配的数据请求，则可确定属于第二类数据请求，可以直接发送至第二类数据库节点，不需要进行执行开销的预估。

本实施例中，在数据库服务集群场景下，面临的数据请求较多，数据库节点比较多，通常会配置有负载均衡服务器，本实施例的代理服务端可配置于负载均衡服务器上。由于第一类数据请求通常较多，所述代理服务端还用于：若确定所述第一类数据库节点的处理压力满足设定溢出条件，将第一类数据请求发送给第二类数据库节点执行。由此可见，本实施例采用单向隔离的方式，第一类数据请求可以溢出至第二类数据库节点执行。其中，所述处理压力和设定溢出条件可以根据实际业务灵活配置。例如，第一类数据库节点的处理压力可以是指第一类数据库节点的当前剩余物理资源，所述设定溢出条件可以是指第一类数据库节点的当前剩余物理资源剩余5%等，本实施例对此不作限定。

如图2所示，是本说明书根据一示例性实施例示出的另一种数据请求处理场景示意图。在图2中，以应用于HTAP数据库架构为例，Proxy指代理服务器，Proxy内配置有一HTAPfilter（过滤器），该过滤器用于执行本说明书实施例中代理服务端的功能，TP表示第一类数据库节点，AP表示第二类数据库节点；RO表示只读处理，RW表示读写处理；本实施例中，TP可以是一个读写节点，可以具有只读处理功能和读写处理功能，图2中示出了TP的一个RO任务和一个RW任务；AP可以是一个只读节点，具有只读处理功能，图2中示出了AP的两个RO任务。

数据库集群分成两组：TP节点和AP节点，其中TP节点采用串行计算的方式，串行执行数据请求；AP节点开采用并行计算的方式，并行执行数据请求；开启并行计算有利于AP类型的请求执行。

数据请求的处理流程可以是：

（1）Proxy接收请求端的数据请求，这些数据请求根据负载均衡逻辑路由到了数据库集群中的某个TP节点；

TP节点接收到数据请求；对于只读数据请求，对执行开销进行预估；如果TP节点中的CBO模块判断这个SQL的开销是否超过max_join_size（预设执行开销阈值，本实施例采用扫描行数），如果未超过，则认为该数据请求是一个OLTP请求数据请求（即第一类数据请求），则该数据请求在本节点执行。

（2）如果CBO判断开销超过max_join_size，则可认为该数据请求是一个OLAP请求（即第二类数据请求）则返回错误消息给Proxy。

（3）Proxy重新将这个SQL发到AP节点，并获取该SQL的特征，下次同样特征的SQL到来时可以直接转发到AP节点。

请求执行完成后，执行结果返回给Proxy，Proxy再返回给请求端，Proxy统计实际扫描行数，若CBO预估不准确造成一个本属于OLAP的请求被当做OLTP请求执行，在执行完成后Proxy统计实际扫描行数，若超过了max_join_size则把该SQL标记为OLAP类型的SQL，当该SQL下次被执行时可以直接转发到AP节点。如图3所示，图3是本说明书根据一示例性实施例示出的一种数据请求处理方法的流程图，所述方法应用于代理服务端，包括以下步骤：

在步骤302、获取请求端发起的数据请求。

在步骤304、将所述数据请求发送给数据库服务集群中的第一类数据库节点，以由所述第一类数据库节点识别所述数据请求的类别并执行识别出的第一类数据请求。

在步骤306、将所述第一类数据库节点识别出的第二类数据请求发送给数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销

可选的，所述执行开销包括：执行数据请求所需要扫描的数据行的数量。

可选的，在所述将所述数据请求发送给第一类数据库节点之前，所述方法还包括：

将获取的数据请求与历史第二类数据请求的特征进行匹配；

若根据匹配结果未确定所述数据请求的类别，则执行所述将所述数据请求发送给第一类数据库节点的步骤；

若根据匹配结果确定出所述数据请求的类别，将确定出的第一类数据库请求发送给第一类数据库节点，将确定出的第二类数据请求发送给第一类数据库节点。

可选的，所述第一类数据库节点用于：预估所述数据请求的执行开销，通过对比预估的执行开销与预设执行开销阈值，识别所述数据请求是否属于第二类数据请求。

可选的，所述方法还包括：在获取由所述第一类数据库节点识别出的第二类数据请求后，确定所述识别出的第二类数据请求的特征并存储为所述历史第二类数据请求的特征。

可选的，所述数据库服务集群中的数据库节点用于：执行所述数据请求后，将执行结果通过所述代理服务端发送给所述请求端。

可选的，所述方法还包括：根据所述第一类数据请求的执行结果，确定所述第一类数据请求的实际执行开销，通过对比所述实际执行开销与预设执行开销阈值，确定对所述第一类数据请求的执行开销是否预估错误。

可选的，所述方法还包括：若所述实际执行开销大于预设执行开销阈值，确定对应的第一类数据请求的特征并存储为所述历史第二类数据请求的特征。

可选的，所述历史第二类数据请求的特征包括：历史第二类数据请求中包含的请求参数。

可选的，所述第二类数据请求为只读数据请求。

可选的，所述第一类数据库节点用于：串行处理数据请求；所述第二类数据库节点用于：并行处理数据请求。

可选的，所述第一类数据请求包括：联机事务处理OLTP请求，所述第二类数据请求包括：联机分析处理OLAP请求。

可选的，所述代理服务端配置于负载均衡服务器中。

可选的，在所述获取请求端发起的数据请求后，所述方法还包括：若确定所述第一类数据库节点的处理压力满足设定溢出条件，将第一类数据请求发送给第二类数据库节点执行。

如图4所示，图4是本说明书根据一示例性实施例示出的另一种数据请求处理方法的流程图，所述数据请求处理方法应用于数据库服务集群中的第一类数据库节点，包括以下步骤：

在步骤402中，接收代理服务端发送的数据请求；

在步骤404中，识别所述数据请求的类别；

在步骤406中，若所述数据请求为第一类数据请求，则执行所述第一类数据请求；

在步骤408中，若所述数据请求为第二类数据请求，通知所述代理服务端，以使所述代理服务端将所述第二类数据请求发送给所述数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

可选的，所述第一类数据库节点为读写节点，第二类数据库节点为只读节点。

可选的，所述识别所述数据请求的类别，包括：

预估所述数据请求的执行开销，通过对比预估的执行开销与预设执行开销阈值识别所述数据请求的类别。

可选的，在所述执行所述第一类数据请求后，还包括：将执行结果发送给所述代理服务端。

可选的，所述执行所述第一类数据请求，包括：串行执行所述第一类数据请求。

可选的，所述第一类数据库节点用于：串行执行第一类数据请求；所述第二类数据库节点用于：并行执行第二类数据请求。

与前述数据请求处理方法的实施例相对应，本说明书还提供了数据请求处理装置及其所应用的设备的实施例。

本说明书数据请求处理装置的实施例可以应用在计算机设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在数据请求处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本说明书数据请求处理装置所在计算机设备的一种硬件结构图，除了图5所示的处理器510、内存530、网络接口520、以及非易失性存储器540之外，实施例中数据请求处理装置531所在的计算机设备，通常根据该计算机设备的实际功能，还可以包括其他硬件，对此不再赘述。

本实施例的计算机设备可以是代理服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

获取请求端发起的数据请求；

将所述数据请求发送给数据库服务集群中的第一类数据库节点，以由所述第一类数据库节点识别所述数据请求的类别并执行识别出的第一类数据请求；

将所述第一类数据库节点识别出的第二类数据请求发送给数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

可选的，所述执行开销包括：执行数据请求所需要扫描的数据行的数量。

可选的，所述处理器还用于在所述将所述数据请求发送给第一类数据库节点之前，实现如下步骤：

将获取的数据请求与历史第二类数据请求的特征进行匹配；

若根据匹配结果未确定所述数据请求的类别，则执行所述将所述数据请求发送给第一类数据库节点的步骤；

若根据匹配结果确定出所述数据请求的类别，将确定出的第一类数据库请求发送给第一类数据库节点，将确定出的第二类数据请求发送给第一类数据库节点。

可选的，所述第一类数据库节点用于：预估所述数据请求的执行开销，通过对比预估的执行开销与预设执行开销阈值，识别所述数据请求是否属于第二类数据请求。

可选的，所述处理器还用于实现：在获取由所述第一类数据库节点识别出的第二类数据请求后，确定所述识别出的第二类数据请求的特征并存储为所述历史第二类数据请求的特征。

可选的，所述数据库服务集群中的数据库节点用于：执行所述数据请求后，将执行结果通过所述代理服务端发送给所述请求端。

可选的，所述处理器还用于实现：根据所述第一类数据请求的执行结果，确定所述第一类数据请求的实际执行开销，通过对比所述实际执行开销与预设执行开销阈值，确定对所述第一类数据请求的执行开销是否预估错误。

可选的，所述处理器还用于实现：若所述实际执行开销大于预设执行开销阈值，确定对应的第一类数据请求的特征并存储为所述历史第二类数据请求的特征。

可选的，所述历史第二类数据请求的特征包括：历史第二类数据请求中包含的请求参数。

可选的，所述第二类数据请求为只读数据请求。

可选的，所述第一类数据库节点用于：串行处理数据请求；所述第二类数据库节点用于：并行处理数据请求。

可选的，所述第一类数据请求包括：联机事务处理OLTP请求，所述第二类数据请求包括：联机分析处理OLAP请求。

可选的，所述代理服务端配置于负载均衡服务器中。

可选的，所述处理器还用于实现：在所述获取请求端发起的数据请求后，若确定所述第一类数据库节点的处理压力满足设定溢出条件，将第一类数据请求发送给第二类数据库节点执行。

如图6所示，是本说明书实施例提供的一种数据请求处理装置的结构框图，所述装置可应用于代理服务端，所述装置包括：

获取模块61，用于：获取请求端发起的数据请求；

发送模块62，用于：将所述数据请求发送给数据库服务集群中的第一类数据库节点，以由所述第一类数据库节点识别所述数据请求的类别并执行识别出的第一类数据请求；将所述第一类数据库节点识别出的第二类数据请求发送给数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

本实施例的计算机设备可以是数据库节点，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

接收代理服务端发送的数据请求；

识别所述数据请求的类别；

若所述数据请求为第一类数据请求，则执行所述第一类数据请求；

若所述数据请求为第二类数据请求，通知所述代理服务端，以使所述代理服务端将所述第二类数据请求发送给数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

可选的，所述第一类数据库节点为读写节点，第二类数据库节点为只读节点。

可选的，所述识别所述数据请求的类别，包括：

预估所述数据请求的执行开销，通过对比预估的执行开销与预设执行开销阈值识别所述数据请求的类别。

可选的，在所述执行所述第一类数据请求后，还包括：将执行结果发送给所述代理服务端。

可选的，所述执行所述第一类数据请求，包括：串行执行所述第一类数据请求。

可选的，所述第一类数据库节点用于：串行执行第一类数据请求；所述第二类数据库节点用于：并行执行第二类数据请求。

如图7所示，是本说明书实施例提供的另一种数据请求处理装置的结构框图，所述数据请求处理装置应用于数据库服务集群中的第一类数据库节点，所述装置包括：

接收模块71，用于：接收代理服务端发送的数据请求；

识别模块72，用于：识别所述数据请求的类别；

执行模块73，用于：在所述数据请求为第一类数据请求的情况下，执行所述第一类数据请求；在所述数据请求为第二类数据请求的情况下，通知所述代理服务端，以使所述代理服务端将所述第二类数据请求发送给所述数据库服务集群中的第二类数据库节点；其中，所述第一类数据请求的执行开销小于第二类数据请求的执行开销。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

本实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述图3所示数据请求处理方法的实施例。

本实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述图4所示数据请求处理方法的实施例。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。