使用盐来避免哈希表冲突怎么样？答案

【问题标题】：What about using salt to avoid hash table collision?使用盐来避免哈希表冲突怎么样？
【发布时间】：2014-10-28 09:26:09
【问题描述】：

如果一个键在哈希表中发生冲突，我想通过递归地对键加盐来找到另一个位置，直到找到一个空闲位置（总是使用相同的盐）。

例如：

“bee”和“ant”哈希为 7
我在表格中插入“bee”。
然后当我插入“ant”时，它发生碰撞，我用“！23”加盐“ant”（导致“！23ant”）并再次调用插入（我存储了原始密钥，但使用加盐的密钥得到索引）。

我用这种方法搜索了哈希表，但没有找到任何资料。

这种碰撞处理方法的缺点是什么？

【问题讨论】：

您是否使用固定盐来解决冲突？还是每次都选新盐？
固定盐。在我的例子中，总是字符串 "!23"
遇到二次碰撞怎么办？（顺便说一句，您所描述的技术与许多其他散列策略有关，但我想确保在进入它们之前了解您的系统。）
我递归地加盐键：ant => !23ant => !23!23ant => …（我假设一个散列函数会为键的微小变化产生非常不同的散列）

标签： string hash hashmap hashtable salt

【解决方案1】：

从性能的角度来看，每次哈希冲突都需要您构建一个新字符串，如果您的输入字符串很长，这可能需要很长时间。另请注意，构建此字符串的成本会随着您获得越来越多的哈希冲突而增加，因此成功查找的成本最终取决于您有多少次冲突。

将这种基于盐的方法与其他散列方法进行比较，我怀疑这种额外的成本会使您的系统在实践中比线性探测或双散列等其他技术慢，后者的分布可能不如您的方法那么好，但是不必做太多工作来计算哈希码和构造辅助字符串。

【讨论】：

【解决方案2】：

我看不出这如何解决任何问题。让我们玩一下这样的碰撞：

// Here you would store "bee" and "bug" with the hashes 7 and 8:
"bee" = 7
"bug" = 8

// Here you get a collision and add a "salt":
"bee" = 7
"ant" = 7 -> "!23ant" -> 8

// Depending on the adding order, you can end up with "bug"=8 or with "!23bug=9"
"bee" = 7
"!23ant" = 8
"bug" = 8 -> "!23bug" -> 9

那么，您如何知道是否必须使用“bug”或“！23bug”进行搜索才能获得哈希值。存储这些信息会抵消快速哈希图的优势。

【讨论】：