Быстрее ли иметь больше файлов в меньшем количестве папок или больше папок с меньшим количеством файлов?

Question

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

Генератор будет написан на C ++, а файлы будут доступны напрямую через GET-запросы.

Спасибо, Стив

Answer 1

С точки зрения скорости, управляемости и т. Д. Используйте больше папок.Если вы изучите несколько больших приложений, то, как правило, они разбивают файлы на несколько папок.Большинство приложений и / или файловых систем не любят слишком много файлов в одной папке.С точки зрения программистов, это не имеет значения.

Answer 2

@ dmckee Нет кликов, так как все изображения загружаются автоматически. Подумайте, картографическое программное обеспечение.

@ Брайан Агнью Он будет работать / обслуживаться в какой-то облачной среде Linux. Я не специалист по информационным технологиям, я просто программист. Но он определенно будет масштабирован до нескольких машин.

@ Onkelborg Я согласен. Я склонялся к тому, чтобы использовать больше папок и меньше файлов. Я думаю, что макет будет что-то вроде ...

комплект / увеличение уровня / колонки / row.jpg

Я хотел использовать структуру имени файла / директории для извлечения файлов без запроса к серверу. Если мы увеличиваем в пять раз, и верхняя левая координата этого увеличенного изображения составляет 25 600 x 15 360, учитывая квадратную плитку 256 пикселей, некоторая базовая математика выдаст мне этот URL:

2389/5 / 20 / 12.jpg

Где "2389" - это идентификатор набора плиток. Таким образом, вы можете видеть, что изображения будут храниться только в каталогах глубиной в три уровня. Каталоги с изображениями могут содержать от 4 до 100 изображений в зависимости от уровня масштабирования. Или, может быть, от десятка до нескольких сотен (с чуть меньшим количеством папок), если пойти по этому пути ...

комплект / масштабирование уровня / строки / column.jpg

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

Поскольку я написал это, я думаю, что я понимаю, что первый макет - это, вероятно, путь. Меньше элементов для итерации, чтобы найти запрошенный файл. Я просто думаю о фрагментации, но думаю, что это будет работа ИТ. ;)

Answer 3

Вещи, которые приходят на ум:

Pro "меньше папок"

• Каждая папка для навигации означает еще один щелчок для пользователя и еще одно отставание во время загрузки страницы.
• Если пользователь собирается перемещаться по всем (или большой части дерева), то все эти дополнительные файлы - это просто еще много байтов для отправки.Это тривиально по сравнению с итогом, если вы не доведите стратегию «много папок» до крайности, но она предполагает, что где-то есть предел.

Pro «больше папок»:

• Длинные списки содержимого каталога вынуждают пользователя прокручивать, вводить текст вперед или иным образом взаимодействовать с находить конкретный файл вместо , выбирая , так как они могут быть приняты вКраткий обзор страницы.
• Пользователь, щелкающий по папке Foo, должен дождаться загрузки всех элементов в этом каталоге, прежде чем страница завершит рендеринг.Это может быть ощутимой задержкой и большим количеством байтов для пользователя, которому нужно только одно изображение.
• Каждый доступ к элементу в каталоге занимает некоторое время.В старомодных файловых системах это часто было операцией O (n).Более новые файловые системы поддерживают доступ O (ln (n)).Как это повлияет на оптимальную работу вашей системы, зависит от производительности файловой системы, которую вы планируете использовать.Также обратите внимание на обычный вариант использования (который, я полагаю, рассматривает небольшое количество каталогов, а не охватывает все дерево, не так ли?).

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

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

Answer 4

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

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