Dash:Scalable Hashing on Persistent Memory

Abstract

字节寻址的PM让哈希表具有低延迟，持久化代价低，立刻恢复的潜能。最近的英特尔的DCPMM的出现加速了这一趋势。很多新的哈希表算法被提出，但大部分都是基于仿真并且在真的PM上的效果是次优的，他们都是piece-wise.partitial 的方法（不知道什么意思，我估计是能在部分或者局部可以取得最优的效果），这些方法都规避了很多重要的特性 ，例如可测量性、高的载重因子和立即恢复的能力。
我们提出了Dash，一种基于PM的功能全面的方法，建立一个动态可升级的哈希表。这个方法具有之前提到的所有的特性。基于Dash，我们采用了两种流行的动态的哈希模式（可扩展哈希和线性哈希）。在一个23核的机器上，我们与当前最优秀的方法相比较，可以在载重因子高达90%的时候提升3.9倍的性能，并且无论数据集有多大，恢复时间都只需要57ms。

introduction

动态哈希表可以按照需求扩大或者缩小，并且可以作为建立很多数据密集型系统的基础数据结构，例如数据库系统和键值对存储。PM例如3D Xpoint 和memristor承诺可以字节寻址、持久性和高容量和低代价和高性能都依赖存储总线（？）。这些特性让PM对于建立动态哈希表非常具有吸引性，像可以直接在PM上操作和持久化，并且保持高性能和快速恢复。最近发布的因特尔的DCPMM使得这一版本成为了现实。自从PM展现出几个明显的特性（非对称读写速度，高延迟），盲目地应用于先进的磁盘或者DRAM中不会体现出这些特性，因此需要背弃传统的设计方案。
1.1 Hashing on PM：Not What You Assumed
这里已经有几种基于DRAM的演进，针对PM设计出的哈希表。他们主要专注于减少cacheline flushes和PM 写操作为了获得可扩展的性能。但是当他们被真正第在DCPMM上实施时，我们发现可扩展性仍然是主要问题，想要的特性常常是被折中。

图一显示了在目前最优秀的针对PM设计的哈希表的在插入和搜索操作下的吞吐率表现，环境是一个24核的包含Optane DCPMM的服务器运行基于同意的键值分布的负载。然而随着核心数的上升，基于插入和搜索操作下的吞吐率并没有按比例上升。这证实了最近的工作，我们发现主要的问题出在Optane DCMPP的限制带宽比DRAM低3-14倍。即使服务器已经全部用上用来提供最大可能的带宽，但是多余的PM访问依旧可以很轻松的占满整个系统，使得系统无法扩展。我们描述两种主要的多余的PM访问操作，这两个操作是在之前没有给予足够的重视，之前在讨论文中认为很重要但是忽略可功能性。

第一个是多余的PM reads 之前的很多工作关注于如何见啥PM写，但是我们发现减少PM读也是很有必要的，然而现在的策略都是为了减少PM写而增加PM 读。和设备层次级别的操作不同（PM read比写要更快），端到端的写延迟（整个数据路径抱哈CPU caches 和在内存控制器中的写缓存）经常是低于读延迟的。主要原因是当PM 写时可以利用写缓存，由于哈希表内在的随机访问特性，PM读大多数情况都需要接触到PM介质。特别是，针对是否存在记录的这种检查往往会导致大量的PM读：为了找到一个key是否存在，衣蛾或者多个bucket需要被搜索，当比较key的值时，导致很多的cache miss和PM reads。

第二个是重量级的同步控制。大部分之前的工作避开了同步控制的影响。bucket层级的加锁已经被广泛地使用，但是会导致多余的PM 写来请求或者释放读锁，进一步逼迫带宽消耗到达极限。针对只读的无锁的设计可以减少PM写，但是众所周知地是很难去获得权限，更多的是在PM中持有（？）

记录探测和并发控制通常都不会阻止设计良好的哈希表在 DRAM 上扩展。然而在PM上他们可以轻松地消耗掉PM的最大带宽。这个问题需要一种新的设计来减少当记录探测时的不必要的PM read和一个轻量级的并发控制来进一步减少PM writes。