Compresia datelor – când este și când nu este necesară?

Când eram în liceu, arhivam totul. Hard-disk-urile erau mici și scumpe, dischetele se stricau foarte repede, iar de transfer pe Internet nu prea ne puteam apropia (foloseam, evident, modem-uri și plăteam telefonul la minut). Prin urmare, eram experți în algoritmi de compresie, diversele opțiuni pentru rar, ace, arhive solide și așa mai departe. În zilele noastre, oare care mai este situația?

Compresia poate fi folosită în principal pentru două scopuri: pentru a economisi spațiu de stocare și pentru a economisi bandă de transfer. Să le analizăm pe rând.

În primul rând, spațiul de stocare este foarte ieftin în zilele noastre. Cu câteva mii de euro îți poți construi un server de stocare de câțiva zeci de terabytes – suficient pentru a nu fi necesar să stochezi prea multe date în format comprimat. Desigur, formatele de fișiere comprimate, cum ar fi jpeg pentru imagini, mp3 pentru audio și mpeg/xvid pentru video au rolul lor, iar consumatorii le vor folosi mult timp de acum încolo. Profesioniștii însă își pot permite să lucreze fără mari probleme pe formate necomprimate (“raw”) sau folosind algoritmi de compresie care să acorde prioritate calității în defavoarea spațiului ocupat (“lossless compression”). În nici un caz nu mai este necesară comprimarea de documente și fișiere uzuale, pentru “arhivare”.

Banda utilizată este cel de-al doilea criteriu. Sau, mai ușor de înțeles, “cât timp îmi ia să copiez un fișier”, indiferent că este vorba despre transfer pe Internet sau între periferice (hard-disk-uri, stick-uri USB, CD-uri). În zilele noastre, calculatoarele pot să-și transfere date între periferice sau peste rețea cu viteze extrem de mari – de multe ori, chiar mai rapid decât ar dura comprimarea datelor la sursă și decomprimarea la destinație. Chiar și vitezele de transfer pe Internet tind să fie suficient de mari încât compresia să nu mai fie necesară.

O formulă exactă nu există, din păcate. Putem însă să identificăm, în mare, operațiunile pe care le-ar efectua calculatorul la transferul unei cantități oarecare de date și să analizăm câteva variante. Să presupunem că dorim să copiem tot directorul personal al unui utilizator de pe un sistem pe altul – de exemplu ca parte a unui backup regulat sau la cumpărarea unui nou calculator. Dorim să facem asta folosind un stick USB.

Copierea directă folosind un stick presupune două citiri și două scrieri: citire de la sursă, scriere pe stick, citire de pe stick și scriere pe hard-disk la destinație.

Dar dacă folosim compresie? Procesul va presupune scrierea unui fișier comprimat, care trebuie creat de procesorul sistemului sursă. La destinație, procesorul sistemului va trebui să muncească pentru a decomprima datele. Iată ce pași se vor face: citire date, compresie, scriere fișier comprimat pe stick-ul USB (la sursă), apoi la destinație se va citi fișierul comprimat, se va decomprima și se vor scrie datele pe hard-disk.

Observăm că am adăugat două operațiuni care iau ceva timp – compresia și decompresia, economisind din cantitatea de date care trebuie scrisă și citită apoi de pe stick-ul USB. În funcție de viteza stick-ului, de puterea procesorului, de performanța algoritmilor de compresie și de cantitatea totală de date, una dintre variantele de mai sus este cea mai rapidă. Care însă? Este greu de spus.

Voi oferi însă un exemplu real, o întâmplare de acum câteva săptămâni, în care am constatat că există cazuri în care compresia încetinește procesul de copiere.

Aveam de copiat câteva zeci de GB de fișiere (backup-ul unui sistem care trebuia reinstalat). Atât sistemul sursă cât și cel destinație aveau hard-disk-uri SATA rapide, iar rețeaua folosită funcționa la 1Gbit/sec. Prima încercare de copiere a fost efectuată folosind programul scp din pachetul SSH – deci atât compresie cât și criptare a datelor. Am renunțat repede, atât din cauza vitezei extrem de mici cât și din cauză că nu aveam nevoie de criptare.

Următoarea încercare a fost făcută folosind protocolul rsync (remote) – făcând doar compresie, nu și criptare. Viteza a fost mai bună, dar nu suficient de mare. A treia încercare a fost crearea unui fișier comprimat .tar.gz într-un director exportat prin NFS de pe mașina destinație. Viteza a fost chiar mai slabă decât în încercarea anterioară.

Am identificat repede problema ca fiind puterea insuficientă a procesorului mașinii sursă. Prin urmare, metoda prin care am copiat datele a fost folosirea rsync pe un director exportat prin NFS de pe mașina destinație – pentru rsync, atât sursa cât și destinația păreau locale, și nu s-a folosit compresia datelor. Copierea a funcționat aproape de viteza maximă fizică a rețelei, fără a încărca aproape deloc procesoarele celor două calculatoare.

Iată că închei un post fără a oferi o soluție. Mă voi mulțumi doar să afirm că utilizarea compresiei datelor nu mai este ceva implicit și obligatoriu, existând o mulțime de scenarii în care comprimarea și decomprimarea pot afecta negativ timpul total al transferurilor de date. Cazurile de utilizare trebuie înțelese și explorate cu diferite teste, înainte de adoptarea unei soluții.

Tu cum și când folosești compresia datelor? Ai și tu scenarii în care mai mult te-a încurcat, în loc să-ți aducă beneficii de viteză? Scrie mai jos, într-un comentariu!

Iar dacă vrei să te asiguri că folosești corect și unde trebuie compresia datelor, nu ezita să ne contactezi!

Image credit: Noel Feans.

No related posts.