我正在解析大量网络跟踪数据。我想将跟踪分成块，对每个块进行哈希处理，并存储一系列结果哈希而不是原始块。我工作的目的是识别相同的数据块——我正在对原始数据块进行哈希处理以减少数据集大小以供以后分析。在我的工作中，我们可以权衡偶尔发生冲突的可能性以减小哈希大小（例如，相同块的 1% 错误识别的 40 位哈希可能优于 0.001% 错误识别的 60 位哈希）。
我的问题是，考虑到 a) 要散列的块数和 b) 允许的错误识别百分比，如何选择合适的散列大小？
举个例子：
1,000,000 个要散列的块，我们准备好有 1% 的错误识别（当原始数据中的散列块不相同时，1% 的散列块看起来相同）。我们如何选择满足这一点的最少位数的哈希？
我查看了有关Birthday Paradox 的材料，尽管这特别关注单个 碰撞的概率。我还查看了讨论根据单个碰撞的可接受概率选择尺寸的材料，但无法从中推断如何根据可接受的 n 概率选择尺寸（或更少）碰撞。
【问题讨论】：
标签： hash size probability collision
显然，哈希函数的质量很重要，但一些简单的概率论可能会在这方面对您有所帮助。
问题是您究竟愿意接受什么，是否足以让您在仅 1% 的数据中获得预期的碰撞次数？或者，您是否要求超过某个界限的碰撞次数的概率是什么？如果是第一个，则信封样式计算的背面将执行：
从你的集合中散列到相同事物的预期对数是 (1,000,000 C 2)*P（任何两个都是一对）。让我们假设第二个数字是 1/d，其中 d 是哈希表的大小。 （注意：期望是线性的，所以到目前为止我并没有作弊）。现在，你说你想要 1% 的碰撞，所以总共是 10000。好吧，你有 (1,000,000 C 2)/d = 10,000，所以 d = (1,000,000 C 2)/10,000，根据谷歌的说法大约是 50,000,000。
因此，您需要 5000 万个可能的哈希值。这小于 2^26，因此您将获得大约 26 位散列的所需性能（取决于散列算法的质量）。我可能在某个地方有 2 个错误，所以你知道，它很粗糙。
如果这是一个离线任务，你不能那个空间受限。
【讨论】：
听起来很有趣！
其他人可能有更好的答案，但我会走蛮力路线，只要有足够的时间：
使用增量散列大小运行散列计算并记录每个散列大小的冲突百分比。
您可能希望使用二分搜索来减少搜索空间。
【讨论】：