Qual è la differenza tra i diversi sistemi di "compressione"?


9

Ho sempre usato TAR e ZIP per la compressione, ma recentemente ho sentito parlare *.Zdell'algoritmo di compressione. Ciò ha sollevato una domanda per me:

Con tutti questi sistemi di compressione, qual è il migliore per uso generale e compressione?

Eseguendo alcuni test, ho scoperto che tar, come ho scoperto, NON si comprime realmente (se non diversamente specificato). Significato, a cosa serve rispetto ad altri metodi di compressione?

Sono già a conoscenza che ZIP è il sistema di compressione più diffuso, ma devo usare al posto di *.Z, *.7z, .tar, o .tar.<insert ending here>?

Riepilogo post:

  1. Dovrei usare *.tar, *.Z, *.7z, .tar, o .tar.<insert ending here>per la migliore compressione?
  2. Se plain *.tarnon si comprime, perché lo usiamo?

EDIT: non tutti gli algoritmi consentono l'archiviazione delle autorizzazioni Linux (da quello che ho imparato). Cosa fare, e c'è una sorta di hack (o script) che potrei usare per archiviare le autorizzazioni?


Non c'è bisogno di dire quella roba, basta scegliere quello più votato o quello che hai trovato più utile :)
Seth

Risposte:


17

tarsta per archivio nastro. Tutto ciò che fa è comprimere i file e i loro metadati (permessi, proprietà, ecc.) In un flusso di byte che possono essere memorizzati su un'unità a nastro (o un file) e ripristinati in seguito. La compressione è una questione completamente separata che era necessario reindirizzare l'output attraverso un'utilità esterna per comprimerlo, se desiderato. Tar GNU è stato abbastanza carino da aggiungere switch per dirgli di filtrare automaticamente l'output attraverso l'utilità appropriata come scorciatoia.

Zip e 7z combinano l'archiviazione e la compressione nel loro formato contenitore e hanno lo scopo di impacchettare i file su un sistema DOS / Windows, quindi non memorizzano autorizzazioni e proprietà unix. Pertanto, se si desidera archiviare le autorizzazioni per i backup corretti, è necessario attenersi a tar. Se hai intenzione di scambiare file con utenti Windows, zip o 7z sono buoni. Gli attuali algoritmi di compressione zip e 7zip use possono essere usati con tar, uzing gzipe lzmarispettivamente.

lzma (aka. * .xz) ha uno dei migliori rapporti di compressione, ed è abbastanza veloce alla decompressione, rendendolo una delle migliori scelte in questi giorni. Tuttavia, richiede una tonnellata di tempo di ram e cpu per comprimere. Il venerabile gzipè un po 'più veloce in compressione, quindi può essere usato se non vuoi dedicare così tanto tempo alla CPU. Ha anche una variante ancora più veloce chiamata lzop. bzip2è ancora abbastanza popolare in quanto ha ampiamente sostituito gzip per un po 'di tempo prima che si verificasse 7zip / lzma, poiché ha ottenuto rapporti di compressione migliori, ma in questi giorni sta perdendo il favore poiché 7z / lzma è più veloce in decompressione e ottiene rapporti di compressione migliori. L' compressutilità, che normalmente chiama i file * .Z, è antica e dimenticata da tempo.

Un'altra delle differenze importanti tra zip e tar è che zip comprime i dati in piccoli blocchi, mentre quando comprimi un file tar, comprimi tutto in una volta. Quest'ultimo offre rapporti di compressione migliori, ma per estrarre un singolo file alla fine dell'archivio, è necessario decomprimere il tutto per raggiungerlo. Quindi il formato zip è migliore per estrarre un singolo file o due da un archivio di grandi dimensioni. 7z e darti permettono di scegliere di comprimere il tutto (chiamato modalità "solido") o piccoli pezzi per una facile estrazione frammentaria.


Ma solo TAR supporta i metadati? Oppure gzip / bzip2 ora supporta anche i metadati
Kaz Wolfe,

@pacificfils, le utilità di compressione comprimono solo un singolo file, senza metadati.
psusi

si può tarare una cartella e poi metterlo in una zip e conservare le autorizzazioni?
Kaz Wolfe,

@pacificfils, sì, ma sarebbe un po 'sciocco dal momento che rinunceresti ai vantaggi di zip e al miglior rapporto di compressione di gzip.
psusi

@pacificfils tar cfpconserverà le autorizzazioni. Un file tar non è compresso, quindi zip (7-zip), gzip2, gzip, lzo, ecc comprimeranno bene un file tar (in generale, è improbabile che un tar di file compressi sia comprimibile).
Elliott Frisch,

9

I dettagli degli algoritmi sono fuori tema qui 1 poiché non sono in alcun modo specifici di Linux, per non parlare di Ubuntu. Troverai comunque delle belle informazioni qui .

Ora tar, come hai detto, tarnon è e non è mai stato un programma di compressione. Invece, è un archiviatore ; il suo scopo principale è quello di creare un file di grandi dimensioni da molti di quelli piccoli. Storicamente questo era per facilitare l'archiviazione su unità nastro, da cui il nome: Tape ARchive.

Oggi, il motivo principale da utilizzare tarè ridurre il numero di file sul sistema. Ogni file su un file system Unix occupa un inode , più file hai, meno inode sono disponibili e quando esaurisci gli inode, non puoi più creare nuovi file. Per dirla semplicemente, la stessa quantità di dati archiviati come migliaia di file occuperà più disco rigido rispetto agli stessi file in un singolo archivio tar.

Per illustrare, dato che questo è stato contestato nei commenti, sulla mia /partizione 68G , ho il seguente numero di inode totali e usati (tenere presente che il conteggio degli inode dipende dal tipo di file system e dalle dimensioni della partizione):

Inode count:              393216
Free inodes:              171421

Se ora procedo nel tentativo di creare più file di quelli che ho inode:

$ touch {1..171422}
touch: cannot touch ‘171388’: No space left on device
touch: cannot touch ‘171389’: No space left on device
touch: cannot touch ‘171390’: No space left on device
touch: cannot touch ‘171391’: No space left on device
touch: cannot touch ‘171392’: No space left on device
touch: cannot touch ‘171393’: No space left on device
touch: cannot touch ‘171394’: No space left on device
touch: cannot touch ‘171395’: No space left on device
touch: cannot touch ‘171396’: No space left on device
touch: cannot touch ‘171397’: No space left on device

Nessuno spazio? Ma ho un sacco di spazio:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       5,8G  4,3G  1,2G  79% /

Come puoi vedere sopra, la creazione di alcune centinaia di migliaia di file vuoti esaurisce rapidamente i miei inode e non posso più crearne di nuovi. Se fossi in tarquesti, sarei in grado di ricominciare a creare file.

Avere meno file inoltre accelera notevolmente l'I / O del file system, specialmente sui filesystem montati su NFS. Tarano sempre le mie vecchie directory di lavoro quando un progetto è finito poiché meno file ho, più programmi simili findfunzioneranno.

C'è una grande risposta su Super User che va molto più in dettaglio, ma oltre a quanto sopra, gli altri motivi di base per cui tarè ancora popolare oggi sono:

  1. Efficienza: utilizzare tarper eseguire il pipe tramite un programma di compressione come gzipè più efficiente poiché evita la creazione di file intermedi.

  2. tar viene fornito con tutti i tipi di campane e fischietti, caratteristiche che sono state progettate nel corso della sua lunga storia che lo rendono particolarmente utile per i backup * nix (pensare autorizzazioni, proprietà dei file, la capacità di reindirizzare i dati direttamente a STDOUT e su un collegamento SSH ... )

  3. Inerzia. Siamo abituati tar. È sicuro supporre che sarà disponibile su qualsiasi * nix che potresti usare, il che lo rende molto portatile e pratico per i tarball del codice sorgente.


1 Questo è assolutamente vero e non ha nulla a che fare con il fatto che non ne conosco abbastanza da spiegare :)


3
Il mio computer ha avuto (in passato) oltre 10.000.000 di file, e questo non è davvero troppo folle. Non ho mai usato tarper "ridurre il numero di file" poiché la maggior parte dei filesystem non mi interessa, e non è comunque ottimale poiché tarnon supporta un facile accesso casuale ai file. Piuttosto, l'uso principale (per me e penso per la maggior parte delle persone) è quello di condividere i file (ad esempio il codice sorgente) con altre persone in modo semplice.
nneonneo,

@nneonneo hai mai dovuto lavorare con milioni di file in una singola directory? Ho e credimi non è facile. A parte gli ovvi problemi con ARG_MAX, questo può rendere la gestione dei file in qualche modo una seccatura e può effettivamente portare una rete (malamente) configurata in cui i file sono archiviati in un server centrale e condivisi con NFS in ginocchio. Per quanto riguarda la riduzione del numero complessivo di file, avrai bisogno di molti più file di quelli da notare, ma nelle configurazioni multiutente, il numero di inode può effettivamente diventare limitante.
terdon,

@nneonneo per fare un esempio più concreto, tune2fs -lsulla partizione che tiene il mio $ HOME mi dice che ho 19.300.352 inode. Non sarò in grado di creare più file di quello. Come hai detto, 10 ^ 6 non è pazzo, nemmeno nelle gamme più alte. A seconda di cosa stai facendo, potresti aver bisogno di molto di più.
terdon,

@nneonneo vedi la risposta aggiornata per un esempio reale di come puoi facilmente rimanere senza inode.
terdon,

Il mio server sta usando poco più di 1 milione di inode e questo è solo perché ho una tonnellata di e-mail (molte mailing list ad alto traffico che risalgono a anni fa) e le memorizzo nel formato Maildir. Non ho idea di cosa potresti fare per utilizzare fino a 19 milioni di inode. Dovresti creare un nuovo file ogni secondo, 24 ore al giorno, per oltre 7 mesi.
psusi

4

Esistono due attività distinte ma correlate. Il raggruppamento di un albero di file (inclusi nomi di file, struttura di directory, autorizzazioni del file system, proprietà e qualsiasi altro metadata) in un flusso di byte viene chiamato archiviazione . La rimozione della ridondanza in un flusso di byte per produrre un flusso di byte più piccolo si chiama compressione .

Su Unix, le due operazioni sono separate, con strumenti distinti per ciascuna. Sulla maggior parte delle altre piattaforme (attuali e storiche) gli strumenti combinati eseguono sia l'archiviazione che la compressione.

(gzip e altri programmi che imitano l'interfaccia di gzip hanno spesso la possibilità di memorizzare il nome file originale nell'output compresso, ma questo, insieme a un CRC o un altro controllo per rilevare la corruzione, sono gli unici metadati che possono memorizzare.)

Ci sono vantaggi nel separare la compressione dall'archiviazione. L'archiviazione è specifica della piattaforma (i metadati del filesystem che devono essere conservati variano ampiamente), ma l'implementazione è semplice, in gran parte legata a I / O, e cambia poco nel tempo. La compressione è indipendente dalla piattaforma, ma le implementazioni sono legate alla CPU e gli algoritmi migliorano costantemente per sfruttare le maggiori risorse che l'hardware moderno può far fronte al problema.

L'archiviatore Unix più popolare è tar, anche se ne esistono altri come cpioe ar. (I pacchetti Debian sono ararchivi, mentre cpioè spesso usato per i ramdisk originali.) tarÈ o è stato spesso combinato con strumenti di compressione come compress(.Z), gzip(.gz), bzip2(.bz2) e xz(.xz), dal più vecchio al più giovane e non a caso dalla compressione peggiore a quella migliore.

Fare un tararchivio e comprimerlo sono passaggi distinti: il compressore non sa nulla del tarformato del file. Ciò significa che l'estrazione di un singolo file da un tararchivio compresso richiede la decompressione di tutti i file precedenti. Questo è spesso chiamato un archivio "solido".

Allo stesso modo, poiché tar è un formato "streaming" - necessario per essere utile in una pipeline - non esiste un indice globale in un archivio tar e elencare il contenuto di un archivio tar è costoso quanto estrarlo.

Al contrario, Zip e RAR e 7-zip (gli archivi più popolari sulle moderne piattaforme Windows) di solito comprimono ogni file separatamente e comprimono i metadati leggermente se non del tutto. Ciò consente un elenco economico dei file in un archivio e l'estrazione di singoli file, ma significa che la ridondanza tra più file nello stesso archivio non può essere sfruttata per aumentare la compressione. Mentre in generale la compressione di un file già compresso non riduce ulteriormente le dimensioni del file, a volte potresti vedere un file zip all'interno di un file zip: il primo zippare ha trasformato molti file piccoli in un file grande (probabilmente con compressione disabilitata), che il secondo zippare quindi compresso come una singola entità.

Esiste una impollinazione incrociata tra le diverse piattaforme e filosofie: gzipè essenzialmente zipil compressore senza il suo archiviatore, ed xzè essenzialmente 7-zipil compressore senza il suo archiviatore.

Esistono altri compressori specializzati. Le varianti di PPM e il loro successore ZPAQsono ottimizzate per la massima compressione indipendentemente dal consumo di risorse. Possono facilmente masticare tutta la CPU e la RAM che puoi lanciare contro di loro, e la decompressione è tanto faticosa quanto la compressione (per contrasto, gli strumenti di compressione più utilizzati sono asimmetrici : la decompressione è più economica della compressione).

D'altra estremità dello spettro, lzo, snappye LZ4sono compressori "leggeri" progettati per la massima velocità e minimo consumo di risorse, a costo di compressione. Sono ampiamente utilizzati nei filesystem e in altri negozi di oggetti, ma meno come strumenti autonomi.


Quindi quale dovresti scegliere?

Archiviazione:

Dato che sei su Ubuntu non c'è alcun motivo reale per usare altro che tarper l'archiviazione, a meno che tu non stia provando a creare file facilmente leggibili altrove.

zipè difficile da battere per l'ubiquità, ma non è incentrato su Unix e non manterrà le autorizzazioni del file system e le informazioni sulla proprietà e la sua compressione integrata è antiquata. 7-zip e RAR (e ZPAQ) hanno una compressione più moderna ma sono ugualmente inadatti all'archiviazione dei filesystem Unix (anche se non c'è nulla che ti impedisca di usarli come compressori); RAR è anche proprietario.

Compressione:

Per la massima compressione puoi dare un'occhiata a un benchmark, come quello enorme su http://mattmahoney.net/dc/text.html . Questo dovrebbe darti un'idea migliore dei compromessi coinvolti.

Tuttavia, probabilmente non vuoi la massima compressione. È troppo costoso.

xzè lo strumento di compressione per uso generico più popolare sui moderni sistemi Unix. Credo che 7-zip possa leggere anche i file xz, poiché sono strettamente correlati.

Infine: se stai archiviando dati per qualcosa di diverso dall'archiviazione a breve termine, dovresti scegliere qualcosa di open source e preferibilmente diffuso, per ridurre al minimo i mal di testa in seguito.


1

lzo, gz, b2, lzma (.lzma2 =.xz)sono compressori "stream": comprimono un flusso di bye e non conoscono e non si preoccupano di file, directory e metadati come le autorizzazioni. Devi usare un archiviatore come tar per raggruppare tutti quei dati in un flusso di byte (un file tar) e comprimerlo con un compressore. Se sono i dati di un singolo file che ti interessa, puoi anche alimentare quel file da solo a uno di questi compressori.

Tar, cpio and paxsono archiviatori: prendono un sacco di file e directory e codificano i dati e i metadati in un singolo file. il catrame è il più popolare e il più compatibile sebbene i meriti tecnici tra i tre siano abbastanza minimi da far nascere guerre di religione durante l'alba dei tempi.

7z e zip sono compressori E archiviatori: quindi archiviare tutti i dati e i metadati e comprimerli. Tuttavia, AFAICT, nessuno dei due salva le autorizzazioni unix.

Zip utilizza lo stesso algoritmo di gzip chiamato DEFLATE. 7z utilizza l'algoritmo lzma

per leggere un singolo file da tar.gz o simili, dovrai decomprimere l'intero flusso gz fino a quando non viene esposto il contenuto sufficiente del file tar in modo da poterlo estrarre. Zip ti consente di comprimere ed estrarre ogni file singolarmente. 7z può avere entrambi i comportamenti.

Rapporti e velocità di compressione: gzip e lzo hanno velocità di compressione e decompressione molto elevate ma rapporti di compressione bassi. Inoltre non richiede molta memoria per comprimere. gzip è un po 'più lento e offre un rapporto di compressione leggermente migliore rispetto a lzo.

È così veloce, può essere più veloce leggere un file compresso gz o lzo dal disco e decomprimerlo al volo invece di leggere il file non compresso direttamente dal disco.

LZMA (xz) offre un'eccellente compressione dei dati generali, ma richiede molto tempo per comprimere e decomprimere insieme a prendere quantità significative di memoria per comprimere.

bz2 era l'algoritmo di compressione ad alta scelta di scelta, ma è caduto in disgrazia in quanto è sia più lento di lzma e richiede più tempo per comprimere e decomprimere. Tuttavia per alcuni tipi di dati (sequenze di DNA, file con esecuzioni molto grandi dello stesso byte, ecc.) Bzip2 può battere tutto il resto a mani basse. Ad esempio, una volta ho dovuto comprimere un file da 4 GB di 1 e b2 ho ridotto i a pochi 10 di kb mentre lzma ha preso alcuni 10 di MB se ricordo bene.


In realtà lzma è piuttosto veloce nella decompressione.
psusi,

0

Per file particolarmente grandi, è possibile utilizzare rzip. Prima esamina i dati ridondanti all'interno di blocchi di grandi dimensioni da 900 MB, li codifica e quindi li passa a bzip2 (non proprio, ma vengono utilizzati gli stessi algoritmi).

Effetto? Molto più veloce di xz, lzmao bzip2, e nella mia esperienza il suo rapporto di compressione è in concorrenza con quello di lzma. È un maiale RAM, però.

http://en.wikipedia.org/wiki/Rzip

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.