为python中的大型文件创建校验和的最快方法

Question

我需要通过网络传输大型文件，并需要为它们创建每小时的校验和。所以生成校验和的速度对我来说是至关重要的。

不知何故，我无法让zlib.crc32和zlib.adler32在Windows 64位计算机上处理大于4GB的文件。我想我已经达到32位限制了？使用hashlib.md5，我可以得到一个结果，但问题是速度。生成4.8GB文件的md5大约需要5分钟。任务管理器显示流程仅使用一个核心。

我的问题是：

1. 是否有办法使crc在大文件上工作？比起md5，我更喜欢使用crc。
2. 如果没有，那么是否有一种方法可以加快md5.十六进制()/md5.digest的速度？或者在本例中，任何hashlib十六进制/摘要？也许把它分割成多线程进程？我该怎么做？

PS:我正在做一些类似于“资产管理”系统的工作，有点像svn，但是资产是由大型压缩图像文件组成的。这些文件有一些微小的增量变化。需要散列/校验和来检测变化和错误检测。

Answer 1

首先，CRC算法中没有任何固有的内容会阻止它们处理任意长度的数据(但是，特定的实现很可能会造成限制)。

但是，在一个文件同步应用程序中，这可能并不重要，因为您可能不想在整个文件变得大的时候散列，只是块。如果您散列整个文件，并且每一端的散列不同，则必须复制整个文件。如果散列固定大小的块，则只需复制散列已更改的块。如果对文件的大部分更改都是本地化的(例如数据库)，那么这可能需要更少的复制(并且“更容易在多个核之间传播每块计算)。

至于哈希算法本身，基本的权衡是速度与冲突的缺乏(两个不同的数据块产生相同的哈希)。CRC-32是快速的，但只有2^32的唯一值，可以看到碰撞.MD5要慢得多，但是有2^128的唯一值，所以几乎看不到碰撞(但理论上仍然是可能的)。较大的散列(SHA1，SHA256，.)有更独特的价值，但速度更慢:我怀疑你是否需要它们:你担心的是意外碰撞，而不是数字签名应用程序，你担心的是故意(恶意)设计的冲突。

听起来，您正在尝试做一些与rsync实用程序非常相似的事情。你能用一下rsync吗？

Answer 2

您可能会遇到XP中文件的大小限制。64位为您提供了更多的寻址空间(删除每个应用程序的2GB (大约)寻址空间)，但可能对文件大小问题没有任何作用。

Answer 3

您不可能使用多个核心来计算一个大型文件的MD5散列，因为MD5的本质是:它期望一条消息以块的形式被分解，并按照严格的顺序输入散列函数。但是，可以使用一个线程将文件读入内部队列，然后在单独的线程中计算散列，以便。不过，我不认为这会给你带来任何显著的业绩提升。

处理一个大文件需要这么长的时间，这可能是因为“未缓冲”读取。试着一次读取16 Kb，然后将内容以块的形式提供给散列函数。