hash - 使用哈希跟踪文件的唯一版本

Question

我将跟踪可能数百万个不同文件的不同版本，我的目的是对它们进行散列，以确定我已经看到了该文件的特定版本。目前，我只使用 MD5(该产品仍在开发中，因此从未处理过数百万个文件)，这显然不足以避免冲突。

但是，这是我的问题 - 如果我使用两种不同的方法对文件进行散列并存储两个散列(例如 SHA1 和 MD5)，或者如果我选择一个更长的散列(如 SHA256)并仅依赖于它，我是否更有可能避免冲突？ 我知道选项 1 有 288 个散列位，选项 2 只有 256 个，但假设我的两个选择的总散列长度相同。

由于我可能要处理数百万个文件(以及随着时间的推移这些文件的多个版本)，我想尽我所能避免冲突。但是，CPU 时间不是(完全)免费的，所以我对社区对权衡的看法很感兴趣 - 向我的哈希添加更多位的计算成本按比例增加，并且多个不同的哈希是否有任何优势，而不是在两个解决方案中给定相同数量的位，到单个更长的散列？

Answer 1

我已经对这个问题进行了大量的思考和处理，我建议使用 SHA256 以保持安全(它较慢，但 CPU 仍应设法跟上)。我不知道这是否会显着削弱散列强度，但您可能希望将散列分成 16MB 块(例如)，然后在最后散列散列，以便您可以并行化。

我在玩弄大量文件和散列时学到的一个教训是:一次性将数百万条记录添加到 PostgreSQL 数据库并不是很快。当我编写一个程序来散列一百万个文件并将它们存储在 PostgreSQL 数据库中时，数据库往往是瓶颈。我没有尝试 MySQL，但我推测它大致相同。 SQLite 可能要快得多，因为没有客户端/服务器开销。我建议先尝试 SQLite。也可能太慢了。

此外，如果您通过哈希将一百万个文件存储到一个目录中并丢失了索引文件，则很难找到东西:)