Здесь есть очень хорошие вопросы о SO об управлении файлами и хранении в рамках большого проекта.
Сохранение изображений в БД - Да или Нет?
Будете ли вы хранить двоичные данные в базе данных или в файловой системе?
Первый, у которого есть отличные идеи, и в моем проекте я решил пойти по файловому маршруту, а не по маршруту DB.
Основным моментом против использования файловой системы является резервное копирование. Но в нашей системе у нас отличная схема резервного копирования, поэтому я не беспокоюсь об этом.
Следующий путь - хранить фактические файлы. И я думал о постоянном расположении файлов и создании виртуальной системы каталогов в базе данных. Поэтому ссылки на файл не изменяются.
Система, которую я создаю, будет иметь одно глобальное управление файлами, чтобы все файлы были доступны для всех пользователей. Но многие, которые пошли по файловому маршруту, говорят о размере физического каталога (если все файлы находятся в одном каталоге, например)
Итак, мой вопрос: какие советы или методы лучшей практики в создании папок для этих статических файлов или если я вообще не должен идти по пути виртуального каталога.
(проект находится в стеке LAMP (PHP), если это вообще помогает)
Один из способов - назначить уникальный номер каждому файлу и использовать его для поиска фактического местоположения файла. Затем вы используете этот номер для распространения файлов в разных каталогах в файловой системе. Например, вы можете использовать что-то вроде этой схемы:
/images/{0}/{1}/{2}
{0}: file_number % 100{1}: (file_number / 100) % 100{2}: file_number
Я столкнулся с этой проблемой некоторое время назад для веб-сайта, на котором было много файлов. Мы сделали GUID (который также является полем первичного ключа файла) (например, BCC46E3F-2F7A-42b1-92CE-DBD6EC6D6301) и сохраните файл следующим образом:/B/C/C/BCC46E3F-2F7A-42b1 -92CE-DBD6EC6D6301/filename.ext
Это имеет определенные преимущества:
Надеюсь, это поможет!
Чтобы избежать создания избыточного количества записей в одном каталоге, вы можете захотеть основать создание каталогов на фрагменты имени файла. Например, если у вас есть файл с именем d7f5ae9b7c5a.png, вы можете сохранить его в формате media/d7/f5/d7f5ae9b7c5a.png. Если ваши имена файлов шестнадцатеричные, это ограничивает количество записей в одном каталоге до 256 до конечного уровня.
Один пользовательский образ ~ 100 кб, поэтому пусть в базе данных будет 10 000 пользователей, каждый пользователь будет иметь в среднем 5 изображений, поэтому у нас будет 5 терабайт БД, и каждый вывод изображения будет выполнен через БД, и это дополнительный трафик DB уменьшит общую производительность сервера БД.... вы можете использовать кластер DB, чтобы избежать этого, но предположите, что это дорого
Отчет пользователя об ошибке в живой базе данных (в тесте - все работает правильно), как бы вы создали дамп, чтобы распаковать его на машине разработчиков? Сколько времени это займет?
В какой-то момент вы можете решить разместить изображения на каком-то CDN, каковы будут изменения в исходном коде?
Обычно я использую такой подход:
У вас есть глобальная переменная параметров для вашего приложения, которая указывает на папку, в которой хранятся загруженные файлы. В вашей базе данных хранятся относительные пути к файлам (относительно того, что указывает переменная параметров).
Таким образом, если файл находится по адресу /www/uploads/image.jpg, ваши настройки, отображаемые в /www/uploads, в вашей строке базы данных есть image.jpg. Это гибкий способ, который отделяет структуру вашего системного каталога от вашего приложения.
Далее вы можете фрагментировать файловое хранилище в каталогах на основе того, с какими таблицами базы данных они связаны. Скажем, у вас есть таблица user_reports и таблица user_photos. Вы храните файлы, относящиеся к user_reports в /www/uploads/user _reports. Если у вас есть большое количество пользовательских загрузок, вы можете реализовать фрагментацию еще больше. Скажем, пользователь загружает файл 20.03.2009, файл называется report.pdf, поэтому вы храните его в/www/uploads/user_reports/2009/03/20/report.pdf.
Я не могу сказать много о том, как apache и PHP управляют файлами, но я могу сказать что-то о файловой системе ext3. ext3, похоже, не имеет проблем с большим количеством файлов в одном каталоге. Я протестировал его до миллиона файлов. Перед созданием каталогов убедитесь, что параметр dir_index включен в файловой системе. Вы можете проверить, запустив dump2fs и изменив эту опцию, запустив tune2fs. Хеширование файлов в дерево подкаталогов может быть полезно, потому что средства командной строки все еще могут иметь проблемы с отображением содержимого каталога.