我将跟踪可能数百万个不同文件的不同版本，我的目的是对它们进行散列以确定我已经看到了该文件的特定版本。目前，我只使用 MD5（该产品仍在开发中，因此尚未处理过数百万个文件），这显然不够长，无法避免冲突。
然而，这是我的问题 -如果我使用两种不同的方法对文件进行哈希处理并存储这两种哈希值（例如 SHA1 和 MD5），或者如果我选择一个更长的哈希值（例如 SHA256）并单独依赖它，我是否更有可能避免冲突？我知道选项 1 有 288 个哈希位，而选项 2 只有 256 个，但假设我的两个选择的总哈希长度相同。
由于我正在处理潜在的数百万个文件（以及随着时间的推移这些文件的多个版本），我想尽我所能来避免冲突。然而，CPU 时间并不是（完全）免费的，所以我感兴趣的是社区对这种权衡的看法 - 向我的散列中添加更多位的计算成本是否会按比例增加，以及多个不同散列相比是否有任何优势给定两个解决方案中相同位数的单个、更长的散列？
我对这个问题进行了很多思考和摆弄，为了安全起见，我建议使用 SHA256（它速度较慢，但 CPU 仍应能够跟上）。我不知道这是否会显着削弱哈希强度，但您可能希望将哈希值打包在 16MB 块中（例如），然后在最后对哈希值进行哈希处理，以便可以并行化。
我在处理大量文件和哈希时学到的一个教训是：一次性向 PostgreSQL 数据库添加数百万条记录并不是很快。当我编写一个程序来哈希一百万个文件并将它们存储在 PostgreSQL 数据库中时，数据库通常是瓶颈。我没有尝试MySQL，但我推测它大致相同。 SQLite 可能要快得多，因为没有客户端/服务器开销。我建议首先尝试 SQLite。也可能太慢了。
另外，如果您通过散列将一百万个文件存储到一个目录中并丢失了索引文件，则很难找到东西:)
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
