CN112000845B - 一种基于gpu加速的超空间哈希索引方法 - Google Patents
一种基于gpu加速的超空间哈希索引方法 Download PDFInfo
- Publication number
- CN112000845B CN112000845B CN202010835717.3A CN202010835717A CN112000845B CN 112000845 B CN112000845 B CN 112000845B CN 202010835717 A CN202010835717 A CN 202010835717A CN 112000845 B CN112000845 B CN 112000845B
- Authority
- CN
- China
- Prior art keywords
- data
- gpu
- hash
- super
- node
- 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/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9024—Graphs; Linked lists
-
- 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/24—Querying
- G06F16/245—Query processing
- G06F16/24569—Query processing with adaptation to specific hardware, e.g. adapted for using GPUs or SSDs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9014—Indexing; Data structures therefor; Storage structures hash tables
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)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种基于GPU加速的超空间哈希索引方法。针对key‑value数据库,构建超空间哈希数据结构,使超空间哈希更好地适应GPU,在超空间哈希数据结构中,使用数组结构体而不是结构体数组的数据布局,其中键、次要属性和值分别存储;该数据结构更适合于GPU的线程执行模型和内存层次结构;对于批处理查询,使用通过查询分类来减少分支分歧的warp预组合数据共享策略,而且为了进一步提高超空间哈希数据结构的性能,用原子操作代替加锁,并设计了一种暂时重复读取策略来提高GHSH的性能,实现了无锁的全并发策略;最后,基于超空间哈希数据结构,实现了批量构建、按键搜索、按次要属性搜索、修改、***和删除的操作。
Description
技术领域
本发明涉及数据库索引技术领域,具体涉及一种基于GPU加速的超空间哈希索引方法。
背景技术
在大数据时代,越来越多的服务需要摄取大量、快速、多样的数据,如社交网络数据、智能手机应用使用数据、点击数据等。NoSQL数据库是作为关系数据库的可伸缩性和灵活性更好的替代品而开发的,NoSQL数据库包括Hbase(Hadoop Database)、ApacheCassandra等,引起了业界和学术界的广泛关注,并在产品中得到广泛应用。通过使用日志结构的合并树(LSM),NoSQL***特别擅长于支持两种功能:(a)快速写吞吐量,(b)对数据项的键进行快速查找。但是,许多应用程序还需要查询非键属性,这是关系型数据库中通常支持的功能。例如,如果一条推特tweet具有诸如tweet id、用户ID(身份标识号)和文本等属性,那么能够返回用户的所有推特tweet(或最近的推特tweet)将非常有用。然而,在NoSQL数据库中支持二级索引是一项挑战,因为在写期间必须维护二级索引结构,同时还要管理二级索引和数据表之间的一致性。这大大降低了写入速度,从而影响了***处理高写入吞吐量的能力。
为了解决这个问题,在HyperDex system(HyperDex是一种分布式***)中提出了超空间哈希,用于支持检索除键之外的部分指定的二级属性搜索的分布式键值存储。与独立的二级索引方法(例如Hbase中基于表的二级索引)相比,超空间哈希可以极大地节省存储空间,这对于内存数据库尤为重要。与KD-tree等嵌入式二级索引方法相比,超空间哈希可以快速定位数据所在的哈希桶,而不需要对每一层进行排序。超空间哈希将每个表表示为一个独立的多维空间,其中维度轴直接对应于表的属性。将对象的每个属性值散列到对应轴上的一个位置,从而将对象映射到空间中的一个确定性坐标。
HyperDex作为一种分布式***,可以缓解超空间哈希的性能问题。但是在一个集中的环境中,图形处理单元(简称GPU)加速是必须的。在过去的几年里,GPU作为数据存储应用程序的加速器的应用越来越多。与CPU相比,GPU有几个优点。首先,GPU使用数千个内核提供了大量的并行性,这些内核可以比CPU高几个数量级的吞吐量一起执行计算。例如,每台Nvidia Tesla V100 GPU将5120个CUDA核封装到多个流处理器(SM)中,能够提供14万亿次浮点运算的单精度浮点运算性能。其次,使用紧密集成的高带宽内存技术,GPU为设备内存提供接近1TB/s的带宽。第三,现代GPU也提供各种功能,如可编程共享内存,线程和同步原语,重叠计算技术与I/O等。
然而,超空间哈希应用在GPU处理器上,处理key-value数据库,并没有发挥GPU良好的并行处理能力。由于查询属性的数量无法事先确定,使用传统的超空间哈希结构,使得GPU上的内存吞吐量难以最大化。在同一GPU线程组中的两个并发执行的查询可能需要在不同的哈希桶中执行,或者需要查询不同的属性。这将导致分支分歧,大大降低查询性能。此外,更新可索引属性值将导致数据重新定位,这将进一步增加并发的复杂性。超空间哈希的这些特性与GPU的特性不匹配,阻碍了超空间哈希在GPU上的性能。
发明内容
针对现有技术的不足,本发明提出一种基于GPU加速的超空间哈希索引方法,包括以下步骤:
步骤1:以链表作为处理GPU中哈希冲突的方式,构建超空间哈希数据结构,包括:
步骤1.1:针对存储在GPU的key-value数据库中的n个数据,将所有数据的值value中查询频率大于预设频率H的属性抽离出来,记为次要属性A1,A2,…,Ai…,Ap,i=1,2,…,p,p表示可索引的次要属性的总个数,Ai表示抽离出来的第i个次要属性;
步骤1.2:根据GPU数据访问方式,构造每个存储数据的数据元组形式,定义第j个元组表示为{keyj,A1j,A2j,…Aij,…,Apj,valuej},其中,keyj表示第j个元组中的键,Aij表示第j个元组中的第i个次要属性,valuej表示第j个元组中的位置ID或值,j=1,2,…,n;
步骤1.3:并行构建超空间哈希数据结构,包括:
步骤1.3.1:根据抽离得到的p个次要属性,将GPU存储空间表示为一个p+1维空间,其中维度轴与元组的属性一一对应;
步骤1.3.2:将每个元组的每个属性值散列到对应轴上的一个确定位置,从而映射到存储空间中的一个确定性坐标,得到每个属性值对应的坐标值,则每个元组中第i个次要属性值在对应哈希桶的坐标为xi+1,每个元组中键key在对应哈希桶的坐标为x1;
步骤1.3.3:利用GPU的多线程任务处理方式,将n个数据同时定位到对应的哈希桶中,并存储在哈希桶对应的链表结构中,链表结构由超级节点连接而成,超级节点结构由键节点、属性节点、值节点构成,其中键节点、属性节点、值节点统称为基本节点,所述超级节点具体表示为:根据预设的基本节点的存储容量M,确定每个超级节点存储的元组数量其中size(key)表示键key的字节数,m个数据中的所有键key存储在同一个键节点中,m个数据抽离出的所有第i个次要属性值存储在同一个属性i节点中,m个数据中的所有值value存储在同一个值节点中,链表中的每个基本节点通过指针链接到下一个基本节点;
步骤2:对于超空间哈希数据结构,分类查询任务,合并查询路径,并行实现批量的键key、次要属性的索引查询;
步骤3:对于超空间哈希数据结构,并行实现批量数据的***;
步骤4:对于超空间哈希数据结构,并行实现批量数据的修改,维护数据的一致性;
步骤5:对于超空间哈希数据结构,并行实现批量数据的删除。
所述步骤2包括:
步骤2.1:定义通过哈希函数得到的查询属性Ai的坐标为a,判断每个哈希桶中坐标xi+1的位置是否为a,如果xi+1等于a,则将查询任务添加到对应哈希桶的任务队列中TQi,完成对哈希桶标号的分类,通过GPU的不同线程组执行不同的子任务;
步骤2.2:将每个哈希桶的任务队列中查询相同属性的任务分为同一个组,完成对查询类型的预组合,并将同一个哈希桶中同一个分组的任务分配给GPU的同一个线程组的线程执行;
步骤2.3:当需要执行查询操作时,GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于需要查询的目标数据,如果查询到的数据等于目标数据,则返回结果并将任务标记为解决;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完当前链表中的所有超级节点。
所述步骤3包括:
步骤3.1:利用GPU的多线程任务方式获取待***的数据任务,在键节点中搜索空节点;
步骤3.2:如果搜索到空节点,GPU的线程将待***数据的键、次要属性、值地址***到超级节点的空节点中,如果搜索不到空节点,所有线程需要从地址栏中获取下一个超级节点P1的地址;
步骤3.3:如果下一个超级节点P1的地址不为空,读取超级节点P1并重复步骤3.1~步骤3.2,如果下一个超级节点P1的地址为空,说明超级节点P1不存在,需要为待***的数据任务重新分配一个超级节点然后通过GPU的线程更新上一个超级节点P0的指针;
所述步骤4并行实现批量数据的修改分为两种方式,一种方式为更改不可查询的属性值,另一种方式为更改次要属性值,具体表述为:
步骤4.1:更改不可查询的属性值,包括如下步骤:
步骤4.1.1:利用GPU的多线程任务方式获取待修改数据任务,在超级节点中搜索待修改数据的键值;
步骤4.1.2:GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于待修改的数据,如果相等,则GPU的线程将超级节点中存储的value值修改为新的value值,并将任务标记为解决;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完链表中的所有超级节点;
步骤4.2:更改次要属性值,如果待修改数据的次要属性值修改后,原数据所在的哈希桶并未改变,则直接将修改后的新数据***哈希桶中;如果待修改数据的次要属性值修改后,原数据所在的哈希桶需要改变,则需要先将原位置数据删除,再将修改后的新元组通过哈希函数***到新对应的哈希桶中。
所述步骤5包括:
步骤5.1:利用GPU的多线程任务方式获取待删除的数据任务,在超级节点的键节点中搜索待删除数据的键值;
步骤5.2:GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于待删除的数据,如果相等,则GPU的线程将超级节点中存储的键值标记为无效;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完链表中的所有超级节点。
进一步地,针对查询、***、修改、删除任务同时批量进行时,对于读操作不需要加锁,***和原地修改使用全局内存配合原子操作,对于次要属性索引值修改引起的数据重定位问题,设计暂时重复读策略实现高并发,所述暂时重复读策略表述为:当查询、***、修改、删除中任意两种或多种任务同时进行的过程中涉及到数据的重定位问题,即查询到两个key值一样的数据时,返回其中任意一个数据即可。
本发明的有益效果是:
本发明提出了一种基于GPU加速的超空间哈希索引方法,针对GPU的多线程任务处理方式,设计了一种超空间哈希数据结构(超空间哈希数据结构简称GHSH),在GHSH中,采用数组结构体而不是结构体数组的数据布局,其中键、次要属性和值分别存储,超空间哈希数据结构更适合于GPU的线程执行模型和内存层次结构;其次,对于批处理查询,使用查询分类来减少分支分歧;针对超空间哈希数据结构,采用原子操作代替加锁的方法,并设计了一种暂时重复读取策略来提高GHSH的性能,实现了无锁的全并发策略;最后,基于超空间哈希数据结构,实现了批量构建、按键搜索、按次要属性搜索、修改、***和删除的操作。
附图说明
图1为本发明中的基于GPU加速的超空间哈希索引方法流程图。
图2为本发明中的超空间哈希数据结构图。
图3为本发明中的三维空间哈希示意图。
图4为本发明中的传统数据结构图。
图5为本发明中的元组结构示意图,其中,图(a)表示传统的元组结构示意图,图(b)表示本发明设计的元组结构示意图。
图6为本发明中的超空间哈希数据结构的散列原理图。
图7为本发明中的查询分类示意图,其中图(a)表示查询分类前的示意图,图(b)表示查询分类后的示意图。
图8为本发明中的warp预组合示意图,其中图(a)表示预组合前的内存访问情况,图(b)表示预组合后内存访问情况。
图9为本发明中的warp协作数据共享策略示意图,其中图(a)表示每个线程独立操作扫描链表节点示意图,图(b)表示一个warp中的线程相互合作共同完成每个线程任务的示意图。
图10为本发明中的并行实现数据修改的流程图。
具体实施方式
下面结合附图和具体实施实例对发明做进一步说明。
如图1所示,一种基于GPU加速的超空间哈希索引方法,利用超空间哈希的数据存储模型,充分发挥GPU的并行计算能力,结合多线程同步方法把串行执行的超空间哈希索引操作并行化,提出了基于GPU超空间哈希索引的查询、修改、***、删除的并行化算法,可以有效的解决超空间哈希索引的效率问题,如图1所示,包括如下步骤:
步骤1:以链表作为处理GPU中哈希冲突的方式,构建超空间哈希数据结构如图2所示,设计超空间哈希数据结构作为链表节点,将批量的数据存储于内存,利用GPU初始化数据,并行构建超空间哈希索引,具体包括如下步骤:
步骤1.1:根据历史查询信息,选择被查询频率较高的属性,作为二级索引的次要属性,针对存储在GPU的key-value数据库中的n个数据,将所有数据的值value中查询频率大于预设频率H的属性抽离出来,记为次要属性A1,A2,…,Ai…,Ap,i=1,2,…,p,p表示可索引的次要属性的总个数,Ai表示抽离出来的第i个次要属性;以张三为例给出三维空间哈希示意图,如图3所示,图中x轴表示姓氏属性,y轴表示名字属性,z轴表示电话号码属性。
步骤1.2:根据GPU数据访问方式,设计key-value元组形式如图5中的图(b)所示,图5中的图(a)为传统的元组结构示意图,构造每个存储数据的数据元组形式,定义第j个元组表示为{keyj,A1j,A2j,…Aij,…,Apj,valuej},其中,keyj表示第j个元组中的键,Aij表示第j个元组中的第i个次要属性,valuej表示第j个元组中的位置ID或值,j=1,2,…,n;
步骤1.3:并行构建超空间哈希数据结构,包括:
步骤1.3.1:根据抽离得到的p个次要属性,将GPU存储空间表示为一个p+1维空间,其中维度轴与元组的属性一一对应;
步骤1.3.2:将每个元组的每个属性值散列到对应轴上的一个确定位置,从而映射到存储空间中的一个确定性坐标,得到每个属性值对应的坐标值,则每个元组中第i个次要属性值在对应哈希桶的坐标为xi+1,每个元组中键key在对应哈希桶的坐标为x1,超空间哈希数据结构的散列原理图如图6所示,该坐标为超空间中哈希桶的唯一标识,多线程任务同时将所有数据按照上述规则定位到对应的哈希桶中,并存储在该哈希桶对应的链表结构中;如图6所示,根据元组tuple进行哈希计算的过程,将每一个属性进行哈希计算,通过每个属性的哈希值进而确定超空间哈希桶的唯一ID(身份标识号)。GHSH以链表作为处理冲突的方式。图4是传统的存储结构,图中KV1,KV2,…,KVm表示存储的数据,Next表示下一节点的指针,A1,A2表示从数据KV3可以抽离出两个次要属性,value表示数据KV3的值,key表示数据KV3的键,A1、A2表示抽离出的两个次要属性,这种传统的存储结构直接用于GPU上,不利于数据的合并访存,因此本发明设计的超空间哈希数据结构如图5所示,将每个链表节点设计为一个超级节点,在这个节点中存储多个tuple和指向下一节点的指针;考虑GPU的最大带宽是128Byte以及每个key和值value(简称val)的字节大小,一个链表节点存储31个tuple和指向下一节点的指针;为了适应GPU的硬件特性,每个超级节点包含多个基本节点(键节点key Node、属性节点Attribute Nodes和值节点Value Node),将key值,可查询次要属性值以及对应的value值分开存储,并且每个基本节点都有指向下一个节点的指针,这样可以将key查询与节点node查询分开路径,增大并行度。
步骤1.3.3:利用GPU的多线程任务处理方式,将n个数据同时定位到对应的哈希桶中,并存储在哈希桶对应的链表结构中,链表结构由超级节点连接而成,超级节点结构由键节点、属性节点、值节点构成,其中键节点、属性节点、值节点统称为基本节点,所述超级节点具体表示为:根据预设的基本节点的存储容量M,即每个超级节点中的每个键节点、属性节点、值节点的存储容量均为M,确定每个超级节点存储的元组数量其中size(key)表示键key的字节数,键key、次要属性Ai、值value的字节大小设置为相等,表示向下取整,从个元组中预留出一个元组用来存放指向下一个超级节点的指针,所以需要从取整数的个元组中减去1,m个数据中的所有键key存储在同一个键节点中,m个数据抽离出的所有第i个次要属性值存储在同一个属性i节点中,m个数据中的所有值value存储在同一个值节点中,链表中的每个基本节点通过指针链接到下一个基本节点;
图2以两个次要属性为例,图中给出了由m个元组构成的超级节点,其中key1,…,keym表示每个数据的键值,表示每个数据抽离出来的第一个次要属性,表示每个数据抽离出来的第二个次要属性,Sign表示value中预留出的空节点,可以根据实际需要设置具体值;
步骤2:对于超空间哈希数据结构,分类查询任务,合并查询路径,并行实现批量的键key、次要属性的索引查询;由于cuda(cuda表示由NVIDIA推出的通用并行计算架构)的编程模型下,默认一组线程需要执行相同的路径,如果产生分支,会造成线程串行执行,为了避免这种情况的发生,需要查询任务进行分类预处理,具体表述为:
步骤2.1:根据BucketID(哈希桶坐标)进行分类,如图7所示,每个哈希桶维护一个任务队列,每个查询任务根据被查询属性被解析为多个子任务,定义通过哈希函数得到的查询属性Ai的坐标为a,判断每个哈希桶中坐标xi+1的位置是否为a,如果xi+1等于a,则将查询任务添加到对应哈希桶的任务队列中TQi,完成对哈希桶标号的分类,每个哈希桶维护一个任务队列TQi,所有子任务添加到相应哈希桶的任务队列中,通过GPU的不同线程组执行不同的子任务;当GPU生成线程组获取查询任务时,基于每个哈希桶的任务队列进行任务分配,这样线程组的任务查询路径统一,不会造成线程分支,从图7中的图(a)可以看出来查询分类前,每个线程访问的哈希桶杂乱,容易产生分支分歧,从图7中的图(b)可以看出经过分类之后位于同一个哈希桶的任务有相同的查询路径。
步骤2.2:根据查询类型进行预组合,每个查询任务的查询属性不同,可能查A1、A2或Ap,根据查询属性的不同,将每个哈希桶队列中的任务再次进行分组,将每个哈希桶的任务队列中查询相同属性的任务分为同一个组,完成对查询类型的预组合,并将同一个哈希桶中同一个分组的任务分配给GPU的同一个线程组的线程执行;如图8所示,每个任务队列TQi中的线程按照Ai进行分组,由于节点内部将key、可查询次要属性以及value分开存储,导致按key查询和按属性查询的路径也不相同,所以需要再次进行分类,尽量让查询类型相同的任务位于同一个线程组,GPU中采用线程组warp(32个线程为一组)完成预组合处理,这里称之为是warp预组合,warp预组合的示意图如图8所示,其中图8中图(a)表示预组合前的内存访问情况,图(b)表示预组合后内存访问情况,同一线程组的线程合并访存,减少了访问内存的次数。
按以上规则分类组织任务之后,每个线程组中的线程根据它携带的任务编号决定它应该读取的数据部分。虽然读取位置不同,但每个线程都需要对节点中的数据做出有条件的判断。第一个线程读取的地址被分配给其他线程;
步骤2.3:当需要执行查询操作时,GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于需要查询的目标数据,如果查询到的数据等于目标数据,则返回结果并将任务标记为解决;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完当前链表中的所有超级节点。
查询的算法设计如下:
步骤3:对于超空间哈希数据结构,并行实现批量数据的***;针对超空间哈希数据结构的特点,提出一种warp协作数据共享策略,在查找过程中,一个warp的线程分别有独立的查询任务,但该线程组中的线程协作,一起读取某个超级节点中各自对应的部分,并将读取到的结果存入share memory(共享内存),线程组中的所有线程共享读取到的数据。针对超空间哈希数据结构,一个warp中的所有线程可以并行比较当前节点是否有目标。warp协作数据共享策略如图9所示,一个线程组的线程(32个线程)都有自己的任务,但是由于查询路径相同,32个线程可以合作同时读取一个节点中所有位置的值存入共享内存,同时每个线程可以并行的去比较是否有自己的目标值,如果有,标记任务已解析,之后所有线程根据指向下一节点的指针共同遍历下一个节点中的值进行比较,以此类推,直到到达链表结尾。
多个线程获取***任务,在超级节点的键节点中搜索空点。如果找到,线程使用原子比较交换操作将其键、二级属性和值地址***到超级节点的相应节点中。如果失败,则意味着其他一些线程组warp已经***到那个空白点。然后,整个过程应该重新启动。如果没有找到空点,所有线程将从地址栏中获得下一个超级节点的地址。如果地址不是空的,我们应该读取一个新的超级节点并重复***过程。否则,应该分配一个新的超级节点。然后,线程使用atomicCAS更新上一个超级节点的指针。如果atomicCAS成功,则使用新分配的超级节点重复整个***过程。如果没有,则意味着另一个线程已经分配并***了一个新的超级节点。然后,应该重新分配超级节点,并使用新的超级节点重新启动进程;具体表述为如下步骤:
步骤3.1:利用GPU的多线程任务方式获取待***的数据任务,在键节点中搜索空节点;
步骤3.2:如果搜索到空节点,GPU的线程将待***数据对应的键、次要属性、值地址***到超级节点的空节点中,如果搜索不到空节点,所有线程需要从地址栏中获取下一个超级节点P1的地址;
步骤3.3:如果下一个超级节点P1的地址不为空,读取超级节点P1并重复步骤3.1~步骤3.2,如果下一个超级节点P1的地址为空,说明超级节点P1不存在,需要为待***的数据任务重新分配一个超级节点然后通过GPU的线程更新上一个超级节点P0的指针;
步骤4:对于超空间哈希数据结构,并行实现批量数据的修改,如图10所示,维护数据的一致性;
所述步骤4并行实现批量数据的修改分为两种方式,一种方式为更改不可查询的属性值,另一种方式为更改次要属性值,具体表述为:
步骤4.1:更改不可查询的属性值,包括如下步骤:
步骤4.1.1:利用GPU的多线程任务方式获取待修改数据任务,在超级节点中搜索待修改数据的键值;
步骤4.1.2:GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于待修改的数据,如果相等,则GPU的线程使用原子比较交换操作将超级节点中存储的value值修改为新的value值,并将任务标记为解决;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完链表中的所有超级节点;
步骤4.2:更改次要属性值,如果待修改数据的次要属性值修改后,原数据所在的哈希桶并未改变,则直接将修改后的新数据***哈希桶中;如果待修改数据的次要属性值修改后,原数据所在的哈希桶需要改变,则需要先将原位置数据删除,再将修改后的新元组通过哈希函数***到新对应的哈希桶中。
步骤5:对于超空间哈希数据结构,并行实现批量数据的删除;
步骤5.1:利用GPU的多线程任务方式获取待删除的数据任务,在超级节点的键节点中搜索待删除数据的键值;
步骤5.2:GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于待删除的数据,如果相等,则GPU的线程将超级节点中存储的键值标记为无效;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完链表中的所有超级节点。
针对查询、***、修改、删除任务同时批量进行时,对于读操作不需要加锁,***和原地修改使用全局内存配合原子操作,对于次要属性索引值修改引起的数据重定位问题,设计暂时重复读策略实现高并发,所述暂时重复读策略表述为:当查询、***、修改、删除中任意两种或多种任务同时进行的过程中涉及到数据的重定位问题,即查询到两个key值一样的数据时,返回其中任意一个数据即可;根据上述暂时重复读策略,批量任务可以有不同的任务类型,线程根据任务类型不同,进行相应的***、删除、修改、搜索操作。
Claims (6)
1.一种基于GPU加速的超空间哈希索引方法,其特征在于,包括如下步骤:
步骤1:以链表作为处理GPU中哈希冲突的方式,构建超空间哈希数据结构,包括:
步骤1.1:针对存储在GPU的key-value数据库中的n个数据,将所有数据的值value中查询频率大于预设频率H的属性抽离出来,记为次要属性A1,A2,…,Ai…,Ap,i=1,2,…,p,p表示可索引的次要属性的总个数,Ai表示抽离出来的第i个次要属性;
步骤1.2:根据GPU数据访问方式,构造每个存储数据的数据元组形式,定义第j个元组表示为{keyj,A1j,A2j,…Aij,…,Apj,valuej},其中,keyj表示第j个元组中的键,Aij表示第j个元组中的第i个次要属性,valuej表示第j个元组中的位置ID或值,j=1,2,…,n;
步骤1.3:并行构建超空间哈希数据结构,包括:
步骤1.3.1:根据抽离得到的p个次要属性,将GPU存储空间表示为一个p+1维空间,其中维度轴与元组的属性一一对应;
步骤1.3.2:将每个元组的每个属性值散列到对应轴上的一个确定位置,从而映射到存储空间中的一个确定性坐标,得到每个属性值的坐标值,则每个元组中第i个次要属性值在对应哈希桶的坐标为xi+1,每个元组中键key在对应哈希桶的坐标为x1;
步骤1.3.3:利用GPU的多线程任务处理方式,将n个数据同时定位到对应的哈希桶中,并存储在哈希桶对应的链表结构中,链表结构由超级节点连接而成,超级节点结构由键节点、属性节点、值节点构成,其中键节点、属性节点、值节点统称为基本节点,所述超级节点具体表示为:根据预设的基本节点的存储容量M,确定每个超级节点存储的元组数量其中size(key)表示键key的字节数,m个数据中的所有键key存储在同一个键节点中,m个数据抽离出的所有第i个次要属性值存储在同一个属性i节点中,m个数据中的所有值value存储在同一个值节点中,链表中的每个基本节点通过指针链接到下一个基本节点;
步骤2:对于超空间哈希数据结构,分类查询任务,合并查询路径,并行实现批量的键key、次要属性的索引查询;
步骤3:对于超空间哈希数据结构,并行实现批量数据的***;
步骤4:对于超空间哈希数据结构,并行实现批量数据的修改,维护数据的一致性;
步骤5:对于超空间哈希数据结构,并行实现批量数据的删除。
2.根据权利要求1所述的一种基于GPU加速的超空间哈希索引方法,其特征在于,所述步骤2包括:
步骤2.1:定义通过哈希函数得到的查询属性Ai的坐标为a,判断每个哈希桶中坐标xi+1的位置是否为a,如果xi+1等于a,则将查询任务添加到对应哈希桶的任务队列中TQi,完成对哈希桶标号的分类,通过GPU的不同线程组执行不同的子任务;
步骤2.2:将每个哈希桶的任务队列中查询相同属性的任务分为同一个组,完成对查询类型的预组合,并将同一个哈希桶中同一个分组的任务分配给GPU的同一个线程组的线程执行;
步骤2.3:当需要执行查询操作时,GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于需要查询的目标数据,如果查询到的数据等于目标数据,则返回结果并将任务标记为解决;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完当前链表中的所有超级节点。
3.根据权利要求1所述的一种基于GPU加速的超空间哈希索引方法,其特征在于,所述步骤3包括:
步骤3.1:利用GPU的多线程任务方式获取待***的数据任务,在键节点中搜索空节点;
步骤3.2:如果搜索到空节点,GPU的线程将待***数据的键、次要属性、值地址***到超级节点的空节点中,如果搜索不到空节点,所有线程需要从地址栏中获取下一个超级节点P1的地址;
步骤3.3:如果下一个超级节点P1的地址不为空,读取超级节点P1并重复步骤3.1~步骤3.2,如果下一个超级节点P1的地址为空,说明超级节点P1不存在,需要为待***的数据任务重新分配一个超级节点然后通过GPU的线程更新上一个超级节点P0的指针;
4.根据权利要求1所述的一种基于GPU加速的超空间哈希索引方法,其特征在于,所述步骤4并行实现批量数据的修改分为两种方式,一种方式为更改不可查询的属性值,另一种方式为更改次要属性值,具体表述为:
步骤4.1:更改不可查询的属性值,包括如下步骤:
步骤4.1.1:利用GPU的多线程任务方式获取待修改数据任务,在超级节点中搜索待修改数据的键值;
步骤4.1.2:GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于待修改的数据,如果相等,则GPU的线程将超级节点中存储的value值修改为新的value值,并将任务标记为解决;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完链表中的所有超级节点;
步骤4.2:更改次要属性值,如果待修改数据的次要属性值修改后,原数据所在的哈希桶并未改变,则直接将修改后的新数据***哈希桶中;如果待修改数据的次要属性值修改后,原数据所在的哈希桶需要改变,则需要先将原位置数据删除,再将修改后的新元组通过哈希函数***到新对应的哈希桶中。
5.根据权利要求1所述的一种基于GPU加速的超空间哈希索引方法,其特征在于,所述步骤5包括:
步骤5.1:利用GPU的多线程任务方式获取待删除的数据任务,在超级节点的键节点中搜索待删除数据的键值;
步骤5.2:GPU从超空间哈希数据结构读取哈希桶的坐标,一个线程组的线程同时检查当前超级节点中存储的数据是否等于待删除的数据,如果相等,则GPU的线程将超级节点中存储的键值标记为无效;否则,GPU的每个线程读取地址单元标记的指针,并根据指针查找下一个链表节点,直到查找完链表中的所有超级节点。
6.根据权利要求2~5任意一项所述的一种基于GPU加速的超空间哈希索引方法,其特征在于,针对查询、***、修改、删除任务同时批量进行时,对于读操作不需要加锁,***和原地修改使用全局内存配合原子操作,对于次要属性索引值修改引起的数据重定位问题,设计暂时重复读策略实现高并发,所述暂时重复读策略表述为:当查询、***、修改、删除中任意两种或多种任务同时进行的过程中涉及到数据的重定位问题,即查询到两个key值一样的数据时,返回其中任意一个数据即可。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010835717.3A CN112000845B (zh) | 2020-08-19 | 2020-08-19 | 一种基于gpu加速的超空间哈希索引方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010835717.3A CN112000845B (zh) | 2020-08-19 | 2020-08-19 | 一种基于gpu加速的超空间哈希索引方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112000845A CN112000845A (zh) | 2020-11-27 |
CN112000845B true CN112000845B (zh) | 2021-07-20 |
Family
ID=73472771
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010835717.3A Active CN112000845B (zh) | 2020-08-19 | 2020-08-19 | 一种基于gpu加速的超空间哈希索引方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112000845B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113721862B (zh) * | 2021-11-02 | 2022-02-08 | 腾讯科技(深圳)有限公司 | 数据处理方法及装置 |
CN116301636B (zh) * | 2023-03-22 | 2023-12-22 | 鹏钛存储技术(南京)有限公司 | 一种管理数据结构的方法以及基于哈希算法的硬件加速器 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107577990A (zh) * | 2017-08-09 | 2018-01-12 | 武汉世纪金桥安全技术有限公司 | 一种基于gpu加速检索的大规模人脸识别方法 |
CN109947762A (zh) * | 2017-08-16 | 2019-06-28 | 深圳市中兴微电子技术有限公司 | 一种哈希表管理方法及装置、计算机可读存储介质 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8851999B2 (en) * | 2002-12-10 | 2014-10-07 | Ol2, Inc. | System and method for improving the graphics performance of hosted applications |
-
2020
- 2020-08-19 CN CN202010835717.3A patent/CN112000845B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107577990A (zh) * | 2017-08-09 | 2018-01-12 | 武汉世纪金桥安全技术有限公司 | 一种基于gpu加速检索的大规模人脸识别方法 |
CN109947762A (zh) * | 2017-08-16 | 2019-06-28 | 深圳市中兴微电子技术有限公司 | 一种哈希表管理方法及装置、计算机可读存储介质 |
Non-Patent Citations (1)
Title |
---|
基于GPU的可扩展哈希方法;胡学萱等;《华南理工大学学报(自然科学版)》;20150115;全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN112000845A (zh) | 2020-11-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Motik et al. | Parallel materialisation of datalog programs in centralised, main-memory RDF systems | |
US11449507B2 (en) | Database engine | |
Bu et al. | Pregelix: Big (ger) graph analytics on a dataflow engine | |
US8140585B2 (en) | Method and apparatus for partitioning and sorting a data set on a multi-processor system | |
US7734714B2 (en) | Spatial Sieve Tree | |
AU2016371481B2 (en) | Processing data using dynamic partitioning | |
Bernstein et al. | Optimizing optimistic concurrency control for tree-structured, log-structured databases | |
Prasad et al. | GPU-based Parallel R-tree Construction and Querying | |
CN104778077B (zh) | 基于随机和连续磁盘访问的高速核外图处理方法及*** | |
Bugiotti et al. | RDF data management in the Amazon cloud | |
CN112000845B (zh) | 一种基于gpu加速的超空间哈希索引方法 | |
Ashkiani et al. | GPU LSM: A dynamic dictionary data structure for the GPU | |
CN104750720A (zh) | 多线程并发访问环境下高性能数据处理的实现 | |
Sun et al. | Learned index: A comprehensive experimental evaluation | |
Challa et al. | DD-Rtree: A dynamic distributed data structure for efficient data distribution among cluster nodes for spatial data mining algorithms | |
Chrysafis et al. | Foundationdb record layer: A multi-tenant structured datastore | |
Ashkiani et al. | GPU Multisplit: an extended study of a parallel algorithm | |
Liu et al. | Improving density peaks clustering through GPU acceleration | |
Yang et al. | GPU acceleration of subgraph isomorphism search in large scale graph | |
Kim et al. | A performance study of traversing spatial indexing structures in parallel on GPU | |
CN106776810A (zh) | 一种大数据的数据处理***及方法 | |
Safaee et al. | A distributed B+ Tree indexing method for processing range queries over streaming data | |
Ren et al. | GPU-based dynamic hyperspace hash with full concurrency | |
Li et al. | A Survey of Multi-Dimensional Indexes: Past and Future Trends | |
Salah et al. | Lazy-Merge: A Novel Implementation for Indexed Parallel $ K $-Way In-Place Merging |
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 |