Здесь есть несколько очень хороших вопросов по управлению файлами и их хранению в рамках большого проекта.
Хранение изображений в DB – Yea или Nay?
Будете ли вы хранить двоичные данные в базе данных или в файловой системе?
Первый, у кого есть большой интерес, и в моем проекте я решил пойти по файловому маршруту, а не по маршруту БД.
Основной момент против использования файловой системы – это резервное копирование. Но в нашей системе у нас отличная схема резервного копирования, поэтому я не беспокоюсь об этом.
Следующий путь – хранить фактические файлы. И я думал о постоянном расположении файлов и создании виртуальной системы каталогов в базе данных. Поэтому ссылки на файл не меняются.
Система, которую я создаю, будет иметь одно глобальное управление файлами, чтобы все файлы были доступны для всех пользователей. Но многие, которые пошли по файловому маршруту, говорят о размере физического каталога (если все файлы находятся в одном каталоге, например)
Поэтому мой вопрос: какие советы или методы лучшей практики при создании папок для этих статических файлов, или если я вообще не должен идти по пути виртуального каталога.
(проект находится в стеке 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 / имяфайла.рсш
Это имеет определенные преимущества:
Надеюсь это поможет!
Чтобы избежать создания избыточного количества записей в одном каталоге, вам может понадобиться основать создание каталогов на куски имени файла. Например, если у вас есть файл с именем d7f5ae9b7c5a.png, вы можете сохранить его в формате media / d7 / f5 / d7f5ae9b7c5a.png. Если ваши имена файлов шестнадцатеричные, это ограничивает количество записей в одном каталоге до 256 до конечного уровня.
Один пользовательский образ ~ 100 кб, поэтому пусть в базе данных будет 10 000 пользователей, каждый пользователь будет иметь в среднем 5 изображений, поэтому у нас будет 5 терабайт БД, и каждый вывод изображения будет выполняться через БД, и этот дополнительный трафик БД уменьшит общая производительность сервера БД. … вы можете использовать кластер 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. Хеширование файлов в дерево подкаталогов может быть полезно, потому что средства командной строки все еще могут иметь проблемы с отображением содержимого каталога.