Я пишу приложение для хранения большого количества изображений (размером <5 МБ) в файловой системе ext3, это то, что у меня есть на данный момент. После некоторых поисков здесь на serverfault я решил создать такую структуру каталогов:
000/000/000000001.jpg
...
236/519/236519107.jpg
Эта структура позволит мне сохранить до 1 000 000 000 изображений, поскольку я буду хранить не более 1 000 изображений на каждом листе.
Я создал его, с теоретической точки зрения мне это кажется нормальным (хотя у меня нет опыта в этом), но я хочу узнать, что произойдет, когда там будут каталоги, полные файлов.
Вопрос о создании этой структуры: что лучше создать за один раз (на моем компьютере это занимает около 50 минут) или мне следует создавать каталоги по мере необходимости? С точки зрения разработчика, я думаю, что первый вариант лучше (без дополнительного времени ожидания для пользователя), но с точки зрения системного администратора это нормально?
Я подумал, что могу сделать так, как будто файловая система уже находится под запущенным приложением, я сделаю сценарий, который будет сохранять изображения как можно быстрее, отслеживая вещи следующим образом:
Запускает ли эту команду
sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
вообще имеет смысл? Разве это единственное, что мне нужно сделать, чтобы начать с чистого листа, если я хочу начать все заново с моих тестов?
Есть ли у вас предложения или исправления?
EDIT: я сделал выбор файловой системы, в отличие от db, из-за этих двух вопросов:
Прежде всего, будьте осторожны с ограничениями файловой системы. Вы никогда не будете хранить более 2 ^ 32 файлов в файловой системе vanilla EXT3, так как существует ограничение на максимальное количество inodes (проверьте df -i). В дополнение к этому существуют ограничения на максимальный размер FS и тому подобное.
Во-вторых: вам действительно нужны файлы в файловой системе? В зависимости от того, как осуществляется доступ к файлам, вы можете обнаружить, что улучшите (и намного более предсказуемо) производительность, поместив файлы в базу данных. В дополнение к этому, с базами данных намного проще работать, создавать резервные копии, перемещать и т. Д. Любой дизайн приложения, включающий миллионы файлов, имеет изъяны и вернется, чтобы сильно вас укусить в будущем.
Делать не создавать их все при запуске.
Создавайте каталоги верхнего уровня 1k, если хотите, но сверх этого делайте их по запросу. В противном случае создание их всех поглотит кучу inodes вашей файловой системы, которые, скорее всего, никогда не будут использоваться.
Учтите: на каждый созданный каталог используется 1 индексный дескриптор (индексы содержат разрешения и информацию о владельце как для файлов, так и для каталогов). Итак, каталоги верхнего уровня 1000 - это ... 1000 индексных дескрипторов. Следующий уровень ниже - 1000 * 1000 или 1000000 инодов. Миллион, что даже на сегодняшних больших дисках - немалая сумма. Если вы заполните диск объемом 1 ТБ файлами по 5 МБ, это ... 200 тыс. Файлов. Вы потратите больше инодов на структуру каталогов, чем на сами файлы. Черт возьми, у вас будет больше каталогов, чем файлов!
Pehrs поднимает очень хороший вопрос о файловых системах с таким количеством файлов. Когда приходит время создать резервную копию этой файловой системы, это займет ОЧЕНЬ много времени. Обход файлов - одна из самых больших затрат времени во время процесса резервного копирования, как и все запросы на открытие / закрытие файлов. Вопрос, "сколько времени требуется для сохранения изображения, когда места нет или используется мало?"предполагает, что эти файлы будут довольно маленькими, поэтому файловая система этого типа является почти учебником для наихудших сценариев резервного копирования (один случай хуже: все эти файлы в одном каталоге).
Сравните это с настоящей базой данных, где выгрузка БД в резервную копию - очень быстрая и эффективная операция. Да, эта база данных может быть ОЧЕНЬ большой, но она будет выполнять резервное копирование НАМНОГО быстрее и может даже быстрее обслуживать данные по мере роста количества файлов. Это может зависеть от того, какую БД вы используете и насколько хорошо ею управляете, но обычно использование хранилища БД вместо хранилища ФС в этом случае обеспечивает лучшую устойчивость к бедствиям.
Если БД не подходит, то да, лучше всего заранее создать структуру каталогов. Что также поможет, так это балансировка нагрузки, создаваемой файлом, по всей структуре, а не просто до тех пор, пока / 000/000 / не будет заполнено, прежде чем перейти к / 000/001 /. Это должно гарантировать, что количество файлов на каталог в течение некоторого времени остается низким.