这个可扩展的散列解决方案有什么问题？答案

【问题标题】：Whats is wrong with this extendible hashing solution?这个可扩展的散列解决方案有什么问题？
【发布时间】：2014-08-22 10:55:06
【问题描述】：

我试图掌握可扩展散列的概念，但我对桶中的值分布感到困惑。

例如：

假设我想从头开始插入 6 个值：17、32、14、50、35、21

作为解决方案会有什么问题：

全局深度 = 2
桶大小 = 2

00[] --> [][]
01[] --> [][]
10[] --> [][]
11[] --> [][]

这是否意味着每个哈希值只有一个值将指向存储桶，所以你增加全局深度？或者这行得通吗？

我了解过程的开始，我只是在这一点上感到困惑。

【问题讨论】：

Bucket 不是数组，可以把它看成一个链表。
'[][]' 只是一个大小为 2 的桶的图形表示法。我不是说它是一个数组
我不明白你的问题，抱歉。哈希的想法是将这些值放入桶中。好的，您已选择 2 位作为值的“哈希”。 14 和 50 将进入同一个桶，17 和 21 也会。你有什么问题？
那么解决方法好吗？我只是对将哪些值放入桶中感到困惑，例如，我认为 01[] 只会在桶中放入一个唯一值而不是多个值。
是的，很好。想象一下，现在您想检查 21 是否在列表中。你得到最后两位 = 01 并立即找到一个桶。接下来，您需要在存储桶中进行搜索。在两个元素之间搜索比在六个元素之间搜索要快。那是你的利润。当然，如果您期望，例如 1000 个元素，您应该增加全局深度。但不是在飞行中。

【解决方案1】：

您提供的解决方案没有任何问题，只是不需要增加全局深度。该解决方案与给定的全局深度完美兼容。

假设我们使用最左边的 2 位选择目录和相应的存储桶。然后，解决方案将如下所示
二进制格式的数字也如下所示

17 - 010001
32 - 100000
14 - 001110
50 - 110010
35 - 100011
21 - 010101

目录 ------------- 存储桶
00-----------> 14 |
01-----------> 17 | 21
10-----------> 32 | 35
11-----------> 50 |

希望这会有所帮助。

【讨论】：

【解决方案2】：

您不应该增加全局深度。散列的整个想法是选择这样的函数，它可以或多或少地平等地将项目放入桶中。

这取决于哈希函数。您可以使用像 md5 这样复杂的东西作为哈希，然后您将在 1 个存储桶中获得 1 个元素，但您并不能真正保证只有 1 个。

因此，一般的实现应该对桶使用二分搜索，并在桶内使用其他一些搜索。您不能也不应该动态更改哈希函数。

【讨论】：