{"id":81936,"date":"2020-05-18T01:42:37","date_gmt":"2020-05-17T23:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera"},"modified":"2020-05-18T01:42:37","modified_gmt":"2020-05-17T23:42:37","slug":"szhatie-dannyh-v-apache-ignite-opyt-sbera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","title":{"rendered":"Datakomprimering i Apache Ignite. Erfaring fra Sberbank","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Datakomprimering i Apache Ignite. Erfaring fra Sberbank\" src=\"\/wp-content\/uploads\/2020\/05\/0e26c686b1f29e88e6be4b8df81ab668.jpg\" style=\"display:block;margin: 0 auto;\" \/>N\u00e5r man arbeider med store datamengder, kan det ofte oppst\u00e5 et akutt problem med mangel p\u00e5 lagringsplass p\u00e5 diskene. En av l\u00f8sningene p\u00e5 dette problemet er komprimering, som gj\u00f8r det mulig \u00e5 \u00f8ke lagringskapasiteten med samme utstyr. I denne artikkelen vil vi se p\u00e5 hvordan datakomprimering fungerer i Apache Ignite. Artikkelen vil bare beskrive de komprimeringsmetodene som er implementert i produktet. Andre metoder for datakomprimering (over nettverket, i minnet) vil, b\u00e5de implementerte og ikke implementerte, falle utenfor rammen av denne artikkelen.<\/p>\n<p>S\u00e5 n\u00e5r persistence-modus er aktivert, begynner Ignite \u00e5 skrive til disk som et resultat av at data i cache-ene endres:<\/p>\n<ol>\n<li>Innholdet i cache-ene<\/li>\n<li>Journal for forh\u00e5ndsskrivning (Write Ahead Log, heretter bare WAL)<\/li>\n<\/ol>\n<p>\nDet eksisterer allerede en mekanisme for komprimering av WAL, kalt WAL-komprimering. I den nylig utgitte Apache Ignite 2.8, ble det ogs\u00e5 introdusert to mekanismer som gj\u00f8r det mulig \u00e5 komprimere data p\u00e5 disk, nemlig disk sidekomprimering for \u00e5 komprimere innholdet i cache-ene og WAL side snapshot-komprimering for \u00e5 komprimere enkelte oppf\u00f8ringer i WAL. Mer informasjon om disse tre mekanismene f\u00f8lger nedenfor.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Disk sidekomprimering<\/h3>\n<p><\/p>\n<h4>Hvordan det fungerer<\/h4>\n<p>\nLa oss kort se p\u00e5 hvordan Ignite lagrer data. For lagring brukes sidet minne. St\u00f8rrelsen p\u00e5 sidene angis ved oppstart av noden og kan ikke endres senere. St\u00f8rrelsen p\u00e5 en side m\u00e5 ogs\u00e5 v\u00e6re en potens av to og delelig med blokkst\u00f8rrelsen til filsystemet. Sider lastes inn i RAM fra disk etter behov, og mengden data p\u00e5 disk kan overstige den tildelte RAM. Hvis det ikke er nok plass i RAM til \u00e5 laste en side fra disk, vil gamle, allerede ubrukte sider bli utskiftet fra RAM.<\/p>\n<p>P\u00e5 disken lagres dataene p\u00e5 f\u00f8lgende m\u00e5te: for hver partisjon av hver cache-gruppe opprettes en separat fil, i denne filen kommer sidene i stigende rekkef\u00f8lge etter indeks. Den fullstendige side-ID-en inneholder ID-en til cache-gruppen, nummeret p\u00e5 partisjonen og indeksen til siden i filen. Dermed kan vi med den fulle side-ID-en entydig bestemme filen og offset i filen for hver side. For mer detaljert informasjon om strukturen til sidet minne, kan du lese artikkelen p\u00e5 Apache Ignite Wiki: <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/IGNITE\/Ignite+Persistent+Store+-+under+the+hood\">Ignite Persistent Store \u2014 hvordan det fungerer<\/a><\/noindex>.<\/p>\n<p>Disk page compression-mekanismen fungerer, som navnet antyder, p\u00e5 sideniv\u00e5. N\u00e5r denne mekanismen er aktivert, h\u00e5ndteres data i RAM som de er, uten noen form for komprimering. Men i det \u00f8yeblikket sidene lagres fra RAM til disk utf\u00f8res det en komprimering.<\/p>\n<p>Men \u00e5 komprimere hver side individuelt er ikke l\u00f8sningen p\u00e5 problemet; vi m\u00e5 p\u00e5 en eller annen m\u00e5te redusere st\u00f8rrelsen p\u00e5 de endelige datafilene. Hvis st\u00f8rrelsen p\u00e5 en side slutter \u00e5 v\u00e6re fast, kan vi ikke lenger skrive sidene i filen \u00e9n etter \u00e9n, da dette kan f\u00f8re til en rekke problemer.<\/p>\n<ul>\n<li>Vi vil ikke kunne beregne offset for siden ved hjelp av sideindeksen, for \u00e5 fastsl\u00e5 hvor den er plassert i filen.<\/li>\n<li>Det er uklart hvordan vi skal h\u00e5ndtere sider som ikke er p\u00e5 slutten av filen og endrer st\u00f8rrelse. Hvis st\u00f8rrelsen p\u00e5 en side reduseres, g\u00e5r plassen den frigj\u00f8r tapt. Hvis st\u00f8rrelsen p\u00e5 siden \u00f8ker, m\u00e5 det s\u00f8kes etter et nytt sted i filen for den.<\/li>\n<li>Hvis siden flyttes med et antall byte som ikke er et multiplum av blokkens st\u00f8rrelse i filsystemet, vil lesing eller skriving kreve at ett ekstra filsystemblokk ogs\u00e5 ber\u00f8res, noe som kan f\u00f8re til ytelsesforringelse.<\/li>\n<\/ul>\n<p>\nFor ikke \u00e5 h\u00e5ndtere disse problemene selv, bruker disk page compression i Apache Ignite et filsystemmekanisme kalt sparse filer. En sparse (sparsomt) fil er en fil hvor enkelte regioner fylt med nuller kan merkes som \"hull\". Med dette vil det ikke bli tildelt filsystemblokker for \u00e5 lagre disse hullene, noe som resulterer i plassbesparelser p\u00e5 disken.<\/p>\n<p>Det er logisk at for \u00e5 frigj\u00f8re en filsystemblokk, m\u00e5 st\u00f8rrelsen p\u00e5 hullet v\u00e6re st\u00f8rre enn eller lik filsystemblokkens st\u00f8rrelse, noe som legger et ekstra begrensning p\u00e5 st\u00f8rrelsen p\u00e5 siden i Apache Ignite: for at komprimeringen skal gi noen effekt, m\u00e5 st\u00f8rrelsen p\u00e5 siden v\u00e6re strengt st\u00f8rre enn st\u00f8rrelsen p\u00e5 filsystemblokken. Hvis st\u00f8rrelsen p\u00e5 siden er lik st\u00f8rrelsen p\u00e5 blokken, vil vi aldri kunne frigj\u00f8re en eneste blokk, da for \u00e5 frigj\u00f8re en enkelt blokk m\u00e5 den komprimerte siden ta opp 0 byte. Hvis st\u00f8rrelsen p\u00e5 siden derimot er lik st\u00f8rrelsen p\u00e5 2 eller 4 blokker, kan vi likevel frigj\u00f8re minst \u00e9n blokk hvis siden v\u00e5r komprimeres med minst 50 % eller 75 % henholdsvis.<\/p>\n<p>Dermed er den endelige beskrivelsen av hvordan mekanismen fungerer: N\u00e5r en side skrives til disken, fors\u00f8kes det \u00e5 komprimere siden. Hvis st\u00f8rrelsen p\u00e5 den komprimerte siden gj\u00f8r det mulig \u00e5 frigj\u00f8re en eller flere blokker av filsystemet, skrives siden i komprimert form, mens en \u00abluke\u00bb opprettes p\u00e5 stedet for de frigjorte blokkene (systemanrop blir utf\u00f8rt med flagget \u00abpunch hole\u00bb). <code>fallocate()<\/code> Hvis st\u00f8rrelsen p\u00e5 den komprimerte siden ikke tillater blokkene \u00e5 bli frigitt, lagres siden som den er, uforandret. Alle offsets for sidene beregnes p\u00e5 samme m\u00e5te som uten komprimering, ved \u00e5 multiplisere sideindeksen med sidest\u00f8rrelsen. Ingen relokasjon av sidene er n\u00f8dvendig. Offsets for sidene, akkurat som uten komprimering, vil falle p\u00e5 grensene til filsystemblokkene.<\/p>\n<p><img decoding=\"async\" alt=\"Datakomprimering i Apache Ignite. Erfaring fra Sberbank\" src=\"\/wp-content\/uploads\/2020\/05\/6a6c6ad83d3b8591f76b9343ff067746.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nI den n\u00e5v\u00e6rende implementeringen kan Ignite jobbe med sparse-filer kun under Linux, og dermed kan disk page compression kun aktiveres n\u00e5r Ignite brukes p\u00e5 dette operativsystemet.<\/p>\n<p>Komprimeringsalgoritmene som kan brukes for disk page compression: ZSTD, LZ4, Snappy. I tillegg finnes det en driftmodus (SKIP_GARBAGE), hvor bare det ubrukte plassen i siden kastes uten at komprimering p\u00e5 de gjenv\u00e6rende dataene brukes, noe som reduserer belastningen p\u00e5 CPU sammenlignet med de tidligere nevnte algoritmene.<\/p>\n<h4>Innvirkning p\u00e5 ytelse <\/h4>\n<p>\nDessverre har jeg ikke utf\u00f8rt faktiske ytelsestester p\u00e5 virkelige oppsett, siden vi ikke planlegger \u00e5 bruke denne mekanismen i produksjon, men vi kan teoretisk diskutere hvor vi vil tape og hvor vi vil vinne.<\/p>\n<p>For dette m\u00e5 vi huske hvordan lesing og skriving av sider utf\u00f8res n\u00e5r vi aksesserer dem:<\/p>\n<ul>\n<li>Ved utf\u00f8relse av en leseoperasjon s\u00f8kes det f\u00f8rst i RAM; hvis s\u00f8ket mislykkes, lastes siden inn i RAM fra disken av den samme tr\u00e5den som utf\u00f8rer lesingen.<\/li>\n<li>Ved utf\u00f8ring av en skriveoperasjon markeres siden i RAM som skitten, men den fysiske lagringen av siden p\u00e5 disken skjer ikke umiddelbart i tr\u00e5den som utf\u00f8rer skrivingen. Alle skitne sider lagres p\u00e5 disken senere i prosessen med checkpoint av separate tr\u00e5der.<\/li>\n<\/ul>\n<p>\nDermed er innvirkningen p\u00e5 leseoperasjoner:<\/p>\n<ul>\n<li>Positiv (disk IO), takket v\u00e6re reduksjonen i antall leste blokker av filsystemet.<\/li>\n<li>Negativ (CPU), fordi det er n\u00f8dvendig med ekstra belastning for operativsystemet til \u00e5 h\u00e5ndtere sparse filer. Det kan ogs\u00e5 henvises til at det kan dukke opp ekstra IO-operasjoner for \u00e5 lagre en mer kompleks struktur av sparse filer (jeg er dessverre ikke kjent med alle detaljene i hvordan sparse filer fungerer).<\/li>\n<li>Negativ (CPU), p\u00e5 grunn av behovet for dekomprimering av sider.<\/li>\n<li>Ingen p\u00e5virkning p\u00e5 skriveoperasjoner.<\/li>\n<li>P\u00e5virkning p\u00e5 sjekkpunktprosessen (her er det likt som for leseoperasjoner):<\/li>\n<li>Positiv (disk IO), fordi antallet skrevne blokker i filsystemet reduseres.<\/li>\n<li>Negativ (CPU, muligens disk IO), p\u00e5 grunn av arbeidet med sparse filer.<\/li>\n<li>Negativ (CPU), p\u00e5 grunn av behovet for komprimering av sider.<\/li>\n<\/ul>\n<p>\nHvilken side veier tyngst? Dette avhenger veldig av milj\u00f8et, men jeg tendere til \u00e5 tro at disk page compression mest sannsynlig vil f\u00f8re til ytelsesforringelse i de fleste systemer. Dessuten viser tester p\u00e5 andre DBMS-er som bruker en lignende tiln\u00e6rming med sparse filer fall i ytelse n\u00e5r komprimering er aktivert.<\/p>\n<h4>Hvordan aktivere og konfigurere<\/h4>\n<p>\nSom nevnt tidligere, den minste versjonen av Apache Ignite som st\u00f8tter disk page compression: 2.8, og det st\u00f8ttes kun av operativsystemet Linux. Aktivering og konfigurasjon gj\u00f8res som f\u00f8lger:<\/p>\n<ul>\n<li>Modulen ignite-compression m\u00e5 v\u00e6re i class-path. Som standard ligger den i distribusjonen av Apache Ignite i katalogen libs\/optional og er ikke inkludert i class-path. Du kan ganske enkelt flytte katalogen opp ett niv\u00e5 i libs, og da vil den bli automatisk inkludert n\u00e5r du starter med ignite.sh.<\/li>\n<li>Persistens m\u00e5 v\u00e6re aktivert (Aktiveres gjennom <code>DataRegionConfiguration.setPersistenceEnabled(true))<\/code>.<\/li>\n<li>Sidest\u00f8rrelsen m\u00e5 v\u00e6re st\u00f8rre enn blokkst\u00f8rrelsen i filsystemet (kan settes ved hjelp av <code>DataStorageConfiguration.setPageSize()<\/code> ).<\/li>\n<li>For hver cache hvor dataene m\u00e5 komprimeres, m\u00e5 du konfigurere komprimeringsmetoden og (valgfritt) komprimeringsniv\u00e5et i konfigurasjonen (metoder <code>CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()<\/code>).<\/li>\n<\/ul>\n<p><\/p>\n<h3>WAL komprimering<\/h3>\n<p><\/p>\n<h4>Hvordan det fungerer<\/h4>\n<p>\nHva er WAL og hvorfor er det viktig? Kort sagt: det er en journal som fanger alle hendelser som til slutt endrer sidelageret. Den er f\u00f8rst og fremst n\u00f8dvendig for \u00e5 kunne gjenopprette etter et systemkrasj. Hver operasjon m\u00e5 f\u00f8rst registrere en hendelse i WAL f\u00f8r den gir kontroll tilbake til brukeren, slik at man i tilfelle krasj kan spille tilbake journalen og gjenskape alle operasjoner som ga brukeren et vellykket svar, selv om disse operasjonene ikke ble lagret p\u00e5 disk i sidelageret (det ble tidligere nevnt at den faktiske lagringen i sidelageret skjer i en prosess kalt \u00abcheckpoint\u00bb, med noe etterslep fra separate tr\u00e5der).<\/p>\n<p>Oppf\u00f8ringene i WAL deles inn i logiske og fysiske. Logiske er selve n\u00f8klene og verdiene. Fysiske reflekterer endringer i sidene i sidelageret. Mens logiske oppf\u00f8ringer kan v\u00e6re nyttige i andre sammenhenger, er fysiske oppf\u00f8ringer bare n\u00f8dvendige for \u00e5 gjenopprette etter et krasj, og det er kun oppf\u00f8ringer fra det siste vellykkede checkpointet som er relevante. Her vil vi ikke g\u00e5 i detaljer om hvorfor dette fungerer som det gj\u00f8r, men de som er interesserte kan referere til den allerede nevnte artikkelen p\u00e5 Apache Ignite Wiki: <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/IGNITE\/Ignite+Persistent+Store+-+under+the+hood\">Ignite Persistent Store \u2014 hvordan det fungerer<\/a><\/noindex>.<\/p>\n<p>En logisk post kan ofte ha flere fysiske poster. Det vil si at for eksempel en put-operasjon i cachen ber\u00f8rer flere sider i sideminnet (siden med selve dataene, sider med indekser, sider med free-list'er). I noen syntetiske tester har jeg f\u00e5tt det til at fysiske poster utgjorde opptil 90 % av volumet p\u00e5 WAL-filen. De er imidlertid n\u00f8dvendige bare for en kort periode (som standard er intervallet mellom sjekkpunktene 3 minutter). Det ville v\u00e6re logisk \u00e5 kvitte seg med disse dataene etter at de har mistet relevans. Det er nettopp det mekanismen for WAL komprimering gj\u00f8r, den fjerner fysiske poster og komprimerer de gjenv\u00e6rende logiske postene med zip, samtidig som filst\u00f8rrelsen reduseres betydelig (noen ganger med titalls ganger).<\/p>\n<p>Fysisk WAL best\u00e5r av flere segmenter (som standard 10) med fast st\u00f8rrelse (som standard 64 MB), som overf\u00f8res p\u00e5 en sirkul\u00e6r m\u00e5te. S\u00e5 snart det n\u00e5v\u00e6rende segmentet er fylt opp, tildeles det neste segmentet, og det fylte segmentet kopieres til arkiv i en egen tr\u00e5d. WAL-komprimering fungerer allerede med arkivsegmentene. I tillegg f\u00f8lger den med en egen tr\u00e5d opp gjennomf\u00f8ringen av sjekkpunktet og begynner komprimering av arkivsegmentene, hvor de fysiske registreringene ikke lenger er n\u00f8dvendige.<\/p>\n<p><img decoding=\"async\" alt=\"Datakomprimering i Apache Ignite. Erfaring fra Sberbank\" src=\"\/wp-content\/uploads\/2020\/05\/ca8690ba7a350df9530f2ccf01c90975.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>Innvirkning p\u00e5 ytelse<\/h4>\n<p>\nSiden WAL-komprimering kj\u00f8rer i en egen tr\u00e5d, skal det ikke v\u00e6re noen direkte innvirkning p\u00e5 de utf\u00f8rende operasjonene. Men den gir likevel en ekstra bakgrunnsbelastning p\u00e5 CPU (komprimering) og disk (lesing av hvert WAL-segment fra arkivet og skriving av komprimerte segmenter), s\u00e5 hvis systemet kj\u00f8rer p\u00e5 grensen av kapasitet, vil det ogs\u00e5 f\u00f8re til ytelsesdegradering.<\/p>\n<h4>Hvordan aktivere og konfigurere<\/h4>\n<p>\nWAL-komprimering kan aktiveres ved hjelp av egenskapen <code>WalCompactionEnabled<\/code> i <code>DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)<\/code>). I tillegg kan graden av komprimering spesifiseres med metoden DataStorageConfiguration.setWalCompactionLevel() hvis standardverdien (BEST_SPEED) ikke er tilfredsstillende.<\/p>\n<h3>WAL-side snapshotkomprimering<\/h3>\n<p><\/p>\n<h4>Hvordan det fungerer<\/h4>\n<p>\nVi har allerede avklart at WAL-poster deles inn i logiske og fysiske. For hver endring p\u00e5 hver side i sidens minne dannes det en fysisk WAL-post. Fysiske poster deles igjen inn i to underkategorier: page snapshot record og delta record. Hver gang vi gj\u00f8r en endring p\u00e5 en side og oversetter den fra en ren tilstand til en skitten tilstand, lagres en full kopi av denne siden i WAL (page snapshot record \u2014 en snapshot av siden). Selv om vi bare endrer ett byte, vil WAL lagre en post som er litt st\u00f8rre enn st\u00f8rrelsen p\u00e5 siden. Dersom vi endrer noe p\u00e5 en allerede skitten side, dannes det en delta record i WAL, som kun reflekterer endringene sammenlignet med den tidligere tilstanden til siden, men ikke hele siden. Siden tilbakestilling av sidens tilstand fra skitten til ren skjer i l\u00f8pet av et checkpoint, vil nesten alle fysiske poster rett etter starten p\u00e5 checkpointet best\u00e5 av snapshots av sidene (ettersom alle sidene rett etter starten av checkpointet er rene). Etter hvert som vi n\u00e6rmer oss neste checkpoint, begynner andelen delta records \u00e5 \u00f8ke, f\u00f8r den igjen tilbakestilles ved starten av neste checkpoint. M\u00e5linger fra noen syntetiske tester har vist at andelen snapshots av sidene i den totale mengden av fysiske poster kan n\u00e5 90%.<\/p>\n<p>Ideen med WAL page snapshot kompresjon er \u00e5 komprimere snapshots av sidene ved \u00e5 bruke et allerede eksisterende verkt\u00f8y for kompresjon av sider (se disk page compression). Her lagres WAL-postene sekvensielt i en append-only-modus, og det er ikke n\u00f8dvendig \u00e5 knytte postene til grensene p\u00e5 filsystemets blokker. Derfor, i motsetning til mekanismen for disk page compression, trenger vi absolutt ikke sparse-filer, noe som betyr at denne mekanismen vil fungere ikke bare p\u00e5 Linux OS. I tillegg er det ikke lenger viktig hvor mye vi klarte \u00e5 komprimere siden. Selv om vi frigjorde 1 byte, er det allerede et positivt resultat, og vi kan lagre de komprimerte dataene i WAL, i motsetning til disk page compression, hvor vi lagrer den komprimerte siden bare hvis vi har frigjort mer enn 1 blokk i filsystemet.<\/p>\n<p>Sider er godt komprimerbare data, og deres andel av den totale WAL-st\u00f8rrelsen er veldig h\u00f8y. Dermed kan vi oppn\u00e5 betydelig reduksjon i st\u00f8rrelsen p\u00e5 filen uten \u00e5 endre formatet for WAL-filen. Komprimering av logiske oppf\u00f8ringer ville derimot krevd endring av formatet og tapt kompatibilitet, for eksempel for eksterne brukere som kan v\u00e6re interessert i logiske oppf\u00f8ringer, uten \u00e5 gi en betydelig reduksjon i filens volum.<\/p>\n<p>Som med disk sidekomprimering kan algoritmer som ZSTD, LZ4, Snappy, samt SKIP_GARBAGE-modus brukes for WAL-sidebildekomprimering.<\/p>\n<h4>Innvirkning p\u00e5 ytelse<\/h4>\n<p>\nDet er ikke vanskelig \u00e5 legge merke til at direkte aktivering av WAL-sidebildekomprimering kun p\u00e5virker de tr\u00e5dene som skriver data til sideminne, det vil si de tr\u00e5dene som endrer dataene i cache. Lese fra WAL-fysiske oppf\u00f8ringer skjer bare \u00e9n gang, i \u00f8yeblikket n\u00e5r noden starter etter ett fall (og bare i tilfelle av fall under sjekkpunktet).<\/p>\n<p>Dette p\u00e5virker tr\u00e5dene som endrer data p\u00e5 f\u00f8lgende m\u00e5te: vi f\u00e5r en negativ effekt (CPU) p\u00e5 grunn av n\u00f8dvendigheten av \u00e5 komprimere siden f\u00f8r skriving til disk, og en positiv effekt (disk IO) p\u00e5 grunn av reduksjonen av dataene som skrives. Dermed er det enkelt: hvis systemytelsen er begrenset av CPU, f\u00e5r vi en liten nedgang; hvis det er diskinn-\/utgang, f\u00e5r vi en \u00f8kning.<\/p>\n<p>Indirekte reduserer st\u00f8rrelsen p\u00e5 WAL ogs\u00e5 (positivt) p\u00e5virkning p\u00e5 tr\u00e5dene som arkiverer WAL-segmenter og p\u00e5 tr\u00e5dene som reduserer WAL.<\/p>\n<p>Reelle ytelsestester i v\u00e5rt milj\u00f8 med syntetiske data viste en liten \u00f8kning (gjennomstr\u00f8mning \u00f8kte med 10%-15%, latenstid reduserte med 10%-15%).<\/p>\n<h4>Hvordan aktivere og konfigurere<\/h4>\n<p>\nMinimum versjon av Apache Ignite: 2.8. Aktivering og konfigurasjon skjer som f\u00f8lger:<\/p>\n<ul>\n<li>Modulen ignite-compression m\u00e5 v\u00e6re i class-path. Som standard ligger den i distribusjonen av Apache Ignite i katalogen libs\/optional og er ikke inkludert i class-path. Du kan ganske enkelt flytte katalogen opp ett niv\u00e5 i libs, og da vil den bli automatisk inkludert n\u00e5r du starter med ignite.sh.<\/li>\n<li>Persistens m\u00e5 v\u00e6re aktivert (Aktiveres gjennom <code>DataRegionConfiguration.setPersistenceEnabled(true)<\/code>).<\/li>\n<li>Komprimeringsmodusen m\u00e5 angis ved hjelp av metoden <code>DataStorageConfiguration.setWalPageCompression()<\/code>, som standard er komprimering deaktivert (modus DISABLED).<\/li>\n<li>Valgfritt kan graden av komprimering angis med metoden <code>DataStorageConfiguration.setWalPageCompression()<\/code>, se javadoc for metoden for tillatte verdier for hver av modusene.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Konklusjon<\/h3>\n<p>\nDe mekanismene for datakomprimering i Apache Ignite kan brukes uavhengig av hverandre, men ogs\u00e5 enhver kombinasjon er tillatt. Forst\u00e5elsen av prinsippene for deres arbeid vil gj\u00f8re det mulig \u00e5 avgj\u00f8re hvor godt de passer til dine oppgaver i ditt milj\u00f8 og hva du m\u00e5 ofre for \u00e5 bruke dem. Disksidekomprimering er designet for \u00e5 komprimere det prim\u00e6re lageret og kan gi en gjennomsnittlig komprimeringsgrad. WAL-sidefotosnap-komprimering vil gi en gjennomsnittlig komprimeringsgrad av WAL-filer, og vil mest sannsynlig til og med forbedre ytelsen. WAL-komprimering vil ikke ha en positiv innvirkning p\u00e5 ytelsen, men vil maksimalt redusere st\u00f8rrelsen p\u00e5 WAL-filer ved \u00e5 fjerne fysiske oppf\u00f8ringer.<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/sberbank\/blog\/502136\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438 \u0440\u0430\u0431\u043e\u0442\u0435 \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c\u0438 \u043e\u0431\u044a\u0435\u043c\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0438\u043d\u043e\u0433\u0434\u0430 \u043c\u043e\u0436\u0435\u0442 \u043e\u0441\u0442\u0440\u043e \u0432\u0441\u0442\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u043d\u0435\u0445\u0432\u0430\u0442\u043a\u0438 \u043c\u0435\u0441\u0442\u0430 \u043d\u0430 \u0434\u0438\u0441\u043a\u0430\u0445. \u041e\u0434\u043d\u0438\u043c \u0438\u0437 \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u0432 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0434\u0430\u043d\u043d\u043e\u0439 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0436\u0430\u0442\u0438\u0435, \u0431\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u043a\u043e\u0442\u043e\u0440\u043e\u043c\u0443, \u043d\u0430 \u0442\u043e\u043c \u0436\u0435 \u043e\u0431\u043e\u0440\u0443\u0434\u043e\u0432\u0430\u043d\u0438\u0438, \u043c\u043e\u0436\u043d\u043e \u0441\u0435\u0431\u0435 \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442\u044c \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043e\u0431\u044a\u0435\u043c\u044b \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f. \u0412 \u0434\u0430\u043d\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0441\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u0431\u0443\u0434\u0443\u0442 \u043e\u043f\u0438\u0441\u0430\u043d\u044b \u0442\u043e\u043b\u044c\u043a\u043e \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0432\u043d\u0443\u0442\u0440\u0438 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":81937,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-81936","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.5 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u041e\u043f\u044b\u0442 \u0421\u0431\u0435\u0440\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-17T23:42:37+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-17T23:42:37+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Datakomprimering i Apache Ignite. Erfaringer fra Sber | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u041e\u043f\u044b\u0442 \u0421\u0431\u0435\u0440\u0430 | ProHoster","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-17T23:42:37+00:00","article:modified_time":"2020-05-17T23:42:37+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"81936","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:47:30","updated":"2022-10-02 17:21:32","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/81936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=81936"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/81936\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/81937"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=81936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=81936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=81936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}