2011-06-16 88 views
3

我的Mac應用程序保持一個對象(包含核心數據)的集合,每個對象都有一個封面圖像,創建時我將其分配給一個UUID。我原本一直將封面圖像作爲字段存儲在我的Core Data存儲中,但最近開始將它們存儲在文件系統中的磁盤上。圖像緩存的平面或嵌套目錄結構?

最初,我將這些封面存儲在一個平面目錄中,使用UUID命名文件,如下所示。這讓我O(1)抓取,因爲我知道究竟在哪裏看。

... 
/.../Covers/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg 
/.../Covers/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg 
... 

我看的方式與其它應用程序處理這個任務,不過,注意到一個多層次的方案,如下(例如)。這仍然可以在O(1)時間內實施。

... 
/.../Covers/A/B/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg 
/.../Covers/C/D/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg 
... 

可能是這樣做的原因是什麼? OS X是否限制目錄中文件的數量?從磁盤檢索它們的速度有些快嗎?這會使用於計算文件名的代碼更加複雜,所以我想知道是否有這樣做的好理由。

回答

3

在某些文件系統上(我也相信HFS +),在同一目錄中有太多文件會導致性能問題。

我曾經在一個ISP中工作,他們將打破主目錄(他們有90k +)使用多目錄方案。您可以通過使用,比方說,前兩個字符的UUID,那麼後兩個分區的目錄,如:

/.../Covers/3B/72/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg 
/.../Covers/6B/EC/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg 

這樣,你不需要計算任何額外的字符或代碼,只需使用你已經打破了。由於你的UUID每次都會有所不同,這應該就足夠了。

+0

謝謝,我一直在思考這些問題。我將UUID設置爲'NSMutableString',然後在前兩位和後兩位字符後面插入'/',所以現在我的文件名也縮短了4個字符。 – Dov 2011-06-16 12:44:39

+0

雖然有太多的處罰可以分解嗎?使用2個2位十六進制數字目錄的方案每個意味着創建至多256^2個目錄,這意味着(假設均勻分佈)每個文件實際上都有自己的目錄。 – Dov 2011-06-16 12:56:06

+0

這取決於您計劃存儲多少個文件,但是,您可以從1位開始,然後如果數量太大,請使用第二位數字創建子目錄,依此類推。 – Clinton 2011-06-16 13:07:07

2

最主要的原因是在後一種方式中,正如你所提到的,磁盤檢索速度更快,因爲你的目錄較小(所以FS會在較小的表中查找文件)。

+0

所以,要清楚,從一個具有更多內容的目錄中讀取文件需要更長的時間? – Dov 2011-06-16 12:21:52

+0

不需要。操作系統需要較長時間才能確定該目錄中是否存在文件。一旦你得到文件句柄,讀/寫時間應該是相同的。 – 2011-06-16 12:23:05

2

正如其他人提到的,在某些文件系統上,操作系統打開文件需要更長的時間,因爲一個包含多個文件的目錄比兩個短目錄要長。

但是,您應該針對特定的文件系統和特定的使用場景執行測量。我在Windows XP上爲NTFS做了這個工作,並且驚訝地發現平面目錄在各種測試中的表現都比分層結構更好。