2012-11-30 9 views
2

파일 용 해시 계산과 관련된 프로젝트를 진행 중입니다. 프로젝트는 파일 백업 서비스와 같습니다. 따라서 파일이 클라이언트에서 서버로 업로드되면 해당 파일이 이미 서버에서 사용 가능한지 확인해야합니다. 파일에 대해 CRC-32 해시를 생성 한 다음 서버에 해시를 전송하여 이미 사용 가능한지 확인합니다.대용량 파일 및 512KB 청크에 대한 가장 빠른 및 LightWeight 해시 알고리즘 [C, Linux, MAC, Windows]

파일이 서버에 없으면이 파일을 512KB 청크 [Dedupe 용]로 보내는데이 512KB 청크에 대해 해시를 계산해야합니다. 파일 크기는 때때로 몇 GB 정도일 수 있으며 여러 클라이언트가 서버에 연결합니다. 그래서 파일에 Fast와 LightWeight Hashing 알고리즘이 필요합니다. 어떤 아이디어 ..?

P.S : 이미 StackOverflow에서 몇 가지 해싱 알고리즘 질문을 발견했지만, 해답은 이러한 종류의 작업에 정확히 필요한 해싱 알고리즘을 비교하지 않았습니다. 나는 이것이 많은 사람들에게 정말로 유용 할 것이라고 확신한다.

+0

파일에 대해 "해시 체인"을 미리 계산하려는 것처럼 들리므로 * 마지막 * 청크가 있고 마지막 해시가 추가 된 두 번째 - 마지막 청크가 해시되는 등의 효과가 있습니다. 첫 번째 청크와 두 번째 해시의 해시 만 배포하십시오. 미리 계산되기 때문에 해시에 걸리는 시간이 주요 관심사가 아닐 수도 있습니다. –

+0

그 덩어리는 독립적이며 전체 파일에 덩어리를 결합해야합니다. 클라이언트에서 데이터를 다시 수신하는 동안. 덩어리를 계획하고 있습니다. 덩어리의 해시가 이미 존재하는 것처럼 중복 제거를 계획하고 있습니다. 청크를 클라이언트에서 서버로 보내지 않아도됩니다. –

+0

스트림 프로세서에 잘 맞는 알고리즘을 사용하여 파일의 512K 덩어리를 처리하는 것처럼 보이는 것은 GPU의 작업입니다. CRC32는 너무 기본적인 것입니다. MD5를 살펴보십시오 (그러나 GPU를 사용하면 무차별적일 수 있습니다 ... 아이러니). – ActiveTrayPrntrTagDataStrDrvr

답변

2

실제로 CRC32는 최상의 속도도 아니고 최상의 분배도 없습니다.

이것은 예상됩니다 : CRC32는 오늘날의 표준에 의해 상당히 오래된 것으로, CPU가 32/64 비트가 아니거나 OoO-Ex가 아닌 시대에 만들어졌으며 배포 속성도 오류 감지보다 중요하지 않았습니다. 이러한 요구 사항은 모두 변경되었습니다.

해시 알고리즘의 속도와 배포 특성을 평가하기 위해 Austin Appleby는 우수한 SMHasher 패키지를 만들었습니다. 결과 요약은 presented here입니다. QScore가 10 (완벽한 분포) 인 알고리즘을 선택하는 것이 좋습니다.

0

CRC-32를 사용하고 있지만 더 빠른 해시를 원한다고 가정 해보십시오. CRC-32는 매우 기본적이고 매우 빠릅니다. I/O 시간이 해시 시간보다 훨씬 길 것이라고 생각합니다. 충돌이 발생하지 않는 해시도 필요합니다. 두 개의 다른 파일 또는 512 KB 청크가 동일한 해시 값을 얻습니다. MD5 (보안 응용 프로그램에는 사용하지 않음) 또는 SHA1과 같은 암호화 해시를 살펴볼 수 있습니다.

+0

내가 인터넷 검색을하는 동안, 어떤 사람들은 CRC를 사용하지 말라고 말하고있다. 그래서 나는 그 다음 최선의 대안을 찾고있다. –

0

CRC-32 만 사용하여 파일이 중복되었는지 확인하는 경우 서로 다른 파일이 동일한 crc-32를 가질 수 있으므로 잘못된 중복을 얻게됩니다. 당신은 sha-1, crc-32 및 md5를 모두 사용하는 것이 좋지 않습니다.