Структура каталогов для файлового узла

Question

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

Кроме того, существует ли проблема с производительностью при принудительной загрузке путем отправки информации заголовка и readfile()?Было бы лучше сохранить имена файлов и разрешить использование прямой загрузки без использования скрипта?

Спасибо

Answer 1

Кроме того, существует ли проблема с производительностью при принудительной загрузке путем отправки информации заголовка и readfile()?

Да, если вы делаете это наивно.Хороший скрипт загрузки файла должен:

• передавайте в потоковом режиме длинные файлы, чтобы избежать заполнения памяти
• поддерживайте ETags и заголовки последнего измененного запроса / ответа, чтобы гарантировать, что кэши продолжают работать
• придумайте разумные настройки истечения срока действия / контроля кэша

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

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

Да, это работало бы лучше, но получить право на безопасность - непростая задача.Видишь здесь для некоторого обсуждения.

Компромисс заключается в использовании перезаписи, чтобы URL выглядел примерно так:

hxxp://www.example.com/files/1234/Lovely_long_filename_that_can_contain_any_Unicode_character.zip

Но он перенаправляется внутренне на:

hxxp://www.example.com/realfiles/1234.dat

и обслуживается (быстро) веб-сервером.

Answer 2

Проблемы того типа, о которых вам рассказали, скорее всего, связаны с влияние скопления тысяч и тысяч файлов в одном каталоге на производительность.

Чтобы обойти это, не храните свои файлы непосредственно в одном каталоге, но попробуйте распределить их по подкаталогам (ведра).

Чтобы добиться этого, посмотрите на идентификатор (скажем, 19873) файла, который вы собираетесь сохранить, и сохраните его в <uploads>/73/98/19873_<filename.ext>, где 73 - это ID % 100, 98 - это (ID / 100) % 100 и т.д.

Вышесказанное гарантирует, что у вас будет не более 100 подкаталогов в <uploads>, и не более 100 дополнительных подкаталогов под ним <uploads>/*.Это значительно сократит количество файлов в каталоге на выходе.

Два уровня подкаталогов достаточно типичны и представляют собой хороший баланс между тем, чтобы не тратить слишком много времени на преобразование имен каталогов или файлов в индексы по ширине (что происходит, когда у вас слишком много имен файлов для просмотра в одном каталоге - хотя современные файловые системы, такие как ext3 здесь будет очень эффективно) и глубина (что происходит, когда вам приходится углубляться в 20 подкаталогов в поисках вашего файла).Вы также можете выбрать использование больших или меньших значений (10, 1000) вместо 100.Два уровня по модулю 100 идеально подходят для файлов размером от 100 тыс. до 5 млн.

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

Answer 3

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

Во-первых, да, большое количество файлов в одном месте может вызвать проблему, когда количество файлов превышает системный ARG_MAX.Другими словами, rm -rf * уволился бы, жалуясь на слишком много аргументов.Вы могли бы рассмотреть возможность использования директорий A-Z / a-z и соответствующей парковки файлов на основе значения самого левого байта в их уникальном имени.

Кроме того, старайтесь избегать процессов, которые откроют все эти файлы за короткий промежуток времени...такие файлы, как "updatedb", вызовут проблемы, как только вы действительно начнете заполняться.Аналогично, постарайтесь, чтобы эти каталоги не попадали в сферу действия команд типа "найти".

Это приводит к другой потенциальной проблеме - буферам.Как часто осуществляется доступ к этим файлам?Если бы в данном каталоге было 300 файлов, был бы доступ ко всем из них хотя бы раз в 30 минут?Если это так, вы, вероятно, захотите включить параметр /proc /sys/vfs_cache_pressure, чтобы Linux освободил больше памяти и сделал ее доступной для PHP / Apache / Etc.

Наконец, что касается readfile ...Я бы посоветовал просто воспользоваться прямой ссылкой для скачивания.Это позволяет избежать необходимости поддерживать PHP в рабочем состоянии в ходе загрузки.

Answer 4

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

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

Answer 5

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