CN110083601B - 面向键值存储***的索引树构建方法及*** - Google Patents
面向键值存储***的索引树构建方法及*** Download PDFInfo
- Publication number
- CN110083601B CN110083601B CN201910271085.XA CN201910271085A CN110083601B CN 110083601 B CN110083601 B CN 110083601B CN 201910271085 A CN201910271085 A CN 201910271085A CN 110083601 B CN110083601 B CN 110083601B
- Authority
- CN
- China
- Prior art keywords
- tree
- hash table
- key value
- index
- 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.)
- Active
Links
Images
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/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
- G06F16/2228—Indexing structures
- G06F16/2246—Trees, e.g. B+trees
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (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
本发明涉及一种面向键值存储***的索引树构建方法,包括:对键值数据的键值的前缀进行排序和划分以生成字典树,作为索引树的上层结构;以该键值的哈希值构建哈希表,以该哈希表生成该索引树的下层结构;建立键值数据—哈希表—字典树的对应关系,生成该索引树。本发明的索引树构建方法,通过构建的上下层结构的索引树进行键值数据索引操作,有着更优秀的单体操作能力O(L+K),以及更低的空间开销和更高的效率,并支持范围查找和动态处理数据增长。
Description
技术领域
本发明属于计算机存储的键值存储、索引技术领域,具体涉及一种面向键值存储***的索引树构建的方法和***。
背景技术
对于一个存储***而言,如何高效的组织、索引这些数据成为了影响一个存储***效率优良的关键因素。针对内存索引的设计,现阶段被广泛应用的索引类型主要有以下几种:
1、B+树(B+tree):一个节点可以拥有多于2个子节点的多叉搜索树。它能够存储数据、对其进行排序并允许以O(log n)的时间复杂度运行进行查找、顺序读取、***和删除的数据结构。B+tree算法普遍运用在数据库和文件***。发明“一种B+树读缓存方法及相关装置”(公开号:CN109492005A),公开了一种B+树读缓存方法,首先确定当前可用缓存空间的容量,并确定所述容量可以缓存的前N层B+树非叶子节点,将前N层的节点信息全部进行缓存,从而在查找叶子节点时,纵向的每一条路径中,缓存在缓存空间的节点数均是相同的。“数据查询方法和装置”(公开号:CN109299106A),提供一种数据查询方法和装置,包括:接收用户发送的查询指令,查询指令中包括至少一个查询条件;在三级索引文件集合中,确定与至少一个查询条件中的每一个查询条件对应的第一维度值,并确定与第一维度值对应的三级索引信息;在二级索引文件集合中,确定与三级索引信息对应的二级索引信息;根据与第二维度值对应的二级索引信息,在数据库中确定与二级索引信息对应的数据。进而不再需要对数据的键值进行遍历,只依据三级索引信息、二级索引信息,就可以查找到数据库中的数据。
2、哈希表:哈希表作为一种索引结构一直被广泛的运用在各种内存型数据库***中,它通过哈希函数随机的将数据定址到表的某一槽,在理想情况下操作可以达到O(1)级别的时间复杂度。发明“包括资源有效索引的键值存储***”(公开号:CN109416694A),描述了一种用于使用资源有效索引来与内容存储库中的键值条目进行交互的键值存储***。索引提供包括多个散列桶的数据结构。每个散列桶包括散列桶单元的链表。键值存储***基于其创建时间以分布式方式在存储器中索引存储库与辅助索引存储库之间存储散列桶单元的每个链表中的散列条目。键值存储***还被配置为按时间顺序存储链接的散列桶单元的特定集合中的散列条目以反映其创建时间。索引还包括影响键值存储***的性能的各种可调参数。
3、字典树:是一种有序树,用于保存关联数组,其中的键通常是字符串。与二叉查找树不同,键不是直接保存在节点中,而是由节点在树中的位置决定。一个节点的所有子孙都有相同的前缀,也就是这个节点对应的字符串,而根节点对应空字符串。一般情况下,不是所有的节点都有对应的值,只有叶子节点和部分内部节点所对应的键才有相关的值。发明“一种索引数据存储及检索方法、装置及存储介质”(公开号:CN109325032A),提供了一种索引数据存储及检索方法、装置及存储介质,数据存储方法在数据(即键值对)存储时,不仅根据值元素的大小进行排序,还将排序的数据序列划分为多个段,每个段将键值排序,并将数据序列与键值排序对应存储,实现值元素和键值(也称为记录编号)都有序存储,即构建了全新的索引结构,并提出了适于该索引结构的多条件检索方法,其对于任意的区间查询,结果集都可以用一个或者多个集合的并集来表示,并且这些集合大部分有序的,最多边界两个集合是无序的,从而提高了在多个条件查询时进行与、或、非等运算的效率。
然而上述现有技术都存在有不同程度的问题,例如,对于B+树,由于本身操作复杂度为O(log n),因此效率不是很高,此外,B+树由于本身需要进行***合并维持树形态,因此在并发性方面并不是很优秀;对于哈希表,由于其随机定址的特性哈希表想进行范围搜索只能扫描整个哈希表,因此其范围查询效率极其低下。此外,随着哈希表逐渐被写满,哈希表会产生更多的定址冲突,在进行定址的时候可能会花费更多的时间在处理冲突上,因此当一个哈希表在装载系数达到饱和时需要建立更大的哈希表对数据进行迁移;对于字典树而言,由于其节点的分散性,使得在对进行字典树进行搜索时cache利用率会很低,此外字典树无法很好的控制内部节点的增长会造成大量的内存开销。
发明内容
为解决上述存储***中面临检索效率较低的问题,本发明通过一种具有上下层索引结构的索引树,以满足键值存储***对键值数据高效检索的需要。
具体来说,本发明的索引树构建方法包括:对键值数据的键值的前缀进行排序和划分以生成字典树,作为索引树的上层结构;以该键值的哈希值构建哈希表,以该哈希表生成该索引树的下层结构;建立键值数据—哈希表—字典树的对应关系,生成该索引树。
本发明所述的索引树构建方法,其中该哈希表包括:多个哈希桶,每个该哈希桶包括依次设置的标识槽、缓存槽和地址槽,其中该标识槽的标识项存储该键值的哈希值,该缓存槽的缓存项存储部分该键值,该地址槽的地址项存储该键值数据的存储地址。
本发明所述的索引树构建方法,其中每个该标识槽包括N个标识项,每个该缓存槽包括N个缓存项,每个该地址槽包括N个地址项;第n个标识项与第n个缓存项与第n个地址项对应同一个键值数据;其中N、n为正整数,n≤N。
本发明所述的索引树构建方法,其中该标识项为4字节存储空间,该缓存项为4字节存储空间,该地址项为8字节存储空间。
本发明还提出一种面向键值存储***的索引树构建***,包括:索引树上层结构生成模块,用于对键值数据的键值的前缀进行排序和划分以生成字典树,作为索引树的上层结构;索引树下层结构生成模块,用于以该键值的哈希值构建哈希表,以该哈希表生成该索引树的下层结构;索引树对应关系生成模块,用于建立键值数据—哈希表—字典树的对应关系,生成该索引树。
本发明所述的索引树构建***,其中该哈希表包括多个哈希桶,每个该哈希桶包括依次设置的标识槽、缓存槽和地址槽,该索引树下层结构生成模块具体包括:标识槽存储模块,用于将该键值的哈希值存储为该标识槽中的标识项;缓存槽存储模块,用于将部分该键值存储为该缓存槽的缓存项;地址槽存储模块,用于将该键值数据的存储地址存储为该地址槽的地址项。
本发明所述的索引树构建***,其中每个该标识槽包括N个标识项,每个该缓存槽包括N个缓存项,每个该地址槽包括N个地址项;第n个标识项与第n个缓存项与第n个地址项对应同一个键值数据;其中N、n为正整数,n≤N。
本发明所述的索引树构建***,其中该标识项为4字节存储空间,该缓存项为4字节存储空间,该地址项为8字节存储空间。
本发明还提出一种可读存储介质,存储有可执行指令,该可执行指令用于执行如前述的面向键值存储***的索引树构建方法。
本发明还提出一种数据处理装置,包括如前述的可读存储介质,该数据处理装置调取并执行该可读存储介质中的可执行指令,以构建面向键值存储***的索引树。
本发明提出的一种面向键值存储***的索引树构建方法,构建上下层结构的索引树(Radix Hashing Tree,RH-Tree),相对于B+树等操作复杂度为O(log n)的树形索引结构而言,RH-Tree有着更优秀的单体操作能力O(L+K);相对于哈希索引而言,RH-Tree一方面可以支持范围查找,另一方面RH-Tree可以动态的处理数据增长;对于字典树而言,RH-Tree有着更低的空间开销以及更高的效率。
附图说明
图1是本发明的RH-Tree结构总图。
图2是本发明的索引项和键值数据分离存储结构示意图。
图3是本发明的RH-Tree的搜索操作示意图。
图4是本发明的RH-Tree的搜索操作流程图。
图5是本发明的RH-Tree的***操作流程图。
图6是本发明的RH-Tree的扫描操作示意图。
图7是本发明的RH-Tree的普通***示意图。
图8是本发明的RH-Tree的层***示意图。
图9是本发明的RH-Tree的不平衡***示意图。
图10是本发明的RH-Tree的优化***示意图。
图11是本发明的普通***的一致性保证示意图。
图12是本发明的层***的一致性保证示意图。
图13是传统易失性内存的单线程情况下各索引方法的PUT和GET的吞吐量对比图。
图14是传统易失性内存的单线程情况下各索引方法的SCAN的吞吐量对比图。
图15是传统易失性内存的多线程情况下RH-Tree同B+树的并发性对比图。
图16是非易失性内存的单线程情况下各索引方法的PUT和GET的吞吐量对比图。
图17是非易失性内存的多线程情况下各索引的PUT的吞吐量对比图。
图18是本发明的面向键值存储***的索引树构建***的数据处理装置示意。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图,对本发明提出的面向键值存储***的索引树构建方法进一步详细说明。应当理解,此处所描述的具体实施方法仅仅用以解释本发明,并不用于限定本发明。
本发明提出一种面向键值存储***的索引树构建方法,通过该方法构建的索引树,称之为RH-Tree(Radix Hashing Tree,哈希索引树)。相对于B+树等操作复杂度为O(logn)的树形索引结构而言,RH-Tree有着更优秀的单体操作能力O(L+K);相对于哈希索引而言,RH-Tree一方面可以支持范围查找,另一方面RH-Tree可以动态的处理数据增长;对于字典树而言,RH-Tree有着更低的空间开销以及更高的效率。
本发明的索引树构建方法包括:对键值数据的键值的前缀进行排序和划分以生成字典树,作为索引树的上层结构;以键值的哈希值构建哈希表,以哈希表生成索引树的下层结构;建立键值数据—哈希表—字典树的对应关系,生成索引树。
其中哈希表包括:多个哈希桶,该哈希桶包括多条索引项,每条索引项包括依次设置的标识槽、缓存槽和地址槽,其中标识槽的标识项存储键值的哈希值,缓存槽的缓存项存储部分键值,地址槽的地址项存储键值数据的存储地址。每个标识槽包括N个标识项,每个缓存槽包括N个缓存项,每个地址槽包括N个地址项;第n个标识项与第n个缓存项与第n个地址项对应同一个键值数据;其中N、n为正整数,n≤N。具体的,标识项为4字节存储空间,缓存项为4字节存储空间,地址项为8字节存储空间。
本发明还提出一种面向键值存储***的索引树构建***,包括:索引树上层结构生成模块,用于对键值数据的键值的前缀进行排序和划分以生成字典树,作为索引树的上层结构;索引树下层结构生成模块,用于以该键值的哈希值构建哈希表,以该哈希表生成索引树的下层结构;索引树对应关系生成模块,用于建立键值数据—哈希表—字典树的对应关系,生成索引树。
具体来说,本发明的面向键值存储***的索引树包括:
一、RH-Tree结构
本发明的RH-Tree,索引结构分为上下两结构:使用Radix Tree对键值数据(Key-value)的键值(Key)的前缀进行排序和划分,形成字典树,这部分字典树构成RH-Tree的上层结构;使用哈希表对同一范围内的键值进行索引,所有的下层哈希表共同构成RH-Tree的下层结构;在下层哈希表结构的设计方面,采用标识槽(signature槽);提高了缓存的命中率,减少不必要的数据访问,提升了查找效率。
本发明还提出了处理数据增长的普通***方法和层***方法,将键值和索引结构分离减少数据的搬运,设置缓存槽(cache槽)对RH-Tree的***过程进行优化,提出针对负载不均的***优化算法;本发明的***算法高效,有效的解决了传统哈希表无法很好处理数据增长的问题。
而针对非易失性内存内存,本发明提出了基于8字节原子写的一致性保证算法,保证了RH-Tree在非易失性内存上的适配性。
具体来说,本发明的RH-Tree包括三个部分:索引树(radix tree)、哈希表(HTable)和键值数据(Key-Value,KV)的存储块(Key-Value item,KV item)。
图1是本发明的RH-Tree结构总图。如图1所示,对于RH-Tree的设计,分为上层的前缀排序结构和下层的哈希节点结构:上层的排序结构为一个Radix Tree;下层的哈希结构,对于每个Radix Tree的节点都是一个哈希表,而键值数据则具体与某个哈希表中的某个哈希桶(bucket)相对应。每个哈希桶则对应键值数据存储区域(KV item area)的KV item。
每个哈希表包括多个哈希桶buckets,哈希桶可以看做是键值数据的索引项,每个包括标识槽(signature槽)、缓存槽(cache槽)和地址槽(address 槽),每个signature槽中有4个标识项(signature),每个signature占4字节(Bety,B)(是一个32位的哈希值)存储空间,每个signature槽占16B存储空间,当一个signature槽的signature中有数据时,signature为该bucket对应键值(Key)的哈希值,如果signature为0,则表示该signature槽为空;cache槽存储有cache,cache为一个键值的部分键值数据,每个cache槽存储有4个cache,一个cache项占4B(可缓存一个键值的4B数据)存储空间,每个cache槽占16B,cache槽的作用将在后续进行阐述;address为键值数据的存储地址,address槽共4个address,每个address项占8B存储空间,每个address槽共占32B。每个bucket也包括其他数量的标识槽、缓存槽和地址槽,例如是2组(分别有2个标识槽、2个缓存槽和2个地址槽)或8个(分别有8个标识槽、8个缓存槽和8个地址槽),本发明并不以此为限。
图2是本发明的索引项和键值数据分离存储结构示意图。如图2所示,于本发明的RH-Tree中,将键值Key同键值数据KV item分开存储。对于一个针对下层哈希表的搜索操作:首先使用哈希值定位到哈希表HTable的某一个bucket,本发明使用哈希值对bucket数取余的方式进行判断,例如:该键值Key的哈希值为4097,一个哈希表的bucket为4096项,那么它就被定位到bucket1中(4097mod4096=1)。对于signature不为0的槽,读取其signature值,如果signature值一样,则再通过cache项判断部分键值是否验证正确,如果验证通过则通过address指针最终找到要搜索的键值数据,该键值数据中存在完整的键值,最终和完整的键值比较,符合后返回要搜索的结果。
由于通过上述设计,一个哈希桶的大小为64B,因此RH-Tree可以有效的将对一个哈希桶的搜索操作放在一个缓存行(cache line,cache line大小通常为64B)中进行,有效的减少了内存的访问次数,充分的利用了缓存。
二、数据操作处理
本发明的面向键值存储***的索引树构建方法包括对键值数据的操作,如搜索、***、删除、范围查找等。
1、操作一:搜索
对于一个搜索操作,首先使用要操作的键值的前缀在Radix Tree进行搜索;在搜索到对应的下层的哈希表时,再使用哈希表的搜索算法进行搜索。
因此整体的RH-Tree的搜索复杂度为O(L+K),其中O(L)为操作在上层字典树结构的搜索复杂度,O(K)为操作在下层哈希表结构的搜索复杂度。
图3是本发明的RH-Tree的搜索操作示意图。如图3所示,搜索一个键为”acebbaq”的数据,在Radix Tree结构以ace为前缀搜索到下层的哈希表,最终在哈希表中找到对应键的数据存放位置。
图4是本发明的RH-Tree的搜索操作流程图。如图4所示,本发明的RH-Tree的搜索操作包括:
步骤S11,通过使用键值Key的前缀,搜索RH-Tree上层结构的Radix Tree(前缀树),定位到RH-Tree下层结构的某一个哈希表(哈希叶节点);
步骤S12,计算键值Key的哈希值,得到一个32位的哈希值hash32;
步骤S13,使用这个哈希值对哈希表的桶数进行取余,以定位要搜索的桶;
步骤S14,对桶内的signature槽进行逐一搜索,以判断桶内是否有对应的搜索目标;若有对应的搜索目标,则进行步骤S15,验证搜索结果,若没有,则证明没有存储对应的搜索目标,退出此次搜索;
步骤S15,根据对应的address槽内存储的地址获取目标键值数据,与对应cache槽内存储的部分键值数据进行比较,以确定搜索结果的准确性。
2、操作二:***
***操作同搜索操作一样,需要首先通过搜索算法定址到哈希表中的某一个桶,之后查找该哈希桶的signature中位为0所对应的空槽进行cache槽的写入,最终写入signature代表一次***操作的完成;
图5是本发明的RH-Tree的***操作流程图。如图5所示,本发明的RH-Tree的***操作包括:
步骤S21,通过使用键值Key的前缀,搜索RH-Tree上层结构的Radix Tree(前缀树),定位到RH-Tree下层结构的某一个哈希表(哈希叶节点);
步骤S22,计算键值Key的哈希值,得到一个32位的哈希值hash32;
步骤S23,使用这个哈希值对哈希表的桶数进行取余,以搜索并定位要***的桶;
步骤S24,对桶内的signature槽进行逐一搜索,以判断桶内是否有signature的值为0的signature槽;若有,则进行步骤S15,进行***操作,若没有,则进行步骤S26;
步骤S25,进行键值和键值数据的***操作,并根据***的键值的哈希值、部分键值数据以及键值数据的保存位置更新桶内signature槽、cache槽和address槽的数据;
步骤S26,对RH-Tree进行***,并返回步骤S21,以重新进行键值数据的***。
3、操作三:删除
删除操作同***操作一一样,需要首先通过搜索算法查找键值是否位于某一个下层哈希表中,如果搜索和匹配成功,则释放对应的键值存储空间并将该signature槽的signature字段置为0即可。
4、操作四:范围查找
图6是本发明的RH-Tree的扫描操作示意图。如图6所示,对于范围查找,搜索键值1(Key1)“ababc”到键值2(Key2)“cacbd”键值内的数据,首先通过两个普通搜索找到边界哈希表(HTable1、HTable N),但由于哈希表内部是无序的,无法保证位于搜索边界的两个哈希表的数据全在查找范围(scan range)内,因此需要扫描HTable1和HTableN的所有数据,找到符合范围的数据项。但对于哈希表HTable 2~HTable N-1,基于RH-Tree上层结构的字典树特性,其内部数据范围必然在”ababc”到”cacbd”之间,因此不必一一比较这些数据是否在哈希表HTable 2~HTable N-1的范围内。
三、数据增长处理
传统的哈希表通常无法很好的处理数据的增长。针对处理数据增长的做法,传统哈希表会将建立一个更大的新表,将旧表的数据迁移到新表中。在这种情况下,如果新建立的表过大,则会造成空间的浪费;如果建立的表比较小,则会出现新表马上又被写满,又将重新进行数据迁移的情况。
针对上述问题,RH-Tree的一个节点写满后,会进行***操作产生新的节点,***分为两种,分别是不涉及前缀路径增长的普通***、涉及路径增长的层***;此外,RH-Tree将键值数据同索引项分离,只在索引项中保存键值数据的地址(块内address),在***的时候不会移动键值数据,而是只移动用来索引的索引项,有效的减少的键值数据的移动。
1、普通***
图7是本发明的RH-Tree的普通***示意图。如图7所示,一个普通***的操作过程如下:
当一个哈希表写满之后,如果该哈希表存在两个以上的上层路径(如从内部节点innernode)指向它(见图7左侧,存在a、b两个前缀指针指向该哈希表——HTable1),那么可以进行普通***(normal split)。建立一个新的哈希表——HTable2;将原来指向旧哈希表(HTable1)的指针分一半指向新哈希表(HTable2)(见图7右侧,前缀指针a继续指向旧HTable1,而前缀指针b指向了新建立的HTable2);将符合新哈希表前缀的索引项从旧哈希表移动(movement)到新哈希表。
2、层***
图8是本发明的RH-Tree的层***示意图。如图8所示,一个层***的操作过程如下:
当一个哈希表写满之后,如果该哈希表只存在一个上层路径(如从内部节点innernode)指向它,则进行层***。对于一个层***(level split),会建立一个新的内部节点用来拓展路径(见图6左侧,建立了新的内部节点new innernode);然后建立这个新内部节点的多个子节点(HTable1'、HTable2');最后将节点innernode的索引项搬运到新节点new innernode中。
3、通过cache槽提升***效率
可以看到,不论是普通还是层***,都需要键值去判断一个索引项应该被分配到哪个节点中,因此每次***都涉及到键值数据的访问,由于本发明将索引和键值数据进行了分离,每次***如果都要访问数据,势必会增加大量访存开销。请再次参阅图1,如图1所示,在本发明RH-Tree的哈希桶的设计中会存储一个键值4B的数据缓冲(存储一个键的4B数据)。随着层***,上层路径不断增长,需要更新cache槽,通过这种设计,本发明一个内部节点每进行4次层***才会访问一次键值数据去更新cache槽,从而大大降低了在***过程中对内存的访问,使得一次***大部分查询都可以在cache中完成。
4、密集型键值对的有效处理
图9是本发明的RH-Tree的不平衡***示意图。如图9所示,由于RH-Tree上层是由通过键值的前缀按照字典序进行寻址,并且在***的时候也是根据字典序进行***,因此会出现一个***后,导致两个新节点会出现数据不均的情况,HTable0要一次普通***,它会将数据写入到HTable1和HTable2中,但此时可以看到,根据键的分布,HTable1中写入了80%以上的数据,这样所造成的问题就是马上又会产生一个***,又需要移动一次数据,这样就造成了数据的多次移动。
图10是本发明的RH-Tree的优化***示意图。如图10所示,在每次***的时候,需要判断一下当前***是否会造成一个节点写入超过80%的情况,如果有,那么再判断下一次(多次)***,是否会造成新节点的负载不均。当一次普通***如果会造成了HTable1写入不平衡,此时RH-Tree再判断下一次***是否会造成写入不平衡,此时是一个层***,可以看到这次***不会造成新节点的负载不均,此时RH-Tree就会按照新的***情况构建节点,然后搬运数据。
5、一致性保证
(1)***操作一致性保证
a.申请键值存储空间,写入键值数据并持久化。
b.使用原子写以及同步原语(mfence/clfush)修改索引项中的address项,指向该键值存储地址,若此时宕机,该槽对应的signature为0,标志着该槽依旧为空。
c.使用原子写以及同步原语(mfence/clfush)修改哈希项中的signature,标志着一次写完成
(2)更新操作一致性保证
a.申请键值存储空间,写入键值数并持久化,若此时宕机会发生内存泄漏,但这个问题不由我们所考虑和研究。
b.使用原子写以及同步原语(mfence/clfush)修改索引项中的address,指向该键值数据存储地址,若此时宕机,该槽对应的signature为0,标志着该槽依旧为空。
c.使用原子写以及同步原语(mfence/clfush)修改索引项中的signature,标志着一次写完成。
d.释放旧数据的存储空间。
(3)删除操作一致性保证
a.使用原子写以及同步原语(mfence/clfush)置哈希项中siganture槽为0。此时宕机,删除操作成功,但此时宕机会发生内存泄漏。
b.释放键值存储的空间。
(4)普通***操作一致性保证
图11A、11B、11C是本发明的普通***的一致性保证示意图。针对***操作,RH-Tree设计了原子失败指针去保证***过程中的一致性。原子失败指针是一个由正在***节点指向正在搬运数据节点的指针,当进行***时,搬运数据前要使用该指针将新旧节点相连,以确保在***过程中宕机时可以通过该指针找到新节点。对于一个***,它的流程如下:
原状态为上层Radix Tree指针指向哈希节点(图11A中的哈希表HTable);
申请新的哈希节点(图11B中的哈希表new HTable),并使用要***节点(哈希表HTable)的原子失败指针指向新哈希表new HTable(如图11B中的箭头1);将索引项从旧节点搬运到新节点,并进行持久化(如图11B中箭头2)
修改上层Radix Tree指针(如图11C中的箭头3)指向新的哈希节点(图11C中的哈希表new HTable);移除原子失败指针,标志着一次***完成。
(5)层***操作一致性保证
图12是本发明的层***的一致性保证示意图。如图12所示,和普通***类似,对于层***RH-Tree同样会使用原子失败指针将正在***的节点连接起来,以确保***中如果宕机可以进行恢复。步骤如下:
·申请新的哈希节点,使用原子失败指针将它们彼此相连;
·进行数据的搬运;
·申请新的内部节点,并将新内部节点的指针指向新的哈希节点;
·将旧内部节点的指针指向修改为新内部节点;
·删除所有节点的原子失败指针。
四、评测
评测环境如下:
处理器 Intel Xeon E5-2620v3
内存 96GB
操作*** CentOS 7.0,Linux kernel 4.3.0
内存管理库 jemalloc
测试集:使用100M的数据(100,000,000个Key-value item)进行评测,Key的大小为32B,Key-value的大小为128B。
1、传统易失性内存评测
与B+树(B+-Tree)、红黑树(Red-Black Tree)、Adaptive Radix Tree、LevelHashing等传统索引方法进行对比。
(1)单线程操作效率
图13是传统易失性内存的单线程情况下各索引方法的PUT和GET的吞吐量对比图。如图13所示,RH-Tree的PUT操作分别是B+-Tree、、Level Hashing、Adaptive Radix Tree的7.27倍、7.13倍、3.71倍、1.74倍。RH-Tree的GET操作分别是Red-Black Tree、LevelHashing、Adaptive Radix Tree、B+-Tree的5.3倍、9.6倍、6.05倍、1.71倍。
(2)扫描操作效率
图14是传统易失性内存的单线程情况下各索引方法的SCAN的吞吐量对比图。如图14所示,这里将RH-Tree和搜索性能比较好的B+树索引进行了比较,可以看到,RH-Tree的SCAN性能是传统B+树的80%左右,这是由于在扫描数据时对边界哈希表扫描时的开销。
(3)多线程并发效率
图15是传统易失性内存的多线程情况下RH-Tree同B+树的并发性对比图。如图15所示,在16个线程的情况下,RH-Tree是B+-Tree吞吐量的6.2倍。在12线程~16线程数之间吞吐量上升缓慢或出现下降的原因主要是由于使用的测试机一个物理核最多支持12个线程,由于NUMA架构的设计,13个以上的线程会出现远端内存访问的问题,增大了访存延迟。
2、非易失性内存上的评测
对于传统索引,同FP-Tree、FAST-FAIR Tree、Hybrid Index、Level Hashing进行对比。
(1)单线程操作效率
图16是非易失性内存的单线程情况下各索引方法的PUT和GET的吞吐量对比图。如图16所示,RH-Tree的PUT操作分别是FPTree、FAST-FAIR、Level Hashing的1.86倍、1.53倍、1.44倍。RH-Tree的GET操作分别是FPTree、FAST-FAIR、Level Hashing的5.32倍、4.79倍、2.4倍。
(2)多线程并发效率
图17是非易失性内存的多线程情况下各索引的PUT的吞吐量对比图。如图17所示,在并发性方面,RH-Tree有着优秀的并发性能,在12个线程的时候可以到达FP-Tree索引性能的4倍,由于测试只进行了12个线程,FAST-FAIR和HiKV的劣势还没有体现出来,但即使这样,RH-Tree性能也可以达到他们的1.5倍。
图18是本发明的面向键值存储***的索引树构建***的数据处理装置示意图。如图18所示,本发明实施例还提供一种可读存储介质,以及一种数据处理装置。本发明的可读存储介质存储有计算机可执行指令,可执行指令被数据处理装置的处理器执行时,实现上述面向键值存储***的索引树构建。本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件(例如处理器)完成,所述程序可以存储于可读存储介质中,如只读存储器、磁盘或光盘等。上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地,上述实施例中的各模块可以采用硬件的形式实现,例如通过集成电路来实现其相应功能,也可以采用软件功能模块的形式实现,例如通过处理器执行存储于存储器中的程序/指令来实现其相应功能。本发明实施例不限制于任何特定形式的硬件和软件的结合。
虽然本发明已以实施例揭露如上,然其并非用以限定本发明,任何所属技术领域中的普通技术人员,在不脱离本发明的精神和范围内,可以做出若干变形和改进,故本发明的保护范围当视后附的申请专利范围所界定者为准。
Claims (10)
1.一种面向键值存储***的索引树构建方法,其特征在于,包括:
对键值数据的键值的前缀进行排序和划分以生成字典树,作为索引树的上层结构;
以该键值的哈希值构建哈希表,以该哈希表生成该索引树的下层结构;
建立键值数据—哈希表—字典树的对应关系,生成该索引树;
当该索引树进行***时,若直接指向满哈希表的字典树节点为一个,则根据该键值的前缀建立两个该字典树节点的子节点,将该子节点中的一个指向该满哈希表,将该子节点中的另一个指向新哈希表,并将指向该新哈希表的子节点在该满哈希表的哈希值移动至该新哈希表;若直接指向满哈希表的字典树节点为多个,则将至少一个该字典树节点指向新哈希表,并将指向该新哈希表的字典树节点在该满哈希表的哈希值移动至该新哈希表。
2.如权利要求1所述的索引树构建方法,其特征在于,该哈希表包括:
多个哈希桶,每个该哈希桶包括依次设置的标识槽、缓存槽和地址槽,其中该标识槽的标识项存储该键值的哈希值,该缓存槽的缓存项存储部分该键值,该地址槽的地址项存储该键值数据的存储地址。
3.如权利要求2所述的索引树构建方法,其特征在于,每个该标识槽包括N个标识项,每个该缓存槽包括N个缓存项,每个该地址槽包括N个地址项;第n个标识项与第n个缓存项与第n个地址项对应同一个键值;其中N、n为正整数,n≤N。
4.如权利要求3所述的索引树构建方法,其特征在于,该标识项为4字节存储空间,该缓存项为4字节存储空间,该地址项为8字节存储空间。
5.一种面向键值存储***的索引树构建***,其特征在于,包括:
索引树上层结构生成模块,用于对键值数据的键值的前缀进行排序和划分以生成字典树,作为索引树的上层结构;
索引树下层结构生成模块,用于以该键值的哈希值构建哈希表,以该哈希表生成该索引树的下层结构;
索引树对应关系生成模块,用于建立键值数据—哈希表—字典树的对应关系,生成该索引树;
索引树***模块,用于对该索引树进行***操作;其中,当该索引树进行***时,若直接指向满哈希表的字典树节点为一个,则根据该键值的前缀建立两个该字典树节点的子节点,将该子节点中的一个指向该满哈希表,将该子节点中的另一个指向新哈希表,并将指向该新哈希表的子节点在该满哈希表的哈希值移动至该新哈希表;若直接指向满哈希表的字典树节点为多个,则将至少一个该字典树节点指向新哈希表,并将指向该新哈希表的字典树节点在该满哈希表的哈希值移动至该新哈希表。
6.如权利要求5所述的索引树构建***,其特征在于,该哈希表包括多个哈希桶,每个该哈希桶包括依次设置的标识槽、缓存槽和地址槽,该索引树下层结构生成模块具体包括:
标识槽存储模块,用于将该键值的哈希值存储为该标识槽中的标识项;
缓存槽存储模块,用于将部分该键值存储为该缓存槽的缓存项;
地址槽存储模块,用于将该键值数据的存储地址存储为该地址槽的地址项。
7.如权利要求6所述的索引树构建***,其特征在于,每个该标识槽包括N个标识项,每个该缓存槽包括N个缓存项,每个该地址槽包括N个地址项;第n个标识项与第n个缓存项与第n个地址项对应同一个键值数据;其中N、n为正整数,n≤N。
8.如权利要求6所述的索引树构建***,其特征在于,该标识项为4字节存储空间,该缓存项为4字节存储空间,该地址项为8字节存储空间。
9.一种可读存储介质,存储有可执行指令,该可执行指令用于执行如权利要求1~4任一项所述的面向键值存储***的索引树构建方法。
10.一种数据处理装置,包括如权利要求9所述的可读存储介质,该数据处理装置调取并执行该可读存储介质中的可执行指令,以构建面向键值存储***的索引树。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910271085.XA CN110083601B (zh) | 2019-04-04 | 2019-04-04 | 面向键值存储***的索引树构建方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910271085.XA CN110083601B (zh) | 2019-04-04 | 2019-04-04 | 面向键值存储***的索引树构建方法及*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110083601A CN110083601A (zh) | 2019-08-02 |
CN110083601B true CN110083601B (zh) | 2021-11-30 |
Family
ID=67414358
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910271085.XA Active CN110083601B (zh) | 2019-04-04 | 2019-04-04 | 面向键值存储***的索引树构建方法及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110083601B (zh) |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110888886B (zh) * | 2019-11-29 | 2022-11-11 | 华中科技大学 | 一种索引结构及构建方法、键值存储***及请求处理方法 |
CA3225501A1 (en) * | 2020-02-10 | 2021-08-19 | 2Misses Corporation | System and method for a hash table and data storage and access using the same |
CN111338568B (zh) * | 2020-02-16 | 2020-11-06 | 西安奥卡云数据科技有限公司 | 一种数据逻辑位置映射方法 |
CN111399777B (zh) * | 2020-03-16 | 2023-05-16 | 平凯星辰(北京)科技有限公司 | 一种基于数据值分类的差异化键值数据存储方法 |
CN111858607A (zh) * | 2020-07-24 | 2020-10-30 | 北京金山云网络技术有限公司 | 数据处理方法、装置、电子设备和计算机可读介质 |
CN112579575A (zh) * | 2020-12-28 | 2021-03-30 | 超越科技股份有限公司 | 一种数据库索引结构的快速构建方法 |
CN112667636B (zh) * | 2020-12-30 | 2023-03-24 | 杭州趣链科技有限公司 | 索引建立方法、装置及存储介质 |
CN112732725B (zh) * | 2021-01-22 | 2022-03-25 | 上海交通大学 | 基于nvm混合内存的自适应前缀树构建方法及其***、介质 |
CN112835907A (zh) * | 2021-02-08 | 2021-05-25 | 兴业数字金融服务(上海)股份有限公司 | 多次散列存储方法及*** |
CN113157694A (zh) * | 2021-03-22 | 2021-07-23 | 浙江大学 | 一种基于强化学习的数据库索引生成方法 |
CN113505130B (zh) * | 2021-07-09 | 2023-07-21 | 中国科学院计算技术研究所 | 一种哈希表的处理方法 |
CN113535788B (zh) * | 2021-07-12 | 2024-03-05 | 中国海洋大学 | 一种面向海洋环境数据的检索方法、***、设备及介质 |
CN113821171B (zh) * | 2021-09-01 | 2024-06-11 | 上海沄熹科技有限公司 | 一种基于哈希表与lsm树的键值存储方法 |
CN113778752A (zh) * | 2021-09-10 | 2021-12-10 | 中国电信集团***集成有限责任公司 | 用于重复数据删除的哈希数据存储方法及装置 |
CN114676136B (zh) * | 2022-03-28 | 2024-06-18 | 浙江邦盛科技股份有限公司 | 一种面向内存键值表的子集过滤器 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101477523B (zh) * | 2008-11-24 | 2011-07-20 | 北京邮电大学 | 超大型指纹库的索引结构和检索方法 |
CN102831224B (zh) * | 2012-08-24 | 2018-09-04 | 北京百度网讯科技有限公司 | 一种数据索引库的建立方法、搜索建议生成方法和装置 |
CN104850572B (zh) * | 2014-11-18 | 2018-11-23 | 中兴通讯股份有限公司 | HBase非主键索引构建与查询方法及其*** |
CN104899297B (zh) * | 2015-06-08 | 2019-02-26 | 南京航空航天大学 | 创建具有存储感知的混合索引的方法 |
CN104991905B (zh) * | 2015-06-17 | 2018-01-30 | 河北大学 | 一种基于层次索引的数学表达式检索方法 |
CN107273443B (zh) * | 2017-05-26 | 2020-09-29 | 电子科技大学 | 一种基于大数据模型元数据的混合索引方法 |
-
2019
- 2019-04-04 CN CN201910271085.XA patent/CN110083601B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN110083601A (zh) | 2019-08-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110083601B (zh) | 面向键值存储***的索引树构建方法及*** | |
US8868926B2 (en) | Cryptographic hash database | |
US11899641B2 (en) | Trie-based indices for databases | |
US9672235B2 (en) | Method and system for dynamically partitioning very large database indices on write-once tables | |
US9575976B2 (en) | Methods and apparatuses to optimize updates in a file system based on birth time | |
US8224829B2 (en) | Database | |
US7558802B2 (en) | Information retrieving system | |
JP3771271B2 (ja) | コンパクト0完全木における順序付けられたキーの集まりの記憶と検索のための装置及び方法 | |
US7805427B1 (en) | Integrated search engine devices that support multi-way search trees having multi-column nodes | |
CN105975587B (zh) | 一种高性能的内存数据库索引组织与访问方法 | |
US9292554B2 (en) | Thin database indexing | |
CN112000846B (zh) | 基于gpu分组lsm树索引的方法 | |
US20120215752A1 (en) | Index for hybrid database | |
US8086641B1 (en) | Integrated search engine devices that utilize SPM-linked bit maps to reduce handle memory duplication and methods of operating same | |
CN113535670B (zh) | 一种虚拟化资源镜像存储***及其实现方法 | |
Petrov | Algorithms behind modern storage systems: Different uses for read-optimized b-trees and write-optimized lsm-trees | |
US7953721B1 (en) | Integrated search engine devices that support database key dumping and methods of operating same | |
Jensen et al. | Optimality in external memory hashing | |
US9292553B2 (en) | Queries for thin database indexing | |
Lin | Concurrent frame signature files | |
Shin et al. | Bucket-Sorted Hash Join. | |
Mohammed et al. | Information retrieval using dynamic indexing | |
CN117349477A (zh) | 一种基于持久化内存的图数据异构分层存储结构及其方法 | |
JP2871755B2 (ja) | ダイナミック・ハッシュにおけるスプリット制御方法 | |
Kale | Improving time and space efficiency of trie data structure |
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 |