Как я экспериментировал со сжатием данных при помощи 7-Zip и что из этого вышло

Предисловие

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

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

Потом идет сбалансированное сжатие данных, тут уже идет упор на максимальную степень сжатия данных при минимальном потреблении ресурсов и затрат времени, это уже в основном пользовательская зона с архивами zip, 7-zip и им подобных.

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

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

Те же видеокарты имели много алгоритмов реализованных аппаратно, но с приходом унифицированных шейдерных ядер видеокарты способны аппаратно исполнять разнообразные задачи, те же алгоритмы трассировки лучей могут иметь разнообразные вариации и исполняться даже на старых HD4870 видеокартах аппаратно, было бы желание у разработчика реализовать алгоритм который будет работать на такой старой видеокарте, особенно учитывая что асинхронность вычислений аппаратно адекватно реализована только начиная с видеокарт серии HD7900 и RTX2000 (зачатки в GTX900), но это уже другая тема.

На практике основной массе людей интересен именно вариант программной реализации которые предлагают разнообразные архиваторы, хорошее, но быстрое сжатие при помощи ЦП.

Я же буду искать максимальный уровень сжатия, но обычными пользовательскими инструментами созданными для достижения баланса, в случае с обычными архиваторами просто не выйдет дойти до безумных сроков архивирования как можно получить используя максимальные степени сжатия x265 что специализирован на сжатии видео...

Многие просто сжимают архивы на стандартных параметрах сжатия которые предлагает архиватор, но это не мой путь, в моем случае архивы нужны только для двух целей:
1) Сжать десятки и сотни тысяч файлов максимально быстро с минимальными затратами ресурсов при этом иметь к файлам быстрый доступ, это нужно чтобы не создавать сильную фрагментацию основной файловой системы, вопрос производительности и порядка.
2) Сжать данные на хранение, чтобы освободить место, быстрый доступ к данным не нужен, тут уже вопрос длительного хранения прежде чем удалить данные когда они окончательно потеряют смысл существования.

Сжимать быстро и с легким доступом к файлам можно старым добрым Deflate (ZIP), либо вообще прибегнуть к сжатию NTFS, но работает оно только при размере кластера 4КБ и проблему фрагментации только усугубляет многократно.

Сжимать для экономии места помогает уже LZMA2 (7-Zip), но быстрый доступ к файлам при хорошей степени сжатия не выйдет достичь.

WinRAR я не могу рекомендовать к использованию учитывая лицензионное соглашение данного архиватора, да и преимуществ в степени сжатия я не заметил за RAR относительно LZMA2 (7-Zip), и сравнений прямых с RAR не будет просто потому что у меня нет никакого желания засорять свою операционную систему подобным софтом и наблюдать окошки пробного периода что усердно напоминают какой пользователь плохой не отстегнул разработчикам денег.

RAR конечно предусматривает рудимент под названием "информация для восстановления", но на практике он не имеет никакой практической ценности и не гарантирует восстановление поврежденных архивов, и я не вижу никакого смысла ради этого покупать "лицензию" на использование WinRAR, особенно учитывая что есть 7-Zip с гораздо более адекватными условиями использования.

Есть множество других архиваторов, но в данной статье использовать я буду только 7-Zip, другие архиваторы я не использую.

Если вы впервые слышите про данный архиватор спешу предостеречь от сторонних сайтов на которые обязательно выведет поисковик, чтобы не набраться вирусов и "специальных предложений" софт следует скачивать только с официального сайта разработчика, но это только если разработчик софта не помешан на заработке денег любыми методами, в случае архиватора адрес (7-zip.org), этот адрес указан и в Википедии.

Однако есть еще 7-Zip Zstandart (github.com/mcmilk/7-Zip-zstd), это по сути тот же 7-Zip, но более функциональный, именно такой у меня установлен версии 21.02 ZS v1.5.5 R1 (x64).

Большинству обычных пользователей вряд ли будет интересна такая реализация архиватора, и я бы рекомендовал использовать официальный самый обычный 7-Zip, но тут уже каждый решает сам что использовать.

Я же буду экспериментировать с алгоритмами сжатия, чтобы найти наиболее полезный лично для меня, тем более архиватор 7-Zip так же и под Linux существует в отличие от других поделок, хотя там вообще своя атмосфера.

7-Zip и настройки

Первым делом я определился с данными над которыми буду проводить эксперименты, это мой старый проект на C++ включая скомпилированные версии программы и папка с PSD/PNG файлами.

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

Настройки архиватора разные в зависимости от алгоритма и контейнера (.zip, .7z и т.п.):

И чтобы самому не ввести себя в заблуждение я буду настройки выводить в название архива:

Zip и нюансы

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

Чем больше размер слова тем меньше размер архива выходит, но разница не является существенной, гораздо существеннее влияет настройка степени сжатия, но степени 1 и 4 сработали одинаково, как и ряд других.

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

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

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

И пару слов про потоки, чем больше потоков использует архиватор тем больше памяти нужно для работы, и чем больше размер словаря тем больше памяти нужно для работы, используемый объем ОЗУ легко может превышать 200гб при большом размере словаря с 20+ потоками при сжатии большого объёма информации...

Zip

Старый добрый Zip, минимум памяти для распаковки, сжимает посредственно, работает быстро, идеально для быстрой упаковки с последующим быстрым доступом.

LZMA2

Так же как и Deflate при увеличении размера слова размер архива выходит меньше, но разница небольшая.

Используя 4 потока или более архив имеет размер слегка больше чем при использовании 1-3 потоков.

Теперь в названии архива я пишу еще и количество потоков которые были выставлены для работы над архивом...

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

При сжатии C++ проекта потребовался размер словаря 256МБ для достижения лучшего результата.

Zstandart

Далее я решил проверить Zst алгоритм, настроек немного, но сжимает очень быстро до 11 уровня сжатия включительно, использует только 1 поток даже если указать больше.

Brotli

Почему бы и нет?

Настроек мало, в отличие от LZMA2 количество потоков никак не влияет на результат, феноменального потребления памяти не замечено, как и уровня сжатия.

Тратит очень много вычислительных ресурсов при максимальном уровне сжатия 11.

LZ4 и LZ5

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

LZ4 менее прожорливый в плане вычислительных ресурсов.

С PSD/PNG файлами лучше справился LZ4, но с проектом C++ лучше справился уже LZ5, хотя обеим далеко до уровня LZMA2.

LIZv1

Еще один сомнительный алгоритм для сжатия данных, при "ультра" 29 уровне сжатия размер иногда выходит больше чем при "максимальном" 27 уровне...

PPMd

Работает только в 1 поток, степень сжатия не повлияла на результат, размер слова лучше не трогать...

Весьма нестабильные результаты с данным алгоритмом, а учитывая что он значительно уступил LZMA2 то использовать его смысла нет в моем случае.

BZip2

Еще один аутсайдер при моем наборе исходных данных...

Скорость архивации

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

Сдвинуть ситуацию с мертвой точки удалось, но этого еще недостаточно...

Папка с обоями для рабочего стола позволила задействовать все 12 потоков, главное не увлекаться с размером словаря и количеством потоков, иначе можно не заметить как 32ГБ ОЗУ будут забиты под завязку...

Результаты

Я собирался первым делом сравнить результаты скорости архивирования, но LZMA2 не способен использовать полноценно более двух потоков.

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

В общем реальность оказалась гораздо более сурова чем встроенный бенчмарк, что легко грузит множество потоков выдавая попугаи для измерения "мужского достоинства"...

Если не задалось с производительностью, значит посмотрим что в плане сжатия, да, простое копирование в контейнер ".7z" ничего не сжимает, такой режим полезен для избавления основной файловой системы от сильной фрагментации.

Но перейдем к результатам сжатия разных алгоритмов.

Только LZMA2 и Zstandart хорошо справились с разными данными, Broti Лучше сжимает графику, а PPMd лучше сжал проект C++ и провалился с файлами PSD/PNG.

На один уровень с LZMA2/Zstandart смог выйти только алгоритм Broti, причем только при упаковке C++ проекта.

Заключение

Замену алгоритму LZMA2 к сожалению я не нашел, только Zstandart смог приблизиться по уровню сжатия, но этого алгоритма нет в стандартном 7-Zip, а значит будут сложности с открытием на системах без установленного 7-Zip Zstandart.

Так как требуемый объём памяти зависит от размера словаря и слегка превышает его, по умолчанию 7-Zip использует 16МБ размер словаря, а этого как показала практика недостаточно для эффективного сжатия, оптимальный размер выходит от 64МБ и до 512МБ, больше я не рекомендую использовать ибо для распаковки архива с 512МБ словарем потребуется около 530МБ ОЗУ.

Сжимать на длительное хранение следует в непрерывном режиме, конечно придется весь архив распаковать для открытия одного файла из архива, но разве это критично для архивов созданных ради длительного хранения, особенно если размер архива относительно маленький?

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

В любом случае для архивации с быстрым доступом к файлам следует использовать что-то более простое чем LZMA2, например старый добрый Zip (Deflate), а с LZMA2 извращаться не стоит создавая его прерываемым и пытаясь экономить вычислительные ресурсы.

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

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

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

Флешки и SSD я не могу советовать для долговременного хранения информации, электрический заряд в полупроводниковых затворах имеет свойство утечки со временем, в отличие от магнитного поля жестких дисков, особенно старых моделей HDD.

Так или иначе я продолжу и дальше использовать 7-Zip и LZMA2 алгоритм, только размер словаря буду использовать 128-256МБ вместо стандартных 16МБ, да и размер слова имеет смысл использовать 256 вместо стандартных 32, по уровню производительности на глаз я не заметил особой разницы, а вот разницу в конечном результате отлично видно.

10-25% сжатия просто за счет оптимальной настройки архиватора лишними не бывают .

На этом все, благодарю за внимание.