Сколько файлов я могу поместить в каталог? - PullRequest
529 голосов
/ 21 января 2009

Имеет ли значение, сколько файлов я храню в одном каталоге? Если да, сколько файлов в каталоге слишком много, и каково влияние наличия слишком большого количества файлов? (Это на сервере Linux.)

Фон: у меня есть веб-сайт фотоальбома, и каждое загруженное изображение переименовывается в 8-шестнадцатеричный идентификатор (скажем, a58f375c.jpg). Это делается для того, чтобы избежать конфликтов имен файлов (например, если загружено много файлов «IMG0001.JPG»). Исходное имя файла и любые полезные метаданные хранятся в базе данных. Сейчас у меня где-то около 1500 файлов в каталоге изображений. Это приводит к тому, что перечисление файлов в каталоге (через FTP или SSH-клиент) занимает несколько секунд. Но я не вижу, что это имеет какое-либо влияние, кроме этого. В частности, похоже, что скорость передачи файла изображения пользователю не влияет.

Я думал об уменьшении количества изображений, создав 16 подкаталогов: 0-9 и a-f. Затем я переместил бы изображения в подкаталоги, основываясь на том, какой была первая шестнадцатеричная цифра имени файла. Но я не уверен, что для этого есть какая-либо причина, кроме случайного перечисления каталога через FTP / SSH.

Ответы [ 21 ]

5 голосов
/ 21 января 2009

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

Например, F-Spot хранит файлы фотографий как YYYY \ MM \ DD \ filename.ext, что означает, что самый большой каталог, с которым мне приходилось иметь дело при манипулировании моей коллекцией ~ 20000 фотографий, составляет около 800 файлов. Это также делает файлы более легкими для просмотра из стороннего приложения. Никогда не думайте, что ваше программное обеспечение - единственное, что будет иметь доступ к файлам вашего программного обеспечения.

4 голосов
/ 22 декабря 2018

У меня была такая же проблема. Попытка сохранить миллионы файлов на сервере Ubuntu в ext4. Закончились мои собственные тесты. Выяснилось, что плоский каталог работает намного лучше, но гораздо проще в использовании:

benchmark

Написал статью .

4 голосов
/ 22 января 2014

ext3 на самом деле имеет ограничения на размер каталога, и они зависят от размера блока файловой системы. Существует не «максимальное количество» файлов для каждого каталога, а «максимальное количество блоков, используемых для хранения записей в файлах». В частности, размер самого каталога не может превышать b-дерево высоты 3, и разветвление дерева зависит от размера блока. Смотрите эту ссылку для некоторых деталей.

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

Недавно меня укусило это за файловую систему, отформатированную с 2K-блоками, которая необъяснимым образом получала сообщения ядра с полным каталогом warning: ext3_dx_add_entry: Directory index full!, когда я копировал из другой файловой системы ext3. В моем случае каталог с просто 480 000 файлов не удалось скопировать в место назначения.

4 голосов
/ 21 января 2009

Вопрос сводится к тому, что вы собираетесь делать с файлами.

В Windows любой каталог с более чем 2k файлами имеет тенденцию открываться медленно для меня в Проводнике. Если это все файлы изображений, при просмотре миниатюр более 1К имеют тенденцию открываться очень медленно.

Одно время системный лимит составлял 32 767. Сейчас он выше, но даже это слишком много файлов для обработки за один раз в большинстве случаев.

3 голосов
/ 21 января 2009

Я помню, как запустил программу, которая создавала огромное количество файлов на выходе. Файлы были отсортированы по 30000 за каталог. Я не припоминаю каких-либо проблем с чтением, когда мне приходилось повторно использовать полученный вывод. Он был на 32-битном ноутбуке Ubuntu Linux, и даже Nautilus отображал содержимое каталога, хотя и через несколько секунд.

файловая система ext3: Аналогичный код в 64-битной системе хорошо справлялся с 64000 файлами на каталог.

2 голосов
/ 17 апреля 2015

Я предпочитаю так же, как @ armandino . Для этого я использую эту маленькую функцию в PHP для преобразования идентификаторов в путь к файлу, который дает 1000 файлов на каталог:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

или вы можете использовать вторую версию, если хотите использовать буквенно-цифровую:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

Результаты:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Как видно из версии $int, каждая папка содержит до 1000 файлов и до 99 каталогов, содержащих 1000 файлов и 99 каталогов ...

Но не забывайте, что для многих каталогов можно ускорить процесс резервного копирования. Не стесняйтесь тестировать от 1000 до 10000 файлов в каталоге, но не добавляйте намного больше, так как у вас будет очень много времени доступа, если вы хотите читать файл каталога по файлу (FTP-клиенты, функции чтения файлов и т.

Наконец, вы должны подумать о том, как уменьшить общее количество файлов. В зависимости от вашей цели вы можете использовать CSS-спрайты для объединения нескольких крошечных изображений, таких как аватары, значки, смайлики и т. Д., Или, если вы используете много небольших не мультимедийных файлов, рассмотрите возможность их объединения, например в формате JSON. В моем случае у меня были тысячи мини-кешей, и в конце концов я решил объединить их в пакеты по 10 штук.

2 голосов
/ 26 ноября 2010

Я столкнулся с подобной проблемой. Я пытался получить доступ к каталогу с более чем 10000 файлов в нем. Создание списка файлов и выполнение команд любого типа для любого из файлов заняло слишком много времени.

Я придумал небольшой скрипт php, чтобы сделать это для себя, и попытался найти способ предотвратить его превышение в браузере.

Ниже приведен скрипт php, который я написал для решения проблемы.

Список файлов в каталоге со слишком большим количеством файлов для FTP

Как это помогает кому-то

2 голосов
/ 21 января 2009

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

1 голос
/ 24 мая 2016

То, что большинство ответов выше не показывают, - это то, что не существует ответа «Один размер подходит всем» на первоначальный вопрос.

В современной среде у нас большой конгломерат различного аппаратного и программного обеспечения - некоторые 32-битные, некоторые 64-битные, некоторые современные, некоторые проверенные и надежные - надежные и никогда не меняющиеся. К этому добавляются различные старые и новые аппаратные средства, старые и новые операционные системы, разные поставщики (Windows, Unixes, Apple и т. Д.), А также множество утилит и серверов. Поскольку аппаратное обеспечение улучшилось, а программное обеспечение преобразовано в 64-битную совместимость, неизбежно произошла значительная задержка, чтобы все части этого очень большого и сложного мира хорошо играли с быстрым темпом изменений.

ИМХО, нет единого способа решить проблему. Решение состоит в том, чтобы исследовать возможности, а затем методом проб и ошибок найти то, что лучше всего подходит для ваших конкретных потребностей. Каждый пользователь должен определить, что работает для его системы, а не использовать подход к формам печенья.

Например, у меня есть медиа-сервер с несколькими очень большими файлами. В результате получается всего около 400 файлов, заполняющих диск объемом 3 ТБ. Используется только 1% инодов, но используется 95% от общего пространства. Кто-то другой, с большим количеством файлов меньшего размера, может исчерпать иноды, прежде чем они приблизятся к заполнению пространства. (На файловых системах ext4, как правило, 1 индекс используется для каждого файла / каталога.) Хотя теоретически общее количество файлов, которые могут содержаться в каталоге, практически бесконечно, практичность определяет, что общее использование определяет реалистичные единицы, а не только возможности файловой системы.

Я надеюсь, что все различные ответы, приведенные выше, способствовали мысли и решению проблем, а не создавали непреодолимый барьер для прогресса.

0 голосов
/ 16 февраля 2014

Нет единой цифры, которая "слишком много", если она не выходит за пределы ОС. Однако чем больше файлов в каталоге, независимо от ОС, тем больше времени требуется для доступа к любому отдельному файлу, а на большинстве ОС производительность нелинейная, поэтому для поиска одного файла из 10000 требуется более чем в 10 раз больше времени. затем найти файл в 1000.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...