Структура каталога кэша

StackOverflow https://stackoverflow.com/questions/616099

  •  03-07-2019
  •  | 
  •  

Вопрос

Я нахожусь в процессе внедрения кэширования для своего проекта.Посмотрев на структуры каталогов кэша, я увидел много примеров, таких как:

cache
cache/a
cache/a/a/
cache/a/...
cache/a/z
cache/...
cache/z
...

Вы уловили идею.Другой пример хранения файлов, допустим, наш файл имеет имя IMG_PARTY.JPG, распространенный способ - поместить его в каталог с именем:

files/i/m/IMG_PARTY.JPG

Некоторые мысли приходят в голову, но я хотел бы знать истинные причины этого.

  • Файловые системы, выполняющие линейный поиск, быстрее находят файлы, когда их меньше в каталоге.Такая структура тонко распределяет файлы.

  • Чтобы не испортить * утилиты nix, такие как rm, которые принимают конечное число аргументов и удаляют большое количество файлов одновременно , как правило, сложно (хотя приходится передавать это find и т.д.)

Какова настоящая причина?Что такое "хорошая" структура каталогов кэша и почему?

Это было полезно?

Решение

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

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

Другие советы

Просто используйте даты.Так как вы будете удалять по дате.:)

Если вы это сделаете ls -l, все файлы должны быть stat()редактируется для получения подробной информации, что значительно увеличивает время листинга - это происходит независимо от того, использует ли FS хэшированные или линейные структуры.

Таким образом, даже если FS способна справляться с невероятно большими размерами каталогов, есть веские причины не иметь больших плоских структур (их также сложно создавать для резервного копирования).

Я сравнил GFS2 (кластеризованный) с 32 000 файлами в каталоге или упорядоченный в виде древовидной структуры - рекурсивные списки были примерно в 300 раз быстрее, чем получение списка, когда все они были в плоской структуре (получение списка каталогов могло занять до 10 минут)

EXT4 показал аналогичные соотношения, но поскольку конечная точка составляла всего пару секунд, большинство людей этого не заметили бы.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top