Приветствую,
Я пишу скрипты для обработки изображений с разных фото-сайтов. Сейчас я храню все эти данные в отдельных текстовых файлах в одном каталоге.
Каталог доступен в Интернете. Конечный пользователь обращается к веб-службе, которая возвращает путь к нужному пользователю файлу.
Мне было интересно, на каком этапе я увижу влияние на производительность, если все эти файлы будут в одном каталоге? (Если есть)
Производительность зависит от используемой файловой системы.
EXT3: физический предел - 32 000 файлов, но perf страдает и после нескольких тысяч файлов.
ReiserFS, XFS, JFS, BTRFS: они хороши для большого количества файлов в каталоге, поскольку они более современные и предназначены для обработки большого количества файлов (другие были разработаны еще в те времена, когда жесткие диски измерялись в МБ, а не в ГБ) . Производительность намного выше для большого количества файлов (вместе с ext4), поскольку они оба используют алгоритм типа двоичного поиска для получения нужного файла (другие используют более линейный алгоритм).
Я храню изображения для обслуживания веб-сервером, и у меня есть более 300 000 изображений в одном каталоге на EXT3. Проблем с производительностью не вижу. Перед настройкой я провел тесты с 500 КБ изображений в каталоге и произвольным доступом к файлам по имени, и не было значительного замедления с 500 КБ более чем 10 КБ изображений в каталоге.
Единственный недостаток, который я вижу, состоит в том, что для синхронизации новых со вторым сервером мне нужно запустить rsync по всему каталогу, и не может просто указать ему синхронизировать подкаталог, содержащий самую последнюю тысячу или около того.
Количество файлов в папке теоретически может быть безграничным. Однако каждый раз, когда ОС будет обращаться к определенной папке для поиска файлов, ей придется обрабатывать все файлы в папке. Если у вас меньше 500 файлов, вы можете не заметить никаких задержек. Но когда у вас есть десятки тысяч файлов в одной папке, простая команда списка папок (ls или dir) может занять слишком много времени. Когда к этим папкам можно получить доступ через FTP, это действительно будет слишком медленно ...
Проблемы с производительностью на самом деле зависят не от вашей ОС, а от скорости вашего системного процессора, емкости диска и памяти. Если у вас так много файлов, вы можете объединить их в один архив и использовать систему архивирования, оптимизированную для хранения большого количества данных. Это может быть ZIP-файл, но еще лучше, храните их как капли в базе данных с именем файла в качестве первичного ключа.
Мое практическое правило - разделять папки, если файлов более 1000 и папка будет просматриваться (например, через Интернет или проводник) или 5000 файлов в противном случае.
Как указывает @skaffman, ограничения зависят от операционной системы. Скорее всего, на вас повлияют ограничения старых ОС. Я помню, что старая версия Solaris была ограничена 32768 файлами на каталог.
Обычное решение - использовать какое-то хеширование, то есть сервер Cyrus imap разделяет пользователей по буквенному хешу:
/var/spool/imap/a/user/anna/
/var/spool/imap/a/user/albert/
/var/spool/imap/d/user/dan/
/var/spool/imap/e/user/ewan/
Если вы напрямую обращаетесь к файлу, количество файлов в каталоге не проблема скорости.
Количество файлов, которые вы можете создать в одном каталоге, зависит от используемой файловой системы. Если вы перечисляете все файлы в каталоге или выполняете поиск, сортировку и т. Д., Наличие большого количества файлов замедлит эти операции.
gbjbaanb ошибается в своем ответе о максимальном размере файла ext3. Обычно ext ограничивает количество файлов на вашем диске. Вы не можете создать больше файлов, чем у вас есть inode в вашей таблице inode. Он прав, предлагая reiserfs для большей производительности со многими файлами.
Проверена папка с 10К файлами в NTFS (Windows 7, 64 бит). Папка с изображениями 10K в любом виде (список, значок и т. Д.) Работает и прокручивается без заметной задержки.