CN114365109A - 启用rdma的键-值存储库 - Google Patents
启用rdma的键-值存储库 Download PDFInfo
- Publication number
- CN114365109A CN114365109A CN202080059883.7A CN202080059883A CN114365109A CN 114365109 A CN114365109 A CN 114365109A CN 202080059883 A CN202080059883 A CN 202080059883A CN 114365109 A CN114365109 A CN 114365109A
- Authority
- CN
- China
- Prior art keywords
- key
- hash table
- entry
- value
- client
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
- G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
- G06F15/17306—Intercommunication techniques
- G06F15/17331—Distributed shared memory [DSM], e.g. remote direct memory access [RDMA]
-
- 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
-
- 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/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Computer Hardware Design (AREA)
- Mathematical Physics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
根据一个或多个实施例,允许在冲突补救所需的动作期间继续查找、***和删除操作。当使用重定位操作来解决冲突时,在存储键‑值对的散列表条目的头部部分中编码的信息指示相关联的键‑值对何时进行重定位。通过允许访问RKVS的其它过程无故障地处置重定位,这个信息促进在重定位过程期间继续访问RKVS。此外,当需要散列表扩展以便解决冲突时,分配第二个更大的散列表,并继续对旧散列表和新散列表两者进行查找操作。一个或多个实施例还使用标志在RKVS中防止***、查找和删除失败,这些标志编码在散列表条目的头部信息中,其反映存储库中相应键‑值对的状态。
Description
技术领域
本发明涉及键-值存储库的管理,并且更具体而言涉及在冲突补救期间提高启用远程直接存储器访问(RDMA)的键-值存储库的可用性,并减少存储库内由多个过程并发执行的操作的失败。
背景技术
键-值存储在许多应用中,诸如在设计可扩展的行业数据管理中,都是必不可少的。键-值存储库的性能在实现高速数据处理中起着重要作用。已经开发了无数技术来提高向客户端应用递送客户端应用从键-值存储库请求的数据的效率。此类技术通常涉及在服务器设备上执行接收请求、从键-值存储库搜集所请求的数据并将数据提供给数据库应用的数据库服务器实例。众多客户端应用将频繁地将请求发送到同一个数据库服务器实例。数据库服务器实例中的工作负载越大,数据库服务器实例将能够高效响应所有请求的可能性就越小。
遗憾的是,如果在服务器设备上执行的数据库服务器实例发生故障,那么服务器设备的易失性存储器中的数据通常对客户端应用变得不可用。在这些情形下,客户端应用等待数据库服务器实例被恢复,或者在可能的情况下,从其它源(例如,通过向可以访问期望数据的另一个副本的另一个数据库服务器实例发送请求)获得它们需要的数据。
可替代地,客户端应用可以使用远程直接存储器访问(RDMA)请求从正在执行数据库服务器实例的服务器机器的易失性存储器中检索由数据库服务器实例管理的数据。这种技术允许客户端从主机服务器机器的易失性存储器中检索数据,而不在检索操作中涉及数据库服务器实例。
由客户端机器或客户端发出的RDMA请求是单方面的操作并且不要求主机服务器机器(RDBMS服务器)上的CPU中断或OS内核参与。即,RDMA读取和写入是在没有远程数据库服务器实例的任何参与的情况下执行的。例如,InfiniBand是一种广泛用于高性能计算***的交换架构网络。聚合以太网上RDMA(RDMA over Converged Ethernet,RoCE)是一种网络协议,其允许通过以太网的直接存储器访问。InfiniBand和RoCE网络接口卡旨在通过除了在硬件中实现若干层的网络堆栈之外还提供RDMA和内核绕过来实现低时延。
RDMA启用零副本传送并显著减少时延和CPU开销。它允许一个过程直接访问远程设备的存储器,而不涉及设备上运行的任何过程。因此,因为数据检索不涉及数据库服务器实例,所以即使在数据库服务器实例(或主机服务器机器本身)已经停止或变得无响应时,检索也可以成功。
与传统的消息传递方法相比,RDMA实现了最低的往返时延、最高的吞吐量和零CPU开销。已经进行了研究以探索RDMA的实施以提高存储器内数据存储库的性能。为此目的,已经提出各种方法来维护利用RDMA实现高吞吐量和低CPU开销的键-值存储库。但是,大多数设计不支持在键-值存储库上并行执行RDMA读取和写入操作的多个过程。一般而言,此类***使用单侧RDMA读取来访问数据并将写入操作留给管理数据的服务器实例,这在越来越多的过程访问数据时阻止适当的扩展。
FaRM是一种通用分布式计算平台,它将机器的集群的存储器暴露为共享地址空间。FaRM使用Hopscotch散列的变体为其键-值存储库设计创建位置感知散列表。对于GET操作,客户端读取若干连续的Hopscotch条目,其中一个条目以高概率包含期望的键。对于PUT操作,客户端将其请求写入服务器实例可访问的易失性存储器中的循环缓冲区。服务器实例轮询这个缓冲区以检测新的写入请求。因此,FaRM的PUT操作设计防止多个过程直接在键-值存储库中执行RDMA写入操作。
Pilaf是旨在实现高性能和低CPU使用率的另一种键-值存储库设计。对于GET操作,客户端使用RDMA读取操作访问存储在服务器实例可访问的存储器中的基于布谷鸟(cuckoo)的散列表。但是,对于PUT操作,客户端使用SEND消息将其写入请求发送到服务器实例。与FaRM一样,Pilaf通过将写入请求发送到服务器实例来提供多个PUT操作。Pilaf不支持多个进程直接在键-值存储库中执行RDMA写入操作。
HERD是一种被设计为优化RDMA网络的使用的键-值***。它采用混合方法,同时使用RDMA请求和消息传递。在HERD中,客户端通过不可靠连接(UC)使用RDMA写入请求将其请求发送到服务器实例。这些写入操作将PUT和/或GET请求放入服务器实例可访问的每个客户端的存储器区域中。服务器实例轮询这些存储器区域以获取新请求。在检测到新请求后,服务器实例使用其本地数据结构以常规方式执行请求。然后,服务器实例使用通过不可靠数据报的SEND消息向客户端发送回复。与FaRM和Pilaf一样,HERD还经由向服务器实例发送请求的过程提供多个PUT操作。但是,HERD不支持多个过程直接向键-值存储库执行写入操作。
Nessie是一种键-值***,其包括支持多个过程直接在键-值存储库中执行RDMA读取和写入操作的散列表设计。在Nessie***中,索引散列表将每个键映射到其中存储对应键-值对的辅助数据表中的一个或多个位置。键基于一个或多个散列函数映射到索引散列表中的条目。数据表的条目还包括有效标志,其指示对应的条目是否属于正在进行的PUT操作。
每个客户端都被赋予对数据表中数据项的集合的所有权,并且客户端只能更新该客户端拥有的数据项。对于数据表的每个操作的高级别结构包括:读取索引表中针对指定的键的主索引和辅助索引,以识别键-值对在数据表中的位置;对数据表中已识别出的位置处的适当项执行操作;检查为键-值对列出的位置还没有被另一个客户端修改,即,经由索引表的条目的修改;以及在数据表中的任何新数据项上设置有效位。但是,Nessie的设计有几个弱点,包括潜在的***失败问题、冲突解决期间的掉电问题和查找失败问题。
Nessie***在冲突解决期间可能会出现掉电故障。具体而言,如果键-值对(Keyx,VALx)的写入操作因为索引散列表中的主条目和辅助条目都填充了用于不同键-值对的位置数据而失败,那么执行重定位操作以清空索引散列表中的条目以允许写入操作的完成。作为重定位的候选的第一个键-值对是用于Keyx的主条目中的数据。如果重定位操作因为用于重定位候选的替代条目被填充而失败,那么进行第二次重定位操作以重定位辅助条目中的数据项。未能清空辅助条目导致消息被发送到服务器实例,然后服务器实例撤销对其本地存储器的访问并在允许客户端继续进行之前执行一连串迁移或表尺寸调整。在这种设计中,服务器实例阻止客户端在冲突解决完成之前在键-值存储库中执行任何读取或写入操作,这可能导致不必要的掉电,在此期间键-值存储库对客户端不可用。
Nessie***还有***失败的可能性。例如,在Nessie***中,对于客户端将值写入键-值存储库的操作,客户端首先将数据写入客户端拥有的辅助数据表中的空闲条目。这个数据条目包括将数据标记为无效的标志。一旦辅助数据表中条目的位置被记录在索引表中,写入操作就完成了并且用于***的键-值对的标志被更新为指示数据现在是有效的。但是,Nessie***中的***可能失败,诸如当两个过程A和B尝试同时将相同的键-值对(Keyx,VALx)***键-值存储库并且第三个过程C尝试在它被***之后删除(Keyx,VALx)时。只有过程A和B中的一个应当成功***键-值对,然后***的键-值对应当被过程C删除,从而导致从键-值存储库中移除(Keyx,VALx)。但是,基于***键-值对的过程之一不期望地延迟到过程C将键-值对从存储库中删除之后,可能发生***失败,这将导致(Keyx,VALx)在数据应当被过程C删除之后仍保留在键-值存储库中。
Nessie***还有查找失败的可能性。在这种设计中,为了对特定键执行读取操作,客户端首先读取存储在索引散列表中键的主条目中的位置数据。因为布谷鸟散列对每个键使用多个潜在索引,因此映射到所请求的键的条目处的位置数据可能用于与所请求的键不同的键。因此,当读取索引散列表中的条目时,客户端核实与位置数据相关联的存储的键是否与请求的键匹配。如果键匹配,那么从数据表中的指定位置将对应的值返回给客户端。否则,检查索引散列表中的辅助条目。而且,如果主条目为空,那么检查键的辅助条目。如果辅助条目不为空并且与所请求的键相关联,那么客户端继续读取存储在辅助数据表中指定位置处的值。
这种设计中的查找可能失败,因为未考虑读取索引散列表中的位置信息与读取数据表内该位置处的数据之间的延迟。具体而言,客户端读取给定条目的位置与读取存储在该指示位置处的数据之间可能存在延迟。在这个延迟期间,存储在辅助数据表内指示位置处的数据可能被另一个过程修改或移动到辅助数据表中的另一个位置。在这种情况下,客户端可能返回与所请求的键不关联的值。
因此,支持多个过程直接在键-值存储库中执行RDMA读取和写入操作而不会出现查找失败、掉电失败和/或***失败的可能性将是有益的。
本节中描述的方法是可以采用的方法,但不一定是先前已经设想或采用的方法。因此,除非另有指示,否则不应当仅由于将本节中描述的任何方法包括在本节中而将其假设为现有技术。另外,不应当仅由于将本节中描述的任何方法包括在本节中而假设本节中描述的任何方法都是易于理解的、例行的或常规的。
附图说明
在附图中:
图1是***的框图,该***被配置为使一个或多个客户端能够远程访问由执行数据库服务器实例的服务器机器的易失性存储器内的数据库服务器实例管理的键-值存储库。
图2描绘了用于在键-值对操作的第一子操作期间从散列表条目检索头部信息并基于头部信息中一个或多个设定的标志中止键-值对操作的第二子操作的流程图。
图3描绘了示例散列表条目配置以及示例散列表内容。
图4-图7描绘了实现键-值存储库的散列表的快照的相应时间序列。
图8描绘了实现键-值存储库的第二散列表,以用于与冲突解决相关的键-值迁移的目的。
图9描绘了用于将键-值存储库的至少一部分从易失性存储器中的第一散列表迁移到易失性存储器中的第二散列表的流程图。
图10是可以在其上实现实施例的计算机***的框图。
图11描绘了可以在实施例中使用的软件***。
具体实施方式
在下面的描述中,出于解释的目的,阐述了许多具体细节以便提供对本发明的透彻理解。但是,将明显的是,可以在没有这些具体细节的情况下实践本发明。在其它情况下,以框图形式示出了众所周知的结构和设备,以避免不必要地使本发明模糊。
总体概述
根据一个或多个实施例,可能来自多个过程的远程直接存储器访问(RDMA)请求和本地请求能够在启用RDMA的键-值存储库(RKVS)上使用。因此,RKVS为本地和远程读取和写入操作提供无锁多过程操作,而无需客户端参与管理RKVS的过程。照此,实施例允许完全并行的散列表***、查找和删除操作。
实施例消除了在冲突解决期间限制对RKVS的访问的需要。具体而言,根据一个或多个实施例,允许在冲突补救所需的动作期间继续查找、***和删除操作。冲突补救动作包括重定位键-值对以便为***腾出空间和/或扩展存储RKVS的散列表的尺寸。冲突补救期间RKVS可用性的增加允许要求高可用性和性能的数据库继续运行,而不会出现对键-值存储库性能产生负面影响的掉电状况。
当重定位操作被用于解决冲突时,在存储键-值对的散列表条目的头部部分中编码的信息指示关联的键-值对何时进行重定位。通过允许访问RKVS的其它过程无故障地处置重定位,这个信息促进在重定位过程期间继续访问RKVS。此外,当需要扩展散列表以便解决冲突时,分配第二个更大的散列表,并继续对旧散列表和新散列表两者进行查找操作。当键-值对从旧散列表迁移到新散列表时,使用头部信息来处置两个表之间的重定位操作,如上所述。RKVS中的任何***操作都在新的散列表上执行,并且根据需要对旧散列表和新散列表两者执行删除操作。一旦数据迁移完成,旧散列表就会被释放,并且操作会使用新散列表像以前一样继续。
一个或多个实施例还使用在散列表条目中的头部信息中编码的标志防止RKVS中的***和查找失败,这些标志反映存储库中相应键-值对的状态。具体而言,给定散列表条目中的头部信息包括四个单比特标志中的一个或多个。此类标志提供有关以下一项或多项的信息:
(a)关联的条目是否填充有键-值数据,这允许过程确定条目是否被占用,而无需访问除了RKVS散列表以外的任何单独数据结构;(b)关联的条目中的数据是否正在被写入特定条目的过程中,这有助于确定是否延迟对特定条目的操作,直到数据被写入——此类信息允许过程避免由于继续进行操作而另一个过程写入该操作中所涉及的条目之一所造成的故障;(c)关联的条目中的数据是否处于被重定位的过程中,这允许RKVS在冲突补救期间继续操作;和/或(d)另一个过程是否具有写入与存储在关联的条目中的键信息匹配的特定键-值对的优先权,这有助于防止键-值对的双重***。
根据实施例,在RKVS上的每个操作是包括从RKVS中的目标条目读取头部信息的子操作的多部分过程。发起这种操作的过程可以利用检索到的头部信息来中止操作的子操作的附加部分,从而避免潜在的故障情况。根据下面描述的一个或多个实施例,该过程以至少部分地基于检索到的头部信息的方式用一个或多个进一步的操作来跟随被中止的操作。
***和RDMA概述
图1是***100的框图,***100被配置为使一个或多个客户端能够远程访问由执行数据库服务器实例的服务器机器的易失性存储器内的数据库服务器实例管理的键-值存储库。在图1中,机器120配置有多个客户端122-126,它们可以不同地实现为(一个或多个)数据库应用、(一个或多个)数据库服务器实例或被配置为发送RDMA请求的任何其它种类的过程。另外,服务器机器102配置有数据库服务器实例108在其中运行的易失性存储器106。易失性存储器106的高速缓存110包括由数据库服务器实例108管理的启用RDMA的键-值存储库(RKVS)112。
数据库应用、其它数据库服务器实例和其它种类的过程通常通过向数据库服务器实例108发送数据库命令来检索键-值数据和/或将键-值数据写入远程键-值存储库(诸如RKVS 112)。但是,通过使用本文描述的技术,客户端122-126所需的一些或全部键-值操作是通过对服务器机器102的易失性存储器106的基于RDMA的访问来执行的。如图1中所示,RKVS 112至少由散列表114实现。如图1中所示,键-值对可以由客户端122-126中的任何一个经由RDMA请求写入到RKVS 112或从RKVS 112读取,以从散列表114读取或写入散列表114。任何这样的RDMA请求都可以与来自其它客户端的其它RDMA请求并行地被接收。
服务器机器102和机器120通信地耦合到网络130。网络130可以使用促进RDMA请求的任何网络协议或架构来实现。
除了将RDMA访问信息传送到客户端122-126中的一个或多个客户端之外,用于启用RDMA访问的初步步骤还可以包括数据库服务器实例108向网络接口电路***(NIC)140提供某些信息,服务器机器102通过该NIC 140耦合到网络130。NIC 140可以被实现为任何种类的网络接口电路***,包括作为与服务器机器102相关联的服务器刀片上的芯片、作为服务器机器102的网络接口卡等。具体而言,根据实施例,数据库服务器实例108向NIC 140注册易失性存储器106的哪些区域适合RDMA访问。根据一个实施例,响应于RDMA注册,NIC 140向数据库服务器实例108提供一个或多个认证密钥。根据实施例,这些密钥最终被提供给客户端,使得客户端在对易失性存储器106进行RDMA访问时可以证明其被授权。
本文描述的RDMA技术假设底层网络架构允许在客户端122-126中的一个或多个与服务器机器102之间进行数据传送,其中服务器机器102的易失性存储器存储高速缓存的数据。这种底层网络架构可以是例如InfiniBand互连。根据实施例,对RKVS 112的RDMA请求由NIC 140服务,服务器机器102通过NIC 140使用在NIC 140中实现的运输协议耦合到网络130。根据另一个实施例,对RKVS 112的RDMA请求由网络130的管理层服务。但是,本文描述的技术不限于任何特定的底层网络结构。
散列表冲突避免方案
根据实施例,散列表114采用开放式寻址,这不会引起如链接将会引起的操作中的存储器分配或在不同地址的预分配,这导致更多的高速缓存行共享。根据实施例,散列表114还实现避免散列映射冲突的一个或多个方案。实施例在本文中被描述为实现布谷鸟散列冲突避免方案,其中多个散列函数被依次使用以识别散列表114中用于给定键-值对的条目。对于这种方案,当使用两个散列函数时,散列表有80%的负载因子,而当使用三个散列函数时,散列表有91%的负载因子。
为了说明布谷鸟散列方案,***100(图1)的客户端122将函数序列中的第一散列函数应用于特定键-值对的键。第一散列函数的应用识别散列表114中用于特定键-值对的主条目P。如果条目P没有存储特定的键-值对(在读取请求的情况下)或填充有另一个键-值对(在写入请求的情况下),那么客户端122对特定键-值对的键应用序列的第二散列函数,其识别散列表114中用于该键-值对的辅助条目S。以这种方式,根据布谷鸟散列方案,客户端遍历散列函数的序列,以识别散列表中用于单个键-值对的多个条目。
不过,鉴于不同的冲突避免方案更适合可以对其使用RKVS 112的不同应用,实施例不限于布谷鸟散列冲突避免方案。具体而言,根据一个或多个实施例,可以将多线程安全的多个散列表冲突避免方案中的任何一种应用于散列表114,包括布谷鸟散列、跳房子、红-黑树、拆分有序列表等。因此,实施例提供了用于散列表冲突管理的多个选项。
头部标志位
根据一个或多个实施例,散列表114的条目包括一个或多个头部位,其用作从散列表请求信息的过程(诸如客户端122-126)的标志。图2描绘了用于在键-值对操作的第一子操作期间从散列表条目中检索头部信息并基于头部信息中的一个或多个标志被设置而中止键-值对操作的第二子操作的流程图200。具体而言,在流程图200的步骤202处,第一过程通过执行流程图200的步骤202A和202B来执行特定键-值对操作的第一子操作。在步骤202A处,发送远程直接存储器访问(RDMA)请求以从计算设备的易失性存储器中的散列表中用于特定键-值对的特定条目中获得头部信息,其中头部信息包括标志的集合,其包括以下一项或多项:指示特定条目是否被占用的Allocd(已分配)标志,指示对特定条目的不完整写入操作是否正在进行中的Influx(注入)标志,指示特定条目中的数据是否正在进行迁移的Time(时间)标志,以及指示除了第一过程以外的第二过程是否具有将特定键-值对***散列表的优先权的Fence(围栏)标志。
例如,客户端122经由网络130向NIC 140发送RDMA请求,以检索散列表114中用于键-值对(Kx,Vx)的信息。客户端122通过将散列函数应用于Kx来识别用于键-值对的散列表条目,其返回映射到(Kx,Vx)的条目的标识符。根据其中根据使用序列散列函数H1、H2和H3的布谷鸟冲突避免方案管理散列表114的示例实施例,客户端122在Kx上运行H1以识别散列表114中用于特定键-值对的第一候选条目。
图3描绘了具有16字节数据的示例散列表条目配置300,该数据包括表示键-值对的键的6字节的键320信息和表示键-值对的值的8字节的值330信息。条目配置300还包括16位的头部310信息,在图3中所描绘的实施例中,该信息包括四个1位的标志、五位的节点标识符322信息和七位的保留头部空间324。
四个1位的标志包括已分配标志312、注入标志314、时间标志316和围栏标志318。下面根据一个或多个实施例总结各种标志的效用(下面提供了进一步的细节):
·当新数据将被***相关联的散列表条目时,设置已分配标志312。这个标志的效用包括避免多个过程同时尝试在条目中***数据。当条目被用于存储键-值对时,相关联的已分配标志312保持被设置。
·当相关联的散列表条目中数据的***正在进行但尚未完成时,设置注入标志314。这个标志的效用包括在这个条目处停止查找,直到数据被完全***。在数据***完成之后,注入标志314被取消设置,即,由***数据的过程取消设置。使用这个标志促进避免潜在的查找失败。
·在冲突补救期间,在开始将相关联的散列表条目中的数据移动到另一个位置时,设置时间标志316。这个标志的效用包括通知在条目处请求数据的客户端是否键-值对处于被重定位的过程中。在重定位操作完成之后,由执行重定位的过程(诸如数据库服务器实例108)取消设置时间标志316。使用这个标志允许过程在冲突解决期间继续RKVS 112中的操作。
·当将特定键-值对***到散列表114的另一个条目中的过程确定不同的过程也在将相同的特定键-值对***到相关联的散列表条目中时,设置围栏标志318。这个标志的效用包括允许尝试同时将特定键-值对***RKVS 112的多个过程之一通过指示其它过程中止键-值对的***来对***操作取得优先权,从而避免将键-值对双重***RKVS 112中。
根据实施例,头部310中的节点标识符322被用于识别其上存储有散列表114的节点,即,机器102。在这个实施例中,节点标识符322与实现RKVS 112的分布式散列表结合使用,即,以跟踪其上存储不同键-值对的多节点***的节点。
图3进一步描绘了实现RKVS 112的散列表114的内容350的示例。示例散列表内容350包括条目340-348以及列类型描述以示出每个条目内的不同种类数据的缩写列表。虽然描述了列,但根据实施例,实现RKVS 112的散列表的条目包括数据的串,诸如1000011100000000 6_BYTE_KEY 8_BYTE_VALUE,而没有按列分隔数据。
因此,示例散列表内容350中的条目340-348中的每一个包括用于标志312-318的数据(按那个次序描绘)、键320信息和值330信息。在本文中,已分配标志312、注入标志314、时间标志316和围栏标志318被表示为四个位的有序序列,诸如1000,其中每个相应标志按照由散列表条目配置300指示的次序由其在有序位序列内的位置表示。散列表114中的条目可以包括其它数据,诸如节点标识符322,其不包括在示例散列表内容350中。节点标识符322(诸如包括在上述示例数据串中的“01110”)识别计划存储键-值对的节点,诸如在条目属于散列表114的情况下的机器102。
根据一个或多个实施例,允许从散列表的条目检索数据并评估检索到的数据和/或写入散列表的条目的任何RDMA请求都可以被用于实现RKVS 112内的操作,如本文所述。根据实施例,根据需要,比较和交换(CAS)请求被用于写入或识别用于散列表114中的条目的头部310、键320和/或值330的内容。CAS请求可以使用基于RDMA的CAS请求被远程执行,或者可以例如由维护RKVS 112的数据库服务器实例108在本地执行。
以下伪代码(1)描述CAS操作的示例实施方式:
伪代码(1):CAS操作的示例实施方式
这个示例CAS操作确定accum指针处的值是否与dest指针处的值相同。如果是这样,那么操作返回true并将dest指针处的信息与newval变元交换。如果不是,那么操作返回false并使用dest指针处的值填充由accum指针识别出的位置以供以后审查。
根据实施例,CAS操作对8个字节的数据进行操作。因此,单个CAS操作可以(a)在散列表114的给定条目处读取和/或写入头部310和键320信息两者,或(b)在条目处读取和/或写入值330。因而,至少部分地由CAS操作实现的任何操作都要求针对目标条目的至少两个子操作,这至少包括读取/写入头部310和键320的第一子操作以及根据需要读取/写入目标条目的各个部分的第二子操作。
给定的子操作可以要求对一个或多个散列表中的多个条目的执行。例如,如下所述,***操作要求客户端尝试保留映射到正在***的键-值对的所有条目。根据实施例,执行给定子操作所需的请求由客户端并行执行。这个实施例用于描述本文的示例RKVS操作。但是,根据另一个实施例,执行给定子操作所需的各种请求由访问RKVS 112的一个或多个客户端串行执行。
查找操作设计
返回到对流程图200的步骤202A的讨论,由客户端122执行的键-值对操作是从RKVS 112读取与键Kx相关联的值Vx的查找操作。客户端122在Kx上运行散列函数H1以识别散列表114中用于键-值对的第一候选条目。例如,H1将Kx映射到示例散列表内容350的条目340。客户端122通过经由网络130向NIC 140发送RDMA CAS请求来发起查找操作的第一子操作,其中CAS请求读取包括头部310信息和键320信息的识别出的条目340的8个字节。根据实施例,本文对用于评估或设置来自目标条目的头部310和键320信息的状态的子操作的描述涉及这种CAS请求(或者RDMA或者本地)。
CAS类型的操作对于这个目的是有用的,因为CAS请求的运作固有地提供有关头部的状态和来自目标条目的键信息是否与期望状态匹配的信息。因此,在被配置为探索目标条目的状态的第一子操作的情况下,CAS请求允许容易地理解条目的状态。另外,在被配置为设置目标条目的头部和/或键信息的子操作的情况下,只有当条目处于预期状态时,现有信息才被覆写。这种在写入条目之前由CAS请求对条目状态的固有检查避免了意外覆写其它过程所做的改变。
CAS请求将条目340的前8个字节与如果条目340填充有特定的键-值对并准备好被读取则条目340中将存在的8个字节的数据进行比较。具体而言,如果条目准备好被读取,那么用于该条目的头部310信息中的标志将是1000,即,指示该条目已被占用的已设置的已分配标志,而其它标志未被设置以指示不存在导致入口处于中间状态的特殊情况。因此,在来自客户端122的示例RDMA CAS操作中,accum指针指向值1000 01110 0000000Kx,其中Kx是客户端122正在尝试查找的特定键-值对的6字节键值。用于accum指针的这个值指示该请求是针对与处于准备好读取的状态的节点标识符322 01110(例如,机器102的标识符)相关联的特定键-值对。如图3中所指示的,在CAS操作中由dest指针引用的条目340具有值1100011100000000Kx,其指示该条目与Kx相关联,但设置的注入标志指示到该条目的写入操作正在处理中,并且该条目尚未准备好被读取。下面更详细地描述使用注入标志的***操作。
最后,CAS请求的newval变元与位于accum指针处的值相同,因为客户端122不需要改变从条目340检索到的8个字节的值。根据实施例,客户端122使多个线程并行地对散列表114中基于散列函数H1、H2和H3中的每一个映射到Kx的条目中的每一个执行指示的CAS操作。
返回到图2的流程图200的讨论,在步骤202B处,确定设置了标志的集合中的一个或多个标志。例如,在上述示例CAS请求中存储在accum和dest指针处的值不相同,并且CAS操作返回false,这向客户端122指示条目340尚未准备好被读取。由于失败的比较,因此由accum指针引用的存储器被dest指针处的值填充,即,110001110 0000000Kx。客户端122基于accum指针所引用的这个值确定为条目340设置了注入标志314,这指示在条目340中数据的***正在进行中并且尚未完成。
在流程图200的步骤204处,基于一个或多个标志被设置,第一过程中止特定键-值对操作的第二子操作。例如,客户端122基于为条目340设置了注入标志314来确定对于条目340应当中止对特定键-值对的查找操作。照此,客户端122中止将包括从条目340读取值330的RDMA读取请求的查找操作的第二子操作。
作为另一个示例,用于散列表114的第二散列函数H2将Kx映射到示例散列表内容350的条目346。如上所述,客户端122确定为条目346设置了时间标志316,这指示条目346中的数据正在被重定位到另一个条目的过程中,并且重定位操作尚未完成。因而,客户端122基于为条目346设置的时间标志316确定对于条目346应当中止对特定键-值对的查找操作。照此,客户端122中止将包括从条目346读取值330的RDMA读取请求的查找操作的第二子操作。
因此,客户端122不是在另一个过程对键-值对执行***操作或重定位操作时从RKVS 112读取(Kx,Vx)的值,这可以导致查找失败,而是等待足以让其它过程完成影响目标条目的当前操作然后再次尝试查找操作的预先确定的时间量。
查找操作超时
在一些情况下,客户端在散列表114的特定条目中找到期望的键与从条目中读取相关联的值之间可以存在延迟。在这个延迟期间,可能条目已改变,这将导致客户端在读取改变后的值时查找失败。照此,根据实施例,每个客户端计算给定查找操作的第一子操作的开始与查找操作的第二子操作的开始之间的延迟量。如果这个延迟变得大于预定的查找超时时间段,那么客户端从第一个子操作重新开始查找操作。
如下文进一步详细描述的,改变目标条目的值的操作要求三个子操作:(1)第一子操作(例如,CAS类型),以便如果需要的话则在目标条目的头部310中设置适当的标志并将键320设置为适当的键;(2)第二子操作(例如,写入类型),以将目标条目的值330设置为正在写入的键-值对的值;以及(3)第三子操作(例如,CAS类型),以取消设置头部310中的适当标志以指示写入操作的完成。照此,根据一个或多个实施例,预定的查找超时时间段表示大于一个RDMA操作的时延并且小于背靠背执行的两个RDMA操作的时延的时间量。
为了说明,查找操作的成功的第一子操作确保尚未对目标条目发起写入操作。在第一子操作完成之后立即发起查找操作的第二子操作确保在查找操作的第一子操作开始之后发起的任何写入操作不能完成为了在查找操作的第二子操作从条目中检索正确值之前改变值所需的两个子操作。换句话说,遵守预定的查找超时确保给定查找操作的目标条目中的数据在查找操作完成之前不能被修改。
查找失败避免的说明
以下是可以由Nessie***中查找操作的子操作之间的延迟导致的潜在查找失败的说明。在这个示例中,根据具有两个散列函数的布谷鸟方案,索引表中有两个条目P和S,可用于(Kx,Vx)。索引表的主条目P存储(Kx,Vx)的位置信息,它将辅助数据表中的第一个条目识别为键-值对的位置。当条目P存储(Kx,Vx)的位置数据时,过程A从条目P中读取(Kx,Vx)的位置。在从条目P读取位置数据之后,并且在从辅助数据表中指示的位置读取键-值对(Kx,Vx)之前,将辅助数据表第一个条目中存储的数据改变为不同的键-值对。例如,控制数据表中第一个条目的过程B将(Kx,Vx)移动到辅助数据表中的第二个条目,并用不同的键-值对填充第一个条目。在过程B改变辅助数据表中的数据之后,例如在时隙P中,过程B更新索引表中(Kx,Vx)的位置。但是,过程A已经从索引表中读取了先前(并且现在不正确)的(Kx,Vx)的位置数据并尝试从辅助数据表中的第一个条目读取键-值对,这不会产生预期的键-值对。因此,过程A的查找操作无法从键-值存储库中检索Vx。
上述实施例解决了这种潜在的查找失败。具体而言,根据一个或多个实施例,给定上面提出的其中用于(Kx,Vx)的主条目P为空并且键-值对存储在辅助条目S中的场景,客户端122发起对散列表114的条目P中的键-值对的查找操作。客户端122确定条目P的已分配标志未设置,这指示条目P为空。客户端122还针对键-值对在该对的辅助条目,条目S,中发起查找操作。
在读取条目S的头部和键之后,并且在读取其值之前,数据库服务器实例108发起重定位操作以将(Kx,Vx)从散列表114中的条目S移动到条目P,例如,由于冲突解决。结合将(Kx,Vx)重定位到条目P,数据库服务器实例108在条目P的头部310中设置已分配标志和注入标志,并且还将条目P的键320设置为Kx。数据库服务器实例108还在条目S的头部310中设置时间标志,其中条目S的已分配位保持被设置。条目P和S的头部310和键320中的这个信息示出(Kx,Vx)正在处于被***到条目P的过程中并且还处于从条目S重新定位的过程中,并且这些过程尚未完成。
如果客户端122在条目S上执行的查找操作的预定查找超时没有到期(toll)并且查找操作完成,那么客户端122能够在数据库服务器实例108改变存储在条目S中的值之前经由RDMA读取请求从条目S中检索正确的值。但是,如果在预定的查找超时到期之前没有启动查找操作的第二子操作,那么不能保证在条目S被改变之前客户端122可以检索到Vx。因此,如果查找操作超时到期,那么客户端122中止查找操作。如果客户端122然后在完成重定位操作之前读取条目P和S,那么客户端122从条目的头部310确定它们还没有准备好被读取。因此,客户端122在重新尝试查找操作之前等待被配置为允许写入操作终止的时间量。照此,保证客户端122检索键-值对的正确值。
***操作设计:注入标志
根据一个或多个实施例,注入标志314和围栏标志318的利用允许过程避免***失败。具体而言,实施例允许多个过程可靠地写入散列表114和从散列表114删除,从而避免双重***问题和删除问题。
以下是可能由多个过程将同一个键-值对***RKVS 112导致的潜在***失败的说明,如在Nessie***中可能看到的。在这个示例中,两个过程A和B尝试在同一时间范围内将同一个键-值对(Kz,Vz)***到键-值存储库中。另外,第三个过程C在其***之后尝试删除(Kz,Vz)。在这个示例中,(Kz,Vz)映射到索引表中的两个条目P和S。结合将(Kz,Vz)写入键-值存储库,过程A首先通过将其标志设置为无效来预订(book)索引表中的条目P和S。在将条目P的数据设置为辅助数据表中指示(Kz,Vz)的位置的位置数据之后,并且在过程A将与(Kz,Vz)相关联的标志设置为有效之前,过程B尝试将同一个(Kz,Vz)写入条目P。它首先检查与(Kz,Vz)相关联的标志是否有效。由于该标志尚未被更新以指示该对有效,因此基于提出的设计,过程B将在某个延迟后再次重复***操作。Nessie设计中尚未指定这个延迟的量。如果这个延迟比过程A完成将(Kz,Vz)***条目P和过程C完成从条目P的删除操作所需的时间长,那么在过程C删除数据后(Kz,Vz)将由过程B***。这个结果是不期望的,因为过程C完成的删除操作应当在过程A或B***对(Kz,Vz)之后从散列表中清除(Kz,Vz)。
实施例解决了潜在的***失败,诸如上面解释的那个。具体而言,根据实施例,散列表114中用于每个条目的头部310包括用于将正在进行的***操作的当前状态传达给其它过程的注入标志和围栏标志。图4描绘了在进展时间线上的(具有条目402-410的)散列表114的一系列快照430-438。根据实施例,快照430-438描绘了客户端122-126在上述场景中如何交互。具体而言,在图4中所描绘的示例中,(Kz,Vz)映射到条目406和410两者。在这个示例中,用于散列表114的冲突避免方案依次利用散列函数H1和H2将键-值对映射到散列表中的条目。键-值对(Kz,Vz)基于H1映射到条目406,照此,条目406优先于条目410,条目410基于H2映射到键-值对。
在快照430处,客户端122经由***操作中读取条目的头部310的第一子操作确定条目406和410都是空的。客户端122通过设置它们的注入和已分配标志并将Kz***到用于条目的键320信息中来预订这些条目,如快照432中所描绘的。因此,实施例通过在散列表114中保留可用且映射到键-值对的所有条目来防止键-值对的双重***。
在客户端122完成***操作之前,在快照432处,客户端124尝试将同一个(Kz,Vz)***条目406和410中。因为这种***的第一子操作涉及从条目中读取至少头部310和键320以确定条目的当前状态,所以客户端124确定条目406和410都被另一个过程保留以用于同一个键Kz。基于这个确定,客户端124中止***操作的第二子操作并且不执行任何进一步的动作来***键-值对。如果客户端126在***操作完成之前尝试在条目406和410中查找(Kz,Vz)作为删除操作的第一子操作,那么客户端126基于两个条目的注入位被设置来确定针对(Kz,Vz)的***操作尚未完成,如快照432中所示。因此,客户端126延迟预定量的时间,该时间足以让另一个过程完成***操作,然后从第一子操作重新开始删除操作,如下文进一步详细描述的。
如快照434中所示,在完成***操作的第一子操作之后,客户端122执行***操作的(例如,使用RDMA写入类型请求的)第二子操作以将条目406中的值330设置为Vz。根据实施例,客户端122基于散列表114的冲突避免方案所基于的散列函数的序列来选择条目406作为***键-值对的条目。
如快照436中所示,在完成第二子操作之后,客户端122执行***操作的第三子操作,以将条目406的头部310中的标志设置为1000,从而指示条目406中的信息已最终确定并准备好被读取。第三子操作还涉及将条目410的头部310中的标志设置为0000(并且根据实施例,将条目中的键320信息归零)以指示该条目为空。因此,散列表114仅包括(Kz,Vz)的一个副本,虽然多个过程一次尝试***该键-值对。
而且,如快照438中所示,上述***失败被可靠地避免并且能够例如由客户端126成功地从散列表114的条目406中移除(Kz,Vz)。例如,如果客户端126在***操作完成之前的任何时间尝试删除(Kz,Vz),那么执行删除操作的从条目406和410中检索至少头部310和键320信息的第一子操作揭示,对于条目406和410两者,设置了已分配和注入标志,并且键320信息示出Kz,如快照432中所示。头部标志和键信息的这种配置指示条目406和410当前已针对要***(Kz,Vz)的***操作被预订。这个信息导致客户端126中止删除操作的(用于从RKVS112移除键-值对的)第二子操作并等待预定量的时间以允许清除注入标志。
在等待预定量的时间之后,在此期间,注入标志从条目406和410中被清除,如快照436中所示,客户端126在删除操作的从条目406和410中读取头部310和键320的第一子操作处执行第二次尝试。基于第一子操作的结果,客户端126确定(Kz,Vz)存储在条目406中并且可用于被删除,即,具有标志位1000。客户端126执行删除操作的通过将条目406的头部310和键320信息归零来从RKVS 112中移除键-值对的第二子操作,如快照438中所示。
***操作设计:围栏标志
围栏标志318通过允许过程之间关于***特定键-值对的过程的优先权的通信而在防止***失败中是有用的。例如,图5描绘了(具有示例条目502-510的)散列表114随时间的一系列快照520-536,以描绘围栏标志的有用性的示例。具体而言,客户端122通过从映射到键-值对的散列表中的三个条目502、506和510读取头部310和键320信息来执行将(Ky,Vy)***到散列表114的操作的第一子操作。在这个示例中,客户端122执行第一子操作,而散列表114如快照520中所示。因此,客户端122发现条目502被另一个键-值对(Kx,Vx)占用,并且发现条目506和510为空。客户端122通过执行***操作的将条目506和510的键320信息设置为Ky并设置那些条目的头部310信息中的已分配和注入标志以指示它们正在进行针对(Ky,Vy)的***操作的第二子操作而在空条目上使移动操作继续进行。第二子操作的结果在快照522中示出。
在客户端122确定条目502被(Kx,Vx)占用之后,从条目502中删除这个键-值对,这由快照524中头部310的归零标志和条目502的归零键320示出。在这个示例中,这种删除可以发生在客户端122经由***操作的第一子操作检查条目502之后、客户端122完成***操作之前以及诸如客户端124之类的第二客户端发起将(Ky,Vy)***散列表114的第二***操作之前的任何时间。注意的是,为了便于解释,快照524还指示在从条目中删除(Kx,Vx)之后条目502的值330被归零。一旦给定条目的头部信息被设置以指示该条目为空(即,0000),存储在该条目其余部分中的信息就将被视为垃圾信息,直到将另一个键-值对***该条目中。照此,不必为了删除条目的内容而执行将条目的值330归零的操作。
继续图5的示例,当散列表114处于快照524所指示的状态时,客户端124发起将(Ky,Vy)***散列表114中的第二***操作。具体而言,客户端124执行***操作的从映射到(Ky,Vy)的条目502、506和510中读取头部310和键320的第一子操作。在这种情况下,客户端124发现条目502为空,并且条目506和510都设置了注入标志,并且键320信息指示Ky。
在客户端发现已经在***操作的目标条目之一中设置了注入位的情况下,响应取决于键320信息是否与客户端正在***的键匹配。如果给定目标条目的键320信息指示不同的键-值对,那么该条目被锁定以进行不同键-值对的***操作。如客户端122保留的条目506和510中的快照522所示,***操作的第一子操作是使用一个或多个CAS请求执行的,该一个或多个CAS请求尝试将散列表114中空目标条目的头部310和键320设置为设置了已分配和注入位的头部信息和指示要***的键的键信息。这种动作保留条目以***期望的键-值对。如果在CAS操作期间成功地为键-值对***保留了至少一个条目,那么客户端继续将值***到保留的条目之一中。
但是,如果用作***操作的第一子操作的CAS操作都没有成功地为***保留条目,那么客户端等待一段时间,以便清除列出不同键的目标条目的注入位。这允许保留条目是为了避免双重***而不是为了将另一个键-值对***所需条目的可能性。如果在等待时段之后客户端发现用于***操作的所有目标条目都已满,那么客户端发起冲突补救,如下文详细描述的。
另一方面,如果客户端124尝试保留(但发现设置了注入位)的目标条目中的一个或多个目标条目的键320指示客户端124正在插同一个键,这意味着另一个过程已锁定一个或多个条目以***同一个键-值对。在这种情况下,如果客户端124能够保留目标条目中的至少一个目标条目,那么客户端尝试通过使用围栏位阻止另一个***来优先***键-值对。为了使用图5的示例进行说明,客户端124发现条目506和510设置了注入标志并且在键320中也具有与客户端124正在试图***的键相同的键。因此,保留这些条目506和510的尝试失败。但是,如快照526中所示,考虑到在客户端124执行***操作的第一子操作时条目为空,则保留条目502的尝试成功。在快照526-536中,条目502周围的虚线边界以及条目506和510周围没有虚线边界说明了条目502与条目506和510之间的所有权差异。具体而言,客户端124控制条目502,而客户端122控制条目506和510。
当多个不同的客户端在散列表114中保留条目以***同一个键-值对时,其中一个客户端优先执行***操作。根据实施例,优先权由阻止一个或多个其它客户端执行***的客户端或由在另一个客户端有机会阻止该操作之前完成***操作的客户端确定。根据另一个实施例,优先权转到为键-值对保留具有最低索引的条目的客户端。因为优先权由***客户端之一断言,所以可能不会发生同时***同一个键-值对的多个***操作。具体而言,已经失去优先权的客户端检测到其它客户端建立优先权的动作,并中止完成非优先权***操作所需的任何进一步的子操作。
为了阻止客户端122完成在条目506和510中开始的***操作,客户端124尝试设置条目506和510的围栏位。在这个示例中,设置这些围栏位的尝试成功,如快照528中所示,该成功是客户端122尚未将(Ky,Vy)成功***条目506或510的结果。客户端124通过发送将Vy写入条目502的值330的RDMA写入请求来继续***操作的第二子操作,如快照532中所示。客户端124通过将条目502的头部310设置为1000来执行***操作的第三子操作,如快照534中所示,这指示该条目已被占用并准备好被读取。
当客户端122尝试继续其对(Ky,Vy)的***时,客户端122通过使用RDMA写入请求将Vy作为条目506的值330写入来执行***操作的第二子操作,如快照530中所示。但是,当客户端122尝试使用RDMA CAS请求执行***操作的将条目506的头部310从“1100”改为“1000”的第三子操作时,请求失败,因为设置了围栏位,即,CAS请求在条目506的头部310的预期值(1100)与头部的实际值(1101)之间执行的比较导致CAS请求返回false并且不执行交换。基于在条目506的头部310中设置了围栏位,客户端122确定它没有***(Ky,Vy)的优先权。根据实施例,响应于确定它没有***(Ky,Vy)的优先权,客户端122清除条目506和510的头部310和键320,如快照536中所示。根据另一个实施例,作为其第三子操作的一部分,客户端124清除条目506和510的头部310和键320。因此,只有一个客户端成功***键-值对。
图6描绘了散列表114随时间的一系列快照620-630,其中事件类似于图5的那些,具体而言是在快照520/620、522/622和524/624处的事件。快照的序列中的一个区别是客户端122继续进行***操作的将(Ky,Vy)***到散列表114中的第二子操作。具体而言,如快照624的条目606中所示,客户端122发送将Vy写入条目606的值330中的RDMA写入请求。在客户端122将条目606的头部位设置为“1000”之前,客户端124保留条目602并确定条目606和610先前由另一个客户端保留,如快照626中所示。在客户端124保留条目602之后并且在客户端124为条目606和608设置围栏位之前,客户端122执行***操作的将条目606的头部位设置为“1000”并将条目610的头部位和键320归零的第三子操作,如快照628中所示。当客户端124尝试使用CAS类型RDMA请求设置条目606和610的围栏位时,CAS请求,因为(Ky,Vy)已被另一个客户端成功***到条目606中,即,客户端124在CAS请求中预期的头部位(1100)与快照628处的条目的实际头部位(用于条目606的“1000”和用于条目610的“0000”)不匹配。因而,客户端124中止***操作的剩余子操作并将条目602中的头部310和键320归零,如快照630中所示。
***操作设计:时间标志
在***操作的第一子操作期间,***客户端可以发现其中一个目标条目设置了时间位,这指示特定目标条目参与冲突补救,如下面进一步详细描述的。如果特定目标条目的键320信息具有被***的相同键,那么键-值对已经存在于RKVS 112中并且客户端中止***操作。如果条目的键320信息指示与正在***的键不同的键,并且如果客户端已成功地在散列表114中为***操作保留了一个或多个其它条目,那么客户端使用保留的一个或多个条目继续进行***操作。但是,如果客户端没有为***操作保留任何其它条目,那么客户端在继续进行***操作之前等待从特定目标条目中清除时间位。
冲突解决:键-值对重定位
如上面所指示的,冲突避免方案一般在实现RKVS 112的散列表114内使用。但是,虽然应用了这种方案,但在散列表114内仍可能发生冲突,即,当尝试将键-值对写入散列表114的客户端未找到映射到该键-值对的空闲条目时。在这种情况下,如果客户端不是数据库服务器实例108,那么客户端向数据库服务器实例108发送对键-值对的冲突解决请求。在(或者本地或者基于接收到的冲突解决请求)识别出冲突后,数据库服务器实例108着手解决键-值对的冲突并将键-值对***RKVS 112。
根据实施例,为了限制解决冲突所需的处理能力,数据库服务器实例108将确定重定位操作是否将解决冲突所花费的时间量(如下所述)限制为用于冲突补救的预定时间量。因而,为了解决冲突,数据库服务器实例108至多利用用于冲突补救的预定时间量来确定重新定位散列表114中的一个或多个键-值对是否导致空间被清除以用于要***其映射的条目之一的键-值对。
根据实施例,这个确定包括在散列表114内执行重定位。根据另一个实施例,这个确定包括在确定过程期间执行潜在重定位的分析而不执行重定位。在这个实施例中,如果数据库服务器实例108在定时器到期之前确定重定位导致用于键-值对的空间,那么数据库服务器实例108执行如上所述清除空间所需的重定位。根据实施例,使用确定的重定位序列的冲突解决也必须在时间到期之前完成,以避免散列表调整尺寸。
根据一个或多个实施例,用于实现RKVS 112的散列表中的条目的头部310中的标志允许在RKVS 112内执行冲突解决动作——包括在散列表114内重新定位键-值对和重新分配散列表以增加表的尺寸——同时维持存储在RKVS 112中的数据的可用性。具体而言,数据库服务器实例108与重定位键-值对相关联地设置时间标志以进行冲突补救,以便将重定位操作的发生传达给利用RKVS 112中的信息的其它过程。因此,访问RKVS 112的其它过程能够在正确处置重定位操作中所涉及的条目的同时继续访问数据。
重定位操作涉及三个RDMA请求(可以根据需要在操作的目的地和源条目上并行执行):(1)用于每个条目的第一CAS类型子操作,以在目的地和源条目的头部中设置合适的标志,并根据需要将键320设置为适当的键;(2)第二写入子操作,以将目的地条目的值330设置为被重定位的键-值对的值;以及(3)第三CAS类型子操作,以调整源和目的地条目的头部310中的适当标志以完成重定位操作。
为了说明重定位操作,图7描绘了散列表114的随着时间的快照720-728,包括五个条目702-710。具体而言,在快照720处,条目702和708分别填充有键-值对(Kx,Vx)和(Ky,Vy)。因而,这些条目与标志值“1000”相关联,其中已分配标志是唯一设置的标志。条目704、706和710为空,因此与标志值“0000”相关联。
在条目702-710处于快照720处所指示的状态的情况下,客户端122尝试将键-值对(Kz,Vz)***散列表114。为散列表114实现的冲突避免方案具有两个散列函数,它们分别将(Kz,Vz)映射到条目702和708。因为(Kz,Vz)映射到的两个条目都被其它键-值对占用,所以客户端122向数据库服务器实例108发送针对(Kz,Vz)的冲突解决请求。基于冲突解决请求,数据库服务器实例108确定条目702或708是否可以在散列表114内被重定位以便解决冲突。数据库服务器实例108确定(Ky,Vy)映射到条目706和708,其中条目706未被占用,如快照720中所示。
为了将(Ky,Vy)从源条目708重定位到目的地条目706,数据库服务器实例108经由(例如,并行)执行两个本地CAS操作来执行重定位操作的第一子操作,其结果在快照722中描绘。具体而言,CAS操作之一在条目706中将头部310位改为“1100”,并将键320改为Ky,以通过设置的注入位指示Ky的值正在被写入条目706的过程中。另一个CAS操作在条目708中将头部310位改为“1010”,以通过设置的时间位指示条目的当前内容(Ky,Vy)正在被重定位的过程中。
一旦重定位操作的第一子操作完成,数据库服务器实例108就经由将Vy本地写入条目706的值330来执行重定位操作的第二子操作,如快照724中所示。一旦重定位操作的第二子操作完成,数据库服务器实例108就经由(例如,并行执行的)两个本地CAS操作执行重定位操作的第三子操作,其结果在快照726中描绘。具体而言,CAS操作之一在条目706中将头部310位改为“1000”,以指示该条目已被占用并准备好进行其它操作。另一个CAS操作在条目708中将头部310位改为“0000”以指示条目708当前为空,并且根据实施例,还将条目708内的其它信息设置为零,诸如键320。因而,重定位操作释放条目708以用于***(Kz,Vz),数据库服务器实例108执行***(Kz,Vz)的操作,如上文详细描述的,其最终结果在快照728中描绘。
根据一个或多个实施例,如果在重定位操作的第一子操作期间数据库服务器实例108确定目的地条目设置了注入位,那么数据库服务器实例108延迟预定的时间量并且然后重试重定位操作。这个延迟允许保留目标目的地条目的客户端有时间完成当前操作,并可能释放该条目以用作重定位的目的地,例如,在保留该条目以避免双重***的情况下。
冲突解决:散列表调整尺寸
如果在检测到的冲突被重定位操作解决之前冲突补救的预定时间量已经到期,那么数据库服务器实例108自动停止重定位操作并在易失性存储器106中调整实现RKVS 112的散列表的尺寸。为了说明,数据库服务器实例108在高速缓存110中分配另一个散列表800以实现RKVS 112,如图8中所描绘的,其中相同的附图标记指代图1中的对应描绘和描述。散列表800的尺寸比散列表114大,例如双倍。根据实施例,停止重定位操作包括取消设置数据库服务器实例108已经与冲突补救重定位操作相关地设置的任何时间位。
图9描绘了用于将键-值存储库的至少一部分从易失性存储器中的第一散列表迁移到易失性存储器中的第二散列表的流程图900。在流程图900的步骤902处,一个或多个消息被发送到被配置为使用RDMA请求访问第一散列表处的键-值存储库的一个或多个客户端,其中一个或多个消息包括识别第二散列表的信息。例如,在确定将RKVS 112的键-值对从散列表114迁移到散列表800后,数据库服务器实例108将消息发送到被认证为经由RDMA访问散列表114的每个客户端,例如客户端122-126。这些消息指示键-值存储库的迁移并识别散列表800。这些消息允许客户端在两个散列表之间的迁移期间继续访问RKVS。
基于这些消息,客户端122-126(以及注册为经由RDMA访问散列表114的任何其它客户端)注册以经由RDMA访问散列表800,如上文详细描述的。因此,数据库服务器实例108和被授权访问散列表114的任何客户端都能够在迁移期间访问散列表114和散列表800两者。
在步骤904处,将键-值存储库中的多个键-值对从第一散列表重定位到第二散列表。例如,数据库服务器实例108将存储在散列表114中的键-值对迁移到散列表800,而无需RKVS 112中的客户端在迁移期间停止操作。除了重定位操作的源条目在散列表114中并且重定位操作的目的地条目在散列表800中之外,数据库服务器实例108以类似于上述重定位操作的方式在散列表114和散列表800之间执行迁移。
在步骤906处,在将多个键-值对从第一散列表重定位到第二散列表的同时,第一散列表和第二散列表都被维护。例如,数据库服务器实例108在键-值对的迁移期间在易失性存储器106中维护散列表114和散列表800两者。
在步骤908处,当第一散列表和第二散列表都被维护时,来自一个或多个客户端的针对第一散列表的一个或多个第一RDMA请求被服务,并且来自一个或多个客户端的针对第二散列表的一个或多个第二RDMA请求被服务。例如,NIC 140为来自客户端122-126中的一个或多个客户端的针对散列表114和散列表800两者的RDMA请求提供服务。
具体而言,在迁移期间,在散列表114和散列表800内都执行查找操作。此外,在散列表800内而不是在散列表114内执行***操作。删除操作也在散列表114和散列表800中执行。在迁移过程期间,当客户端遇到散列表114中设置了时间标志的条目(它是特定操作的目标)时,客户端等待一段时间以允许完成重定位,然后在散列表800中(而不是在散列表114和散列表800两者中)尝试该操作。
在步骤910处,在将多个键-值对从第一散列表重定位到第二散列表之后,第一散列表被释放。例如,在将所有键-值对从散列表114重定位到散列表800之后,数据库服务器实例108向具有对RKVS 112的RDMA访问的每个客户端发送另一个消息,以向客户端通知迁移完成。数据库服务器实例108然后释放散列表114,并且随后散列表800作为在服务器机器102上实现RKVS 112的散列表执行。
因此,虽然由于需要在散列表114和800上执行操作类型而使得一些操作类型在针对冲突解决的迁移期间可能较慢,但所有类型的操作(包括***、删除和查找)都能够在RKVS 112中的冲突解决的每一步中继续。
其它***细节
参考图1,一个或多个客户端122-126例如作为并行过程在机器120上执行。客户端122-126可以不同地实现,例如,作为在除了主机服务器机器以外的机器上执行的过程、数据库应用或其它数据库服务器实例而实现。客户端也可以是链接到数据库应用中的客户端侧数据库服务器过程,或者是这种过程和该过程链接到的数据库应用的组合。
虽然客户端122-126在本文中被描述为驻留在单个机器上,但是可以访问RKVS112的客户端可以在例如通过网络130通信耦合到机器102的任何数量的计算设备上执行。诸如客户端122-126或数据库服务器实例108中的任何一个之类的应用、过程或服务在计算设备上运行并且包括软件和来自计算设备的资源分配的组合。具体而言,应用或服务是集成的软件组件和计算资源的分配的组合,诸如存储器和/或计算设备上用于在处理器上执行集成的软件组件的过程,软件和计算资源的组合专用于执行应用或服务的规定功能。
硬件概述
根据一个实施例,本文描述的技术由一个或多个专用计算设备实现。专用计算设备可以是硬连线的以执行这些技术,或者可以包括数字电子设备(诸如被持久地编程为执行这些技术的一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)),或者可以包括被编程为根据固件、存储器、其它存储装置或组合中的程序指令来执行这些技术的一个或多个通用硬件处理器。这种专用计算设备还可以将定制的硬连线逻辑、ASIC或FPGA与定制编程相结合,以实现这些技术。专用计算设备可以是台式计算机***、便携式计算机***、手持设备、联网设备或者结合硬连线和/或程序逻辑以实现这些技术的任何其它设备。
例如,图10是图示可以在其上实现本发明实施例的计算机***1000的框图。计算机***1000包括总线1002或用于传送信息的其它通信机制,以及与总线1002耦合以处理信息的硬件处理器1004。硬件处理器1004可以是例如通用微处理器。
计算机***1000还包括耦合到总线1002的主存储器1006,诸如随机存取存储器(RAM)或其它动态存储设备,用于存储信息和将由处理器1004执行的指令。主存储器1006还可以用于存储在执行由处理器1004执行的指令期间的临时变量或其它中间信息。当存储在处理器1004可访问的非瞬态存储介质中时,这些指令使计算机***1000成为被定制以执行指令中指定的操作的专用机器。
计算机***1000还包括耦合到总线1002的只读存储器(ROM)1008或其它静态存储设备,用于存储用于处理器1004的静态信息和指令。存储设备1010(诸如磁盘、光盘或固态驱动器)被提供并耦合到总线1002,用于存储信息和指令。
计算机***1000可以经由总线1002耦合到显示器1012(诸如阴极射线管(CRT)),用于向计算机用户显示信息。包括字母数字键和其它键的输入设备1014耦合到总线1002,用于将信息和命令选择传送到处理器1004。另一种类型的用户输入设备是光标控件1016(诸如鼠标、轨迹球或光标方向键),用于将方向信息和命令选择传送到处理器1004并用于控制显示器1012上的光标移动。这种输入设备通常在两个轴(第一轴(例如,x)和第二轴(例如,y))上具有两个自由度,这允许设备指定平面中的位置。
计算机***1000可以使用定制的硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑(它们与计算机***相结合,使计算机***1000成为专用机器或将计算机***1000编程为专用机器)来实现本文所述的技术。根据一个实施例,响应于处理器1004执行包含在主存储器1006中的一个或多个指令的一个或多个序列,计算机***1000执行所述的技术。这些指令可以从另一个存储介质(诸如存储设备1010)读入到主存储器1006中。包含在主存储器1006中的指令序列的执行使得处理器1004执行本文所述的处理步骤。在替代实施例中,可以代替软件指令或与软件指令组合使用硬连线的电路***。
如本文使用的术语“存储介质”是指存储使机器以特定方式操作的数据和/或指令的任何非瞬态介质。这种存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如光盘、磁盘或固态驱动器,诸如存储设备1010。易失性介质包括动态存储器,诸如主存储器1006。存储介质的常见形式包括例如软盘、柔性盘、硬盘、固态驱动器、磁带或任何其它磁数据存储介质、CD-ROM、任何其它光学数据存储介质、任何具有孔图案的物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其它存储器芯片或盒式磁带。
存储介质不同于传输介质但可以与传输介质结合使用。传输介质参与在存储介质之间传送信息。例如,传输介质包括同轴电缆、铜线和光纤,包括包含总线1002的导线。传输介质也可以采用声波或光波的形式,诸如在无线电波和红外数据通信期间生成的声波或光波。
将一个或多个指令的一个或多个序列携带到处理器1004以供执行可以涉及各种形式的介质。例如,指令最初可以在远程计算机的磁盘或固态驱动器上携带。远程计算机可以将指令加载到其动态存储器中,并使用调制解调器通过电话线发送指令。计算机***1000本地的调制解调器可以在电话线上接收数据并使用红外发送器将数据转换成红外信号。红外检测器可以接收红外信号中携带的数据,并且适当的电路***可以将数据放在总线1002上。总线1002将数据传送到主存储器1006,处理器1004从主存储器1006检索并执行指令。由主存储器1006接收的指令可以可选地在由处理器1004执行之前或之后存储在存储设备1010上。
计算机***1000还包括耦合到总线1002的通信接口1018。通信接口1018提供耦合到网络链路1020的双向数据通信,其中网络链路1020连接到本地网络1022。例如,通信接口1018可以是集成服务数字网(ISDN)卡、电缆调制解调器、卫星调制解调器或者提供与对应类型的电话线的数据通信连接的调制解调器。作为另一个示例,通信接口1018可以是局域网(LAN)卡,以提供与兼容LAN的数据通信连接。还可以实现无线链路。在任何此类实现中,通信接口1018都发送和接收携带表示各种类型信息的数字数据流的电信号、电磁信号或光信号。
网络链路1020通常通过一个或多个网络向其它数据设备提供数据通信。例如,网络链路1020可以提供通过本地网络1022到主机计算机1024或到由互联网服务提供商(ISP)1026操作的数据设备的连接。ISP 1026进而通过全球分组数据通信网络(现在通常称为“互联网”1028)提供数据通信服务。本地网络1022和互联网1028都使用携带数字数据流的电信号、电磁信号或光信号。通过各种网络的信号以及网络链路1020上并通过通信接口1018的信号(其将数字数据携带到计算机***1000和从计算机***1000携带数字数据)是传输介质的示例形式。
计算机***1000可以通过(一个或多个)网络、网络链路1020和通信接口1018发送消息和接收数据,包括程序代码。在互联网示例中,服务器1030可以通过互联网1028、ISP1026、本地网络1022和通信接口1018发送对应用程序的所请求代码。
接收到的代码可以在它被接收到时由处理器1004执行,和/或存储在存储设备1010或其它非易失性存储装置中以供稍后执行。
软件概述
图11是可以用于控制计算机***1000的操作的基本软件***1100的框图。软件***1100及其组件,包括它们的连接、关系和功能,意在仅仅是示例性的,并且不意味着限制(一个或多个)示例实施例的实现。适于实现(一个或多个)示例实施例的其它软件***可以具有不同的组件,包括具有不同的连接、关系和功能的组件。
提供软件***1100用于指导计算机***1000的操作。可以存储在***存储器(RAM)1006和固定存储装置(例如,硬盘或闪存)1010上的软件***1100包括内核或操作***(OS)1110。
OS 1110管理计算机操作的低级方面,包括管理进程的执行、存储器分配、文件输入和输出(I/O)以及设备I/O。表示为1102A、1102B、1102C...1102N的一个或多个应用程序可以被“加载”(例如,从固定存储装置1010传送到存储器1006中)以供***1100执行。意图在计算机***1000上使用的应用或其它软件也可以被存储为可下载的计算机可执行指令集,例如,用于从互联网位置(例如,Web服务器、应用商店或其它在线服务)下载和安装。
软件***1100包括图形用户界面(GUI)1115,用于以图形(例如,“点击”或“触摸手势”)方式接收用户命令和数据。进而,这些输入可以由***1100根据来自操作***1110和/或(一个或多个)应用1102的指令来起作用。GUI 1115还用于显示来自OS 1110和(一个或多个)应用1102的操作结果,用户可以对操作结果提供附加的输入或终止会话(例如,注销)。
OS 1110可以直接在计算机***1000的裸硬件1120(例如,(一个或多个)处理器1004)上执行。可替代地,管理程序或虚拟机监视器(VMM)1130可以***在裸硬件1120和OS1110之间。在这个配置中,VMM 1130充当OS 1110与计算机***1000的裸硬件1120之间的软件“缓冲”或虚拟化层。
VMM 1130实例化并运行一个或多个虚拟机实例(“客人机”)。每个客人机包括“客人”操作***(诸如OS 1110),以及被设计为在客人操作***上执行的一个或多个应用(诸如(一个或多个)应用1102)。VMM 1130向客人操作***呈现虚拟操作平台并管理客人操作***的执行。
在一些实例中,VMM 1130可以允许客人操作***如同其直接在计算机***1000的裸硬件1120上运行一样运行。在这些实例中,被配置为直接在裸硬件1120上执行的客人操作***的相同版本也可以在VMM 1130上执行而无需修改或重新配置。换句话说,VMM 1130可以在一些情况下向客人操作***提供完全硬件和CPU虚拟化。
在其它实例中,客人操作***可以被专门设计或配置为在VMM 1130上执行以提高效率。在这些实例中,客人操作***“意识到”它在虚拟机监视器上执行。换句话说,VMM1130可以在某些情况下向客人操作***提供半虚拟化。
计算机***进程包括硬件处理器时间的分配,以及存储器的分配(物理和/或虚拟),存储器的分配用于存储由硬件处理器执行的指令的、用于存储由硬件处理器执行指令所生成的数据和/或用于当计算机***进程未运行时在硬件处理器时间的分配之间存储硬件处理器状态(例如,寄存器的内容)。计算机***进程在操作***的控制下运行,并且可以在计算机***上执行的其它程序的控制下运行。
云计算
本文一般地使用术语“云计算”来描述计算模型,该计算模型使得能够按需访问计算资源的共享池,诸如计算机网络、服务器、软件应用和服务,并且允许以最少的管理工作或服务提供商交互来快速提供和释放资源。
云计算环境(有时称为云环境或云)可以以各种不同方式实现,以最好地适应不同要求。例如,在公共云环境中,底层计算基础设施由组织拥有,该组织使其云服务可供其它组织或一般公众使用。相反,私有云环境一般仅供单个组织使用或在单个组织内使用。社区云旨在由社区内的若干组织共享;而混合云包括通过数据和应用可移植性绑定在一起的两种或更多种类型的云(例如,私有、社区或公共)。
一般而言,云计算模型使得先前可能由组织自己的信息技术部门提供的那些职责中的一些代替地作为云环境内的服务层来递送,以供(根据云的公共/私有性质,在组织内部或外部的)消费者使用。取决于特定实现,由每个云服务层提供或在每个云服务层内提供的组件或特征的精确定义可以有所不同,但常见示例包括:软件即服务(SaaS),其中消费者使用在云基础设施上运行的软件应用,同时SaaS提供者管理或控制底层云基础设施和应用。平台即服务(PaaS),其中消费者可以使用由PaaS提供者支持的软件编程语言和开发工具,以开发、部署和以其它方式控制它们自己的应用,同时PaaS提供者管理或控制云环境的其它方面(即,运行时执行环境下的一切)。基础设施即服务(IaaS),其中消费者可以部署和运行任意软件应用,和/或提供进程、存储装置、网络和其它基础计算资源,同时IaaS提供者管理或控制底层物理云基础设施(即,操作***层下面的一切)。数据库即服务(DBaaS),其中消费者使用在云基础设施上运行的数据库服务器或数据库管理***,同时DbaaS提供者管理或控制底层云基础设施、应用和服务器,包括一个或多个数据库服务器。
在前面的说明书中,已经参考众多具体细节描述了本发明的实施例,这些细节可以根据实现而有所变化。因而,说明书和附图应被视为说明性而非限制性的。本发明范围的唯一和排他性指示,以及申请人意图作为本发明范围的内容,是以发布这种权利要求的具体形式从本申请发布的权利要求集合的字面和等同范围,包括任何后续更正。
Claims (14)
1.一种计算机执行的方法,包括:
第一过程,通过以下操作执行特定键-值对操作的第一子操作:
发送远程直接存储器访问RDMA请求以从计算设备的易失性存储器中的散列表中的用于特定键-值对的特定条目获得头部信息,
其中头部信息包括标志的集合,所述标志的集合包括以下中的一个或多个:
已分配标志,指示特定条目是否被占用,
注入标志,指示对特定条目的不完整写入操作是否正在进行中,
时间标志,指示特定条目中的数据是否正在迁移,以及
围栏标志,指示除第一过程以外的第二过程是否具有将特定键-值对***散列表的优先权,
确定标志的集合中的一个或多个标志被设置;以及
基于所述一个或多个标志被设置,第一过程中止所述特定键-值对操作的第二子操作;
其中所述方法由一个或多个计算设备执行。
2.如权利要求1所述的方法,其中:
所述特定键-值对包括特定值;
所述特定键-值对操作是从散列表的特定条目中检索所述特定值的查找操作;
所述一个或多个设置的标志包括时间标志;以及
所述方法还包括,在中止所述特定键-值对操作的第二子操作之后并且在所述确定所述一个或多个标志被设置后的预定时间量之后,第一过程执行第二查找操作以检索所述特定值。
3.如权利要求2所述的方法,其中第一过程执行第二查找操作以从散列表中检索所述特定值。
4.如权利要求2所述的方法,其中:
散列表(a)是第一散列表,并且(b)实现键-值存储库;
所述方法还包括确定键-值存储库正从第一散列表迁移到第二散列表;
第一过程至少部分地基于所述确定键-值存储库正从第一散列表迁移到第二散列表而执行第二查找操作以在第一散列表和第二散列表上检索所述特定值。
5.如权利要求1所述的方法,其中:
所述特定键-值对操作是将特定键-值对***到散列表的特定条目中的***操作;
所述一个或多个设置的标志包括围栏标志;
所述方法还包括,在中止所述特定键-值对操作的第二子操作之后,发送第二RDMA请求以取消设置特定条目的头部信息中的一个或多个标志位。
6.如权利要求1所述的方法,其中:
所述特定键-值对包括特定值;
所述特定键-值对操作是从散列表的特定条目中检索所述特定值的查找操作;
所述一个或多个设置的标志包括注入标志;
所述方法还包括,在中止所述特定键-值对操作的第二子操作之后并且在所述确定所述一个或多个标志被设置后的预定时间量之后,第一过程执行第二查找操作以检索所述特定值。
7.如权利要求1所述的方法,其中:
RDMA请求是比较和交换CAS类型RDMA请求;
CAS类型RDMA请求将来自特定条目的头部信息与其中一个或多个未设置的标志位与所述一个或多个设置的标志对应的目标头部信息进行比较;
所述确定标志的集合中的所述一个或多个标志被设置包括:CAS类型RDMA请求返回指示来自特定条目的头部信息与目标头部信息不匹配的信息。
8.一种用于将键-值存储库的至少一部分从易失性存储器中的第一散列表迁移到易失性存储器中的第二散列表的计算机执行的方法,包括:
向一个或多个客户端发送一个或多个消息,所述一个或多个客户端被配置为使用RDMA请求访问第一散列表处的键-值存储库,其中所述一个或多个消息包括识别第二散列表的信息;
将键-值存储库中的多个键-值对从第一散列表重定位到第二散列表;
在将所述多个键-值对从第一散列表重定位到第二散列表的同时,维护第一散列表和第二散列表两者;
在维护第一散列表和第二散列表两者的同时,对以下请求进行服务:
来自所述一个或多个客户端的对第一散列表的一个或多个第一RDMA请求,以及
来自所述一个或多个客户端的对第二散列表的一个或多个第二RDMA请求;以及
在将所述多个键-值对从第一散列表重定位到第二散列表之后,释放第一散列表;
其中所述方法由一个或多个计算设备执行。
9.如权利要求8所述的方法,其中将所述多个键-值对从第一散列表重定位到第二散列表包括将所述多个键-值对中的特定键-值对通过以下操作从第一散列表的第一条目重定位到第二散列表的第二条目:
在用于第一散列表的第一条目的头部信息中设置时间标志;以及
在所述设置时间标志之后,将特定键-值对的信息写入第二散列表的第二条目。
10.如权利要求8所述的方法,其中,在所述重定位所述多个键-值对期间,至少部分地通过向第一散列表发送第一RDMA请求并向第二散列表发送第二RDMA请求,所述一个或多个客户端中的特定客户端对来自键-值存储库的所述多个键-值对中的特定键-值对执行查找操作。
11.如权利要求8所述的方法,其中,在所述重定位所述多个键-值对期间,至少部分地通过发送将特定键-值对的信息写入第二散列表的RDMA请求,所述一个或多个客户端中的特定客户端执行***操作以将所述多个键-值对中的特定键-值对***到键-值存储库中。
12.一种或多种存储指令的非暂态计算机可读介质,所述指令在由一个或多个处理器执行时使得执行如权利要求1-11中的任一项所述的方法。
13.一种***,包括:
一个或多个处理器;以及
一个或多个存储指令的非暂态计算机可读介质,所述指令在由所述一个或多个处理器执行时使得执行如权利要求1-11中的任一项所述的方法。
14.一种计算***,包括用于执行如权利要求1-11中的任一项所述的方法的部件。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/571,423 US11500856B2 (en) | 2019-09-16 | 2019-09-16 | RDMA-enabled key-value store |
US16/571,423 | 2019-09-16 | ||
PCT/US2020/049437 WO2021055179A1 (en) | 2019-09-16 | 2020-09-04 | Rdma-enabled key-value store |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114365109A true CN114365109A (zh) | 2022-04-15 |
Family
ID=72561990
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202080059883.7A Pending CN114365109A (zh) | 2019-09-16 | 2020-09-04 | 启用rdma的键-值存储库 |
Country Status (4)
Country | Link |
---|---|
US (1) | US11500856B2 (zh) |
EP (2) | EP4031986B1 (zh) |
CN (1) | CN114365109A (zh) |
WO (1) | WO2021055179A1 (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11296867B2 (en) * | 2019-05-01 | 2022-04-05 | Intuit Inc. | Systems and methods for hash chain migration |
CN113268544B (zh) * | 2021-05-31 | 2023-06-27 | 新华三技术有限公司 | 一种数据处理方法及装置 |
Family Cites Families (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7610348B2 (en) | 2003-05-07 | 2009-10-27 | International Business Machines | Distributed file serving architecture system with metadata storage virtualization and data access at the data server connection speed |
US7685254B2 (en) | 2003-06-10 | 2010-03-23 | Pandya Ashish A | Runtime adaptable search processor |
US7984180B2 (en) | 2005-10-20 | 2011-07-19 | Solarflare Communications, Inc. | Hashing algorithm for network receive filtering |
US8892509B2 (en) | 2006-03-28 | 2014-11-18 | Oracle America, Inc. | Systems and methods for a distributed in-memory database |
US9009116B2 (en) | 2006-03-28 | 2015-04-14 | Oracle America, Inc. | Systems and methods for synchronizing data in a cache and database |
US8504791B2 (en) * | 2007-01-26 | 2013-08-06 | Hicamp Systems, Inc. | Hierarchical immutable content-addressable memory coprocessor |
US8762476B1 (en) | 2007-12-20 | 2014-06-24 | Qurio Holdings, Inc. | RDMA to streaming protocol driver |
US20110137861A1 (en) | 2009-12-09 | 2011-06-09 | International Business Machines Corporation | Methods for Achieving Efficient Coherent Access to Data in a Cluster of Data Processing Computing Nodes |
US20120331243A1 (en) | 2011-06-24 | 2012-12-27 | International Business Machines Corporation | Remote Direct Memory Access ('RDMA') In A Parallel Computer |
US9495324B2 (en) | 2012-03-30 | 2016-11-15 | Intel Corporation | Efficient distribution of subnet administration data over an RDMA network |
US9164702B1 (en) | 2012-09-07 | 2015-10-20 | Google Inc. | Single-sided distributed cache system |
US9332083B2 (en) | 2012-11-21 | 2016-05-03 | International Business Machines Corporation | High performance, distributed, shared, data grid for distributed Java virtual machine runtime artifacts |
JP2014130420A (ja) | 2012-12-28 | 2014-07-10 | Hitachi Ltd | 計算機システム及び計算機の制御方法 |
US9292564B2 (en) | 2013-09-21 | 2016-03-22 | Oracle International Corporation | Mirroring, in memory, data from disk to improve query performance |
US9977760B1 (en) * | 2013-12-23 | 2018-05-22 | Google Llc | Accessing data on distributed storage systems |
US9912750B2 (en) | 2014-07-25 | 2018-03-06 | Unisys Corporation | Data path selection for network transfer using high speed RDMA or non-RDMA data paths |
US20160026605A1 (en) | 2014-07-28 | 2016-01-28 | Emulex Corporation | Registrationless transmit onload rdma |
US10936200B2 (en) | 2014-07-30 | 2021-03-02 | Excelero Storage Ltd. | System and method for improved RDMA techniques for multi-host network interface controllers |
US9747249B2 (en) | 2014-12-29 | 2017-08-29 | Nicira, Inc. | Methods and systems to achieve multi-tenancy in RDMA over converged Ethernet |
US10581997B2 (en) * | 2015-03-05 | 2020-03-03 | Intel Corporation | Techniques for storing or accessing a key-value item |
US10484472B2 (en) | 2015-07-31 | 2019-11-19 | Netapp, Inc. | Methods and systems for efficiently moving data between nodes in a cluster |
US10725963B2 (en) | 2015-09-12 | 2020-07-28 | Microsoft Technology Licensing, Llc | Distributed lock-free RDMA-based memory allocation and de-allocation |
US10810179B2 (en) | 2015-09-25 | 2020-10-20 | Microsoft Technology Licensing, Llc | Distributed graph database |
US10713210B2 (en) * | 2015-10-13 | 2020-07-14 | Microsoft Technology Licensing, Llc | Distributed self-directed lock-free RDMA-based B-tree key-value manager |
US10031883B2 (en) | 2015-10-16 | 2018-07-24 | International Business Machines Corporation | Cache management in RDMA distributed key/value stores based on atomic operations |
US10331613B2 (en) | 2015-10-30 | 2019-06-25 | Netapp, Inc. | Methods for enabling direct memory access (DMA) capable devices for remote DMA (RDMA) usage and devices therof |
US10291739B2 (en) * | 2015-11-19 | 2019-05-14 | Dell Products L.P. | Systems and methods for tracking of cache sector status |
US9836397B2 (en) | 2015-11-20 | 2017-12-05 | International Business Machines Corporation | Direct memory access of dynamically allocated memory |
US10375167B2 (en) | 2015-11-20 | 2019-08-06 | Microsoft Technology Licensing, Llc | Low latency RDMA-based distributed storage |
US9448901B1 (en) | 2015-12-15 | 2016-09-20 | International Business Machines Corporation | Remote direct memory access for high availability nodes using a coherent accelerator processor interface |
US10303646B2 (en) | 2016-03-25 | 2019-05-28 | Microsoft Technology Licensing, Llc | Memory sharing for working data using RDMA |
US11586647B2 (en) | 2016-10-03 | 2023-02-21 | Ocient, Inc. | Randomized data distribution in highly parallel database management system |
US10778767B2 (en) | 2017-04-28 | 2020-09-15 | International Business Machines Corporation | Persistent memory replication in RDMA-capable networks |
US10803039B2 (en) | 2017-05-26 | 2020-10-13 | Oracle International Corporation | Method for efficient primary key based queries using atomic RDMA reads on cache friendly in-memory hash index |
US10956335B2 (en) * | 2017-09-29 | 2021-03-23 | Oracle International Corporation | Non-volatile cache access using RDMA |
US10831663B2 (en) * | 2018-12-10 | 2020-11-10 | International Business Machines Corporation | Tracking transactions using extended memory features |
-
2019
- 2019-09-16 US US16/571,423 patent/US11500856B2/en active Active
-
2020
- 2020-09-04 EP EP20775511.7A patent/EP4031986B1/en active Active
- 2020-09-04 CN CN202080059883.7A patent/CN114365109A/zh active Pending
- 2020-09-04 EP EP23181966.5A patent/EP4242862A3/en active Pending
- 2020-09-04 WO PCT/US2020/049437 patent/WO2021055179A1/en active Search and Examination
Also Published As
Publication number | Publication date |
---|---|
WO2021055179A1 (en) | 2021-03-25 |
EP4242862A3 (en) | 2023-10-11 |
EP4031986A1 (en) | 2022-07-27 |
EP4242862A2 (en) | 2023-09-13 |
US11500856B2 (en) | 2022-11-15 |
US20210081401A1 (en) | 2021-03-18 |
EP4031986B1 (en) | 2023-10-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN114341792B (zh) | 存储集群之间的数据分区切换 | |
US10732836B2 (en) | Remote one-sided persistent writes | |
US11562091B2 (en) | Low latency access to physical storage locations by implementing multiple levels of metadata | |
EP3688598B1 (en) | Method for reading data stored in a non-volatile cache using rdma | |
US9342346B2 (en) | Live migration of virtual machines that use externalized memory pages | |
US10599535B2 (en) | Restoring distributed shared memory data consistency within a recovery process from a cluster node failure | |
US20190163545A1 (en) | Messages with delayed delivery in an in-database sharded queue | |
US7827374B2 (en) | Relocating page tables | |
US10802766B2 (en) | Database with NVDIMM as persistent storage | |
US20160012155A1 (en) | System and method for use of immutable accessors with dynamic byte arrays | |
CN114365109A (zh) | 启用rdma的键-值存储库 | |
US10698637B2 (en) | Stale block resynchronization in NVM based systems | |
US12013787B2 (en) | Dual personality memory for autonomous multi-tenant cloud environment | |
US11580013B2 (en) | Free space management in a block store | |
US20240251021A1 (en) | System and method for migrating groups of containers | |
US20240248768A1 (en) | System and method for instantiating twin applications |
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 |