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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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