Советы по управлению большим количеством файлов?

Question

Здесь есть несколько очень хороших вопросов по управлению файлами и их хранению в рамках большого проекта.

Storing Images in DB - Yea or Nay?
Would you store binary data in database or in file system?

Первый имея некоторые большие идеи и в моем проекте я решил пойти по пути файла, а не маршрут DB.

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

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

Система i am building будет иметь одно глобальное управление файлами, чтобы все файлы были доступны для всех пользователей. Но многие, которые пошли по файловому маршруту, говорят о размере физического каталога (если все файлы находятся в одном каталоге, например)

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

(проект находится в стеке ЛАМПЫ (PHP), если это помогает на всех)

Answer 1

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

/images/{0}/{1}/{2}

{0}: file_number % 100
{1}: (file_number/100) % 100
{2}: file_number

Answer 2

Для того, чтобы избежать создания чрезмерного количества элементов в одном каталоге, может захотеть основать создание каталогов на куски имени файла. Например, если у вас есть файл с именем d7f5ae9b7c5a.png, вы можете сохранить его в формате media/d7/f5/d7f5ae9b7c5a.png. Если ваши имена файлов шестнадцатеричные, это ограничивает количество записей в одном каталоге до 256 до конечного уровня.

Answer 3

я обычно беру этот подход:

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

Таким образом, если файл находится по адресу /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.

Answer 4

1. Один пупков ~ 100kb, так что есть 10 000 пользователей в базе данных, каждый пользователь будет иметь в среднем 5 изображений, так что мы будем иметь 5 терабайт DB, и каждый вывод изображения будет выполняться с помощью БД и этот дополнительный трафик DB уменьшит общую производительность сервера БД. ... вы можете использовать кластер DB, чтобы этого избежать, но предположим, что это дорого.

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

3. В какой-то момент вы можете решить разместить изображения на некоторых CDN, какими будут изменения в вашем исходном коде?

Answer 5

Я столкнулся с этой проблемой некоторое время назад для сайта, на котором размещалось много файлов. Мы сделали GUID (который также является полем первичного ключа файла) (например, BCC46E3F-2F7A-42b1-92CE-DBD6EC6D6301) и сохраните файл следующим образом:/B/C/C/BCC46E3F-2F7A-42b1 -92CE-DBD6EC6D6301/имяфайла.рсш

Это имеет определенные преимущества:

• Вы можете масштабировать файловые сервера на несколько серверов (и назначить конкретные каталоги и каждый)
• Вы не имеете чтобы переименовать файл
• Ваши каталоги будут гарантированы уникальными

Надеюсь, это поможет!

Answer 6

Я не могу сказать много о том, как apache и PHP управляют файлами, но я могу сказать что-то о файловой системе ext3. ext3, похоже, не имеет проблем с большим количеством файлов в одном каталоге. Я протестировал его до миллиона файлов. Перед созданием каталогов убедитесь, что параметр dir_index включен в файловой системе. Вы можете проверить, запустив dump2fs и изменив этот параметр, запустив tune2fs. Хеширование файлов в дерево подкаталогов может быть полезно, потому что средства командной строки все еще могут иметь проблемы с отображением содержимого каталога.