Dësen Artikel ass schonn den zweeten am Thema High-Speed Datekompressioun. Den éischten Artikel beschreift e Kompressor deen mat enger Geschwindegkeet vun 10 GB / sec funktionnéiert. pro Prozessor Kär (Minimum Kompressioun, RTT-Min).
Dëse Kompressor ass schonn an der Ausrüstung vu forenseschen Duplikatore fir High-Speed-Kompressioun vu Späichermedien Dumps ëmgesat ginn an d'Kraaft vun der Kryptografie verbesseren; et kann och benotzt ginn fir Biller vu virtuelle Maschinnen a RAM-Swap-Dateien ze kompriméieren wann se op Héichgeschwindegkeet späicheren SSD fiert.
Den éischten Artikel huet och d'Entwécklung vun engem Kompressiounsalgorithmus ugekënnegt fir Backupkopien vun HDD an SSD Disk Drive ze kompriméieren (mëttlere Kompressioun, RTT-Mid) mat wesentlech verbesserte Datekompressiounsparameter. Bis elo ass dëse Kompressor komplett fäerdeg an dësen Artikel ass doriwwer.
E Kompressor deen den RTT-Mid Algorithmus implementéiert bitt e Kompressiounsverhältnis vergläichbar mat Standardarchiver wéi WinRar, 7-Zip, déi am High-Speed-Modus operéieren. Zur selwechter Zäit ass seng Operatiounsgeschwindegkeet op d'mannst eng Uerdnung vun der Gréisst méi héich.
D'Geschwindegkeet vun der Verpakung / Auspackung vun Daten ass e kriteschen Parameter deen den Ëmfang vun der Uwendung vu Kompressiounstechnologien bestëmmt. Et ass onwahrscheinlech datt iergendeen drun denken en Terabyte vun Daten mat enger Geschwindegkeet vun 10-15 MegaBytes pro Sekonn ze kompriméieren (dëst ass genau d'Geschwindegkeet vun den Archiver am Standardkompressiounsmodus), well et bal zwanzeg Stonnen mat enger voller Prozessorbelaaschtung dauert. .
Op der anerer Säit kann deeselwechten Terabyte mat Geschwindegkeete vun der Uerdnung vun 2-3Gigabytes pro Sekonn an ongeféier zéng Minutten kopéiert ginn.
Dofir ass d'Kompressioun vu grousser Volumen Informatioun wichteg wann se mat enger Geschwindegkeet net manner wéi d'Geschwindegkeet vum realen Input / Output gemaach gëtt. Fir modern Systemer ass dëst op d'mannst 100 Megabytes pro Sekonn.
Moderne Kompressere kënnen esou Geschwindegkeet nëmmen am "schnell" Modus produzéieren. Et ass an dësem aktuelle Modus datt mir den RTT-Mid Algorithmus mat traditionelle Kompressere vergläichen.
Comparativ Testen vun engem neie Kompressiounsalgorithmus
Den RTT-Mid Kompressor huet als Deel vum Testprogramm geschafft. An enger richteger "schaffen" Applikatioun funktionnéiert et vill méi séier, et benotzt Multithreading clever a benotzt en "normalen" Compiler, net C #.
Zënter datt d'Kompressere, déi am komparativen Test benotzt ginn, op verschidde Prinzipien gebaut ginn a verschidden Zorte vun Daten kompriméieren anescht, fir d'Objektivitéit vum Test, gouf d'Method fir d'"Duerchschnëttstemperatur am Spidol" ze moossen ...
Eng Secteur-vun-Sektor Dumpdatei vun enger logescher Scheif mam Windows 10 Betriebssystem gouf erstallt; Dëst ass déi natierlechst Mëschung vu verschiddenen Datestrukturen déi tatsächlech op all Computer verfügbar sinn. D'Kompressioun vun dëser Datei erlaabt Iech d'Geschwindegkeet an d'Kompressiounsgrad vum neien Algorithmus mat de modernsten Kompressoren ze vergläichen, déi an modernen Archiver benotzt ginn.
Hei ass d'Dump Datei:
D'Dumpdatei gouf mat PTT-Mid, 7-Zip a WinRar Kompressere kompriméiert. De WinRar a 7-Zip Kompressor goufen op maximal Geschwindegkeet gesat.
Kompressor leeft 7-Zip:
Et lued de Prozessor ëm 100%, während d'Duerchschnëttsgeschwindegkeet fir den Originaldump ze liesen ongeféier 60 MegaBytes / sec.
Kompressor leeft winrar:
D'Situatioun ass ähnlech, de Prozessorbelaaschtung ass bal 100%, déi duerchschnëttlech Dump Liesgeschwindegkeet ass ongeféier 125 Megabytes / sec.
Wéi am virege Fall ass d'Geschwindegkeet vum Archiver limitéiert duerch d'Fäegkeeten vum Prozessor.
De Kompressor Testprogramm leeft elo RTT-Mëtt:
De Screenshot weist datt de Prozessor op 50% gelueden ass an de Rescht vun der Zäit idle ass, well et néierens ass fir déi kompriméiert Donnéeën eropzelueden. D'Dataupload-Disk (Disk 0) ass bal voll gelueden. D'Date Liesgeschwindegkeet (Disk 1) variéiert staark, awer am Duerchschnëtt méi wéi 200 MegaBytes / sec.
D'Geschwindegkeet vum Kompressor ass an dësem Fall limitéiert duerch d'Fäegkeet fir kompriméiert Daten op Disk 0 ze schreiwen.
Elo de Kompressiounsverhältnis vun den resultéierende Archiven:
Et kann gesi ginn datt den RTT-Mid Kompressor déi bescht Aarbecht vu Kompressioun gemaach huet; d'Archiv déi et erstallt huet war 1,3 GigaBytes méi kleng wéi de WinRar Archiv an 2,1 GigaBytes méi kleng wéi de 7z Archiv.
Zäit fir d'Archiv ze kreéieren:
- 7-Zip - 26 Minutten 10 Sekonnen;
- WinRar - 17 Minutten 40 Sekonnen;
- RTT-Mëtt - 7 Minutten 30 Sekonnen.
Sou konnt och en Test, net optimiséierte Programm, mam RTT-Mid Algorithmus, en Archiv méi wéi zwee an en halleft Mol méi séier erstellen, während d'Archiv däitlech méi kleng ass wéi dee vu senge Konkurrenten ...
Déi, déi d'Screenshots net gleewen, kënnen hir Authentizitéit selwer kontrolléieren. Den Testprogramm ass verfügbar um , download a kontrolléieren.
Awer nëmmen op Prozessoren mat AVX-2 Support, ouni Ënnerstëtzung fir dës Instruktioune funktionnéiert de Kompressor net, a testen den Algorithmus net op eeler AMD Prozessoren, si si lues wat d'Ausféierung vun AVX Instruktiounen ugeet ...
Kompressiounsmethod benotzt
Den Algorithmus benotzt eng Method fir widderholl Textfragmenter an Bytegranularitéit ze indexéieren. Dës Kompressiounsmethod ass scho laang bekannt, awer gouf net benotzt well d'passende Operatioun ganz deier war wat déi néideg Ressourcen ugeet a vill méi Zäit erfuerdert wéi e Wierderbuch ze bauen. Also ass den RTT-Mid Algorithmus e klassescht Beispill fir "zréck an d'Zukunft" ze plënneren ...
De PTT-Kompressor benotzt en eenzegaartegen High-Speed-Match Sich Scanner, deen eis erlaabt de Kompressiounsprozess ze beschleunegen. E selwergemaachte Scanner, dëst ass "meng Charme ...", "et ass zimlech deier, well et ass komplett handgemaach" (am Assembler geschriwwen).
De Match Sich Scanner gëtt no engem zwee-Niveau probabilistesche Schema gemaach: éischtens gëtt d'Präsenz vun engem "Zeeche" vun engem Match gescannt, an nëmmen nodeems de "Schëld" op dëser Plaz identifizéiert ass, d'Prozedur fir e richtege Match z'entdecken. ass ugefaangen.
D'Match Sichfenster huet eng onberechenbar Gréisst, ofhängeg vum Grad vun der Entropie am veraarbechten Dateblock. Fir komplett zoufälleg (inkompressibel) Donnéeën huet et eng Gréisst vu Megabytes, fir Daten mat Wiederholungen ass et ëmmer méi grouss wéi e Megabyte.
Awer vill modern Dateformate sinn inkompressibel a lafen e Ressourceintensive Scanner duerch si ass nëtzlos an verschwendeg, sou datt de Scanner zwee Operatiounsmodi benotzt. Als éischt gi Sektioune vum Quelltext mat méiglechen Widderhuelunge gesicht; dës Operatioun gëtt och mat enger probabilistescher Method duerchgefouert a gëtt ganz séier gemaach (mat enger Geschwindegkeet vu 4-6 GigaBytes / sec). D'Gebidder mat méigleche Matcher ginn dann vum Haaptscanner veraarbecht.
Indexkompressioun ass net ganz effizient, Dir musst duplizéiert Fragmenter mat Indizes ersetzen, an d'Index-Array reduzéiert de Kompressiounsverhältnis wesentlech.
Fir de Kompressiounsverhältnis ze erhéijen, ginn net nëmme komplette Matcher vu Byte Strings indexéiert, awer och deelweis, wann d'String passend an onvergläicht Bytes enthält. Fir dëst ze maachen, enthält den Indexformat e Matchmaskefeld, deen déi passend Bytes vun zwee Blocken ugeet. Fir nach méi Kompressioun gëtt Indexéierung benotzt fir e puer deelweis passende Blocken op den aktuelle Block ze iwwerlageren.
All dëst huet et méiglech gemaach am PTT-Mid Kompressor e Kompressiounsverhältnis ze kréien, vergläichbar mat Kompressoren, déi mat der Wierderbuchmethod gemaach goufen, awer vill méi séier schaffen.
Geschwindegkeet vum neie Kompressiounsalgorithmus
Wann de Kompressor mat exklusivem Gebrauch vum Cache-Speicher funktionnéiert (4 Megabytes sinn pro Fuedem erfuerderlech), da läit d'Betribsgeschwindegkeet vun 700-2000 Megabytes / sec. pro Prozessor Kär, jee no der Zort vun Daten kompriméiert an hänkt wéineg op der Betribssystemer Frequenz vum Prozessor.
Mat enger Multi-threaded Implementatioun vum Kompressor gëtt effektiv Skalierbarkeet duerch d'Gréisst vum drëtten Niveau Cache bestëmmt. Zum Beispill, 9 MegaBytes Cache Memory "u Bord" ze hunn, ass et kee Sënn fir méi wéi zwee Kompressiounsfäegkeeten ze lancéieren; d'Geschwindegkeet wäert dovun net eropgoen. Awer mat engem Cache vun 20 Megabytes kënnt Dir scho fënnef Kompressiounsfäegkeeten lafen.
Och d'Latenz vum RAM gëtt e wichtege Parameter deen d'Geschwindegkeet vum Kompressor bestëmmt. Den Algorithmus benotzt zoufälleg Zougang zum OP, e puer vun deenen net an de Cache-Erënnerung kommen (ongeféier 10%) an et muss Idle, op Daten aus dem OP waarden, wat d'Vitesse vun der Operatioun reduzéiert.
Bedeitend beaflosst d'Geschwindegkeet vum Kompressor an d'Operatioun vum Dateinput / Output System. Ufro un den OP vun I / O Block Ufroe fir Daten vun der CPU, wat och d'Kompressiounsgeschwindegkeet reduzéiert. Dëse Problem ass bedeitend fir Laptops an Desktops; fir Serveren ass et manner bedeitend wéinst enger méi fortgeschratt Systembus Access Control Eenheet a Multi-Channel RAM.
Am ganzen Text am Artikel schwätze mir iwwer Kompressioun; Dekompressioun bleift ausserhalb vum Ëmfang vun dësem Artikel well "alles mat Schockela bedeckt ass". Dekompressioun ass vill méi séier a gëtt limitéiert duerch I/O Geschwindegkeet. Ee kierperleche Kär an engem Fuedem bitt einfach Auspackungsgeschwindegkeet vun 3-4 GB / sec.
Dëst ass wéinst der Verontreiung vun enger Match Sich Operatioun während dem Dekompressiounsprozess, deen d'Haaptressourcen vum Prozessor an d'Cache-Erënnerung während der Kompressioun "frësst".
Zouverlässegkeet vun der kompriméierter Datelagerung
Wéi den Numm vun der ganzer Klass vu Software, déi Datekompressioun (Archiver) benotzt, seet, si si fir laangfristeg Späichere vun Informatioun entwéckelt, net fir Joeren, mee fir Jorhonnerte a Joerdausend ...
Wärend der Späichere verléieren d'Späichermedien e puer Daten, hei ass e Beispill:
Dësen "analogen" Informatiounsdréier ass dausend Joer al, e puer Fragmenter si verluer gaangen, awer allgemeng ass d'Informatioun "liesbar" ...
Keen vun de verantwortleche Hiersteller vu modernen digitale Datespeichersystemer an digitale Medien fir si bitt Garantien vun der kompletter Datesécherheet fir méi wéi 75 Joer.
An dëst ass e Problem, awer e verréckten Problem, eis Nokommen léisen et ...
Digital Datespeichersystemer kënnen Daten verléieren net nëmmen no 75 Joer, Fehler an Daten kënnen zu all Moment optrieden, och während hirer Opnam, probéieren se dës Verzerrungen ze minimiséieren andeems se Redundanz benotzen an se mat Fehlerkorrektursystemer korrigéieren. Redundanz- a Korrektursystemer kënnen net ëmmer verluer Informatioun restauréieren, a wa se et maachen, gëtt et keng Garantie datt d'Restauratiounsoperatioun richteg ofgeschloss gouf.
An dat ass och e grousse Problem, awer net e verstoppt, mee en aktuelle.
Modern Kompressere benotzt fir digital Donnéeën ze archivéieren sinn op verschidde Ännerunge vun der Wierderbuchmethod gebaut, a fir sou Archiven ass de Verloscht vun engem Informatiounsstéck e fatale Event; et gëtt souguer en etabléierte Begrëff fir sou eng Situatioun - e "gebrach" Archiv ...
Déi geréng Zouverlässegkeet vun der Späichere vun Informatioun an Archiven mat Wierderbuchkompressioun ass mat der Struktur vun de kompriméierte Donnéeën assoziéiert. D'Informatioun an esou engem Archiv enthält net de Quelltext, d'Zuel vun den Entréen am Wierderbuch sinn do gespäichert, an d'Wörterbuch selwer gëtt dynamesch vum aktuellen kompriméierten Text geännert. Wann en Archivfragment verluer oder beschiedegt ass, kënnen all spéider Archiv-Entréen weder duerch den Inhalt oder duerch d'Längt vun der Entrée am Wierderbuch identifizéiert ginn, well et net kloer ass wat d'Wörterbuch-Entréenummer entsprécht.
Et ass onméiglech Informatiounen aus esou engem "gebrach" Archiv ze restauréieren.
Den RTT Algorithmus baséiert op enger méi zouverléisseger Method fir kompriméiert Daten ze späicheren. Et benotzt d'Indexmethod fir d'Rechnung fir Fragmenter ze widderhuelen. Dës Approche fir d'Kompressioun erlaabt Iech d'Konsequenze vun der Verzerrung vun der Informatioun op de Späichermedium ze minimiséieren, a ville Fäll automatesch Verzerrungen ze korrigéieren, déi während Informatiounsspeicher entstoen.
Dëst ass wéinst der Tatsaach datt d'Archivdatei am Fall vun der Indexkompressioun zwee Felder enthält:
- e Quelltextfeld mat Widderhuelungssektiounen dovun ofgeholl;
- Index Feld.
D'Indexfeld, dat kritesch ass fir d'Erhuelung vun Informatioun, ass net grouss an der Gréisst a ka fir zouverlässeg Datelagerung duplizéiert ginn. Dofir, och wann e Fragment vum Quelltext oder Index-Array verluer ass, gëtt all aner Informatioun ouni Probleemer restauréiert, wéi am Bild mat engem "analogen" Späichermedium.
Nodeeler vum Algorithmus
Et gi keng Virdeeler ouni Nodeeler. D'Indexkompressiounsmethod kompriméiert net kuerz Widderhuelungssequenzen. Dëst ass wéinst den Aschränkungen vun der Indexmethod. Indexe sinn op d'mannst 3 Bytes grouss a kënne bis zu 12 Bytes grouss sinn. Wann eng Widderhuelung mat enger méi klenger Gréisst begéint ass wéi den Index deen et beschreift, da gëtt et net berücksichtegt, egal wéi dacks esou Wiederholungen an der kompriméierter Datei festgestallt ginn.
Déi traditionell Wierderbuch Kompressiounsmethod kompriméiert effektiv multiple Wiederholungen vu kuerzer Längt an erreecht dofir e méi héije Kompressiounsverhältnis wéi Indexkompressioun. Richteg, dëst ass erreecht wéinst der héijer Belaaschtung op den Zentralprozessor; fir datt d'Wierderbuchmethod ufänkt Daten méi effizient ze kompriméieren wéi d'Indexmethod, muss se d'Datenveraarbechtungsgeschwindegkeet op 10-20 Megabytes pro Sekonn op real reduzéieren Recheninstallatiounen mat enger voller CPU-Laascht.
Esou niddreg Geschwindegkeete sinn inakzeptabel fir modern Datespeichersystemer a si vu méi "akademeschen" Interessi wéi praktesch.
De Grad vun der Informatiounskompressioun gëtt wesentlech erhéicht an der nächster Ännerung vum RTT Algorithmus (RTT-Max), dee schonn an der Entwécklung ass.
Also, wéi ëmmer, fortgesat ...
Source: will.com