Найти файлы в огромной директории - очень медленно
У меня есть каталог с файлами. Архив очень большой и имеет 1,5 миллиона PDF-файлов внутри.
каталог хранится на сервере IBM i с ОС V7R1, и машина новая и очень быстрая.
Файлы названы так:
invoice_[custno]_[year']_[invoice_number].pdf
invoice_081500_2013_7534435564.pdf
Нет, я пытаюсь найти файлы с помощью команды поиска с помощью командной консоли.
find . -name 'invoice_2013_*.pdf' -type f | ls -l > log.dat
Команда заняла много времени, поэтому я прервал операцию безрезультатно.
Если я попробую это с меньшими каталогами, все работает отлично.
Позже я хочу получить работу, которая запускается каждый день и находит файлы, созданные за последние 24 часа, но я, как правило, работает так медленно, что могу забыть об этом.
5 ответов
Этот вызов никогда не будет работать, потому что ls
не читает имена файлов из stdin
,
Возможные решения:
Использовать find
Опция встроенного списка утилиты:
find . -name 'invoice_2013_*.pdf' -type f -ls > log.dat
Использовать find
утилиты -exec
возможность выполнить ls -l
для каждого соответствующего файла:
find . -name 'invoice_2013_*.pdf' -type f -exec ls {} \; > log.dat
Передайте имена файлов в xargs
утилита и дайте ей выполнить ls -l
с именами файлов в качестве параметров:
find . -name 'invoice_2013_*.pdf' -type f | xargs ls -l > log.dat
Поиск по шаблону из 1,5 миллионов файлов в одном каталоге будет неэффективным в любой файловой системе.
Для просмотра только списка новых записей в каталоге, вы можете рассмотреть возможность ведения журнала в каталоге. Вы бы указали INHERIT(*NO)
чтобы предотвратить ведение журнала всех файлов в каталоге, а также. Затем вы можете просто извлечь последние записи журнала с помощью DSPJRN, чтобы узнать, какие объекты были добавлены.
Я не думаю, что я поместил бы больше чем 15k файлов в один каталог. У некоторых утилит QShell возникают проблемы с файлами размером около 16 КБ. Но я не уверен, что буду хранить их в каталоге в любом случае, за исключением, может быть, для более чем 16 МБ, если это значительная часть общего объема. Возможно, я бы хотел сначала сохранить их в CLOB /BLOB в базе данных.
Хранение в виде отдельных потоковых файлов приводит к проблемам с правами владения и правами, которые необходимо решить. Некоторые профили получают записи в таблицу собственных объектов, и я ожидаю, что этот профиль станет довольно большим. Возможно добраться до одного или нескольких пределов.
Храня в базе данных, вы переходите на один принадлежащий объект.
Или, возможно, несколько похожих объектов... Может быть процесс очистки / архивирования, который перемещает строки во вторичную или третичную таблицу. Трудно догадаться, как это может быть необходимо структурировать, если вообще.
Экономия может также принести пользу, особенно SAVSECDTA и SAV. Безопасность данных значительно снижена. А сохранение таблицы 4 ГБ происходит быстрее, чем сохранение тысячи объектов 4 МБ (или любой другой разбивки).
Помимо определения того, как исходная установка и реализация будут проходить в вашей среде, большая сложная часть может включать волатильность. Если это стабильные объекты с относительно небольшим количеством изменений и небольшим удалением, все должно быть в порядке. Но если BLOB-объекты часто модифицируются, это может вызвать проблемы, когда таблица занимает значительную долю емкости DASD. Он становится особенно грубым, когда он превышает размер свободного пространства DASD, и требуется повторная организация. С низкой волатильностью это гораздо меньше проблем.
Чтобы улучшить быстрый процесс поиска и сохранения файла или конкретной части кода из огромного каталога, используйте приведенный ниже код.
INHERIT(*NO)
Как правило, в таких случаях создаются подкаталоги, возможно, с использованием первой буквы каждого файла. размер каждого подкаталога..