Я слишком долго работал над этой проблемой. Я на третьем (и, надеюсь, последнем) переписывании.
Вообще говоря, я рекомендую SHA1, потому что у него нет известных коллизий (тогда как коллизии MD5 можно обнаружить за минуты ), а SHA1 не является узким местом при работе с жесткими дисками. Если вы одержимы стремлением заставить вашу программу работать быстро при наличии твердотельного накопителя, либо переходите на MD5, либо тратите дни и дни своего времени, пытаясь найти способ распараллеливания операции. В любом случае, не распараллеливайте хеширование , пока ваша программа не сделает все, что вам нужно.
Также я рекомендую использовать sqlite3. Когда я сделал хэш-файл моего программного хранилища в базе данных PostgreSQL, вставки в базу данных стали настоящим узким местом. Конечно, я мог бы попытаться использовать COPY (я забыл, если бы я сделал или нет), и я предполагаю, что это было бы достаточно быстро.
Если вы используете sqlite3 и выполняете вставки в блоке BEGIN
/ COMMIT
, вы, вероятно, просматриваете около 10000 вставок в секунду при наличии индексов. Однако то, что вы можете сделать с полученной базой данных, делает все это стоящим. Я сделал это с около 750000 файлов (85 ГБ). Вся операция вставки и хеширования SHA1 заняла менее часа, и она создала файл sqlite3 размером 140 МБ. Однако мой запрос на поиск дубликатов файлов и их сортировку по идентификатору занимает менее 20 секунд.
В целом, использование базы данных хорошо, но обратите внимание на накладные расходы. SHA1 безопаснее, чем MD5, но потребляет примерно в 2,5 раза больше ресурсов процессора. Тем не менее, ввод-вывод является узким местом (процессор занимает второе место), поэтому использование MD5 вместо SHA1 действительно не сэкономит вам много времени.