Komprimační program 7-ZIP

7zip

Domovská stránka programu je www.7-zip.org, vlastní projekt je umístěn na Source Forge, kde najdete i jeho portabilní verzi.

7zip je zajímavý ze dvou hledisek:

1. Umí velmi dobře komprimovat data. Algoritmus LZMA dosahuje nejvyššího mně známého kompresního poměru.
2. Je to všeuměl, který si kromě vlastního formátu 7Z umí poradit i se soubory RAR, CAB, ZIP, GZIP, TAR, BZIP2, RPM, DEB, CPIO, ARJ. Formáty RAR, CAB, ARJ, DEB, RPM umí však pouze rozbalovat.

Použité algoritmy

Nativní algoritmus 7-zipu je modifikace Lempel-Ziv metody nazývaná LZMA. Program implementuje i metody převzaté z jiných programů. Za zmínku stojí modifikace metody PPMd převzaté ze stejnojmenného programu. Tato metoda má poskytovat výborné výsledky při komprimaci textových souborů.

Druhá metoda, která stojí za zmínku, je Deflate64. Deflate64 je vylepšením metody Deflate, která je známá především z rodiny komprimačních programů odvozených od PKZIPu 2.0. Tato metoda se používá jako preferovaná u zip archivů s rozšířením zip64, v dnešní době se však ona ani takto rozšířené archivy prakticky nepoužívají. 7zip tak nabízí jediný možný prostředek k jejímu otestování v prostředí UNIXu.

Třetí věcí, která mne zaujala, je preprocesor. Každý kvalitnější komprimační program, např. rar nebo ace, obsahuje několik preprocesorů, které po auto detekci vstupního formátu data upravují do lépe komprimovatelného tvaru. Obyklé jsou preprocesory pro obrazová, zvuková či textová data. 7-zip nic takového sice nemá, ale má dva preprocesory pro komprimaci Intel binárek. Jednoduší verze BCJ upravuje CALL a JUMP instrukce, rožšířená verze BCJ2 přidává navíc instrukci JCC.

Test č. 1 – zdrojové texty

Při komprimaci zdrojových textů je nejdůležitější maximalizovat kompresní poměr, abychom následně minimalizovali počet přenesených dat po síti a výdaje s tím spojené. Doba komprese v tomto případě nehraje moc velkou roli. Uživatelé však musí mít možnost dekomprimovat námi zabalené archivy na různých platformách. Open Source komprimační program je v tomto případě holou nutností.

Uživatelé jsou ale často velmi konzervativní. Ze své zkušenosti mohu potvrdit, že při nabídce jednoho programu v několika formátech (gzip, rzip, bzip2) si vybírají tradiční gzip, i když bzip2 je dnes nainstalován na každém Linuxu. Poté, co jsem nabídku gzipů zrušil, počet downloadů se snížil a zvýšil se až poté, co jsem tam gzipy vrátil.

postgresql 7.4.1 tarball 36444160 bajtu

Přepínač –7 je poslední u gzipu, který se ještě vyplatí. Vyšší stupně komprese podstatně prodlouží čas komprimování, a tak je lepší použít místo gzipu bzip2, který to zvládne lépe a rychleji. U Bzipu2 jsou nižší stupně komprese výhodné jen při nedostatku operační paměti. 7zip dosahuje o stupeň lepšího komprimačního poměru ve srovnání s RARem, je však o dost pomalejší. Pomalost 7zip je pravděpodobně hlavním důvodem, proč je ve warez komunitě doposud preferován Rar3. 7zip v režimu fast se nevyplatí, místo toho je lepší použít bzip2 a nekomplikovat si život s 7z formátem. Zajímavé je, že čas metody PPMd je konstantní a nezávisí na nastavené velikosti dictionary size. Metoda Deflate64 ukázala, že ostatním metodám dnes již nestačí.

Test č. 2 – filesystém dump

Filesystémové dumpy se obvykle komprimují přes pipe. Pokud program tuto možnost neposkytuje (7z, rzip), stává se pro tento účel nepoužitelným. Komprimační program navíc musí být natolik rychlý, aby se na něj nemuselo při zálohování zbytečně čekat. V praxi se zálohování optimalizuje za účelem dosažení co nejkratší zálohovací doby, nikoliv minimálního objemu uložených dat. Komprimace se provádí především proto, aby se data vešla na požadovaný nosič. Různé druhy páskových zálohovacích zařízení umějí provádět vlastní kompresi. Kompresní poměr bývá 2:1.

Nekomprimovaná velikost 55521280

Test č. 3 – pgsql databázový dump

Tato databáze neobsahovala žádné položky typu řetězec. Soubor obsahoval pouze čísla v ascii kódování. Nekomprimovaná velikost 98072648 Bajtů.

Jak probíhá zálohování databází v praxi

Výše zmíněná databáze o cca dvou milionech řádků zabírá na disku 189 MB. Její dump má však velikost pouze 98 MB. Dumpovat indexy není potřeba, ty lze znovu jednoduše vytvořit po importu dat. Každá řádka navíc obsahuje kromě vlastních dat také interní databázové struktury, jejichž overhead je značný, zejména pokud ukládáme krátké řádky. Numerické řádky jsou krátké. Databáze navíc obsahují transakční žurnály a temporary tablespace, které se rovněž nedumpují. V našem případě do velikosti nejsou započítány. Jejich velikost je minimálně dalších 50 MB. Takže provedením dumpu zmenšíme objem dat v poměru o něco větším než 2:1. Tato data se pak zakomprimují, což jak dále uvidíte, jde velmi snadno. Obyčejný gzip je smrskne v poměru 10:1. Já doporučuji používat k jejich kompresi rar. Kromě lepšího komprimačního poměru 20:1 umí přidávat do archivu media recovery data, která se používají v případě chyb při čtení. Výsledkem akce jsou data slisovaná v poměru více než 40:1. Tento objem dat lze již bez problémů napálit na DVD. Právě jste si přečetli další díl mého seriálu o databázích mírně ztrátově zkomprimovaný.

Tady se již PPMd algoritmus hezky vytáhl. Osobně jsem byl překvapen těsným rozdílem bzip2/rar, který bývá většinou mnohem větší.

Dekomprese

Závěr

Ve warez komunitě 7zip moc velký úspěch nezaznamenal. Uvidíme, jak si povede v Open Source komunitě. Komprimační poměr má výborný. Bohužel je ve srovnání s bzipem2 při komprimaci o dost pomalejší. Jak se říká, není růže bez trní. Své místo by však určitě našel při distribuci velkých balíků, jako např: Open Office, Mozilla, Firebird, Linux kernel, protože tam doba komprese není tak podstatná a v dekompresi se bzipu2 vyrovná.