1)为了实现真正的低哈希冲突,我是否可以使用sha1的128位中的一半而不是处理sha1本身？我知道这不适用于加密哈希,但我只需要哈希表键的哈希.
2)计算时间不是优先考虑的事项,除此之外我还要挖掘非常小的数据.特别是,我主要是采用2或3个64位哈希并对它们进行散列以获得另一个64位哈希值.为此目的,有比sha1更好的选择吗？同样,碰撞应该是不太可能的.
3)我是一个新手.在sql中使用64位哈希作为id是一个好主意吗？64位id是否会导致sqlite或postgres出现性能问题？我将需要跨多个数据库协调数据(包括Lucene索引),所以我认为我应该直接在表中处理哈希,而不是打扰自动递增的id(这只会在一个数据库中有意义,而不是跨所有数据存储).我认为64位是一个很好的折衷方案:足够大,不可能发生冲突但节省空间(和查找时间？).
4)CRC-64怎么样？这会产生足够随机的分布吗？
如果你有足够的记录,几乎可以肯定你永远不会有64位的哈希冲突.可能你会属于这一类.
有应与修剪下来的加密哈希像SHA1没有问题的,因为如果在哈希是内部结构,那么它是不够好是一个加密散列,如果没有结构,那么该位的任何子集应该是相当随意.请注意,我只是在讨论将其用于ID,而不是用于任何加密目的!
但实际上,你的SQL是不是有某种GUID？如果确实如此,为什么不使用它呢？