使用GUID作爲文件夾名稱+拆分

Question

我想使用GUID（uuid）命名文件夾中的大型文件存儲。每個存儲項目都有自己的文件夾和GUID。 最簡單的方法是 「X：\項目\ UUID \ {UUID} ...」
例如： 「X：\項目\ UUID \ F3B16318-4236-4E45-92B3-3C2C3F31D44F ......」

我在這裏看到一個問題。如果您希望至少獲得10,000個物品，並且可能達到100,000或更多，那麼該怎麼辦？我不想將太多的項目（子文件夾）放在一個文件夾中。

我想通過分解導引來解決這個問題。把兩個第一個字符在第一級創建子文件夾，並採取下兩個字符，並創建子文件夾。 上面的例子將是 - >「x：\ items \ uuid \ F3 \ B1 \ 6318-4236-4E45-92B3-3C2C3F31D44F ...」

如果guid的前4個字符的確是隨機的然後我會在256個文件夾中獲得256個文件夾，並且我總是會在這些文件夾中的每個文件夾中產生合理數量的項目 例如，如果您有100萬個項目，則會得到 - > 1 000 000/256/256 =每個文件夾15.25項

在過去，我已經測試了第一個字符的隨機性。 （通過vb.net應用程序）。結果：傳播的項目均勻地放在文件夾上。 也有人得出同樣的結論。見How evenly spread are the first four bytes of a Guid created in .NET?

可能分割我認爲（1萬件爲例） C1 =字符GUID，C2 =角色2的1等

• C1 GUID的\ C2 \休息 - - > 16 * 16 * 3906（幾乎4000個仍然是很多文件夾）
• C1 \ C2 \ C3 \ C4 \ Guid其餘部分 - > 16 * 16 * 16 * 16 * 15（不必要的分割文件夾）
• C1C2 \ C3C4 \ Guid其餘部分 - > 2 56 * 256 * 15（對我來說是最好的選擇嗎？）
• C1C2C3的Guid \休閒 - > 4096 * 244（在第一級多個文件夾？）
的Guid
• C1C2C3C4 \休閒 - > 65536 * 15（！在第一級多個文件夾）

我的問題是：

• 有誰看到缺點的這種實現。 （方案：* C1C2 \ C3C4 \ Guid其餘部分）
• 是否有一些標準來分解Guids，或者一般的做法。
• 如果你把幾百幾千子文件夾的一個文件夾中會發生什麼（我還是不喜歡使用，如果可能的任何分裂）

感謝，Mumblic

Answer 1

這是相當類似的方法git用於分解它的對象數據庫（儘管使用SHA1哈希代替GUID ...）。與任何算法一樣，有優點和缺點，但我認爲在這種情況下沒有任何重大缺點會超過明確的優點。有一點點額外的CPU開銷來計算的目錄結構，但是從長遠來看，這開銷可能比什麼是必要通過一百萬個文件的單個目錄反覆搜索顯著少。

關於如何做到這一點，它取決於您正在使用什麼庫來生成GUID - 你是否得到它們的字節數組（甚至是struct）格式，然後需要將其轉換爲字符代表爲了顯示它，或者你在一個已經格式化的ASCII數組中獲得它們嗎？在第一種情況下，你需要提取適當的字節，自己格式化，第二，你只需要抽取子。

至於投入一個文件夾的子文件夾（甚至是文件）的極端數字，確切的性能在很大程度上取決於實際使用中的文件系統上。一些執行比別人好，但幾乎所有將呈現顯著的性能下降的多個條目的每個目錄了。