CN115827660B - 数据更新方法、装置、电子设备及非易失性存储介质 - Google Patents
数据更新方法、装置、电子设备及非易失性存储介质 Download PDFInfo
- Publication number
- CN115827660B CN115827660B CN202310112773.8A CN202310112773A CN115827660B CN 115827660 B CN115827660 B CN 115827660B CN 202310112773 A CN202310112773 A CN 202310112773A CN 115827660 B CN115827660 B CN 115827660B
- Authority
- CN
- China
- Prior art keywords
- data
- log
- area
- updated
- target
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
本申请公开了一种数据更新方法、装置、电子设备及非易失性存储介质。其中,该方法包括:确定待更新数据所在的数据区域,其中,数据区域包括:第一区域和第二区域,第一区域中数据的读取速率大于第二区域中数据的读取速率;在待更新数据位于第一区域的情况下,通过目标日志将待更新数据原位更新为目标数据;在待更新数据位于第二区域的情况下,通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域。本申请解决了由于相关技术中数据存储与更新方式不合理,造成的数据更新与处理效率低下的技术问题。
Description
技术领域
本申请涉及数据管理技术领域,具体而言,涉及一种数据更新方法、装置、电子设备及非易失性存储介质。
背景技术
随着对数据库对同时事务处理和分析能力需求提升,HTAP(Hybrid TransactionAnalytical Processing,在线事务与分析数据库)技术的应用也越来越多,由于TP的访问和更新往往具有较强的局部性,AP的访问模式经常会涉及到大量的全局表扫描,大部分的数据一旦被写入后很少被更新,因此无论是中间历经什么样的存储格式,最终大部分的数据会存储为利于压缩和扫描的行列混合存储(或者列存)格式,然而,相关技术中数据存储与更新方式不合理,造成随数据库中数据进行分析处理的性能差、数据更新效率低下等问题。
针对上述的问题,目前尚未提出有效的解决方案。
发明内容
本申请实施例提供了一种数据更新方法、装置、电子设备及非易失性存储介质,以至少解决由于相关技术中数据存储与更新方式不合理,造成的数据更新与处理效率低下的技术问题。
根据本申请实施例的一个方面,提供了一种数据更新方法,包括:确定待更新数据所在的数据区域,其中,数据区域包括:第一区域和第二区域,第一区域中数据的读取速率大于第二区域中数据的读取速率;在待更新数据位于第一区域的情况下,通过目标日志将待更新数据原位更新为目标数据;在待更新数据位于第二区域的情况下,通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域。
可选地,将待更新数据原位更新为目标数据包括:依据待更新数据生成第一日志,其中,第一日志为用于记录待更新数据进行数据更新之前的版本的目标日志;在待更新数据上存在指向第二日志的指针的情况下,设置第一日志的指针指向第二日志,其中,第二日志为在第一日志生成的时刻之前所生成的目标日志;将目标数据更新至待更新数据所在的存储位置,并设置目标数据的指针指向第一日志。
可选地,方法还包括:依据数据处理事务的发起时间,确定位于数据处理事务之前且与数据处理事务最近的数据更新事务为历史更新事务,其中,数据更新事务用于对待更新数据进行数据更新;依据目标数据与第一时刻和第二时刻之间生成的目标日志进行数据回滚,得到目标历史数据,其中,第一时刻为历史更新事务完成的时刻,第二时刻为系统中最新一条的数据更新事务完成的时刻,目标历史数据为数据处理事务计划处理的版本的数据;依据目标历史数据,执行数据处理事务。
可选地,目标日志的类型包括:第一类型、第二类型和第三类型,其中,第一类型的目标日志在第二区域内的数据进行更新的情况下生成,第二类型的目标日志在第二区域内的数据更新完成后添加至第一区域的情况下生成,第三类型的目标日志在第一区域内的数据进行更新的情况下生成;通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域,包括:依据目标数据和待更新数据,生成第一类型的第三日志,其中,第三日志为用于记录目标数据和待更新数据之间的区别的目标日志;在第二区域的待更新数据中不存在指向第四日志的指针的情况下,在待更新数据中增加指向第三日志的指针,其中,第四日志为在第三日志生成的时刻之前所生成的目标日志;异步删除位于第二区域的待更新数据,并依据第三日志将待更新数据更新为目标数据后插入第一区域。
可选地,方法还包括:在第二区域的待更新数据中存在指向第四日志的指针的情况下,设置第三日志的指针指向第四日志;将第二区域的待更新数据中指向第四日志的指针修改为指向第三日志。
可选地,异步删除位于第二区域的待更新数据,并依据第三日志将待更新数据更新为目标数据后插入第一区域,包括:依据第二区域中的待更新数据与第三日志,生成目标数据,并在目标数据中添加指向第三日志的指针;将目标数据插入第一区域,并在系统中存在计划访问第二区域中的待更新数据的数据处理事务的情况下,新建一条第二类型的目标日志,其中,第二类型的目标日志用于记录目标新建事务的标识号,目标新事务为用于在第二区域内插入待更新数据的事务;将第二区域中待更新数据中指向第三日志的指针修改为指向删除标记的指针,其中,删除标记用于表征待更新数据已在第二区域中删除。
可选地,第一区域中的数据划分为多个数据块进行存储,方法还包括:在计划将第二区域中的目标数据插入第一区域且第一区域的存储空间已满的情况下,统计各个数据块的访问频度;确定访问频度最低的数据块为目标数据块,并将目标数据块替换至第二区域,以使第二区域中的目标数据插入第一区域。
根据本申请实施例的另一个方面,还提供了一种数据更新装置,包括:区域确定模块,用于确定待更新数据所在的数据区域,其中,数据区域包括:第一区域和第二区域,第一区域中数据的读取速率大于第二区域中数据的读取速率;热区更新模块,用于在待更新数据位于第一区域的情况下,通过目标日志将待更新数据原位更新为目标数据;冷区更新模块,用于在待更新数据位于第二区域的情况下,通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域。
根据本申请实施例的又一方面,还提供了一种电子设备,电子设备包括:存储器和处理器,处理器用于运行存储在存储器中的程序,其中,程序运行时执行数据更新方法。
根据本申请实施例的再一方面,还提供了一种非易失性存储介质,非易失性存储介质包括存储的计算机程序,其中,非易失性存储介质所在设备通过运行计算机程序执行数据更新方法。
在本申请实施例中,采用确定待更新数据所在的数据区域,其中,数据区域包括:第一区域和第二区域,第一区域中数据的读取速率大于第二区域中数据的读取速率;在待更新数据位于第一区域的情况下,通过目标日志将待更新数据原位更新为目标数据;在待更新数据位于第二区域的情况下,通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域的方式,通过对数据进行冷热分区,热区使用原位更新,冷区使用异步删除加插入方式进行更新,实现了列存存储下高效的更新操作,并且也保证了点查询高性能,达到了提升全表扫描(大范围查询)、点查(小范围查询)以及更新操作的性能的目的,进而解决了由于相关技术中数据存储与更新方式不合理,造成的数据更新与处理效率低下技术问题。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是根据本申请实施例提供的一种用于实现数据更新的方法的计算机终端(或电子设备)的硬件结构框图;
图2是根据本申请实施例提供的一种数据更新的方法流程的示意图;
图3是根据本申请实施例提供的一种常见数据库体系结构的示意图;
图4是根据本申请实施例提供的几种常见的数据存储格式的示意图;
图5a是根据本申请实施例提供的一种异位更新的示意图;
图5b是根据本申请实施例提供的一种原位更新的示意图;
图6是根据本申请实施例提供的一种数据更新整体架构的示意图;
图7是根据本申请实施例提供的一种热区数据更新流程的示意图;
图8是根据本申请实施例提供的一种冷区数据更新流程的示意图;
图9是根据本申请实施例提供的一种数据更新装置的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
为了方便本领域技术人员更好地理解本申请实施例,现将本申请实施例涉及的部分技术术语或者名词解释如下:
在线事务与分析数据库(Hybrid Transaction Analytical Processing,HTAP):是在线事务(On-Line Transaction Processing,OLTP)和在线分析(Online AnalyticalProcessing,OLAP)的合称简写,即(HTAP= OLTP +OLAP)。
多版本并发控制(Multi-Version Concurrency Control,MVCC):是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;在编程语言中实现事务内存。
在相关技术中,对于很多行存数据库,例如Oracle, MySQL,OpenGauss等,为了避免MVCC带来的数据库膨胀,以及频繁更新导致读性能下降,采用了原位更新。然而对于行列混合存储的数据库,往往选择将更新的部分单独存储(例如PDT,kudu,TiDB),或者将更新操作转换成删除加插入操作(如SQL server),也有在内存数据库中实现了行列混合存储加原位更新(如Hyper),上述各种数据存储和更新方式均存在问题,具体如下。
对于行存格式来说,使用原位更新虽然能提升点查(小范围查询)的性能,但行存的存储格式无法像列存一样直接使用向量化执行引擎以及在只需要某些列的情况下需要读整行数据,对于OLAP的扫描操作并不友好。
对于PDT这类单独存储更新部分的方案,读取时需要合并增量数据和基表。虽然在全表扫描操作中,时间代价被分摊后占比较小,但是对于点查(小范围查询)并不友好,虽然增量的部分会被定期合并回基表,但考虑合并操作的成本,频率并不不会特别高,存在大量读操作无法避免合并操作。
对于SQL Server将更新拆分为删除加插入,虽然相较于上述PDT这类单独存储更新部分的方案在点查(小范围查询)下性能更好,但更新时需要将整行(包括其他不更新的列)进行读取,更改完之后插入,对于在宽表下更新少量列的操作而言,性能并不理想。
Hyper实现了内存数据库下的行列混合存储加原位更新。但由于内存价格昂贵,成本高,因此对列存数据格式的单条数据读写代价仍然不小,所以对于大部分数据库,Hyper的方案并不适用。
为了解决上述问题,本申请实施例中提供了相关的解决方案,以下详细说明。
根据本申请实施例,提供了一种数据更新的方法实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。图1示出了一种用于实现数据更新方法的计算机终端(或电子设备)的硬件结构框图。如图1所示,计算机终端10(或电子设备10)可以包括一个或多个(图中采用102a、102b,……,102n来示出)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输模块106。除此以外,还可以包括:显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为BUS总线的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解,图1所示的结构仅为示意,其并不对上述电子装置的结构造成限定。例如,计算机终端10还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。
应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外,数据处理电路可为单个独立的处理模块,或全部或部分的结合到计算机终端10(或电子设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的,该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
存储器104可用于存储应用软件的软件程序以及模块,如本申请实施例中的数据更新方法对应的程序指令/数据存储装置,处理器102通过运行存储在存储器104内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述数据更新方法。存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中,传输装置106包括一个网络适配器(Network Interface Controller,NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输装置106可以为射频(Radio Frequency,RF)模块,其用于通过无线方式与互联网进行通讯。
显示器可以例如触摸屏式的液晶显示器(LCD),该液晶显示器可使得用户能够与计算机终端10(或电子设备)的用户界面进行交互。
在上述运行环境下,本申请实施例提供了一种数据更新方法,该数据更新方法可以在常见的数据库体系结构上实现对高效的数据大范围读取、小范围查找以及写入更新删除等操作,图3是根据本申请实施例提供的一种常见数据库体系结构的示意图,如图3所示,一个通用数据库可以分为连接管理系统、编译执行系统、存储管理系统和事务管理系统等模块,存储管理系统除了用于存储和管理数据的外存管理器之外,还包括了对进入内存中数据管理的内存管理器,以及用于快速查找的索引管理器。本申请通过索引管理、内存管理、外存管理等部分实现上述数据更新方法。
为了方便本领域技术人员更好地理解本申请实施例中的数据更新方法,下面对数据更新方法中涉及的概念做进一步介绍。
首先,对几种常见的数据存储格式进行介绍。
在关系数据库中最常见的就是行存,即一个元组所有列作为一行连续地存储在表中(如图4中所示的行式存储),行式存储对于OLAP负载下经常访问部分列的全部数据操作来说,需要读取整张表的所有数据,开销很大。因此列存表开始出现,即将关系表中的每一属性列作为一个文件存储((如图4中所示的列式存储),在列式存储时上述数据访问只需要读取对应列所对应的文件,而且同一列存储在一起也提升了编码压缩率,大大减小了I/O数量,同时也可以直接利用上向量化执行引擎。然而列存也存在一定问题,对于每个列存一个文件的行为带来了大量小文件的行为,虽然可以通过底层文件系统实现段页式来解决此问题,但对文件系统的要求较高,例如,在HDFS上就无法直接使用。
目前,行列混合存储替代掉大部分OLAP数据库中列存格式,成为默认存储格式,本申请中所指的列式存储包括了行列混合存储。行列混合存储是将数据表按照一定的大小按照行划分成若干个row group(行组),每个row group中按照列存存储,一张表存储在一个文件中。行列混合存储格式既继承了列存的优点,也避免了列存的文件过多的问题。
下面对原位更新和异位更新的概念进行介绍。
为了提升数据库的并发能力,很多数据库采用了MVCC(多版本并发控制)的方式避免了读操作时对数据的加锁和写操作对读操作的影响。多版本并发控制常见的实现方式就是进行异位更新,如图5a所示,把更新操作拆成删除加插入,老版本标记删除,新版本直接插入到数据文件结尾,并在老版本中记录下指向新版本的指针,新老版本存储在一起,通过每个版本所带的事务号来判断所需要读取的版本。
在采用异位更新的情况下,增删改操作可以快速执行,然而对于查找来说,随着更新删除操作的增多,无效数据的占比也会越来越高,直接影响读操作的效率,尤其是对于使用索引的点查(小范围查询)来说,索引指向的是最旧的版本,而大多数读操作要访问的最新版本需要沿着版本链遍历进行多次查找。
另一种实现方式就是进行原位更新,如图5b所示,更新时将新版本的数据写在老版本数据所在的位置,而老版本写入undo log(为了减小日志大小,一般记录新版本和老版本中更改的部分),新版本中记录下老版本在undo log的位置,用于查找。当更新事务发生回滚时,利用undo log可以将数据回滚回老版本;当更新事务提交后,在更新事务提交之后开始的事务直接读取新版本数据,在此之前开始的事务则会通过undo log获得老版本,当不存在比更新事务更老的活跃事务时,该undo log可以被清理,且通过索引进行点查(小范围查询)时可以直接读取最新数据。
相关技术中列式存储不使用原位更新的原因在于持久化到磁盘上的数据是每个row group经过编码压缩之后得到的,如果原位更新某行的某列值,会涉及到整个rowgroup内部该列的读取、解压、解码、重新编码、压缩、写入,与在行存格式中只需要原位更新并记录undo log的代价相比代价巨大。通过本申请实施例所提供的数据更新方法可以解决上述问题,下面对数据更新方法进行详细说明。
图6是根据本申请实施例提供的一种数据更新整体架构的示意图,如图6所示,数据分为冷、热两个区,热区的数据存储在内存中,记录undo log(目标日志)进行原位更新;冷区的数据存储在持久化存储中,更新的时候将冷区的数据标记为删除并将新的行插入热区,之后的更新变为对热区数据的原位更新。本申请中对冷区数据的第一次更新带来的删除加插入操作通过异步实现:更新操作将更新部分记录到undo log,记录undo log位置;此期间有新的更新操作会记录新的undo log,并更新undo log位置;待新的数据插入后,原数据标记为删除,原本的undo log链由新数据开始。
图2是根据本申请实施例提供的一种数据更新的方法流程的示意图,图2中数据更新方法可应用于图6中的数据更新整体架构中,如图2所示,该方法包括如下步骤:
步骤S202,确定待更新数据所在的数据区域,其中,数据区域包括:第一区域和第二区域,第一区域中数据的读取速率大于第二区域中数据的读取速率;
在步骤S202所提供的方案中,上述第一区域可以为内存中的热数据区,上述第二区域可以为磁盘中的冷数据区。
具体地,对于经常访问的和新写入的数据会以列存格式存储在内存(热数据区)中,数据逻辑上按照固定大小分成多个row group,用于热区满时替换写到冷区做为一整个完整的block。热区数据的更新都是原位更新。
具体地,对于长时间不访问的数据将整个row group从热区替换下来编码压缩成block后写入冷区。冷区的数据包括两个部分,一是编压缩写下来的cold data block,一旦写入就不会再变化(除非做垃圾回收时候会重新生成新的block);二是冷区数据被更新删除时记录的cold data delta pointer部分,用于记录每条被更新删除的冷区数据对应的undo log位置,当异步更新操作完成时,该pointer(指针)会被修改为该条记录的删除标记。
作为一种可选的实施方式,上述cold data delta pointer部分可以为B-Tree结构或者其他结构。
在本申请的一些实施例中,无论是热区数据的原位更新还是冷区社区的异位更新,均会生成undo log追加到undo log文件中,写入持久化存储。同时后台的清理线程会定期将无效的undo log空间进行回收。
步骤S204,在待更新数据位于第一区域的情况下,通过目标日志将待更新数据原位更新为目标数据,其中,所述目标数据为计划将所述待更新数据更新为的数据;
在本申请的一些实施例中,将待更新数据原位更新为目标数据包括以下步骤:依据待更新数据生成第一日志,其中,第一日志为用于记录待更新数据进行数据更新之前的版本的目标日志;在待更新数据上存在指向第二日志的指针的情况下,设置第一日志的指针指向第二日志,其中,第二日志为在第一日志生成的时刻之前所生成的目标日志;将目标数据更新至待更新数据所在的存储位置,并设置目标数据的指针指向第一日志。
在本申请的一些实施例中,方法还包括以下步骤:依据数据处理事务的发起时间,确定位于数据处理事务之前且与数据处理事务最近的数据更新事务为历史更新事务,其中,数据更新事务用于对待更新数据进行数据更新;依据目标数据与第一时刻和第二时刻之间生成的目标日志进行数据回滚,得到目标历史数据,其中,第一时刻为历史更新事务完成的时刻,第二时刻为系统中最新一条的数据更新事务完成的时刻,目标历史数据为数据处理事务计划处理的版本的数据;依据目标历史数据,执行数据处理事务。
热区(即上述第一区域)的数据存储在内存中且没有被编码压缩,原位更新只需要记录undo log(即上述目标日志)并原位覆盖新值即可,多次更新记录的undo log会按照从新到旧链接起来用于对应版本的查找。图7是根据本申请实施例提供的一种热区数据更新流程的示意图,如图7所示。
具体地,查找数据在热区中的版本(即上述待更新数据),生成新的undo log(即上述第一日志);判断原有的版本上是否已有指向undo log(即上述第二日志)的指针;在原有的版本上已有指向的undo log的指针的情况下,将新undo log指向老undo log后,再将新版本(即上述目标数据)原位更新老版本(即上述待更新数据的存储位置)上,并更新新版本指针指向新undo log;在原有的版本上不存在指向的undo log的指针的情况下,直接将新版本原位更新老版本上,并更新新版本指针指向新undo log。
举例说明,下表中列举了热区数据v1被更新了三次数据存储和和undo log的内容。初始事务t1插入的数据版本为v1,事务t2中将v1改为v2,热区中数据原位更新成v2,事务ID更新成t2,undo log记录∆21=v2 xor v1和v1的事务ID t1。
经历完三次更新后,数据记录为v4(t4) 指向undo log ∆43(t3)->∆32(t2)->∆21(t1)。对于t4提交之后开始事务如t5,直接读到v4返回;对于开始比较早的事务如t2’(在t2提交后t3提交前开始的事务,期待读到v2(即上述目标历史数据),会依次读到v4、∆43、∆32并合并获得v2。
对于热区数据的原位更新的更新性能,更新操作的原位更新是在内存中直接覆盖的(不涉及到压缩解压等操作),同时生成了undo log是追加写到undo log文件(不要求同步落盘),性能代价与行存表原位更新基本一致;对于点查(小范围查询)性能,在热区中查找到的数据即为最新版本可直接返回,只有在读取较老版本的时候需要读取undo log进行合并,代价与行存表原位更新基本一致。
步骤S206,在待更新数据位于第二区域的情况下,通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域。
在步骤S206所提供的技术方案中,目标日志的类型包括:第一类型、第二类型和第三类型,其中,第一类型的目标日志在第二区域内的数据进行更新的情况下生成,第二类型的目标日志在第二区域内的数据更新完成后添加至第一区域的情况下生成,第三类型的目标日志在第一区域内的数据进行更新的情况下生成;
具体地,undo log(即上述目标日志)分为三类:(1)redo(即上述第一类型),此类型是在冷区数据被更新的时候产生的,记录的是最新版本和冷区初始版本的差值,合并冷区初始版本和单条此类型的日志可以得到对应版本的数据;(2)switch(即上述第二类型),冷区数据更新完成新插入热区数据删除冷区数据时产生的undo log,用于保留初始冷区数据版本的事务ID,此日志并非每个更新操作都会生成,如果冷区数据版本不会被正在进行的事务访问,则不需要记录此条日志;(3)undo(即上述第三类型),热区数据做原位更新产生的,记录最新两个版本的差别。
在本申请的一些实施例中,通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域,包括以下步骤:依据目标数据和待更新数据,生成第一类型的第三日志,其中,第三日志为用于记录目标数据和待更新数据之间的区别的目标日志;在第二区域的待更新数据中不存在指向第四日志的指针的情况下,在待更新数据中增加指向第三日志的指针,其中,第四日志为在第三日志生成的时刻之前所生成的目标日志;异步删除位于第二区域的待更新数据,并依据第三日志将待更新数据更新为目标数据后插入第一区域。
在本申请的一些实施例中,方法还包括以下步骤:在第二区域的待更新数据中存在指向第四日志的指针的情况下,设置第三日志的指针指向第四日志;将第二区域的待更新数据中指向第四日志的指针修改为指向第三日志。
在本申请的一些实施例中,异步删除位于第二区域的待更新数据,并依据第三日志将待更新数据更新为目标数据后插入第一区域,包括以下步骤:依据第二区域中的待更新数据与第三日志,生成目标数据,并在目标数据中添加指向第三日志的指针;将目标数据插入第一区域,并在系统中存在计划访问第二区域中的待更新数据的数据处理事务的情况下,新建一条第二类型的目标日志,其中,第二类型的目标日志用于记录目标新建事务的标识号,目标新事务为用于在第二区域内插入待更新数据的事务;将第二区域中待更新数据中指向第三日志的指针修改为指向删除标记的指针,其中,删除标记用于表征待更新数据已在第二区域中删除。
具体地,包括如下步骤:步骤1,记录下更新部分的undo log(即上述第三日志),冷区数据保持不变但为该条数据增加指向undo log的指针,此时可返回客户端完成更新;步骤2,异步完成冷区数据该条记录的读取,更新为新记录插入热区,并记录一条新的undolog(即上述新建一条第二类型的目标日志)存储对应冷数据版本的事务ID(即上述目标新建事务的标识号),原冷区数据上指向undo log的指针不再需要,改为记录该数据无效的标识(即上述删除标记)。
在步骤2完成之后,该更新数据的新版本进入热区,之后的更新操作转换成上述热区数据更新的操作。在步骤1、2之间的数据更新,会继续记录新的undo log,并更新冷区数据上指向undo log的指针,除了冷区上的初始数据版本,其他版本均从新往旧链接起来。
图8是根据本申请实施例提供的一种冷区数据更新流程的示意图,如图8所示。
具体地,查找数据在冷区中的版本(即上述待更新数据),判断原有版本是否标记为删除;在已标记为删除的情况下,说明该数据已插入热区,执行热区更新逻辑;若原有版本未标记为删除,则判断原有版本上是否已有指向undo log(即上述第四日志)的指针,在不存在指向第四日志的指针的情况下,将原有版本增加指针指向新undo log(即上述第三日志),将老版本(即上述待更新数据)标记删除,并将新版本(即上述目标数据)插入热区。
在原有版本上存在已有指向undo log(即上述第四日志)的指针的情况下,将新undo log(即上述第三日志)指向老undo log(即上述第四日志),并更新原有版本(即上述待更新数据)上已有指向undo log(即上述第四日志)的指针指向新undo log(即上述第三日志)。
举例说明,下表举例了冷区数据v1被更新了五次数据存储和和undo log的内容。初始事务t1插入的数据版本为v1,事务t2中将v1改为v2,冷区数据继续保留原始数据v1(t1),undo log记录∆21=v2 xor v1和v2的事务ID t2,冷区数据增加该条数据指向undolog的指针。事务t3中将v2改为v3,此时异步删除并插入新数据的操作还未完成,记录新的undo log并更改冷区数据对应的指针,事务t4同理。事务t4完成之后,新数据插入到热区,此时因为还存在事务要访问v1(t1),故产生undo log记录t1,并将冷区数据标为无效,热区数据也指向该条记录最新的undo log。之后的事务t5/t6对该数据的更新执行热区更新逻辑,具体同上述热区数据更新举例。
经历完五次更新后,对于事务t4’(在t4提交后t5提交前开始的事务,期待读到v4),读到v6、∆65、∆54并合并获得v4;对于事务如t2’(在t2提交后t3提交前开始的事务,期待读到v2),会依次读到v6、∆65、∆54、∆41、∆31、∆21并合并v6、∆65、∆54、∆41、∆21获得v2。
对于冷区更新的更新性能,异位更新的操作是异步的不在更新操作路径中,同步的流程里记录更新部分的undo log,只需要读更新部分的列,另外,会比热区数据更新多出将undo log的位置插入到cold data delta pointer中的步骤,虽然复杂度会和cold datadelta pointer数据结构有一定相关度(比如B-Tree的单条插入性能),比异位更新的读取多列解压等操作的复杂减小很多,提升了效率;对于点查(/小范围查询)性能,主要关注异位更新操作完成前的性能(之后的性能就是热区读的性能),每次读取的冷区数据是原始数据,再通过cold data delta pointer读到最新版数据对应的undo log,基本代价比读取未修改的冷区数据仅仅多出读取undo log并合并的代价,而且在异步更新完成后,这个代价就会被抹去。
在本申请的一些实施例中,第一区域中的数据划分为多个数据块(block)进行存储。
作为一种可选的实施例,方法还包括以下步骤:在计划将第二区域中的目标数据插入第一区域且第一区域的存储空间已满的情况下,统计各个数据块的访问频度;确定访问频度最低的数据块为目标数据块,并将目标数据块替换至第二区域,以使第二区域中的目标数据插入第一区域。
具体地,热区数据以列存格式存储在内存中,数据逻辑上按照固定大小分成多个row group,统计每个row group的访问频度(统计写入、更新以及点查,不统计全表扫描操作),当热区满时选择访问频度最低的row group替换写到冷区做为一整个完整的block。
相比于行存格式的原位更新,本申请提升了全表扫描这类大范围查询的性能。相比于PDT等这类单独存储更新部分的方案,本申请提升了点查(小范围查询)的性能。相比于SQL Server这类将更新拆分为删除加插入的方案,本申请提升了更新操作的性能。相比于Hyper内存数据库的行列混合存储加原位更新,本申请不局限于内存大小,能适用于磁盘数据库。
通过上述步骤,通过对数据进行冷热分区,热区使用原位更新,冷区使用异步删除加插入方式进行更新,实现了列存存储下高效的更新操作,并且也保证了点查询高性能,达到了提升全表扫描(大范围查询)、点查(小范围查询)以及更新操作的性能的目的,进而解决了由于相关技术中数据存储与更新方式不合理,造成的数据更新与处理效率低下技术问题。
根据本申请实施例,还提供了一种数据更新装置的实施例。图9是根据本申请实施例提供的一种数据更新装置的结构示意图。如图9所示,该装置包括:
区域确定模块90,用于确定待更新数据所在的数据区域,其中,数据区域包括:第一区域和第二区域,第一区域中数据的读取速率大于第二区域中数据的读取速率;
热区更新模块92,用于在待更新数据位于第一区域的情况下,通过目标日志将待更新数据原位更新为目标数据;
冷区更新模块94,用于在待更新数据位于第二区域的情况下,通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域。
本申请使用统一的undo log完成了同一存储中原位和异位的更新,并且保证在读操作时高效获取最新版本;冷区异步删除加插入方案解决latency。异步地使用异位更新的方式,避免了操作本身在关键路径上导致的性能损耗,能够快速的产生新版本便于后续的读取。本申请方案相较于现有技术具有高性能的更新性能、高性能的点查(小范围查询)性能,且不受限于内存大小,适用于磁盘数据库。
需要说明的是,上述数据更新装置中的各个模块可以是程序模块(例如是实现某种特定功能的程序指令集合),也可以是硬件模块,对于后者,其可以表现为以下形式,但不限于此:上述各个模块的表现形式均为一个处理器,或者,上述各个模块的功能通过一个处理器实现。
需要说明的是,本实施例中所提供的数据更新装置可用于执行图2所示的数据更新方法,因此,对上述数据更新方法的相关解释说明也适用于本申请实施例中,在此不再赘述。
本申请实施例还提供了一种非易失性存储介质,非易失性存储介质包括存储的计算机程序,其中,非易失性存储介质所在设备通过运行计算机程序执行以下数据更新方法:确定待更新数据所在的数据区域,其中,数据区域包括:第一区域和第二区域,第一区域中数据的读取速率大于第二区域中数据的读取速率;在待更新数据位于第一区域的情况下,通过目标日志将待更新数据原位更新为目标数据;在待更新数据位于第二区域的情况下,通过目标日志将待更新数据异位更新为目标数据,并将目标数据添加至第一区域。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
在本申请的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的技术内容,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,可以为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。
Claims (9)
1.一种数据更新方法,其特征在于,包括:
确定待更新数据所在的数据区域,其中,所述数据区域包括:第一区域和第二区域,所述第一区域中数据的读取速率大于所述第二区域中数据的读取速率;
在所述待更新数据位于所述第一区域的情况下,通过目标日志将所述待更新数据原位更新为目标数据,包括:依据所述待更新数据生成第一日志,其中,所述第一日志为用于记录所述待更新数据进行数据更新之前的版本的所述目标日志;在所述待更新数据上存在指向第二日志的指针的情况下,设置所述第一日志的指针指向所述第二日志,其中,所述第二日志为在所述第一日志生成的时刻之前所生成的所述目标日志;将所述目标数据更新至所述待更新数据所在的存储位置,并设置所述目标数据的指针指向所述第一日志;
在所述待更新数据位于所述第二区域的情况下,通过所述目标日志将所述待更新数据异位更新为所述目标数据,并将所述目标数据添加至所述第一区域,包括:依据所述目标数据和所述待更新数据,生成第一类型的第三日志,其中,所述第三日志为用于记录所述目标数据和所述待更新数据之间的区别的所述目标日志,所述目标日志的类型包括:所述第一类型,所述第一类型的所述目标日志在所述第二区域内的数据进行更新的情况下生成;在所述第二区域的所述待更新数据中不存在指向第四日志的指针的情况下,在所述待更新数据中增加指向所述第三日志的指针,其中,所述第四日志为在所述第三日志生成的时刻之前所生成的所述目标日志;异步删除位于所述第二区域的所述待更新数据,并依据所述第三日志将所述待更新数据更新为所述目标数据后插入所述第一区域。
2.根据权利要求1所述的数据更新方法,其特征在于,所述方法还包括:
依据数据处理事务的发起时间,确定位于所述数据处理事务之前且与所述数据处理事务最近的数据更新事务为历史更新事务,其中,所述数据更新事务用于对所述待更新数据进行数据更新;
依据所述目标数据与第一时刻和第二时刻之间生成的所述目标日志进行数据回滚,得到目标历史数据,其中,所述第一时刻为所述历史更新事务完成的时刻,所述第二时刻为系统中最新一条的所述数据更新事务完成的时刻,所述目标历史数据为所述数据处理事务计划处理的版本的数据;
依据所述目标历史数据,执行所述数据处理事务。
3.根据权利要求1所述的数据更新方法,其特征在于,所述目标日志的类型还包括:第二类型和第三类型,其中,所述第二类型的所述目标日志在所述第二区域内的数据更新完成后添加至所述第一区域的情况下生成,所述第三类型的所述目标日志在所述第一区域内的数据进行更新的情况下生成。
4.根据权利要求3所述的数据更新方法,其特征在于,所述方法还包括:
在所述第二区域的所述待更新数据中存在指向所述第四日志的指针的情况下,设置所述第三日志的指针指向所述第四日志;
将所述第二区域的所述待更新数据中指向所述第四日志的指针修改为指向所述第三日志。
5.根据权利要求3所述的数据更新方法,其特征在于,异步删除位于所述第二区域的所述待更新数据,并依据所述第三日志将所述待更新数据更新为所述目标数据后插入所述第一区域,包括:
依据所述第二区域中的所述待更新数据与所述第三日志,生成所述目标数据,并在所述目标数据中添加指向所述第三日志的指针;
将所述目标数据插入所述第一区域,并在系统中存在计划访问所述第二区域中的所述待更新数据的数据处理事务的情况下,新建一条所述第二类型的所述目标日志,其中,所述第二类型的所述目标日志用于记录目标新建事务的标识号,所述目标新建事务为用于在所述第二区域内插入所述待更新数据的事务;
将所述第二区域中所述待更新数据中指向所述第三日志的指针修改为指向删除标记的指针,其中,所述删除标记用于表征所述待更新数据已在所述第二区域中删除。
6.根据权利要求1所述的数据更新方法,其特征在于,所述第一区域中的数据划分为多个数据块进行存储,所述方法还包括:
在计划将所述第二区域中的所述目标数据插入所述第一区域且所述第一区域的存储空间已满的情况下,统计各个所述数据块的访问频度;
确定所述访问频度最低的数据块为目标数据块,并将所述目标数据块替换至所述第二区域,以使所述第二区域中的所述目标数据插入所述第一区域。
7.一种数据更新装置,其特征在于,包括:
区域确定模块,用于确定待更新数据所在的数据区域,其中,所述数据区域包括:第一区域和第二区域,所述第一区域中数据的读取速率大于所述第二区域中数据的读取速率;
热区更新模块,用于在所述待更新数据位于所述第一区域的情况下,通过目标日志将所述待更新数据原位更新为目标数据,包括:依据所述待更新数据生成第一日志,其中,所述第一日志为用于记录所述待更新数据进行数据更新之前的版本的所述目标日志;在所述待更新数据上存在指向第二日志的指针的情况下,设置所述第一日志的指针指向所述第二日志,其中,所述第二日志为在所述第一日志生成的时刻之前所生成的所述目标日志;将所述目标数据更新至所述待更新数据所在的存储位置,并设置所述目标数据的指针指向所述第一日志;
冷区更新模块,用于在所述待更新数据位于所述第二区域的情况下,通过所述目标日志将所述待更新数据异位更新为所述目标数据,并将所述目标数据添加至所述第一区域,包括:依据所述目标数据和所述待更新数据,生成第一类型的第三日志,其中,所述第三日志为用于记录所述目标数据和所述待更新数据之间的区别的所述目标日志,所述目标日志的类型包括:所述第一类型,所述第一类型的所述目标日志在所述第二区域内的数据进行更新的情况下生成;在所述第二区域的所述待更新数据中不存在指向第四日志的指针的情况下,在所述待更新数据中增加指向所述第三日志的指针,其中,所述第四日志为在所述第三日志生成的时刻之前所生成的所述目标日志;异步删除位于所述第二区域的所述待更新数据,并依据所述第三日志将所述待更新数据更新为所述目标数据后插入所述第一区域。
8.一种电子设备,其特征在于,包括:存储器和处理器,所述处理器用于运行存储在所述存储器中的程序,其中,所述程序运行时执行权利要求1至6中任意一项所述的数据更新方法。
9.一种非易失性存储介质,其特征在于,所述非易失性存储介质包括存储的计算机程序,其中,所述非易失性存储介质所在设备通过运行所述计算机程序执行权利要求1至6中任意一项所述的数据更新方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310112773.8A CN115827660B (zh) | 2023-02-14 | 2023-02-14 | 数据更新方法、装置、电子设备及非易失性存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310112773.8A CN115827660B (zh) | 2023-02-14 | 2023-02-14 | 数据更新方法、装置、电子设备及非易失性存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115827660A CN115827660A (zh) | 2023-03-21 |
CN115827660B true CN115827660B (zh) | 2023-05-12 |
Family
ID=85521312
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310112773.8A Active CN115827660B (zh) | 2023-02-14 | 2023-02-14 | 数据更新方法、装置、电子设备及非易失性存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115827660B (zh) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111611223A (zh) * | 2020-05-20 | 2020-09-01 | 清华大学 | 非易失性数据的访问方法、系统、电子设备和介质 |
CN113626449A (zh) * | 2021-07-02 | 2021-11-09 | 上海硬通网络科技有限公司 | 数据存储、数据查询方法及相关设备 |
CN114880329A (zh) * | 2022-05-25 | 2022-08-09 | 广州文远知行科技有限公司 | 数据查询方法、装置、存储介质及计算机设备 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019087295A1 (ja) * | 2017-10-31 | 2019-05-09 | 三菱電機株式会社 | 更新システム、更新装置および被更新装置 |
CN111090663B (zh) * | 2019-12-25 | 2023-07-07 | 上海金仕达软件科技股份有限公司 | 事务并发控制方法、装置、终端设备及介质 |
CN113051241B (zh) * | 2019-12-27 | 2023-08-15 | 中国移动通信集团湖南有限公司 | 数据库持久化的方法、装置及设备 |
CN111880731B (zh) * | 2020-07-17 | 2023-03-21 | 北京浪潮数据技术有限公司 | 一种数据处理方法、装置及相关组件 |
-
2023
- 2023-02-14 CN CN202310112773.8A patent/CN115827660B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111611223A (zh) * | 2020-05-20 | 2020-09-01 | 清华大学 | 非易失性数据的访问方法、系统、电子设备和介质 |
CN113626449A (zh) * | 2021-07-02 | 2021-11-09 | 上海硬通网络科技有限公司 | 数据存储、数据查询方法及相关设备 |
CN114880329A (zh) * | 2022-05-25 | 2022-08-09 | 广州文远知行科技有限公司 | 数据查询方法、装置、存储介质及计算机设备 |
Also Published As
Publication number | Publication date |
---|---|
CN115827660A (zh) | 2023-03-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9881049B2 (en) | Reducing the cost of update, delete, and append-only insert operations in a database | |
US9606921B2 (en) | Granular creation and refresh of columnar data | |
US10409864B2 (en) | Transaction control block for multiversion concurrency commit status | |
US8423528B2 (en) | Selection of rows and values from indexes with updates | |
Larson et al. | Enhancements to SQL server column stores | |
US11275759B2 (en) | Data storage method and apparatus, server, and storage medium | |
US20160147786A1 (en) | Efficient Database Undo / Redo Logging | |
EP2608071A1 (en) | Hybrid database table stored as both row and column store | |
CN110990402B (zh) | 由行存储到列存储的格式转化方法、查询方法及装置 | |
US8924373B2 (en) | Query plans with parameter markers in place of object identifiers | |
CN105630864A (zh) | 存储行标识符值的字典的强制排序 | |
CN111046034A (zh) | 管理内存数据及在内存中维护数据的方法和系统 | |
CN110309122B (zh) | 获取增量数据的方法、装置、服务器和存储介质 | |
CN111651519A (zh) | 数据同步方法、数据同步装置、电子设备及存储介质 | |
CN115827660B (zh) | 数据更新方法、装置、电子设备及非易失性存储介质 | |
WO2023197865A1 (zh) | 一种信息存储方法及装置 | |
CN116881371B (zh) | 数据同步方法、装置、设备及存储介质 | |
CN115827653B (zh) | 一种用于htap和海量数据的纯列式更新方法及装置 | |
US20230394017A1 (en) | Systems and methods for column store indices | |
CN115905259B (zh) | 一种支持行级并发控制的纯列式更新方法及装置 | |
Myalapalli et al. | Optimizing SQL queries in OLAP database systems | |
CN117909344A (zh) | 数据更新方法、装置、非易失性存储介质及计算机设备 | |
CN117056427A (zh) | 混合事务分析系统中的数据处理方法、装置及电子设备 | |
JP2024514672A (ja) | アペンド専用データ構造を用いるリスト・ベースのデータ検索 | |
CN113051274A (zh) | 一种海量标签存储系统及方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |