以下约束的最佳数据结构？

Question

以下是我需要的数据结构的一些约束。 看起来没有一个共同的数据结构（我会提到我在下面想到的那些）都很适合这些。 任何人都可以建议一个我可能没有想到的吗？

1. 我需要能够通过无符号整数键执行查找。
2. 要存储的项目是用户定义的结构。
3. 这些指数很稀疏，通常极其如此。 常规数组已经出局。
4. 每个指数的频率将具有非均匀分布，小指数比大指数更频繁。
5. N通常很小，可能不大于5或10，但我不想太依赖它，因为它可能偶尔会大得多。
6. 常数术语很重要。 当N很小时，我需要非常快速的查找。 我已经尝试过通用哈希表，根据经验，它们太慢了， 即使N = 1，也就是说没有冲突 ，可能是因为涉及的间接量很大。 但是，我会接受有关利用所提到的其他约束的专用哈希表的建议。
7. 只要检索时间很快，插入时间就不重要了。 即使O（N）插入时间也足够好。
8. 空间效率并不是非常重要，但重要的是不要只使用常规数组。

Answer 1

当N很小时，带有键+值作为有效载荷的简单数组或单个链表非常有效。 即使N变大也不是最好的。

您获得O（N）查找时间，这意味着查找需要k * N时间。 AO（1）查找需要恒定的K时间。 因此，对于N < K/k使用O（N）可以获得更好的性能。 这里k非常小，所以你可以得到N的有趣值。请记住，Big O符号只描述大 N的行为，而不是你所追求的。 适用于小桌子

void *lookup(int key_to_lookup)
{
  int n = 0;
  while (table_key[n] != key_to_lookup)
    n++;
  return table_data[n];
}

可能很难被击败。

对哈希表，平衡树和简单数组/链表进行基准测试，看看它们各自的N值开始变得更好。 然后你会知道哪个更适合你。

我差点忘了：将经常访问的密钥保存在数组的开头。 鉴于您的描述意味着保持排序。

Answer 2

这个建议假设现代cpus：

• 快速缓存
• 与时钟速度相比，内存延迟要慢得多。
• 合理的分支预测（在最新的桌面/服务器处理器中确实惊人）

我认为混合结构可能胜过单一结构。

使用基于简单数组的键值对和O（N）访问，如上所述，但非常低的常数因子和非常好的缓存行为。 这个初始结构应该很小（可能不大于16，可能不是8个值），以避免超出单个缓存行。 遗憾的是，您需要调整自己的参数。

一旦你超越了这个数字，你就会想要回到一个具有更好的O（N）行为的结构，我建议尝试一个合适的哈希表开始，因为这可能是合理的从16 - 几千范围，如果你往往会查找类似的值往往更容易留在更快的缓存中。

如果你也删除以及插入，你必须注意不要在两个状态之间来回晃动。 要求计数缩减到“升级”到二级结构的截止值的一半应该可以防止这种情况，但请记住，任何确定性的交叉行为都会受到最坏情况表现输入的影响。
如果您尝试防御恶意输入数据，这可能是一个问题。 如果是这样，在决策中使用随机因素可以防止它。 你可能不关心这个，因为你没有提到它。

如果您愿意，可以尝试对初始主数组进行排序，允许二进制搜索，即O（log（N）），但代价是更复杂的搜索代码。 我认为简单的数组行走实际上会击败它，但是你想要对N的不同值进行基准测试，它可能会让你坚持使用主数组更长时间，但我认为这是大小的函数高速缓存行大小超过O（N）行为。

其他选择包括：

• 不同地处理所有键值<256并将它们存储在一个字节中->结构对数组保存键上的空间（并且可能允许它们在切换到二级结构时保留在那里）这可能会因为需要而导致严重不良将数组解压缩到本机字长。
• 使用类似于trie的结构在键的某个时间执行一个字节。 我怀疑这种复杂性会使它在实践中表现良好

我将再次重复kmkaplan的非常好的建议。 彻底测试它，避免使用微基准测试。 在这种分析中，实际数字可能与理论有惊人的不同......

Answer 3

哈希表查找的速度与它一样快：

唯一区别于常规数组查找的是散列的计算和（如果你的散列函数足够好，或者你在插入过程中花了足够的时间来生成最佳散列函数，这将使你的插入取O（N） ）然后基本上是一个数组查找。

基本上，因为它可能发生（除非你使用最佳散列函数），你必须重新散列或遵循一个非常小的链表。

由于用于散列表的大多数散列函数都是k * c_1％c_2，因此在相当稀疏和/或最优的散列表中与数组查找的差异包括一个间接，两个乘法，一个减法和一个除法（一个有效的模数实现）使用cpus功能可以减少通过减法和乘法）和数组查找。

它根本不会比这更快。

Answer 4

您可能尝试结合两者的优点：如果密钥很小，则将其放入类似于数组的数据结构中，该结构不会比预定义的最大密钥大。 如果密钥很大，请将其放入哈希表中。

Answer 5

对于所描述的问题，我能看到的唯一解释是散列函数太复杂了。 我倾向于采用两阶段方法：

1）对于小键，一个简单的指针数组。 没有哈希或任何东西。

2）对于大于您分配的表大小的键：

如何将一个非常简单的散列函数展开聚集键：

左边5位（假设是32位整数。如果是64位则再加一位。）是实际包含数据的位数，其余的只是数据的总和（丢弃进位）原始密钥切割成您正在使用的多个位的块并添加到一起。

请注意，有效位数可以部分预先计算 - 构建64k高位值表。 如果高阶字非零，则将其用作表的索引并添加16，否则使用低阶字作为索引。 对于64位整数，您显然必须使用4步而不是2步。

Answer 6

你可以考虑Judy Arrays ：

Judy是一个C库，它提供了一种实现稀疏动态数组的最先进的核心技术。 Judy数组只用空指针声明。 Judy数组仅在填充时消耗内存，但如果需要可以增长以利用所有可用内存... Judy可以替换许多常见的数据结构，例如数组，稀疏数组，哈希表，B树，二叉树，线性列表，跳过列表，其他排序和搜索算法以及计数功能。

Answer 7

我会考虑使用自平衡二叉树而不是简单链接来处理哈希冲突的哈希表。 您应该可以通过O（1）摊销查找所有密钥和O（logN）的最坏情况查找。 由于您的密钥分配是偏斜的，因此您可能会遇到索引值较低的冲突，并且树查找将真正得到回报。

Answer 8

如果你的N通常很小，你可以尝试使用二次探测而不是单独链接的开放地址哈希。 如果你得到罕见的N超过它的情况，你需要从初始大小32重新分配到更大的宽度。 如果您可以使整个结构适合几个缓存行，则线性探测或布谷鸟散列将为您提供良好的性能。

老实说，即使是标准的哈希表也给你如此悲惨的表现，我感到很惊讶。 也许你可以分析一下它是什么让它如此慢 - 如果它是哈希函数本身，使用一个简单的就像二次幂模数（例如，键和（N-1）其中N是已知的是2 ^ x）无论如何都会支持以0为中心的分布。 如果是追逐单独链的dcache miss，请编写一个实现，将存储桶中每个存储桶中的前四个元素存储起来，这样您至少可以快速获取它们。 N = 1有多慢？

我将存储指针存储在结构中而不是存储桶中的结构本身：如果结构很大，那么走它们的链就会有很多缓存未命中。 另一方面，您可以在单个缓存行上容纳大约16个键/指针对，并且只有在找到正确的元素时才支付未命中。

Answer 9

这是散列函数的一般概念。 你说插入物可能很昂贵。

使用简单模数散列键，这是一个整数，与哈希表的每个实例一起存储

如果插入会导致冲突，请通过计算合理范围内每个模数可能发生的冲突次数来重新优化哈希表，例如，地图中元素的数量通过其中的常量倍数。

显然，你的插入实际上变得相当昂贵，如果你最小化分配，大约是O（n ^ 2），但你可能能够用单个整数除法和单个指针间接实现查找，你知道，因为你在插入时间，最坏情况查找将是什么。

Answer 10

我会在这里推荐一个Skip列表 。 如果你进入那个java.util.concurrent包有一个很好的实现。