CN117421331A - 数据查询优化方法、装置、设备及存储介质 - Google Patents

Abstract

本公开提供了数据查询优化方法、装置、设备及存储介质，涉及数据处理技术领域，尤其涉及分布式数据库、大数据、云计算等技术领域。具体实现方案为：确定目标查询请求的多个候选执行计划；确定多个候选执行计划的执行成本；基于多个候选执行计划中涉及的数据节点的监控数据，更新多个候选执行计划的执行成本，得到多个候选执行计划的最终成本；基于多个候选执行计划的最终成本，从多个候选执行计划中筛选出目标查询请求的最终执行计划。本公开实施例中，考虑了结合数据节点自身的情况对执行成本进行更新，有利于提高最终成本的准确性，从而有利于提高目标查询请求的最终执行计划的准确性，有利于基于最终执行计划实现数据查询的优化。

Description

数据查询优化方法、装置、设备及存储介质

技术领域

本公开涉及数据处理领域，尤其涉及分布式数据库、大数据、云计算等技术领域。

背景技术

针对数据库中的SQL(Structured Query Language，结构化查询语言)请求，通常能够通过多种执行计划来实现。而不同的执行计划可能需要不同的执行成本。在分布式数据库场景下，尤其是云分布式数据库，如何从多个执行计划中确定出合适的执行计划，是目前亟待解决的问题。

发明内容

本公开提供了一种数据查询优化方法、装置、设备及存储介质。

根据本公开的一方面，提供了一种数据查询优化方法，包括：

确定目标查询请求的多个候选执行计划；

确定多个候选执行计划的执行成本；

基于多个候选执行计划中涉及的数据节点的监控数据，更新多个候选执行计划的执行成本，得到多个候选执行计划的最终成本；

基于多个候选执行计划的最终成本，从多个候选执行计划中筛选出目标查询请求的最终执行计划。

根据本公开的另一方面，提供了一种数据查询优化装置，包括：

第一确定模块，用于确定目标查询请求的多个候选执行计划；

第二确定模块，用于确定多个候选执行计划的执行成本；

更新模块，用于基于多个候选执行计划中涉及的数据节点的监控数据，更新多个候选执行计划的执行成本，得到多个候选执行计划的最终成本；

筛选模块，用于基于多个候选执行计划的最终成本，从多个候选执行计划中筛选出目标查询请求的最终执行计划。

根据本公开的另一方面，提供了一种电子设备，包括：

至少一个处理器；以及

与该至少一个处理器通信连接的存储器；其中，

该存储器存储有可被该至少一个处理器执行的指令，该指令被该至少一个处理器执行，以使该至少一个处理器能够执行本公开中任一实施例的方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，该计算机指令用于使该计算机执行根据本公开中任一实施例的方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序在被处理器执行时实现根据本公开中任一实施例的方法。

本公开实施例中，在确定多个候选执行计划的执行成本之后，再结合数据节点的监控数据，对各执行成本进行更新，并将执行计划的最终成本作为目标查询请求的最终执行计划的参考依据。最终执行成本不仅考虑了执行计划的预估成本和数据库自身的状态，还考虑了执行计划数据节点自身的情况，有利于提高最终成本的准确性，从而有利于提高基于最终成本得到的目标查询请求的最终执行计划的准确性，有利于基于最终执行计划实现数据查询的优化。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开一实施例中分布式数据库的场景示意图；

图2是根据本公开另一实施例中数据查询优化方法的流程示意图；

图3是根据本公开另一实施例中更新执行成本的流程示意图；

图4是根据本公开另一实施例中汇总操作节点的子成本的示意图；

图5是根据本公开另一实施例中目标执行计划和候选执行计划的关系示意图；

图6是根据本公开另一实施例中数据查询优化装置的结构示意图；

图7是用来实现本公开实施例的数据查询优化方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者多个该特征。在本公开的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

相关技术中，针对SQL请求的不同执行计划，通常会采用查询优化器对各执行计划进行比较和筛选，以确定最优执行计划，该最优执行计划一般是执行成本最低的执行计划。而查询优化器中，可以采用CBO(Cost Based Optimizer，基于成本的优化)方式对各执行计划的cost(即执行成本)进行估算和比较。CBO一般采用数据库内部的三部分统计数据进行cost的估算，包括针对执行计划预估出的I/O(Input/Output，输入/输出)代价、预估出的CPU(Central Processing Unit，中央处理器)代价和预估出的网络代价。对于单节点的数据库，CBO方式一般能够实现cost的准确判断，但在分布式数据库场景下，如图1所示，为分布式数据库的场景示意图，其中可能会包含多个数据节点，如图1中的数据节点1、数据节点2......数据节点N(N为正整数)。各数据节点的性能状态可能会存在差异，多个数据节点之间的网络传输代价可能也有所不同，即，同样的SQL请求对于不同的数据节点，执行成本可能并不相同。

由于云分布式数据库产品为了满足用户需求，通常都具备对各个数据节点数据的监控功能，从而无需额外引入获取数据节点数据的监控工具。如果能将这些监控到的数据节点数据加入cost的计算中，就能帮助查询优化器准确掌控各数据节点的数据处理能力，使计算出的cost更加准确，从而使基于cost的查询优化也能更加准确。

有鉴于此，本公开实施例提供了一种数据查询优化方法。如图2所示，为本公开实施例中数据查询优化方法的流程示意图，包括：

S201，确定目标查询请求的多个候选执行计划。

其中，多个候选执行计划均能处理目标查询请求，得到查询结果。可基于多个候选执行计划中的任一候选执行计划实现对目标查询请求的响应。

S202，确定多个候选执行计划的执行成本。

例如，可以采用查询优化器实现执行成本的确定。其中，查询优化器用于从多个候选执行计划中筛选出最优的执行计划，为了实现该筛选过程，先通过查询优化器计算出各候选执行计划的执行成本，以将执行成本作为筛选依据。

S203，基于多个候选执行计划中涉及的数据节点的监控数据，更新多个候选执行计划的执行成本，得到多个候选执行计划的最终成本。

其中，候选执行计划中可能会涉及一个或多个数据节点。数据节点的监控数据指的是除数据库自身相关监控数据之外的，数据库所在数据节点的监控数据。例如，监控数据可以为数据节点当前已经使用的CPU资源和空闲可用的CPU资源。

S204，基于多个候选执行计划的最终成本，从多个候选执行计划中筛选出目标查询请求的最终执行计划。

本公开实施例中，在确定多个候选执行计划的执行成本之后，再结合数据节点的监控数据，对各执行成本进行更新，并将执行计划的最终成本作为目标查询请求的最终执行计划的参考依据。最终执行成本不仅考虑了执行计划的预估成本，不仅考虑了数据库自身的状态，还考虑了执行计划的数据节点自身的情况，有利于提高最终成本的准确性，从而有利于提高基于最终成本得到的目标查询请求的最终执行计划的准确性，有利于基于最终执行计划实现数据查询的优化。

在一些实施例中，监控数据包括以下中的至少一种：处理器使用率、网络状态、网络延迟参数、待执行任务规划等。

其中，处理器使用率主要包括CPU使用率，指的是计算机中央处理单元的工作负载与其可用处理能力之间的比例。是衡量CPU使用效率的一个重要指标，能够反映系统的性能和效能。需要说明的是，如果CPU使用率超过CPU的性能阈值，那么就意味着CPU正在承担较重的工作负载，可能会导致系统的响应速度变慢，甚至出现卡顿现象。因此，采用CPU使用率作为一项监控数据，有利于使得筛选出的执行计划能够在相应的数据节点上成功高效的执行。

网络状态指的是数据节点与网络的连接情况。例如在上网时，网络状态可以是良好、较差或断开。网络状态通常会受到一些因素的影响，例如网络信号强度、网速、带宽等。在网络状况良好的情况下，数据节点与网络的连接状态稳定，数据传输速度快，系统响应速度快。当网络状况较差时，可能会出现系统响应速度变慢、网络卡顿、甚至网络无法连接等情况。因此，采用网络状态作为一项监控数据，有利于使得筛选出的执行计划能够在相应的数据节点上成功高效地执行。

网络延迟参数用于表示网络延迟情况，在本公开实施例中用于表示数据节点的延时情况。比如，向一个数据节点发送请求，该数据节点一小时后才回复了该请求，则该数据节点在该方向上收发信息的延时即节点延时。如果数据节点出现了较为严重的延迟，则可能会影响执行计划的执行效率，因此，采用网络延迟参数作为一项监控数据，有利于使得筛选出的执行计划能够在相应的数据节点上成功高效地执行。

在数据节点中，除数据库的执行计划之外，通常还需要处理其他的待执行任务，待执行任务规划即对于其他的执行任务的规划。如果其他的待执行任务过多，则可能会影响数据节点对于数据库的执行计划的处理效率，因此，采用待执行任务规划作为一项监控数据，有利于使得筛选出的执行计划能够在相应的数据节点上成功高效地执行。

本公开实施例中，监控数据可能由多个监控项组成，监控项越多，得到的监控数据越全面，参考依据越丰富，有利于提高基于监控数据得到的候选执行计划的最终成本的准确性，从而有利于提高基于最终成本得到的目标查询请求的最终执行计划的准确性，有利于基于最终执行计划实现数据查询的优化。

下面分别对监控数据可能包含处理器使用率、网络状态、网络延迟参数、待执行任务规划中的至少一种监控项的情况进行说明。

在一些实施例中，基于最终成本与处理器使用率之间的正相关关系，可更新所有候选执行计划的执行成本，得到各候选执行计划的最终成本。

在另一些实施例中，在监控数据包括处理器使用率的情况下，更新多个候选执行计划的执行成本，可实施为：针对执行成本之间的差距小于第一差距阈值的多个第一目标执行计划，基于最终成本与处理器使用率之间的正相关关系，更新多个第一目标候选执行计划的执行成本。

由于多个候选执行计划中，各候选执行计划的执行成本可能不同，所以不同的候选执行计划之间的执行成本一般会存在差距。如果候选执行计划之间的执行成本的差距很大，则选取执行成本较低的候选执行计划作为最终执行计划。而如果候选执行计划之间的执行成本相近，则需要对候选执行计划的执行成本进行更新，以便于基于最终成本从多个候选执行计划中确定出最优的最终执行计划。基于此，通过设置第一差距阈值，能够便于确定候选执行计划的执行成本之间的差距关系，差距关系用于反映候选执行计划的执行成本是否相近。上述第一目标执行计划为多个候选执行计划中，执行成本之间的差距小于第一差距阈值的执行计划，该多个第一目标执行计划的执行成本相近。其中，第一差距阈值可以根据实际需求制定，本公开对此不作限定。例如，第一差距阈值可以为1，2，3。

由于随着处理器使用率的升高，会一定程度上造成第一目标执行计划的最终成本增加；随着处理器使用率的降低，会一定程度上使第一目标执行计划的最终成本减少。所以，需要根据处理器使用率对第一目标执行计划的执行成本进行更新，以得到更新后的执行计划的最终成本。

本公开实施例中，在监控数据包括处理器使用率的情况下，针对执行成本之间的差距小于第一差距阈值的多个第一目标执行计划，即执行成本相近的第一目标执行计划，结合处理器使用率对各第一目标执行计划的执行成本进行更新，以便于得到最终成本。基于最终成本实现查询优化，有利于使最终成本更能准确地表示候选执行计划的实际执行成本，从而有利于使查询优化结果更加准确。

在一些实施例中，在监控数据包括网络状态的情况下，更新多个候选执行计划的执行成本，可实施为：

步骤A1，基于网络状态确定网络拥堵程度。

其中，网络拥堵程度指的是网络中数据节点的端口流量达到一定程度时出现拥塞的程度。通常情况下，可以通过网络状态中的以下指标来进行网络拥堵程度的判断，包括：端口利用率、数据包丢失率等。具体地，端口利用率指的是端口已经使用的带宽与其剩余的可用带宽之间的比例。当端口利用率超过一定阈值时，表示该端口可能存在拥堵的情况。例如，当端口利用率达到80％～90％以上时，就可能会发生网络拥堵。当端口拥堵时，可能会导致传输的数据包丢失。数据包丢失率通常指的是在单位时间内，端口丢失的数据包占总发送数据包的比例。数据包丢失率越高，表示网络拥堵程度越严重。

步骤A2，针对执行成本之间的差距小于第二差距阈值的多个第二目标执行计划，基于最终成本与网络拥堵程度之间的正相关关系，更新多个第二目标候选执行计划的执行成本。

由于随着网络拥堵程度的增强，会一定程度上造成第二目标执行计划的最终成本增加；随着网络拥堵程度的减弱，会一定程度上使第二目标执行计划的最终成本减少。所以，对于执行成本相近的多个第二目标执行计划，则需要结合监控数据中的网络拥堵程度对第二目标执行计划的执行成本进行更新，以便于基于最终成本从多个第二目标执行计划中确定出最优的最终执行计划。

本公开实施例中，在监控数据包括网络拥堵程度的情况下，针对执行成本之间的差距小于第二差距阈值的多个第二目标执行计划，即执行成本相近的第二目标执行计划，结合网络拥堵程度对各第二目标执行计划的执行成本进行更新，以便于得到最终成本。基于最终成本实现查询优化，有利于使最终成本更能准确地表示候选执行计划的实际执行成本，从而有利于使查询优化结果更加准确。

在一些实施例中，在监控数据包括网络延迟参数的情况下，更新多个候选执行计划的执行成本，可实施为：针对执行成本之间的差距小于第三差距阈值的多个第三目标执行计划，基于最终成本与网络延迟参数之间的正相关关系，更新多个第三目标执行计划的执行成本。

其中，网络延迟参数表示网络延迟情况，指的是由于网络中数据节点的端口拥堵，导致数据包在传输过程中所需的时间增加。由于数据包的正常传输过程本来就存在一定程度上的延迟，所以数据包的传输时间增加，即延迟增加。延迟是指数据包从发送端传输到接收端所需的时间，延迟增加会降低网络性能和用户体验。网络延迟参数可包括例如报文响应时间，其中，报文响应时间是指从发送请求到接收到对该请求的响应的时间间隔，网络中的某个端口拥堵时，会导致报文响应时间延长，当拥堵严重时，报文响应时间会显著增加。

由于随着网络延迟参数表示的网络延迟情况越来越严重，会一定程度上造成执行计划的最终成本增加；随着网络延迟参数表示的网络延迟情况的缓解，会一定程度上使执行计划的最终成本减少。所以，在第三目标执行计划之间的执行成本相近的情况下，则需要结合监控数据中的网络延迟参数对第三目标执行计划的执行成本进行更新，以便于基于最终成本从多个第三目标执行计划中确定出最优的最终执行计划。

本公开实施例中，在监控数据包括网络延迟参数的情况下，针对执行成本之间的差距小于第三差距阈值的多个第三目标执行计划，即执行成本相近的第三目标执行计划，结合网络延迟参数对各第三目标执行计划的执行成本进行更新，以便于得到最终成本。基于最终成本实现查询优化，有利于使最终成本更能准确地表示候选执行计划的实际执行成本，从而有利于使查询优化结果更加准确。

在一些实施例中，在监控数据包括待执行任务规划的情况下，更新多个候选执行计划的执行成本，可实施为：

步骤B1，预估在未来指定时长内的待执行任务规划所耗费的节点资源量。

其中，未来指定时长的时间范围可以根据实际需求确定，本公开对此不做限制。待执行任务规划所需的节点资源并不一定为同一量级。例如，待执行任务规划可能需要一定的空闲网络带宽和CPU可用余量，而网络带宽和CPU资源不属于同一量级。在待执行任务规划所耗费的节点资源的量级不同的情况下，可以对这些节点资源进行归一化去量纲，并将处理为同一量级的节点资源相加，作为待执行任务规划所耗费的节点资源量。

步骤B2，针对执行成本之间的差距小于第四差距阈值的多个第四目标执行计划，基于最终成本与节点资源量之间的正相关关系，更新多个第四目标候选执行计划的执行成本。

由于随着待执行任务规划的升高，会一定程度上造成执行计划的最终成本增加；随着待执行任务规划的降低，会一定程度上使执行计划的最终成本减少。对于执行成本相近的第四目标执行计划，则需要结合监控数据中的待执行任务规划对候选执行计划的执行成本进行更新，以便于基于最终成本从多个候选执行计划中确定出最优的最终执行计划。

本公开实施例中，在监控数据包括待执行任务规划的情况下，针对执行成本之间的差距小于第四差距阈值的多个第四目标执行计划，即执行成本相近的第四目标执行计划，结合待执行任务规划对各第四目标执行计划的执行成本进行更新，以便于得到最终成本。基于最终成本实现查询优化，有利于使最终成本更能准确地表示候选执行计划的实际执行成本，从而有利于使查询优化结果更加准确。

在一些实施例中，如图3所示，为本公开实施例中更新执行成本的流程示意图，其中，基于多个候选执行计划中涉及的数据节点的监控数据，更新多个候选执行计划的执行成本，包括：

S301，针对多个候选执行计划中的待处理候选执行计划，确定待处理候选执行计划的操作节点。

其中，待处理候选执行计划可以为多个候选执行计划中的任一执行计划。待处理候选执行计划中可能包含一个或多个操作节点。例如，待处理候选执行计划可能需要经过多个操作节点才能完成。

S302，基于操作节点涉及的数据节点的监控数据，更新操作节点在对应执行成本中的子成本。

其中，操作节点可能涉及不同的数据节点，待处理候选执行计划对于不同的数据节点所需的节点资源量也可能不同，对于每个数据节点，都能基于监控数据对完成待处理候选执行计划所需的子成本进行更新。

S303，汇总待处理候选执行计划包含的操作节点更新后的子成本，得到待处理候选执行计划的最终成本。

如图4所示，为本公开实施例中汇总操作节点的子成本的示意图。图4中，待处理候选执行计划中包含了两个操作节点，分别是操作节点N和操作节点M，其中，操作节点N涉及了三个数据节点，分别是数据节点N1、N2、N3，操作节点M涉及了一个数据节点M1，每个操作节点都具有相应的子成本，子成本的总和构成待处理候选执行计划的最终成本。

本公开实施例中，通过对待处理候选执行计划包含的操作节点的子成本进行汇总，将汇总的子成本作为待处理候选执行计划的执行成本，在待处理候选执行计划包含多个子成本的情况下，有利于避免执行成本的遗漏，从而有利于提高执行成本的准确性，有利于基于执行成本实现查询优化的准确性。

需要说明的是，根据实际需求，上述用于进行执行成本之间的差距评估的第一差距阈值、第二差距阈值、第三差距阈值和第四差距阈值可以相同也可以不同。

在一些实施例中，根据实际需求，针对执行成本相近且重点考虑处理器使用率的优化的执行计划，例如计算需求很大的执行计划，可以优先将处理器使用率作为监控项纳入监控数据；针对执行成本相近且重点考虑网络状态的优化的执行计划，例如待处理候选执行计划中包含多个操作节点，则涉及多个操作节点之间的数据传输，则该待处理执行计划所需的网络宽带资源相对于只包含一个操作节点的待处理执行计划的可能会更多，所以可以优先将网络状态作为监控项纳入监控数据。对于监控数据中可能包含其他监控项的优化方案也可以依此类推，以便于根据实际需求使监控数据的采集更加合理，例如在重点考虑优化处理器使用率的情况下，可以减少或不进行网络状态相关的监控数据的采集，从而能一定程度上提高查询优化器对于监控数据的处理效率。在此基础上，例如针对执行成本相近且需要同时考虑处理器使用率的优化和网络状态的优化的执行计划，可以结合对优化处理器使用率和优化网络状态的侧重情况，对处理器使用率和网络状态进行加权求和得到一个参考值，再结合该参考值对执行成本进行更新。

还需要说明的是，如图5所示，为目标执行计划和候选执行计划的关系示意图，其中，上述的多个目标执行计划(包括第一目标执行计划、第二目标执行计划、第三目标执行计划、第四目标执行计划)为多个候选执行计划的子集，可以在对多个候选执行计划进行筛选得到多个目标执行计划的情况下，针对目标执行计划的执行成本结合数据节点的监控数据进行更新；也可以不对多个候选执行计划进行筛选，即对所有的候选执行计划的执行成本均结合数据节点的监控数据进行更新，本公开对此不作限定。且监控数据中包含的监控项可以是一种或多种，本公开对此不作限定。

本公开实施例是在获取到数据节点的监控数据的前提下实现的，下面对监控数据的获取情况进行说明。

在一些实施例中，获取监控数据，可实施为：定期获取预先汇总的监控数据。

其中，对于获取预先汇总的监控数据的间隔时间，即定期时间点，可以根据实际需求进行制定，本公开对此不作限定。

本公开实施例中，定期获取预先汇总的监控数据，相较于实时对预先汇总的监控数据进行获取，有利于在一定程度上节约系统资源。

除此之外，在一些特殊情况下，还可以在未到达定期时间点的情况下，执行对预先汇总的监控数据的相关操作。

在一些实施例中，获取监控数据，还可实施为：响应于预设事件，在未到达定期时间点的情况下，获取预先汇总的监控数据。

其中，预设事件可以根据实际需求进行设置，本公开对此不作限定。举例来说，在发生预设事件的情况下，比如目标查询请求需要数据节点中的大量节点资源执行候选执行计划时，可以在定期时间点前主动获取预先汇总的监控数据，以判断监控数据所对应的数据节点是否具备相应的处理能力，以及在数据节点具备相应处理能力的情况下所需的执行成本。在数据节点不具备相应的处理能力的情况下，舍弃包含该数据节点的候选执行计划。并在候选执行计划所涉及的数据节点都具备相应处理能力的情况下，采用总执行成本最低的候选执行计划作为目标查询请求的最终执行计划，以便于提高查询优化的准确性。

在一些实施例中，获取监控数据，还可实施为：接收监控数据，监控数据是在发生关键事件的情况下发送的。

其中，关键事件可以根据实际需求进行设置，本公开对此不作限定。举例来说，在发生关键事件的情况下，比如在得知某个或某些数据节点发生了较大变动的情况下，例如数据节点突然被大量其他待处理任务占用，导致数据节点的整体性能超过了监控阈值，此时数据节点在定期时间点前主动提供预先汇总的监控数据，以便于基于监控数据实现查询优化过程中的筛选操作。其中，该监控阈值用于判断数据节点性能的浮动情况是否超出预期。

除了处理器使用率、网络状态、网络延迟参数、待执行任务规划这些原始的监控数据之外，还可以基于这些原始的监控数据进行统计与分析得到高阶数据，例如时序预测数据可以作为一种待执行任务规划影响执行成本。周期性的任务也可以作为一种待执行任务规划影响执行成本。

总之，待执行任务规划可以是已知的任务安排，也可以是基于历史监控数据得到的处理器使用率或网络状态等的周期性特点，例如每天早上八点处理器使用率达到峰值，还可以是基于待执行任务规划得到的时序预测数据。

具体地，例如，假设有两个候选执行计划，分别是在A数据节点上和在B数据节点上完成T1表和T2表的hash join(哈希连接)操作，这两个候选执行计划的I/O代价，CPU代价与网络代价相近，如果A数据节点的CPU使用率(并非本哈希连接操作的CPU代价)为95％而B数据节点的CPU使用率为20％，显然在B数据节点执行该哈希连接操作更优，因为B数据节点上还有更充裕的计算资源，也更有利于计算资源的合理分配。

继续上面的举例，如果A数据节点的CPU使用率和B数据节点的CPU使用率均为20％，在采用prophet(时序预测)方式进行预测的情况下，得知10秒后A数据节点会迎来大批查询请求占用CPU，则在数据节点B上执行该哈希连接操作更优。

再例如，目前有两个数据节点C和D，分别运行着T3表的replica(Ct3，Dt3)，其中Ct3和Dt3分别为T3表的两个副本；还有两个数据节点E和F，分别运行着T4表的replica(Et4，Ft4)，其中Et4和Ft4分别为T4表的两个副本。现在需要对T3表和T4表进行inner join(内连接)操作，则需要计算inner join的成本。假设T3表很大而T4表很小，那么显然将T4表复制到T3表最优，则将产生4种方案，分别是：Et2->Ct1、Et2->Dt1、Ft2->Ct1、Ft2->Dt1。经过对这两个数据节点的网络状态的分析与预测，发现1秒后数据节点E->C，E->D的网络带宽基本会被占满，无法进行有效迁移；同时数据节点C上会有较复杂的运算，CPU占用率较高。因此综合上述情况，应该选择Ft2->Dt1这个方案。cost可以采用如下方式计算得出，例如，针对T3表和T4表，基于查询优化器计算得到的inner join操作的成本表示为：cost(localT3 inner join T4)＝cost(DiskIO)+cost(CPU)+size(t3)*size(t4)，其中，cost(DiskIO)表示预估的I/O代价，cost(CPU)表示预估的CPU代价，size(t3)表示T3表的大小，size(t4)表示T4表的大小。

则考虑到网络状态和CPU使用率之后，在分布式数据库下在数据节点D中执行T3表和T4表的inner join操作的cost表示为：cost(distributed T3inner join T4)＝cost(#Network)+cost(Network_usage)+cost(local T3 inner join T4)+cost(#CPU)。cost(#Network)表示网络状态，可包括当前实际的网络状态，和未来一段时间对网络的占用情况；cost(Network_usage)表示执行该inner join操作预计所需的网络资源；cost(local T3inner join T4)表示执行该T3 inner join T4操作预计所需的本地资源；cost(#CPU)表示涉及的数据节点当前的网络状态，和未来一段时间预测的需额外增加的CPU使用率。

基于相同的技术构思，本公开实施例提供了一种数据查询优化装置600，如图6所示，该装置包括：

第一确定模块601，用于确定目标查询请求的多个候选执行计划；

第二确定模块602，用于确定多个候选执行计划的执行成本；

更新模块603，用于基于多个候选执行计划中涉及的数据节点的监控数据，更新多个候选执行计划的执行成本，得到多个候选执行计划的最终成本；

筛选模块604，用于基于多个候选执行计划的最终成本，从多个候选执行计划中筛选出目标查询请求的最终执行计划。

在一些实施例中，监控数据包括以下中的至少一种：

处理器使用率、网络状态、网络延迟参数、待执行任务规划。

在一些实施例中，在监控数据包括处理器使用率的情况下，更新模块，包括：

第一更新单元，用于针对执行成本之间的差距小于第一差距阈值的多个第一目标执行计划，基于最终成本与处理器使用率之间的正相关关系，更新多个第一目标候选执行计划的执行成本。

在一些实施例中，在监控数据包括网络状态的情况下，更新模块，包括：

第一确定单元，用于基于网络状态确定网络拥堵程度；

第二更新单元，用于针对执行成本之间的差距小于第二差距阈值的多个第二目标执行计划，基于最终成本与网络拥堵程度之间的正相关关系，更新多个第二目标候选执行计划的执行成本。

在一些实施例中，在监控数据包括网络延迟参数的情况下，更新模块，包括：

第三更新单元，用于针对执行成本之间的差距小于第三差距阈值的多个第三目标执行计划，基于最终成本与网络延迟参数之间的正相关关系，更新多个第三目标候选执行计划的执行成本。

在一些实施例中，在监控数据包括待执行任务规划的情况下，更新模块，包括：

预估单元，用于预估在未来指定时长内的待执行任务规划所耗费的节点资源量；

第四更新单元，用于针对执行成本之间的差距小于第四差距阈值的多个第四目标执行计划，基于最终成本与节点资源量之间的正相关关系，更新多个目标候选执行计划的执行成本。

在一些实施例中，更新模块，还包括：

第二确定单元，用于针对多个候选执行计划中的待处理候选执行计划，确定待处理候选执行计划的操作节点；

第五更新单元，用于基于操作节点涉及的数据节点的监控数据，更新操作节点在执行成本中的子成本；

汇总单元，用于汇总待处理候选执行计划包含的操作节点更新后的子成本，得到待处理候选执行计划的最终成本。

在一些实施例中，在更新模块中获取监控数据，包括：

获取单元，用于定期获取预先汇总的监控数据。

本公开实施例的装置的各模块、子模块的具体功能和示例的描述，可以参见上述方法实施例中对应步骤的相关描述，在此不再赘述。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图7示出了可以用来实施本公开的实施例的示例电子设备700的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字助理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图7所示，设备700包括计算单元701，其可以根据存储在只读存储器(ROM)702中的计算机程序或者从存储单元708加载到随机访问存储器(RAM)703中的计算机程序，来执行各种适当的动作和处理。在RAM 703中，还可存储设备700操作所需的各种程序和数据。计算单元701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

设备700中的多个部件连接至I/O接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理，例如数据查询优化方法。例如，在一些实施例中，数据查询优化方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序加载到RAM 703并由计算单元701执行时，可以执行上文描述的数据查询优化方法的一个或多个步骤。备选地，在其他实施例中，计算单元701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行数据查询优化方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、复杂可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入、或者触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

根据本公开的实施例，电子设备可以与通信部件、显示屏以及信息采集设备一体集成，也可以与通信部件、显示屏以及信息采集设备分体设置。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (19)

1.一种数据查询优化方法，包括：

确定目标查询请求的多个候选执行计划；

确定所述多个候选执行计划的执行成本；

基于所述多个候选执行计划中涉及的数据节点的监控数据，更新所述多个候选执行计划的执行成本，得到所述多个候选执行计划的最终成本；

基于所述多个候选执行计划的最终成本，从所述多个候选执行计划中筛选出所述目标查询请求的最终执行计划。

2.根据权利要求1所述的方法，其中，所述监控数据包括以下中的至少一种：

处理器使用率、网络状态、网络延迟参数、待执行任务规划。

3.根据权利要求2所述的方法，其中，在所述监控数据包括所述处理器使用率的情况下，所述更新所述多个候选执行计划的执行成本，包括：

针对执行成本之间的差距小于第一差距阈值的多个第一目标执行计划，基于所述最终成本与所述处理器使用率之间的正相关关系，更新所述多个第一目标候选执行计划的执行成本。

4.根据权利要求2所述的方法，其中，在所述监控数据包括所述网络状态的情况下，所述更新所述多个候选执行计划的执行成本，包括：

基于所述网络状态确定网络拥堵程度；

针对执行成本之间的差距小于第二差距阈值的多个第二目标执行计划，基于所述最终成本与所述网络拥堵程度之间的正相关关系，更新所述多个第二目标候选执行计划的执行成本。

5.根据权利要求2所述的方法，其中，在所述监控数据包括所述网络延迟参数的情况下，所述更新所述多个候选执行计划的执行成本，包括：

针对执行成本之间的差距小于第三差距阈值的多个第三目标执行计划，基于所述最终成本与所述网络延迟参数之间的正相关关系，更新所述多个第三目标候选执行计划的执行成本。

6.根据权利要求2所述的方法，其中，在所述监控数据包括所述待执行任务规划的情况下，所述更新所述多个候选执行计划的执行成本，包括：

预估在未来指定时长内的待执行任务规划所耗费的节点资源量；

针对执行成本之间的差距小于第四差距阈值的多个第四目标执行计划，基于所述最终成本与所述节点资源量之间的正相关关系，更新所述多个目标候选执行计划的执行成本。

7.根据权利要求1-6中任一项所述的方法，其中，所述基于所述多个候选执行计划中涉及的数据节点的监控数据，更新所述多个候选执行计划的执行成本，包括：

针对所述多个候选执行计划中的待处理候选执行计划，确定所述待处理候选执行计划的操作节点；

基于所述操作节点涉及的数据节点的监控数据，更新所述操作节点在所述执行成本中的子成本；

汇总所述待处理候选执行计划包含的操作节点更新后的子成本，得到所述待处理候选执行计划的所述最终成本。

8.根据权利要求1-7中任一项所述的方法，其中，获取所述监控数据，包括：

定期获取预先汇总的所述监控数据。

9.一种数据查询优化装置，包括：

第一确定模块，用于确定目标查询请求的多个候选执行计划；

第二确定模块，用于确定所述多个候选执行计划的执行成本；

更新模块，用于基于所述多个候选执行计划中涉及的数据节点的监控数据，更新所述多个候选执行计划的执行成本，得到所述多个候选执行计划的最终成本；

筛选模块，用于基于所述多个候选执行计划的最终成本，从所述多个候选执行计划中筛选出所述目标查询请求的最终执行计划。

10.根据权利要求9所述的装置，其中，所述监控数据包括以下中的至少一种：

处理器使用率、网络状态、网络延迟参数、待执行任务规划。

11.根据权利要求10所述的装置，其中，在所述监控数据包括所述处理器使用率的情况下，所述更新模块，包括：

第一更新单元，用于针对执行成本之间的差距小于第一差距阈值的多个第一目标执行计划，基于所述最终成本与所述处理器使用率之间的正相关关系，更新所述多个第一目标候选执行计划的执行成本。

12.根据权利要求10所述的装置，其中，在所述监控数据包括所述网络状态的情况下，所述更新模块，包括：

第一确定单元，用于基于所述网络状态确定网络拥堵程度；

第二更新单元，用于针对执行成本之间的差距小于第二差距阈值的多个第二目标执行计划，基于所述最终成本与所述网络拥堵程度之间的正相关关系，更新所述多个第二目标候选执行计划的执行成本。

13.根据权利要求10所述的装置，其中，在所述监控数据包括所述网络延迟参数的情况下，所述更新模块，包括：

第三更新单元，用于针对执行成本之间的差距小于第三差距阈值的多个第三目标执行计划，基于所述最终成本与所述网络延迟参数之间的正相关关系，更新所述多个第三目标候选执行计划的执行成本。

14.根据权利要求10所述的装置，其中，在所述监控数据包括所述待执行任务规划的情况下，所述更新模块，包括：

预估单元，用于预估在未来指定时长内的待执行任务规划所耗费的节点资源量；

第四更新单元，用于针对执行成本之间的差距小于第四差距阈值的多个第四目标执行计划，基于所述最终成本与所述节点资源量之间的正相关关系，更新所述多个目标候选执行计划的执行成本。

15.根据权利要求9-14中任一项所述的装置，其中，所述更新模块，还包括：

第二确定单元，用于针对所述多个候选执行计划中的待处理候选执行计划，确定所述待处理候选执行计划的操作节点；

第五更新单元，用于基于所述操作节点涉及的数据节点的监控数据，更新所述操作节点在所述执行成本中的子成本；

汇总单元，用于汇总所述待处理候选执行计划包含的操作节点更新后的子成本，得到所述待处理候选执行计划的所述最终成本。

16.根据权利要求9-15中任一项所述的装置，其中，在所述更新模块中获取所述监控数据，包括：

获取单元，用于定期获取预先汇总的所述监控数据。

17.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-8中任一项所述的方法。

18.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-8中任一项所述的方法。

19.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-8中任一项所述的方法。