NTFS目錄有100K條目。 如果分布在100個子目錄上，性能會提升多少？

Question

上下文我們有一個自行開發的文件系統支持的緩存庫。 由於大量條目（例如，最多100,000個），我們目前在一次安裝時遇到性能問題。 問題是：我們將所有fs條目存儲在一個“緩存目錄”中。 非常大的目錄表現不佳。

我們正在考慮將這些條目分布在子目錄上 - 就像git那樣，例如100個子目錄，每個子目錄大約有1,000個條目。

這個問題

我知道較小的目錄大小將有助於文件系統訪問。

但是“傳播到子目錄”會加速遍歷所有條目，例如枚舉/讀取所有100,000條目嗎？ 即當我們從FS存儲中初始化/加熱緩存時，我們需要遍歷所有100,000個條目（並刪除舊條目）可能需要10多分鍾。

“傳播數據”會減少這種“遍歷時間”。 此外，這種“遍歷”實際上可以/確實刪除陳舊的條目（例如，比N天更早）“傳播數據”會改進刪除時間嗎？

附加上下文 -NTFS -Windows系列操作系統（Server 2003,2008）

-Java J2ee應用程序。

我/我們將感謝文件系統可擴展性問題的任何教育。

提前致謝。

將

ps我應該評論說我有自己測試這個的工具和能力，但我想首先選擇理論和經驗的蜂巢頭腦。

Answer 1

我還相信在子目錄中傳播文件會加速操作。

所以我進行了測試：我已經生成了從AAAA到ZZZZ的文件（26 ^ 4個文件，大約450K）並將它們放入一個NTFS目錄中。 我還將相同的文件放在從AA到ZZ的子目錄中（即按名稱的前2個字母分組文件）。 然后我進行了一些測試 - 枚舉和隨機訪問。 我在創建之后和測試之間重新啟動了系統。

扁平結構暴露的性能略好於子目錄。 我相信這是因為目錄被緩存而NTFS索引目錄內容，所以查找速度很快。

請注意，400K文件的完整枚舉（在兩種情況下）大約需要3分鍾。 這是重要的時間，但子目錄使情況更糟。

結論：特別是在NTFS上，如果可以訪問任何這些文件，將文件分組到子目錄中是沒有意義的。 如果你有一個緩存 ，我還會測試按日期或按域分組文件，假設某些文件比其他文件更頻繁地訪問，並且操作系統不需要將所有目錄保存在內存中。 但是，對於您的文件數量（低於100K），這可能也不會帶來顯着的好處。 我想你需要自己測量這些特定場景。

更新：我已經減少了我的隨機訪問測試，只能訪問一半的文件（從AA到OO）。 假設這將涉及一個平面目錄和只有一半的子目錄（給子目錄案例獎勵）。 仍然平坦的目錄表現更好。 所以我假設除非你有數百萬個文件，否則將它們保存在NTFS上的一個平面目錄中比將它們分組到子目錄中要快。

Answer 2

如果您永遠不需要統計或列出緩存目錄，並且只需要通過完整路徑來統計和打開文件，那么它應該無關緊要（至少不是在100k文件級別）目錄中有多少文件。

在這種情況下，許多緩存框架和文件系統繁重的存儲引擎將根據文件名中的第一個字符創建子目錄，這樣如果您在緩存中存儲文件“abcdefgh.png”，它將進入“cache / a /” b / cdefgh.png“而不僅僅是”cache / abcdefgh.png“。 這假設您的文件名的前兩個字母的分布在字符空間中大致是一致的。

正如您所提到的，由於涉及列出或遍歷目錄的主要任務是刪除過時的文件，我建議您根據文件緩存的日期和/或時間創建目錄，即“cache / 2010/12/04 /22/abcdefgh.png“並且，無論您在哪里索引緩存，請務必按文件名和日期（特別是如果它在數據庫中）對其進行索引，以便您可以從索引中按日期快速刪除項目並刪除相應的目錄。

Answer 3

你是如何加載緩存的？ 如果您正在使用標准的Java文件系統交互，那將是您的第一個瓶頸 - Java在文件夾內容迭代方面非常糟糕 - 如果您在迭代時對每個文件進行檢查（獲取修改日期，請確保文件不是這是一個目錄等......表演可能會受到很大的打擊（這些都涉及到原生地的往返）。 轉向基於本機FindFirstFile的解決方案可能會提供顯着（如數量級）的改進。 FindFirstFile在每個迭代步驟中返回有關該文件的所有信息。 Java File.listFiles（）返回路徑列表。 然后當您查詢屬性或其他元時 - 每個調用都是文件系統的往返。 可怕的是，非常低效。

好的 - 那就不行了。 接下來，NTFS中巨大目錄的原始迭代並不比n-ary樹方法（文件夾和子文件夾等）慢得多。 使用FAT32，這是一個非常大的問題 - 但NTFS處理這種事情非常好。 也就是說，拆分為子文件夾會打開一些自然的並行化機會，而單個文件夾則難以實現。 如果您可以生成10個或15個線程，每個線程都可以訪問單獨的文件夾，那么您可以有效地消除磁盤延遲作為一個影響因素。

我可能會建議您從剖析開始（當然，您已經知道） - 並查看大部分加載時間來自何處。 您可能會感到驚訝（例如，在我們的一個應用程序中執行了大量的文件列表處理，我很震驚地發現在檢查isDirectory（）時我們被擊中了多少時間 - 一個簡單的更改，比如在目錄之前進行日期比較/文件確定使我們的迭代速度提高了30％）。

Answer 4

要查看的是磁盤子系統的排列方式。 雖然磁盤的大小正在快速增長，但它們的速度並不快（訪問時間）是不同的磁盤安排（使用更多磁盤）或使用SSD驅動器的選項。 例如，SSD沒有移動部件，可以在10秒內觸摸100K文件。 不必進行預熱。