привет местным. я тут первый раз у вас. если понравится, то и останусь пишу вам потому, что у меня сейчас появился один большой проект. и у меня нет опыта в некоторых вопросах. может, кто поможет. вопросы будут поступать еще. постановка проблемы: предвидятся большое количество файлов (картинки, видео), которые пользователи регулярно будут добавлять, смотреть и стерать. разговор идет о потенциально сотнях тысяч или даже миллионах файлов. картинки до 100KB, видео (переделанное во флэш) до 20MB. первоначально предвидится один сервер, если проект пойдет, то больше. потенциально ресурс будет посещать до 100000 человек ежедневно. вопрос: как разумно (с точки зрения времени доступа) разместить все эти файлы по каталогам (и в будущем по серверам)? разумно ли пихать все в один каталог или в несколько? если в несколько, то по какому принципу (случайным способом или туда, где больше места, или как-то еще). как зависит время доступа к файлу от количества других файлов и их размера (как в каталоге, так и вообще)? какие еще проблемы могут возникнуть в связи с таким количеством файлов? от чего еще может зависеть время доступа к файлу и как? кто должен распределять файлы (PHP или файловая система или кто-то еще)? more questions to come... 8)
у папок квотирование? при прямом запросе файла ("абсолютный путь" типа ) по-барабану при поиске (вообще переборе всех файлов) ясно что медленее чем больше файлов. фтп клиент долго будет грузить список а так никаких не должно быть, ограничения на кол-во файлов начинаются минимум от 2^31. от фрагментации по моему распределять файлы должен скрипт я бы хранил по отдельности картинки и видео в разных папках, но в одну кучу к названию нового файла добавлять автоинкрементальное значение из таблицы, тогда проблем с уникальностью не будет.
OK. ну а как насчет производительности жесткого диска. если, например, одновременно 500 человек захотят скачать себе 20-мегабайтовый файл (да если это еще и окажется один файл), не начнет ли жесткий диск тормозить? вопрос о пропускной способности внешнего канала оставим за скобками.
начней, а как же для этого и собирают raid, да еще на scsi, от структуры папок скорость не зависит (грубо говоря, папка это тоже файл)
Нуну. Вам не приходила мысль, что скорость доступа к ХДД на порядки выше пропускной способности канала?
именно это мне и пришло в голову, поэтому я намеренно исключил этот вопрос из постановки задачи :wink:
Это вам кто сказал? Директория по сути тот же файл, в котором хранится список вложенных элементов (директорий и файлов). Чем больше список, тем дольше его просматривать при любом обращении к файлу. Хостеры не просто так делают ограничение на максимальное количество файлов в директории, считая оптимальным ограничение в 1000-4000 файлов.
Практические занятия прикладным программированием. Хостеры ограничивают, чтоб через веб-интерфейс их "проводника" и фтп клиента не перебирать постоянно эти списки файлов. Да и то, 5134 файла в папке, сайчас, хостер не ругается и не ограничивает, можно закопировать еще как через веб, так и через фтп, у меня неправильный хостер
и при обращеии к файлу не происходит перебор остальных, директория - файл с флагом dir, используется непосредственно при построении дерева каталогов с файлами. при обращении к файлу просиходит обращение к директории на предмет прав доступа, никаких переборов не происходит (хотя я тут могу ошибаться, потому как так в Виндовозе происходит, неужели юникс с ее журналируемой ФС перебирает все файлы в папке? ).
antonn AlexGousev прав. Речь не о переборе содержимого файлов, а о переборе имен файлов во внутреннем списке каталога. Если в нем 10000 файлов и нужный тебе идет последним, то операционке придется попеределать кучу безуспешных сравнений
Dagdamor с чего бы это? путь файла типа \home\dir\files\picture.png обращается конкретно к файлу, будут проверены три каталога на наличие ограничивающих прав (если еще точнее три "файла" в вайловой таблице с аттрибутом dir). Зачем что то перебирать, если в файловой таблице указан стартовый кластер и смещение на сам файл? Конечно, чем больше файлов (в сумме), тем больше файловая таблица, тем более медленный поиск, однако это время совершенно не сравнимо, например, с простым отрабатыванием скрипта простого счетчика, и уж тем более пофиг на то, находятся ли файлы в одной папке или в десяти. Падение производительности будет только при запросе всего листа файлов в папке - например обзор папки в фтп-менеджере или в его аналоге вебинтерфейсном.
да, и кстати, очень ощутимо будет разниться запрос к базе на выборку одного элемента из 100 или 10000 записей фиксированой длины, индексацией по нескольким полям? а если это на уровне kernel_mode операционки с офигенной оптимизацией под конкретную задачу? Не надо себе жизнь усложнять
antonn Да, именно об этом мы и говорили - про выборку из "файловой таблицы". Пожалуйста - если считаешь что это не превратится в проблему, храни все в одном каталоге. Хозяин барин
Это верно для FAT и ей подобных. Но это неверно ни для Ext3, ни для JFS, XFS, NTFS, ReiserFS… кого забыл? Именно в фате без разницы сколько где файлов - одинаково будет тормозить. В ФС, построенной на узлах, каждый файл директории содержит вот такую табличку. Поэтому выгодно разбрасывать файлы по директориям, уменьшая таблички в каждом отдельно взятом файле директории.
у нтфс поиск в таблице элементов каталога еще быстрее, чем в фат, а сама таблица в mft без фрагментаций (ну почти ), т.ч. теоретически оно может и медленей, но практически без разницы. о чем речь и шла.