CN104424219B - 一种数据文件的管理方法及装置 - Google Patents
一种数据文件的管理方法及装置 Download PDFInfo
- Publication number
- CN104424219B CN104424219B CN201310373456.8A CN201310373456A CN104424219B CN 104424219 B CN104424219 B CN 104424219B CN 201310373456 A CN201310373456 A CN 201310373456A CN 104424219 B CN104424219 B CN 104424219B
- Authority
- CN
- China
- Prior art keywords
- memory block
- major key
- data file
- merging
- data
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/174—Redundancy elimination performed by the file system
- G06F16/1744—Redundancy elimination performed by the file system using compression, e.g. sparse files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Quality & Reliability (AREA)
Abstract
本申请公开了一种数据文件的管理方法及装置。其中,数据文件的管理方法包括:在增量数据存储区达到第一数据文件合并条件时,将增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的主键对应的历史完整记录合并,形成每个主键对应的合并时刻的完整记录;将每个主键对应的合并时刻的完整记录写入完整数据存储区的一个新建的数据文件中,其中,每个主键对应的合并时刻的完整记录作为在完整数据存储区精确查询主键的输出结果。通过上述方式,本申请能够使主键的记录集中化,为在完整数据存储区主键精确查询减少IO开销。
Description
技术领域
本发明涉及一种数据文件的管理方法及装置。
背景技术
数据库分为关系型数据库和非关系型数据库(Not Only SQL,NoSQL),NoSQL是对所有不同于传统的关系型数据库的统称。NoSQL数据存储可以不需要固定的表格模式,通常以键值对存储。目前多数NoSQL的数据存储以日志结构合并树(Log-Structured Merge-Tree,LSM-tree)为基础,提出一种延迟更新、批量写入硬盘的数据结构及其算法。LSM-tree通过将很多小文件的存取转换为连续的大批量传输,使得对于文件系统的大多数存取都是顺序性的,从而提高磁盘带宽利用率,最小化系统的存取性能的开销,特别适用于会产生大量插入操作的应用环境。所以,以LSM-tree为基础的NoSQL也被称为增量数据库。
LSM-tree由至少两个部件构成。一个部件常驻内存,称为C0树(或C0),可以为任何方便键值查找的数据结构,其他部件常驻硬盘之中,称为C1......CK树(或C1......CK),C1......CK中经常被访问的结点也将会被缓存在主存中。增量数据库采用增量写模式,即数据库新增记录或者更新记录,首先放入内存数据结构(如主存内数据表,Memory Table,Memtable)中,即C0树,它达到一定大小形成一个小数据文件(如有序字符串表,SortedString Table,Sstable)刷入硬盘数据结构,即C1......CK树,内部主键(Rowkey)有序排列。这样的文件将不可修改。查询时,则需要分别从这些小数据文件查询Rowkey记录片段,共同构成一条完整Rowkey记录。
采用增量写模式,一条完整Rowkey记录在存储上可以是离散在不同数据文件的Rowkey记录片段构成。这样,导致一次Rowkey精确查询需要多次存储器输入/输出(Input/Output,IO)消耗。
发明内容
本发明主要解决的技术问题是提供一种数据文件的管理方法及装置,能够使Rowkey由增量存储区的离散状态变为完整数据存储区的集中状态,为在完整数据存储区Rowkey精确查询减少IO开销。
本申请第一方面,提供一种数据文件的管理方法,包括:在增量数据存储区达到第一数据文件合并条件时,将所述增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的所述主键对应的历史完整记录合并,形成所述每个主键对应的合并时刻的完整记录;将所述每个主键对应的所述合并时刻的完整记录写入完整数据存储区的一个新建的数据文件中,其中,所述每个主键对应的所述合并时刻的完整记录作为在所述完整数据存储区精确查询所述主键的输出结果。
结合第一方面,在第一方面的第一种可能的实现方式中:所述方法还包括:将所述每个主键对应的所述合并时刻的完整记录写入主存。
结合第一方面或第一方面的的第一种可能的实现方式,在第一方面的第二种可能的实现方式中:所述方法还包括:在所述完整数据存储区达到第二数据文件合并条件时,对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录。
结合第一方面的第二种可能的实现方式,在第一方面的第三种可能的实现方式中,所述对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录,具体为:采用归并算法对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录。
结合第一方面的第三种可能的实现方式,在第一方面的第四种可能的实现方式中:所述采用归并算法对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录的步骤包括:从所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件中,查找出每个所述主键所在的最新的数据文件,所述最新的数据文件是指形成时间最晚的数据文件;从所述每个主键所在的最新的数据文件中获取每个所述主键对应的完整记录并写入所述完整数据存储区的合并的数据文件,删除所述完整数据存储区的已完成合并的所述数据文件。
结合第一方面的第二种至第四种任一可能的实现方式,在第一方面的第五种可能的实现方式中:所述将所述增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的所述主键对应的历史完整记录合并,形成所述每个主键对应的合并时刻的完整记录的步骤之前,还包括:从所述主存或所述完整数据存储区的数据文件中查找每个所述主键对应的历史完整记录。
结合第一方面的第五种可能的实现方式,在第一方面的第六种可能的实现方式中:所述从所述主存或所述完整数据存储区的数据文件中查找每个所述主键对应的历史完整记录的步骤包括:按照每个所述主键对应的完整记录的形成时间由新到旧的方式在所述主存中的数据文件中进行检索,若所述主存中没有检索到,再到所述完整数据存储区的数据文件中进行检索,直到检索到所述主键对应的完整记录,所述检索到的主键的完整记录为所述主键对应的历史完整记录。
结合第一方面的第五种可能的实现方式,在第一方面的第七种可能的实现方式中:在没有查找到所述主键对应的历史完整记录时,所述将所述增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的所述主键对应的历史完整记录合并,形成所述每个主键对应的合并时刻的完整记录,具体为:将所述增量数据存储区中的各数据文件中所述主键对应的记录片段合并,作为所述主键对应的所述合并时刻的完整记录。
结合第一方面,在第一方面的第八种可能的实现方式中:所述方法还包括:删除所述增量数据存储区的所述数据文件。
本申请的第二方面,提供一种存储装置,所述存储装置包括第一合并模块和写入模块,其中:所述第一合并模块用于在增量数据存储区达到第一数据文件合并条件时,将所述增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的所述主键对应的历史完整记录合并,形成所述每个主键对应的合并时刻的完整记录并输出给所述写入模块;所述写入模块用于将所述每个主键对应的所述合并时刻的完整记录写入完整数据存储区的一个新建的数据文件中,其中,所述每个主键对应的所述合并时刻的完整记录作为在所述完整数据存储区精确查询所述主键的输出结果。
结合第二方面,在第二方面的第一种可能的实现方式中:所述写入模块还用于将所述每个主键对应的所述合并时刻的完整记录写入主存。
结合第二方面或第二方面的第一种可能的实现方式,在第二方面的第二种可能的实现方式中:所述装置还包括第二合并模块,其中:所述第二合并模块用于在所述完整数据存储区达到第二数据文件合并条件时,对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录。
结合第二方面的第二种可能的实现方式,在第二方面的第三种可能的实现方式中:所述第二合并模块包括查找单元和写入单元,其中:所述查找单元用于从所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件中,查找出每个所述主键所在的最新的数据文件,所述最新的数据文件是指形成时间最晚的数据文件;所述写入单元用于从所述每个主键所在的最新的数据文件中获取每个所述主键对应的完整记录并写入所述完整数据存储区的合并的数据文件,删除所述完整数据存储区的已完成合并的所述数据文件。
结合第二方面的第一种至第三种任一可能的实现方式,在第二方面的第四种可能的实现方式中:所述装置还包括查找模块,其中:所述查找模块用于从所述主存或所述完整数据存储区的数据文件中查找每个所述主键对应的历史完整记录,并将查找到的每个所述主键对应的历史完整记录输出给所述第一合并模块。
结合第二方面的第四种可能的实现方式,在第二方面的第五种可能的实现方式中:在所述查找模块没有查找到所述主键对应的历史完整记录时,所述第一合并模块用于将所述增量数据存储区中的各数据文件中所述主键对应的记录片段合并,作为所述主键对应的所述合并时刻的完整记录。
本发明的有益效果是:区别于现有技术的情况,本申请将增量数据存储区的数据文件中每个Rowkey对应的记录片段,分别与查找到的Rowkey对应的历史完整记录合并,形成每个Rowkey对应的合并时刻的完整记录并写入完整数据存储区,通过这样的方式,对增量数据库的数据文件在增量数据存储区和完整数据存储区进行动态管理,从而使Rowkey在完整数据存储区呈集中状态存储,为在完整数据存储区Rowkey精确查询减少IO开销。
附图说明
图1是本申请分层存储结构示意图;
图2是本申请数据文件的管理方法一个实施方式的流程图;
图3是本申请数据文件的管理方法其中一个实施方式中,形成每个主键对应的合并时刻的完整记录的流程图;
图4是本申请数据文件的管理方法另一个实施方式的流程图;
图5是本申请数据文件的管理方法其中一个实施方式中,归并算法对完整数据存储区的保存的包含各合并时刻的完整记录的各数据文件进行合并的流程图;
图6是本申请数据文件的管理方法其中一个实施方式的存储结构示意图;
图7是本申请数据文件的管理方法另一个实施方式的存储结构示意图;
图8是本申请数据文件的管理方法又一个实施方式的存储结构示意图;
图9是本申请存储装置一个实施方式的结构示意图;
图10是本申请存储装置另一个实施方式的结构示意图;
图11是本申请存储装置一个实施方式中第二合并模块的结构示意图;
图12是本申请存储装置又一个实施方式的结构示意图。
具体实施方式
硬盘驱动器(Hard Disk Drive,HDD)作为存储信息的媒介广泛用于存储系统,比如数据库。基于硬盘的数据库通常采用主存(Main Memory)+HDD的两层存储结构。数据记录首先写入到主存,再在一定触发条件下持久化到硬盘。但长期以来,工业界二者发展不均衡,主存IO性能大大提高,而硬盘IO性能增长缓慢,这就造成基于硬盘的数据库的读写性能严重受限于硬盘IO。固态硬盘(Solid State Disk,SSD)的问世给数据库带来可观的优化空间。SSD具有良好的读写性能,相对于HDD更快,通常作为容量有限的读/写缓存引入到存储系统,构成了Main Memory+SSD+HDD的多层存储结构,充分发挥硬件优势,寻求性能、容量、价格三者的平衡。SSD和HDD均是非易失性存储介质。
本申请中,定义零级存储区、一级存储区和二级存储区:零级存储区特指主存;一级存储区和二级存储区是两类存储设备,其中一级存储区相对于二级存储区读写性能突出,但价格较为昂贵,如主存和SSD组合、SSD和HDD组合、HDD和磁带组合等。一级存储区和二级存储区可以理解为SSD和HDD组合,但在本申请的实施例中不仅仅局限于这种组合。在本申请中,也将一级存储区叫做增量数据存储区,而二级存储区叫做完整数据存储区。
请参阅图1,图1是分层存储结构示意图,其中,A中所示为两层存储结构示意图,B中所示为三层存储结构示意图。
在两层存储结构中,数据流向是从零级存储区向一级存储区。数据库存储引擎接收数据写入(包括插入、更新、删除)请求,数据首先写入到零级存储区内的数据集。存储引擎监控数据集,当达到一定触发条件,比如数据集大小超过一定阀值,将满足条件的数据集刷(flush)到二级存储区上的持久化数据文件。存储引擎接收数据查询(select)请求时,存储引擎将分别从零级存储区内的数据集和二级存储区上的持久化数据文件检索(retrieve)符合查询条件的数据记录片段,然后对来自这两个存储区的数据记录片段进行拼接,构成完整数据记录作为查询结果返回。
在三层存储结构中,数据流向是从零级存储区向一级存储区,再从一级存储区向二级存储区。数据库存储引擎接收数据写入(包括插入、更新、删除)请求,数据首先写入到零级存储区内的数据集。存储引擎监控数据集,当达到一定触发条件,比如数据集大小超过一定阀值,将满足条件的数据集刷到一级存储区上的持久化数据文件。当一级存储区上的持久化数据文件满足设定的触发条件时,以一定形式转移这些数据到二级存储区上的持久化数据文件。引擎接收数据查询(select)请求时,存储引擎将分别从零级存储区内的数据集、一级存储区和二级存储区上的持久化数据文件检索符合查询条件的数据记录片段,然后对来自这三个存储区的数据记录片段进行拼接,构成完整数据记录作为查询结果返回。
现有增量数据库通常采用增量写模式,从而导致一条完整Rowkey记录在存储上可以是离散在不同数据文件的Rowkey记录片段构成。这样,导致一次Rowkey精确查询多次存储器IO消耗。
基于现有技术在存储设备上形成大量数据文件,造成Rowkey离散,不利于查询操作的技术问题,本申请提供一种数据文件的管理方法及装置,能够对增量数据库的数据文件在增量数据存储区和完整数据存储区进行动态管理,使Rowkey从最初的增量数据存储区的离散状态变为完整数据存储区的集中状态,为完整数据存储区内Rowkey精确查询减少IO开销。
以下结合具体实施方式,对本申请的数据文件的管理方法及装置进行详细说明,但是并不用以限制本申请的保护范围。
请参阅图2,图2是本申请数据文件的管理方法一个实施方式的流程图,本实施方式的数据文件的管理方法包括:
步骤S101:在增量数据存储区达到第一数据文件合并条件时,将增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的主键对应的历史完整记录合并,形成每个主键对应的合并时刻的完整记录;
本申请实施方式中,主键(Rowkey)是指NoSQL所支持的嵌套结构的表格模式(Schema)的每个子表格模式的唯一性标识,以下博客为例来说明嵌套类型Schema,定义博客表(Feed_Table)的Schema:
Feed_Table的Schema包括三层子Schema,分别定义用户信息(userid、user_name)、博文信息(feed_id、feed_posttime、feed_content)、评论信息(comment_id、comment_posttime、comment_content),它们三者之间具有嵌套从属关系。用户信息、博文信息和评论信息分别具有唯一性标识,在Feed_Table中分别是userid、feed_id、comment_id,其中userid称为feed_table的主键,即rowkey。
本申请实施方式中,数据文件区分为增量数据和完整数据,对应到存储区,增量数据存储在增量数据存储区,对一个Rowkey而言,就是该Rowkey的增量数据,完整数据存储在完整数据存储区,对一个Rowkey而言,就是该Rowkey的完整数据。
用户可以根据需要预先设置增量数据存储区的数据合并条件即第一数据文件合并条件,比如预设预定时间或增量数据存储区的数据量达到预定阈值或者是只要增量数据存储区出现新的增量数据就进行增量数据存储区的数据文件合并。只要增量数据存储区的达到第一数据文件合并条件,即执行对增量数据存储区的数据文件进行合并的过程。
在对增量存储区的数据文件进行合并时,将Rockey在完整数据存储区的历史记录参与到合并过程,合并得到该Rowkey对应的合并时刻的完整记录。这个合并时刻的完整记录也可以理解为最新完整记录,是本次合并后得到的该Rowey对应的完整记录。也就是说,在下一次增量数据存储区有该Rowkey记录的数据文件合并之前,该Rowkey的记录是完整的。每个Rowkey记录形成时都带有一个新旧程度的标量(如时间戳)。
本申请实施方式中,区分历史完整记录和合并时刻的完整记录,所述历史完整记录是指在文件合并开始前,完整数据存储区上按时间由新到旧找到的该Rowkey的第一条记录,该第一记录记载了该Rowkey在文件合并之前的所有记录。对于第一次插入到完整数据存储区的Rowkey不存在历史完整记录。而所谓合并时刻的完整记录是指当前这次文件合并结束后,该Rowkey对应写入到完整数据存储区的数据文件中的所有记录(包括之前合并的和本次合并的Rowkey的记录)。这个合并时刻的完整记录具有一定的时效性,也就是说,只在下一次有该Rowkey对应的记录合并前有效。
增量数据存储区的数据文件中,数据是按Rowkey依次排列的,在进行合并时,将数据文件中的每个Rowkey的记录都与查询到的历史完整记录进行合并,得到每个Rowkey对应的合并时刻的完整记录。这里数据文件中的每个Rowkey的记录是指Rowkey对应的所有记录片段。
步骤S102:将每个主键对应的合并时刻的完整记录写入完整数据存储区的一个新建的数据文件中,其中,每个主键对应的合并时刻的完整记录作为在完整数据存储区精确查询主键的输出结果;
将进行合并后得到的每个Rowkey对应的合并时刻的完整记录都分别写入到完整数据存储区的新建的数据文件中,该新建的数据文件即进行合并后在完整数据存储区生成的目标数据文件,用于存储对增量数据存储区的数据文件进行合并而得到的每个Rowkey对应的合并时刻的完整记录。
由于在完整数据存储区对Rowkey进行精确查询时,是根据文件的生成时间顺序进行的,所以,在合并结束后,下一次该Rowkey记录合并之前,如果在完整数据存储区对Rowkey进行查询,那么该Rowkey对应的合并时刻的完整记录即为查询该Rowkey的输出结果。
上述的合并过程也可以叫纵向合并过程,是一种跨存储区的文件合并方式,其能够合并Rowkey记录片段,使Rowkey聚集,做到对于完整数据存储区的任意一次Rowkey精确查询只需要一次IO。
上述合并过程完成后,可以删除增量数据存储区的数据文件,以释放存储空间。
通过上述实施方式的阐述,可以理解,本申请数据文件的管理方法,将增量数据存储区的各数据文件中每个Rowkey对应的记录片段,分别与查找到的Rowkey对应的历史完整记录合并,形成每个Rowkey对应的合并时刻的完整记录并写入完整数据存储区,通过这样的方式,对增量数据库的数据文件在增量数据存储区和完整数据存储区进行动态管理,从而使Rowkey在完整数据存储区呈集中状态存储,为在完整数据存储区Rowkey精确查询减少IO开销。
本申请数据文件的管理方法另一个实施方式中,请参阅图3,图3是形成每个主键对应的合并时刻的完整记录的流程图,本实施方式的形成每个主键对应的合并时刻的完整记录包括以下子步骤:
子步骤S201:将增量数据存储区的数据文件按主键的排列顺序对每个主键的记录片段依次迭代得到每个主键的增量记录;
增量数据存储区n个数据文件,按照Rowkey排列顺序依次迭代,从这n个数据文件中迭代出的每个Rowkey的全部记录片段作为每个Rowkey的增量记录。
子步骤S202:从主存或完整数据存储区的数据文件中查找每个主键对应的历史完整记录;
从主存或完整数据存储区的数据文件中查找每个Rowkey对应的历史完整记录,具体查找时,先在主存的数据文件中进行查找,如果没有找到再到完整数据存储区的数据文件中进行查找。在查找的时候,根据每个主键形成时间由新到旧进行检索,直到找到Rowkey的记录,该找到的Rowkey记录就是时间戳最新的,即该Rowkey的历史完整记录。对每个Rowkey都执行以上的查找过程。
子步骤S203:判断是否查找到主键对应的历史完整记录;
在对每个Rowkey都执行完以上查找过程后,判断是否有查找到Rowkey对应的历史完整记录,对于没有找到Rowkey对应的历史完整记录的Rowkey,执行子步骤S205,对于查找到Rowkey对应的历史完整记录的Rowkey,执行子步骤S204。
子步骤S204:将每个主键的增量记录与查找到的该主键对应的历史完整记录进行合并,形成每个主键对应的合并时刻的完整记录;
对于查找到历史完整记录的Rowkey,将查找到的该Rowkey的历史完整记录与该Rowkey的增量记录进行合并,形成该Rowkey对应的合并时刻的完整记录,即最新完整记录。对于每个查找到历史完整记录的Rowkey都执行这样的合并过程,得到每个Rowkey对应的合并时刻的完整记录。
子步骤S205:将该主键的增量记录作为该主键对应的合并时刻的完整记录;
对于没有查找到历史完整记录的Rowkey,将该Rowkey的增量记录作为该Rowkey的合并时刻完整记录,写入到完整数据存储区的目标数据文件。
以下举例具体说明纵向合并过程,请参阅图6所示的存储结构示意图,如图所示:
其中,增量数据存储区中的数据文件A和数据文件B包含用户(User)1、用户2和用户3的博文(feed)增量数据,即数据文件A中包含User1的feed3、feed4以及User3的feed2和feed3,数据文件B中包含User1的feed5以及User2的feed1。这里User1、User2、User3即上文提到的不同的Rowkey。
完整数据存储区中的数据文件1和数据文件2是之前纵向或横向合并过程生成的数据文件,其中,数据文件1是在时间点t1生成,它保存了t1时刻User1和User3的完整记录,即User1的feed1和User3的feed1,是纵向文件合并或者前一轮横向文件合并的结果。数据文件2是在时间点t2生成,它保存了在t2时刻User1的完整记录,即User1的feed1和feed2,是纵向文件合并的结果。其中,t2晚于t1。数据文件3是新建数据文件,用于存储当前次纵向合并的输出结果。纵向合并具体过程如下:
(1)纵向合并开始时,从增量数据存储区的数据文件A和数据文件B按Rowkey排列顺序依次迭代,从数据文件A和数据文件B中迭代出的Rowkey记录片段作为该Rowkey的增量记录,即User1的feed3、feed4、feed5作为User1的增量记录,User2的feed1作为User2的增量记录,User3的feed2和feed3作为User3的增量记录;
(2)从主存或者完整数据存储区的数据文件中查找每个Rowkey的历史完整记录,具体为,先检索主存,没有的话再到完整数据存储区查找。查找的时候,按照每个主键形成时间由新到旧进行查找,直到找到Rowkey的记录,这个找到的记录就是时间戳最新的,即Rowkey的历史完整记录。本实施方式默认为主存都没有找到Rowkey的历史完整记录的情况。在完整数据存储区的数据文件中,首先查找User1的历史完整记录,找到数据文件2中的User1的feed1和feed2,即为User1的历史完整记录,接着用同样的方法查找User2,但没有找到对应的历史完整记录,再查找到User3的历史完整记录,即数据文件1的User3的feed1;(3)将查找到的Rowkey的历史完整记录与该Rowkey的增量记录进行合并,得到该Rowkey的最新完整记录,写入完整数据存储区的新建的数据文件。即将User1的feed1-feed5写入数据文件3,而没有历史完整记录的User2,直接将User2的增量数据feed1写入数据文件3,User3的feed1和feed2都写入完整数据存储区的数据文件3,当然,上述的写入过程也可以同时写入到主存;
(4)纵向合并完成,删除增量数据存储区的已合并的数据文件A和数据文件B,结束。
请参阅图4,图4是本申请数据文件的管理方法另一个实施方式的流程图,本实施方式的数据文件的管理方法包括以下步骤:
步骤S301:在增量数据存储区达到第一数据文件合并条件时,将增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的主键对应的历史完整记录合并,形成每个主键对应的合并时刻的完整记录;
步骤S302:将每个主键对应的合并时刻的完整记录写入完整数据存储区的一个新建的数据文件中,其中,每个主键对应的合并时刻的完整记录作为在完整数据存储区精确查询主键的输出结果;
步骤S303:删除增量数据存储区的数据文件;
在完成增量数据存储区的数据文件中每个Rowkey记录的合并以及将合并得到的每个Rowkey的合并时刻的完整记录写入完整数据存储区后,删除增量数据存储区的数据文件,为增量数据存储区释放空间以写入下一次的增量数据。
步骤S304:在完整数据存储区达到第二数据文件合并条件时,对完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除完整数据存储区的每个主键的冗余记录;
对于完成上述的跨存储区数据文件的合并之后,在完整数据存储区形成合并时刻的完整记录时,历史完整记录就变为无效,需要进行回收,以消除Rowkey冗余数据。因此,进一步进行完整存储区内部的数据文件合并过程,这个过程也可以叫做横向数据文件合并过程,是完整存储区内部的数据文件合并过程。目的是消除冗余Rowkey,舍弃无效的Rowkey记录,回收存储空间。
实际应用过程中,用户可以根据需要预先设置完整数据存储区数据合并条件即第二数据文件合并条件,比如设置预定时间或数据量达到预定阈值或者是只要完成一次增量数据存储区的数据合并之后就启动完整数据存储区的数据文件合并过程。只要实际完整数据存储区达到第二数据文件合并条件,开始对完整数据存储区的数据文件进行合并。
其中,对完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并可以采用现有技术中数据消冗的多种算法实现,比如归并算法。在数据文件的管理方法另一个实施方式中,以归并算法对完整数据存储区保存的包含各合并时刻的完整记录的各数据文件进行合并作为举例说明。请参阅图5,图5是归并算法对完整数据存储区保存的包含各合并时刻的完整记录的各数据文件进行合并的流程图,本实施方式中对完整数据存储区的保存的包含各合并时刻的完整记录的各数据文件进行合并包括以下子步骤:
子步骤S401:从完整数据存储区的保存的包含各合并时刻的完整记录的各数据文件中,查找出每个主键所在的最新的数据文件,最新的数据文件是形成时间最晚的数据文件;
完整数据存储区的包含各合并时刻的完整记录的各数据文件即为合并时刻存储在完整数据存储区内的所有数据文件。从这些数据文件中,查找出每个Rowkey所在的最新的数据文件,这个最新的数据文件是形成时间最晚的数据文件,因为完整数据存储区的每个数据文件在生成时都携带一个新旧程度的标量(如时间戳),形成时间最晚的数据文件中记载该Rowkey最新最全的记录片段。
作为一种优选的实施方式,在查找前,迭代器按照完整数据存储区的数据文件的生成顺序,对数据文件按照Rowkey大小顺序依次迭代,比如按User1、User2、User3......这样的顺序依次迭代,然后按照Rowkey大小顺序去查找每个Rowkey所在的最新数据文件。即先查找User1所在的最新数据文件,再查找User2所在的最新数据文件......依次类推。
子步骤S402:从每个主键所在的最新的数据文件中获取每个主键对应的完整记录并写入完整数据存储区的合并的数据文件,删除完整数据存储区的已完成合并的数据文件;
从每个Rowkey所在的最新的数据文件中获取Rowkey对应的记录片段并写入完整数据存储区的合并的数据文件,然后删除完整数据存储区的已完成合并的数据文件。合并的数据文件是完整数据存储区用于存储其内部的数据文件合并结果的目标数据文件。
以下举例说明上述完整数据存储区内部合并过程,请参阅图7,图7是完整数据存储区的示意图,其中,完整数据存储区的数据文件1和数据文件2是两个待合并的数据文件,数据文件3是横向合并输出的目标文件,即上述的合并的数据文件。其中,数据文件1是在时间点t1生成,它保存了t1时刻User1和User3的完整记录,即User1的feed1和User3的feed1,是纵向文件合并或者前一轮横向文件合并的结果。这里User1、User3即上文提到的不同的Rowkey。数据文件2是在时间点t2生成,它保存了在t2时刻User1的完整记录,即User1的feed1和feed2,是纵向文件合并的结果。其中,t2晚于t1。
合并开始时,(1)迭代器按照文件的生成时间顺序对数据文件1和数据文件2按Rowkey大小顺序依次迭代,取出Rowkey=User1;(2)从数据文件1和数据文件2中查找出Rowkey=User1的最新完整记录所在文件,找到数据文件2,而数据文件1已经是历史完整记录;(3)从数据文件2中读取Rowkey=User1的最新完整记录,包括feed1和feed2,将feed1和feed2拷贝到数据文件3;重复上述步骤迭代合并Rowkey=User3,它的记录只存在数据文件1中,从数据文件1中读取记录并写入数据文件3,横向数据合并完成,删除数据文件1和数据文件2。
由于采用分层存储结构,Rowkey可能在主存、增量数据存储区和完整数据存储区都有,在查询某一Rowkey,则必须从这三个存储区汇总结果。下面举例说明在采用了上述数据文件的管理方法以后,Rowkey的查询过程:
请参阅图8,图8为本申请数据文件的管理方法一个实施方式中存储结构示意图,比如要查询Rowkey=User1的记录,图中Rowkey=User1的记录在三个存储区都有分布,查询过程如下:(1)首先到主存查找Rowkey=User1的记录,找到feed5;(2)在增量数据存储区的数据文件1和数据文件2都有Rowkey=User1的记录,查找出feed3和feed4;(3)在完整数据存储区查找到数据文件1和数据文件2都有Rowkey=User1的记录,按时间戳比较可知数据文件2上的Rowkey=User1的记录是最新最全的,所以只查找出feed1和feed2,而直接忽略数据文件1;(4)汇总并返回查询结果。上述查询过程,很显然,完整数据存储区上对Rowkey的精确查找只需一次IO。
通过上述实施方式的描述,本申请数据文件的管理方法,将数据文件区分增量数据和完整数据,分级存储,分阶段合并,解决在完整数据存储区上Rowkey精确查询多次IO消耗的问题,达到在完整数据存储区上对Rowkey的精确查找只需一次IO。
请参阅图9,图9是本申请存储装置一个实施方式的结构示意图,本实施方式的存储装置100包括第一合并模块11和写入模块12,其中:
第一合并模块11用于在增量数据存储区达到第一数据文件合并条件时,将增量数据存储区中的各数据文件中每个Rowkey对应的记录片段分别与查找到的Rowkey对应的历史完整记录合并,形成每个Rowkey对应的合并时刻的完整记录并输出给写入模块12;
本申请实施方式中,数据文件区分为增量数据和完整数据,对应到存储区,增量数据存储在增量数据存储区,对一个Rowkey而言,就是该Rowkey的增量数据,完整数据存储在完整数据存储区,对一个Rowkey而言,就是该Rowkey的完整数据。
用户可以根据需要预先设置增量数据存储区的数据合并条件即第一数据文件合并条件,比如预设预定时间或增量数据存储区的数据量达到预定阈值或者是只要增量数据存储区出现新的增量数据就进行增量数据存储区的数据文件合并条件。只要增量数据存储区的达到第一数据文件合并条件,即执行对增量数据存储区的数据文件进行合并过程。
第一合并模块11在对增量存储区的数据文件进行合并时,将Rockey在完整数据存储区的历史记录参与到合并过程,合并得到该Rowkey对应的合并时刻的完整记录。这个合并时刻的完整记录也可以理解为最新完整记录,是本次合并后得到的该Rowey对应的完整记录。也就是说,在下一次有该Rowkey记录的数据文件合并之前,该Rowkey的记录是完整的。每个Rowkey记录形成时都带有一个新旧程度的标量(如时间戳)。
本申请实施方式中,区分历史完整记录和合并时刻的完整记录,所述历史完整记录是指在文件合并开始前,完整数据存储区上按时间由新到旧找到的该Rowkey的第一条记录,该第一记录记载了该Rowkey在文件合并之前的所有记录。对于第一次插入到完整数据存储区的Rowkey不存在历史完整记录。而所谓合并时刻的完整记录是指当前这次文件合并结束后,该Rowkey对应写入到完整数据存储器的新建的数据文件中的所有记录(包括之前合并的和本次合并的Rowkey的记录)。
增量数据存储区的数据文件中,数据是按Rowkey依次排列的,在进行合并时,将数据文件中的每个Rowkey的所有记录都与查询到的历史完整记录进行合并,得到每个Rowkey对应的合并时刻的完整记录。
写入模块12用于将每个Rowkey对应的合并时刻的完整记录写入完整数据存储区一个新建的数据文件中,每个Rowkey对应的合并时刻的完整记录作为下一次该Rowkey的记录合并前,在完整数据存储区精确查询该Rowkey的输出结果。
写入模块12将进行合并后得到的每个Rowkey对应的合并时刻的完整记录都分别写入到完整数据存储区的新建的数据文件中,该新建的数据文件即进行合并后在完整数据存储区生成的目标数据文件,用于存储增量数据存储区的数据文件中每个Rowkey对应的合并时刻的完整记录。
由于在完整数据存储区对Rowkey进行精确查询时,是根据文件的生成时间顺序进行的,所以,在合并结束后,下一次该Rowkey记录合并之前,如果在完整数据存储区对Rowkey进行查询,那么该Rowkey对应的合并时刻的完整记录即为查询该Rowkey的输出结果。
上述的合并过程也可以叫纵向合并过程,是一种跨存储区的文件合并方式,其能够合并Rowkey记录片段,使Rowkey聚集,做到对于完整数据存储区的任意一次Rowkey精确查询只需要一次IO。
上述合并过程完成后,写入模块12可以删除增量数据存储区的相应数据文件,以释放存储空间。
请参阅图10,图10是本申请存储装置另一个实施方式的结构示意图,本实施方式存储装置200包括第一合并模块21、写入模块22、第二合并模块23以及查找模块24,其中:
第一合并模块21用于在增量数据存储区达到第一数据文件合并条件时,将增量数据存储区中的各数据文件中每个Rowkey对应的记录片段分别与查找到的Rowkey对应的历史完整记录合并,形成每个Rowkey对应的合并时刻的完整记录并输出给写入模块22;
写入模块22用于将每个Rowkey对应的合并时刻完整记录写入完整数据存储区的一个新建的数据文件中,每个Rowkey对应的合并时刻完整记录作为下一次该Rowkey的记录合并前,在完整数据存储区精确查询该Rowkey的输出结果。
第二合并模块23用于在完整数据存储区达到第二数据文件合并条件时,对完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除完整数据存储区的每个Rowkey的冗余记录。
对于完成上述的跨存储区数据文件的合并之后,在完整数据存储区形成每个Rowkey合并时刻完整记录时,该Rowkey的历史完整记录就变为无效,需要进行回收,以消除Rowkey冗余数据。因此,第二合并模块23进一步进行完整存储区内部的数据文件合并过程,这个过程也可以叫做横向数据文件合并过程,是完整存储区内部的数据文件合并过程。目的是消除冗余Rowkey,舍弃无效的Rowkey记录,回收存储空间。
其中,第二合并模块23对完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并可以采用数据消冗的多种算法,比如归并算法。
查找模块24用于从主存或完整数据存储区的数据文件中查找每个Rowkey对应的历史完整记录,并将查找到的Rowkey对应的历史完整记录输出给第一合并模块21;
查找模块24用于在合并前,从主存或完整数据存储区的数据文件中查找每个Rowkey对应的历史完整记录,具体查找时,先在主存的数据文件中进行查找,如果没有找到再到完整数据存储区的数据文件中进行查找。在查找的时候,根据数据文件的生成顺序由新到旧进行检索,直到找到Rowkey的记录,该找到的Rowkey记录就是时间戳最新的,即该Rowkey的历史完整记录。查找模块24对每个Rowkey都执行以上的查找过程。
在查找模块24没有查找到Rowkey对应的历史完整记录时,第一合并模块21用于将增量数据存储区的数据文件中该Rowkey对应的记录片段合并,作为该Rowkey对应的合并时刻的完整记录。
其中,请参阅图11,本实施方式中第二合并模块23进一步包括查找单元111以及写入单元112,其中:
查找单元111用于从完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件中,查找出每个Rowkey所在的最新的数据文件并输出给写入单元112,最新的数据文件是指形成时间最晚的数据文件;
完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件即为合并时刻完整数据存储区内的所有数据文件。查找单元111从这些数据文件中,查找出每个Rowkey所在的最新的数据文件,这个最新的数据文件是形成时间最晚的数据文件,因为完整数据存储区的每个数据文件在生成时都携带一个新旧程度的标量(如时间戳),形成时间最晚的数据文件记载该Rowkey最新最全的记录片段。
作为一种优选的实施方式,在查找前,查找单元111按照完整数据存储区的数据文件的生成顺序,对完整数据存储区的数据文件按照Rowkey大小顺序依次迭代,比如按User1、User2、User3......这样的顺序依次迭代,然后按照Rowkey大小顺序去查找每个Rowkey所在的最新的数据文件。即先查找User1所在的最新的数据文件,再查找User2所在的最新的数据文件......依次类推。
写入单元112用于从每个Rowkey所在的最新的数据文件中获取每个Rowkey对应的完整记录并写入完整数据存储区合并的数据文件,删除完整数据存储区中保存的包含各合并时刻的完整记录的数据文件。
写入单元112从每个Rowkey所在的最新的数据文件中获取Rowkey对应的记录片段并写入完整数据存储区的合并的数据文件,然后删除完整数据存储区的已完成合并的数据文件。合并的数据文件是完整数据存储区用于存储其内部数据文件合并结果的目标文件。
请参阅图12,图12是本申请存储装置又一个实施方式的结构示意图,本实施方式的存储装置300包括处理器31、交互接口32、随机存取存储器33、只读存储器34总线35以及网络接口单元36。其中,处理器31通过总线35分别耦接交互接口32、随机存取存储器33、只读存储器34以及网络接口单元36。其中,当需要运行存储装置300时,通过固化在只读存储器34中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动,引导存储装置300进入正常运行状态。在存储装置300进入正常运行状态后,在随机存取存储器33中运行应用程序和操作系统,通过网络接口单元36从网络接收数据或者向网络发送数据,使得:
交互接口32是人机交互的设备接口,用于接收用户的操作指令,可以是USB接口、显示接口等;
处理器31在增量数据存储区达到第一数据文件合并条件时,通过交互接口接收到用户的对增量数据存储区的数据文件进行合并的操作指令时,将增量数据存储区的各数据文件中每个Rowkey对应的记录片段,分别与查找到的每个Rowkey对应的历史完整记录合并,形成每个Rowkey对应的合并时刻的完整记录,并将每个Rowkey对应的合并时刻的完整记录写入完整数据存储区的一个新建的数据文件中,每个Rowkey对应的合并时刻的完整记录作为下一次Rowkey的记录合并前,在所述完整数据存储区精确查询该Rowkey的输出结果;
另一方面,处理器31进一步根据用户的对完整数据存储区的数据进行合并的操作指令,对完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除完整数据存储区的每个Rowkey的冗余记录;
本实施方式中,处理器31可能是一个中央处理器CPU,或者是特定集成电路ASIC(Application Specific Integrated Circuit),或者是被配置成实施本申请实施方式的一个或多个集成电路。
本实施方式中,上述的增量数据存储区和完整数据存储区可以分别对应本实施方式的存储装置300的随机存取存储器33和只读存储器34。
通过以上实施方式的阐述,可以理解,本申请数据文件的管理方法及装置,将增量数据存储区的数据文件中每个Rowkey对应的记录片段,分别与查找到的Rowkey对应的历史完整记录合并,形成每个Rowkey对应的合并时刻的完整记录并写入完整数据存储区,通过这样的方式,对增量数据库的数据文件在增量数据存储区和完整数据存储区进行动态管理,从而使Rowkey在完整数据存储区呈集中状态存储,为在完整数据存储区Rowkey精确查询减少IO开销。
另外,定期对完整数据存储区的数据文件进行内部文件的合并,消除无效记录,减少Rowkey冗余度和离散度,提高Rowkey查询性能,而且能够有效的回收存储空间。
在本申请所提供的几个实施方式中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施方式仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
另外,在本申请各个实施方式中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本申请的实施方式,并非因此限制本申请的专利范围,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本申请的专利保护范围内。
Claims (13)
1.一种数据文件的管理方法,其特征在于,所述管理方法应用于三层存储结构中,所述三层存储结构包括主存、增量数据存储区、完整数据存储区,所述管理方法包括:
在所述增量数据存储区达到第一数据文件合并条件时,从所述主存或所述完整数据存储区的数据文件中查找每个主键对应的历史完整记录,将所述增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的所述主键对应的历史完整记录合并,形成所述每个主键对应的合并时刻的完整记录;
将所述每个主键对应的所述合并时刻的完整记录写入完整数据存储区的一个新建的数据文件中,其中,所述每个主键对应的所述合并时刻的完整记录作为在所述完整数据存储区精确查询所述主键的输出结果。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:将所述每个主键对应的所述合并时刻的完整记录写入主存。
3.根据权利要求1所述的方法,其特征在于,
所述方法还包括:在所述完整数据存储区达到第二数据文件合并条件时,对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录。
4.根据权利要求3所述的方法,其特征在于,所述对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录,具体为:
采用归并算法对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录。
5.根据权利要求4所述的方法,其特征在于,
所述采用归并算法对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录的步骤包括:
从所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件中,查找出每个所述主键所在的最新的数据文件,所述最新的数据文件是指形成时间最晚的数据文件;
从所述每个主键所在的最新的数据文件中获取每个所述主键对应的完整记录并写入所述完整数据存储区的合并的数据文件,删除所述完整数据存储区的已完成合并的所述数据文件。
6.根据权利要求1所述的方法,其特征在于,
所述从所述主存或所述完整数据存储区的数据文件中查找每个所述主键对应的历史完整记录的步骤包括:
按照每个所述主键对应的完整记录的形成时间由新到旧的方式在所述主存中的数据文件中进行检索,若所述主存中没有检索到,再到所述完整数据存储区的数据文件中进行检索,直到检索到所述主键对应的完整记录,所述检索到的主键的完整记录为所述主键对应的历史完整记录。
7.根据权利要求1所述的方法,其特征在于,
在没有查找到所述主键对应的历史完整记录时,所述将所述增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的所述主键对应的历史完整记录合并,形成所述每个主键对应的合并时刻的完整记录,具体为:
将所述增量数据存储区中的各数据文件中所述主键对应的记录片段合并,作为所述主键对应的所述合并时刻的完整记录。
8.根据权利要求1至7任一项所述的方法,其特征在于,所述方法还包括:删除所述增量数据存储区的所述数据文件。
9.一种存储装置,其特征在于,所述存储装置包括三层存储结构,分别为主存、增量数据存储区、完整数据存储区,所述存储装置还包括查找模块、第一合并模块以及写入模块,其中:
所述查找模块用于在增量数据存储区达到第一数据文件合并条件时,从所述主存或所述完整数据存储区的数据文件中查找每个主键对应的历史完整记录,并将查找到的每个所述主键对应的历史完整记录输出给所述第一合并模块;
所述第一合并模块用于将所述增量数据存储区中的各数据文件中每个主键对应的记录片段分别与查找到的所述主键对应的历史完整记录合并,形成所述每个主键对应的合并时刻的完整记录并输出给所述写入模块;
所述写入模块用于将所述每个主键对应的所述合并时刻的完整记录写入完整数据存储区的一个新建的数据文件中,其中,所述每个主键对应的所述合并时刻的完整记录作为在所述完整数据存储区精确查询所述主键的输出结果。
10.根据权利要求9所述的装置,其特征在于,所述写入模块还用于将所述每个主键对应的所述合并时刻的完整记录写入主存。
11.根据权利要求9所述的装置,其特征在于,所述装置还包括第二合并模块,其中:
所述第二合并模块用于在所述完整数据存储区达到第二数据文件合并条件时,对所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件进行合并,删除所述完整数据存储区的每个所述主键的冗余记录。
12.根据权利要求11所述的装置,其特征在于,所述第二合并模块包括查找单元和写入单元,其中:
所述查找单元用于从所述完整数据存储区中保存的包含各合并时刻的完整记录的各数据文件中,查找出每个所述主键所在的最新的数据文件,所述最新的数据文件是指形成时间最晚的数据文件;
所述写入单元用于从所述每个主键所在的最新的数据文件中获取每个所述主键对应的完整记录并写入所述完整数据存储区的合并的数据文件,删除所述完整数据存储区的已完成合并的所述数据文件。
13.根据权利要求9所述的装置,其特征在于,
在所述查找模块没有查找到所述主键对应的历史完整记录时,所述第一合并模块用于将所述增量数据存储区中的各数据文件中所述主键对应的记录片段合并,作为所述主键对应的所述合并时刻的完整记录。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310373456.8A CN104424219B (zh) | 2013-08-23 | 2013-08-23 | 一种数据文件的管理方法及装置 |
PCT/CN2014/079700 WO2015024406A1 (zh) | 2013-08-23 | 2014-06-12 | 一种数据文件的管理方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310373456.8A CN104424219B (zh) | 2013-08-23 | 2013-08-23 | 一种数据文件的管理方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104424219A CN104424219A (zh) | 2015-03-18 |
CN104424219B true CN104424219B (zh) | 2018-10-09 |
Family
ID=52483032
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310373456.8A Active CN104424219B (zh) | 2013-08-23 | 2013-08-23 | 一种数据文件的管理方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN104424219B (zh) |
WO (1) | WO2015024406A1 (zh) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106156070B (zh) * | 2015-03-31 | 2019-07-12 | 华为技术有限公司 | 一种查询方法、文件合并方法与相关装置 |
CN105138622B (zh) * | 2015-08-14 | 2018-05-22 | 中国科学院计算技术研究所 | 用于lsm树存储系统的插入操作及负载的读取和合并方法 |
CN107861959A (zh) * | 2016-09-22 | 2018-03-30 | 阿里巴巴集团控股有限公司 | 数据处理方法、装置及系统 |
CN107402980A (zh) * | 2017-07-06 | 2017-11-28 | 北京亿赛通网络安全技术有限公司 | 一种基于网络环境下的大数据的处理方法和系统 |
CN110019254A (zh) * | 2017-07-17 | 2019-07-16 | 中兴通讯股份有限公司 | 规划区增量记录的处理方法、装置及计算机可读存储介质 |
CN109947775B (zh) * | 2019-03-13 | 2021-03-23 | 北京微步在线科技有限公司 | 数据处理方法、装置、电子设备及计算机可读介质 |
CN111309673B (zh) * | 2020-02-12 | 2023-06-23 | 普信恒业科技发展(北京)有限公司 | 增量数据的快照数据生成方法及装置 |
CN112395276B (zh) * | 2020-11-13 | 2024-05-28 | 中国人寿保险股份有限公司 | 一种数据比对方法及相关设备 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1517918A (zh) * | 2003-01-17 | 2004-08-04 | 深圳市中兴通讯股分有限公司 | 一种备份和恢复重要数据的方法 |
CN1867902A (zh) * | 2003-08-05 | 2006-11-22 | 赛帕顿有限公司 | 仿真存储系统 |
CN101794299A (zh) * | 2010-01-27 | 2010-08-04 | 浪潮(山东)电子信息有限公司 | 一种历史数据管理的增量定义、处理方法 |
US8103448B2 (en) * | 2006-10-25 | 2012-01-24 | Denso Corporation | Information storage apparatus for storing new road, program for the same, and system for the same |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102096685B (zh) * | 2009-12-11 | 2013-04-17 | 阿里巴巴集团控股有限公司 | 分布式数据同步到数据仓库的方法及装置 |
-
2013
- 2013-08-23 CN CN201310373456.8A patent/CN104424219B/zh active Active
-
2014
- 2014-06-12 WO PCT/CN2014/079700 patent/WO2015024406A1/zh active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1517918A (zh) * | 2003-01-17 | 2004-08-04 | 深圳市中兴通讯股分有限公司 | 一种备份和恢复重要数据的方法 |
CN1867902A (zh) * | 2003-08-05 | 2006-11-22 | 赛帕顿有限公司 | 仿真存储系统 |
US8103448B2 (en) * | 2006-10-25 | 2012-01-24 | Denso Corporation | Information storage apparatus for storing new road, program for the same, and system for the same |
CN101794299A (zh) * | 2010-01-27 | 2010-08-04 | 浪潮(山东)电子信息有限公司 | 一种历史数据管理的增量定义、处理方法 |
Also Published As
Publication number | Publication date |
---|---|
CN104424219A (zh) | 2015-03-18 |
WO2015024406A1 (zh) | 2015-02-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104424219B (zh) | 一种数据文件的管理方法及装置 | |
CN107423422B (zh) | 基于网格的空间数据分布式存储及检索方法和系统 | |
US8296312B1 (en) | Search and update of attributes in file systems | |
CN107918612B (zh) | 键值存储系统数据结构的实现方法和装置 | |
CN100458779C (zh) | 扩展索引的方法 | |
US8738572B2 (en) | System and method for storing data streams in a distributed environment | |
CN103023982B (zh) | 一种云存储客户端的低延迟元数据访问方法 | |
CN113961514B (zh) | 数据查询方法及装置 | |
JP2017504924A (ja) | ファイルシステムのコンテンツベースの編成 | |
JP6598996B2 (ja) | データ準備のためのシグニチャベースのキャッシュ最適化 | |
CN104850572A (zh) | HBase非主键索引构建与查询方法及其系统 | |
CN102567434B (zh) | 一种数据块处理方法 | |
JP2005122702A5 (zh) | ||
CN104731886B (zh) | 一种海量小文件的处理方法及系统 | |
CN102169507A (zh) | 一种分布式实时搜索引擎 | |
CN102024019B (zh) | 一种分布式文件系统中基于后缀树的目录组织方法 | |
CN103019887A (zh) | 数据备份方法及装置 | |
CN111459885B (zh) | 一种数据的处理方法、装置、计算机设备和存储介质 | |
CN104054071A (zh) | 访问存储设备的方法和存储设备 | |
CN102567415B (zh) | 一种数据库的控制方法和装置 | |
CN105468644B (zh) | 一种用于在数据库中进行查询的方法与设备 | |
CN104854587A (zh) | 主动数据库查询的维护 | |
JP6598997B2 (ja) | データ準備のためのキャッシュ最適化 | |
CN103530067B (zh) | 一种数据操作的方法和设备 | |
KR101806394B1 (ko) | 모바일 dbms환경에서 트랜잭션에 특화된 색인 캐시의 구조를 갖는 데이터 처리 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |