Vantaggi della compressione dei dati a livello di applicazione?

5

Questa domanda è stata ispirata da MessagePack , ma sto cercando una risposta generale sui vantaggi di in-app vs. compressione esterna.

Per l'I / O di rete, il protocollo di trasporto (almeno facoltativamente) non fornisce una sorta di compressione? In tal caso, cosa rende migliore la compressione in-app?

Per la memorizzazione dei file, cosa rende migliore la compressione in-app rispetto alla compressione esterna (zip, ecc.)?

La mia ipotesi è che la compressione in-app abbia più informazioni contestuali su ciò che viene compresso, e quindi potrebbe avere prestazioni migliori in termini di velocità e / o fattore di compressione. Ovviamente la mia comprensione è un po 'vaga. C'è dell'altro oltre?

    
posta Kevin Krumwiede 26.05.2017 - 21:08
fonte

1 risposta

5

In un sistema ideale (leggi: ben programmato), specifico è più efficiente del generico, ma generico è più ampiamente applicabile. Risparmia tempo di sviluppo utilizzando generico, risparmi tempo utente usando specifici.

Un buon esempio potrebbero essere le immagini. Se hai usato la compressione gzip di TCP su una bitmap, che non ha compressione incorporata, stai applicando una soluzione puramente generica. Cercherà modelli che possa replicare in meno dati. Ad esempio, 1000 pixel di bianco puro potrebbero essere modificati da 3000 0xFF byte in pochi byte, ad esempio un'istruzione di "replicare byte" seguita dal conteggio "3000" e dal valore "0xFF". (gzip è molto più complicato di così, ma ottieni il succo) Ma non noterà che un rettangolo di bianco 100x1000 può essere sostituito con una singola istruzione; avrà bisogno di 100 istruzioni, ogni volta che raggiunge quel 3000 blocco di 0xFF nel flusso.

D'altra parte, se usi un JPG, che ha integrato la compressione, sa che è un'immagine. Può riconoscere quei blocchi regolari, sa che può lesinare in certe aree e l'occhio umano non noterà la differenza. Se alcuni pixel sono leggermente off color, le persone non se ne accorgeranno, ma la macchina può adattarlo a un pattern che lo rende più compresso.

Ma se provassi ad applicare quella compressione ai dati binari, la corromperà.

In alternativa, se si utilizza un tipo di compressione di immagine senza perdita di dati, come ad esempio, PNG, avrà tutta la teoria delle immagini dietro di esso per riconoscere i modi in cui può ridurre le dimensioni dell'immagine. Sebbene sia possibile applicarlo a dati regolari senza corruzione, sarebbe significativamente meno utile a causa dei pattern che sta cercando di essere tutti sbagliati per i pattern nei dati.

Il Gzipping in cima a quello può anche trovare pattern nei pattern per renderlo ancora più piccolo.

Il vantaggio principale che MessagePack sembra avere su gzip (da un aspetto superficiale) è che elimina gli elementi di chiusura (cioè la citazione di chiusura, le parentesi di chiusura, le virgole), tagliando il sovraccarico sintattico di json a metà, al costo di renderlo meno leggibile e modificabile dall'uomo. Gzip non può farlo.

Non sembra comprimere i dati effettivi, che gzip è buono, quindi dovresti usare le due compressioni per completarsi a vicenda. Gzip in TCP sopra a MessagePack nell'applicazione.

Tuttavia, c'è la possibilità (non so, dovrete provarlo) che gzip potrebbe gestire i pattern in JSON regolare meglio dei pattern prodotti da MessagePack, e quindi potrebbe produrre una dimensione più piccola. Lo trovo dubbio, però, poiché gzip è più destinato al binario generale che al testo in particolare.

    
risposta data 26.05.2017 - 22:47
fonte

Leggi altre domande sui tag