У меня есть приложение, записывающее в каталог ext3, который со временем вырос примерно до трех миллионов файлов. Излишне говорить, что чтение списка файлов в этом каталоге невыносимо медленно.
Я не виню ext3. Правильным решением было бы позволить коду приложения писать в подкаталоги, такие как ./a/b/c/abc.ext вместо использования только ./abc.ext.
Я перехожу на такую структуру подкаталогов, и мой вопрос прост: примерно, сколько файлов я должен хранить в одном каталоге ext3, сохраняя при этом приемлемую производительность? Какой у вас опыт?
Или другими словами; предполагая, что мне нужно сохранить в структуре три миллиона файлов, на сколько уровней глубины должен ./a/b/c/abc.ext структура быть?
Очевидно, что на этот вопрос нельзя дать точного ответа, но я ищу оценку парка мячей.
Если у вас есть дистрибутив, поддерживающий dir_index возможность, то вы можете легко иметь 200 000 файлов в одном каталоге. Я бы оставил около 25000, на всякий случай. Без dir_index, постарайтесь держать его на уровне 5000.
Быть ОЧЕНЬ осторожно выбирайте разделение каталогов. "a / b / c" звучит для меня как рецепт катастрофы ...
Не создавайте вслепую структуру из нескольких каталогов, скажем, 100 записей на первом уровне, 100 записей на втором уровне, 100 записей на третьем. Я был там, сделал это, получил оболочку и пришлось ее реструктурировать, когда производительность упала с несколькими миллионами файлов. :-)
У нас есть клиент, который делал макет «несколько каталогов» и в итоге помещал от одного до пяти файлов в каталог, и это их убивало. От 3 до 6 часов, чтобы сделать «ду» в этой структуре каталогов. Спасителем здесь был SSD, они не хотели переписывать эту часть своего приложения, а SSD сократил это время с часов до минут.
Проблема в том, что каждый уровень поиска в каталогах требует поиска, а поиск очень дорог. Размер каталога также является важным фактором, поэтому иметь его меньше, чем больше, - это большая победа.
Отвечая на ваш вопрос о том, сколько файлов в каталоге, 1000, как я слышал, называют "оптимальными", но производительность на уровне 10 000 кажется хорошей.
Итак, я бы рекомендовал один уровень каталогов, каждый из которых представляет собой каталог длиной 2 символа, состоящий из прописных и строчных букв и цифр, для примерно 3800 каталогов на верхнем уровне. Затем вы можете хранить 14 миллионов файлов с этими подкаталогами, содержащими 3800 файлов, или около 1000 файлов на подкаталог для файлов 3M.
Я сделал подобное изменение для другого клиента, и это имело огромное значение.
Я бы посоветовал вам попробовать протестировать каталоги различных размеров с помощью инструмента для тестирования, например штемпель, потому что существует множество переменных, таких как размер кеша (как в ОС, так и в дисковой подсистеме), которые зависят от вашей конкретной среды.
Мое личное эмпирическое правило - стремиться к размеру каталога <= 20 КБ файлов, хотя я видел относительно приличную производительность до 100 КБ файлов / каталог.
У меня есть все файлы в папках, например:
uploads / [дата] / [час] /to.png
и нет проблем с производительностью.
http://en.wikipedia.org/wiki/Ext3#Functionality - Здесь упоминается, что каталог может иметь только приблизительно 32000 подкаталогов, но не упоминаются файлы.
http://roopindersingh.com/2008/05/10/ext3-handling-large-number-of-files-in-a-directory/
Также я ненавижу Experts Exchange, но я прочитал комментарий к этот вопрос что идеально иметь менее 10-15 000 на каталог.
Я могу подтвердить на довольно мощном сервере с большим количеством памяти при приличной нагрузке, что 70 000 файлов могут вызвать разного рода хаос. Я пошел, чтобы удалить папку кеша с 70k файлами в ней, и это заставило apache начать создавать новые экземпляры, пока он не достиг максимального значения 255, и система использовала всю свободную память (16 ГБ, хотя виртуальный экземпляр мог быть меньше). В любом случае, держать его ниже 25000 - вероятно, очень разумный шаг.
По моему опыту, лучший подход - заранее не переусердствовать с файловой структурой. Как упоминалось по крайней мере в одном другом ответе, существуют расширения файловой системы, которые имеют дело с проблемами производительности.
Проблема, с которой я сталкиваюсь чаще, - это удобство использования с административной стороны. Наименьший объем работы, который вы можете сделать, чтобы уменьшить количество файлов в каталоге, вероятно, вам нужен прямо сейчас.
sqrt (3_000_000) == 1732
Мне кажется, что пара тысяч файлов в одном каталоге звучит разумно. Будь сам судьей в своей ситуации. Для этого попробуйте разделить файлы на один уровень хэш-каталогов, чтобы среднее количество файлов в каталоге было примерно таким же, как и количество каталогов.
Учитывая ваш пример, это будет ./a/abc.ext, ./ab/abc.ext, ./abc/abc.ext, ....
Распространение файлов будет сильно зависеть от фактических имен файлов. Представьте, что вы применяете эту технику к каталогу из миллиона файлов, каждый из которых называется foobar???.txt. Есть способы добиться более равномерного распределения, например хеширование, основанное на значении определенного количества битов из суммы MD5 каждого файла, но я осмелюсь предположить, что это было бы излишним для того, что вы пытаетесь выполнить.
Хм я читал эта статья недавно. По сути, вы используете распространение вашего любимого алгоритма хеширования. Я начал играть с числами, MySQL подписанный INT имеет максимальное значение 2147483647. Вы также можете изменить желаемое количество файлов в каталоге и количество подкаталогов, чтобы выбрать окончательный вариант. количество-подкаталогов / файлов-на-каталог разделить для данного набора данных, но трудно найти эмпирические доказательства оптимальной организации каталогов / файлов. Эта статья дает некоторое представление о различиях в производительности файловых систем (некоторые интересные показатели), но ничего не говорит об оптимальной организации.
Я думаю, вы слишком много думаете об этом. Если бы вы даже выбрали один дополнительный уровень каталогов и смогли бы сбалансировать вещи равномерно, у вас было бы 1732 * каталогов и 1732 файла на каталог.
Если вы не планируете нуждаться в десятках миллиардов файлов, вы можете выбрать число от 1000 до 100000 и получить хорошие результаты.
* квадратный корень из 3 миллионов.