Быстрый доступ к файлам в каталоге с 500 000 файлов

Question

У меня есть каталог с 500 000 файлов в нем. Я хотел бы получить к ним доступ как можно быстрее. Алгоритм требует, чтобы я неоднократно открывал и закрывал их (не может одновременно открываться 500 000 файлов).

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

Другой вариант - просто не беспокоиться об этом и надеяться, что ФС хорошо справится с поиском файлов в каталоге. Если это лучший вариант, то какой FS будет работать лучше всего. Некоторые шаблоны имен файлов выглядят быстрее, чем другие? например, 01234.txt против foo.txt

Кстати, все это в Linux.

Answer 1

Если ваша файловая система имеет значение ext3 , ваш каталог индексируется с помощью хешированного B-дерева, если включен dir_index. Это даст вам такой же толчок, как и все, что вы могли бы написать в своем приложении.

Если каталог проиндексирован, схема именования файлов не должна иметь значения.

http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

Answer 2

Пара идей:

a) Если вы можете управлять макетом каталога, поместите файлы в подкаталоги.

б) Если вы не можете перемещать файлы, то вы можете попробовать разные файловые системы, я думаю, что xfs может подойти для каталогов с большим количеством записей?

Answer 3

Традиционный способ сделать это - использовать хешированные подкаталоги. Предположим, что ваши имена файлов - это равномерно распределенные хэши, закодированные в шестнадцатеричном формате. Затем вы можете создать 256 каталогов на основе первых двух символов имени файла (например, файл 012345678 будет называться 01/2345678). Вы можете использовать два или даже больше уровней, если одного недостаточно.

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

Answer 4

Если у вас достаточно памяти, вы можете использовать ulimit, чтобы увеличить максимальное количество файлов, которые ваш процесс может открыть за один раз, я успешно справился со 100 000 файлов, 500 000 также должны работать.

Если это не вариант, постарайтесь убедиться, что в вашем кэш-памяти достаточно места для хранения всех записей. Кэш dentry - это отображение имени файла -> inode, которое ядро ​​использует для ускорения доступа к файлу на основе имени файла, доступ к огромному количеству различных файлов может эффективно исключить выгоду кэш-памяти dentry, а также привнести дополнительное снижение производительности. Ядро Stock 2.6 имеет хэш-память с 256 * МБ записями ОЗУ за раз, если у вас 2 ГБ памяти, вы можете использовать чуть более 500 000 файлов.

Конечно, убедитесь, что вы выполнили соответствующее профилирование, чтобы определить, действительно ли это вызывает узкое место.

Answer 5

Другой вопрос: сколько данных в файлах? SQL-сервер является опцией?