Разное

Делаю небольшой файлообменик.
Вся информация о файлах храниться в БД.
С этим вроде все нормально.

Но вот как сами файлы хранить на сервере?

Я лишь разделил директории по типу файлов: картинки, музыка, видео и т.д.->
"picture","music","video".

Но все говорят, что в одной директории лучше не хранить больше 100 или 1000 файлов.

тогда как поступить?
Каждый файл имеет ID.

может создавать подкаталоги из кусочка ID?
но тогда будут много каталогов... или большое количество каталогов это нормально?

ну у меня на серве и по ~100000(+-20000) файлов в директории лежит
а по сути - soft/l/li/lin/linux

Например, так:

picture/a/ picture/b/ picture/c/ picture/d/ ... picture/z/

Если файлов очень много, то так:

picture/a/a/ picture/a/b/ picture/a/c/ ... picture/a/z/ picture/b/a/ picture/b/b/ picture/b/c/ ... picture/b/z/ ...

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

>Большое кол-во файлов в директории увеличивает время доступа к этой директории на уровне операционной системы. Поэтому используют многоуровневое дерево директорий.

Это было актуально лет 5-10 назад, во времена FAT32 .
Современные файловые системы таких проблем не имеют.
А усложнение логики работы скрипта может аукнуться ошибками в его коде.

Директория с парой десятков тысяч файлов на современных файловых системах достаточно долго открывается только первый раз - потом информация попадает в кэш и проблема исчезает.

На своем сервера - закешироваться может. Но на сервере где много пользователей - неизвестно сколько этот кэш проживет.

>Это было актуально лет 5-10 назад, во времена FAT32 .
Безотносительно файловых систем - чем меньше файлов в директории - тем лучше. Так как чтение директории производится не только при ее листинге, но и при любом обращении к файлу внутри ее. Разумеется, реальное влияние это параметра будет только на большом количестве файлов.

Недаром прокси-сервера (тот же SQUID) используют многоуровневую структуру для хранения кеш-файлов.

>А усложнение логики работы скрипта может аукнуться ошибками в его коде.
Если количество файлов исчисляется десятками/сотнями тысяч и более, то усложнение работы скрипта того стоит.

И самых наглядных примеров - открытие директории (листинг) по FTP. От нескольких десятков тысяч файлов - и с открытием такой директории будут большие проблемы. Процесс начинает есть и CPU и память и продолжается это достаточно долго - больше, чем терпение у пользователя.

>>Это было актуально лет 5-10 назад, во времена FAT32 .
>Безотносительно файловых систем - чем меньше файлов в директории - тем лучше. Так как чтение директории производится не только при ее листинге, но и при любом обращении к файлу внутри ее.
Не при любом. При первом. Дальше данные будут взяты из кеша.
Но даже если рассматривать лишь первые обращения, каталог не читается целиком. Читаться будут лишь те страницы его B+ дерева, которые ведут к конкретному элементу каталога.

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


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


>И самых наглядных примеров - открытие директории (листинг) по FTP. От нескольких десятков тысяч файлов - и с открытием такой директории будут большие проблемы. Процесс начинает есть и CPU и память и продолжается это достаточно долго - больше, чем терпение у пользователя.

Получение листинга - операция не элементарная (как открытие файла), а массовая.
Она сопряжена с чтением всего каталога, а в случае с FTP (кстати не только с FTP: ls от ls -la тоже отличается разительно) - еще и с массовым чтением метаданных файлов (т.е. не только имен, которые можно взять тут же в каталоге, но и атрибутов, меток времени,идентификаторов владельца и группы и пр. Понятно, что массовая операция будет жрать все ресурсы пропорционально объему каталога, да еще и напрочь устраняя эффект кеширования. Потому как кеш оправдан там, где из всей массы обращения идут лишь в малую часть её.

>>А усложнение логики работы скрипта может аукнуться ошибками в его коде.
>Если количество файлов исчисляется десятками/сотнями тысяч и более, то усложнение работы скрипта того стоит.

Конечно, положительный эффект будет. Но не при работе скрипта.
Возиться руками по FTP / SSH с таким ресурсом будет куда приятнее.

>Но даже если рассматривать лишь первые обращения, каталог не читается целиком. Читаться будут лишь те страницы его B+ дерева, которые ведут к конкретному элементу каталога.

Хм... не все файловые системы используют B-деревья. Так, например, ext3 - до сих пор самая популярная в Linux B-деревья не использует. И если заранее не известно где будет работать код, то нужно от этого подстраховаться.

>>И самых наглядных примеров - открытие директории (листинг) по FTP. От нескольких >Получение листинга - операция не элементарная (как открытие файла), а массовая.

Все так, но минусы большого кол-ва файлов в одной директории иллюстрирует.

Спасибо за советы...

решил делать как зайцы.

допустим ID-файлы: 12345
тогда путь к файлу будет: files/123/12345.xxx

так в одной папке будет где-то 100файлов, но тогда в папке `files` будет очень много подкаталогов. это нормально???

т.е. в одной папке сколько лучше создавать подпапок?

Логично предположить, что столько же, сколько и файлов! =)
Хотя может я ошибаюсь...

>100файлов
Можно больше. Оставляйте 100 только если вдруг захотите сами глазами просматривать такие директории.

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