具体实施方式
为了使本领域的人员更好地理解本申请实施例中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本申请实施例一部分实施例,而不是全部的实施例。基于本申请实施例中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于本申请实施例保护的范围。
图2中示出了一种分布式系统,该系统100可以包括通过通信网络104相连的多个物理节点102,图2中示例为4个物理节点。
在分布式数据库系统中,物理节点102主要用于存储信息、数据、程序和/或任何其他合适类型的内容等,由DBMS(DataBase Management System,数据库管理系统)进行管理和运行。在一台物理节点上可以部署一个或多个数据库分片,本申请实施例中,将每个数据库分片称为一个分片节点。
一个分布式数据库在逻辑上是一个统一的整体,在物理上则是分别存储在不同的物理节点上。在分布式数据库系统中,一个应用程序可以对数据库进行透明操作,数据库中的数据分别在不同的局部数据库中存储、由不同的 DBMS进行管理、在不同的机器上运行、由不同的操作系统支持、被不同的通信网络连接在一起。从用户的角度看,一个分布式数据库系统在逻辑上和集中式数据库系统一样,用户可以在任何一个场地执行全局应用,就好像数据是存储在同一台计算机上,有单个DBMS管理一样。
而对于采用分片形式的分布式数据库系统,则需要对数据库进行分库分表。此种情况下,一张数据表可能被拆分到多个数据库中,分成多张表。如图2中示例所示,item表原为一张表,按照一定的拆分原则(如按照itemid)被拆分为4张表(分别为item01、item02、item03、item04),分布至4个数据库(DB1、DB2、DB3、DB4)中,并且,图2示例中,这4个数据库分别位于不同的4个物理节点1、2、3和4上(实际应用中,有可能部分数据库位于同一物理节点)。此种情况下,应用将无法直连数据库,需要支持数据库分库分表的中间件进行路由访问数据。在MYSQL-SHARDING类型的分布式数据库中,可以由其中的计算节点CN充当中间件(也称中间件节点)。
基于此,如图2所示,对于用户来说,其对数据库的访问从逻辑层面来说还是一个单库单表的形式,如图2所示的逻辑库DB和逻辑表item。但实际上,应用对item的访问将由中间件路由到不同的物理节点上的数据库和数据表中。例如,假设itemid0001-1000在item01表中,itemid1001-2000在item02表中,itemid2001-3000在item03表中,itemid3001-4000在item04表中,则用户对itemid1501的访问将被中间件路由至物理节点2的DB02的item02中。
在一些实施例中,当用户输入一条针对逻辑库表的逻辑DDL指令,将先由中间件节点接收外部传入的该逻辑DDL指令;进而,中间件节点对逻辑DDL指令的兼容性类型进行判断,以根据判断结果确定是否立即让新的逻辑Schema对外可见;然后,中间件节点将逻辑DDL指令转换为物理DDL指令;中间件节点将物理DDL指令分发给所有分片节点;每个分片节点执行物理DDL指令,并在其物理日志中记录DDL Event;中间件节点等待所有分片节点都已成功执行物理DDL指令后,中间件节点构造DDL打标指令;中间件节点将该DDL打标指令分发给所有分片节点;每个分片节点执行这个DDL打标指令,并在各自的物理日志中生成代表该打标操作的DDL打标事件;中间件节点等待所有分片节点都已成功执行打标指令;此时,中间件节点还会根据之前对逻辑DDL指令的兼容性判断的判断结果,若确定判断结果指示在该阶段让新的逻辑Schema对外可见,则进行相应操作,以使新的逻辑Schema对外可见。
在一些实施例中,通信网络104可以是一个或多个有线和/或无线网络的任何适当的组合。例如,通信网络104能够包括以下各项中的任何一种或多种:互联网、内联网、广域网(WAN)、局域网(LAN)、无线网络、数字订户线路(DSL)网络、帧中继网络、异步转移模式(ATM)网络、虚拟专用网(VPN)和/或任何其它合适的通信网络。
基于上述系统,本申请实施例提供了一种数据处理方法,以下通过多个实施例进行说明。
实施例一
参照图3A,示出了根据本申请实施例一的一种数据处理方法的步骤流程图。
本实施例的数据处理方法从分布式数据库系统中的分片节点角度进行说明,该数据处理方法包括以下步骤:
步骤S202:接收由用于对分布式数据库系统中的数据进行变更的逻辑DDL指令转换成的物理DDL指令。
如前所述,分布式数据库系统中的数据虽然可能实际分布在多个物理节点上或多个分片节点上,但呈现给用户的却是“单库单表”的形式,用户可以直接对相应的“单表”,即呈现给用户的逻辑表进行相应操作,如进行对数据表进行DDL变更的操作等,此种针对逻辑表的DDL操作将生成逻辑DDL指令。
通过该逻辑DDL指令,可实现诸如为数据表增加数据列、变更数据列类型、长度,为数据列增加约束等功能。但该逻辑DDL指令需最终转换成可被实际分片节点对应的数据库和数据表执行的指令,即物理DDL指令,才能实现其目的。
例如,在分布式MySQL-SHARDING的数据库系统,具备多个分片的库表即为逻辑库表,作用在逻辑库表上的DDL指令即为逻辑DDL指令;每个分片的数据需要存储到各自的分库分表,即为物理库表(具体实现在相应的分片节点上),作用在物理库表上的DDL指令即为物理DDL指令。
其中,将逻辑DDL指令转换成物理DDL指令的具体转换方式可由本领域技术人员根据实际情况采用适当方式实现,本申请实施例对此不作限制,转换后的物理DDL指令可被准确下发至对应的分片节点即可。
此外,需要说明的是,本申请实施例中,若无特殊说明,“多个”、“多种”等与“多”有关的数量均意指两个及两个以上。
步骤S204:执行物理DDL指令,并在成功执行物理DDL指令后,为本分片节点生成分片节点模式快照。
本实施例中,以单个分片节点执行DDL指令为示例进行说明,但本领域技术人员应当明了的是,在实际的应用中,逻辑DDL指令涉及的所有分片节点均可参照本实施例执行所述数据处理方法。
针对分布式数据库系统中的每个分片节点来说,其在接收到物理DDL指令后即会执行该指令。本申请实施例中,每个分片节点在成功执行完该物理DDL指令后,会在其日志中生成相应的事件数据,如DDL Event(本申请实施例中,若无特殊说明,可以认为DDL事件和DDL Event为相同含义的不同表达)。基于该事件数据,分布式数据库中相应的节点(包括但不限于计算节点、管理节点、本分片节点及其所在的物理节点等)还会为该分片节点生成分片节点模式快照,即本分片节点的Schema快照。
模式Schema也称数据模式,是数据库中全体数据的逻辑结构和特征的描述,它仅仅涉及到“型”的描述,不涉及到具体的值。“型”是指对某一类数据的结构和属性的说明,值是型的一个具体赋值。模式的一个具体值称为一个实例,同一个模式可以有很多实例。可见,模式反映的是数据的结构及其联系,而实例反映的是数据库某一时刻的状态。对于分布式数据库来说,呈现在用户层面的全局逻辑数据库、表具有对应的全局逻辑Schema,而具体的分片节点上的数据库、表具有对应的局部Schema,即本分片节点的Schema。而对于采用分片的分布式数据库系统来说,例如,分布式MySQL-SHARDING的数据库系统,具备多个分片的库表即为逻辑库表,逻辑库表的Schema即为逻辑Schema;每个分片的数据需要存储到各自的分库分表,即为物理库表(具体实现在相应的分片节点上),物理库表的Schema即为物理Schema。
因DDL指令涉及的也多为针对数据表的结构和其中数据列等的属性的变更,因此,本申请实施例中,在某个分片节点成功执行完物理DDL指令后,会生成该分片节点的Schema快照,以为后续与全局逻辑Schema快照的比对提供依据。
步骤S206:若确定分片节点模式快照与分布式数据库系统的全局逻辑模式快照不一致,则将本分片节点汇入全局日志中的日志数据调整至与全局逻辑模式快照一致。
仍以前述MYSQL-SHARDING类型的分布式数据库为示例,其中的Binlog(物理Binlog和逻辑Binlog)以事件Event的方式按序完整记录了数据库的各种操作,如DDL类型的操作和DML类型的操作,在Binlog文件中分别对应DDL Event和DML Event(本申请实施例中,若无特殊说明,可以认为DML Event和DML事件为相同含义的不同表达),每个DDL Event代表了模式Schema的一次变更,即每个DDL Event对应一个模式快照版本。其中,Binlog中的Event需满足如下两个约束:约束一,DDL Event必须具备原子性特征,即一次DDL操作只能在Binlog中对应一个DDL Event,不能拆分为多个;约束二,每个DML Event的数据模式必须和先前最近一次DDL Event对应的模式快照一致。所述两个约束必须同时满足,才能保证在消费Binlog中的数据时不会出现异常。
基于此,本申请实施例中,针对一次DDL指令,全局逻辑模式通常为该DDL指令被所有分片节点均成功执行完成后的模式,因此,当一个逻辑DDL指令被转换为物理DDL指令下发至分片节点,而分片节点并未全部完成时,分布式数据库系统的全局逻辑模式仍然是前次DDL指令执行后的模式。例如,2021年1月1日23时,DDL指令A被成功执行,则分布式数据库系统对应的全局逻辑模式为2021年1月1日23时的模式,此时生成的快照为全局逻辑模式快照A。继而,在2021年1月3日22时,逻辑DDL指令B被触发,生成多个物理DDL指令并下发至对应的多个分片节点,在2021年1月3日22时,分布式数据库系统对应的全局逻辑模式仍为2021年1月1日23时的模式,对应的全局逻辑模式快照仍为快照A。假设2021年1月3日23时,DDL指令B被成功执行,则分布式数据库系统对应的全局逻辑模式为2021年1月3日23时的模式,此时生成的快照为全局逻辑模式快照B。但是,在2021年1月3日22时至2021年1月1日23时期间,全局逻辑模式快照仍为快照A。也即,只有在所有分片节点均成功完成DDL指令后,才触发生成新的全局逻辑模式快照。
一种多个分片节点的Schema快照与全局逻辑Schema快照的对比示意如图3B所示。由图3B中可见,全局逻辑Schema快照的更新晚于分片节点Schema快照的更新。
基于此,在分布式数据库系统中仅有部分分片节点成功执行物理DDL指令的情况下,成功执行物理DDL指令的分片节点的分片节点模式快照将与分布式数据库系统的全局逻辑模式快照不一致。而另一方面,分片节点的日志数据又会不停汇入全局日志中,此种情况下,需要对分片节点汇入全局日志的日志数据进行调整,以使分片节点中的日志数据与全局逻辑模式快照一致。其中,全局日志通常为包含所有分片节点的日志的日志。例如,全局Binlog,即全局日志,其中包含所有DN节点的Binlog,按照Binlog Event的commit TSO有序,保证事务的完整性和事务间的全局有序性。
假设,以分片节点1为例,其在成功执行完物理DDL指令后,将记录该物理DDL指令的执行信息及执行后的数据的信息,这部分信息简单示意为A。再假设当前的全局逻辑模式快照的数据简单示意为B,则需要在从日志中读取出A后,将A调整为B一致,再将调整后的A汇入全局日志中。
这是因为,全局逻辑模式快照的更新依据于全局日志,而全局日志的更新依据于实时拉取并汇入的分片节点的日志数据。简单示例如下,如图1中所示,假设分布式数据库系统存在四个物理节点1、2、3和4,且每个物理节点上仅部署有一个分片,为便于描述,基于该四个物理节点上部署的分片将其分别对应称为分片节点1、2、3和4。并且,分片节点1、2、3和4当前对应的Schema均为A1,分布式数据库系统对应的全局Schema当前也为A1。设定用于指示在各个数据表中增加一列的逻辑DDL指令X被触发并被转换为对应于分片节点1、2、3和4的四个物理DDL指令X1、X2、X3和X4。则当分片节点1成功执行完X1,其Schema更新为A2,同时触发其物理日志更新,在其中记录X1的执行信息及执行后的数据的信息。该物理日志被汇入全局日志后,会引发全局日志基于物理日志的X1执行后的数据的信息的更新,因此时,分片节点2、3和4还未执行完X2、X3、X4,它们对应的Schema仍为A1,导致可能出现数据处理和访问中的不一致等问题。而通过本申请实施例的方案,在分片节点1成功执行完X1,其Schema更新为A2,同时触发其物理日志更新,而分片节点2、3和4还未执行完成对应的X2、X3、X4时,分片节点1汇入全局日志的日志数据将会调整为与全局Schema快照即A1对应的快照一致。这时,虽然分片节点1中的数据库表已经发生了变化,但因日志数据的调整,则不会因分片节点1的Schema的变化而向全局日志中汇入A2版本的数据,从而避免了在部分分片节点还未完成DDL指令时,向消费全局日志的下游系统输出不一致的数据而导致的数据处理异常。
因全局日志以事件Event的方式按序完整记录了数据库的各种操作,如DDL类型的操作和DML类型的操作在日志文件中分别对应DDL Event和DML Event,每个DDL Event代表了全局逻辑模式的一次变更,即每个DDL Event对应一个全局逻辑模式快照版本。所述全局日志必须满足如下约束,每个DML Event的数据模式必须和先前最近一次DDL Event对应的全局逻辑模式快照一致,否则在顺序消费全局日志时将会引发数据处理异常。但在多个分片节点的DDL操作不同步的情况下,多个分片节点汇入全局日志的DML Event将出现多个版本,从而违反前述所述的两个约束。而通过将分片节点汇入全局日志的日志数据调整与全局逻辑模式一致,也即以全局逻辑模式为基准,在所有分片节点未全部完成DDL操作时,仍以原全局逻辑模式对DML Event进行调整,直至所有分片节点均完成该DDL操作后生成新的全局逻辑模式快照,则可继续满足前述两个约束。由此,既无需对DML进行禁写或加锁而影响正常数据服务,也使得后台数据同步过程对用户透明,用户对全局数据表的操作不会导致数据处理异常,从而有效解决了分布式数据库系统在DDL变更过程中的多数据版本引发的数据处理异常问题。
可见,通过本实施例,引入了Schema快照即模式快照,所述模式快照划分为两类,分别为分片节点模式快照和全局逻辑模式快照,各个分片节点在成功执行物理DDL指令后,将为本分片节点生成分片节点模式快照,并将该模式快照与全局逻辑模式快照进行比对,在两者不一致时,调整分片节点汇入全局日志中的日志数据,且调整规则为将分片节点汇入全局日志中的数据调整至和全局逻辑模式快照一致。这是因为,因各分片节点执行物理DDL指令的操作无法做到原子性,则在所有分片节点的物理DDL指令全部执行成功之前,将产生不同模式版本的日志数据,并且这些数据会实时汇入全局日志中,而通过将分片节点汇入全局日志的日志数据调整与全局逻辑模式一致,则在所有分片节点未全部完成DDL操作时,仍以原全局逻辑模式为基准,直至所有分片节点均完成该DDL操作后生成新的全局逻辑模式快照。由此,在诸如基于全局日志进行数据复制的场景,可以保证为下游输出版本一致的数据,既无需对DML进行禁写或加锁,影响正常数据服务,也使得后台数据同步过程对用户透明,从而有效解决了分布式数据库系统在DDL变更过程中的多数据版本引发的数据处理异常问题。
实施例二
参照图4A,示出了根据本申请实施例二的一种数据处理方法的步骤流程图。
本实施例的数据处理方法仍从分布式数据库系统中的分片节点的角度进行说明,该数据处理方法包括以下步骤:
步骤S302:接收由用于对分布式数据库系统中的数据进行变更的逻辑DDL指令转换成的物理DDL指令。
例如,在分布式MySQL-SHARDING的数据库系统,作用在逻辑库表上的DDL指令即为逻辑DDL指令,作用在物理库表上的DDL指令即为物理DDL指令。通过该逻辑DDL指令,可实现诸如为数据表增加数据列、变更数据列类型、长度,为数据列增加约束等功能。而将逻辑DDL指令转换成物理DDL指令的具体转换方式可由本领域技术人员根据实际情况采用适当方式实现,本申请实施例对此不作限制,转换后的物理DDL指令可被准确下发至对应的分片节点即可。
步骤S304:执行物理DDL指令。
如前所述,DDL指令可实现诸如为数据表增加数据列、变更数据列类型、长度,为数据列增加约束等功能。各分片节点接收到各自的物理DDL指令后,即可根据该指令,对本分片节点的数据库表执行所述物理DDL指令所指示的操作。
步骤S306:在成功执行物理DDL指令后,为本分片节点生成分片节点模式快照。
在某分片节点成功执行物理DDL指令后,其Schema将发生变化,可为该分片节点的Schema生成快照,以为后续与全局Schema快照比对使用。
在一种可行方式中,本步骤可以实现为:在成功执行物理DDL指令后,在本分片节点的日志数据中生成用于指示物理DDL指令已被本分片节点成功执行的DDL事件,以根据DDL事件为成功执行物理DDL指令的分片节点生成分片节点模式快照。因日志数据可顺序反映节点的变化,基于日志数据中的DDL事件为本分片节点生成模式快照,可在不引入锁机制的情况下保护生成过程的原子性和一致性。
此外,本实施例中,还可接收在所有分片节点均成功执行各自的物理DDL指令后,在本分片节点的日志数据中插入用于指示逻辑DDL指令成功完成对应的DDL打标事件,该DDL打标事件具有分布式数据库系统的TSO的信息,且本分片节点的DDL打标事件的TSO与其它分片节点的DDL打标事件的TSO相同。因本实施例中是从单个分片节点的角度来对方案进行说明,若从分布式数据库系统的角度,则在所有分片节点均成功执行完各自的物理DDL指令后,会在同一TSO时刻在每个分片节点的日志中均插入一条DDL打标事件的信息,以指示逻辑DDL指令被成功执行。
也即,针对分片节点的DDL打标事件是指在分片节点的物理日志中插入一条相同的数据,以指示逻辑DDL指令被成功执行。通过该种方式,可以大大提高后续判断各个分片节点的物理DDL指令执行成功与否的效率。并且,分布式事件在各个分片拥有相同CommitTSO,可有效保证各个物理日志中的DDL相关数据处理的一致性。
在一种可行方式中,在本分片节点的日志数据中插入用于指示逻辑DDL指令成功完成对应的DDL打标事件可以实现为:在本分片节点的日志数据中插入用于指示逻辑DDL指令被成功执行的事件数据,所述事件数据中包含逻辑DDL指令的内容数据。
不管是上述DDL打标事件还是TSO信息,都将在后续全局日志更新时发挥作用,以为全局逻辑Schema更新提供依据。
步骤S308:若确定分片节点模式快照与分布式数据库系统的全局逻辑模式快照不一致,则将本分片节点汇入全局日志中的日志数据调整至与全局逻辑模式快照一致。
针对一次DDL指令,全局逻辑模式快照通常为该DDL指令被所有分片节点均成功执行完成后触发生成的模式快照,因此,当一个逻辑DDL指令被转换为物理DDL指令下发至分片节点,而分片节点并未全部完成时,分布式数据库系统的全局逻辑模式快照仍然是前次DDL指令执行后的模式快照,只有在所有分片节点均成功完成DDL指令后,才触发生成新的全局逻辑模式快照。
因此,在分布式数据库系统中仅有部分分片节点成功执行物理DDL指令的情况下,成功执行物理DDL指令的分片节点的分片节点模式快照将与分布式数据库系统的全局逻辑模式快照不一致。此种情况下,需要对分片节点汇入全局日志的日志数据进行调整,以使分片节点汇入全局日志的日志数据与全局逻辑模式快照一致,以避免在部分分片节点还未完成DDL指令时,因日志数据与全局Schema的不同而导致的数据访问和处理异常。其具体实现可参照前述实施例一中的相关描述,在此不再赘述。
一种采用上述方式进行分布式数据库系统的数据处理过程如图4B所示,从图4B中可见,在各个分片节点均成功完成物理DDL指令,并被在物理日志中进行了DDL打标后,全局日志将基于该DDL打标事件生成统一的逻辑DDL事件,由此保护了各个TSO时间节点上的数据一致性。
可见,通过本实施例,引入了Schema快照即模式快照,所述模式快照划分为两类,分别为分片节点模式快照和全局逻辑模式快照,各个分片节点在成功执行物理DDL指令后,将为本分片节点生成分片节点模式快照,并将该模式快照与全局逻辑模式快照进行比对,在两者不一致时,调整分片节点汇入全局日志中的日志数据,且调整规则为将分片节点汇入全局日志中的数据调整至和全局逻辑模式快照一致。这是因为,因各分片节点执行物理DDL指令的操作无法做到原子性,则在所有分片节点的物理DDL指令全部执行成功之前,将产生不同模式版本的日志数据,并且这些数据会实时汇入全局日志中,而通过将分片节点汇入全局日志的日志数据调整与全局逻辑模式一致,则在所有分片节点未全部完成DDL操作时,仍以原全局逻辑模式为基准,直至所有分片节点均完成该DDL操作后生成新的全局逻辑模式快照。由此,在诸如基于全局日志进行数据复制的场景,可以保证为下游输出版本一致的数据,既无需对DML进行禁写或加锁,影响正常数据服务,也使得后台数据同步过程对用户透明,从而有效解决了分布式数据库系统在DDL变更过程中的多数据版本引发的数据处理异常问题。
实施例三
参照图5,示出了根据本申请实施例三的一种数据处理方法的步骤流程图。
本实施例的数据处理方法从分布式数据库系统中的中间件节点角度进行说明,该数据处理方法包括以下步骤:
步骤S402:接收用于对分布式数据库系统中的数据进行变更的逻辑DDL指令,并将逻辑DDL指令转换为物理DDL指令。
如前所述,用户基于呈现的全局逻辑表发出DDL指令,即逻辑DDL指令,该指令需转换为实际分片节点可执行的物理DDL指令。
步骤S404:将物理DDL指令下发给对应的分片节点,以使分片节点执行物理DDL指令,并在物理DDL指令成功执行后,根据为本分片节点生成的分片节点模式快照与获得的全局逻辑模式快照的一致性关系,调整本分片节点汇入全局日志的日志数据,以使汇入全局日志的分片节点的日志数据与全局逻辑模式快照一致。
将物理DDL指令发送给相应的分片节点,可以使得分片节点能够接收指令进而正确执行;全局逻辑模式快照可存储在任意适当的节点或存储空间中,在需要时能够获取得到即可;基于分片节点的模式快照与全局逻辑模式快照比对的一致性关系,调整分片节点汇入全局日志的日志数据,以避免在某些分片节点尚未完成物理DDL指令的情况下,向消费全局日志的下游系统输出不一致的数据而导致的数据处理异常。
通过本实施例,引入了Schema快照即模式快照,以使各个分片节点在成功执行物理DDL指令后,在本分片节点生成模式快照,并将该模式快照与全局逻辑模式快照进行比对,在两者不一致时,调整分片节点汇入全局日志的的日志数据。通过将分片节点汇入全局日志的的日志数据调整与全局逻辑模式一致,则在所有分片节点未全部完成DDL操作时,仍以原全局逻辑模式为基准,而实际的分片节点仍在后台继续进行DDL操作,直至所有分片节点均完成该DDL操作并生成新的全局逻辑模式快照。由此,既无需对DML进行禁写或加锁,影响正常数据服务,也使得后台数据同步过程对用户透明,从而有效解决了分布式数据库系统在DDL变更过程中的多数据版本引发的数据处理异常问题。
实施例四
参照图6,示出了根据本申请实施例四的一种数据处理方法的步骤流程图。
本实施例的数据处理方法仍从分布式数据库系统中的中间件节点的角度进行说明,该数据处理方法包括以下步骤:
步骤S502:接收用于对分布式数据库系统中的数据进行变更的逻辑DDL指令,并将逻辑DDL指令转换为物理DDL指令;并且,根据逻辑DDL指令的类型,确定逻辑DDL指令的执行规则。
本实施例中,在接收到作用于全局逻辑表的逻辑DDL指令后,一方面将其转换为用于各个分片节点执行的物理DDL指令,另一方面,还会根据逻辑DDL指令的类型,确定逻辑DDL指令的执行规则。
本实施例中,将逻辑DDL指令根据其引发的Schema版本的变更划分为两种类型,包括新模式兼容旧模式类型,和旧模式兼容新模式类型。
具体地,设定某一时刻的Schema结构(包含表结构等)称为一个模式版本,逻辑DDL指令执行前的模式版本称为Vx,逻辑DDL指令执行后的模式版本称为Vy。则,逻辑DDL指令对应的模式版本间的兼容为:一个模式版本Va兼容Vb,当:
(1)Va中包含的Element(如列、索引等)的集合,是Vb中包含的Element集合的超集;
(2)对于相同的Element,Va中Element的长度或精度,大于Vb中相应Element的长度或精度。
基于此,将逻辑DDL指令的类型区分为:
(1)Vy兼容Vx的逻辑DDL类型(即新模式兼容旧模式的类型),该逻辑DDL指令指示的操作可以包括以下至少之一:
(A)增加数据列;
(B)数据列的长度变长,例如varchar(128)->varchar(1024);
(C)增加数据列的默认值;
(D)创建、删除索引;
(E)创建、删除数据约束,例如创建唯一键约束;
(F)创建新数据表;
(G)增加数据列的精度,例如double(10)->double(20)。
(2)Vx兼容Vy的逻辑DDL类型(即旧模式兼容新模式的类型),该逻辑DDL指令指示的操作可以包括以下至少之一:
(H)删除数据列;
(I)数据列的长度变短,例如varchar(1024)->varchar(128);
(J)删除数据表;
(K)减小数据列的精度,例如double(20)->double(10)。
根据上述设定,在一种可行方式中,本步骤可以实现为:根据逻辑DDL指令的类型,确定逻辑DDL指令的执行规则。
例如,若逻辑DDL指令的类型为新模式兼容旧模式的类型,则执行规则为:将物理DDL指令下发给分片节点;在所有分片节点成功执行物理DDL指令后生成用于指示逻辑DDL指令成功执行的DDL打标事件;在DDL打标事件后,再将新模式设置为对外可见。此种方式中,因逻辑DDL指令的类型为新模式兼容旧模式的类型,其更多涉及到数据列的增加、数据表的创建等操作,因此,在DDL打标事件完成后再使新模式对外可见,以避免在部分分片节点尚未完成物理DDL指令的情况下,即接收到用户针对新增加的数据列或新创建的数据表的操作,导致数据服务异常或中断,确定DDL指令的顺利执行。
又例如,若逻辑DDL指令的类型为旧模式兼容新模式的类型,则执行规则为:先将新模式设置为对外可见;再将物理DDL指令下发给分片节点;在所有分片节点成功执行物理DDL指令后生成用于指示逻辑DDL指令成功执行的DDL打标事件。此种方式中,因逻辑DDL指令的类型为旧模式兼容新模式的类型,其更多涉及到数据列的删除、数据表的删除等操作,因此,先使得新模式对外可见,以避免在部分分片节点已完成物理DDL指令的情况下,仍然接收到用户针对原模式中被删减掉的数据列或数据表的操作,导致数据服务异常或中断,确定DDL指令的顺利执行。
为不同的类型确定不同的执行规则既可保证DDL指令的顺利执行,还可有效避免因用户对逻辑库表执行数据处理而导致的数据服务中断或异常等问题。
步骤S504:将物理DDL指令下发给对应的分片节点,以使分片节点执行物理DDL指令,并在物理DDL指令成功执行后,根据为本分片节点生成的分片节点模式快照与获得的全局逻辑模式快照的一致性关系,调整本分片节点汇入全局日志的日志数据,以使汇入全局日志的分片节点的日志数据与全局逻辑模式快照一致。
如前所述,若逻辑DDL指令的类型为新模式兼容旧模式的类型,在转换为物理DDL指令后将下发物理DDL指令给相应的分片节点,以使分片节点执行相应的操作。而若逻辑DDL指令的类型为旧模式兼容新模式的类型,则会先将新模式对外可见,以使用户基于新模式进行操作,再将物理DDL指令下发给相应的分片节点,以使分片节点执行相应操作。
而在全局日志的生成过程中,会实时拉取汇总分片节点的日志数据,因此,若分片节点模式快照与获得的全局逻辑模式快照的不一致,则需调整本分片节点汇入全局日志的日志数据,以使汇入全局日志的分片节点的日志数据与全局逻辑模式快照一致。
步骤S506:接收各分片节点在成功执行物理DDL指令后生成的用于指示逻辑DDL指令成功执行的DDL打标事件。
分布式数据库系统中的各分片节点在成功执行物理DDL指令后,会被向其物理日志中插入一条DDL打标事件,其中通常包含有逻辑DDL指令的内容,该DDL打标事件可通过物理日志反馈并被全局日志使用。
此外,DDL打标事件通常具有分布式数据库系统的TSO的信息,指示DDL打标事件对应的时间点,且各分片节点的DDL打标事件的TSO相同。
步骤S508:创建与DDL打标事件对应的全局逻辑模式快照。
在一种可行方式中,可以根据各分片节点的日志数据中的DDL打标事件对应的TSO的信息,对各分片节点对应的DDL打标事件进行合并,根据合并结果生成全局日志中的逻辑DDL事件。
例如,DDL打标事件在各个shard中有相同的commit TSO,保证了各个物理Binlog队列中DDL处理的一致性。DDL打标事件在全局Binlog中会完成合并(例如,可以从描述相同DDL打标事件的物理DDL打标事件中随机选中一个,其它的舍弃掉),转化为一条代表逻辑DDL指令成功执行的逻辑DDL Event,该DDL Event的前后数据对应不同的Schema版本。
在全局Binlog中每收到一个逻辑DDL事件,即新增一个全局逻辑Schema的快照,以供下次DDL操作使用。
通过本实施例,引入了Schema快照即模式快照,以使各个分片节点在成功执行物理DDL指令后,为本分片节点生成模式快照,并将该模式快照与全局逻辑模式快照进行比对,在两者不一致时,调整分片节点汇入全局日志的日志数据。通过将分片节点汇入全局日志的日志数据调整与全局逻辑模式一致,则在所有分片节点未全部完成DDL操作时,仍以原全局逻辑模式为基准,而实际的分片节点仍在后台继续进行DDL操作及同步,直至所有分片节点均完成该DDL操作并生成新的全局逻辑模式快照。由此,既无需对DML进行禁写或加锁,影响正常数据服务,也使得后台数据同步过程对用户透明,用户对全局数据表的操作不会导致数据处理异常,从而有效解决了分布式数据库系统在DDL变更过程中的多数据版本引发的数据处理异常问题。
实施例五
再次参照图2所示的分布式数据库系统,本实施例将结合前述多个方法实施例中的描述,以一个具体示例的形式对本申请实施例涉及的分布式数据库系统进行说明。
如图2所示,该分布式数据库系统包括中间件节点和物理节点,每个物理节点上可存在有一个或多个分片节点。因此,也可认为该分布式数据库系统包括中间件节点和分片节点。
其中:中间件节点,用于接收用于对分布式数据库系统中的数据进行变更的逻辑DDL指令,并将逻辑DDL指令转换为物理DDL指令;将物理DDL指令下发给对应的分片节点;分片节点,用于执行物理DDL指令,并在成功执行物理DDL指令后,为本分片节点生成分片节点模式快照;若确定分片节点模式快照与分布式数据库系统的全局逻辑模式快照不一致,则将本分片节点汇入全局日志中的日志数据调整至与全局逻辑模式快照一致。
进一步可选地,中间件节点还用于在分片节点的日志数据中插入用于指示逻辑DDL指令成功执行对应的DDL打标事件;以及,根据各个分片节点的日志数据中的DDL打标事件生成逻辑DDL事件,并创建与逻辑DDL事件对应的全局逻辑模式快照。
以MYSQL-SHARDING类型的分布式数据库为示例,其会全局维护一个全局逻辑Schema的版本快照历史,在全局Binlog(逻辑Binlog,包含所有DN节点的Binlog,按照Binlog Event的commit TSO有序,保证事务的完整性和事务间的全局有序性)队列中每收到一个逻辑DDL事件,新增一个逻辑Schema快照版本。
每个shard自维护物理Schema的版本快照历史,在物理Binlog(分布式MYSQL-SHARDING场景下,每个MYSQL节点上的Binlog。例如,每个DN节点的Binlog)队列中每收到一个DDL事件,新增一个物理Schema快照版本。
在物理DDL指令成功执行后,对于由一条由DML操作生成的DML事件,基于该DML事件的时间,通过Schema快照历史可查询其对应的物理Schema和全局逻辑Schema的版本,当版本不一致时需要对该DML事件进行整形,将该DML事件的数据内容调整到和逻辑Schema快照一致的状态。例如,在增加数据列场景,物理Schema快照会比全局逻辑Schema快照多出一列,则需要对DML事件中的该列数据进行裁剪;在删除数据列场景中,物理Schema快照比全局逻辑Schema快照少一数据列,则需要对DML事件补加数据列。
在物理DDL指令被成功执行后,会在每个shard对应的Binlog中都会插入一条相同的事件数据,该事件数据中包含逻辑DDL SQL(即逻辑DDL指令)的内容,该操作即被定义为DDL打标事件。打标事件在各个shard中有相同的commit TSO,保证了各个物理Binlog队列中DDL处理的一致性。DDL打标事件在全局Binlog中会完成合并,转化为一条逻辑DDL事件,以指示逻辑DDL指令执行成功,该逻辑DDL事件的前后数据对应不同的Schema版本。
此外,在具体执行过程中,中间件节点会针对不同的逻辑DDL指令类型使用不同的执行规则。例如,对于一条逻辑DDL指令,如果其为Vy版本兼容Vx版本的类型,则处理顺序为: 执行物理DDL指令-> 逻辑DDL打标 ->Vy版本对外可见;而对于一条逻辑DDL指令,如果其为Vx版本兼容Vy版本的类型,则处理顺序为: Vy版本对外可见-> 执行物理DDL指令 ->逻辑DDL打标。
通过本实施例的分布式数据库系统,引入Schema版本快照,并基于Schema快照历史对不同版本的物理Binlog数据进行整形,无需禁写或加锁,解决了分布式数据库场景下DDL变更过程中的多数据版本问题。并且,巧妙利用了分布式事件在各个分片拥有相同Commit TSO的特性,以DDL打标事件的方式构造逻辑DDL事件,解决了各个分片的物理DDL之间不一致的问题,提供了一致性的DDL复制能力。
实施例六
参照图7,示出了根据本申请实施例六的一种电子设备的结构示意图,本申请具体实施例并不对电子设备的具体实现做限定。
如图7所示,该电子设备可以包括:处理器(processor)702、通信接口(Communications Interface)704、存储器(memory)706、以及通信总线708。
其中:
处理器702、通信接口704、以及存储器706通过通信总线708完成相互间的通信。
通信接口704,用于与分布式数据库系统中的其它电子设备进行通信。
处理器702,用于执行程序710,具体可以执行上述数据处理方法实施例中的相关步骤。
具体地,程序710可以包括程序代码,该程序代码包括计算机操作指令。
处理器702可能是处理器CPU,或者是特定集成电路ASIC(Application SpecificIntegrated Circuit),或者是被配置成实施本申请实施例的一个或多个集成电路。智能设备包括的一个或多个处理器,可以是同一类型的处理器,如一个或多个CPU;也可以是不同类型的处理器,如一个或多个CPU以及一个或多个ASIC。
存储器706,用于存放程序710。存储器706可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。
程序710具体可以用于使得处理器702执行前述多个方法实施例中任一所描述的数据处理方法。
程序710中各步骤的具体实现可以参见上述数据处理方法实施例中的相应步骤和单元中对应的描述,在此不赘述。所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的设备和模块的具体工作过程,可以参考前述方法实施例中的对应过程描述,并具有相对应的有益效果,在此不再赘述。
本申请实施例还提供了一种计算机程序产品,包括计算机指令,该计算机指令指示计算设备执行上述多个方法实施例中的任一数据处理方法对应的操作。
本申请实施例提供的数据处理方案可广泛应用于多种场合,以对各种应用进行支撑。例如,对于大型的企业级应用或互联网系统应用,为了应对大流量、高并发和海量数据存储场景,通常会引入分布式数据存储方案,如引入分库分表中间件或直接部署分布式NewSQL数据库。与此同时,这些企业通常也会构建自己的DataPipeline,用来实现数据的分发订阅,以支持各种类型的业务场景,如将OLTP数据库中的数据实时同步到搜索引擎ElasticSearch。在强调敏捷开发、快速迭代的时代,对库表进行高频的DDL操作是一个非常普遍的现象,同时实现DDL在Pipeline中的自动复制也是一个比较刚性的需求(如Mysql增加新数据列,Pipeline可以自动同步给ElasticSearch增加新数据列),但在引入了分布式数据存储方案后,由于不同存储节点的DDL操作无法做到原子性,目前业界很多分布式NewSQL数据库并不具备对外输出一致性DDL事件的能力,一般只能牺牲DDL订阅能力或直接对外输出每个存储节点的DDL,但这会引发数据版本不一致的问题,而本申请实施例的方案则可有效避免上述问题,为各种互联网应用或企业级应用提供数据服务支撑。
需要指出,根据实施的需要,可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤,也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤,以实现本申请实施例的目的。
上述根据本申请实施例的方法可在硬件、固件中实现,或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码,或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码,从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解,计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如,RAM、ROM、闪存等),当所述软件或计算机代码被计算机、处理器或硬件访问且执行时,实现在此描述的数据处理方法。此外,当通用计算机访问用于实现在此示出的数据处理方法的代码时,代码的执行将通用计算机转换为用于执行在此示出的数据处理方法的专用计算机。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及方法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请实施例的范围。
以上实施方式仅用于说明本申请实施例,而并非对本申请实施例的限制,有关技术领域的普通技术人员,在不脱离本申请实施例的精神和范围的情况下,还可以做出各种变化和变型,因此所有等同的技术方案也属于本申请实施例的范畴,本申请实施例的专利保护范围应由权利要求限定。