掌桥专利:专业的专利平台
掌桥专利
首页

DDL任务的并行处理方法、计算节点、及电子设备

文献发布时间:2023-06-19 18:34:06


DDL任务的并行处理方法、计算节点、及电子设备

技术领域

申请涉及数据库技术领域,具体而言,本申请涉及一种DDL任务的并行处理方法、计算节点、电子设备、计算机可读存储介质。

背景技术

目前数据定义语言(data definition language,DDL)语句的分布式调度系统主要分为如下集中实现:

1,以Oracle,MySQL等传统数据库为例的传统单机或者集群系统。通常采用实现一个Meta data Lock系统,通过对于需要进行DDL变更的对象加锁的方式,来协调各种DDL语句执行的先后顺序。达到并发效果。

2,分布式数据库系统Ocean Base,TDSQL的数据库也是通过采取在分布式系统中实现一种类似MDL锁的方式来达成并发DDL语句调度的效果。

如何保证在多个DDL worker(也称之为任务执行单元)在并发执行DDL任务的时候,不会造成用户数据库中对象定义或者对象存储的数据的不一致性,是需要解决的问题。

发明内容

本申请实施例提供了一种DDL任务的并行处理方法、计算节点、电子设备、计算机可读存储介质,可以解决现有技术的上述问题。所述技术方案如下:

根据本申请实施例的一个方面,提供了一种数据定义语言DDL任务的并行处理方法,由数据库系统中的目标计算节点执行,所述方法包括:

获得作业任务表,所述作业任务表用于记录未处理完成的DDL任务的相关信息,所述相关信息包括DDL任务进入数据库系统的顺序以及DDL任务对应的变更对象所处的数据模式;

确定正在执行的第一DDL任务,从所述作业任务表中确定符合预先确定的任务并行处理规则的第二DDL任务,所述任务并行处理规则与DDL任务进入数据库系统的顺序以及DDL任务对应的变更对象所处的数据模式相关;

将所述目标第二DDL任务与所述第一DDL任务并行处理。

根据本申请实施例的另一个方面,提供了一种数据库系统中的目标计算节点,该节点包括:

作业任务表模块,用于获得作业任务表,所述作业任务表用于记录未处理完成的DDL任务的相关信息,所述相关信息包括DDL任务进入数据库系统的顺序以及DDL任务对应的变更对象所处的数据模式;

任务确定模块,用于确定正在执行的第一DDL任务,从所述作业任务表中确定符合预先确定的任务并行处理规则的第二DDL任务,所述任务并行处理规则与DDL任务进入数据库系统的顺序以及DDL任务对应的变更对象所处的数据模式相关;

并行处理模块,用于将所述第二DDL任务与所述第一DDL任务并行处理。

根据本申请实施例的另一个方面,提供了一种电子设备,该电子设备包括存储器、处理器及存储在存储器上的计算机程序,处理器执行所述计算机程序以实现上述DDL任务的并行处理方法的步骤。

根据本申请实施例的再一个方面,提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现上述DDL任务的并行处理方法的步骤。

本申请实施例提供的技术方案带来的有益效果是:

通过获取任务作业任务表,任务作业任务表中记录了至少一个DDL任务的相关信息,基于任务并行处理规则,从作业任务表中确定与处理中的第一DDL任务可并行处理的第二DDL任务,将第二DDL任务与第一DDL任务并行处理,实现逻辑简单,并且可扩展性强,能够适应不同的数据块形态的部署,不存在现有技术那样只能从队列中按排序选择DDL任务的限定。

附图说明

为了更清楚地说明本申请实施例中的技术方案,下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为相关技术提供的DDL任务的执行流程示意图;

图2为本申请实施例提供的一种DDL任务的并行处理方法的流程示意图;

图3为本申请实施例提供的一种由三种级别的变更对象构成的树结构;

图4为本申请另一个实施例提供的一种DDL任务的处理方法的流程示意图;

图5为本申请再一个实施例提供的一种DDL任务的处理方法的流程示意图;

图6为本申请实施例提供的一种目标计算节点的结构示意图;

图7为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解,下面结合附图所阐述的实施方式,是用于解释本申请实施例的技术方案的示例性描述,对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”和“该”也可包括复数形式。应该进一步理解的是,本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件,但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解,当我们称一个元件被“连接”或“耦接”到另一元件时,该一个元件可以直接连接或耦接到另一元件,也可以指该一个元件和另一元件通过中间元件建立连接关系。此外,这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个,例如“A和/或B”可以实现为“A”,或者实现为“B”,或者实现为“A和B”。

为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。

目前常见的DDL语句的实现采取的解决方案是在分布式集群里面所有的DDL任务会以进入集群的先后顺序登记到一个队列当中,之所以需要登记到队列当中主要是用在故障恢复的目的。这些任务会被执行DDL任务的任务执行单元获取并执行。具体执行流程如图1所示,计算节点都可以接受来自客户端的DDL变更语句,然后将语句存入DDL任务队列中,任务执行单元从DDL任务队列中每次取一个DDL任务执行,由于DDL任务的执行顺序仅与DDL任务队列中的DDL任务的排序相关,因此多个任务执行单元在并发执行DDL任务时,可能造成用户数据库中对象定义或者对象存储的数据的不一致性。通常数据库会使用MDL锁来保证DDL语句之间的正确执行。

本申请提供的DDL任务的并行处理、装置、电子设备、计算机可读存储介质以及计算机程序产品,旨在解决现有技术的如上技术问题。

下面通过对几个示例性实施方式的描述,对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。需要指出的是,下述实施方式之间可以相互参考、借鉴或结合,对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等,不再重复描述。

本申请实施例中提供了一种DDL任务的并行处理方法,如图2所示,该方法包括:

S101、获得作业任务表,所述作业任务表用于记录未处理完成的DDL任务的相关信息,所述相关信息包括DDL任务进入数据库系统的顺序以及DDL任务对应的变更对象所处的数据模式schema。

客户端在向数据库系统发送DDL语句后,可以根据DDL语句获得至少一个DDL任务,本申请实施例可以根据DDL任务进入数据库系统的顺序,设置每个DDL任务的任务标识,并将DDL任务的相关信息写入作业任务表。

本申请实施例的DDL任务的相关信息可以包括DDL任务的任务标识、DDL任务的元信息(也即执行DDL任务执行的关键信息,可以确保DDL任务的正确执行与发生异常处理)、DDL任务执行的计算节点等等,本申请实施例不作具体的限定。

在一个实施例中,通过任务标识用来表征DDL任务进入数据库系统的顺序,例如第一个进入数据库系统的DDL任务的任务标识为1,第二个进入数据库系统的DDL任务的任务标识为2,以此类推。

S102、确定正在执行的第一DDL任务,从所述作业任务表中确定符合预先确定的任务并行处理规则的第二DDL任务,所述任务并行处理规则与DDL任务进入数据库系统的顺序以及DDL任务对应的变更对象所处的数据模式相关;

本申请实施例通过将待处理的DDL任务的相关信息记录于作业任务表中,在确定当前执行的第二DDL任务时不存在现有技术那样只能从队列中按排序选择DDL任务的限定。

本申请实施例的DDL任务并发规则包括但不限于以下内容:

1)同一数据表上的DDL语句对应的DDL任务需要根据DDL任务进入数据库系统的先后顺序执行;

2)不同数据表上的DDL语句对应的DDL任务可以并发执行;

3)数据中不同级别的变更对象对应的DDL任务,也需要根据级别的顺序执行。

请参见图3,其示例性地示出了本申请实施例由三种级别的变更对象构成的树结构,其中树结构的根节点为第一级别的变更对象:DB(schema),第二级别的变更对象包括:function、stored procedure、Table、view,对于Table而言,其第三级别的变更对象包括:index、column、tigger和constraint。

在一个实施例中,本申请实施例基于SQL语句实现了任务并行处理规则,基于SQL语句实现任务并行处理规则的好处在于其是无锁且非常轻量的操作,不影响DML以及其他DDL任务的执行。

本申请实施例基于SQL语句实现的任务并行处理规则包括:

语句1:select*from tidb_ddl_job where job_id in(select min(job_id)fromtidb_ddl_job where not reorg group by table_id)and exec_owner=0;

语句1的含义是:找到当前的第二DDL任务,如果是物理DDL任务,在选择执行该第二DDL任务之后,需要将第二DDL任务的相关信息记录到重组信息表中。exec_owner=0表示DDL任务还没有被执行。

语句2:select*from tidb_ddl_job where is_drop_schema and schema_id={job.SchemaID}and job_id<{job.id}limit 1;

语句2的含义是:如果是第二或三级别的变更对象,判断是否有更高级别的变更对象对应的DDL任务执行。

语句3:select*from mysql.tidb_ddl_job where schema_id={job.SchemaID}and job_id<{job.id}limit 1;

语句3的含义是如果是第一级别的变更对象,判断是否有更低级别的变更对象对应的DDL任务执行。

需要说明的是,上述3条SQL语句是针对TiDB开源分布式关系型数据库的实现,对于其他数据库,如果做相应的实现,SQL语句会有所改动,本质不变,本申请实施例不再赘述。

S103、将所述第二DDL任务与第一DDL任务并行处理。

本申请在确定第二DDL任务后,即可将第二DDL任务与正在执行的第一DDL任务并行处理。本申请实施例的第一DDL任务的数量不作具体限定,例如可以是一个,也可以是多个。

本申请实施例通过获取作业任务表,作业任务表中记录了至少一个未处理完成的DDL任务的相关信息,基于任务并行处理规则,从作业任务表中确定与处理中的第一DDL任务可并行处理的第二DDL任务,将第二DDL任务与第一DDL任务并行处理,实现逻辑简单,并且可扩展性强,能够适应不同的数据块形态的部署,不存在现有技术那样只能从队列中按排序选择DDL任务的限定。

在上述各实施例的基础上,作为一种可选实施例,相关信息包括用于指示当前执行对应DDL任务的计算节点的计算节点标识,所述作业任务表包括用于记录计算节点标识的第一字段。

具体地,本申请实施例可以在作业任务表中设置exec owner字段(即第一字段),在该字段中记录当前执行对应DDL任务的计算节点的计算节点标识,应当理解的是,当DDL任务没有被执行过时,第一字段可以为空,或者其他表示没有被执行过的标记(例如0)。如果DDL任务被执行过但没有执行成功,则该字段仍然会记录执行该DDL任务的计算节点的计算节点标识。

将所述第二DDL任务与所述第一DDL任务并行处理,包括:

S201、若根据作业任务表中第二DDL任务的第一字段确定第二DDL任务首次被执行,则在第一字段记录目标计算节点的目标计算节点标识;

S202、调用所述数据库系统中的任务执行单元执行所述第二DDL任务,所述任务执行单元的类型包括进程、线程、协程中的至少一种。

本申请实施例在确定第二DDL任务首次被执行时,需要初始化第二DDL任务,并在第一字段记录目标计算节点的目标计算节点标识,后续如果第二DDL任务没有执行成功,便于回退。

在记录目标计算节点标识后,本申请实施例即可调用任务执行单元执行第二DDL任务。需要说明的是,本申请实施例具有多个任务执行单元,计算节点可以从多个任务执行单元选择空闲的任务执行单元执行第二DDL任务。多个任务执行单元可以并行执行DDL任务。在一些实施例中,一个DDL任务可以拆分为多个子任务,每个任务执行单元用于执行一个子任务。

在上述各实施例的基础上,作为一种可选实施例,相关信息包括DDL任务对应的变更对象的对象标识以及所述DDL任务的元信息。

具体地,本申请实施例可以在作业任务表中设置table_id字段(即第二字段)记录DDL任务对应的变更对象的对象标识,设置schema_id字段(即第三字段)记录变更对象所处的schema的模式标识,设置job meta字段(即第四字段)记录DDL任务的元信息。

调用数据库系统中的任务执行单元执行第二DDL任务,包括:

S301、调用所述任务执行单元读取所述作业任务表中所述第二DDL任务的所述第二字段至第四字段,获得所述第二DDL任务对应的目标变更对象的目标对象标识、所述目标变更对象所处的目标数据模式的目标模式标识以及所述第二DDL任务的目标元信息;

S302、根据所述目标对象标识和所述目标模式标识,从所述数据库系统的所述目标数据模式中确定所述目标变更对象;

S303、根据所述目标元信息,对所述目标变更对象执行所述第二DDL任务。

本申请实施例的任务执行单元通过读取作业任务表中第二DDL任务的第二字段至第四字段,可获得第二DDL任务对应的目标变更对象的目标对象标识、所述目标变更对象所处的目标schema的目标模式标识以及所述第二DDL任务的目标元信息,基于目标对象标识和目标模式标识,可以从数据库系统中确定目标变更对象,最后基于目标元信息对目标变更对象执行第二DDL任务,可以实现精准确定变更对象并进行任务处理。

在上述各实施例的基础上,作为一种可选实施例,对所述第二DLL任务进行并行处理,还包括:

S401、若根据所述作业任务表中所述第二DDL任务的第一字段确定所述第二DDL任务非首次被执行,则判断是否恢复所述第二DDL任务的执行;

S402、若确定恢复所述第二DDL任务的执行,则执行所述第二DDL任务,若确定不恢复所述第二DDL任务的执行,则回滚上一次执行所述第二DDL任务产生的数据。

需要说明的是,当第一字段中记录了除目标计算节点之外的计算节点的计算节点标识,表示第二DDL任务不是首次执行,且上一次执行失败,此时需要判断是否恢复第二DDL任务的执行(DDL任务如果执行完毕,则会归档到历史任务表中,如果还在作业任务列表中,则表示仍需要继续执行)。

若确定恢复第二DDL任务的执行,则执行第二DDL任务,具体地,本申请实施例可以在作业任务表中记录第二DDL任务上一次执行的进度,从而根据上一次执行的进度继续执行第二DDL任务。若确定不恢复第二DDL任务的执行,则回滚上一次执行所述第二DDL任务产生的数据,可以理解的是,回滚后该第二DDL任务也不再执行。

在上述各实施例的基础上,作为一种可选实施例,相关信息包括用于指示相应DDL任务是否为逻辑DDL任务的类型标识,所述作业任务表包括用于记录所述类型标识的第五字段;

通常DDL任务可以分为逻辑DDL和物理DDL,逻辑DDL只需要修改数据库中对象(数据表、索引、列等)的定义即可(例如修改表名)。物理DDL,则通常有一个重组(reorg)的过程,这个过程通常需要扫描一次数据表的完整数据,将数据表上的数据同步到新增或者修改的对象上面,确保数据一致性。

作业任务表包括用于记录所述类型标识的reorg字段(也即第五字段)。

将所述第二DDL任务与所述第一DDL任务并行处理,包括:

S501、若根据所述作业任务表中所述第二DDL任务的第五字段确定所述第二DDL任务不为逻辑DDL任务,则将所述第二DDL任务拆分为多个子任务;

S502、根据所述子任务的数量,调用相应数量的任务执行单元并行执行子任务。

具体地,本申请实施例若根据第二DDL任务的第五字段确定第二DDL任务为逻辑DDL任务,则不对第二DDL任务进行拆分,即只调用一个任务执行单元执行第二DDL任务。若第二DDL任务不为逻辑DDL任务,也即为物理DDL任务,则将第二DDL任务拆分为多个子任务,由相应数量的任务执行单元并行执行子任务。

在上述各实施例的基础上,作为一种可选实施例,调用相应数量的任务执行单元执行子任务,之前还包括:

创建所述第二DDL任务的重组信息表。

在所述重组信息表中记录所述子任务的元信息;

所述调用相应数量的任务执行单元执行子任务,包括:

调用所述任务执行单元,根据所述重组信息表中相应子任务的元信息,执行所述相应子任务。

具体的,子任务的元信息包括子任务开始扫描和结束扫描的数据位置、所述目标计算节点的节点标识、所述子任务的执行状态中的至少一种。

本申请实施例的重组信息表包括以下字段:

Job id,用于记录DDL任务的任务标识;

reorg_obj_id,用于记录需要重组的变更对象的对象标识,例如add index中index的标识。

physical_id,需要scan表的id;

dist para,用于记录各个子任务的元信息,以进行并行调度。

在一些实施例中,dist para字段包括:

exec_dist,用于表示是否在整个集群中分布式执行DDL任务;

is_canceled,用于表示是否取消执行DDL任务;

curr_reorg_type,用于表示reorg的任务类型;

reorg sub tasks,进一步包括:

sub scan start point,用于记录子任务开始扫描的数据位置;

sub scan end point,用于记录子任务结束扫描的数据位置;

sub scan executor,用于记录子任务的计算节点;

sub task staus,用于记录子任务的执行状态。

在一个可选实施例中,任务并行处理规则是基于结构化查询语言SQL语句实现的;

从所述作业任务表中确定符合预先确定的任务并行处理规则的第二DDL任务,包括:

从所述作业任务表中选择参考DDL任务,将参考DDL任务的任务标识和模式标识写入所述任务并行处理规则,若确定所述任务并行处理规则符合预设条件,则将所述参考DDL任务作为所述目标DDL任务。

在上述各实施例的基础上,作为一种可选实施例,将所述第二DDL任务与所述第一DDL任务并行处理,之后还包括:

在处理所述第二DDL任务结束后,将所述第二DDL任务的相关信息从所述作业任务表中移动至任务历史表中,所述任务历史表包括所述作业任务表中的字段。

请参见图4,其示例性地示出了本申请另一个实施例的DDL任务的处理方法的流程示意图,如图所示,包括:

步骤S601、目标计算节点开始运行;

步骤S602、目标计算节点根据任务并行处理规则,从作业任务表中选择第二DDL任务;

步骤S603、启动任务执行节点并发执行步骤S603-608部分的逻辑,判断第二DDL任务是否首次启动,若否,则进入步骤S604,若是,则进入步骤S605;

步骤S604、初始化第二DDL任务,更新作业任务表,之后进入步骤S610;

步骤S605、判断是否恢复第二DDL任务,若是,则进入步骤S606,若否,则进入步骤S607;

步骤S606、恢复之前保存的第二DDL任务的执行进度,并继续执行,在完成第二DDL任务或者出现异常情况后进入步骤608;

步骤S607、回滚上一次执行所述第二DDL任务产生的数据;

步骤S608、结束第二DDL任务的执行,将第二DDL任务的相关信息从所述作业任务表中移动至任务历史表中,任务历史表包括所述作业任务表中的字段;

步骤S609、计算节点并行发起一个后台任务,不断选择可以执行的DDL任务,如果有可选的DDL任务,则进入步骤S602,如果没有可选的DDL任务,进入步骤S610;

步骤S610、判断是否计算节点结束运行,若否,进入步骤S611,若是,进入步骤S612;

步骤S611、休眠一个周期,例如1秒,然后进入步骤SS609;

步骤S612、流程结束。

请参见图5,其示例性地示出了本申请再一个实施例的DDL任务的处理方法的流程示意图,如图所示,包括:

S701、每一个物理DDL任务都有一个主子任务,使用第一个子任务作为主子任务;

S702、判断是否需要启动DDL任务,若是,进入步骤S703;若否,进入步骤S706;

S703、启动DDL任务;

S704、读取作业任务表中DDL任务的prefer_rule字段,prefer_rule设置DDL任务在集群中执行时并行的分布策略(例如:根据不同计算阶段的计算资源,设置并行的不同的任务执行节点的数目,或者根据数据位置,设置不同子任务在不同的计算节点上),一个简单的分布策略可以包括按照同一种方式对所有计算节点进行并行设置。

S705、将需要回填的数据按照DDL任务生成的子任务数,划分子任务数据处理范围。如果需要回填的数据比较少,相应的减少子任务数量。初始化重组信息表中的dist_para,为每一个计算节点初始化dist_para,设置exec_owner.保存dist_para信息。

S706、各计算节点根据任务并行处理规则获取当前活跃的可执行的DDL任务,查看子任务中是否有需要自身执行的子任务,若有,则恢复子任务的上下文;

S707、执行子任务,本申请实施例的计算节点根据自身情况启动相应的任务执行节点执行DDL任务;

S708、每个计算节点启动任务执行节点,检查是否取消执行DDL任务执行,若是,进入步骤S712,若否,进入步骤S709;

S709、完成数据处理;

S710、在重组信息表更新子任务状态,这里可以采用乐观事务模式,因为有其他子任务更新同一条DDL任务,更新子任务会有可能失败,因此只需要重新获取最新的DDL任务,只更新和自身相关的子任务,再次提交,直到更新成功;也可以采用悲观事务模式,每次需要提交子任务状态的时候,先获取最新的DDL任务,并锁定记录,完成更新后提交事务。

S711、判断子任务是否完成,若否,进入步骤S708,若是,进入步骤S715;

S712、判断是否是主子任务,若否,进入步骤S715,若是,进入步骤S713;

S713、判断是否所有子任务都结束。具体通过判断每个子任务的status字段来判断是否子任务都结束了。若否,进入步骤S714,若是,进入步骤S716;

S714、休眠一段时间;

S715、子任务结束。

S716、DDL任务结束。

需要说明的是,当需要取消执行DDL任务时,只需要将is_canceled字段设置为true。所有任务在更新子任务状态时,首先需要读取任务记录,获取该字段即可确定是否取消任务。包括某个子任务发生异常退出,也可以通过设置这个字段来停止DDL任务执行,并通过子任务状态将错误信息返回。

对于计算节点Crash重启的异常情况,计算节点的每个任务执行节点选择一个非活跃的DDL任务,查看属于自身执行的子任务,将子任务恢复即可。计算节点可以编号,即计算节点即使在其他机器上重启,只要编号不变,依然可以根据编号获取子任务,然后恢复对应的子任务,继续执行。

对于计算节点Crash后长期不能启动的情况,计算节点增加一个对于集群中计算节点变更的感知,当有计算节点在一段时间未能重新加入节点,就将重组信息表中子任务的exec_owner修改为集群中的其他节点或者清0(所有活跃节点均可获取改DDL任务并恢复执行),等待其他计算节点的任务执行节点恢复执行。

本申请具有以下技术效果:

1,方案实现逻辑简单,可扩展性强

2,方案能够充分利用集群整体资源,自动进行任务的负载均衡,具备很强的在线扩展性

3,能够适应不同的数据库形态的部署;

a)单实例数据库部署;

b)集群单主节点,全集群分布式DDL任务调度;

c)集群分布式DDL任务调度(多主节点);

4,对于分布式系统中故障恢复有特别良好的表现,不会像锁实现方案中会遇到分布式死锁检测的复杂度问题,或者是单点锁中控的性能和故障单点问题。

5,故障恢复简单,高效,本方案能够在基本上无需额外操作的情况下,使得DDL任务调度恢复正常。

6,很容易在本模型实现特定的分布式调度规则,将特定的DDL任务调度到特定的计算节点上执行,例如通过数据的位置,多租户的可用计算节点等等条件来调度。

本申请实施例提供了一种数据库系统中的目标计算节点,如图6所示,该节点可以包括:作业任务表模块601、任务确定模块602以及并行处理模块603,其中,

作业任务表模块601,用于获得作业任务表,所述作业任务表用于记录未处理完成的DDL任务的相关信息,所述相关信息包括DDL任务进入数据库系统的顺序以及DDL任务对应的变更对象所处的数据模式;

任务确定模块602,用于确定正在执行的第一DDL任务,从所述作业任务表中确定符合预先确定的任务并行处理规则的第二DDL任务,所述任务并行处理规则与DDL任务进入数据库系统的顺序以及DDL任务对应的变更对象所处的数据模式相关;

并行处理模块603,用于将所述第二DDL任务与所述第一DDL任务并行处理

本申请实施例的节点可执行本申请实施例所提供的方法,其实现原理相类似,本申请各实施例的节点中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的,对于节点的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述,此处不再赘述。

本申请实施例中提供了一种电子设备,包括存储器、处理器及存储在存储器上的计算机程序,该处理器执行上述计算机程序以实现DDL任务的并行处理方法的步骤,与相关技术相比可实现:通过获取任务作业任务表,任务作业任务表中记录了至少一个DDL任务的相关信息,基于SQL语句实现任务并行处理规则,从作业任务表中确定与处理中的其他DDL任务可并行处理的第二DDL任务,将第二DDL任务与第一DDL任务并行处理,实现逻辑简单,并且可扩展性强,能够适应不同的数据块形态的部署,不存在现有技术那样只能从队列中按排序选择DDL任务的限定。

在一个可选实施例中提供了一种电子设备,如图7所示,图7所示的电子设备4000包括:处理器4001和存储器4003。其中,处理器4001和存储器4003相连,如通过总线4002相连。可选地,电子设备4000还可以包括收发器4004,收发器4004可以用于该电子设备与其他电子设备之间的数据交互,如数据的发送和/或数据的接收等。需要说明的是,实际应用中收发器4004不限于一个,该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit,中央处理器),通用处理器,DSP(Digital Signal Processor,数据信号处理器),ASIC(Application SpecificIntegrated Circuit,专用集成电路),FPGA(Field Programmable Gate Array,现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。处理器4001也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等。

总线4002可包括一通路,在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect,外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture,扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示,图7中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory,只读存储器)或可存储静态信息和指令的其他类型的静态存储设备,RAM(Random Access Memory,随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备,也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory,电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory,只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质,在此不做限定。

存储器4003用于存储执行本申请实施例的计算机程序,并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序,以实现前述方法实施例所示的步骤。

本申请实施例提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请实施例还提供了一种计算机程序产品,包括计算机程序,计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除图示或文字描述以外的顺序实施。

应该理解的是,虽然本申请实施例的流程图中通过箭头指示各个操作步骤,但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明,否则在本申请实施例的一些实施场景中,各流程图中的实施步骤可以按照需求以其他的顺序执行。此外,各流程图中的部分或全部步骤基于实际的实施场景,可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行,这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下,这些子步骤或者阶段的执行顺序可以根据需求灵活配置,本申请实施例对此不限制。

以上所述仅是本申请部分实施场景的可选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请的方案技术构思的前提下,采用基于本申请技术思想的其他类似实施手段,同样属于本申请实施例的保护范畴。

相关技术
  • 任务处理方法、装置、电子设备及计算机可读存储介质
  • 任务处理方法、装置、电子设备及计算机可读存储介质
  • 任务处理方法、装置及电子设备
  • 一种任务处理方法、装置、电子设备及介质
  • 任务处理方法及装置、电子设备及存储介质
  • DDL任务的分布式处理方法、节点及分布式数据库系统
  • 交易任务的并行处理方法、装置、电子设备和存储介质
技术分类

06120115614285