CN110069431B - 基于RDMA和HTM的弹性Key-Value键值对数据存储方法 - Google Patents
基于RDMA和HTM的弹性Key-Value键值对数据存储方法 Download PDFInfo
- Publication number
- CN110069431B CN110069431B CN201810070442.1A CN201810070442A CN110069431B CN 110069431 B CN110069431 B CN 110069431B CN 201810070442 A CN201810070442 A CN 201810070442A CN 110069431 B CN110069431 B CN 110069431B
- Authority
- CN
- China
- Prior art keywords
- data
- key
- hash
- rdma
- value pair
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 58
- 238000013500 data storage Methods 0.000 title claims abstract description 37
- 238000013523 data management Methods 0.000 claims abstract description 77
- 238000004891 communication Methods 0.000 claims abstract description 41
- 238000005516 engineering process Methods 0.000 claims abstract description 32
- 238000003780 insertion Methods 0.000 claims abstract description 24
- 230000037431 insertion Effects 0.000 claims abstract description 24
- 230000008569 process Effects 0.000 claims abstract description 15
- 230000005540 biological transmission Effects 0.000 claims abstract description 13
- 230000004044 response Effects 0.000 claims abstract description 6
- 238000012795 verification Methods 0.000 claims abstract description 4
- 230000006870 function Effects 0.000 claims description 58
- 241000544061 Cuculus canorus Species 0.000 claims description 44
- 238000007726 management method Methods 0.000 claims description 16
- 238000013507 mapping Methods 0.000 claims description 14
- 238000013479 data entry Methods 0.000 claims description 11
- 238000010586 diagram Methods 0.000 claims description 11
- 238000001152 differential interference contrast microscopy Methods 0.000 claims description 9
- 230000003993 interaction Effects 0.000 claims description 8
- 230000015556 catabolic process Effects 0.000 claims description 5
- 238000006731 degradation reaction Methods 0.000 claims description 5
- 238000007405 data analysis Methods 0.000 claims description 4
- 238000005295 random walk Methods 0.000 claims description 4
- 241000714203 Rabbit hemorrhagic disease virus Species 0.000 claims description 3
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 238000012544 monitoring process Methods 0.000 claims description 3
- 230000003068 static effect Effects 0.000 claims description 3
- 230000008901 benefit Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000011156 evaluation Methods 0.000 description 3
- 238000002474 experimental method Methods 0.000 description 3
- 244000144980 herd Species 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000007547 defect Effects 0.000 description 2
- 239000010445 mica Substances 0.000 description 2
- 229910052618 mica group Inorganic materials 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 230000003321 amplification Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000002360 explosive Substances 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000003199 nucleic acid amplification method Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
- 238000009827 uniform distribution Methods 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
- G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal
-
- 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/2255—Hash tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供了一种基于RDMA和HTM的弹性Key‑Value键值对数据存储方法，设计遵循服务器端—客户端架构模式，包括：在服务器端，结合哈希图给出改进型的G‑Cuckoo哈希数据管理模式，避免在数据***过程中查找空闲位置而导致的哈希表之间kick‑out无限循环问题；分析在客户端与服务器端之间传统网络传递消息需要来回round响应而引起的键值对存储性能瓶颈问题，使用Infiniband远程直接内存访问RDMA技术，设计RDMA网络通信引擎，接收数据访问请求和送回数据请求结果；利用硬件事务内存HTM技术，实现两段锁协议锁操作，保障数据操作原子特性；使用键值对数据自验证检验码保障数据一致性。本发明实现可极大提升键值对数据基本操作速度。
Description
技术领域
本发明属于计算机***与数据存储***领域，具体涉及一种基于RDMA和HTM的弹性Key-Value键值对数据存储方法，可以提供快速的、有规模性的数据服务。
背景技术
现今阶段，数据密集型计算需求与日俱增，提供给数据密集型计算的数据一般都存放在存储***中。除了关系型数据库等存储***外，越来越多的键值对存储***不断出现，也可以满足数据的快速访问。对于键值对存储***而言，如何获得数据访问的低延时和高吞吐量已成为一个值得深入研究与探讨的议题。
在分布式集群环境中，往往需要通过传统网络对键值对存储***开展远程数据访问。在此情况下，需要包含负责数据管理的服务器端和访问数据的客户端两者的共同参与，存在数据访问延时问题。例如，经典的Ethernet网络就会存在性能瓶颈问题，网络轮回缺陷将导致快速数据传输与访问存在一定弊端，键值对存储***的高性能数据访问并不能很好地利用。Infiniband远程直接内存访问Remote Direct Memory Access(RDMA)技术已经出现，这给使用传统网络远程访问键值对存储***中的数据带来优化的可能性。较为常用的方式是采用Infiniband RDMA技术，减轻数据访问请求延时较长的问题。
著名的英特尔公司和Mellanox公司是主要的InfiniBand适配器生产商。Mellanox40Gbps ConnectX-3 RNIC的通信代价开销要比10Gbps Ethernet adapter远小地多。实际上，Infiniband RDMA READs技术绕过CPU初始化控制传输，便利地访问远程内存，如同操作本地内存一样。例如，Pilaf键值对存储***就直接使用RDMA Reads对键值对数据开展GET操作。更多地，FaRM键值对存储***和HERD键值对存储***的吞吐量和速度提升的原因主要来自于高性能网络栈以及CPU核绕过技术。直接利用RDMA READs技术开展数据读写操作，其中，开展复杂指针操作是十分困难的，例如，操作远程内存的dereferencing指针和following指针就显得十分地繁杂。
因此，在设计键值对存储管理时，尝试不直接采用RDMA READs进行内存指针操作，而是为哈希数据管理模式管理键值对数据，设计高性能的RDMA消息通信库开展数据传输通信，这样可以有效避免操作远程内存中的复杂指针。尝试利用高性能RDMA通信协议构建有效的通信库引擎开展数据通信，并对哈希数据管理模式中的数据进行直接操作，从而取得RDMA READs直接访问内存获取数据的同样效果。
在键值对存储***中操作数据，数据操作的原子性需要得到保障，避免数据并发请求冲突。虽然键值对数据存储***数据操作较为简单，但是在哈希数据管理模式中，底层数据结构操作较为复杂。任何在远程机器上的数据并发冲突请求，都将导致整体作业的中断退出。当前，硬件事务内存Hardware Transactional Memory(HTM)主要以限制性事务内存Restricted Transactional Memory(RTM)和硬件锁省略Hardware LockElision(HLE)方式出现。已经有研究者和工程师们利用HTM技术提供请求竞争管理，有效避免死锁发生。
实际上，结合HTM和RDMA技术设计基于哈希数据管理模式的键值对存储***是十分重要的。基于“RDMA+HTM”键值对存储管理需要包含以下几大特征：(i)数据存取的高效率和高吞吐量特性；(ii)基于RDMA通信具备较低CPU使用量；(iii)有效率的哈希数据管理模式设计；(iii)无数据请求冲突，等等。
Key-Value键值对数据库是传统关系型数据库的一个简化，使性能优势最大，数据间耦合度最低。总地来说，现有主要有3种主要实现方式：(1)通过B+树实现。B+树通过增加每个计算节点的子节点数目来尽可能减小整棵树的高度，减少外存设备的读写次数。其优点是查询效率较高；缺点是大量随机写容易造成节点碎片化，导致性能下降。(2)基于Hash表实现，例如Redis，基于Hash表实现的优点是查询效率高，缺点是不能支持范围查询，当出现大量Hash值碰撞时会导致读写效率下降。ShenZhaoyan等人提出基于Hash表的Key-Value键值对存储***，消除Hash表和FTL的地址映射表存在的冗余映射的问题。(3)基于Log-Structured-Merge tree(LSM tree)实现，例如levelDB，其优点是写性能很高，缺点是读性能表现不佳且容易造成严重的写放大。
现有技术给出一系列的弹性Key-Value键值对数据存储管理原理和实现等。键值对存储***已经获得蓬勃的发展。例如，Redis是一种基于RAM的键值对存储***，它是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型Key-Value键值对数据库，提供多种语言的API函数。然而，它没有直接利用RDMA协议开展数据传输。由于RDMA技术的高带宽和低延时特性，以及单边零负载CPU消耗能力，使用RDMA协议开展高效的数据传输已经被广泛关注，HERD键值对存储******化地分析RDMA原语的优点与缺点。HERD并没有保证可靠的数据传输。此外，RAMCloud存储***是完全使用DRAM的存储***，所有数据都保存到内存中。另外，Pilaf键值对存储***利用RDMA READs提高数据GET操作的性能。键值对存储***MICA键值对存储***部署在多核***中，它可以操作65.6到76.9百万每秒的键值对操作。MICA将客户端请求直接地映射到服务器端特定的CPU核NIC层，使用轻量级网络栈技术，绕过内核开展数据操作。Wu等提出键值对数据缓存zExpander，键值对数据缓存具备高性能和较低的准确率，他们也提出基于NVM的新型键值对缓存存储***NVMcached。
总地来说，基于RDMA和HTM的弹性Key-Value键值对数据存储方法一方面缺乏对诸如高性能数据传输网络协议、保障数据操作原子特性的硬件事务内存管理等强有力软件与程序支撑；另一方面，还存在数据管理模式效率不高，没有设计数据缓存存储最近已经访问过的数据、数据一致性机制差等的问题，数据操作的并行程度也有待进一步提升。因此，对基于RDMA和HTM的弹性Key-Value键值对数据存储管理的研究可以大大提升密集型数据处理的能力和并行性，有效缓解数据传输延迟等。
发明内容
针对现有技术中的缺陷，本发明的目的在于提供一种基于RDMA和HTM的弹性Key-Value键值对数据存储方法。从通信速度和I/O吞吐角度出发，关注高吞吐量和低延迟指标的提升。现今的高性能通信网络、高内存技术、硬件事务内存等技术的发展也为弹性Key-Value键值对数据存储管理提供有力技术支撑。该方法充分利用上述先进技术，提高键值对存储***的数据读写性能，为在集群***中进行大规模的数据密集型计算性能提升奠定基础。
本发明是根据以下技术方案实现的：
一种基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，包括如下步骤：
步骤1：遵循服务器端-客户端架构模式，利用硬件事务内存HTM和远程直接内存访问RDMA，构建大规模数据密集型计算的弹性Key-Value键值对数据存储管理***；
步骤2：在服务器端，键值对数据存储管理***使用桶-点bucket-vertex映射方式构建哈希图，并给出改进型的G-Cuckoo哈希数据管理模式，避免在数据***过程中需要查找空闲的位置而导致的在哈希表之间无限循环kick-out踢数据条目的问题；
步骤3：通过自定义数据访问接口获取客户端的数据请求；
步骤4：在客户端与服务器端之间，分析传统网络来回round响应而引起的键值对存储性能瓶颈问题，使用Infiniband远程直接内存访问RDMA SEND/RECVverbs技术，设计RDMA网络通信引擎，接收数据访问请求和返回数据请求结果给客户端；
步骤5：利用硬件事务内存HTM，实现遵循加锁和释放锁协议的锁操作，形成数据操作HTM区域，保障基本数据操作的原子特性；
步骤6：使用键值对数据的自验证Checksum检验码以保证数据一致性。
上述技术方案中，在所述的步骤1中，构建弹性Key-Value键值对数据存储管理***，具体如下：
键值对存储***整体部署在InfiniBand网络集群环境中，承担着数据存取和为上层数据分析型应用提供数据I/O请求服务的角色，客户端根据改进型的Cuckoo哈希数据管理模式G-Cuckoo定位键值对数据存储位置，键值对存储***管理哈希表键值对数据，并利用two-sided RDMA SEND/RECV verbs技术开展消息通信；
所有数据都存放在服务器端的DRAM中，通过RDMA网络为客户端提供有效的数据服务；利用服务器的计算能力，采纳HTM感知的、RDMA友好的哈希表，每一个Key-Value键值对在两个哈希表中都有对应的存放位置和备份位置，用边连接这两个位置，边的起点对应于键值对的实际存放位置，而边的末尾对应于键值对的实际备份存放位置，哈希数据管理模式采纳两个静态的哈希函数h1(x)和h2(x)；当一个数据请求被发送到服务器端时，相关控制消息需要预先发送到服务器端；当接收到数据请求后，服务器端提供数据读写服务，将数据封装成有效载荷payload返回给客户端。
上述技术方案中，在所述的步骤2中，G-Cuckoo哈希数据管理模式具体如下：
选择经典的Cuckoo哈希数据管理模式，并做相应改进，作为键值对存储***数据管理策略，其中经典的Cuckoo哈希数据管理模式：如果存在着d(d>0)个哈希表，令K为键值对的key键集合，哈希表T1和哈希表T2分别拥有n个数据项，给出两个独立函数h1,h2:K→{0,...,n-1}，key键k∈K可被***到哈希表T1的位置h1(k)或哈希表T2的位置h2(k)，Cuckoo哈希数据管理模式拥有基本数据操作方式；在开展键值对PUT操作时，服务器端需要计算键值对***的候选位置，key键在哈希表中拥有一个或两个位置，一旦想要***的候选位置已经被其他的键值对数据所占有，kick-out操作将会被执行，即键值对需要从一个哈希表踢到另外一个哈希表的空闲位置；
当***一个键值对数据条目时，传统的Cuckoo哈希数据管理模式采纳随机游走方法寻找空闲bucket位置，这导致***数据的无限循环和性能衰退问题；在经典Cuckoo哈希数据管理模式中，为了寻找空闲数据条目***位置，不断的kick-out操作问题可以被中断，并转向替换性的重新哈希操作，这样会出现时间延迟问题；
改进经典的Cuckoo哈希数据管理模式，在kick-out操作中融入无限循环预测功能，当d＝2时，Cuckoo哈希数据管理模式存在着两个表，每个***到哈希数据管理模式中的实际位置都有与之对应的备份位置，提供kick-out操作后的存储位置，表之间都存在着多条边，采用bucket-vertex映射方式将哈希表的各个位置映射到哈希图中，提出改进型的Cuckoo哈希数据管理模式G-Cuckoo，预测避免无限kick-out来回踢问题。
上述技术方案中，在所述的步骤3中，定义数据访问接口获取客户端的数据请求，具体如下：
提供用户使用的接口，这些接口包含数值设置函数rhkv_set、数值获取函数rhkv_get和数值更新函数rhkv_update。
上述技术方案中，在所述的步骤4中，设计Infiniband RDMA网络通信引擎，具体如下：
数据消息通信操作Infiniband RDMA网络引擎采用two-sided隧道语义，用户空间程序通过使用RDMA verbs函数访问RDMA NICs，其中RDMA NICs基于硬件丢失包重传方式提供可靠传输，RDMANICs包含two-sided隧道语义和绕过目标CPU的one-sided内存语义，在RDMA NICs里维护消息队列queue，队列queue以两种形式存在：发送队列send queue和接收队列receive queue，称之为aqueue pair；当RHKV接收到数据操作请求，将通过RDMA网络引擎与改进的G-Cuckoo哈希数据管理模式开展数据交互，最终查找到相对应的键值对数据位置用于数据***或其他数据操作。
上述技术方案中，在步骤5中，遵循加锁和释放锁协议的锁操作，形成数据操作HTM区域，具体包括：
在开始Start阶段，HTM事务加锁和预取远程数据记录，通过运行XACQUIRE启动HTMtransaction；在局部事务LocalTX阶段，HTM事务对所有的局部记录提供事务级别的读和写；在提交Commit阶段，通过使用XRELEASE提交数据操作的HTM事务，数据记录更新后释放锁。
上述技术方案中，在所述的步骤6中，键值对数据的自验证Checksum过程如下：
(1)首先计算key键值的实际哈希值；
(2)从哈希表中查询想要获得的数值；
(3)获得键值对的内容计算Checksum值；
(4)比较内容与存储在哈希表中bucket的Checksum值是否一样。
上述技术方案中，数据的请求需要与哈希数据管理模式进行消息交互，具体包括：
(1)服务器端Server注册回调操作柄callback handler，绑定并监听新到达的客户端数据操作，当数据请求操作被执行后，连接将中断并对客户端连接监听的解绑操作；
(2)客户端Client设置host信息，RDMA通信组件给出构造器constructor和析构器destructor，分别用于初始化和释放Infiniband连接，定义函数connect用于添加connection数组，在Infiniband RDMA通信组件中，使用函数init、insert和free操作Infiniband连接数组，客户端发送的内容被存放在char vector数据结构中，并被封装为通信消息。
与现有技术相比，本发明具有如下的有益效果：
本发明利用RDMA verbs消息的数据传输高性能特性，客户端传递请求到服务器端的G-Cuckoo哈希数据管理模式。设计改进的哈希数据管理模式–G-Cuckoo，以桶–点映射bucket-vertex mapping方式构建Cuckoo图；在键值对***过程中，通过预测方式有效避免数据条目在哈希表间无限kick-out循环，缓解数据项在***时出现无限循环的问题，保证每一个数据请求尽可能在低延时和低代价的情况下完成。当接收到数据请求后，服务器端哈希数据管理模式完成数据操作，并把响应结果返回给客户端。构建RDMA通信模型，使用RDMA messaging verbs技术构建RDMA网络引擎，加速数据访问与结果传输。结合HTM技术和两段锁协议two-phase locking protocol(2PL)技术保证数据操作原子特性。基本数据操作可以获得实质上的延时减少，获得有意义的高吞吐量。遵循本发明所提的键值对数据管理方法，开发得到的键值对存储原型***可以不断地完善成熟，并成为可靠存储***，或单独地成为数据密集型计算***的存储组件。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
图1为本发明中一种基于RDMA和HTM的弹性Key-Value键值对数据存储方法流程图。
图2为本发明中一种基于RDMA和HTM的弹性Key-Value键值对数据存储原型***整体架构图。
图3为本发明中最大有向森林和非最大有向森林示意图。
图4为本发明中RDMA通信模型示意图。
具体实施方式
下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。
请参考图1-2，本发明的一种基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，包括如下步骤：
步骤1：遵循服务器端-客户端架构模式，利用硬件事务内存HTM和远程直接内存访问RDMA，构建大规模数据密集型计算的弹性Key-Value键值对数据存储管理***；
步骤2：在服务器端，键值对数据存储管理***使用桶-点bucket-vertex映射方式构建的哈希图，并给出改进型的G-Cuckoo哈希数据管理模式，避免在数据***过程中需要查找空闲的位置而导致的在哈希表之间无限循环kick-out踢数据条目的问题；
步骤3：通过自定义数据访问接口获取客户端的数据请求；
步骤4：在客户端与服务器端之间，分析传统网络来回round响应而引起的键值对存储性能瓶颈问题，使用Infiniband远程直接内存访问RDMA SEND/RECV verbs技术，设计RDMA网络通信引擎，接收数据访问请求和返回数据请求结果给客户端；
步骤5：利用硬件事务内存HTM，实现遵循加锁和释放锁协议的锁操作，形成数据操作HTM区域，保障基本数据操作的原子特性；
步骤6：使用键值对数据的自验证Checksum检验码以保证数据一致性。
在步骤1中，构建弹性Key-Value键值对数据存储管理***，具体如下：
键值对存储***整体部署在InfiniBand网络集群环境中，承担着数据存取和为上层数据分析型应用提供数据I/O请求服务的角色，客户端根据的改进型的Cuckoo哈希数据管理模式G-Cuckoo定位键值对数据存储位置，键值对存储***管理哈希表键值对数据，并利用two-sided RDMA SEND/RECV verbs技术开展消息通信；
所有数据都存放在服务器端的DRAM中，通过RDMA网络为客户端提供有效的数据服务；利用服务器的计算能力，采纳HTM感知的、RDMA友好的哈希表，每一个Key-Value键值对在两个哈希表中都有对应的存放位置和备份位置，用边连接这两个位置，边的起点对应于键值对的实际存放位置，而边的末尾对应于键值对的实际备份存放位置，哈希数据管理模式采纳两个静态的哈希函数h1(x)和h2(x)；当一个数据请求被发送到服务器端时，相关控制消息需要预先发送到服务器端；当接收到数据请求后，服务器端提供数据读写服务，将数据封装成有效载荷payload返回给客户端。
在步骤2中，G-Cuckoo哈希数据管理模式具体如下：
选择经典的Cuckoo哈希数据管理模式，并做相应改进，作为键值对存储***数据管理策略。其原因是，Cuckoo哈希数据管理模式是一种开放地址的数据管理方式，每个哈希表中的非空单元都包含有一个键或键值对。一个哈希函数可被用来决定每个键的实际位置，通过扫描哈希表各个位置发现空闲位置。查找过程需要检查哈希表的两个位置，这将花费一定时间。和其他哈希表算法进行对比，开展数据查找操作更加高效。对于Cuckoo哈希数据管理模式来说，数据删除操作也显得更加地简单。
经典的Cuckoo哈希数据管理模式：如果存在着d(d>0)个哈希表，令K为键值对的key键集合，哈希表T1和哈希表T2分别拥有n个数据项，给出两个独立函数h1,h2:K→{0,...,n-1}，key键k∈K可被***到哈希表T1的位置h1(k)或哈希表T2的位置h2(k)，Cuckoo哈希数据管理模式拥有基本数据操作方式；在开展键值对PUT操作时，服务器端需要计算键值对***的候选位置，key键在哈希表中拥有一个或两个位置，一旦想要***的候选位置已经被其他的键值对数据所占有，kick-out操作将会被执行，即键值对需要从一个哈希表踢到另外一个哈希表的空闲位置；
当***一个键值对数据条目时，传统的Cuckoo哈希数据管理模式采纳随机游走方法寻找空闲bucket位置，这导致***数据的无限循环和性能衰退问题；在经典Cuckoo哈希数据管理模式中，为了寻找空闲数据条目***位置，不断的kick-out操作问题可以被中断，并转向替换性的重新哈希操作，这样会出现时间延迟问题；事实上，中断kick-out操作并转向替换性的重哈希操作并不能很好地解决无限循环问题。
改进经典的Cuckoo哈希数据管理模式，在kick-out操作中融入无限循环预测功能，当d＝2时，Cuckoo哈希数据管理模式存在着两个表，每个***到哈希数据管理模式中的实际位置都有与之对应的备份位置，提供kick-out操作后的存储位置，表之间都存在着多条边，采用bucket-vertex映射方式，将哈希表的各个位置映射到哈希图中，提出改进型的Cuckoo哈希数据管理模式G-Cuckoo，预测避免无限kick-out来回踢问题。
在步骤3中，定义数据访问接口获取客户端的数据请求，具体如下：
提供用户可以使用的数据基本操作接口包括：数值设置函数rhkv_set、数值获取函数rhkv_get和数值更新函数rhkv_update。
在步骤4中，设计Infiniband RDMA网络通信引擎，具体如下：
数据消息通信操作Infiniband RDMA网络引擎采用two-sided隧道语义，用户空间程序通过使用RDMA verbs函数访问RDMA NICs，其中RDMA NICs基于硬件丢失包重传方式提供可靠传输，RDMANICs包含two-sided隧道语义和绕过目标CPU的one-sided内存语义，在RDMA NICs里维护消息队列queue，队列queue以两种形式存在：发送队列send queue和接收队列receive queue，称之为aqueue pair；当RHKV接收到数据操作请求，将通过RDMA网络引擎与改进的G-Cuckoo哈希数据管理模式开展数据交互，最终查找到相对应的键值对数据位置用于数据***或其他数据操作。而InfiniBand RoCE(RDMA over Converged Ethernet)能够提供低延时的数据操作功能。
数据的请求需要与哈希数据管理模式进行消息交互，包含基本的InfinibandServer和Infiniband Client。当执行读数据操作时，Inifiniband Client从哈希表的数列中查找key键，客户端获得哈希表对应于key键入口。具体的服务器端和客户端数据交互操作具体包括：
(1)服务器端Server注册回调操作柄callback handler，绑定并监听新到达的客户端以及操，当数据请求操作被执行后，连接将中断并对客户端连接监听的解绑操作；
(2)客户端Client设置host信息，RDMA通信组件给出构造器constructor和析构器destructor，分别用于初始化和释放Infiniband连接，定义函数connect用于添加connection数组，在Infiniband RDMA通信组件中，使用函数init、insert和free操作Infiniband连接数组，客户端发送的内容被存放在char vector数据结构中，并被封装为通信消息。
在步骤5中，遵循加锁和释放锁协议的锁操作，形成数据操作HTM区域，具体包括：
在开始Start阶段，HTM事务加锁和预取远程数据记录，通过运行XACQUIRE启动HTMtransaction；在局部事务LocalTX阶段，HTM事务对所有的局部记录提供事务级别的读和写；在提交Commit阶段，通过使用XRELEASE提交数据操作的HTM事务，数据记录更新后释放锁。
采用HTM技术保证数据基本操作的原子特性，具体如下：
数据密集计算应用程序可访问服务器端的哈希表，在数据并发请求的同时，存在着锁竞争和请求冲突的问题。为了保证数据操作的原子性，每个在哈希表的操作需要使用锁来保证访问Key-Value键值对数据记录的原子特性，不被其他数据请求所干扰。一旦数据被Inifiniband客户端所访问，它很有可能被修改到另外一个新值，在返回结果到客户端前，关于这段数据操作需要添加锁。如果数据操作的原子特性不能够被保证，这将导致并发数据请求的数据不一致性的问题。
数据操作主要是基于Cuckoo图的复杂操作进行的，而对于底层的操作来说是比较复杂的。对于一个数据操作来说，需要在一定的时间间隔内完成，此时，另外的数据操作请求可能已经到来。这样导致的结果是，新的操作请求同样会操作这个数据键值对条目。使用HTM感知的强原子性保障，在进入HTM保护区域前，获得相应的锁，在数据操作的执行过程中，每个基本数据请求将不会被其他的数据请求所干扰，防止出现数据不一致的问题。
保障计算节点的数据操作的强原子特性，并检测访问请求冲突。HTM是保障数据操作原子特性的有效方式，包括HLE(Hardware Lock Elision)技术。Intel的RTM(RestrictedTransactional Memory)是HLE技术的具体表现形式，RTM提供一系列诸如XBEGIN、XEND和XABORT的接口，它们分别表示开始、结束和中断事务。HLE技术易于集成到现有的x86软件，它能很好地兼容x86微处理器。这些微处理器具备Intel Haswell的事务同步扩展TSXIntel Transactional Synchronization Extension(TSX)功能，通过自动化方式执行load和store指令。方法使用Intel的RTM技术保障数据操作的原子特性。HLE有两个基本指令XACQUIRE和XRELEASE。其中，XACQUIRE指令主要用来获得锁，代表锁区域的开始。相对应地，XRELEASE指令主要用来释放锁，代表锁区域的结束。为了保障数据操作的原子性，定义加锁操作和解锁操作，包含函数ACQUIRE_LOCK()和函数RELEASE_LOCK()。这些函数包含基本指令XACQUIRE和XRELEASE。
在所述的步骤6中，利用数据一致性原理，保障数据的在客户端和服务器端之间的数据传输前后的一致性与正确性。具体如下：
当在哈希表上开展数据操作时，可能会引起键值对存储的数据操作会处于不一致的状态，而引起不一致状态的场景包括：(1)初始化哈希表；(2)触发重哈希操作；(3)***或更新键值对条目；(4)InfiniBand RDMA通信；以及(5)删除已存在的key键，等等。键值对数值的变化可通过回调函数通知客户端。具体地，在给定的时间内，如果Infiniband服务器端查找到一个值已经变化到一个新值时，它返回成功信号给Infiniband客户端；否则，它返回错误信号给Infiniband客户端。对于数据恢复，数据存储策略可以使用append操作保证key键的多版本数值特性，其中的一个数值被标记为活跃状态。
为了保证消息服务器端和客户端间消息通信的准确性，具体的键值对数据的自验证Checksum过程如下：
(1)首先计算key键值的实际哈希值；
(2)从哈希表中查询想要获得的数值；
(3)获得键值对的内容计算Checksum值；
(4)比较内容与存储在哈希表中bucket的Checksum值是否一样。
G-Cuckoo哈希数据管理模式的详细设计结合Cuckoo图构建。具体如下：
定义(Cuckoo图).两个哈希表之间的位置构成有向图G＝(V,E)，其中，V和E是顶点和边的集合。图中的每个顶点都有唯一标识号，顶点集合可被划分为多个子图集合。
定义(Cuckoo子图).G的一个子图可以表示为Pi＝(Vi,Ei)，其中，
Ei＝{(vi,vj)∈E|vi∈Vi}。需要注意的是，Ei包含所有顶点集合Vi的出边，它有可能在子图间跨越。所有的子图分布在两个哈希表之间；同时，每个顶点应当都隶属于一个子图，本发明将映射表示为φp:它记录顶点集合属于哪一个子图。
图3为本发明中最大有向森林和非最大有向森林示意图。
定义(最大有向森林和非最大有向森林).一个最大有向森林是一个有向图，每个顶点都有唯一一个与之对应的出度。非最大有向森林可被转化为一个最大有向森林，通过用边连接图中出度为0的顶点与图中的任意一个其他顶点。
桶—节点映射(Bucket-vertex mapping).从上述几个定义得到启发，使用桶—节点映射构建两个哈希表间的Cuckoo图。将Cuckoo图表示为有向森林，森林中的每个顶点都对应与哈希表中的bucket桶(位置)，每条边都位于每个键值对的位置之间。这个图包含若干条有向边，在图中开展kick-out操作，寻找空闲位置并***键值对。
最大子图不能添加一条新边，因为无限循环问题很容易出现。新边可以添加到一个非最大子图，非最大子图不存在无限循环问题。出度为零的顶点代表有向森林中空的位置(bucket)。更新或删除哈希表中键值对是十分容易的。然而，当***一个键值对时，两个候选位置通常被两个数据item所占有，在子图中不存在空的位置，键值对数据不可以直接***。
成功的键值对***操作通常依赖于是否查找到空闲位置用于数据存储。一个键值对的候选位置所对应的顶点应当隶属于一个子图，这个子图需要包含出度为零的顶点，对应于哈希表中的空闲位置。为了提升服务器端的I/O吞吐量，对于键值对数值的***操作来说，查找一个空的位置，并预测无限循环kick-out操作。
寻找空闲位置并***键值对数据，具体的过程如下：
键值对存储被***到G-Cuckoo哈希数据管理模式时，需要发现空闲位置。至少存在一个空闲候选位置位于非最大子图中，在有向森林中，出度为零的顶点代表着一个空闲bucket位置，它位于非最大子图的最大有向路径上。当数据条目被***到非最大子图中，需要被存储到空闲bucket位置中，空闲bucket位置对应于有向Cuckoo路径的最后一个顶点。
基于已经构建完成的Cuckoo图，顶点数据项的***将导致顶点数量的增长变化，可以表示为count(v)+i,(i＝2,1,0)，如下：
·Case A:count(v)+2。假设一个键值对的两个候选位置都没有对应于所构造的Cuckoo图(有向森林)，键值对数据的***将形成新子图，它是一个非最大有向子图。易知，新数据条目将会成功地***，子图顶点数量增加2，边数量增加1。
·Case B:count(v)+1。一个候选位置对应于Cuckoo子图中现存的顶点，另外一个候选位置并没有对应于Cuckoo子图的顶点。在这种情况下，键值对将被成功地***，顶点的数量增加1，边的数量同样增加1。在有向森林子图中，这条新边连接新添加的顶点和已存在的顶点。
·Case C:count(v)+0。当***一个键值对时，并没有增加Cuckoo图顶点的数量。***键值对后，情况会比较复杂，会出现三种不同的情况，具体如下：
(1)当两个候选位置都位于同一个非最大有向子图，或两个不同的非最大有向子图中时，哈希表中的bucket都有可能成为***键值对的候选位置，kick-out操作将会被开展。原先的非最大子图有可能会被转化为最大子图。
(2)当其中一个候选位置位于非最大有向子图，而另外一个位于最大有向子图时，数据条目将会被***到非最大子图。两个子图可能会被合并。如果被***到最大子图中时，将会导致无限kick-out操作问题。
(3)当所有的候选位置都位于同一个最大子图中，或者分离地位于两个最大有向子图中时，***结果将会失败，会出现无限kick-out循环问题。
具备预测无限kick-out循环是否存在的过程，具体如下：
在G-Cuckoo数据哈希管理模式中，预先知道数据操作后将产生权利要求9的哪一种Case结果。当数据***后，遇到的顶点数量增量结果是count(v)+0，数据的***将不会导致无限环的问题。子图的边数量增加量为1，节点数量不会增加。当至少一个子图是非最大时，数据***操作成功。
在键值对***过程中，本发明需要判定数值***是否会引起无限的kick-out循环问题。想要知道数据***后出现的结果，需要定时地判定每一个子图状态情况，是否是最大子图还是非最大子图。
具体地，本发明的技术方案重点在于：
(1)遵循服务器端—客户端架构模式构建弹性Key-Value键值对数据存储方法
***可以整体部署在InfiniBand高性能网络集群环境中，承担数据存取和为上层数据分析型应用提供I/O请求服务的角色，***包含客户端和服务器端。具体地，客户端根据本发明所设计的改进型的Cuckoo哈希数据管理模式–G-Cuckoo(结合Cuckoo图)定位键值对数据存储的位置。***有效地管理哈希表中的键值对数据，并利用two-sided RDMASEND/RECV verbs技术开展消息通信。所开发的键值对存储原型***可以不断地被完善，成为可靠的存储***，或单独地成为数据密集型计算***的存储组件。
(2)改进型的G-Cuckoo哈希数据管理模式
当***一个键值对数据条目时，传统的Cuckoo哈希数据管理模式采纳随机游走方法寻找空闲的bucket位置，这将导致在数据***哈希表时出现无限循环和性能衰退问题。需要指出的是，在经典的Cuckoo数据管理模式中，为了寻找空闲的数据条目***位置，不断的kick-out操作问题可以被中断，并转向替换性的重新哈希操作，但是会在开展大量的kick-out操作的过程中出现时间延迟较大的问题。中断kick-out操作并转向替换性的重哈希操作，并不能很好地解决无限循环问题。为了获取更好的Cuckoo哈希数据管理模式，检测无限环问题。改进经典的Cuckoo哈希数据管理模式，在kick-out操作中融入无限循环预测。通过bucket-vertex映射方式，将哈希表中的各个位置映射到哈希图中，提出改进型的Cuckoo哈希数据管理模式——G-Cuckoo，预测避免无限kick-out来回踢问题。
(3)基于RDMA构建RDMA网络通信引擎
直接利用RDMA READs技术开展数据读写并开展复杂指针操作是十分困难的。在客户端与服务器端之间，分析传统网络来回round响应而引起的键值对存储性能瓶颈问题，使用Infiniband远程直接内存访问RDMA(Remote Direct Memory Access)SEND/RECV verbs技术，设计网络通信引擎，接收数据访问请求和送回数据请求结果。InfiniBand RoCE(RDMAover Converged Ethernet)能够低延时地开展数据操作。RDMANICs基于硬件丢失包重传提供可靠传输。实际上，RDMA-capable NICs包含two-sided隧道语义和目标CPU绕过的one-sided内存语义。在所提的键值对数据管理方法中，用于数据消息通信的Infiniband RDMA网络引擎是采用two-sided隧道语义的。
(4)基于HTM的数据操作原子特性
由于键值对数据存储方法是基于改进型的G-Cuckoo哈希数据管理模式的，数据操作将会关联到内部底层的数据操作。对于一个简单的基本数据操作而言，内部的数据结构的改变相对来说是复杂的，如果没有数据操作的原子特性保障，在并发数据操作的情况下，数据读写将会造成死锁或一定程度的错乱，进而导致整体数据存取程序的中断和数据的不正确性。数据密集计算应用程序可以访问服务器端的哈希表，在数据并发请求的情况下，存在着锁竞争和请求冲突的问题。为了保证数据操作的原子性，每个哈希表的操作需要使用锁，保证访问Key-Value键值对数据记录的原子特性，并数据操作不被其他请求所干扰。
(5)数据一致性保障技术
本发明所提的键值对存储方法使用Checksum数据一致性保障技术保障数据的一致性，从一定程度上保证数据在服务器端和客户端之间的传输不会发生错误。同时，数据一致性保障技术是轻量级的，相对于其他负担较重的数据一致性保障技术来说，显得更加简单，无需太多硬件资源参与。在保证数据存取性能良好的情况下保证数据的一致性和正确性。
本发明的一个具体实施例如下：
基于RDMA和HTM的弹性Key-Value键值对存储***关键实现和软件接口包括：
(1)软件接口抽象，***提供基本操作接口给用户使用，这些接口包括数值设置函数rhkv_set、数值获取函数rhkv_get和数值更新函数rhkv_update，等等。
软件接口提供的底层细节描述如下：对于函数rhkv_get来说，key键参数m通过Infiniband网络传递到哈希函数Hash。抽象函数通过掩码操作计算两个候选位置，并找到哈希表的实际值情况，并返回最后结果。对于函数rhkv_set来说，实际过程可能更为复杂。具体地，函数首先在缓存stash中找到key值条目。如果条目存在，更新键值对条目；否则，它将在哈希表中找到实际位置，使用哈希函数Hash计算哈希表的实际哈希位置。另外，将同步地更新构造的Cuckoo图。对于函数rhkv_update来说，和set操作一样，获得哈希表或缓存stash中的实际位置，更新旧数值为新数值。
(2)Infiniband通信模块设计.在Infiniband配置组件中定义不同的层级，包括网络层network layer、传输层transport layer、加密层crypto layer、应用层applicationlayer，并定义对应的的setter和getter方法。在通信模块中定义函数setHostName、setPort、getHostname和getPort，分别为设置主机名函数、设置端口号函数、获取主机名称函数和获取端口号函数。
更多地，函数server_on_completion将receive-state的状态修改为MSG_RECEIVED。当服务器接收到RDMA-read请求时，此函数使用动态buffer，并传递参数到SERVERuser，用户平滑地接收数据信息。当消息被处理后，函数重新设置ib_connection。另外，在函数client_on_completion中，如果send-state设置为MSG_SENT状态，receive-status设置为INIT状态，这意味着客户端接收从服务器段发来的请求，服务器端信息包含RDMA详细信息。当客户端读取数据后，send-state的状态变化到REDMA_READ_DONE。图4为本发明中RDMA通信模型示意图。
(3)哈希数据管理模块设计.在哈希数据管理模块中，定义Node数据结构，包含变量appVar、变量occuVar和变量subVar。其中，变量appVar用于判断子图是非最大子图还是最大子图；变量occuVar表示图中顶点是否被占用；变量subVar表示顶点位于所在子图的标识号。
为了有效地管理哈希表，检测在键值***过程中是否存在无限kick-out的问题，定义一些主要函数，使用函数search和函数update，实现在哈希表上的数据操作。在函数insert实现过程中，需要调用函数judgeNum判定子图是非最大子图还是最大子图。另外，设计数据结构UnionSet开展子图合并操作。设计cache数据结构存储一部分已经被访问过的数据。将整体数据操作阶段分为以下几个部分：(1)检查、加载和更新cache数据结构；(2)服务器端响应；(3)客户端等待；(4)结果返回。
开展有效的实验评估原型***的性能，实验评测可以使用服从Zipfian和Uniform分布的YCSB负载开展实验性能评测。实验评测在InfiniBand(FDRinterconnects)环境中开展，并且与键值对存储***性能开展真实性能对比。
本发明的应用场景举例如下：
S4、Spark等分布式并行计算***不断出现，与之相关的基于磁盘的存储***(例如，HDFS或基于云的NoSQL存储***)的I/O交互仍然是一个主要的性能瓶颈。***将数据从HDFS预取到实际程序计算，为上层应用I/O请求提供相应的数据服务，架设起MapReduce栈的I/O鸿沟。更多地，对于实际的商业价值而言，随着互联网用户数量的不断增长，因特网广告业务不断快速发展，实时广告投标***也不断地呈现。为了更好地满足服务质量，用户可以使用本发明的方法与***存储广告数据，并提高广告数据访问的实际速率。
以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。
Claims (7)
1.一种基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，包括如下步骤：
步骤1：遵循服务器端-客户端架构模式，利用硬件事务内存HTM和远程直接内存访问RDMA，构建大规模数据密集型计算的弹性Key-Value键值对数据存储管理***；
步骤2：在服务器端，键值对数据存储管理***使用桶-点bucket-vertex映射方式构建哈希图，并给出改进型的G-Cuckoo哈希数据管理模式，避免在数据***过程中需要查找空闲的位置而导致的在哈希表之间无限循环kick-out踢数据条目的问题；
步骤3：通过自定义数据访问接口获取客户端的数据请求；
步骤4：在客户端与服务器端之间，分析传统网络来回round响应而引起的键值对存储性能瓶颈问题，使用Infiniband远程直接内存访问RDMA SEND/RECV verbs技术，设计RDMA网络通信引擎，接收数据访问请求和返回数据请求结果给客户端；
步骤5：利用硬件事务内存HTM，实现遵循加锁和释放锁协议的锁操作，形成数据操作HTM区域，保障基本数据操作的原子特性；
步骤6：使用键值对数据的自验证Checksum检验码以保证数据一致性；
在所述的步骤2中，G-Cuckoo哈希数据管理模式具体如下：
选择经典的Cuckoo哈希数据管理模式，并做相应改进，作为键值对存储***数据管理策略，其中经典的Cuckoo哈希数据管理模式：如果存在着d(d>0)个哈希表，令K为键值对的key键集合，哈希表T1和哈希表T2分别拥有n个数据项，给出两个独立函数h1,h2:K→{0,...,n-1}，key键k∈K可被***到哈希表T1的位置h1(k)或哈希表T2的位置h2(k)，Cuckoo哈希数据管理模式拥有基本数据操作方式；在开展键值对PUT操作时，服务器端需要计算键值对***的候选位置，key键在哈希表中拥有一个或两个位置，一旦想要***的候选位置已经被其他的键值对数据所占有，kick-out操作将会被执行，即键值对需要从一个哈希表踢到另外一个哈希表的空闲位置；
当***一个键值对数据条目时，传统的Cuckoo哈希数据管理模式采纳随机游走方法寻找空闲bucket位置，这导致***数据的无限循环和性能衰退问题；在经典Cuckoo哈希数据管理模式中，为了寻找空闲数据条目***位置，不断的kick-out操作问题可以被中断，并转向替换性的重新哈希操作，这样会出现时间延迟问题；
改进经典的Cuckoo哈希数据管理模式，在kick-out操作中融入无限循环预测功能，当d＝2时，Cuckoo哈希数据管理模式存在着两个表，每个***到哈希数据管理模式中的实际位置都有与之对应的备份位置，提供kick-out操作后的存储位置，表之间都存在着多条边，采用bucket-vertex映射方式将哈希表的各个位置映射到哈希图中，提出改进型的Cuckoo哈希数据管理模式G-Cuckoo，预测避免无限kick-out来回踢问题。
2.根据权利要求1所述的基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，在所述的步骤1中，构建弹性Key-Value键值对数据存储管理***，具体如下：
键值对存储***整体部署在InfiniBand网络集群环境中，承担着数据存取和为上层数据分析型应用提供数据I/O请求服务的角色，客户端根据改进型的Cuckoo哈希数据管理模式G-Cuckoo定位键值对数据存储位置，键值对存储***管理哈希表键值对数据，并利用two-sided RDMA SEND/RECV verbs技术开展消息通信；
所有数据都存放在服务器端的DRAM中，通过RDMA网络为客户端提供有效的数据服务；利用服务器的计算能力，采纳HTM感知的、RDMA友好的哈希表，每一个Key-Value键值对在两个哈希表中都有对应的存放位置和备份位置，用边连接这两个位置，边的起点对应于键值对的实际存放位置，而边的末尾对应于键值对的实际备份存放位置，哈希数据管理模式采纳两个静态的哈希函数h1(x)和h2(x)；当一个数据请求被发送到服务器端时，相关控制消息需要预先发送到服务器端；当接收到数据请求后，服务器端提供数据读写服务，将数据封装成有效载荷payload返回给客户端。
3.根据权利要求1所述的基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，在所述的步骤3中，定义数据访问接口获取客户端的数据请求，具体如下：
提供用户使用的基本操作接口，这些接口包括数值设置函数rhkv_set、数值获取函数rhkv_get和数值更新函数rhkv_update。
4.根据权利要求1所述的基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，在所述的步骤4中，设计Infiniband RDMA网络通信引擎，具体如下：
数据消息通信操作Infiniband RDMA网络引擎采用two-sided隧道语义，用户空间程序通过使用RDMA verbs函数访问RDMA NICs，其中RDMA NICs基于硬件丢失包重传方式提供可靠传输，RDMANICs包含two-sided隧道语义和绕过目标CPU的one-sided内存语义，在RDMANICs里维护消息队列queue，队列queue以两种形式存在：发送队列send queue和接收队列receive queue，称之为aqueue pair；当RHKV接收到数据操作请求，将通过RDMA网络引擎与改进的G-Cuckoo哈希数据管理模式开展数据交互，最终查找到相对应的键值对数据位置用于数据***或其他数据操作。
5.根据权利要求1所述的基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，在步骤5中，遵循加锁和释放锁协议的锁操作，形成数据操作HTM区域，具体包括：
在开始Start阶段，HTM事务加锁和预取远程数据记录，通过运行XACQUIRE启动HTMtransaction；在局部事务LocalTX阶段，HTM事务对所有的局部记录提供事务级别的读和写；在提交Commit阶段，通过使用XRELEASE提交数据操作的HTM事务，数据记录更新后释放锁。
6.根据权利要求1所述的基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，在所述的步骤6中，键值对数据的自验证Checksum过程如下：
(1)首先计算key键值的实际哈希值；
(2)从哈希表中查询想要获得的数值；
(3)获得键值对的内容计算Checksum值；
(4)比较内容与存储在哈希表中bucket的Checksum值是否一样。
7.根据权利要求4所述的基于RDMA和HTM的弹性Key-Value键值对数据存储方法，其特征在于，数据的请求需要与哈希数据管理模式进行消息交互，具体包括：
(1)服务器端Server注册回调操作柄callback handler，绑定并监听新到达的客户端操作请求，当数据请求操作被执行后，连接将中断并对客户端连接监听的解绑操作；
(2)客户端Client设置host信息，RDMA通信组件给出构造器constructor和析构器destructor，分别用于初始化和释放Infiniband连接，定义函数connect用于添加connection数组；在Infiniband RDMA通信组件中，使用函数init、insert和free操作Infiniband连接数组，客户端发送的内容被存放在char vector数据结构中，并被封装为通信消息。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810070442.1A CN110069431B (zh) | 2018-01-24 | 2018-01-24 | 基于RDMA和HTM的弹性Key-Value键值对数据存储方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810070442.1A CN110069431B (zh) | 2018-01-24 | 2018-01-24 | 基于RDMA和HTM的弹性Key-Value键值对数据存储方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110069431A CN110069431A (zh) | 2019-07-30 |
| CN110069431B true CN110069431B (zh) | 2020-11-24 |
Family
ID=67365734
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810070442.1A Expired - Fee Related CN110069431B (zh) | 2018-01-24 | 2018-01-24 | 基于RDMA和HTM的弹性Key-Value键值对数据存储方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110069431B (zh) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110727612B (zh) * | 2019-09-09 | 2021-01-15 | 无锡江南计算技术研究所 | 一种基于精确预取的计算缓存装置 |
| CN111400306B (zh) * | 2020-02-20 | 2023-03-28 | 上海交通大学 | 基于rdma与非易失性内存的基数树访问*** |
| CN111404931B (zh) * | 2020-03-13 | 2021-03-30 | 清华大学 | 一种基于持久性内存的远程数据传输方法 |
| CN112612803B (zh) * | 2020-12-22 | 2022-07-12 | 浙江大学 | 基于持久性内存的键值对存储***及数据并发***方法 |
| CN113326033B (zh) * | 2021-06-09 | 2023-08-11 | 北京八分量信息科技有限公司 | 一种带有多种语言API的key-value存储*** |
| CN117573602B (zh) * | 2024-01-16 | 2024-05-14 | 珠海星云智联科技有限公司 | 用于远程直接内存访问报文发送的方法及计算机设备 |
| CN117812039B (zh) * | 2024-02-24 | 2024-05-14 | 深圳赋乐科技集团有限公司 | 一种网络地址转换日志记录方法、***、设备及介质 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105404546A (zh) * | 2015-11-10 | 2016-03-16 | 上海交通大学 | 基于rdma和htm的分布式并发控制方法 |
| CN105938446A (zh) * | 2016-01-12 | 2016-09-14 | 上海交通大学 | 基于rdma和htm支持的数据复制容错方法 |
-
2018
- 2018-01-24 CN CN201810070442.1A patent/CN110069431B/zh not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105404546A (zh) * | 2015-11-10 | 2016-03-16 | 上海交通大学 | 基于rdma和htm的分布式并发控制方法 |
| CN105938446A (zh) * | 2016-01-12 | 2016-09-14 | 上海交通大学 | 基于rdma和htm支持的数据复制容错方法 |
Non-Patent Citations (2)
| Title |
|---|
| "Fast and General Distributed Transactions using RDMA and HTM";Yanzhe Chen etc.;《EuroSys’16》;20160421;第1-7页 * |
| "Key-Value Memory Networks for Directly Reading Documents";Alexander H. Miller etc.;《Proceedings of the 2016 Conference on Empirical Methods in Natural Language Processing》;20161105;第1400-1409页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110069431A (zh) | 2019-07-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110069431B (zh) | 基于RDMA和HTM的弹性Key-Value键值对数据存储方法 | |
| US10990590B2 (en) | Aggregation framework system architecture and method | |
| US10176057B2 (en) | Multi-lock caches | |
| US10803066B2 (en) | Methods and systems for hardware acceleration of database operations and queries for a versioned database based on multiple hardware accelerators | |
| US8165988B2 (en) | Fast batch loading and incremental loading of data into a database | |
| CN108431774B (zh) | 无限存储器结构流和api | |
| US9652287B2 (en) | Using databases for both transactions and analysis | |
| US20160246861A1 (en) | Aggregation framework system architecture and method | |
| US20160179865A1 (en) | Method and system for concurrency control in log-structured merge data stores | |
| CN113282236A (zh) | 对象存储器结构及其基于硬件的处理节点及方法 | |
| US9229869B1 (en) | Multi-lock caches | |
| CN108885607A (zh) | 使用容错对象的存储器结构操作和一致性 | |
| CN111159252A (zh) | 事务执行方法、装置、计算机设备及存储介质 | |
| US11048669B2 (en) | Replicated state management using journal-based registers | |
| Xia et al. | Graph analytics and storage | |
| Bhatotia | Incremental parallel and distributed systems | |
| US20230367815A1 (en) | Energy-efficient hardware-software collaborative method and apparatus for graph processing | |
| Wu et al. | RHKV: An RDMA and HTM friendly key–value store for data-intensive computing | |
| CN114756509B (zh) | 文件***的操作方法、***、设备以及存储介质 | |
| US20240143594A1 (en) | Offloading graph components to persistent storage for reducing resident memory in distributed graph processing | |
| Kunkel | Performance Analysis of the PVFS2 Persistency Layer | |
| Krause | Graph Pattern Matching on Symmetric Multiprocessor Systems | |
| Bikonda | Retina: Cross-Layered Key-Value Store using Computational Storage | |
| Baumstark et al. | So Far and yet so Near-Accelerating Distributed Joins with CXL | |
| Zadok et al. | Storage |
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 | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20201124 |