Архитектура каталога с графикой

[impossible]

Архитектура каталога с графикой

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

Две идеи:
1. корневая директория с фото => id - пользователя => фото
хранить в БД id - фото

2. корневая директория с фото => год добавления фото => месяц добавления фото{=> день добавления фото} => фото
хранить в БД полный путь до фото

Что эффективнее? или как эффективнее?

 

[Krishna]

impossible
ИМХО по-всякому, иерархию каталога надо закладывать в БД, а не ФС. СУБД для того и делается, чтобы быстрее и удобнее чем ФС такие штуки проворачивать.

 

[impossible]

Krishna
вопрос не в этом, а в быстроте работы ФС. Если в директории Огромное число файлов, то замедляется работа с файлами в этой директории.

 

[Сенсей]

impossible
php обращается к фалу напрямую.. ничего не тормозит...
это в винде у тебя тормозит потому что ты открываешь папку - и считываются все данные этой папки....

 

[SiMM]

> php обращается к фалу напрямую..
С этого места - поподробнее.
> считываются все данные этой папки
И каким же это чудотейственным образом происходит без чтения ВСЕГО каталога, если речь о последнем файле в каталоге? Поскольку FAT32 - тоже поддерживается виндой - можно начать с неё.

 

[impossible]

Сенсей

Файловая система связывает носитель информации с одной стороны и API для доступа к файлам — с другой. Когда прикладная программа обращается к файлу, она не имеет никакого представления о том, каким образом расположена информация в конкретном файле, также как и на каком физическом типе носителя (CD, жестком диске, магнитной ленте или блоке флэш памяти) он записан. Все, что знает программа — это имя файла, его размер и атрибуты. Эти данные она получает от драйвера файловой системы. Именно файловая система устанавливает, где и как будет записан файл на физическом носителе (например, жестком диске).

С точки зрения ОС весь диск представляет из себя набор кластеров размером от 512 байт и выше. Драйверы файловой системы организуют кластеры в файлы и каталоги (реально являющиеся файлами, содержащими список файлов в этом каталоге). Эти же драйверы отслеживают, какие из кластеров в настоящее время используются, какие свободны, какие помечены как неисправные.

взято с wiki-педии.
Если каталог будет содержать Большое число файлов, то будет замедлен поиск по нему. Самый не оптимальный способ, это скидывать всю графику в одну папку, тогда поиск будет существено замелен. Встает вопрос создание архитектуры каталогов. Если все фотографии пользователя хранить в его личной папке, а ее хранить в root папке фото, то больше число пользователей приведет к тому же торможению. Если архитектуру строить на дате сохранения файла (год - месяц - день), то получается жестко ограниченная структура, каждый каталог будет иметь приемлемое число фото. Но увеличивается место занимаемого в БД для сохранения пути к фото, в то время как в первом случае можно было храить только имя файла.

-~{}~ 04.04.06 10:27:

+ во втором варианте (по дате) теряется логика. по дате менее понятно, чем по id-пользователя к примеру.
вопрос, как все это оптимально организовать сохранив "прозрачноть"?

 

[Фанат]

Но увеличивается место занимаемого в БД для сохранения пути к фото,

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

Что эффективнее? или как эффективнее?

не пробовал обратить внимание на существующие проекты? или ты пишешь свой в вакууме, первый в мире большой каталог фотографий?

 

[SiMM]

Если приспичило - путь можно узнавать по id - к примеру, файл с id 123456789 мог бы лежать в 123/456/789.jpg

 

[impossible]

Фанат

увеличение на 6 байт

Возможно это не существенно.

не пробовал обратить внимание на существующие проекты

Если честно - не обратил. Решил спросить на форуме.

 

[Фанат]

Вот и обрати.

 

[impossible]

SiMM
Не приспичело, но идея интересная.

 

[Сенсей]

Вы хотите сказать что когда я обращаюсь к картинке как к

http://img.phpclub.ru/logotransp.gif

то для операционки не пофиг сколько еще картинок лежит в той же папке?

Не верю я в то что само понятие ПАПКА так сильно воздействует на быстродействие системы...

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

з.ы
У меня в пооэкте есть две папки.... photos и photos_thums

В каждой - по 17,000 файлов с названиеми в формате 12221_1141740952.jpg (id_time.jpg)

Ни каких тормозов....

 

[SiMM]

Как всё запущено-то
http://phpclub.ru/talk/showthread.php?threadid=69270
Дальше - думать о том, как операционка получает доступ к файлу (для этого нелпохо бы изучить структуру FAT'а - с этим в гугль), ну и поиском пошуршать.