Распределение изображений по дирам - а надо ли?

[Василий М.]

Собственно, есть задача - сохранять пользовательские картинки.
Имя изображения - хэш от md5.
Что изначально хотел - брать 2-5 первых символов имени файла и генерировать в основной директории поддиректории с именами первых букв файла. Т.е. перед сохранением файла

931b34a1def01a90f7de2b64b775bcd7.jpg

хотел сначла создавать вложенность директорий
/images/9/3/1/b/3/
и сохранять файл в /images/9/3/1/b/3/931b34a1def01a90f7de2b64b775bcd7.jpg

Теперь самое главное - а зачем так делать? Зачем так делают? В чем плюсы и минусы данного подхода?

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

 

[С.]

Стандартные файловые системы не заточены под слишком большое количество файлов в одной директории.

 

[c0dex]

Сохраняй в одну диру, как попытаешься туда зайти по ftp и он не сможет прочитать листинг, перепишешь.

 

[Breeze]

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

 

[Absinthe]

Сохраняй в одну диру, как попытаешься туда зайти по ftp и он не сможет прочитать листинг, перепишешь.

Предлагаешь устанавливать FTP-сервер для диагностирования этого?

 

[SiZE]

Я как-то делал так. При каждой записи файла в директорию, увеличивал счетчик файлов этой директории. Как только счетчик переваливал, допустим за 1000, создавал новую.

 

[c0dex]

Absinthe
Зачем, оно обычно как бы уже установлено у всех хостеров, надо просто подождать и как-нибудь забыв о кривых руках попытаться туда зайти. Вуаля, вот он и капец...

 

[Adelf]

c0dex
у тебя какой-то шаредхостинговый образ мышления

 

[c0dex]

Adelf
Да у нас просто тут на формуе куча нищебродов последнее время объявилась, которые жмут двадцатку за норм хостинг с рутом %) В общем в моем первом сообщении был легкий сарказм, так что делать так не стоит) Для таких вещей отлично подходит Amazon S3

 

[Adelf]

Я думаю на тему ответили... есть вопрос схожий.
Нужно будет хранить zip файлы(и разумеется отдавать их постоянно юзерам).. и довольно часто компоновать их в другие zip(которые тоже надо будет отдавать). Т.е. брать несколько файлов и соединять их в новый. Нормально для этого будет заюзать Amazon S3? Просто как-то идеологически кажется неправильным гонять туда сюда файлы, которые могут быть обьемными... Хотя для этого можно в самом амазоне замутить машину... Или лучше все-таки у себя на серверах все держать?
Делал кто чего такое?

 

[c0dex]

Делать не делали, но думаю можно хранить все несжатое в амазоне, а отдавать по требованию в зипе, вопрос только как часто отдавать и как часто "склеивать".

Есть ли смысл хранить все уже сжатое?

 

[Adelf]

Ну, разумеется, отдавать надо в разы чаще чем склеивать.

З.Ы. Ну, хорошо. Не разумеется. Но обычно отдача статики происходит сильно чаще ее изменения.

 

[c0dex]

Adelf
ты меня не понял, я имел в виду, накладно ли будет сжимать то, что надо отдавать на лету. А не то, сколько склеиваний будет в процентном соотношении ко всем отдачам =)

 

[Adelf]

c0dex
Хорошая идея. Обдумаю. Тогда хранить придется лишь базовые эти кирпичики. да и проще все будет. thx

 

[Тугай]

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

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

Если не нужно содержимое каталога, то можно не заморачиваться с этой вложенностью.

 

[С.]

Если не нужно содержимое каталога, то можно не заморачиваться с этой вложенностью.

Оба-на! Ты знаешь, как ФС может отдать файл, не читая содержимое каталога?

 

[MiksIr]

Оба-на! Ты знаешь, как ФС может отдать файл, не читая содержимое каталога?

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

 

[С.]

Там, где "обычно" дерево, там и проблем с количеством файлов нет (до нескольких миллионов). А сортировка и маски файлов -- проблема не ФС, а среды, в которой это происходит.

 

[MiksIr]

Теоретик.

 

[fixxxer]

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

http://unix.stackexchange.com/questions/28756/what-is-the-most-high-performance-linux-filesystem-for-storing-a-lot-of-small-fi
http://serverfault.com/questions/6711/filesystem-for-millions-of-small-files