CN112416969A - 分布式数据库中的并行任务调度系统 - Google Patents

Abstract

本申请公开了一种分布式数据库中的并行任务调度系统，包括：主节点以及与主节点通信的至少一个从节点，并且从节点设置有用于执行调度任务的代理调度器，其中主节点配置用于执行以下操作：接收查询语句，并根据查询语句生成查询任务；将查询任务发送至至少一个从节点；以及从节点配置用于执行以下操作：接收查询任务；通过代理调度器将查询任务分配至由从节点管理的至少一个查询执行器进行处理。

Description

分布式数据库中的并行任务调度系统

技术领域

本申请涉及分布式数据库技术领域，特别是涉及一种分布式数据库中的并行任务调度系统。

背景技术

并行任务调度器是分布式数据库中最核心的与分布式紧密相关的模块之一，负责将分片的查询计划调度到各个从节点上，并且负责协调查询计划执行的全过程，是整个并行系统的粘合剂。如果执行成功，调度器将负责汇总调度信息。如果执行失败，调度器将负责取消其他正在运行的任务，以及把第一个出错的任务相关的报错信息返回终端用户。现有技术中，如开源的GPDB和Apache顶级项目HAWQ都是采用master节点上的QD(querydispatcher查询调度器)和segment节点上的每一个QE(queryexecutor查询执行器)直接建立libpq连接，发送接收消息。

然而，现有技术会在大规模集群下，造成master和segment节点之间存在大量libpq连接，比如1000个节点集群，每个节点启动了100个QE，这样就是100*1000＝100000个libpq连接。同时任务分发的时候会给每个QE分发大量的重复的信息，包括序列化的查询计划，元信息等。这些都会导致随着集群规模的扩大，任务派遣的性能会越来越慢，甚至造成master节点最早成为整个集群的瓶颈。

针对上述的现有技术中存在的分布式集群中的主节点的查询调度器需要和和每个从节点的每个查询执行器建立连接关系，因此随着集群规模的扩大会影响任务派遣速度，甚至造成集群到达瓶颈的技术问题，目前尚未提出有效的解决方案。

发明内容

本公开的实施例提供了一种分布式数据库中的并行任务调度系统，以至少解决现有技术中存在的分布式集群中的主节点的查询调度器需要和和每个从节点的每个查询执行器建立连接关系，因此随着集群规模的扩大会影响任务派遣速度，甚至造成集群到达瓶颈的技术问题。

根据本公开实施例的一个方面，提供了一种分布式数据库中的并行任务调度系统，包括：主节点以及与主节点通信的至少一个从节点，并且从节点设置有用于执行调度任务的代理调度器，其中主节点配置用于执行以下操作：接收查询语句，并根据查询语句生成查询任务；将查询任务发送至至少一个从节点；以及从节点配置用于执行以下操作：接收查询任务；通过代理调度器将查询任务分配至由从节点管理的至少一个查询执行器进行处理。

在本公开实施例中，在分布式数据库中的每个从节点设置代理调度器，因此主节点的调度器在每次发送任务的时候只需要向从节点发送任务，然后从节点通过代理调度器将任务下发至查询执行器，因此主节点不需要向每个查询执行器发送。从而与现有技术相比，本方案可以显著减少主节点与查询执行器之间的连接数量。达到了节省计算资源的技术效果。此外，通过向从节点发送查询任务的过程中，对于共用的数据部分只发送一份，因此还可以进一步地节省了计算资源，提高数据的发送效率。进而解决了现有技术中存在的分布式集群中的主节点的查询调度器需要和和每个从节点的每个查询执行器建立连接关系，因此随着集群规模的扩大会影响任务派遣速度，甚至造成集群到达瓶颈的技术问题。

附图说明

此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：

图1是用于实现根据本公开实施例1所述的方法的计算设备的硬件结构框图；

图2是根据本公开实施例1所述的分布式数据库中的并行任务调度系统的示意图；

图3是根据本公开实施例1所述的主节点执行操作的流程示意图；以及

图4是根据本公开实施例1所述的从节点执行操作的流程示意图。

具体实施方式

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

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本实施例，提供了一种分布式数据库中的并行任务调度系统的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本实施例所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的计算设备中执行。图1示出了一种用于实现主节点和从节点的执行步骤的计算设备的硬件结构框图。如图1所示，计算设备可以包括一个或多个处理器(处理器可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器、以及用于通信功能的传输装置。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算设备还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

应当注意到的是上述一个或多个处理器和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算设备中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器可用于存储应用软件的软件程序以及模块，如本公开实施例中的主节点和从节点的执行步骤对应的程序指令/数据存储装置，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的主节点和从节点的执行步骤。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算设备的通信供应商提供的无线网络。在一个实例中，传输装置包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与计算设备的用户界面进行交互。

此处需要说明的是，在一些可选实施例中，上述图1所示的计算设备可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和软件元件两者的结合。应当指出的是，图1仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算设备中的部件的类型。

图2是根据本实施例所述的分布式数据库中的并行任务调度系统的示意图。参照图2所示，该系统包括：主节点100以及与主节点通信的至少一个从节点(也可以称为数据节点)，例如从节点201和从节点202等，每个从节点例如可以对应不同的主机，从节点201对应于Host1，从节点202对应于Host2。其中，主节点100上部署一个master实例，每个从节点都会部署一个segment实例。master实例会为每个session会话(例如每个查询任务)克隆出一个查询调度器(querydispatcher，简称QD)，其中主节点的主调度器(MainDispatcher)的逻辑存在于查询调度器QD上，即通过查询调度器执行对应的查询任务。segment实例会fork出多个查询执行器(queryexecutor，简称QE)，即每个从节点中会设置有多个查询执行器QE。此外，参考图2所示，每个从节点(从节点201和从节点202等)还为每个session会话(即，每个查询任务)设置用于执行调度任务的代理调度器(ProxyDispatcher)，即从节点上例如可以设置多个代理调度器，每个代理调度器负责对应的查询任务。需要说明的是，系统中的主节点100、从节点201、从节点202等均可适用上面所述的硬件结构。

在上述运行环境下，图3示出了主节点100执行操作的流程图，参考图3所示，主节点100执行操作包括：

S302：接收查询语句，并根据查询语句生成查询任务；以及

S304：将查询任务发送至至少一个从节点。

图4示出了每个从节点(例如从节点201)执行操作的流程图，参考图4所示，从节点201执行操作包括：

S402：接收查询任务；以及

S404：通过代理调度器将查询任务分配至由从节点管理的至少一个查询执行器进行处理。

正如背景技术中所述的，现有技术会在大规模集群下，造成master和segment节点之间存在大量libpq连接，比如1000个节点集群，每个节点启动了100个QE，这样就是100*1000＝100000个libpq连接。同时任务分发的时候会给每个QE分发大量的重复的信息，包括序列化的查询计划，元信息等。这些都会导致随着集群规模的扩大，任务派遣的性能会越来越慢，甚至造成master节点最早成为整个集群的瓶颈。

针对背景技术中存在的技术问题，本实例技术方案提供的主节点100在步骤S302中，首先接收查询语句，并根据查询语句生成查询任务。在一个具体实例中，在用户需要在该分布式数据库中查询数据的情况下，用户例如可以在该系统设置的客户端输入查询语句(例如SQL语句)，然后主节点100可以接收该查询语句。然后。主节点100进一步地根据查询语句生成或创建查询任务，具体可以由QD(查询调度器)对SQL语句经过查询优化生成并行的查询任务，然后进入主调度器(MainDispatcher)运行逻辑。

进一步地，在步骤304中，主节点100和从节点可以建立libpq连接，主节点100将查询任务发送至至少一个从节点，例如将并行的查询任务发送至从节点201和从节点202，或者直接将查询任务发送至从节点的代理调度器。在发送查询任务的过程中还可以发送用于查询的元数据。从而，分布式数据库中的主节点在发送查询任务时，只需要向设置有代理调度器的从节点发送任务，不需要向该从节点管理下的每个查询执行器分别发送。

在主节点100将查询任务发送至至少一个从节点的情况下，每个从节点(例如从节点201)在步骤402中可以接收查询任务。然后在步骤S404中，从节点201通过代理调度器(ProxyDispatcher)将查询任务分配至由从节点管理的至少一个查询执行器(QE)进行处理。即：每个从节点接收各自的查询任务，然后通过代理调度器将查询任务发送至每个从节点部署的至少一个查询执行器，通过多个查询执行器进行查询操作。

从而通过这种方式，在分布式数据库中的每个从节点设置代理调度器，因此主节点在每次发送任务的时候只需要向从节点发送任务，然后从节点通过代理调度器将任务下发至查询执行器，因此主节点不需要向每个查询执行器发送。从而与现有技术相比，本方案可以显著减少主节点与查询执行器之间的连接数量。达到了节省计算资源的技术效果。此外，通过向从节点发送查询任务的过程中，对于共用的数据部分只发送一份，因此还可以进一步地节省了计算资源，提高数据的发送效率。进而解决了现有技术中存在的分布式集群中的主节点的查询调度器需要和和每个从节点的每个查询执行器建立连接关系，因此随着集群规模的扩大会影响任务派遣速度，甚至造成集群到达瓶颈的技术问题。

可选地，将查询任务发送至至少一个从节点，包括：从至少一个从节点中确定用于执行查询任务的目标从节点，并启动目标从节点的代理调度器；以及将查询任务发送至目标从节点。

在实际操作中面临的查询任务的数量可能不确定，例如：查询任务的数据量比较大或者比较小，因此需要合理的分配计算资源。具体地，本实施例在将查询任务发送至至少一个从节点的操作中，首先从至少一个从节点中确定用于执行查询任务的目标从节点，例如：根据查询任务的大小从至少一个从节点中确定开启的目标从节点(例如：目标从节点为从节点201和从节点202)。在确定目标从节点之后，有主节点100启动目标从节点的代理调度器。在实际操作中，主节点100的查询调度器(QD)对查询语句经过查询优化生成并行的查询任务，进入主调度器(MainDispatcher)运行逻辑，然后去每个目标从节点启动一个专有的代理调度器(ProxyDispatcher)。然后，将查询任务发送至目标从节点。从而通过这种方式，可以根据任务大小选择性的开启从节点进行查询，因此可以合理的分配计算资源。

此外，主节点100还可以根据任务大小选择开启每个从节点的查询执行器(QE)的数量，在去每个目标从节点启动一个专有的代理调度器之后，每个从节点的代理调度器会同时去各自的节点上启动QE。从而还可以合理的分配查询执行器的数量，节省资源的占用。

可选地，接收查询任务之前，还包括：从节点通过代理调度器接收至少一个查询执行器的基本信息并汇总；以及从节点通过代理调度器将汇总后的至少一个查询执行器的基本信息发送至主节点。

具体地，在从节点接收查询任务之前或者查询执行器QE启动以后，每个查询执行器QE可以把各自的基本信息(例如：进程号，监听端口等)发送至对应的从节点的代理调度器(ProxyDispatcher)，通过代理调度器将每个QE的信息进行汇总。然后从节点通过代理调度器将汇总后的至少一个查询执行器的基本信息发送至主节点。最终，主节点的调度器会把QE传回来的基本信息填充到查询计划里，连同元数据等分发下去。从而，主节点可以根据查询执行器的信息分配任务。此外，查询执行器的基本信息是由代理调度器汇总发送的，因此不需要每个查询执行器分别向主节点发送，因此可以节省资源。

可选地，通过代理调度器将查询任务分配至由从节点管理的至少一个查询执行器进行处理之后，还包括：从节点通过代理调度器接收至少一个查询执行器发送的第一消息并汇总，其中第一消息用于描述查询任务的处理情况；以及从节点通过代理调度器将汇总后的第一消息发送至主节点。

具体地，通过代理调度器将查询任务分配至由从节点管理的至少一个查询执行器进行处理之后，每个查询执行器的查询结果以及运行状态的信息都可以向对应的代理调度器发送，从而从节点通过代理调度器接收至少一个查询执行器发送的第一消息(对应于上述的查询结果或者运行状态的信息)并汇总，然后从节点通过代理调度器将汇总后的第一消息发送至主节点100。从而通过这种方式，在整个任务执行过程中，主节点100主要监控从节点的代理调度器的状态，每个代理调度器主要监控各自管理的查询执行器的状态。因此可以提升监控的效率。

可选地，主节点执行的操作还包括：在根据汇总后的第一消息确定代理调度器或者查询执行器出现故障的情况下，主节点关闭正在执行查询任务的从节点的代理调度器。

具体地，第一消息中的查询结果可以包括查询成功或者查询失败，运行状态信息可以包括运行正常和运行出现故障等。主节点100在根据汇总后的第一消息确定代理调度器或者查询执行器出现故障的情况下，关闭或取消正在执行查询任务的从节点的代理调度器。在一个具体实例中，所有QE执行成功消息会通过代理调度器汇总回传给主节点的调度器MainDispatcher，如果其中任何一个进程(包括QE或者代理调度器)出现故障，错误信息(第一信息)都会最终回传给调度器MainDispatcher，调度器MainDispatcher收到出错信息以后，会负责去取消其他正在执行的代理调度器ProxyDispatcher，ProxyDispatcher会负责去取消各自管理的QE。从而，在计算该过程中发生故障的情况下，可以快速的停止任务，避免不必要的资源浪费。

可选地，主节点执行的操作还包括：主节点将错误信息发送至与查询语句对应的终端设备。从而用户可以了解查询任务的进展情况。

可选地，从节点还设置有用于缓存开启状态的查询执行器的第一线程池，并且通过代理调度器管理第一线程池。

具体地，参考图2所示，每个从节点还设置有第一线程池(对应于图2中的QEPool)，通过第一线程池可以缓存开启状态的查询执行器。在一个具体实例中：从节点201的查询执行器在第一次查询任务时开启，在第一次查询任务完成之后可以将开启的查询执行器缓存到第一线程池(QEPool)中。在进行第二次查询任务时可以直接从线程池中调用缓存的已经开启的查询执行器，从而可以实现查询执行器的复用，因此避免每次新启动进程带来的开销。此外，该第一线程池可以由从节点的代理调度器管理。

可选地，参考图2所示，主节点100还设置有用于缓存开启状态的查询执行器的第二线程池(对应于图2中的ProxyQEPool)。主节点在分配查询任务时，首先从第二线程池中调用开启的查询执行器。因为主节点中缓存有查询执行器的信息，因此查询执行器不需要向代理调度器上报信息，可以节省计算资源，并且可以实现查询执行器的复用，避免每次新启动进程带来的开销。此外，主节点中还可以缓存开启状态的代理调度器。

可选地，从节点还设置有用于缓存调度到主节点执行的查询执行器的第三线程池。

具体地，数据库里有些任务是必须要调度到主节点的，因为需要直接访问主节点的元数据部分。例如，数据库里有一种函数叫generate_series，这个是用来生成自增序列的，这部分信息是没有办法分发下去的。如果查询执行器QE需要执行这个函数，那这种QE必须要调度到主节点上，直接访问sequence服务器。对于这种必须要调度到主节点的查询执行器，被称为EntryDB。对于这部分查询执行器QE复用放在一个单独的第三线程池里(对应于图2中从节点的EntryDBPool)。此外，主节点也可以设置缓存该部分查询执行器的线程池(对应于图2中的ProxyEntryDBPool)。从而可以实现查询执行器的复用。

可选地，从节点从对应的主进程克隆代理调度器。即，代理调度器从从节点segment的postmaster主进程fork(克隆)出来。从而，可以更快的部署代理调度器。

以下以一个具体实例描述本方案的主要流程：

并行任务调度器采用代理模式，在每个segment节点上为每个session新增一个proxydispatcher，proxydispatcher同样从segment的postmaster进程fork出来。具体工作流程如下：QD对SQL语句经过查询优化生成并行的查询计划，进入maindispatcher运行逻辑，然后去每个segment节点启动一个专有的proxy dispatcher，每个节点的proxydispatcher会同时去各自的节点上启动QE。QE启动以后会把各自的描述信息(包括进程号，监听端口等)通过proxydispatcher汇总，然后回传给QD上的maindispatcher。Maindispatcher会把QE传回来的全局描述信息填充到查询计划里，连同元数据等分发下去，这个时候main dispatcher只会把信息第一步分发给每个segment节点上的proxydispatcher，然后由每个segment节点的proxydispatcher分发给各自管理的QE去执行。在整个执行过程中，maindispatcher在监控proxydispatcher的状态，每个proxydispatcher在监控各自管理的QE状态。所有QE执行成功消息会通过proxy dispatcher汇总回传给maindispatcher，如果其中任何一个进程(包括QE和proxy dispatcher)出现故障，错误信息都会最终回传给maindispatcher，maindispatcher收到出错信息以后，会负责去取消其他正在执行的proxydispatcher，并且把第一个错误报给终端用户。Proxydispatcher会负责去取消各自管理的QE。为了避免每次新启动进程带来的开销，maindispatcher上维护了proxydispatcher的pool，proxydispatcher上维护了QE的pool。pool里的proxydispatcher和QE都是可以复用的，直到session连接退出或者超时条件达成。

并行任务调度器采用代理模式显著的减少了master和segment节点之间的libpq连接，上面的例子里1000个segment节点，每个节点100个QE，master到segment节点一共有100000个libpq连接，采用代理模式master节点到segment节点一共有1000个libpq连接。同时如果每次分发的数据量是100MB，之前需要为100000个QE每个分发100MB数据，master和segment节点之间有大量的数据传输，改成代理模式以后master只需要为1000个proxydispatcher各自分发100MB数据，显著降低了master到segment的数据传输量。

从而根据本实施例，在分布式数据库中的每个从节点设置代理调度器，因此主节点在每次发送任务的时候只需要向从节点发送任务，然后从节点通过代理调度器将任务下发至查询执行器，因此主节点不需要向每个查询执行器发送。从而与现有技术相比，本方案可以显著减少主节点与查询执行器之间的连接数量。达到了节省计算资源的技术效果。此外，通过向从节点发送查询任务的过程中，对于共用的数据部分只发送一份，因此还可以进一步地节省了计算资源，提高数据的发送效率。进而解决了现有技术中存在的分布式集群中的主节点的查询调度器需要和和每个从节点的每个查询执行器建立连接关系，因此随着集群规模的扩大会影响任务派遣速度，甚至造成集群到达瓶颈的技术问题。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种分布式数据库中的并行任务调度系统，其特征在于，包括：主节点以及与所述主节点通信的至少一个从节点，并且所述从节点设置有用于执行调度任务的代理调度器，其中所述主节点配置用于执行以下操作：

接收查询语句，并根据所述查询语句生成查询任务；

将所述查询任务发送至所述至少一个从节点；以及

所述从节点配置用于执行以下操作：

接收所述查询任务；

通过所述代理调度器将所述查询任务分配至由所述从节点管理的至少一个查询执行器进行处理。

2.根据权利要求1所述的系统，其特征在于，将所述查询任务发送至所述至少一个从节点，包括：

从所述至少一个从节点中确定用于执行所述查询任务的目标从节点，并启动所述目标从节点的所述代理调度器；以及

将所述查询任务发送至所述目标从节点。

3.根据权利要求1所述的系统，其特征在于，接收所述查询任务之前，还包括：

所述从节点通过所述代理调度器接收所述至少一个查询执行器的基本信息并汇总；以及

所述从节点通过所述代理调度器将汇总后的所述至少一个查询执行器的基本信息发送至所述主节点。

4.根据权利要求1所述的系统，其特征在于，通过所述代理调度器将所述查询任务分配至由所述从节点管理的至少一个查询执行器进行处理之后，还包括：

所述从节点通过所述代理调度器接收所述至少一个查询执行器发送的第一消息并汇总，其中所述第一消息用于描述所述查询任务的处理情况；以及

所述从节点通过所述代理调度器将汇总后的第一消息发送至所述主节点。

5.根据权利要求4所述的系统，其特征在于，还包括：

在根据所述汇总后的第一消息确定所述代理调度器或者所述查询执行器出现故障的情况下，所述主节点关闭正在执行所述查询任务的从节点的代理调度器。

6.根据权利要求5所述的系统，其特征在于，还包括：所述主节点将错误信息发送至与所述查询语句对应的终端设备。

7.根据权利要求1所述的系统，其特征在于，所述从节点还设置有用于缓存开启状态的查询执行器的第一线程池，并且通过所述代理调度器管理所述第一线程池。

8.根据权利要求1所述的系统，其特征在于，所述主节点还设置有用于缓存开启状态的查询执行器的第二线程池。

9.根据权利要求1所述的系统，其特征在于，所述从节点还设置有用于缓存调度到主节点执行的查询执行器的第三线程池。

10.根据权利要求1所述的系统，其特征在于，所述从节点从对应的主进程克隆所述代理调度器。

Images