Плоская или вложенная структура каталогов для кэша изображений?

Question

В моем приложении 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 количество файлов в каталоге?В некотором смысле быстрее получить их с диска?Это сделало бы код, используемый для вычисления имени файла, более сложным, поэтому я хочу выяснить, есть ли для этого веские причины.

Answer 1

В некоторых файловых системах (и я считаю, что HFS + тоже) слишком большое количество файлов в одном каталоге приведет к проблемам с производительностью.

Раньше я работал в интернет-провайдере, где они разбивали домашние каталоги (их было более 90 тысяч), используя схему из нескольких каталогов. Вы можете разделить ваши каталоги, используя, скажем, первые два символа UUID, затем вторые два, например:

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

Таким образом, вам не нужно вычислять какие-либо дополнительные символы или коды, просто используйте те, которые у вас уже есть, чтобы разбить его. Поскольку ваши UUID будут отличаться каждый раз, этого должно быть достаточно.

Answer 2

Как уже упоминалось, в некоторых файловых системах для открытия файла ОС требуется больше времени, поскольку один каталог с большим количеством файлов читается дольше, чем пара коротких каталогов.

Однако вы должны выполнить измерения в вашей конкретной файловой системе и для вашего конкретного сценария использования.Я сделал это для NTFS в Windows XP и с удивлением обнаружил, что плоский каталог работает лучше во всех видах тестов, чем в иерархической структуре.

Answer 3

Основная причина в том, что в последнем случае, как вы упомянули, извлечение диска происходит быстрее, потому что ваш каталог меньше (поэтому ФС будет искать в меньшей таблице файл, который существует).