Сохраняет ли много изображений в одном каталоге медленное извлечение изображений?

Ответ 1

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

Точные точки останова, где запускаются основные проблемы, будут варьироваться от типа файловой системы до типа файловой системы, но, в общем, если вы говорите о нескольких сотнях файлов, вам не о чем беспокоиться. Если вы говорите о нескольких тысячах, стоит подумать и, возможно, сделать небольшой бенчмаркинг, чтобы увидеть, как его файловая система и оборудование справляются с этим. Если вы говорите о десятках тысяч файлов, то вам действительно нужно начинать ломать ситуацию. (У меня когда-то был сервер печати Linux/e2fs, где CUPS не удалял свои файлы управления заданиями после завершения печати, и он собрал около 100 000 файлов в одном каталоге. Просто получение списка каталогов заняло полчаса, прежде чем он даже начал отобразить любые имена файлов.)

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

Поскольку у вас будет метка времени, то, что я, вероятно, сделаю, будет помещен в подкаталоги на основе трех последних цифр временной метки. Это будет распределять файлы относительно равномерно в 1000 подкаталогах и должно содержать количество файлов в каждом каталоге достаточно мало. (Использование первых трех цифр приведет к заполнению одного каталога, прежде чем переходить к следующему, а не распределять их равномерно.) Если вы все еще заканчиваете слишком много файлов в каждом подкаталоге (это, вероятно, означает, что вы имеете дело с несколькими миллион загруженных изображений), вы можете добавить второй уровень для предыдущих трех цифр, поэтому upload-1234567890.jpg закончится на/567/890/upload-1234567890.jpg.

Ответ 2

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

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

siteroot
-- uploads
---- a
---- b
---- c
  :
---- z

... и затем сохраните файлы на основе их первой буквы (так что все изображения с именами, начинающимися с "a", попадают в папку "a" ). Вы можете использовать это как два или три суффикса букв (aa, ab, ac, ad..., ba, bb, bc..., zx, zy, zz) и, возможно, иметь иерархию под этим, чтобы вы разделились файлов по нескольким папкам, зависящим от первых четырех символов имени.

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

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

Ответ 3

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

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

Ответ 4

Я часто использую схему следующим образом: добавления /(# Идентификатор% 1000)/img_#id.jpg

Где #id является cc. id (целое число) фотографии, хранящейся в базе данных. Это обеспечивает простую схему, основанную только на идентификаторе фотографии.

Ответ 5

Это зависит от файловой системы. Например, FAT16 имеет тенденцию быть довольно медленным, если в каталоге имеется более 512 файлов. FAT32 и NTFS не имеют одинаковых ограничений, но также работают намного медленнее, если у вас очень большое количество файлов. Даже если вы используете одну из наиболее надежных файловых систем Linux, вы все равно сможете анализировать каталоги быстрее, если они меньше.

Я бы определенно пошел С# 2 - разбивая изображения на каталоги пользователем.

Ответ 6

Я думаю, что подкаталоги в каталоге uploads будут лучшими.

site root
--uploads
----username
------image1.jpg
------image2.jpg
------image3.jpg
----anotheruser
------image1.jpg
------image2.jpg
------image3.jpg
...

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

Плюс, вариант 2 был бы беспорядок.:)