Замедляет ли хранение большого количества изображений в одном каталоге поиск изображений?

Question

Если у меня есть сайт, на котором пользователи могут загружать столько изображений, сколько они хотят (например, как в фотобакете), как лучше всего настроить хранилище файлов (кроме того, все загрузки получают уникальную временную метку)?

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

или

siteroot
--uploads
----image1.jpg
----image2.jpg
----image3.jpg
----image4.jpg
----image6.jpg
...
----image50000.jpg

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

--- редактировать ---

Спасибо за великолепные ответы. Кроме того, я буду создавать миниатюры, поэтому мне также нужно будет вставить этот каталог куда-нибудь ... или , создать соглашение об именах, например thumb_whwhat.jpg.

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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