CN108319602A - 数据库管理方法及数据库系统 - Google Patents
数据库管理方法及数据库系统 Download PDFInfo
- Publication number
- CN108319602A CN108319602A CN201710031732.0A CN201710031732A CN108319602A CN 108319602 A CN108319602 A CN 108319602A CN 201710031732 A CN201710031732 A CN 201710031732A CN 108319602 A CN108319602 A CN 108319602A
- Authority
- CN
- China
- Prior art keywords
- file
- data
- storage
- memory table
- key
- 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.)
- Granted
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/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/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/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种数据库管理方法及数据库系统。用于存储多条数据,其中,每条所述数据包括相对应的键和值,数据存储流程如下:将多条数据写入外部存储器中的日志文件;将日志文件中的数据写入内部存储器中的内存表,其中,写入内存表中的数据按照键的大小有序存储;在内存表的大小超过预定阈值时,将内存表转化为只读内存表,将日志文件中的后续数据写入新的内存表;将只读内存表中的数据写入外部存取器中,以得到第一级存储文件;合并两个或更多个第一级存储文件,以得到第二级存储文件。由此,最终存储在外部存储器中的文件仅有两层,冗余度较低,查找起来比较方便。
Description
技术领域
本发明涉及数据库存储技术领域,特别是涉及一种数据库管理方法及数据库系统。
背景技术
近年来,随着NoSql的兴起,涌现了各种KV型的存储引擎。有针对缓存的,也有针对持久化的,在持久化领域中具有代表性的要属LevelDB了。LevelDB是Google开发的高性能KV存储引擎,其灵感源自于Google的BigTable。
尽管LevelDB在小数据量的场景下,已经可以发挥非常不错的性能,然而大数据量(上百G)、高频度写入的情况下,LevelDB在读、写、合并、数据清理、重启恢复等多方面都暴露了其不足之处。如何在大数据量、高频度写入的情况下,依然保障高效的服务质量,是目前亟需解决的技术问题
发明内容
本发明的主要目的在于提供一种新的数据库管理方法及数据库系统以解决上述技术问题。
根据本发明的一个方面,提供了一种数据库管理方法,用于存储多条数据,其中,每条数据包括相对应的键和值,该方法包括:将多条数据写入外部存储器中的日志文件;将日志文件中的数据写入内部存储器中的内存表,其中,写入内存表中的数据按照键的大小有序存储;在内存表的大小超过预定阈值时,将内存表转化为只读内存表,并将日志文件中的后续数据写入新的内存表;将只读内存表中的数据写入外部存取器中,以得到第一级存储文件;以及合并两个或更多个第一级存储文件,以得到第二级存储文件。
由此,最终存储在外部存储器中的文件仅有两层,冗余度较低,查找起来比较方便。
优选地,该数据块管理方法还可以包括:以第一命名规则指定第一级存储文件的主文件名;以及以第二命名规则指定第二级存储文件的主文件名,第一命名规则与第二命名规则不同,以便基于主文件名区分存储文件是第一级存储文件还是第二级存储文件。
由此可以根据对存储文件的主文件名来确认其属于第一级存储文件还是第二级存储文件。
优选地,内存表可以由一个哈希表组成,哈希表包括一个或多个哈希桶,每个哈希桶对应一个跳表,内存表中的每条数据构成跳表的一个元素,其中,跳表中的元素的顺序是按照键的大小有序排列的。
在跳表前插入内存表,可以降低锁粒度,对于并发读写操作,如果键不相同,则可在各自的哈希桶所对应的跳表中进行快速的查找插入,另一方面,在扩大内存表的大小的同时,不至于扩大跳表的大小,这可以降低跳表随着数据量变大而变成线性查找的概率,从而提高整体的查找效率。
优选地,该数据块管理方法还可以包括:在内部存储器中维护只读内存表队列,在只读内存表中的数据未全部写入外部存储器,而新的内存表的大小超过预定阈值时,将新的内存表转化为另一个只读内存表,并放入只读内存表队列。
由此通过维护内存表队列可以应对在高频度写的时候不至于因为数据来不及合并,而内存表又写满之后出现阻塞的问题。
优选地,存储文件的数据结构可以包括:文件头,用于记录存储文件的元数据信息;数据块,用于存放值;以及索引块,用于以B+树的形式存放值对应的键,其中,所有键及其对应的值在数据块中的逻辑地址均分别记录于B+树中的叶子节点中,并且构成B+树的所有节点在物理上连续存储。
由此,可以利用磁盘的局部性预加载特点,在物理上连续存储B+树,使得在重建索引块的过程中通过简单的遍历连续的磁盘块就可以获取需要合并的文件的索引块。
优选地,合并两个第一级存储文件的步骤可以包括:在第一存储文件之后追加写入追加数据块,其中写入第二存储文件的数据块中的值;在追加数据块之后追加写入新索引块,新索引块是基于第一存储文件的索引块和第二存储文件的索引块生成的,第一存储文件的索引块和第二存储文件的索引块中的全部键及其对应的值在第一存储文件的数据块和追加数据块中的逻辑地址均分别记录于新B+树中的叶子节点中;在新索引块之后追加写入新文件头,以记录合并后的新文件的元数据信息。
由此在将两个文件进行合并时,可以保持一个文件不动,将另一个文件的值直接追加写入即可,提高了写性能。并且合并后的索引块为新的B+树,根据新的索引块可以方便地读取合并后的文件中的值,合并后的文件的读性能也不会受到影响。
优选地,元数据信息可以包括以下一项或多项:索引块中键的数量;索引块中键的范围;B+树的高度;B+树中第一个叶子节点的逻辑地址;B+树中内部节点的个数。
由此,在根据请求键读取对应的目标值时,可以根据文件的文件头中的元数据信息判断请求键是否在该文件的键的范围内,判定为是的情况下,再在该文件的索引块中查找,可以减少不必要的查找。
优选地,该数据库管理方法还可以包括:根据新文件头更新第一存储文件的文件头,以用新文件头中的元数据信息替换第一存储文件的文件头中的元数据信息。
由于追加写入是一种破坏性写入,由此本发明通过设置双文件头可以避免合并过程中异常情况发生对文件造成的破坏。
优选地,文件可以包括位于文件头部的前文件头和位于文件尾部的后文件头,前文件头和后文件头的内容相同,根据新文件头更新第一存储文件的前文件头,作为新文件的前文件头,而以新文件头作为新文件的后文件头。
由此,合并正常完成时,新文件的前文件头和后文件头都能得到正常更新,都可以用来查看新文件中的元数据信息。
优选地,该数据库管理方法还可以包括:在新文件头中写入新文件的元数据信息的步骤出错的情况下,根据第一存储文件的文件头将新文件还原为合并前的第一存储文件;以及/或者在更新第一存储文件的文件头的步骤出错的情况下,根据新文件头重新更新第一存储文件的文件头。
由此,在写入新文件头的过程中出错时,由于第一存储文件的文件头尚未得到更新,因此可以根据第一存储文件的文件头将合并过程中的文件还原为合并前的第一存储文件,在更新第一存储文件的文件头的过程中出错时,则可以根据新文件头重新更新。
优选地,该数据库管理方法还可以包括:响应于查找请求键所对应的目标值的请求,在内存表中查找是否具有与请求键对应的键,在查找到的情况下读取目标值;在内存表中查到不到请求键的情况下,从只读内存表中查找是否具有与请求键对应的键,在查找到的情况下读取目标值;在只读内存表中查到不到请求键的情况下,按照时间顺序逐个查找磁盘中各个第一级存储文件中是否具有与请求键对应的键,在查找到的情况下读取目标值;以及在各个第一级存储文件中查到不到的情况下,使用折半查找的方式查找磁盘中第二级存储文件中是否具有与请求键对应的键,在查找到的情况下读取目标值。
优选地,该数据库管理方法还可以包括:响应于从目标存储文件中读取请求键所对应的目标值的请求,获取目标存储文件的文件头和索引块;根据文件头判断请求键是否在文件头所指示的键的范围内;在判定请求键在文件头所指示的键的范围内的情况下,基于索引块的B+树结构,在索引块中查找对应于请求键的叶子节点;在查找到的情况下,根据所查找到的叶子节点所存储的键所对应的值在目标存储文件中的数据块中的逻辑地址读取目标值。
优选地,该数据库管理方法还可以包括:响应于重启恢复内部存储器的请求,根据第二级存储文件所包含的键的范围的大小顺序,构建第二级存储文件列表;根据第一级存储文件的文件序号顺序,构建第一级存储文件列表;根据第一级存储文件列表和第二级存储文件列表,判断日志文件中的数据被写入到第一级存储文件的写入进度;以及根据写入进度,将日志文件中未写入到第一级存储文件的数据写入内部存储器中的内存表。
根据本发明的另一个方面,还提供了一种数据库系统,包括:内部存储器和外部存储器,其中,内部存储器用于将多条数据写入外部存储器中的日志文件,外部存储器将日志文件中的数据写入内部存储器中的内存表,其中写入内存表中的数据按照键的大小有序存储,在内存表的大小超过预定阈值时,内部存储器将内存表转化为只读内存表,外部存储器将日志文件中的后续数据写入新的内存表,内部存储器将只读内存表中的数据写入外部存取器中,以得到第一级存储文件,外部存储器合并两个或更多个第一级存储文,以得到第二级存储文件。
优选地,外部存储器以第一命名规则指定第一级存储文件的主文件名,并且以第二命名规则指定第二级存储文件的主文件名,第一命名规则与第二命名规则不同,以便基于主文件名区分存储文件是第一级存储文件还是第二级存储文件。
优选地,内存表由一个哈希表组成,哈希表包括一个或多个哈希桶,每个哈希桶对应一个跳表,内存表中的每条数据构成跳表的一个元素,其中,跳表中的元素的顺序是按照键的大小有序排列的。
优选地,在内部存储器中维护只读内存表队列,在只读内存表中的数据未全部写入外部存储器,而新的内存表的大小超过预定阈值时,外部存储器将新的内存表转化为另一个只读内存表,并放入只读内存表队列。
优选地,存储文件的数据结构可以包括:文件头,用于记录存储文件的元数据信息;数据块,用于存放值;以及索引块,用于以B+树的形式存放值对应的键,其中,所有键及其对应的值在数据块中的逻辑地址均分别记录于B+树中的叶子节点中,并且构成B+树的所有节点在物理上连续存储。
优选地,外部存储器通过执行以下操作合并两个第一级存储文件:在第一存储文件之后追加写入追加数据块,其中写入第二存储文件的数据块中的值;在追加数据块之后追加写入新索引块,新索引块是基于第一存储文件的索引块和第二存储文件的索引块生成的,第一存储文件的索引块和第二存储文件的索引块中的全部有效键及其对应的值在第一存储文件的数据块和追加数据块中的逻辑地址均分别记录于新B+树中的叶子节点中;在新索引块之后追加写入新文件头,以记录合并后的新文件的元数据信息。
利用本发明的数据库管理方法及数据库系统,最终存储在外部存储器中的文件仅有两层层级结构,文件冗余度较低,查找起来比较方便。
附图说明
通过结合附图对本公开示例性实施方式进行更详细的描述,本公开的上述以及其它目的、特征和优势将变得更加明显,其中,在本公开示例性实施方式中,相同的参考标号通常代表相同部件。
图1是示出了根据本发明一实施例的数据库系统的结构示意图。
图2是示出了内部存储器110和外部存储器120之间的数据存储流程图。
图3是示出了存储数据过程中的静态示意图。
图4、图5是示出了存储文件可以具有的数据结构的示意图。
图6是示出了根据本发明一实施例的存储文件合并方法的示意性流程图。
图7是示出了根据本发明一实施例的将G文件合并到F文件的合并过程的示意图。
图8是示出了根据本发明另一实施例的将G文件合并到F文件的合并过程的示意图。
图9是示出了一次完整查找的流程示意图。
图10是示出了在文件内部查找的流程示意图。
图11是示出了根据本发明一实施例的重启恢复过的示意性流程图。
具体实施方式
下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式,然而应该理解,可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
如前所述,LevelDB在读、写、合并、数据清理、重启恢复等多方面都暴露了许多不足,针对于此,本发明提出了一种新的数据库管理方法及数据库系统。
图1是示出了根据本发明一实施例的数据库系统的结构示意图。如图1所示,本发明的数据库系统100主要包括内部存储器110和外部存储器120。内部存储器110和外部存储器120可以相互配合以完成数据存储。
图2是示出了内部存储器110和外部存储器120之间相配合以实现数据存储的流程图。
参见图2,首先在步骤S110,可以由内部存储器110将需要存储的多条数据写入外部存储器120中的日志文件。其中,每条数据包括相对应的键和值,此处可以按照数据到来的时间顺序依次写入日志文件。
然后可以执行步骤S120,由外部存储器120将日志文件中的数据写入内部存储器110中的内存表。其中,写入内存表中的数据可以按照键的大小有序存储。例如,内存表中存储的数据可以采用跳表结构,以使得内存表中存储的数据按照键的大小有序排列。作为本发明的一个优选实施例,内存表可以由一个哈希表组成,此处的哈希表可以包括一个或多个哈希桶,每个哈希桶对应一个跳表,内存表中的每条数据构成跳表的一个元素,其中,跳表中的元素的顺序是按照键的大小有序排列的。
由此,在跳表前嵌入一个哈希表,这样一方面可以降低锁粒度,对于并发读写操作,如果键不相同,则可在各自的哈希桶所对应的跳表中进行快速的查找插入。另一方面,在扩大内存表的大小的同时,不至于扩大跳表的大小,这可以降低跳表随着数据量变大而变成线性查找的概率,从而提高整体的查找效率。
在写入内存表的数据逐渐增多,以至于内存表的大小超过预定阈值时,内部存储器110可以将内存表转化为只读内存表(步骤S130),此时日志文件中未写入内部存储器110的数据可以写入新的内存表中。顾名思义,只读内存表只可以读取,不可以写入。
需要说明的是,外部存储器120中的日志文件和内部存储器110中的内存表可以是一一对应的,即对于一条key-Value数据来说,可以将其写入日志文件,然后再从日志文件写入内存表,在内存表的大小超过预定阈值需要转换为只读内存表时,新到来的数据可以写入新的日志文件,新的日志文件中的数据可以写入新的内存表。
在内存表转化为只读内存表后,可以执行步骤S140,可以由内部存储器110将只读内存表中的数据写入外部存储器120,以得到第一级存储文件。外部存储器120可以执行步骤S150,对存储在其内的两个或更多个第一级存储文件进行合并,以得到第二级存储文件。
另外,外部存储器120可以以第一命名规则指定第一级存储文件的主文件名,并可以以第二命名规则指定第二级存储文件的主文件名,此处第一命名规则与第二命名规则不同,以便基于主文件名区分存储文件是第一级存储文件还是第二级存储文件。例如,可以在第一级存储文件的主文件名后加上“_0”,在第二级存储文件的主文件名后加上“_1”来区分。即可以以xxx_0.hdb,xxx_1.hdb分别命名第一级存储文件和第二级存储文件。
至此,结合图2简要说明了数据库系统中外部存储器和内部存储器相配合以实现将数据持久化存储到外部存储器的存储流程。图3是示出了存储数据过程中的静态示意图。
如图3所示,可以在内部存储器中维护只读内存表队列,在只读内存表中的数据未全部写入外部存储器,而新的内存表的大小超过预定阈值时,将新的内存表转化为另一个只读内存表,并放入只读内存表队列。由此通过维护内存表队列可以应对在高频度写的时候不至于因为数据来不及合并,而内存表又写满之后出现阻塞的问题。
至此结合图1至图3描述了本发明的数据库系统的结构以及数据库系统将数据持久化存储到外部存储器中的数据存储流程。下面就持久化存储到外部存储器中的存储文件的合并过程、数据查找过程、在特殊情况下重启数据库系统时的数据恢复过程分别进行说明。
一、存储文件合并过程
在详细说明本发明的文件合并过程前,首先就持久化存储在外部存储器中的存储文件的数据结构仅说明。
图4是示出了存储在外部存储器中的存储文件的数据结构的示意图。如图4所示,本发明述及的文件在物理上可以按块分为文件头、数据块以及索引块,每个区块可以由多个页组成。其中,本文述及的页是一次I/O的最小单位,一般是系统页的整数倍,不同类型块的页的大小可以不一样。
数据块用于存放值(Value)。索引块用于以B+树的形式存放值所对应的键(Key),此处关于B+树的形式为本领域技术人员所公知,这里不再赘述。需要说明的是,B+树中每个叶子节点对应一个键,所有键及其对应的值在数据块中的逻辑地址均分别记录于B+树中的叶子节点中。即B+树的叶子节点中只存放键,而没有存放值,取而代之可以存放值所在数据块中页的偏移量及值在页内的偏移量。
优选地,构成B+树的所有节点(根节点、内部节点、叶子节点)在物理上连续存储,由此可以利用磁盘的局部性预加载特点,快速获取B+树中的全部节点,可以提高合并过程中构建新B+树的效率(合并过程将在下文详细说明)。
文件头用于记录文件的元数据信息。其中,元数据信息可以包括索引块中键的数量、索引块中键的范围、B+树的高度、B+树中第一个叶子节点的逻辑地址以及B+树中内部节点的个数等等。
至此,结合图4简要说明了存储在外部存储器中的存储文件的数据结构。其中,图4所示的文件的数据结构仅是一种示例,应该知道,其还可以具有多种变形形式。例如图5所示,存储文件的文件头可以包括前文件头和后文件头,前文件头和后文件头记录的文件的元数据信息可以相同。再例如,存储文件还可以包括过滤器(Filter),过滤器可以用于确定访问的键是否在文件中,例如过滤器可以是布隆过滤器,对于访问到不存在的key,可以通过布隆过滤器快速判断key是不存在的,而不用再去B+树里面查询。因为布隆过滤器实际上是一个哈希表,可以在O(1)的复杂度内判断key存在与否,而B+树的查找时间复杂度是O(logn),所以设置布隆过滤器可以提高查找效率,即可以提升读性能。
下面结合图6至图8详细说明存储文件的合并过程。图6是示出了根据本发明一实施例的存储文件合并方法的示意性流程图。该方法可以将两个或更多个存储文件进行合并,其中,可以将两个或更多个第一级存储文件合并为一个第二级存储文件,也可以合并两个或更多个第二级存储文件,生成新的第二级存储文件。为了便于描述,这里以将第一存储文件和第二存储文件进行合并为例来说明本发明的存储文件的合并过程。
参见图6,在步骤S210,在第一存储文件之后追加写入追加数据块,其中写入第二存储文件的数据块中的值。
此处第二存储文件的新鲜度可以大于第一存储文件,即第二存储文件可以是在后存储在外部存储器中的,第一存储文件可以是在先存储在外部存储器中的。
由于存储文件中的值和键是分开存储的,因此在将第一存储文件和第二存储文件合并时,可以在第一存储文件之后追加写入第二存储文件的数据块中的值,这里可以在第一存储文件之后追加写入值的块称为追加数据块。也就是说可以在第一存储文件之后的追加数据块中重新写入第二存储文件的数据块中的值,从而物理上文件F的结尾和追加数据块的地址连续。
在第一存储文件之后追加写入第二存储文件的数据块中的值后,就可以建立新的索引信息,即步骤S220,在追加数据块之后追加写入新索引块。
此处新索引块是基于第一存储文件的索引块和第二存储文件的索引块生成的。如上文所述,第二存储文件的新鲜度可以大于第一存储文件,因此第二存储文件中的键值有可能是对第一存储文件中的键值的修改、删除、替换等,因此对于第一存储文件和第二存储文件的索引块中存在的相同的键,可以选取新鲜度较高的第二存储文件中的键作为有效键,摒弃第一存储文件中的键,以此构建新索引块。
也就是说,生成的新索引块中的键均为有效键,其对应的值均为有效值。其中新索引块中的键也是以B+树的形式存储的,该B+树是根据第一存储文件的索引块和第二存储文件的索引块重新生成的,因此可以称为新B+树。第一存储文件的索引块和第二存储文件的索引块中的全部有效键及其对应的值在第一存储文件的数据块和所述追加数据块中的逻辑地址均分别记录于新B+树中的叶子节点中。
正如上文所述,第一存储文件的索引块和第二存储文件的索引块中的B+树的所有节点在物理上是连续存储的,因此在重新构建新B+树的过程中,可以利用磁盘的局部性预加载特点,通过简单的遍历连续的磁盘块就可以获取第一存储文件的索引块和第二存储文件的索引块,从而可以提高新B+树的构造效率。
在构造新B+树以生成新索引块后,第一存储文件中的索引块被无效,由新索引块代替。其中,这里述及的无效是指在后续查找过程中,使用新索引块进行查找,而不再使用旧的索引块。即在生成新索引块后,可以不删除旧索引块。
在步骤S230,在新索引块之后追加写入新文件头,以记录合并后的新文件的元数据信息。
新文件的元数据信息可以包括新索引块中键的数量、新索引块中键的范围、新B+树的高度、新B+树中第一个叶子节点的逻辑地址以及新B+树中内部节点的个数等等。在生成新文件头后,可以删除第二存储文件,释放存储空间。
图7是示出了根据本发明一实施例的将G文件合并到F文件的合并过程的示意图。
根据图7以及上文结合图6的描述可知,在合并过程中,F文件不变,仅需把G文件中的值追加写入F文件,并生成新的索引块和新文件头即可。与现有LevelDB中合并时需要一一取出键值对重新构造相比,合并过程较为简单,并且根据合并后的B+树可以方便地查找文件中的键所对应的值,读性能也得到了提升。
图8是示出了根据本发明另一实施例的将G文件合并到F文件的合并过程的示意图。
与图7不同的是,图8中的F文件和G文件都包括位于文件头部的前文件头和位于文件尾部的后文件头。其中,前文件头和后文件头的内容相同。
与上文述及的合并过程不同的是,在追加写入新文件头后,还可以根据新文件头更新F文件的前文件头,作为新文件的前文件头,而以新文件头作为新文件的后文件头。
由此在文件合并过程中,可以维护两个文件头,这是因为,合并过程中的追加写入也是一种“破坏性写入”,即在将G文件合并到F文件时,是会破坏F文件的。其中,这里述及的破坏性写入是指在将G文件合并到F文件时,合并后的新文件的新文件头记录的是合并后的新文件的元数据信息,合并前的F文件的文件头被无效,因此如果没有采用防护措施,一旦合并过程失败,F文件将无法被修复。采用维护双文件头的方式,可以解决因异常情况导致文件被破坏而无法恢复的问题。
具体来说,合并正常完成时,新文件的首尾两个文件头都能得到正常更新,且是一样的。在出现异常情况需要恢复时,随便以那个文件头为准都没问题。
如果在还没写完末尾的新文件头时,发生异常。由于此时首部的文件头并尚未得到更新,还是完好的,只不过是旧的而已。通过该文件头,可将上次合并未完成的残余信息截断,得到一个旧版的完整的文件。
如果在更新前文件头时,发生异常。由于此时新文件头已经是完整的了,恢复时,只要以新文件头为准即可。即可以用新文件头重新更新前文件头,以保障两个文件头在初始状态时的完整性和一致性。
二、数据查找过程
根据上文对数据存储过程的描述可知,在将数据持久化存储到外部存储器中的存储文件中时,存储流程是先写入内存表,然后再写入只读内存表、继而写入到外部存储器中的第一级存储文件,第一级存储文件合并成第二级存储文件。因此,数据的新鲜度是按照内存表、只读内存表、第一级存储文件、第二级存储文件递减的。
所以在读取数据时,可以先从内存表读取,在内存表读取不到的情况下,再从只读内存表读取,只读内存表也读取不到的情况下,再从外部存储器中的第一级存储文件中查找,第一存储文件中查找不到,再从第二级存储文件中查找。
图9是示出了一次完整查找的流程示意图。参见图8,首先可以执行步骤S210,在内存表中查找是否具有与请求键对应的键。例如,在内存表中的数据是以哈希表加跳表的形式存储时,可以先根据请求键定位到内存表中的具体哈希桶,之后再在对应的跳表内查找。
在内存表中查找到的情况下,直接读取即可。在内存表中查找不到的情况下,可以继续在内部存储器中的只读内存表中查找是否具有请求键对应的键(步骤S220)。其中,在内存存储器维护了具有多个只读内存表的只读内存表队列时,可以按照时间顺序逐个查找只读内存表队列中的只读内存表。
在只读内存表中查找不到的情况下,可以从外部存储器中的第一级存储文件中查找,此处可以按照时间顺序逐个查找外部存储器中各个第一级存储文件是否具有请求键对应的键(步骤S230)。
在查找到某个第一级存储文件具有请求键对应的键的情况下,可以从该第一级存储文件中读取对应于请求键的值。在查找不到的情况下,可以从外部存储器中的第二级存储文件中查找,此处可以使用折半查找的方便时查找第二级存储文件中是否具有请求键对应的值(步骤S240).
在查找到某个第二级存储文件具有请求键对应的键的情况下,可以从该第二级存储文件中读取对应于请求键的值。在查找不到的情况下,表明数据库系统中没有存储该请求键及对应的值。
图10是示出了在文件内部查找的流程示意图。参见图10,首先可以获取目标存储文件的文件头和索引块(步骤S310),然后执行步骤S320,根据文件头判断请求键是否在文件头所指示的键的范围内,不在的话,表明目标存储文件中不存在请求键所对应的值,读取结束。
在判定请求键在范围内的情况下,可以执行步骤S330,基于索引块的B+树结构,在索引块中查找对应于请求键的叶子节点。在索引块中查找不到与请求键对应的叶子节点的情况下,表明目标存储文件中不存在请求键所对应的值,读取结束。在查找到的情况下,可以执行步骤S340,根据所查找到的叶子节点所存储的键所对应的值在目标存储文件中的数据块中的逻辑地址读取目标值。
三、重启恢复过程
在LevelDB中,重启是一件令人苦恼的事。因为它需要从MANIFEST和Current两个清单文件中来恢复内部存储器中的数据,随着数据量的增长,这两个文件可能会很大,尤其是Current文件,上GB的情况也是很常见。以致有时重启得要花上数十分钟,更糟糕的,如果清单文件丢失,整个库都将不可用。而在本发明的数据库系统中,因每个文件的描述信息都在其自身的索引块、文件头等块中完整描述,而这些块的信息往往都不大,重启时,只要从这几个块中读取相应的信息,就能完整的恢复出整个文件的元数据。即便某个文件损坏,亦不会导致整个库不可用,即便是百GB级的库,亦可以在秒级内完成恢复重启。
图11是示出了根据本发明一实施例的重启恢复过的示意性流程图。其中,步骤S410和步骤S420之间的先后顺序不做要求,可以同时执行,也可以异时执行。
参见图11,在步骤S410,构建第二级存储文件列表。具体地,可以通过内存映射的方式,预载入第二级存储文件的索引块、过滤器块(有的情况下)、文件头等,然后根据键的范围顺序,构建第二级存储文件列表。
在步骤S420,构建第一级存储文件列表。具体地,可以通过内存映射的方式,预载入第一级存储文件的索引块、过滤器块(有的情况下)、文件头等,然后根据键的范围顺序,构建第一级存储文件列表。
在构建好第一级存储文件列表和第二级存储文件列表后,就可以判断日志文件中被写入到第一级存储文件的写入进入(步骤S430),以使得可以根据写入进度,构建内部存储器中的内存表和只读内存表(步骤S440)。
如上文所述,写入外部存储器中的日志文件可以有多个,分别与内存表(或者说只读内存表)一一对应,因此可以根据构建好的第一文件列表和第二文件列表判断多个日志文件中那些日志文件中的数据没有写入存储文件。然后可以将没有写入存储文件的日志文件转化为只读内存表,其中,对于最后生成的日志文件,可以将该日志文件中的数据写入内存表。由此,就可以完成内部存储器中内存表和只读内存表的恢复。
上文中已经参考附图详细描述了根据本发明的数据库管理方法及数据库系统。
此外,根据本发明的方法还可以实现为一种计算机程序,该计算机程序包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。或者,根据本发明的方法还可以实现为一种计算机程序产品,该计算机程序产品包括计算机可读介质,在该计算机可读介质上存储有用于执行本发明的上述方法中限定的上述功能的计算机程序。本领域技术人员还将明白的是,结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。
附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
以上已经描述了本发明的各实施例,上述说明是示例性的,并非穷尽性的,并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择,旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进,或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。
Claims (19)
1.一种数据库管理方法,用于存储多条数据,其中,每条所述数据包括相对应的键和值,该方法包括:
将所述多条数据写入外部存储器中的日志文件;
将所述日志文件中的数据写入内部存储器中的内存表,其中,写入所述内存表中的数据按照键的大小有序存储;
在所述内存表的大小超过预定阈值时,将所述内存表转化为只读内存表,并将所述日志文件中的后续数据写入新的内存表;
将所述只读内存表中的数据写入外部存取器中,以得到第一级存储文件;以及
合并两个或更多个第一级存储文件,以得到第二级存储文件。
2.根据权利要求1所述的数据块管理方法,还包括:
以第一命名规则指定所述第一级存储文件的主文件名;以及
以第二命名规则指定所述第二级存储文件的主文件名,所述第一命名规则与所述第二命名规则不同,以便基于主文件名区分存储文件是第一级存储文件还是第二级存储文件。
3.根据权利要求1所述的数据库管理方法,其中,所述内存表由一个哈希表组成,所述哈希表包括一个或多个哈希桶,每个哈希桶对应一个跳表,所述内存表中的每条数据构成所述跳表的一个元素,其中,所述跳表中的元素的顺序是按照键的大小有序排列的。
4.根据权利要求1所述的数据库管理方法,还包括:
在所述内部存储器中维护只读内存表队列,在所述只读内存表中的数据未全部写入外部存储器,而新的内存表的大小超过预定阈值时,将所述新的内存表转化为另一个只读内存表,并放入所述只读内存表队列。
5.根据权利要求1所述的数据库管理方法,其中,所述存储文件的数据结构包括:
文件头,用于记录所述存储文件的元数据信息;
数据块,用于存放值;以及
索引块,用于以B+树的形式存放所述值对应的键,其中,所有键及其对应的值在所述数据块中的逻辑地址均分别记录于所述B+树中的叶子节点中,并且构成所述B+树的所有节点在物理上连续存储。
6.根据权利要求5所述的数据库管理方法,其中,所述合并两个第一级存储文件的步骤包括:
在第一存储文件之后追加写入追加数据块,其中写入第二存储文件的数据块中的值;
在所述追加数据块之后追加写入新索引块,所述新索引块是基于所述第一存储文件的索引块和所述第二存储文件的索引块生成的,所述第一存储文件的索引块和所述第二存储文件的索引块中的全部有效键及其对应的值在所述第一存储文件的数据块和所述追加数据块中的逻辑地址均分别记录于新B+树中的叶子节点中;
在所述新索引块之后追加写入新文件头,以记录合并后的新文件的元数据信息。
7.根据权利要求6所述的数据库管理方法,其中,所述元数据信息包括以下一项或多项:
所述索引块中键的数量;
所述索引块中键的范围;
所述B+树的高度;
所述B+树中第一个叶子节点的逻辑地址;
所述B+树中内部节点的个数。
8.根据权利要求6所述的数据库管理方法,还包括:
根据所述新文件头更新所述第一存储文件的文件头,以用所述新文件头中的元数据信息替换所述第一存储文件的文件头中的元数据信息。
9.根据权利要求8所述的数据库管理方法,其中,
所述文件包括位于文件头部的前文件头和位于文件尾部的后文件头,所述前文件头和所述后文件头的内容相同,
根据所述新文件头更新所述第一存储文件的前文件头,作为新文件的前文件头,而以所述新文件头作为新文件的后文件头。
10.根据权利要求8或9所述的数据库管理方法,还包括:
在所述新文件头中写入新文件的元数据信息的步骤出错的情况下,根据所述第一存储文件的文件头将新文件还原为合并前的所述第一存储文件;以及/或者
在更新所述第一存储文件的文件头的步骤出错的情况下,根据所述新文件头重新更新所述第一存储文件的文件头。
11.根据权利要求1-9中任何一项所述的数据库管理方法,还包括:
响应于查找请求键所对应的目标值的请求,在内存表中查找是否具有与所述请求键对应的键,在查找到的情况下读取所述目标值;
在所述内存表中查到不到所述请求键的情况下,从所述只读内存表中查找是否具有与所述请求键对应的键,在查找到的情况下读取所述目标值;
在所述只读内存表中查到不到所述请求键的情况下,按照时间顺序逐个查找外部存储器中各个所述第一级存储文件中是否具有与所述请求键对应的键,在查找到的情况下读取所述目标值;以及
在各个所述第一级存储文件中查到不到的情况下,使用折半查找的方式查找所述磁盘中第二级存储文件中是否具有与所述请求键对应的键,在查找到的情况下读取所述目标值。
12.根据权利要求11所述的数据库管理方法,还包括:
响应于从目标存储文件中读取请求键所对应的目标值的请求,获取目标存储文件的文件头和索引块;
根据所述文件头判断所述请求键是否在所述文件头所指示的键的范围内;
在判定所述请求键在所述文件头所指示的键的范围内的情况下,基于所述索引块的B+树结构,在所述索引块中查找对应于所述请求键的叶子节点;
在查找到的情况下,根据所查找到的叶子节点所存储的键所对应的值在所述目标存储文件中的数据块中的逻辑地址读取所述目标值。
13.根据权利1-9中任何一项所述的数据库管理方法,还包括:
响应于重启恢复内部存储器的请求,根据第二级存储文件所包含的键的范围的大小顺序,构建第二级存储文件列表;
根据第一级存储文件的文件序号顺序,构建第一级存储文件列表;
根据所述第一级存储文件列表和所述第二级存储文件列表,判断所述日志文件中的数据被写入到第一级存储文件的写入进度;以及
根据所述写入进度,构建所述内部存储器中的内存表和只读内存表。
14.一种数据库系统,包括:内部存储器和外部存储器,其中,
所述内部存储器用于将多条数据写入外部存储器中的日志文件,
所述外部存储器将所述日志文件中的数据写入内部存储器中的内存表,其中写入所述内存表中的数据按照键的大小有序存储,
在所述内存表的大小超过预定阈值时,所述内部存储器将所述内存表转化为只读内存表,所述外部存储器将所述日志文件中的后续数据写入新的内存表,
所述内部存储器将所述只读内存表中的数据写入外部存取器中,以得到第一级存储文件,
所述外部存储器合并两个或更多个第一级存储文,以得到第二级存储文件。
15.根据权利要求14所述的数据库系统,其中,
所述外部存储器以第一命名规则指定所述第一级存储文件的主文件名,并且以第二命名规则指定所述第二级存储文件的主文件名,所述第一命名规则与所述第二命名规则不同,以便基于主文件名区分存储文件是第一级存储文件还是第二级存储文件。
16.根据权利要求14所述的数据库系统,其中,所述内存表由一个哈希表组成,所述哈希表包括一个或多个哈希桶,每个哈希桶对应一个跳表,所述内存表中的每条数据构成所述跳表的一个元素,其中,所述跳表中的元素的顺序是按照键的大小有序排列的。
17.根据权利要求14所述的数据库系统,其中,
在所述内部存储器中维护只读内存表队列,在所述只读内存表中的数据未全部写入外部存储器,而新的内存表的大小超过预定阈值时,所述外部存储器将所述新的内存表转化为另一个只读内存表,并放入所述只读内存表队列。
18.根据权利要求14所述的数据库系统,其中,所述存储文件的数据结构包括:
文件头,用于记录所述存储文件的元数据信息;
数据块,用于存放值;以及
索引块,用于以B+树的形式存放所述值对应的键,其中,所有键及其对应的值在所述数据块中的逻辑地址均分别记录于所述B+树中的叶子节点中,并且构成所述B+树的所有节点在物理上连续存储。
19.根据权利要求18所述的数据库系统,其中,所述外部存储器通过执行以下操作合并两个第一级存储文件:
在第一存储文件之后追加写入追加数据块,其中写入第二存储文件的数据块中的值;
在所述追加数据块之后追加写入新索引块,所述新索引块是基于所述第一存储文件的索引块和所述第二存储文件的索引块生成的,所述第一存储文件的索引块和所述第二存储文件的索引块中的全部键及其对应的值在所述第一存储文件的数据块和所述追加数据块中的逻辑地址均分别记录于新B+树中的叶子节点中;
在所述新索引块之后追加写入新文件头,以记录合并后的新文件的元数据信息。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710031732.0A CN108319602B (zh) | 2017-01-17 | 2017-01-17 | 数据库管理方法及数据库系统 |
PCT/CN2018/072641 WO2018133762A1 (zh) | 2017-01-17 | 2018-01-15 | 文件合并方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710031732.0A CN108319602B (zh) | 2017-01-17 | 2017-01-17 | 数据库管理方法及数据库系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108319602A true CN108319602A (zh) | 2018-07-24 |
CN108319602B CN108319602B (zh) | 2020-10-16 |
Family
ID=62891040
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710031732.0A Active CN108319602B (zh) | 2017-01-17 | 2017-01-17 | 数据库管理方法及数据库系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108319602B (zh) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109213444A (zh) * | 2018-08-17 | 2019-01-15 | 上海小蚁科技有限公司 | 文件存储方法及装置、存储介质、终端 |
CN109271570A (zh) * | 2018-10-30 | 2019-01-25 | 郑州云海信息技术有限公司 | 一种元数据管理查询的方法 |
CN109614411A (zh) * | 2018-11-19 | 2019-04-12 | 杭州复杂美科技有限公司 | 数据存储方法、设备和存储介质 |
CN109656926A (zh) * | 2018-12-24 | 2019-04-19 | 杰信软件科技(苏州)有限公司 | 数据库的管理方法 |
CN109885573A (zh) * | 2019-02-22 | 2019-06-14 | 广州荔支网络技术有限公司 | 一种数据存储系统的维护方法、装置和移动终端 |
CN112433671A (zh) * | 2020-10-29 | 2021-03-02 | 苏州浪潮智能科技有限公司 | 一种数据持久化方法、系统、设备以及介质 |
CN112487095A (zh) * | 2020-12-09 | 2021-03-12 | 浪潮云信息技术股份公司 | 一种分布式数据库事务数据存储优化的方法 |
CN113051241A (zh) * | 2019-12-27 | 2021-06-29 | 中国移动通信集团湖南有限公司 | 数据库持久化的方法、装置及设备 |
CN113377292A (zh) * | 2021-07-02 | 2021-09-10 | 北京青云科技股份有限公司 | 一种单机存储引擎 |
CN113468080A (zh) * | 2021-06-10 | 2021-10-01 | 山东英信计算机技术有限公司 | 一种全闪元数据的缓存方法、系统及相关装置 |
CN113515518A (zh) * | 2020-04-10 | 2021-10-19 | 腾讯科技(深圳)有限公司 | 数据存储方法、装置、计算机设备和存储介质 |
CN113535714A (zh) * | 2021-06-18 | 2021-10-22 | 深圳市汉云科技有限公司 | 数据的存储方法、读取方法及计算机设备 |
CN113778951A (zh) * | 2021-09-16 | 2021-12-10 | 平安国际智慧城市科技股份有限公司 | 文件的追加方法、装置、设备以及存储介质 |
CN113821704A (zh) * | 2020-06-18 | 2021-12-21 | 华为技术有限公司 | 构建索引的方法、装置、电子设备和存储介质 |
CN114328545A (zh) * | 2022-03-03 | 2022-04-12 | 北京蚂蚁云金融信息服务有限公司 | 数据存储及查询方法、装置及数据库系统 |
WO2022183904A1 (en) * | 2021-03-02 | 2022-09-09 | International Business Machines Corporation | Replicating data changes using multiple storage devices and tracking records of pending data changes stored on storage devices |
CN118069074A (zh) * | 2024-04-22 | 2024-05-24 | 联想凌拓科技有限公司 | 一种数据处理方法及装置、存储介质、计算机程序产品 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030120602A1 (en) * | 2000-01-12 | 2003-06-26 | June-Kee Jung | Method of combinning multimedia files |
CN103678491A (zh) * | 2013-11-14 | 2014-03-26 | 东南大学 | 一种基于Hadoop中小文件优化和倒排索引的方法 |
CN103744617A (zh) * | 2013-12-20 | 2014-04-23 | 北京奇虎科技有限公司 | 一种键-值存储系统中数据文件的合并压缩方法及装置 |
CN104133867A (zh) * | 2014-07-18 | 2014-11-05 | 中国科学院计算技术研究所 | 分布式顺序表片内二级索引方法及系统 |
CN104504105A (zh) * | 2014-12-30 | 2015-04-08 | 青岛海信网络科技股份有限公司 | 一种实时数据库的存储方法 |
CN104572920A (zh) * | 2014-12-27 | 2015-04-29 | 北京奇虎科技有限公司 | 一种数据整理方法和装置 |
CN105117415A (zh) * | 2015-07-30 | 2015-12-02 | 西安交通大学 | 一种优化的ssd数据更新方法 |
CN105868286A (zh) * | 2016-03-23 | 2016-08-17 | 中国科学院计算技术研究所 | 基于分布式文件系统小文件合并的并行追加方法及系统 |
CN106326292A (zh) * | 2015-06-29 | 2017-01-11 | 杭州海康威视数字技术股份有限公司 | 数据结构和文件聚合、读取方法及装置 |
-
2017
- 2017-01-17 CN CN201710031732.0A patent/CN108319602B/zh active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030120602A1 (en) * | 2000-01-12 | 2003-06-26 | June-Kee Jung | Method of combinning multimedia files |
CN103678491A (zh) * | 2013-11-14 | 2014-03-26 | 东南大学 | 一种基于Hadoop中小文件优化和倒排索引的方法 |
CN103744617A (zh) * | 2013-12-20 | 2014-04-23 | 北京奇虎科技有限公司 | 一种键-值存储系统中数据文件的合并压缩方法及装置 |
CN104133867A (zh) * | 2014-07-18 | 2014-11-05 | 中国科学院计算技术研究所 | 分布式顺序表片内二级索引方法及系统 |
CN104572920A (zh) * | 2014-12-27 | 2015-04-29 | 北京奇虎科技有限公司 | 一种数据整理方法和装置 |
CN104504105A (zh) * | 2014-12-30 | 2015-04-08 | 青岛海信网络科技股份有限公司 | 一种实时数据库的存储方法 |
CN106326292A (zh) * | 2015-06-29 | 2017-01-11 | 杭州海康威视数字技术股份有限公司 | 数据结构和文件聚合、读取方法及装置 |
CN105117415A (zh) * | 2015-07-30 | 2015-12-02 | 西安交通大学 | 一种优化的ssd数据更新方法 |
CN105868286A (zh) * | 2016-03-23 | 2016-08-17 | 中国科学院计算技术研究所 | 基于分布式文件系统小文件合并的并行追加方法及系统 |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109213444A (zh) * | 2018-08-17 | 2019-01-15 | 上海小蚁科技有限公司 | 文件存储方法及装置、存储介质、终端 |
CN109271570A (zh) * | 2018-10-30 | 2019-01-25 | 郑州云海信息技术有限公司 | 一种元数据管理查询的方法 |
CN109614411A (zh) * | 2018-11-19 | 2019-04-12 | 杭州复杂美科技有限公司 | 数据存储方法、设备和存储介质 |
CN109614411B (zh) * | 2018-11-19 | 2022-03-04 | 杭州复杂美科技有限公司 | 数据存储方法、设备和存储介质 |
CN109656926A (zh) * | 2018-12-24 | 2019-04-19 | 杰信软件科技(苏州)有限公司 | 数据库的管理方法 |
CN109885573A (zh) * | 2019-02-22 | 2019-06-14 | 广州荔支网络技术有限公司 | 一种数据存储系统的维护方法、装置和移动终端 |
CN109885573B (zh) * | 2019-02-22 | 2020-01-31 | 广州荔支网络技术有限公司 | 一种数据存储系统的维护方法、装置和移动终端 |
CN113051241B (zh) * | 2019-12-27 | 2023-08-15 | 中国移动通信集团湖南有限公司 | 数据库持久化的方法、装置及设备 |
CN113051241A (zh) * | 2019-12-27 | 2021-06-29 | 中国移动通信集团湖南有限公司 | 数据库持久化的方法、装置及设备 |
CN113515518A (zh) * | 2020-04-10 | 2021-10-19 | 腾讯科技(深圳)有限公司 | 数据存储方法、装置、计算机设备和存储介质 |
CN113821704B (zh) * | 2020-06-18 | 2024-01-16 | 华为云计算技术有限公司 | 构建索引的方法、装置、电子设备和存储介质 |
CN113821704A (zh) * | 2020-06-18 | 2021-12-21 | 华为技术有限公司 | 构建索引的方法、装置、电子设备和存储介质 |
CN112433671B (zh) * | 2020-10-29 | 2023-01-06 | 苏州浪潮智能科技有限公司 | 一种数据持久化方法、系统、设备以及介质 |
CN112433671A (zh) * | 2020-10-29 | 2021-03-02 | 苏州浪潮智能科技有限公司 | 一种数据持久化方法、系统、设备以及介质 |
CN112487095A (zh) * | 2020-12-09 | 2021-03-12 | 浪潮云信息技术股份公司 | 一种分布式数据库事务数据存储优化的方法 |
CN112487095B (zh) * | 2020-12-09 | 2023-03-28 | 浪潮云信息技术股份公司 | 一种分布式数据库事务数据存储优化的方法 |
US11675809B2 (en) | 2021-03-02 | 2023-06-13 | International Business Machines Corporation | Replicating data changes using multiple storage devices and tracking records of pending data changes stored on the storage devices |
WO2022183904A1 (en) * | 2021-03-02 | 2022-09-09 | International Business Machines Corporation | Replicating data changes using multiple storage devices and tracking records of pending data changes stored on storage devices |
CN113468080A (zh) * | 2021-06-10 | 2021-10-01 | 山东英信计算机技术有限公司 | 一种全闪元数据的缓存方法、系统及相关装置 |
CN113468080B (zh) * | 2021-06-10 | 2024-02-09 | 山东英信计算机技术有限公司 | 一种全闪元数据的缓存方法、系统及相关装置 |
CN113535714A (zh) * | 2021-06-18 | 2021-10-22 | 深圳市汉云科技有限公司 | 数据的存储方法、读取方法及计算机设备 |
CN113377292B (zh) * | 2021-07-02 | 2024-02-02 | 北京青云科技股份有限公司 | 一种单机存储引擎 |
CN113377292A (zh) * | 2021-07-02 | 2021-09-10 | 北京青云科技股份有限公司 | 一种单机存储引擎 |
CN113778951B (zh) * | 2021-09-16 | 2024-04-26 | 平安国际智慧城市科技股份有限公司 | 文件的追加方法、装置、设备以及存储介质 |
CN113778951A (zh) * | 2021-09-16 | 2021-12-10 | 平安国际智慧城市科技股份有限公司 | 文件的追加方法、装置、设备以及存储介质 |
CN114328545A (zh) * | 2022-03-03 | 2022-04-12 | 北京蚂蚁云金融信息服务有限公司 | 数据存储及查询方法、装置及数据库系统 |
WO2023165272A1 (zh) * | 2022-03-03 | 2023-09-07 | 蚂蚁云创数字科技(北京)有限公司 | 数据存储及查询 |
CN114328545B (zh) * | 2022-03-03 | 2022-07-08 | 北京蚂蚁云金融信息服务有限公司 | 数据存储及查询方法、装置及数据库系统 |
CN118069074A (zh) * | 2024-04-22 | 2024-05-24 | 联想凌拓科技有限公司 | 一种数据处理方法及装置、存储介质、计算机程序产品 |
CN118069074B (zh) * | 2024-04-22 | 2024-06-21 | 联想凌拓科技有限公司 | 一种数据处理方法及装置、存储介质、计算机程序产品 |
Also Published As
Publication number | Publication date |
---|---|
CN108319602B (zh) | 2020-10-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108319602A (zh) | 数据库管理方法及数据库系统 | |
US8225029B2 (en) | Data storage processing method, data searching method and devices thereof | |
CN108319625B (zh) | 文件合并方法和装置 | |
US9594674B1 (en) | Method and system for garbage collection of data storage systems using live segment records | |
US9715505B1 (en) | Method and system for maintaining persistent live segment records for garbage collection | |
CN102609446B (zh) | 一种分布式Bloom过滤系统及其使用方法 | |
CN110647514B (zh) | 一种元数据更新方法、装置及元数据服务器 | |
JP2016529633A (ja) | スナップショットおよびクローンの複製 | |
CN112131140B (zh) | 基于ssd的支持高效存储空间管理的键值分离存储方法 | |
CN109213432B (zh) | 利用日志结构合并树将数据写入的存储设备及其方法 | |
CN113377292B (zh) | 一种单机存储引擎 | |
US11436102B2 (en) | Log-structured formats for managing archived storage of objects | |
CN113407550A (zh) | 数据存储及查询方法、装置及数据库系统 | |
WO2018133762A1 (zh) | 文件合并方法和装置 | |
CN114780530A (zh) | 基于lsm树键值分离的时序数据存储方法及系统 | |
CN110109927A (zh) | 基于LSM树的Oracle数据库数据处理方法 | |
CN103268270A (zh) | 快照的管理方法和装置 | |
CN114936188A (zh) | 数据处理方法、装置、电子设备及存储介质 | |
CN111444114B (zh) | 一种非易失性内存中数据的处理方法、装置及系统 | |
CN104156432A (zh) | 一种文件访问方法 | |
CN117473117B (zh) | 一种视频循环存储方法、系统及计算机 | |
CN104133970A (zh) | 一种数据空间管理方法及装置 | |
KR101456104B1 (ko) | 비휘발성 메모리를 위한 듀얼 버퍼링 파일 관리 방법, 파일 관리 시스템 및 대용량 저장 장치 | |
CN111752913B (zh) | 分布式系统的数据恢复方法、介质、计算机设备、装置 | |
JP2553751B2 (ja) | ディスクセクタ代替方式 |
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 | ||
TA01 | Transfer of patent application right | ||
TA01 | Transfer of patent application right |
Effective date of registration: 20200713 Address after: 310052 room 508, floor 5, building 4, No. 699, Wangshang Road, Changhe street, Binjiang District, Hangzhou City, Zhejiang Province Applicant after: Alibaba (China) Co.,Ltd. Address before: 510627 Guangdong city of Guangzhou province Whampoa Tianhe District Road No. 163 Xiping Yun Lu Yun Ping B radio square 14 storey tower Applicant before: Guangzhou Dongjing Computer Technology Co.,Ltd. |
|
GR01 | Patent grant | ||
GR01 | Patent grant |