我將跟蹤潛在的數百萬個不同文件的不同版本，我的意圖是對它們進行散列以確定我已經看到了該文件的特定版本。目前，我只使用MD5（該產品仍處於開發階段，因此它從未處理過數百萬個文件），顯然這不足以避免衝突。使用散列跟蹤文件的唯一版本
但是，這裏是我的問題 - 如果我使用兩種不同的方法散列文件並存儲散列（比如SHA1和MD5），或者如果我選擇單個較長的散列（比如SHA256）並依靠這一點？我知道選項1有288個散列位，而選項2只有256個，但假設我的兩個選擇是相同的總散列長度。
因爲我正在處理潛在的數百萬個文件（以及這些文件的多個版本），所以我想盡我所能避免衝突。但是，CPU時間不是（完全）免費的，所以我對社區感覺如何權衡感興趣 - 將更多的位添加到我的哈希計算比較昂貴的計算中，並且對於多個不同的哈希值是否有優勢到一個單一的，更長的散列，在兩個解決方案中給定相同數量的位？
對於文件版本跟蹤，我想不同的文件之間的衝突是不是關心。對於每個文件，您使用散列來確定該文件是否更改以及是否僅更改了該文件。該文件的散列是否與不同的文件相沖突是不相干的，不是嗎？
編輯：你正在應用散列作爲優化，以避免比較每個新文件數以百萬計的現有文件。碰撞不是避免使用快速散列的理由。只要通過存儲文件的新版本來處理碰撞情況（如果它發生的話）。兩種哈希方案都將提供優化。爲什麼過度優化可能不會發生的事情。如果你有一個超級快速散列，它會在1000000中發生1次碰撞。這對於加密技術來說並不好，但對於版本控制來說可以。
即使使用GUID，系統也會檢測衝突並處理它們。系統不需要針對統計上從未發生的事情進行優化。
我想過很多事情都是爲了解決這個問題，並且我建議使用SHA256來保持安全（速度較慢，但CPU應該仍能保持）。我不知道這是否會顯着削弱散列強度，但是您可能想要在16MB塊之間加上散列（例如），然後在末尾散列散列，以便可以並行化。
我學到了一大堆用大量文件和哈希處理的教訓：在一次坐席中向PostgreSQL數據庫添加數百萬條記錄的速度並不是很快。當我編寫一個程序來散列一百萬個文件並將它們存儲在PostgreSQL數據庫中時，數據庫往往是瓶頸。我沒有嘗試MySQL，但我猜測它大致相同。由於沒有客戶端/服務器開銷，SQLite可能要快得多。我建議先嚐試SQLite。它可能太慢了。
另外，如果你存儲百萬個文件通過散列到一個目錄中，失去索引文件，這是一種很難找到的東西:)
如果兩個文件具有相同的哈希但不同，文件跟蹤器將不知道它們是不同的，並可能最終刪除其中一個文件，導致數據丟失（無論如何）。 – 2010-03-13 05:36:17
如果這是一個問題，那麼散列函數是不合適的。 – codenheim 2010-03-13 05:52:14
我很擔心不同文件之間的衝突 - 無論它是什麼名稱，我想確定一個文件是否已經被網絡上其他人備份。我想我的問題是減少碰撞風險的最佳方法。 – SqlRyan 2010-03-13 21:09:29