Каким образом хранить огромное кол-во фото на сервере?

[verfaa]

В одной из папок на сервере, куда копируются фотографии пользователей скопилось очень много файлов. Попытался открыть эту папку - winscp думал минут 15)) Всвязи с тем что со временем количество файлов в этой папке будет сильно возрастать встал вопрос: Каким образом лучше всего хранить очень большое количество фотографий на сервере и как удобнее всего получать к ним доступ с помощью php?

Т.к. я раньше с таким не сталкивался, на ум пришло только распределять фото по разным папкам на основе id пользователя, т.е. например для пользователей с id 1-50000 хранить фото в папке 1, для пользователей с id 50000-100 000 хранить фото в папке 2, для пользователей с id 100 000-150 000 хранить фото в папке 3 и т.д. А из скрипта можно получать к ним доступ так

if($id > 1 && $id =< 50000) {
$fotoph = "/1";
} else if ($id > 50000 && $id =< 100000) {
$fotoph = "/2";
} else if ($id > 100000 && $id =< 150000) {
$fotoph = "/3";
}
...

Но наверное это будет не самый удобный и лучший вариант...
Может быть есть лучше?
И ещё очень важный для меня вопрос, какое оптимальное количество фото лучше всего хранить в одной папке - 10 000, 50 000, 100 000 ???

 

[o_nix]

лучше использовать структуру вложенных папок типа
год/месяц/

так с ними потом на много удобнее работать

попробуй не winscp а обычный ссхашный mc, он у меня быстрее всего открывает проблемные папки

 

[verfaa]

Для просмотра ссылки Войди или Зарегистрируйся , спасибо, но этот вариант врядли подойдёт - к примеру в скрипт приходит запрос фото пользователя 43224 - скрипт обращается к БД и получает 43224_mhv7gfFhb.jpg - это значение храниться в базе, пути к этому фото в базе не храниться - это в принципе ни к чему, только базу засорять. И как в таком случае узнаем папку? Она ведь будет иметь название месяца и года, когда фото было загружено пользователем?

 

[o_nix]

если ты собираешься делать средствами php листинг файлов в папке и их вывод это это не правильно

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

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

 

[verfaa]

По поводу листинга уточню: в движке нигде нет запроса на получение списка содержимого директории, т.е. функции наподобие glob, readdir нигде в движке к папкам с фото не применяются.
Если, например, нужно получить все фото пользователя с id 43224 - скрипт обращается к БД с запросом вроде: select foto_path from user_fotos where id_user=43224 и получает 43224_mhv7gfFhb.jpg 43224_ci9ehzFvb.jpg и т.д.

 

[smalllamer]

Смотря какая ФС. Та же UFS преспокойно живет более чем с 500к файлов.
Даже тесты проводили. Время выборки 10 файлов увеличивается до 3х сек с 3кк файлов. Подходит/не подходит - смотри сам.

Хотя я бы переписал функции вывода фото.

 

[donvictorio]

многоуровневая структура каталогов позволит разгрузить листинг. по 255 каталогов в уровне, 2х уровней достаточно, чтобы без проблем хранить миллионы файлов и особо не грустить по этому поводу. если в id файла прописать номера каталогов, то и найти его не составит труда. к примеру ffab13.jpg это 13й файл в /ff/ab и так далее.

 

[mcdir]

короч - хранить нуна хэши с префиксами ffab13.jpg -> /aa/bb/ksdfjscfjkhdgf.jpg
а еще лучше поставить опен свифт или что нить подобное, там можно действительно хранить оч много кортинок

надеюсь огромное это милиарды
т.к. милионы - это не огромное...

 

[verfaa]

Смотря какая ФС.


Хотя я бы переписал функции вывода фото.

хз, df -T выдало:

Filesystem    Type  1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup80-ROOT
              ext4  952809388  10562560 893846856  2% /
tmpfs        tmpfs    8152392        0  8152392  0% /dev/shm
/dev/sda1    ext4      495844    59078    411166  13% /boot

ОСь CentOS 6.3, если это важно.

smalllamer, а каким образом ты бы переписал функции вывода фото?

 

[smalllamer]

Для просмотра ссылки Войди или Зарегистрируйся
Это глюканул клиент. Ну можешь еще провести тесты на серваке)
Вобщем до 4кк можно не заморачиваться.

Примерно так, исходя из того, как идет нагрузка:
1. SQL, как предложил товарищ o_nix
2. Хранить в ненормализованном виде — список id пользователя для ряда обьектов. Выборка уже будет быстрее. (отдельная табл)
3.

короч - хранить нуна хэши с префиксами ffab13.jpg -> /aa/bb/ksdfjscfjkhdgf.jpg

Я сделал по 3 варианту.