Можно ли (с точки зрения производительности) иметь сотни или тысячи файлов в одном каталоге Linux?

Question

Хорошо известно, что в Windows каталог со слишком большим количеством файлов будет иметь ужасную производительность при попытке открыть один из них.У меня есть программа, которая должна выполняться только в Linux (в настоящее время она работает на Debian-Lenny, но я не хочу конкретно говорить об этом дистрибутиве) и записывает много файлов в один каталог (который действует как хранилище).Под «многими» я подразумеваю десятки каждый день, имея в виду, что через год я ожидаю получить что-то вроде 5000-10000 файлов.Они должны быть сохранены (когда файл создан, он никогда не удаляется), и предполагается, что жесткий диск имеет необходимую емкость (если нет, его следует обновить).Эти файлы имеют широкий диапазон размеров, от нескольких КБ до десятков МБ (но не намного больше).Имена всегда являются числовыми значениями, генерируемыми постепенно.Меня беспокоит долговременное снижение производительности, поэтому я бы спросил:

• Можно ли записывать все в один каталог?Или мне стоит подумать о создании набора подкаталогов для каждого X-файла?
• Нужно ли требовать, чтобы для такого каталога использовалась определенная файловая система?
• Что было бы более надежной альтернативой?Специализированная файловая система?Какие?
• Какие-либо другие соображения / рекомендации?

Answer 1

Очень сильно зависит от файловой системы.

ext2 и ext3 имеют жесткое ограничение 32 000 файлов на каталог. Это несколько больше, чем вы просите, но достаточно близко, чтобы я не рисковал. Кроме того, ext2 и ext3 будут выполнять линейное сканирование каждый раз, когда вы обращаетесь к файлу по имени в каталоге.

ext4 предположительно исправляет эти проблемы, но я не могу поручиться за это лично.

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

Так что, если вам действительно нужно огромное количество файлов, я бы использовал XFS или, возможно, ext4.

Обратите внимание, что ни одна файловая система не заставит "ls" работать быстро, если у вас огромное количество файлов (если вы не используете "ls -f"), так как "ls" будет читать весь каталог и сортировать имена. Несколько десятков тысяч, вероятно, не так уж и много, но хороший дизайн должен превзойти то, что вам нужно на первый взгляд ...

Для приложения, которое вы описываете, я бы, вероятно, вместо этого создал бы иерархию, поскольку вряд ли это будет какое-либо дополнительное кодирование или умственное усилие для того, кто смотрит на него. В частности, вы можете назвать свой первый файл «00/00/01» вместо «000001».

Answer 2

Если вы используете файловую систему без индексации каталогов, то очень плохо иметь множество файлов в одном каталоге (скажем,> 5000).

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

Однако, довольно много инструментов, чтобы иметь много файлов в одном каталоге (например, «ls»)будет stat () всех файлов, что занимает много времени).Вы можете легко разделить его на подкаталоги.

Но не переусердствуйте.Не используйте многоуровневый вложенный подкаталог без необходимости, он просто использует много inode и замедляет операции с метаданными.

Я видел больше случаев "слишком большого количества уровней вложенных каталогов", чем я виделmsgstr "слишком много файлов в каталоге".

Answer 3

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

Просто используйте выбранную вами файловую систему.Создайте несколько случайных тестовых данных для 100, 1000 и 10000 записей.Затем измерьте время, которое требуется вашей системе для выполнения действия, которое вас беспокоит по времени (открытие файла, чтение 100 случайных файлов и т. Д.).

Затем вы сравниваете время и используете лучшее решение.(поместите их все в один каталог; поместите каждый год в новый каталог; поместите каждый месяц каждого года в новый каталог).

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

Answer 4

В дополнение к другим ответам, если огромным каталогом управляет известное приложение или библиотека, вы можете заменить его другим, например:

• a GDBM индексный файл; GDBM - это очень распространенная библиотека, предоставляющая индексированный файл, который связывает произвольный ключ (последовательность байтов) с произвольным значением (другая последовательность байтов).
• возможно, таблица внутри базы данных, такой как MySQL или PostGresQL. Будьте осторожны при индексации.
• другой способ индексации данных

Преимущества вышеуказанных подходов включают в себя:

1. производительность пространства для большой коллекции мелких предметов (менее килобайта каждый). Файловой системе нужен индекс для каждого элемента. Индексированные системы могут иметь гораздо меньшую степень детализации
2. производительность по времени: у вас нет доступа к файловой системе для каждого элемента
3. масштабируемость: индексированные подходы разработаны для удовлетворения больших потребностей: либо файл индекса GDBM, либо база данных может обрабатывать многие миллионы элементов. Я не уверен, что ваш подход к каталогу будет так же легко масштабироваться.

Недостатком такого подхода является то, что они не отображаются в виде файлов. Но, как ответ MarkR напоминает вам, ls ведет себя очень плохо на огромных каталогах.

Если вы придерживаетесь файлового подхода, многие программы, использующие большое количество файлов, организуют их в подкаталоги, такие как aa/ ab/ ac/ ... ay/ az/ ba/ ... bz/ ...

Answer 5

Плохо для производительности иметь огромное количество файлов в одном каталоге.Проверка на наличие файла обычно требует O (n) сканирования каталога.Создание нового файла потребует того же сканирования с заблокированным каталогом, чтобы предотвратить изменение состояния каталога перед созданием нового файла.Некоторые файловые системы могут быть умнее в этом (используя B-деревья или что-то еще), но чем меньше связей у вашей реализации с сильными и слабыми сторонами файловой системы, тем лучше для долгосрочного обслуживания.Предположим, кто-то может решить запустить приложение в сетевой файловой системе (устройство хранения или даже облачное хранилище).Огромные каталоги - ужасная идея при использовании сетевого хранилища.

Answer 6

• Можно ли записывать все в один каталог? Или мне стоит подумать о создании набора подкаталогов для каждого X-файла?

По моему опыту, единственное замедление работы каталога с большим количеством файлов - это если вы делаете такие вещи, как получение списка с помощью ls. Но в основном это вина ls, есть более быстрые способы составления списка содержимого каталога с использованием таких инструментов, как echo и find (см. Ниже).

• Должен ли я требовать использование определенной файловой системы для такого каталога?

Я так не думаю относительно количества файлов в одном каталоге. Я уверен, что некоторые файловые системы работают лучше с большим количеством маленьких файлов в одном каталоге, в то время как другие лучше справляются с большими файлами. Это также вопрос личного вкуса, сродни vi против emacs. Я предпочитаю использовать файловую систему XFS, так что это мой совет. : -)

• Что было бы более надежной альтернативой? Специализированная файловая система? Что?

XFS определенно надежна и быстра, я использую ее во многих местах, в качестве загрузочного раздела, табличных пространств оракула, пространства для управления исходным кодом, как вы его называете. Ему немного не хватает производительности удаления, но в остальном это безопасная ставка. Кроме того, он поддерживает увеличение размера, пока он еще установлен (на самом деле это требование). То есть вы просто удаляете раздел, воссоздаете его в том же начальном блоке и любом другом конечном блоке, который больше исходного раздела, а затем запускаете xfs_growfs на нем с подключенной файловой системой.

• Какие-либо другие соображения / рекомендации?

см. Выше. С добавлением, что наличие 5000-10000 файлов в одном каталоге не должно быть проблемой. На практике это не произвольно замедляет файловую систему, насколько я знаю, за исключением таких утилит, как "ls" и "rm". Но вы могли бы сделать:

find * | xargs echo
find * | xargs rm

Преимущество того, что дерево каталогов с файлами, например, каталог «a» для имен файлов, начинающихся с «a» и т. Д., Даст вам внешний вид, выглядит более организованным. Но тогда у вас меньше обзора ... Так что то, что вы пытаетесь сделать, должно быть хорошо. : -)

Я забыл сказать, что вы могли бы рассмотреть возможность использования чего-то, называемого "разреженными файлами" http://en.wikipedia.org/wiki/Sparse_file