У нас есть система, которая ежедневно генерирует буквально 5-10 тысяч XML-файлов. Это долгая история, но эта система пока не изменится.
В любом случае система выгружает эти XML-файлы (от 3 до 20 КБ каждый) в ОДНУ папку. Итак, представьте, как быстро эта папка начинает забиваться.
Я написал программу, которая берет файлы и организует их в иерархию формата год / месяц / день. Затем входит другая программа и удаляет все файлы старше 90 дней.
Вот в чем проблема. Наша система резервного копирования (опять же, что-то, что нельзя изменить) занимает ЧАСЫ для резервного копирования этих заархивированных папок, потому что там около 1 миллиона файлов. Резервная копия делает полную резервную копию (опять же, мы не можем изменить), и что происходит, резервная копия должна открывать и проверять КАЖДЫЙ XML-файл. Таким образом, скорость резервного копирования настолько мала, что оно фактически не завершается до резервного копирования на следующую ночь!
Итак, я сейчас беру ежемесячные папки и создаю архив 7z. Это хорошо работает. 200k файлов до одного файла. Однако мне приходится делать это вручную.
Также есть еще одна загвоздка. Мы не можем архивировать текущий месяц. Таким образом, всегда должно быть 30 дней (x 5 000–10 000) файлов, мгновенно «доступных для поиска».
Есть предложения, как лучше с этим справиться?
В моей голове промелькнуло следующее:
1) Напишите программу, чтобы взять предыдущий день и выгрузить в SQL. Затем добавьте файл в архив.
2) Какой-то тип файловой системы «живого архивирования», в которую можно переместить XML.
Спасибо.
Если это XML, можно ли их объединить перед сжатием? Затем они должны сжиматься лучше (лучше общий словарь символов). Вы могли бы делать почти то, что делаете сейчас, если объединяете дневные файлы в конце каждого месяца в один большой XML-файл месяца, или идете еще дальше и объединяете годы или даже за всю историю, кроме одного месяца. Во всех случаях вы затем сжимаете их, да.
На самом деле, это не похоже на то, что вы делаете что-то слишком плохо, за исключением того, что вам нужно написать несколько сценариев, чтобы делать что-то автоматически за вас.
Вы не упоминаете свою платформу ... если это Linux, почему бы не написать сценарий сортировки (который вы, кажется, уже делаете), который разбивает их на более мелкие каталоги, а затем запустить архив командной строки 7z, чтобы сжать эти каталоги до одного файл, затем сделайте резервную копию?
В качестве альтернативы вы можете создать «сервер резервного копирования», который отражает скопированный каталог по IP (что-то вроде drdb или rsync), тогда вы можете сделать резервную копию с этого сервера и освободить некоторые ресурсы на перегруженном сервере.
На самом деле, помимо поиска способов сократить количество создаваемых файлов, у вас есть ограниченные возможности. К каждой кирпичной стене, которую вы называете, добавлен тег, что с ней ничего нельзя поделать или изменить.
Если ваши данные за месяц должны быть доступны для мгновенного поиска, возможно, вы захотите изучить решение для базы данных или способ интеграции его с базой данных. Судя по всему, вы уже используете файловую систему в качестве специальной базы данных, и фактическое размещение информации в базе данных должно улучшить вашу производительность (и возможность ее резервного копирования).
вы имеете в виду logrotate? Это в основном для архивирования журналов, но может сработать для вашего сценария.
О вашем случае, какая у вас база данных? Может ли он поддерживать указанное вами количество открытого текста?
И зачем вам архив 7zip делать вручную? Почему бы вам не использовать cron, чтобы сделать это за вас?
Я знаю, что вы упомянули, что вы не можете изменить свою систему резервного копирования, но с учетом возникших у вас проблем, возможно, стоит пересмотреть решение для начала.
Также доступен rsnapshot. При этом используется rsync, который выполняет резервное копирование только измененных файлов. В вашем случае, если вы запускаете его ежедневно, он будет создавать резервные копии только файлов размером 5-10 тысяч, и вы также можете ограничить его до самого последнего месяца.
Если вам нужно что-то с возможностью поиска, я согласен с Бартом Сильверстримом о том, чтобы бросать содержимое в базу данных, поскольку резервные копии и базы данных следует рассматривать как две отдельные системы.
Вы можете попробовать использовать другую файловую систему (xfs) и настроить ее параметры.
Например: http://everything2.com/title/Filesystem+performance+tweaking+with+XFS+on+Linux
Также вы можете добавить несколько дисков и / или настроить более быстрый уровень RAID для повышения производительности, так как похоже, что у вас есть узкое место в IOPS.