哈希式保存与增量之间的设计优势是什么？

Question

jsfiddle和tinyurl等网站不按增量顺序保存。这有什么好处吗？

如果它是随机字符串或散列，这不会很慢，因为首先你必须检查这样的条目是否已经存在，如果是，那么创建一个新的on并重复。

增量不是那么高效和直观吗？

Answer 1

以增量顺序保存肯定更快。但是，如果您的阵列目前有10亿个元素，您添加了10亿个条目，并删除了9.5亿个条目，您可能希望重用空间而不是再次增加阵列的大小。无论你有多少记忆，总有一天你会用完。使用一个好的哈希表，您可以轻松地保存相同数量的数据，使用一个您永远不需要调整大小的1亿个元素阵列。

哈希表确实需要一个好的算法来开发哈希码。如果它们的大小发生巨大变化，它们可能会浪费空间或导致重复分配大型阵列（这会严重惹恼垃圾收集器）。但它们很快，检查重复是一个简单的索引操作。可以在小型链接列表中处理少量重复项，这些列表非常快。如果你能猜出哈希表的初始大小，它确实有用。

我总是喜欢基于二叉树的“地图”或“词典”。它们速度较慢，但​​更灵活，不使用大型阵列;内存以小的，可管理的位分配和释放。它们可以处理大小/使用量的大幅波动。您不需要值得信赖的哈希码生成器。但是如果你知道你的数据，哈希表通常会更好。

Answer 2

外人并不总是能够区分哈希和顺序密钥。应用程序完全有可能在内部使用某种形式的顺序ID，但在将其暴露给外部世界之前对其进行加密。通常不应依赖这些方法来为可能试图“猜测”ID代码的攻击者提供很大的安全性（他们基本上代表“通过默默无闻的安全性”）但至少他们可以阻止人们基于以下事实采取行动：网站似乎以某种特定的方式分配ID。例如，一个站点可能从一个使用顺序ID的服务器开始，但可能会切换到有两个服务器，其中一个顺序分配奇数，另一个顺序分配偶数（两个服务器从最高的数字开始到达由单个服务器分配）。如果序列ID已经暴露给外界，那么某些站点可能已经编码，假设ID编号表示按时间顺序排列。即使是一些简单的事情，例如将ID乘以一些大常量（忽略溢出），xor'ing一些值，并乘以一些其他常量将产生ID，这可以很容易地被知道该方法的人转换回序列号，但是哪个会阻止任何关于订购的假设。

Answer 3

如果底层结构是哈希表，则检查是否存在条目可以在恒定时间内完成，所以根本不会很慢。