Стратегии хранения загрузки изображений
4 ответа
Я уже отвечал на аналогичный вопрос раньше, но не могу его найти, возможно, ОП удалил свой вопрос ...
В любом случае, решение Адамса кажется лучшим пока что, но оно не является пуленепробиваемым, поскольку images / c / cf / (или любая другая пара dir / subdir) может содержать до 16 ^ 30 уникальных хэшей и по крайней мере в 3 раза больше файлов, если мы посчитаем расширения изображений, намного больше, чем может обработать любая обычная файловая система.
AFAIK, SourceForge.net также использует эту систему для репозиториев проектов, например, «fatfree» проект будет размещен в projects / f / fa / fatfree / , однако я считают, что они ограничивают имена проектов до 8 символов.
Я бы сохранил хэш изображения в базе данных вместе с полем DATE / DATETIME / TIMESTAMP , указывающим, когда изображение было загружено / обработано, а затем поместил изображение в такой структуре:
images/
2010/ - Year
04/ - Month
19/ - Day
231c2ee287d639adda1cdb44c189ae93.png - Image Hash
Или:
images/
2010/ - Year
0419/ - Month & Day (12 * 31 = 372)
231c2ee287d639adda1cdb44c189ae93.png - Image Hash
Помимо большей наглядности, этой структуры достаточно, чтобы разместить сотни тысяч (в зависимости от ограничений вашей файловой системы) изображений на day в течение нескольких тысяч лет , именно так Wordpress и другие делают это, и я думаю, что они сделали это правильно на этом.
Дублированные изображения можно легко запросить в базе данных, и вам просто нужно будет создать символические ссылки.
Конечно, если вам этого недостаточно, вы всегда можете добавить дополнительные подкаталоги (часы, минуты, ...).
Лично я бы не стал использовать идентификаторы пользователей, если у вас нет этой информации в вашей базе данных, потому что:
- Раскрытие имен пользователей в URL-адресе
- Имена пользователей изменчивы (вы можете переименовывать папки, но все равно...)
- Пользователь может гипотетически загрузить большое количество изображений
- Бесполезен (?)
Что касается CDN, я не вижу причин, по которым эта схема (или любая другая) не будет работать ...
MediaWiki генерирует сумму MD5 имени загруженного файла и использует первые две буквы MD5 (скажем, «c» и «f» суммы «cf1e66b77918167a6b6b972c12b1c00d») для создания такой структуры каталогов:
images/c/cf/Whatever_filename.png
Вы также можете использовать идентификатор изображения для предсказуемого верхнего предела количества файлов в каталоге. Может быть, взять этаж (уникальный идентификатор изображения / 1000) , чтобы определить родительский каталог, для 1000 изображений на каталог.
Вы можете рассмотреть открытый исходный код http://danga.com/mogilefs/ , поскольку он идеально подходит для того, что вы делаете . Это отвлечет вас от размышлений о папках к пространствам имен (которые могут быть пользователями) и позволит хранить ваши изображения для вас. Самое приятное, что вам не нужно заботиться о том, как хранятся данные. Это делает его полностью избыточным, и вы даже можете установить контроль над тем, насколько избыточны эскизы.
Вы думали об использовании чего-то вроде Amazon S3 для хранения файлов? Я управляю компанией по размещению фотографий, и, быстро достигнув ограничений на нашем собственном сервере, мы перешли на AmazonS3. Прелесть S3 в том, что здесь нет ограничений, таких как inodes и тому подобное, вы просто продолжаете перебрасывать файлы.
Также: если вам не нравится S3, вы всегда можете попробовать разбить его на подпапки, сколько сможете:
/userid/year/month/day/photoid.jpg
{{1 }}