Тестирование на запись на диск

Я пишу приложение для хранения большого количества изображений (размером <5 МБ) в файловой системе ext3, это то, что у меня есть сейчас. После некоторых поисков здесь на serverfault я решил для структуры каталогов как это:

000/000/000000001.jpg
...
236/519/236519107.jpg

Эта структура позволит мне сохранить до 100000000 изображений, так как я буду хранить до 1000 изображений на каждом листе.

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

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

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

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

Запускает ли эту команду

sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

имеет ли вообще смысл? Разве это единственное, что мне нужно сделать, чтобы начать все сначала, если я хочу начать все заново с моих тестов?

Есть ли у вас какие-либо предложения или исправления?

РЕДАКТИРОВАТЬ: я сделал выбор файловой системы, в отличие от БД, из-за этого два вопроса:

Источник

3 ответа

Решение

Pehrs поднимает очень хороший вопрос о файловых системах с таким количеством файлов. Когда придет время для резервного копирования этой файловой системы, это займет ОЧЕНЬ много времени. Обратный путь к файлам является одним из самых больших временных отказов во время процесса резервного копирования, прямо по всем этим запросам на открытие / закрытие файла. Вопрос "сколько времени требуется для сохранения изображения, когда оно не используется или мало места используется?" Предполагает, что эти файлы будут довольно маленькими, поэтому файловая система этого типа почти учебник для резервного копирования в худшем случае. сценарии (один случай хуже: все эти файлы в одном каталоге).

Сравните это с настоящей базой данных, где выгрузка БД в резервную копию является очень быстрой и эффективной операцией. Да, эта база данных может быть ОЧЕНЬ большой, но она будет выполнять резервное копирование LOT быстрее и может даже обслуживать данные быстрее по мере увеличения числа файлов. Это может зависеть от того, какую БД вы используете и насколько хорошо она управляется, но обычно использование хранилища БД вместо хранилища ФС в этом случае обеспечит лучшую устойчивость к бедствиям.

Если БД не является опцией, тогда да, лучше всего предварительно создать структуру каталогов. Также поможет балансировка нагрузки, создаваемая файлами по всей структуре, а не просто переход до заполнения /000/000/ перед переходом к /000/001/. Это должно гарантировать, что количество файлов в каталоге остается низким в течение достаточно долгого времени.

Источник

Прежде всего, будьте осторожны с ограничениями файловой системы. Вы никогда не будете хранить более 2^32 файлов в файловой системе vanilla EXT3, поскольку существует ограничение на максимальное число inode (проверьте df -i). В дополнение к этому, существуют максимальные пределы размера FS и такие, чтобы рассмотреть.

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

Источник

Не создавайте их все при запуске.

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

Примите во внимание: 1 индекс используется для каждого созданного каталога (в индексах хранятся разрешения и информация о владельце как для файлов, так и для каталогов). Таким образом, каталог 1000 верхнего уровня - это... 1000 inode. Следующий уровень - 1000 * 1000 или 1000000 inode. Миллион, что даже на современных больших дисках - немалая сумма. Если вы заполнили диск объемом 1 ТБ 5 МБ, это... 200 КБ файлов. Вы собираетесь тратить больше inode на структуру каталогов, чем на сами файлы. Черт возьми, у вас будет больше каталогов, чем файлов!

Источник
Другие вопросы по тегам