具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述。显然,所描述的实施例仅仅是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先对本申请实施例中涉及的相关名词做以下解释:
引擎文件:存放数据库数据记录的文件。不同的存储引擎有不同的引擎文件格式,例如TcaplusDB数据库中的TXHDB存储引擎,其引擎文件是以.txh为后缀的文件,而MySQL数据库中的InnoDB存储引擎,其引擎文件是以.ibd为后缀的文件。
空洞:删除数据记录所导致引擎文件中的空间碎片。
存储节点:数据库集群中用于对数据库中数据进行处理的设备,例如在TcaplusDB数据库架构中,Tcapsvr即为存储节点。通常存储节点可以有主存储节点(master)和从存储节点(slave)之分,主存储节点用于存储数据以及响应控制节点请求,备份节点用于实时备份主存储节点所存储的数据,且在主存储节点发生故障时,升级作为主存储节点。
控制节点:管理数据库集群中各个存储节点以及处理来自网页页面等客户端请求的设备,例如在TcaplusDB数据库架构中,Tcapcenter即为控制节点。
哈希桶:存放不同关键值(key)链表的容器。
云技术(Cloud technology):是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术。云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用,将来每个物品都有可能存在自己的识别标志,都需要传输到后台系统进行逻辑处理,不同程度级别的数据将会分开处理,各类行业数据皆需要强大的系统后盾支撑,只能通过云计算来实现。
数据库(Database):简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。
请参阅图1,其示出了本申请实施例提供的一种数据库引擎文件处理系统的架构示意图,如图1所示,该系统可以包括客户端101、控制节点102以及一个或多个(图中采用103a、103b,……,103n来示出)存储节点103。
具体地,客户端01可以是智能手机、台式电脑、平板电脑、笔记本电脑、数字助理、智能可穿戴设备、监控设备及语音交互设备等类型的设备,也可以是运行于设备中的软体,例如一些服务商提供给用户的网页页面,也可以为该些服务商提供给用户的应用。具体的,客户端01可以用于提交引擎文件处理请求至控制节点102。
控制节点102可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。客户端01以及控制节点102可以通过有线或无线通信方式进行直接或间接地连接,本申请在此不做限制。
控制节点102可以包括有网络通信单元、处理器和存储器等等,控制节点102与每个存储节点103之间均建立有连接。控制节点102在接收到引擎文件处理请求后,向该引擎文件处理请求对应的存储节点103下发文件处理指令,然后由该存储节点103进行待处理数据表的引擎文件中空洞的处理,并且实时将处理进度反馈至控制节点102,直至在线处理完成。
在其他实施例中,上述客户端、控制节点或者存储节点可以是一个分布式系统中的一个节点,该分布式系统可以为区块链系统,该区块链系统可以是由该多个节点通过网络通信的形式连接形成的分布式系统。其中,节点之间可以组成点对点(Peer To Peer,简称P2P)网络,任意形式的计算设备,比如服务器、终端等电子设备都可以通过加入该点对点网络而成为该区块链系统中的一个节点。
现有采用离线处理的方式,存储节点103在消除待处理引擎文件中空洞时,需要先停止存储节点103服务,致使数据库存在单点故障问题。鉴于此,本申请实施例提供了一种数据库引擎文件处理方法。需要说明的是,本申请提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的系统或服务器产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。
以下以上述系统为执行主体介绍本申请的一种数据库引擎文件处理方法。请参阅图2,其示出了本申请实施例提供的一种数据库引擎文件处理方法的时序图。如图2所示,该方法可以包括:
S201,客户端向控制节点发送引擎文件处理请求。
本申请实施例中,引擎文件处理请求表征对引擎文件中空洞进行在线处理的请求,用于指示控制节点向相应的存储节点发送文件处理指令,以使存储节点消除引擎文件中的空洞。
在一个示例中,如图3所示,其示出了引擎文件在线处理的运维页面的界面示意图。用户可以通过运维页面上处理节点选项选择是在master存储节点或者在slave存储节点上进行引擎文件的处理,并选择需要消除空洞的引擎文件对应的数据库表,以及选择是否删除备份文件即处理过程中的临时性文件,用户可以点击提交按钮发起引擎文件处理请求。在具体实施时,对于采用一主多从的存储模式而言,可能出现多个slave存储节点,用户可以在运维页面选择是在哪个slave存储节点上进行引擎文件的处理。
S203,控制节点接收引擎文件处理请求,获取引擎文件处理请求中的存储节点类型标识和待处理数据表标识。
待处理数据表标识用于对数据表进行唯一标识,可以是数据表的表名或者序列号等等。存储节点类型标识表征进行引擎文件处理的存储节点的类型,存储节点类型标识的设置与数据库的存储模式有关。例如,对于一主一从的存储模式而言,存储节点类型标识可以是master(主)类型或slave(从)类型,若存储节点类型标识为master类型,则处理主存储节点上的引擎文件,若存储节点类型标识为slave类型,则处理从存储节点上的引擎文件。而对于一主二从的存储模式而言,假设有第一从存储节点和第二从存储节点之分,则存储节点类型标识可以是master类型、slave1类型或slave2类型。其中,master类型表征主存储节点的类型,slave1类型表征第一从存储节点的类型,slave2类型表征第二从存储节点的类型。
S205,控制节点根据存储节点类型标识和待处理数据表标识,确定待处理数据表和存储节点。
待处理数据表即为待处理数据表标识对应的数据表,控制节点可以根据存储节点类型,确定是处理哪种类型存储节点上的引擎文件。可选的,存储节点可能包含有多个。
S207,控制节点发送用于消除待处理数据表的引擎文件中空洞的文件处理指令至每个存储节点。
S209,存储节点响应于文件处理指令,将待处理数据表的引擎文件确定为待处理引擎文件,生成与待处理引擎文件对应的第一引擎文件和第二引擎文件。
S211,存储节点使用第一引擎文件处理对待处理数据表的读写操作。
在对待处理引擎文件进行处理的过程中,若有对待处理数据表中数据记录的增删改查等读写操作,均通过第一引擎文件进行处理,而待处理引擎文件作为一个只读的文件。换言之,待处理引擎文件是当前待处理数据表的一份快照,而第一引擎文件作为实际对数据记录进行处理的引擎文件,所有由待处理引擎文件实施的读写操作均改为由第一引擎文件实施。
S213,存储节点将待处理引擎文件中的每条有效的第一数据记录写入至第二引擎文件中。
存储节点遍历待处理引擎文件中的每条第一数据记录,在判定该第一数据记录为有效记录的记录下,将该第一数据记录写入至第二引擎文件中。因此,第二引擎文件中的每条第一数据记录均是有效记录,从而将待处理引擎文件中的空洞进行了清除。
S215,存储节点将第一引擎文件中的各条第二数据记录合并至第二引擎文件中,并将合并后的第二引擎文件设置为待处理数据表的引擎文件。
第一引擎文件中的第二数据记录可能是在处理过程中新插入的,或者是对待处理引擎文件中的第一数据记录进行删除的或者修改的,通过将第一引擎文件中的各条第二数据记录合并至第二引擎文件中,使得合并后的第二引擎文件中具有当前待处理数据表的完整的数据记录,且消除了待处理引擎文件中的空洞。
由上述实施例提供的技术方案可见,存储节点在清除待处理引擎文件中的空洞时,通过为待处理引擎文件生成对应的第一引擎文件和第二引擎文件,使用第一引擎文件处理对待处理数据表的读写操作,使用第二引擎文件存储待处理引擎文件中的有效数据记录,然后将第一引擎文件和第二引擎文件进行合并的方式,使得无需停止存储节点服务,避免了数据库的单点故障问题的发生;通过使用所生成的第一引擎文件继续处理对待处理数据表的读写操作,使得在第数据库引擎文件中空洞的在线处理过程中,不影响业务请求的正常响应,避免了业务数据的丢失。
以下以上述系统中的存储节点为执行主体介绍本申请的一种数据库引擎文件处理方法。请参阅图4,其示出了本申请实施例提供的一种数据库引擎文件处理方法的流程示意图。如图4所示,该方法可以包括:
S401,响应于用于消除待处理数据表的引擎文件中空洞的文件处理指令,将待处理数据表的引擎文件确定为待处理引擎文件,生成与待处理引擎文件对应的第一引擎文件和第二引擎文件。
存储节点在对待处理引擎文件进行在线处理时,会为每个待处理数据表生成两个引擎文件即第一引擎文件和第二引擎文件,通过这两个引擎文件实现待处理引擎文件中空洞的清除。
S403,使用第一引擎文件处理对待处理数据表的读写操作。
存储节点将第一引擎文件作为待处理数据表的临时的引擎文件,用于在对待处理引擎文件的处理过程中进行对待处理数据表中数据的处理。换言之,在在对待处理引擎文件的处理过程中,若存储节点在接收到针对待处理数据表的读写操作后,使用第一引擎文件进行第一数据记录的读写。可选的,为了防止在处理过程中对待处理引擎文件进行写入操作,妨碍处理进程,可以将待处理引擎文件设置为只读,禁止对待处理引擎文件进行写入。
在一个可能的实施方式中,步骤S403在实施时可以包括:响应于用于插入新数据记录的插入操作,将新数据记录确定为第二数据记录,将第二数据记录的标记设置为用于指示第二数据记录是新插入的数据记录的值后,例如新插入,将第二数据记录直接写入至第一引擎文件中。其中,第二数据记录表征第一引擎文件中的数据记录。
在一个可能的实施方式中,在需要查询数据记录时,先查询第一引擎文件,若未查询到,再从待处理引擎文件中查询。因此,步骤S403在实施时还可以包括:响应于用于查询目标关键值对应第二数据记录的查询操作,从第一引擎文件中匹配与目标关键值相同的第二数据记录;若匹配上,则将所匹配到的第二数据记录返回至发送查询操作的请求方;若未匹配上,则从待处理引擎文件中匹配与目标关键值相同的第一数据记录;若匹配上,则将所匹配到的第一数据记录返回至发送查询操作的请求方;若未匹配上,则返回用于指示数据记录不存在的结果消息至请求方。
在一个可能的实施方式中,在修改数据记录时,先查询第一引擎文件,若查询到则直接修改所查询到的数据记录,若未查询到则再从待处理引擎文件中查询,并将查询到的数据记录修改后存储至第一引擎文件中。因此,步骤S403在实施时还可以包括:响应于用于修改目标关键值对应第二数据记录的修改操作,从第一引擎文件中匹配与目标关键值相同的第二数据记录;若匹配上,则根据修改操作对所匹配到的第二数据记录进行修改,并将修改后的第二数据记录的标记设置为用于指示第二数据记录是已修改的数据记录的值,例如已修改;若未匹配上,则从待处理引擎文件中匹配与目标关键值相同的第一数据记录;若匹配上,则根据修改操作对所匹配到的第一数据记录进行修改,将修改后的第一数据记录确定为第二数据记录,再将第二数据记录的标记设置为用于指示第二数据记录是已修改的数据记录的值后,将第二数据记录写入至第一引擎文件中;则返回用于指示数据记录不存在的结果消息至发送修改操作的请求方。
在一个可能的实施方式中,在删除数据记录时,先查询第一引擎文件,若查询到则将所查询到的数据记录进行标记,若未查询到则再从待处理引擎文件中查询,并将查询到的数据记录进行标记后存入至第一引擎文件中。因此,步骤S403在实施时还可以包括:响应于用于删除目标关键值对应第二数据记录的删除操作,从第一引擎文件中匹配与目标关键值相同的第二数据记录;若匹配上,则将所匹配到的第二数据记录的标记设置为指示第二数据记录是待删除的数据记录的值,例如待删除;若未匹配上,则从待处理引擎文件中匹配与目标关键值相同的第一数据记录;若匹配上,则将所匹配上的第一数据记录确定为第二数据记录;将第二数据记录的标记设置为指示第二数据记录是待删除的数据记录的值后,将第二数据记录写入至第一引擎文件中;若未匹配上,则返回用于指示数据记录不存在的结果消息至发送删除操作的请求方。
在一个示例中,如图5所示,其示出了存储节点使用第一引擎文件处理读写操作的示意图。存储节点在接收到数据记录操作后,由第一引擎文件进行相应的增删改查操作,并将每条数据记录进行标记。如图中新增的Data5被标记为新插入,对Data4修改后的数据将被标记为已修改。
S405,遍历待处理引擎文件中的每条第一数据记录,确定第一数据记录是否为有效记录;在第一数据记录为有效记录的情况下,将第一数据记录写入至第二引擎文件中。
本申请实施例中,第一数据记录表征待处理引擎文件中预先包含的数据记录。对于引擎文件中所包含的数据记录,存储节点仅将有效的数据记录写入至第二引擎文件中,使得第二引擎文件中的数据记录存储更加紧凑,减少了空洞的存在。可选的,在同一个引擎文件中的数据记录具有相同的预设存储格式,数据记录在存储时均会按照预设存储格式进行存储,因而存储节点在确定第一数据记录是否为有效记录时,可以基于第一数据记录的预设存储格式进行判定。
在一个可能的实施方式中,如图6所示,步骤S405在具体实施时可以包括:
S4051,遍历待处理引擎文件中的每条第一数据记录,获取第一数据记录中的头部数据;根据头部数据中的校验标识符确定第一数据记录是否为有效记录,校验标识符是第一数据记录在存储时设置的;在第一数据记录为有效记录的情况下,将第一数据记录写入至第二引擎文件中。
本申请实施例中,预设存储格式可以是具有头部数据的存储格式,也即每个第一数据记录均至少包含头部数据和数据内容两部分,头部数据用于存储第一数据记录的标识信息,数据内容为第一数据记录的真实数据。其中,标识信息用于对第一数据记录进行识别,校验标识符即为标识信息中的一种。
在一个示例中,如图7所示,其示出了遍历待处理引擎文件的示例图。存储节点遍历读取待处理引擎文件中的每条第一数据记录(图中采用Data1以及Data2等来示出),每条第一数据记录均包含头部数据和数据内容,头部数据中包含有Magic(魔数值)、Version(版本号)、CRC(循环冗余校验值)以及Size(数据记录大小)等各种标识信息,存储节点可以将上述标识信息中的至少之一作为校验标识符,以检测第一数据记录是否为有效记录。
在一个可能的实施方式中,若将第一数据记录中的魔数值作为初始魔数值,将第一数据记录中的循环冗余校验值作为初始循环冗余校验值,使用初始魔数值和初始循环冗余校验值作为校验标识符,则如图8所示,步骤S4051中根据头部数据中的校验标识符确定第一数据记录是否为有效记录,在具体实施时可以包括:
S40511,确定初始魔数值与预设魔数值是否一致。
待处理引擎文件中所有第一数据记录具有相同的初始魔数值,存储节点在对第一数据记录进行存储时,将预设魔数值作为第一数据记录的初始魔数值存储至Magic字段中。其中,预设魔数值可以根据业务进行设定和调整,在此不做具体限定。
若初始魔数值与预设魔数值一致,则实施步骤S40513进一步确定第一数据记录的有效性;若初始魔数值与预设魔数值不一致,则认为第一数据记录是空洞,实施步骤S40519。
S40513,计算第一数据记录对应的新循环冗余校验值。
存储节点可以重新计算第一数据记录中数据内容对应二进制的CRC值(循环冗余校验值),得到新循环冗余校验值。
S40515,检测新循环冗余校验值与初始循环冗余校验值是否一致。
初始循环冗余校验值是第一数据记录在存储时进行计算得到的,存储节点按照相同的计算方式计算得到新CRC值,然后将新CRC值与存储时的CRC值进行比较;若不一致,则实施步骤S40519;若一致,则实施步骤S40517。
S40517,判定第一数据记录是有效记录。
S40519,判定第一数据记录不是有效记录。
通过有效记录的判定,可以将待处理引擎文件中的空洞清除。如图7中,第二引擎文件中仅存储有待处理引擎文件中有效的数据记录Data1、Data2、Data4以及Data5,而第二引擎文件中不再出现空洞。
S407,将第一引擎文件中的各条第二数据记录合并至第二引擎文件中。
如前述步骤S403所述,第一引擎文件中的各条数据记录在存储时均设置有相应的标记,存储节点使用标记来指示第二数据记录的状态,因而可以遍历第一引擎文件中的每条第二数据记录,根据第二数据记录的标记将第二数据记录合并至第二引擎文件中。
在一个可能的实施方式中,如图9所示,步骤S407在具体实施时可以包括:
S4071,对于第一引擎文件中的每条第二数据记录,获取第二数据记录的标记和第一关键值,标记是在第二数据记录存储时设置的,第一关键值用于对第二数据记录进行唯一标识;
S4073,若标记指示第二数据记录是新插入的数据记录,则将第二数据记录写入至第二引擎文件中;
S4075,若标记指示第二数据记录是已修改的数据记录,则从第二引擎文件中将第二关键值与第一关键值相同的第一数据记录替换为第二数据记录,第二关键值用于对第一数据记录进行唯一标识;
S4077,若标记指示第二数据记录是待删除的数据记录,则从第二引擎文件中将第二关键值与第一关键值相同的第一数据记录删除。
存储节点利用第二数据记录的标记,来确定将第二数据记录是直接写入至第二引擎文件中,或替换第二引擎文件中的数据记录,或删除第二引擎文件中的数据。在一个示例中,如图10所示,其示出了将第一引擎文件中第二数据记录合并至第二引擎文件中的示例图。将第一引擎文件中的数据记录合并至第二引擎文件中后,合并后的第二引擎文件中具有当前待处理数据表的完整的数据记录,且消除了待处理引擎文件中的空洞。
在实际应用中,在对第一引擎文件和第二引擎文件中的数据记录进行合并的过程中,用户仍可以通过客户端对待处理数据表进行增删改查操作,致使第一引擎文件中的第二数据记录会不断的更新。但这种增删改查操作并不是持续不断的,存储节点可以根据第一引擎文件中的第二数据记录的数量来确定是否暂停外部数据访问,以实现对引擎文件合并流程的终止。
基于以上描述,在一个可能的实施方式中,存储节点在将第一引擎文件中的各条第二数据记录合并至第二引擎文件中的过程中,还可以检测第一引擎文件中的第二数据记录的总数量是否小于预设临界值时,若小于预设临界值,则暂停使用第一引擎文件处理待处理数据表的读写操作。其中,预设临界值可以根据业务场景进行设置,本申请不做具体限定。
S409,将合并后的第二引擎文件设置为待处理数据表的引擎文件。
存储节点在将合并后的第二引擎文件设置为待处理数据表的引擎文件后,由于第一引擎文件是临时的引擎文件,可以将第一引擎文件进行删除,以防止存储节点上过多的冗余文件存在,影响存储节点的处理效率。在一些实施方式中,存储节点还可以每间隔一段时间,将消除待处理数据表的引擎文件中空洞的处理进展反馈至控制节点,以使控制节点将该处理进展通过客户端展现给用户,提升用户体验。
由上述实施例提供的技术方案可见,存储节点在清除待处理引擎文件中的空洞时,通过为待处理引擎文件生成对应的第一引擎文件和第二引擎文件,使用第一引擎文件处理对待处理数据表的读写操作,使用第二引擎文件存储待处理引擎文件中的有效数据记录,然后将第一引擎文件和第二引擎文件进行合并的方式,使得无需停止存储节点服务,避免了数据库的单点故障问题的发生;通过使用所生成的第一引擎文件继续处理对待处理数据表的读写操作,使得在第数据库引擎文件中空洞的在线处理过程中,不影响业务请求的正常响应,避免了业务数据的丢失。
在一些实施例中,数据库中数据记录的查找是通过哈希表进行的,每条数据记录的哈希值表征数据记录在哈希表中的存储位置。在写入数据记录时,需要对该哈希表进行维护。
具体地,存储节点通过数据记录的关键值即key字段计算该数据记录的哈希值,通过该哈希值确定存放key字段对应记录的目标哈希桶,如果目标哈希桶下已有记录(也称发生冲突),则以链表的方式挂在已有记录的后方,形成数据链表。在查找数据记录时,也是通过该数据记录的key字段计算在哪个哈希桶下,然后根据key字段遍历哈希桶下的数据链表找到该数据记录。因此,哈希桶下数据链表越长,查找的次数越多。为了减小哈希桶下数据链表的长度,提升数据记录查找的效率,存储节点在遍历待处理引擎文件之前,还可以对哈希桶数量进行调整。其中,数据记录的哈希值可以通过数据记录的key字段与哈希桶数量进行取模运算得到,哈希桶数量可以在待处理引擎文件的头部中获取得到。
鉴于此,在一个可能的实施方式中,如图11所示,在步骤S405实施之前,该数据库引擎文件处理方法还可以包括:
S4041,获取待处理引擎文件的初始哈希桶配置;
S4043,根据初始哈希桶配置中各个初始哈希桶对应数据链表的长度,确定目标哈希桶数量;
S4045,根据目标哈希桶数量创建目标哈希桶配置;
S4047,将目标哈希桶配置确定为第二引擎文件的哈希桶配置。
初始哈希桶配置包括每个哈希桶下数据链表信息,数据链表信息至少包括数据链表的长度。哈希桶下数据链表越长,查询效率越低。可选的,存储节点可以基于初始哈希桶对应数据链表的长度中的最大值,确定目标哈希桶数量。
在一个可能的实施方式中,如图12所示,步骤S4043在具体实施时可以包括:
S40431,基于初始哈希桶配置中各个初始哈希桶对应数据链表的长度,从所有长度中选取最大值,以作为最大链表长度;
S40433,获取初始哈希桶配置中初始哈希桶的数量;
S40435,若最大链表长度超过预设长度阈值,则将预设倍数与初始哈希桶的数量之间的乘积,确定为目标哈希桶数量;
S40437,若最大链表长度未超过预设长度阈值,则将初始哈希桶的数量,确定为目标哈希桶数量。
最大链表长度指示了冲突链表的最大长度,若最大链表长度超过预设长度阈值,则重新调整哈希桶的数量,将哈希桶数量翻倍;若最大链表长度未超过预设长度阈值,则使用原来哈希桶的数量。在一个示例中,若初始哈希桶的数量为N,预设倍数为M,若最大链表长度超过预设长度阈值,则将哈希桶数量翻倍,也即将M与N的乘积确定为目标哈希桶数量;若最大链表长度未超过预设长度阈值,则将初始哈希桶的数量作为目标哈希桶数量,也即将N确定为目标哈希桶数量。其中,预设倍数为大于或等于2的整数,而预设长度阈值可以根据实际应用场景进行设置,在此不做具体限定。
存储节点在将目标哈希桶配置确定为第二引擎文件的哈希桶配置后,在每次向第二引擎文件中写入数据记录时,均将重新计算每条数据记录所属的哈希桶。例如,假设目标哈希桶数量为200,则在向第二引擎文件中写入数据记录时,将该数据记录的key字段与200进行取模运算,所确定的哈希值指示存储该数据记录的位置信息。
在一个示例中,如图13所示,其示出了哈希桶调整的一个示例图。在调整前的初始哈希桶配置中包括了4个Bucket(哈希桶),在各哈希桶下数据链表的长度中的最大值超过预设长度阈值,则将目标哈希桶数量设置为2*4=8。那么在第二引擎文件中写入数据记录时,目标哈希桶配置中各个哈希桶下数据链表也将发生变化,由于目标哈希桶配置具有目标哈希桶数量的哈希桶,冲突数据链表的长度减少了,从而提高了数据记录的查找效率。
以下以上述系统中的控制节点为执行主体介绍本申请的一种数据库引擎文件处理方法。请参阅图14,其示出了本申请实施例提供的另一种数据库引擎文件处理方法的流程示意图。如图14所示,该方法可以包括:
S1401,接收引擎文件处理请求,获取引擎文件处理请求中的存储节点类型标识和待处理数据表标识;
S1403,将待处理数据表标识对应的数据表,确定为待处理数据表;
S1405,根据存储节点类型标识和待处理数据表标识,确定至少一个存储节点;
S1407,向每个存储节点发送用于消除待处理数据表的引擎文件中空洞的文件处理指令,以使存储节点对待处理数据表的引擎文件进行在线处理。
本申请实施例中,对待处理数据表的引擎文件进行在线处理也即:响应于用于消除待处理数据表的引擎文件中空洞的文件处理指令,将待处理数据表的引擎文件确定为待处理引擎文件,生成与待处理引擎文件对应的第一引擎文件和第二引擎文件;使用第一引擎文件处理对待处理数据表的读写操作;遍历待处理引擎文件中的每条第一数据记录,确定第一数据记录是否为有效记录;在第一数据记录为有效记录的情况下,将第一数据记录写入至第二引擎文件中;将第一引擎文件中的各条第二数据记录合并至第二引擎文件中;将合并后的第二引擎文件设置为待处理数据表的引擎文件。对于存储节点进行在线处理的详细内容,可参见上述骤S401至步骤S409中的内容,在此不再赘述。
在实际应用中,为了减少数据库的负担,提高数据表的增删改查效率,通常采用分片的方式实现将同一张数据表中的数据存储在不同位置。在同一个数据库中,不同数据表可以采用分片或非分片的方式。对于采用非分片的数据表,其数据存储在相同位置,则可以使用一个存储节点实施;而对于采用分片的数据表,其数据存储在不同位置,需要使用多个存储节点实施。
控制节点中记录有每个数据表是分片的数据表还是非分片的数据表,对于非分片的数据表,控制节点还记录有该非分片的数据表对应的存储节点;对于分片的数据表,控制节点还记录有该分片的数据表有哪些分片,以及这些分片分布在哪些存储节点上。
基于此,在一个可能的实施方式中,如图15所示,步骤S1405在具体实施时可以包括:
S14051,根据待处理数据表标识,获取待处理数据表的分片分布信息,分片分布信息表征每个分片所分布的存储节点;
S14053,获取存储节点类型标识对应的存储节点;
S14055,从存储节点类型标识对应的存储节点中选择与分片分布信息匹配的存储节点,得到至少一个存储节点。
分片分布信息中包括待处理数据表的每个分片分布在哪个存储节点上,控制节点根据存储节点类型标识确定所有主存储节点或所有从存储节点,然后将分片所分布的存储节点与所有主存储节点或所有从存储节点进行匹配,即可确定由哪些存储节点实施对待处理数据表的引擎文件中空洞的在线处理的操作。
由上述实施例提供的技术方案可见,存储节点在清除待处理引擎文件中的空洞时,通过为待处理引擎文件生成对应的第一引擎文件和第二引擎文件,使用第一引擎文件处理对待处理数据表的读写操作,使用第二引擎文件存储待处理引擎文件中的有效数据记录,然后将第一引擎文件和第二引擎文件进行合并的方式,使得无需停止存储节点服务,避免了数据库的单点故障问题的发生;通过使用所生成的第一引擎文件继续处理对待处理数据表的读写操作,使得在第数据库引擎文件中空洞的在线处理过程中,不影响业务请求的正常响应,避免了业务数据的丢失。
需要说明的是,本申请提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。上述方法实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的系统或服务器产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。
本申请实施例还提供了一种数据库引擎文件处理装置,请参阅图16,其示出了一种数据库引擎文件处理装置的框图,该装置具有实现上述存储节点侧的方法实施例的功能。该装置1600可以包括:
指令接收模块1610,用于响应于用于消除待处理数据表的引擎文件中空洞的文件处理指令,将待处理数据表的引擎文件确定为待处理引擎文件,生成与待处理引擎文件对应的第一引擎文件和第二引擎文件;
第一引擎文件设置模块1620,用于使用第一引擎文件处理对待处理数据表的读写操作;
数据记录处理模块1630,用于遍历待处理引擎文件中的每条第一数据记录,确定第一数据记录是否为有效记录;在第一数据记录为有效记录的情况下,将第一数据记录写入至第二引擎文件中;
引擎文件合并模块1640,用于将第一引擎文件中的各条第二数据记录合并至第二引擎文件中;
第二引擎文件设置模块1650,用于将合并后的第二引擎文件设置为待处理数据表的引擎文件。
在一个可能的实施方式中,引擎文件合并模块1640可以包括:
标记获取单元,用于对于第一引擎文件中的每条第二数据记录,获取第二数据记录的标记和第一关键值,标记是在第二数据记录存储时设置的,第一关键值用于对第二数据记录进行唯一标识;
新插入数据处理单元,用于在标记指示第二数据记录是新插入的数据记录的情况下,将第二数据记录写入至第二引擎文件中;
已修改数据处理单元,用于在标记指示第二数据记录是已修改的数据记录的情况下,从第二引擎文件中将第二关键值与第一关键值相同的第一数据记录替换为第二数据记录,第二关键值用于对第一数据记录进行唯一标识;
待删除数据处理单元,用于在标记指示第二数据记录是待删除的数据记录的情况下,从第二引擎文件中将第二关键值与第一关键值相同的第一数据记录删除。
在一个可能的实施方式中,该装置1600还可以包括哈希桶调整模块,哈希桶调整模块用于对哈希桶配置进行调整。具体地,哈希桶调整模块可以包括:
初始配置获取单元,用于获取待处理引擎文件的初始哈希桶配置;
哈希桶数量确定单元,用于根据初始哈希桶配置中各个初始哈希桶对应数据链表的长度,确定目标哈希桶数量;
哈希桶配置创建单元,用于根据目标哈希桶数量创建目标哈希桶配置;
哈希桶配置设置单元,用于将目标哈希桶配置确定为第二引擎文件的哈希桶配置。
在一个可能的实施方式中,哈希桶数量确定单元可以包括:
最大长度确定单元,用于基于初始哈希桶配置中各个初始哈希桶对应数据链表的长度,从所有长度中选取最大值,以作为最大链表长度;
初始数量确定单元,用于获取初始哈希桶配置中初始哈希桶的数量;
第一数量确定单元,用于在最大链表长度超过预设长度阈值的情况下,将预设倍数与初始哈希桶的数量之间的乘积,确定为目标哈希桶数量;
第二数量确定单元,用于在最大链表长度未超过预设长度阈值的情况下,将初始哈希桶的数量,确定为目标哈希桶数量。
在一个可能的实施方式中,数据记录处理模块1630可以包括:
头部数据获取单元,用于遍历待处理引擎文件中的每条第一数据记录,获取第一数据记录中的头部数据;
有效记录校验单元,用于根据头部数据中的校验标识符确定第一数据记录是否为有效记录,校验标识符是第一数据记录在存储时设置的。
在一个可能的实施方式中,校验标识符包括初始魔数值和初始循环冗余校验值,有效记录校验单元可以包括:
第一判断单元,用于确定初始魔数值与预设魔数值是否一致;
第一结果处理单元,用于在初始魔数值与预设魔数值不一致的情况下,判定第一数据记录不是有效记录;
冗余校验值计算单元,用于在初始魔数值与预设魔数值一致的情况下,计算第一数据记录对应的新循环冗余校验值;
第二判断单元,用于检测新循环冗余校验值与初始循环冗余校验值是否一致;
第二结果处理单元,用于在新循环冗余校验值与初始循环冗余校验值一致的情况下,判定第一数据记录是有效记录;
第三结果处理单元,用于在新循环冗余校验值与初始循环冗余校验值不一致的情况下,判定第一数据记录不是有效记录。
本申请实施例还提供了一种数据库引擎文件处理装置,请参阅图17,其示出了另一种数据库引擎文件处理装置的框图,该装置具有实现上述控制节点侧的方法实施例的功能。该装置1700可以包括:
请求接收模块1710,用于接收引擎文件处理请求,获取引擎文件处理请求中的存储节点类型标识和待处理数据表标识;
数据表确定模块1720,用于将待处理数据表标识对应的数据表,确定为待处理数据表;
存储节点确定模块1730,用于根据存储节点类型标识和待处理数据表标识,确定至少一个存储节点;
指令发送模块1740,用于向每个存储节点发送用于消除待处理数据表的引擎文件中空洞的文件处理指令,以使存储节点将待处理数据表的引擎文件确定为待处理引擎文件,生成与待处理引擎文件对应的第一引擎文件和第二引擎文件,使用第一引擎文件处理对待处理数据表的读写操作,并遍历待处理引擎文件中的每条第一数据记录,在第一数据记录为有效记录的情况下,将第一数据记录写入至所述第二引擎文件中,以及将第一引擎文件中的各条第二数据记录合并至第二引擎文件中,将合并后的第二引擎文件设置为待处理数据表的引擎文件。
在一个可能的实施方式中,存储节点确定模块1730可以包括:
分片信息获取单元,用于根据待处理数据表标识,获取待处理数据表的分片分布信息,分片分布信息表征每个分片所分布的存储节点;
存储节点类型匹配单元,用于获取存储节点类型标识对应的存储节点;
存储节点确定单元,用于从存储节点类型标识对应的存储节点中选择与分片分布信息匹配的存储节点,得到至少一个存储节点。
需要说明的是,上述实施例提供的装置,在实现其功能时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的装置与方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
本申请实施例还提供了一种计算机设备,该计算机设备包括处理器和存储器,该存储器中存储有至少一条指令或至少一段程序,该至少一条指令或至少一段程序由该处理器加载并执行上述方法实施例提供的数据库引擎文件处理方法。
进一步地,图18示出了一种用于实现数据库引擎文件处理方法的计算机设备的硬件结构示意图,该设备可以参与构成或包含本申请实施例所提供的装置或系统。如图18所示,设备18可以包括一个或多个(图中采用1802a、1802b,……,1802n来示出)处理器1802(处理器1802可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器1804、以及用于通信功能的传输装置1806。除此以外,还可以包括:显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解,图18所示的结构仅为示意,其并不对上述电子装置的结构造成限定。例如,设备18还可包括比图18中所示更多或者更少的组件,或者具有与图18所示不同的配置。
应当注意到的是上述一个或多个处理器1802和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外,数据处理电路可为单个独立的处理模块,或全部或部分的结合到设备18(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的,该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
存储器1804可用于存储应用软件的软件程序以及模块,如本申请实施例中所述数据库引擎文件处理方法对应的程序指令/数据存储装置,处理器1802通过运行存储在存储器1804内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的一种数据库引擎文件处理方法。存储器1804可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实施例中,存储器1804可进一步包括相对于处理器1802远程设置的存储器,这些远程存储器可以通过网络连接至设备18。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置1806用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备18的通信供应商提供的无线网络。在一个实例中,传输装置1806包括一个网络适配器(NetworkInterfaceController,NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输装置1806可以为射频(RadioFrequency,RF)模块,其用于通过无线方式与互联网进行通讯。
显示器可以例如触摸屏式的液晶显示器(LCD),该液晶显示器可使得用户能够与设备18(或移动设备)的用户界面进行交互。
本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有至少一条指令或至少一段程序,该至少一条指令或至少一段程序由处理器加载并执行以实现上述方法实施例提供的数据库引擎文件处理方法。
可选地,在本实施例中,上述计算机可读存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random AccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
本申请实施例还提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述的方法实施例提供的数据库引擎文件处理方法。
需要说明的是:上述本申请实施例先后顺序仅仅为了描述,不代表实施例的优劣。且上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
本申请中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置和电子设备实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
上述说明已经充分揭露了本申请的具体实施方式。需要指出的是,熟悉该领域的技术人员对本申请的具体实施方式所做的任何改动均不脱离本申请的权利要求书的范围。相应地,本申请的权利要求的范围也并不仅仅局限于前述具体实施方式。