Это может быть очень общий вопрос, но мне очень нравится находить подробные ответы или подсказки.
Я обсуждаю это с другом, пытаясь убедить его поместить более 300 000 файлов из одной папки в более чем одну (например, 1000 на подкаталог). Эти файлы являются изображениями и предназначены для просмотра в Интернете, например:
www.example.com/folder/1.png
.
.
.
www.example.com/folder/300000.png
Я просто помню, как много лет назад я работал в компании по предоставлению онлайн-видео, такой как Youtube. Скриншоты складывали в одну папку, и тогда сервер постоянно падал. В то время ходили «слухи» о том, что люди не должны класть много файлов в одну папку, но мы не знаем точной причины.
Итак, сколько файлов я должен поместить в одну папку? Если есть ограничение, почему? Любые рекомендуемые способы создать это?
Информация о моем сервере:
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.8 (wheezy)
Release: 7.8
Codename: wheezy
Версия Core Build:
Linux linode 4.1.5-x86_64-linode61 #7 SMP Mon Aug 24 13:46:31 EDT 2015 x86_64 GNU/Linux
Думаю, этот случай применим ко многим различным типам серверного программного обеспечения.
На самом деле это не имеет большого значения новее файловые системы, такие как XFS и ext4, но в старых или неправильно настроенных файловых системах это может стать серьезной проблемой.
В старых файловых системах Linux, таких как ext3, каталог - это просто неупорядоченный список файлов.
То, что он неупорядочен, важно, потому что это означает, что единственный способ для системы найти файл в каталоге - это выполнить поиск от начала до конца.
Если каталог содержит 3000 файлов, потребуется средний 1500 сравнений, чтобы найти случайный файл в каталоге. Но если в каталоге 300 000 файлов, потребуется средний 150 000 сравнений, чтобы найти случайный файл в этом каталоге.
В любом случае, если запись каталога еще не кэширована в ОЗУ, она должна быть загружена с диска, что приведет к значительному увеличению времени доступа к файлу, пропорциональному размеру каталога. Очевидно, что небольшая зубочистка загружается быстрее, чем большая.
Таким образом, это много быстрее, если вы используете более иерархическую структуру каталогов для разделения большого количества файлов в уникальные каталоги.
XFS не страдает этой проблемой, поскольку использует хеш-таблица для поиска записей в каталоге. Таким образом, он может обрабатывать каталог с сотнями тысяч файлов почти так же легко, как каталог с одним файлом. Но у него по-прежнему есть штраф, заключающийся в необходимости загружать более крупную структуру данных с диска. Однако, если у вас достаточно оперативной памяти в системе, это не совсем практическая проблема.
Ext4 также использует хешированный индекс каталогов.
Многие файловые системы будут замедляться, когда один каталог содержит много (десятки, сотни тысяч или миллионы) файлов или подкаталогов в одном каталоге, и может даже быть жесткий верхний предел, но если и насколько сильно зависит от обоих выбранную файловую систему и операции ввода-вывода. Поищите в Википедии сравнение характеристик файловой системы.
Очевидно, что список и сортировка каталога с много файлы будут более дорогостоящими, но даже получение файла по имени может стать более дорогостоящим с более крупными каталогами.
Обычное решение - создать многоуровневую структуру подкаталогов на основе или производных от имени файла.
Насколько это важно, зависит от используемой файловой системы, а иногда и от других аспектов реализации вашего хранилища. Это также может зависеть от характера использования.
Производительность некоторых старых файловых систем очень сильно ухудшалась, когда количество файлов превышало 1000 или около того. В меньшей степени это относится к новым файловым системам, но это не полная проблема.
При большом количестве файлов узел каталога станет большим. Это нужно переписывать каждый раз, когда оно меняется. Это может повлиять на производительность.
Если ваше хранилище подключено к сети, то блокировка, связанная с записью в каталог, может стать проблемой. Например. если у вас есть кластер веб-серверов, совместно использующих большой каталог для хранения файлов сеансов, которые изменяются при каждом обращении к сети, это, вероятно, будет работать очень плохо, по существу сериализуя доступ, поскольку процессы ожидают блокировки узла каталога. Хеширование файлов сеанса в каталоги меньшего размера означает, что большинство обращений к файлам сеанса не будут иметь записи в данном сеансе, требующей блокировки.