здравствуйте. проектирую фотохостинг, думаю как лучше хранить фото. как всё будет: много пользователей, у каждого много фото у пользователей фото распределены по альбомам. идея хранить так: /data/user_id/album_id/photo_id.jpg или /data/user_id/photo_id.jpg или /data/photo_id.jpg при чем еще храниться три варианта фото в разных папках, small medium и normal. какой способ лучше выбрать, чтобы были максимальная скорость чтения/записи? спасибо
Максимальная скорость чтения-записи - раскидать по серверам А в твоем случаи я думаю выбрал бы 1 вариант, хорошо структурировано, не много фото в папке, быстрее немного обращение к фото значит))
я храню примерно так foto/1/small/ - для маленьких foto/1/big/ - для больших ... папка 1 - это константа, которая записывается в БД, когда накопится много файлов просто создам аналогичную папку имя файла получаю из последовательности в БД (pgsql)
сервера пока рано да...скорее всего вот эти album_id и photo_id будут рандомными и хранится отдельно в базе. хотелось бы структурировано. просто если у каждого пользователя в альбомах будет много фото, то папки будут огромными.
"Мечтать не вредно" (с) Если у Вас будет хотя бы по сотни фоток на нос (в среднем), считайте, что Вам повезло. Если "по правильному", то разбивать по папкам по ~1 тысяче файлов. (хотя, конечно всё зависит от файловой системы) Что-то вроде /group_user/user_id/0{1,2,3,4...}/ или /group_user/user_id_0/ или что-то подобное. Смысла разбивать по альбомам нет никакого - у вас будет уйма каталогов по десятку-другому файлов. Плодить много маленьких каталогов, это плохо.
КО предлагает: при загрузке файла создается соотв. запись в таблице с автоинкрементным id. если ты хочешь хранить не более 1000 файлов в папке, то имя папки вычисляем как floor(id / 1000). гениально, правда? превьюшки соответственно по имени размера + подпапка по этому же правилу - типа img/small/0/286.jpg img/big/1/1044.jpg вариация на тему: если наш id строковый и состоит из маленьких латинских букв и цифр, это как бы число по основанию 36. два символа это уже 1296 вариантов. значит если мы хотим хранить примерно по 1000 файлов в папке, можно имя папки вычислять как substr(id, 0, -2) ну и т.д. и т.п.
$id = 21639; path to image : .../imagestore/2/1/6/3/9/21639.jpg path to thumb: .../imagestore/2/1/6/3/9/21639.175.70.jpg (последние две цыфры - высота и ширина) проверено на прортале игровом с 3 лямами уников
MaXyC_Web_Studio, я правильно понимаю: в каждом каталоге оказывается только один оригинал + несколько превьюшек от него? иными словами сколько "оригинальных" файлов, столько и каталогов + еще более 9000 каталогов верхнего уровня. эммм... а какой в этом смысл?
каждый файл лежит в отдельной папке со всеми тумбами какие надо. в этот же момент в этой же папке лежат и более последние папки с файлами
в итоге получается в 1 папке не более 10 подпапок и не болльшое кол-во файлов изображений и тумбов п.с. не я разрабатывал, до меня делали. я лишь продолжаю эту идею. многогигабайтный фотоархив уже не перестроить
По моему мнению лучше сделать отдельную папку для изображений в которой рандомом создавались бы папки аналогично месяцу и году, а всю информацию с какого альбома и чья фото хранить в базе. Например папка host.ru/i/ в которой создаются помесячные папки например host.ru/i/11_08_1_b/ 11 - год 08 - это месяц 1 - номер папки месяца b или s - символизирует какого размера в ней изображения b - оригиналы, s- превью При заполнении папки до 5000 картинок создавать новую папку и сливать туда свежие картинки. На подобии такого типа я у себя реализовал, для админа все понятно и легко найти нужную папку.
ramen Бгг, на аватарке Яцына Павел =)) Это ж ещё с того сета, где он в бильярд гоняет, если память не подводит меня.