Wann Dir mat grousse Bänn vun Daten schafft, kann de Problem vum Manktem un Disk Space heiansdo entstoen. Ee Wee fir dëse Problem ze léisen ass d'Kompressioun, duerch déi Dir Iech op der selwechter Ausrüstung leeschte kënnt fir Späichervolumen ze erhéijen. An dësem Artikel wäerte mir kucken wéi Datekompressioun am Apache Ignite funktionnéiert. Dësen Artikel wäert nëmmen d'Diskkompressiounsmethoden beschreiwen, déi am Produkt implementéiert sinn. Aner Methoden fir Datekompressioun (iwwer dem Netz, an der Erënnerung), egal ob implementéiert oder net, bleiwen ausserhalb vum Ëmfang.
Also, mam Persistenzmodus aktivéiert, als Resultat vun Ännerunge vun den Daten an de Cache, fänkt Ignite op d'Disk ze schreiwen:
- Inhalt vun Cache
- Schreift Ahead Log (nodréiglech einfach WAL)
Et gëtt e Mechanismus fir WAL Kompressioun fir eng laang Zäit elo, genannt WAL Verdichtung. De kierzlech verëffentlechten Apache Ignite 2.8 huet zwee méi Mechanismen agefouert, déi Iech erlaben Daten op der Disk ze kompriméieren: Disk Säit Kompressioun fir den Inhalt vu Cache ze kompriméieren an WAL Säit Snapshot Kompressioun fir e puer WAL Entréen ze kompriméieren. Méi Detailer iwwer all dräi vun dëse Mechanismen ënnendrënner.
Disk Säit Kompressioun
Wéi heescht dat Aarbecht
Als éischt kucke mer e ganz kuerze Bléck op wéi Ignite Daten späichert. Säit Erënnerung gëtt fir Späichere benotzt. D'Säitgréisst ass um Ufank vum Node gesat a kann net a spéider Stadien geännert ginn; och d'Säitgréisst muss eng Kraaft vun zwee an e Multiple vun der Dateisystemblockgréisst sinn. Säiten ginn an de RAM vun der Disk gelueden wéi néideg; d'Gréisst vun den Daten op der Disk kann d'Quantitéit vum zougewisenen RAM iwwerschreiden. Wann et net genuch Plaz am RAM ass fir eng Säit vun der Disk ze lueden, ginn al, net méi benotzte Säiten aus dem RAM evictéiert.
D'Donnéeë ginn op der Disk an der folgender Form gespäichert: eng separat Datei gëtt fir all Partition vun all Cache-Grupp erstallt; an dëser Datei erschéngen Säiten een nom aneren an opsteigend Indexuerdnung. De komplette Säitidentifizéierer enthält den Cache-Gruppidentifizéierer, Partitionsnummer a Säitindex an der Datei. Also, mat der voller Säit Identifizéierer, kënne mir d'Datei an d'Offset an der Datei fir all Säit eenzegaarteg bestëmmen. Dir kënnt méi iwwer Paging Memory am Apache Ignite Wiki Artikel liesen: .
Den Disk-Säit-Kompressiounsmechanismus, wéi Dir aus dem Numm kënnt roden, funktionnéiert um Säitniveau. Wann dëse Mechanismus aktivéiert ass, ginn Daten am RAM veraarbecht wéi se sinn, ouni Kompressioun, awer wann Säite vum RAM op Disk gespäichert ginn, gi se kompriméiert.
Awer all Säit individuell ze kompriméieren ass keng Léisung fir de Problem; Dir musst iergendwéi d'Gréisst vun de resultéierende Datedateien reduzéieren. Wann d'Säitgréisst net méi fix ass, kënne mir keng Säiten méi een nom aneren an d'Datei schreiwen, well dat kann eng Rei Problemer entstoen:
- Mat Hëllef vum Säitindex kënne mir den Offset net berechnen, duerch deen et an der Datei läit.
- Et ass net kloer wat mat Säiten ze maachen déi net um Enn vun der Datei sinn an hir Gréisst änneren. Wann d'Säitgréisst erofgeet, verschwënnt de Raum deen se fräigelooss huet. Wann d'Säitgréisst eropgeet, musst Dir eng nei Plaz an der Datei dofir sichen.
- Wann eng Säit mat enger Zuel vu Bytes bewegt, déi net e Multiple vun der Dateisystemblockgréisst ass, da wäert d'Liesen oder d'Schreiwen et erfuerderen datt Dir e méi Dateiesystemblock beréiert, wat zu enger Leeschtungsverschlechterung féieren kann.
Fir d'Léisung vun dëse Probleemer op sengem eegenen Niveau ze vermeiden, benotzt Disk-Säitkompressioun am Apache Ignite e Dateiesystemmechanismus genannt Spuerdateien. Eng sparse Datei ass eng an där e puer Null-gefëllte Regiounen als "Lächer" markéiert kënne ginn. An dësem Fall gi keng Dateiesystemblocker zougewisen fir dës Lächer ze späicheren, wat zu Spuer op Disk Space resultéiert.
Et ass logesch datt fir e Dateiesystemblock ze befreien, d'Gréisst vum Lach muss méi grouss sinn wéi oder gläich wéi de Dateiesystemblock, wat eng zousätzlech Begrenzung vun der Säitgréisst an Apache Ignite setzt: fir datt d'Kompressioun en Effekt huet, d'Säitgréisst muss strikt méi grouss sinn wéi d'Gréisst vum Dateiesystemblock. Wann d'Säitgréisst d'selwecht ass wéi d'Blockgréisst, da wäerte mir ni fäeg sinn en eenzege Block ze befreien, well fir en eenzege Block ze befreien, muss déi kompriméiert Säit 0 Bytes besetzen. Wann d'Säitgréisst d'selwecht ass wéi d'Gréisst vun 2 oder 4 Blocks, kënne mir schonn op d'mannst ee Block befreien wann eis Säit op mindestens 50% respektiv 75% kompriméiert ass.
Also déi lescht Beschreiwung wéi de Mechanismus funktionnéiert: Wann Dir eng Säit op Disk schreift, gëtt probéiert d'Säit ze kompriméieren. Wann d'Gréisst vun der kompriméierter Säit erlaabt een oder méi Dateiesystemblocken ze befreien, da gëtt d'Säit a kompriméierter Form geschriwwen, an e "Lach" gëtt an der Plaz vun de befreitem Block gemaach (e Systemruff gëtt ausgefouert fallocate() mam Punch Lach Fändel). Wann d'Gréisst vun der kompriméierter Säit net erlaabt datt d'Blöcke befreit ginn, gëtt d'Säit gespäichert wéi et ass, onkompriméiert. All Säit Offsets ginn déiselwecht Manéier berechent wéi ouni Kompressioun, andeems de Säitindex mat der Säitgréisst multiplizéiert gëtt. Kee Verlagerung vu Säiten ass op Iech selwer erfuerderlech. Säit Offsets, grad wéi ouni Kompressioun, falen op d'Grenze vun Dateiesystemblocken.
An der aktueller Implementatioun kann Ignite nëmme mat spatzen Dateien ënner Linux OS funktionnéieren; Deementspriechend kann d'Disk Säit Kompressioun nëmmen aktivéiert ginn wann Dir Ignite op dësem Betribssystem benotzt.
Kompressioun Algorithmen déi fir Disk Säit Kompressioun benotzt kënne ginn: ZSTD, LZ4, Snappy. Zousätzlech gëtt et e Betribsmodus (SKIP_GARBAGE), an deem nëmmen onbenotzt Plaz op der Säit erausgehäit gëtt ouni d'Kompressioun op déi verbleiwen Donnéeën z'applizéieren, wat d'Laascht op der CPU am Verglach zu de virdrun opgelëscht Algorithmen reduzéiert.
Leeschtung Impakt
Leider hunn ech keng tatsächlech Leeschtungsmessungen op echte Stänn gemaach, well mir plangen net dëse Mechanismus an der Produktioun ze benotzen, awer mir kënnen theoretesch spekuléieren wou mir verléieren a wou mir gewannen.
Fir dëst ze maachen, musse mir erënneren wéi d'Säite gelies a geschriwwe ginn wann se zougänglech sinn:
- Wann Dir eng Liesoperatioun ausféiert, gëtt et fir d'éischt am RAM gesicht; wann d'Sich net erfollegräich ass, gëtt d'Säit an de RAM vun der Disk gelueden mam selwechte Fuedem deen d'Liesen ausféiert.
- Wann eng Schreifoperatioun ausgeführt gëtt, gëtt d'Säit am RAM als dreckeg markéiert, awer d'Säit gëtt net kierperlech op Disk gespäichert direkt vum Fuedem deen d'Schreiwen ausféiert. All dreckeg Säite ginn spéider am Checkpointprozess op der Disk gespäichert an getrennten Threads.
Also den Impakt op Liesoperatiounen ass:
- Positiv (Disk IO), wéinst enger Ofsenkung vun der Unzuel vun de gelies Dateiesystemblocken.
- Negativ (CPU), wéinst der zousätzlech Belaaschtung, déi vum Betribssystem erfuerderlech ass fir mat spatzen Dateien ze schaffen. Et ass och méiglech datt zousätzlech IO Operatiounen implizit hei erschéngen fir eng méi komplex sparse Dateistruktur ze späicheren (leider sinn ech net vertraut mat all Detailer wéi sparse Dateien funktionnéieren).
- Negativ (CPU), wéinst der Bedierfnes fir Säiten ze dekompriméieren.
- Et gëtt keen Impakt op Schreiwen Operatiounen.
- Impakt op de Checkpoint Prozess (alles hei ass ähnlech wéi d'Operatiounen ze liesen):
- Positiv (Disk IO), wéinst enger Ofsenkung vun der Zuel vun geschriwen Dateiesystem Spären.
- Negativ (CPU, méiglecherweis Scheif IO), wéinst Aarbecht mat spatzen Fichieren.
- Negativ (CPU), wéinst der Bedierfnes fir Säitkompressioun.
Wéi eng Säit vun der Skala wäert d'Skala tippen? Dëst alles hänkt ganz vun der Ëmwelt of, awer ech sinn geneigt ze gleewen datt d'Disk Säit Kompressioun héchstwahrscheinlech zu enger Leeschtungsverschlechterung op de meeschte Systemer féiert. Ausserdeem, Tester op aner DBMSs, déi eng ähnlech Approche mat spatzen Dateien benotzen, weisen e Réckgang an der Leeschtung wann d'Kompressioun aktivéiert ass.
Wéi aktivéiert a konfiguréieren
Wéi uewen erwähnt, ass d'Mindestversioun vun Apache Ignite déi Disk Säit Kompressioun ënnerstëtzt 2.8 an nëmmen de Linux Betribssystem gëtt ënnerstëtzt. Aktivéiert a konfiguréieren wéi follegt:
- Et muss en Ignite-Kompressiounsmodul am Klassewee sinn. Par défaut läit et an der Apache Ignite Verdeelung am libs/optional Verzeechnes an ass net am Klassewee abegraff. Dir kënnt de Verzeechnes einfach op een Niveau op libs réckelen an dann wann Dir et duerch ignite.sh leeft, gëtt et automatesch aktivéiert.
- Persistenz muss aktivéiert ginn (Ageschalt via
DataRegionConfiguration.setPersistenceEnabled(true)). - D'Säitgréisst muss méi grouss sinn wéi d'Dateisystemblockgréisst (Dir kënnt et astellen mat
DataStorageConfiguration.setPageSize()). - Fir all Cache, deem seng Donnéeën kompriméiert musse ginn, musst Dir d'Kompressiounsmethod an (optional) de Kompressiounsniveau (Methoden) konfiguréieren
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
WAL Verdichtung
Wéi heescht dat Aarbecht
Wat ass WAL a firwat ass et néideg? Ganz kuerz: Dëst ass e Log deen all Eventer enthält, déi schlussendlech d'Säitlagerung änneren. Et ass virun allem néideg fir am Fall vun engem Stuerz ze erholen. All Operatioun, ier de Benotzer d'Kontroll gëtt, muss als éischt en Event am WAL ophuelen, sou datt am Fall vun engem Echec et am Logbuch kann zréckgespillt ginn an all Operatiounen restauréiert ginn, fir déi de Benotzer eng erfollegräich Äntwert krut, och wann dës Operatiounen hat keng Zäit fir an der Säitespäicherung op der Disk ze reflektéieren (schonn uewen Et gouf beschriwwen datt d'tatsächlech Schreiwen an d'Säitgeschäft gemaach gëtt an engem Prozess genannt "Checkpointing" mat e puer Verspéidung duerch getrennten Threads).
Entréen am WAL sinn a logesch a kierperlech opgedeelt. Boolesch sinn d'Schlësselen a Wäerter selwer. Kierperlech - reflektéiert Ännerungen op Säiten am Säitegeschäft. Wärend logesch Opzeechnunge fir e puer aner Fäll nëtzlech kënne sinn, sinn kierperlech Opzeechnungen nëmme gebraucht fir Erhuelung am Fall vun engem Crash an Opzeechnunge sinn nëmmen zënter dem leschten erfollegräiche Kontrollpunkt gebraucht. Hei wäerte mir net an den Detail goen an erkläre firwat et esou funktionnéiert, awer déi interesséiert kënnen op de schonn ernimmten Artikel iwwer d'Apache Ignite Wiki verweisen: .
Et ginn dacks e puer kierperlech records pro logesche Rekord. Dat ass, zum Beispill, eng Operatioun an de Cache setzen beaflosst verschidde Säiten an der Säit Erënnerung (eng Säit mat den Donnéeën selwer, Säiten mat Indexen, Säiten mat fräie Lëschten). An e puer syntheteschen Tester hunn ech fonnt datt kierperlech records bis zu 90% vun der WAL Datei besat hunn. Wéi och ëmmer, si gi fir eng ganz kuerz Zäit gebraucht (par défaut ass den Intervall tëscht Kontrollpunkten 3 Minutten). Et wier logesch dës Donnéeën ze läschen nodeems se hir Relevanz verluer hunn. Dëst ass genau wat de WAL Verdichtungsmechanismus mécht: et läscht physesch Opzeechnungen a kompriméiert déi verbleiwen logesch Opzeechnungen mat Zip, während d'Dateigréisst ganz wesentlech reduzéiert gëtt (heiansdo ëm zéng Mol).
Kierperlech besteet WAL aus verschiddene Segmenter (10 Standard) vun enger fixer Gréisst (64MB Standard), déi op eng kreesfërmeg Manéier iwwerschriwwe ginn. Soubal den aktuelle Segment gefëllt ass, gëtt de nächste Segment als aktuell zougewisen, an de gefëllte Segment gëtt an d'Archiv vun engem getrennten Fuedem kopéiert. WAL Verdichtung funktionnéiert scho mat Archivsegmenter. Och, als separat Fuedem, iwwerwaacht et d'Ausféierung vum Checkpoint a fänkt d'Kompressioun an den Archivsegmenter un, fir déi kierperlech Opzeechnungen net méi gebraucht ginn.
Leeschtung Impakt
Zënter WAL Verdichtung leeft als separat Fuedem, sollt et keen direkten Impakt op d'Operatiounen sinn, déi ausgefouert ginn. Awer et setzt nach ëmmer zousätzlech Hannergrondbelaaschtung op d'CPU (Kompressioun) an d'Disk (liest all WAL-Segment aus dem Archiv an schreift déi kompriméiert Segmenter), also wann de System op seng maximal Kapazitéit leeft, féiert et och zu Leeschtungsverschlechterung.
Wéi aktivéiert a konfiguréieren
Dir kënnt d'WAL Verdichtung aktivéieren mat der Immobilie WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Och benotzt d'Method DataStorageConfiguration.setWalCompactionLevel (), Dir kënnt d'Kompressiounsniva setzen wann Dir net mam Standardwäert zefridden sidd (BEST_SPEED).
WAL Säit Snapshot Kompressioun
Wéi heescht dat Aarbecht
Mir hu schonn erausfonnt datt am WAL records a logesch a kierperlech opgedeelt sinn. Fir all Ännerung op all Säit gëtt e kierperleche WAL-Rekord am Säitespäicher generéiert. Kierperlech Opzeechnunge sinn am Tour och an 2 Ënnertypen opgedeelt: Säit Snapshot Record an Delta Record. All Kéier wann mir eppes op enger Säit änneren an et vun engem propperen Zoustand zu engem dreckeg Staat transferéieren, gëtt eng komplett Kopie vun dëser Säit am WAL (Säitschnëtt-Rekord) gespäichert. Och wa mir nëmmen ee Byte am WAL geännert hunn, wäert de Rekord liicht méi grouss sinn wéi d'Säitgréisst. Wa mir eppes op enger scho dreckeg Säit änneren, gëtt en Delta-Rekord am WAL geformt, deen nëmmen Ännerungen am Verglach zum viregten Zoustand vun der Säit reflektéiert, awer net déi ganz Säit. Zënter datt den Zoustand vun de Säiten vun dreckeg op propper zréckgesat gëtt während dem Checkpointprozess, direkt nom Start vum Checkpoint, wäerte bal all kierperlech Opzeechnungen nëmmen aus Snapshots vu Säiten bestoen (well all Säiten direkt nom Start vum Checkpoint propper sinn) , dann, wéi mer den nächste Checkpoint Approche, fänkt d'Delta Rekord Fraktioun wuessen an erëm am Ufank vum nächste Checkpoint zréckgesat. Miessungen an e puer syntheteschen Tester hunn gewisen datt den Undeel vu Säitsnapshots am Gesamtvolumen vu kierperleche Rekorder 90% erreecht.
D'Iddi vu WAL Säit Snapshot Kompressioun ass Säit Snapshots ze kompriméieren mat engem fäerdege Säit Kompressiounsinstrument (kuckt Disk Säit Kompressioun). Zur selwechter Zäit, am WAL, ginn records sequenziell am append-nëmmen Modus gespäichert an et ass kee Besoin fir records un d'Grenze vun Dateiesystemblocken ze binden, also hei, am Géigesaz zum Disk-Säitkompressiounsmechanismus, brauche mir keng sparse Dateien um all; Deementspriechend funktionnéiert dëse Mechanismus net nëmmen op dem OS Linux. Ausserdeem ass et eis net méi wichteg wéi vill mir d'Säit kompriméiere konnten. Och wa mir 1 Byte befreit hunn, ass dëst schonn e positiv Resultat a mir kënnen kompriméiert Donnéeën am WAL späicheren, am Géigesaz zu der Kompressioun vun der Disk Säit, wou mir déi kompriméiert Säit nëmmen späicheren wa mir méi wéi 1 Dateiesystemblock befreit hunn.
Säiten sinn héich kompriméierbar Donnéeën, hiren Undeel am Gesamt WAL Volumen ass ganz héich, also ouni de WAL Dateiformat z'änneren kënne mir eng bedeitend Reduktioun vu senger Gréisst kréien. Kompressioun, dorënner logesch records, géif eng Ännerung am Format a Verloscht vun Onbedenklechkeet verlaangen, Zum Beispill, fir extern Konsumenten déi an logesch records interesséiert kann, mä géif net zu enger bedeitend Reduktioun vun Fichier Gréisst Féierung.
Wéi mat Disk Säit Kompressioun, kann WAL Säit Snapshot Kompressioun ZSTD, LZ4, Snappy Kompressiounsalgorithmen benotzen, souwéi de SKIP_GARBAGE Modus.
Leeschtung Impakt
Et ass net schwéier ze bemierken datt d'WAL Säit Snapshot Kompressioun direkt aktivéiert nëmmen Threads beaflosst déi Daten an d'Säitspeicher schreiwen, dat heescht déi Threads déi Daten an de Cache änneren. Liesen kierperlech records aus WAL geschitt nëmmen eemol, am Moment ass den Node no engem Fall opgehuewe (an nëmmen wann et während engem Checkpoint fällt).
Dëst beaflosst Threads déi Daten op déi folgend Manéier änneren: mir kréien en negativen Effekt (CPU) wéinst der Bedierfnes fir d'Säit all Kéier virum Schreiwen op Disk ze kompriméieren, an e positiven Effekt (Disk IO) wéinst enger Reduktioun vun der Quantitéit vun daten geschriwen. Deementspriechend ass alles hei einfach: wann d'Systemleistung vun der CPU limitéiert ass, kréie mir eng liicht Degradatioun, wann et duerch Disk I/O limitéiert ass, kréie mir eng Erhéijung.
Indirekt, d'Reduktioun vun der WAL Gréisst beaflosst och (positiv) Streamen déi WAL Segmenter an d'Archiv a WAL Verdichtungsstroum dumpen.
Real Performance Tester an eisem Ëmfeld mat syntheteschen Donnéeën hunn e liichte Steigerung gewisen (D'Duerchsatz ass ëm 10% -15% eropgaang, Latenz ass ëm 10% -15% erofgaang).
Wéi aktivéiert a konfiguréieren
Minimum Apache Ignite Versioun: 2.8. Aktivéiert a konfiguréieren wéi follegt:
- Et muss en Ignite-Kompressiounsmodul am Klassewee sinn. Par défaut läit et an der Apache Ignite Verdeelung am libs/optional Verzeechnes an ass net am Klassewee abegraff. Dir kënnt de Verzeechnes einfach op een Niveau op libs réckelen an dann wann Dir et duerch ignite.sh leeft, gëtt et automatesch aktivéiert.
- Persistenz muss aktivéiert ginn (Ageschalt via
DataRegionConfiguration.setPersistenceEnabled(true)). - De Kompressiounsmodus muss mat der Method agestallt ginn
DataStorageConfiguration.setWalPageCompression(), Kompressioun ass par défaut deaktivéiert (DISABLED Modus). - Optional kënnt Dir de Kompressiounsniveau mat der Method setzen
DataStorageConfiguration.setWalPageCompression(), kuckt de Javadoc fir d'Method fir gëlteg Wäerter fir all Modus.
Konklusioun
Déi ugesinn Datekompressiounsmechanismen am Apache Ignite kënnen onofhängeg vunenee benotzt ginn, awer all Kombinatioun vun hinnen ass och akzeptabel. Verstinn wéi se funktionnéieren erlaabt Iech ze bestëmmen wéi gëeegent se fir Är Aufgaben an Ärem Ëmfeld sinn a wat Dir musst opferen wann Dir se benotzt. Disk Säit Kompressioun ass entwéckelt fir d'Haaptspeicher ze kompriméieren a kann e mëttlere Kompressiounsverhältnis ginn. WAL Säit Snapshot Kompressioun gëtt en Duerchschnëttsgrad vu Kompressioun fir WAL Dateien, a wäert héchstwahrscheinlech souguer d'Leeschtung verbesseren. WAL Verdichtung wäert net e positiven Effekt op d'Performance hunn, awer d'Gréisst vun de WAL-Dateien reduzéieren sou vill wéi méiglech andeems physesch Rekorder ofgeschaaft ginn.
Source: will.com