Стратегии хранения файлов для веб-хостинга

Question

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

На протяжении всего срока существования этого файла есть два момента, представляющих интерес.Первый — когда данные абстрагируются, а второй — когда файл архивируется для совместного использования.

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

Когда файл будет заархивирован, я придумал три стратегии.Один из них — хранить все файлы, загруженные из определенных данных, в одной папке.(2006/сентябрь/04, 2008/январь/05) Другой - сохранить папку и продолжать заполнять ее до тех пор, пока не будет достигнуто максимальное количество файлов, которые я хочу сохранить в папке, а затем создать еще одну (/folder001/, /folder002/, /folder003/ и т. д.).Другой вариант — создавать подпапки, когда они достигают определенного порога.Например (/j/jd/jde/jdelator). Я видел это в Unix, не знаю, как это объяснить.

У меня есть вопросы: какие стратегии вы, ребята, нашли полезными или использовали?

Answer 1

Когда данные абстрагируются, я бы выбрал что-то вроде: filename + millisec();Маловероятно, что два вызова миллисекунд будут одинаковыми, а имя файла будет более удобным для пользователя при доступе.

Стратегия дат может быть удобной, если вы решите удалить старые и неиспользуемые файлы:вам нужно только получить папку 2006 года и удалить все, к чему не обращались за последний год, согласно вашему журналу.Это также может быть хорошим индикатором для ваших пользователей, поскольку они будут знать, новый это файл или нет.Папка XYZ — это всего лишь вариант этой папки, в которой дата заменяется тегом для каждого N файлов.

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

Другая возможность — использовать БД с UID, соответствующим местоположению имени файла, и получать доступ к файлу через http://server.com/UID/имя_файла.txt .Таким образом, пользователь сохраняет файл как «имя_файла.txt», что ему удобно, и вы знаете по URL-адресу, где найти файл (используя БД для преобразования UID в местоположение).Обратите внимание, что UID может быть контрольной суммой (MD5, SHA-1) для обработки дубликатов одного и того же файла.

Answer 2

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

Answer 3

Я использовал реляционную базу данных, которая помечает идентификаторы (int) uuid, которые являются именами файлов.Таким образом, не имеет значения, как они находятся на диске.Это помогает мне запутать файлы.Кроме того, я могу использовать JOIN для произвольного «переименования» файла.Кроме того, я могу использовать разные файлы «имена». Все зависит от вашего приложения и от того, где оно работает.

Answer 4

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

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