哈希表针对完整迭代+密钥替换进行了优化

Question

我有一个哈希表，运行时绝大多数访问都遵循以下模式之一：

• 遍历所有键/值对。 （此操作的速度至关重要。）
• 修改键（即删除一个键/值对并添加另一个具有相同值但另一个键不同的键。检测重复键并在必要时组合值。）这是在一个循环中完成的，影响了数千个键，但没有其他行动介入。

我还希望它尽量少消耗内存。

其他标准操作必须可用，但使用频率较低，例如

• 插入新的键/值对
• 给定一个键，查找相应的值
• 更改与现有密钥相关联的值

当然，所有“标准”哈希表实现（包括大多数高级语言的标准库）都具有所有这些功能。我正在寻找的是针对第一个列表中的操作进行优化的实现。

常见实施的问题：

• 大多数哈希表实现都使用单独的链接（即每个存储桶的链接列表。）这有效但我希望能够占用更少内存并具有更好的引用位置的东西。注意：我的密钥很小（每个13个字节，填充到16个字节。）
• 大多数开放式寻址方案对我的应用程序都有一个主要的缺点：密钥被删除并以大组替换。这留下了删除标记，增加了负载因子，需要经常重建表。

有效但不太理想的方案：

• 每个桶与数组（而不是链表）分开链接：
  由于小数组被重新分配多次，因此内存碎片导致参考局部性差，
• 线性探测/二次散列/双重散列（有或没有布伦特变化）：
  表快速填满删除标记
• Cuckoo哈希
  仅适用于<50％的负载系数，我想要一个高LF来节省内存并加快迭代速度。

是否有专门的散列方案可以适用于这种情况？

---

注意：我有一个很好的哈希函数，适用于2的幂和素数表大小，并且可以用于双重哈希，所以这不应该是一个问题。

Answer 1

Extendable Hashing会有帮助吗？通过走“目录”来迭代键应该很快。不确定使用此方案的“修改键值”操作是否更好。

Answer 2

根据您访问数据的方式，使用哈希表真的有意义吗？

由于您的主要用例涉及迭代 - 排序列表或btree可能是更好的数据结构。

看起来你真的不需要为哈希表构建的常量时间随机数据访问。

Answer 3

使用布谷鸟散列可以比50％的负载因子做得更好。

两个带有四个项目的哈希函数可以轻松实现90％以上。见本文：

http://www.ru.is/faculty/ulfar/CuckooHash.pdf

我正在使用cuckoo哈希构建一个预先计算的字典，并使用两个哈希函数和每个存储桶七个项目获得优于99％的加载因子。