Лучше сжать все данные или сжатые каталоги?
Я архивирую некоторые проекты, скажем, у каждого из них есть свой каталог:
projects
|- project-1
|- project-2
|- project-3
Я начал сжимать их следующим образом:
==== SITUATION 1 ====
projects
|- project-1.zip
|- project-2.zip
|- project-3.zip
и затем я начал задаваться вопросом, не лучше ли сжимать все данные в один zip-файл:
==== SITUATION 2 ====
projects.zip
|- project-1
|- project-2
|- project-3
или может сжать уже сжатые файлы?
==== SITUATION 3 ====
projects.zip
|- project-1.zip
|- project-2.zip
|- project-3.zip
Какая ситуация лучше (занимает меньше всего места)? Зачем? Зависит ли это от алгоритма сжатия? Я знаю, что сжатие одного сжатого файла мало чем может помочь, но скажем, 20 из них? Для меня ситуация 1 не выглядит хорошей идеей.
4 ответа
Я сомневаюсь, что разные схемы будут иметь большое значение, если честно, так как алгоритмы сжатия обычно рассчитывают только ограниченное количество, чтобы контролировать использование памяти.
Исключением является S3, который, скорее всего, будет больше по размеру, так как сжатие сжатого файла добавляет накладные расходы, но не может сжать.
Если вы хотите улучшить сжатие, ищите новые инструменты архивации, которые имеют лучшие алгоритмы. Например, 7-zip лучше, чем zip.
Что касается разницы между s1 и s2, я бы сказал, что это зависит от того, как вы, скорее всего, будете использовать архив в будущем, и от того, насколько велики они будут.
Действительно большие архивы - трудная задача (перемещение, открытие и т. Д.), И это, вероятно, будет более важным, чем сохранение нескольких кБ.
Кроме того, думая о долгосрочном хранении, не игнорируйте "гниль". Небольшая ошибка в большом архиве может быть разрушительной. Потеря одного проекта, вероятно, намного лучше, чем потеря их всех.
Однако вы можете взглянуть на что-то вроде RAR, которое допускает избыточность и разделение архивов. Это немного похоже на RAID5. Вы создаете несколько архивных файлов, каждый из которых имеет встроенную избыточность, так что вы можете потерять файл и при этом воссоздать исходные данные.
Прежде всего, помните об отличных аргументах @Julian Knight. Даже лучшее сжатие бесполезно, если ваш архив слишком большой для обработки или поврежден какими-то перевернутыми битами.
Если пространство является вашей основной задачей, возможно, стоит провести некоторые эксперименты с вашими конкретными данными и различными алгоритмами сжатия.
Кроме того, ваш третий подход действительно может привести к другому уменьшению размера. Я помню некоторые обсуждения ( см. Здесь) о сжатии файлов несколько раз с использованием разных алгоритмов. Автор сжимал сильно избыточные текстовые файлы и после экспериментов мог перейти от 100 ГБ к нескольким МБ. Обратите внимание, что его случай был немного особенным, но общая идея заключается в том, что в некоторых случаях итеративное сжатие может быть полезным.
Если вы хотите попробовать разные алгоритмы сжатия, вот несколько тестов, которые сравнивают скорость и степень сжатия:
Ситуация 3 отсутствует, потому что бессмысленно повторное сжатие архивов по тому же алгоритму.
Между ситуациями 1 и 2 последняя, безусловно, имеет больше шансов получить меньший архив, особенно когда вы используете больший размер словаря (словарь в простых словах - это область памяти, используемая для поиска и сжатия повторяющихся шаблонов в данных). Обычный старый ZIP может использовать только небольшой словарь размером 32 КБ, который, учитывая современное оборудование, слишком мал.
Формат RAR 5.0 для сравнения может использовать словарь 1 ГБ в 64-битных системах. Он также поддерживает сохранение идентичных файлов в качестве ссылок:
Если эта опция включена, WinRAR анализирует содержимое файла перед началом архивирования. Если найдено несколько идентичных файлов размером более 64 КБ, первый файл в наборе сохраняется как обычный файл, а все последующие файлы сохраняются как ссылки на этот первый файл. Это позволяет уменьшить размер архива, но накладывает некоторые ограничения на результирующий архив. Вы не должны удалять или переименовывать первый идентичный файл в архиве после создания архива, поскольку это сделает невозможным извлечение следующих файлов с использованием его в качестве ссылки. Если вы измените первый файл, следующие файлы также будут иметь измененное содержимое после распаковки. Команда извлечения должна включать первый файл для успешного создания следующих файлов.
Таким образом, если у вас много дублирующих файлов в ваших проектах, большой размер словаря в сочетании с надежным архивированием и описанной выше функцией, скорее всего, приведет к значительному уменьшению размера в ситуации 2. Конечно, применяются все общие предостережения относительно больших архивов, поэтому рекомендуется также включить запись восстановления.
Как сказали другие, ситуация 3 — худшая из всех. Первые два варианта примерно одинаковы, но ситуация 2 немного лучше из-за повторного использования некоторых метаданных (и, возможно, словаря).
Однако для целей архивирования все вышеперечисленное не подходит, поскольку формат zip не поддерживает сплошные архивы . 7z и rar по умолчанию используют сплошные архивы (архивы 7z сжимают каждый файл индивидуально или сжимают все вместе как один? ), поэтому степень сжатия намного лучше (потому что во многих файлах наверняка повторяются одни и те же шаблоны байтов). Точно так же, как и тыtar(т.е. создание надежного несжатого архива), затем перейдите к gz или bz2 для сжатия. OTOH zip сжимает каждый файл отдельно, поэтому будет проще извлечь отдельные файлы, но сжатый результат будет намного больше.
Поэтому вам следует использовать ситуацию 2, но перейти на 7z или rar.