【问题标题】:Which datastructure is appropriate for this situation?哪种数据结构适合这种情况?
【发布时间】:2010-11-21 08:09:31
【问题描述】:

当只有需要的功能时,我正在尝试决定使用哪种数据结构来存储键值对

  • 插入
  • 查找

具体来说,我不需要能够删除对,或遍历键/值/对。

键是整数元组,值是指针(引用等)。我只存储了分布在(许多)对象上的几百万对。

目前我正在考虑使用任一

  • 哈希表
  • kd 树
  • b 树

我倾向于哈希表(O(1) 插入/查找时间),但我想确认我的倾向。

您会推荐哪种结构(上述结构或其他结构),为什么?如果您推荐一个哈希表,我应该为每个对象创建一个单独的表,还是只创建一个表并将对象的 id 作为键元组的一部分?

【问题讨论】:

  • kd-tree 是一种空间数据结构——在这种情况下使用它没有任何意义。你是说红黑树吗?
  • 你将如何使用这个数据结构?您是预先完成所有插入,还是将它们与查找混合?您期望多少次查找与插入?键是唯一的吗?有多少个键(2^64?)。它们是如何分布的?

标签: language-agnostic data-structures hashtable b-tree kdtree


【解决方案1】:

哈希表将是这里的最佳选择,因为对您而言重要的所有操作都是 O(1)(因此您不必担心创建多个哈希表)。

【讨论】:

  • O(1) vs O(log n) 放在一边——我(轶事地)读到哈希映射仅在某个 N 以上表现更好,因为该常数足够高以阻止其用于一些案例。几百万对对我来说听起来足够高,但是你有一些数字吗?或者这是否依赖于太多的实现,只有分析才会有所帮助?
【解决方案2】:

我是哈希表的忠实粉丝,因为它们很简单,而且几乎所有主要语言都有可用的实现。 O(1) 插入/查找是一个特别好的功能。

您可能应该使用单个表,以节省内存。众所周知,哈希表在内存方面的效率低下,使用单个表将有助于减少这种情况。

【讨论】:

    【解决方案3】:

    哈希表在这里很有用,我认为没有理由拥有多个表。

    【讨论】:

    【解决方案4】:

    大多数树的查找时间为 O(n ln n),但哈希表的查找时间为 O(1),所以这是您要使用的。这也很常见,而且通常实施高度优化以启动。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-01-06
      • 1970-01-01
      • 1970-01-01
      • 2023-03-10
      • 1970-01-01
      相关资源
      最近更新 更多