Организация тысяч изображений на сервере

Question

Я занимаюсь разработкой веб-сайта, который может вырасти до нескольких тысяч пользователей, и все они будут загружать до десяти фотографий на сервере. Мне интересно, какой будет лучший способ хранения изображений. Предположим, что у меня есть 5000 пользователей с 10 картинками каждый, что дает нам 50 000 фото. (Я думаю, было бы неплохо хранить их в базе данных в blobs;))

Будет ли это хороший способ динамически создавать каталоги для каждых 100 пользователей, зарегистрированных (всего 50 гигабайт, при условии, что 5000 пользователей), и загружать их фотографии там? Будет ли соглашение об именовании «xxx_yy.jpg» (xxx - идентификатор пользователя и номер изображения yy) в порядке? В этом случае, однако, в одной папке было бы 1000 изображений (100x10), разве это не слишком много?

Answer 1

Предоставлено, что я никогда не хранил 50 000 изображений, но я обычно просто храню все изображения в одном каталоге и назову их как таковые, чтобы избежать конфликтов. затем сохраните ссылку в db.

$ext = explode('.', $filename); 
$newName = md5(microtime()) . '.' . $ext; 

Таким образом, у вас никогда не будет одинаковых двух имен файлов, таких как microtime, никогда не будет одинаковым.

Answer 2

Я бы скорее всего сохранил изображения хешем их содержимого. Например, 128-битная SHA. Итак, я бы переименовал загруженное изображение пользователя 'foo.jpg' в его 128-битный sha (возможно, в базе 64 для унифицированных 16-символьных имен), а затем сохранит имя пользователя для файла и его SHA в базе данных , Вероятно, я также добавлю счетчик ссылок. Затем, если некоторые люди загружают одно и то же изображение, оно сохраняется только один раз, и вы можете удалить его, когда все ссылки исчезнут.

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

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

Answer 3

Различные файловые системы работают по-разному с каталогами, содержащими большое количество файлов. Некоторые сильно замедляются. Некоторые вообще не возражают. Например, IBM JFS2 stores the contents of directory inodes as a B+ Tree sorted by filename .... поэтому он, вероятно, обеспечивает время доступа к журналу (n) даже в случае очень больших каталогов.

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

Что бы вы ни делали, не оптимизируйте слишком рано. Просто убедитесь, что ваш механизм доступа к файлам может быть asbstracted (сделайте FileStorage, из которого вы .getfile (id), или что-то ...).

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