{"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\/da\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","title":{"rendered":"Datakomprimering i Apache Ignite. Erfaringer fra Sber.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Datakomprimering i Apache Ignite. Erfaringer fra Sber.\" src=\"\/wp-content\/uploads\/2020\/05\/0e26c686b1f29e88e6be4b8df81ab668.jpg\" style=\"display:block;margin: 0 auto;\" \/>N\u00e5r man arbejder med store m\u00e6ngder data, kan problemet med pladsmangel p\u00e5 diske ofte opst\u00e5. En af l\u00f8sningerne p\u00e5 dette problem er komprimering, som g\u00f8r det muligt at \u00f8ge lagerkapaciteten p\u00e5 det samme udstyr. I denne artikel vil vi se p\u00e5, hvordan datakomprimering fungerer i Apache Ignite. Artiklen vil kun beskrive de komprimeringsmetoder, der er implementeret i produktet. Andre metoder til datakomprimering (over netv\u00e6rket, i hukommelsen) vil ikke v\u00e6re medtaget, uanset om de er implementeret eller ej.<\/p>\n<p>S\u00e5 n\u00e5r persistence-tilstand er aktiveret, begynder Ignite at skrive til disken som et resultat af \u00e6ndringer i dataene i cacherne:<\/p>\n<ol>\n<li>Indholdet af cacherne<\/li>\n<li>Journal for forudg\u00e5ende skrivning (Write Ahead Log, herefter blot WAL)<\/li>\n<\/ol>\n<p>\nDer har l\u00e6nge eksisteret en mekanisme til komprimering af WAL, kaldet WAL compaction. I den nyligt udgivne Apache Ignite 2.8 er der ogs\u00e5 kommet to nye mekanismer, der muligg\u00f8r komprimering af data p\u00e5 disken, nemlig disk page compression til komprimering af indholdet af cacherne og WAL page snapshot compression til komprimering af visse WAL-poster. L\u00e6s mere om disse tre mekanismer nedenfor.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Disk page compression<\/h3>\n<p><\/p>\n<h4>Hvordan fungerer det<\/h4>\n<p>\nLad os f\u00f8rst kort gennemg\u00e5, hvordan Ignite opbevarer data. Der anvendes sideorienteret hukommelse til opbevaring. St\u00f8rrelsen p\u00e5 siden fasts\u00e6ttes ved start af noden og kan ikke \u00e6ndres senere; st\u00f8rrelsen skal ogs\u00e5 v\u00e6re en potens af to og et multipel af filsystemets blokst\u00f8rrelse. Sider hentes ind i RAM fra disken efter behov, og st\u00f8rrelsen p\u00e5 dataene p\u00e5 disken kan overstige den tildelte RAM. Hvis der ikke er plads i RAM til at hente en side fra disken, vil gamle, ikke-brugte sider blive skubbet ud af RAM.<\/p>\n<p>Dataene gemmes p\u00e5 disken p\u00e5 f\u00f8lgende m\u00e5de: for hver partition af hver cache-gruppe oprettes en separat fil, hvor siderne i stigende indeks r\u00e6kkef\u00f8lge f\u00f8lger hinanden. Den fulde identifiering af en side indeholder identificeringen af cache-gruppen, partitionens nummer og sidens indeks i filen. Dermed kan vi entydigt bestemme filen og offsettet i filen for hver side ud fra den fulde identifiering. Du kan l\u00e6se mere om opbygningen af sideorienteret hukommelse i artiklen 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 under overfladen<\/a><\/noindex>.<\/p>\n<p>Disk page compression-mekanismen arbejder, som navnet antyder, p\u00e5 en side-for-side basis. N\u00e5r denne mekanisme er aktiveret, behandles data i RAM som de er, uden nogen kompression, men n\u00e5r siderne gemmes fra RAM til disk, komprimeres de.<\/p>\n<p>Men at komprimere hver side individuelt l\u00f8ser stadig ikke problemet; vi skal finde en m\u00e5de at reducere st\u00f8rrelsen p\u00e5 de endelige datofiler. Hvis st\u00f8rrelsen p\u00e5 en side ikke l\u00e6ngere er fast, kan vi ikke l\u00e6ngere skrive sider i filen \u00e9n efter \u00e9n, da det kan for\u00e5rsage en r\u00e6kke problemer:<\/p>\n<ul>\n<li>Vi kan ikke beregne offset for en side i filen ved hj\u00e6lp af sidens indeks.<\/li>\n<li>Det er uklart, hvordan man skal h\u00e5ndtere sider, der ikke er i slutningen af filen og \u00e6ndrer st\u00f8rrelse. Hvis st\u00f8rrelsen p\u00e5 en side reduceres, vil det frigjorte plads g\u00e5 tabt. Hvis st\u00f8rrelsen p\u00e5 en side \u00f8ges, skal der findes ny plads til den i filen.<\/li>\n<li>Hvis en side flyttes med et antal bytes, der ikke er et multiplum af blokst\u00f8rrelsen i filsystemet, vil l\u00e6sning eller skrivning af den kr\u00e6ve, at der ber\u00f8res en blok mere i filsystemet, hvilket kan f\u00f8re til degradering af ydeevnen.<\/li>\n<\/ul>\n<p>\nFor at undg\u00e5 at skulle h\u00e5ndtere disse problemer selv, bruger disk page compression i Apache Ignite et filsystemmekanisme kaldet sparse filer. En sparse (sparsom) fil er en fil, i hvilken nogle regioner, der er fyldt med nuller, kan m\u00e6rkes som 'huller'. Der vil ikke blive tildelt filsystemblokke til at gemme disse huller, hvilket resulterer i besparelser p\u00e5 diskplads.<\/p>\n<p>Det er logisk, at for at frig\u00f8re en filsystemblok, skal st\u00f8rrelsen af hullet v\u00e6re st\u00f8rre end eller lig med blokst\u00f8rrelsen, hvilket p\u00e5l\u00e6gger en yderligere begr\u00e6nsning for side st\u00f8rrelsen i Apache Ignite: For at kompressionen skal have en effekt, skal st\u00f8rrelsen p\u00e5 en side v\u00e6re strengt st\u00f8rre end blokst\u00f8rrelsen i filsystemet. Hvis st\u00f8rrelsen p\u00e5 en side er lig med blokst\u00f8rrelsen, vil vi aldrig kunne frig\u00f8re nogen blokke, da for at frig\u00f8re en enkelt blok, skal den komprimerede side tage 0 bytes. Hvis st\u00f8rrelsen p\u00e5 en side derimod er lig med st\u00f8rrelsen p\u00e5 2 eller 4 blokke, kan vi allerede frig\u00f8re mindst \u00e9n blok, hvis vores side komprimeres med mindst 50% eller 75% henholdsvis.<\/p>\n<p>S\u00e5ledes er den endelige beskrivelse af mekanismens arbejde: N\u00e5r en side skrives til disk, fors\u00f8ges det at komprimere siden. Hvis den komprimerede sides st\u00f8rrelse g\u00f8r det muligt at frigive en eller flere blokke fra filsystemet, skrives siden i komprimeret form, og der laves et 'hul' (udf\u00f8res et systemopkald <code>fallocate()<\/code> med flaget \u201epunch hole\u201c). Hvis st\u00f8rrelsen p\u00e5 den komprimerede side ikke tillader at frigive blokke, gemmes siden som den er, i ukomprimeret form. Alle offsets af siderne beregnes som uden kompression, ved at gange sideindekset med sidens st\u00f8rrelse. Ingen relokering af sider kr\u00e6ves manuelt. Offsets af siderne, som uden kompression, rammer gr\u00e6nserne for filsystemblokkene.<\/p>\n<p><img decoding=\"async\" alt=\"Datakomprimering i Apache Ignite. Erfaringer fra Sber.\" src=\"\/wp-content\/uploads\/2020\/05\/6a6c6ad83d3b8591f76b9343ff067746.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nI den nuv\u00e6rende implementering kan Ignite kun arbejde med sparse filer under Linux, derfor kan disk page compression kun aktiveres, n\u00e5r Ignite bruges p\u00e5 dette operativsystem.<\/p>\n<p>Kompressionsalgoritmer, der kan anvendes til disk page compression: ZSTD, LZ4, Snappy. Derudover er der en driftsform (SKIP_GARBAGE), hvor kun det ubrugte plads i siden kasseres uden at anvende kompression p\u00e5 de resterende data, hvilket reducerer CPU-belastningen sammenlignet med de tidligere n\u00e6vnte algoritmer.<\/p>\n<h4>Indflydelse p\u00e5 ydeevnen <\/h4>\n<p>\nDesv\u00e6rre har jeg ikke foretaget m\u00e5linger af ydeevnen p\u00e5 reelle teststands, da vi ikke planl\u00e6gger at bruge denne mekanisme i produktionen, men vi kan teoretisk overveje, hvor vi vil tabe, og hvor vi vil vinde.<\/p>\n<p>For at forst\u00e5 dette m\u00e5 vi huske, hvordan l\u00e6sning og skrivning af sider udf\u00f8res, n\u00e5r der tilg\u00e5s dem:<\/p>\n<ul>\n<li>N\u00e5r l\u00e6seoperationen udf\u00f8res, s\u00f8ges det f\u00f8rst i RAM, hvis s\u00f8gningen ikke lykkes, indl\u00e6ses siden i RAM fra disken af den samme tr\u00e5d, der udf\u00f8rer l\u00e6sningen.<\/li>\n<li>Ved udf\u00f8relsen af skriveoperationer bliver siden i RAM markeret som beskidt, men den fysiske gemming af siden til disk finder ikke sted med det samme i den tr\u00e5d, der udf\u00f8rer skrivningen. Alle beskidte sider gemmes senere p\u00e5 disken i checkpoints af separate tr\u00e5de.<\/li>\n<\/ul>\n<p>\nDerfor p\u00e5virkning p\u00e5 l\u00e6seoperationer:<\/p>\n<ul>\n<li>Positiv (disk IO), ved at reducere antallet af l\u00e6ste blokke fra filsystemet.<\/li>\n<li>Negativ (CPU), p\u00e5 grund af den ekstra belastning, der kr\u00e6ves af operativsystemet for at arbejde med sparse-filer. Det er ogs\u00e5 muligt, at der her implicit opst\u00e5r yderligere IO-operationer for at bevare den mere komplekse struktur af en sparse-fil (desv\u00e6rre er jeg ikke bekendt med alle detaljer om, hvordan sparse-filer fungerer).<\/li>\n<li>Negativ (CPU), p\u00e5 grund af behovet for dekompression af sider.<\/li>\n<li>Der er ingen indflydelse p\u00e5 skriveoperationer.<\/li>\n<li>Indflydelse p\u00e5 checkpoint-processen (her er det analogt med l\u00e6seoperationer):<\/li>\n<li>Positiv (disk IO), p\u00e5 grund af reduktionen af antallet af skrevne blokke i filsystemet.<\/li>\n<li>Negativ (CPU, muligvis disk IO), p\u00e5 grund af arbejdet med sparse-filer.<\/li>\n<li>Negativ (CPU), p\u00e5 grund af behovet for kompression af sider.<\/li>\n<\/ul>\n<p>\nHvilken vej v\u00e6gtene vil tippe? Det afh\u00e6nger meget af milj\u00f8et, men jeg h\u00e6lder til, at disk sidekompression sandsynligvis vil f\u00f8re til en nedgang i ydeevnen p\u00e5 de fleste systemer. Is\u00e6r da tests p\u00e5 andre DBMS'er, der bruger en lignende tilgang med sparse-filer, viser fald i ydeevnen, n\u00e5r kompression er aktiveret.<\/p>\n<h4>Hvordan man aktiverer og konfigurerer<\/h4>\n<p>\nSom n\u00e6vnt ovenfor er den minimale version af Apache Ignite, der underst\u00f8tter disk page compression: 2.8 og underst\u00f8ttes kun af operativsystemet Linux. Aktivering og konfiguration udf\u00f8res som f\u00f8lger:<\/p>\n<ul>\n<li>Modulet ignite-compression skal v\u00e6re i class-path. Som standard findes det i distribueringspakken af Apache Ignite i biblioteket libs\/optional og inkluderes ikke i class-path. Du kan blot flytte biblioteket op \u00e9t niveau i libs, s\u00e5 det automatisk inkluderes, n\u00e5r du starter via ignite.sh.<\/li>\n<li>Persistence skal v\u00e6re aktiveret (aktiveres via <code>DataRegionConfiguration.setPersistenceEnabled(true))<\/code>.<\/li>\n<li>St\u00f8rrelsen p\u00e5 siden skal v\u00e6re st\u00f8rre end st\u00f8rrelsen p\u00e5 filsystemblokken (kan angives ved hj\u00e6lp af <code>DataStorageConfiguration.setPageSize()<\/code> ).<\/li>\n<li>For hver cache, hvis data skal komprimeres, skal der i konfigurationen indstilles en kompressionsmetode og (valgfrit) kompressionsniveau (metoderne <code>CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()<\/code>).<\/li>\n<\/ul>\n<p><\/p>\n<h3>WAL komprimering<\/h3>\n<p><\/p>\n<h4>Hvordan fungerer det<\/h4>\n<p>\nHvad er WAL, og hvorfor er det vigtigt? Meget kort: Det er en log, hvor alle begivenheder, der \u00e6ndrer det sidetilfredsstillende lager, registreres. Det er prim\u00e6rt n\u00f8dvendigt for at muligg\u00f8re genopretning i tilf\u00e6lde af nedbrud. Enhver operation skal, inden den giver kontrol til brugeren, f\u00f8rst registrere en begivenhed i WAL, s\u00e5 man efter et nedbrud har mulighed for at spille loggen tilbage og genoprette alle operationer, som brugeren har f\u00e5et et positivt svar p\u00e5, selvom disse operationer ikke er blevet reflekteret i det sidetilfredsstillende lager p\u00e5 disken (det blev tidligere n\u00e6vnt, at den faktiske skrivning til det sidetilfredsstillende lager sker i en proces kaldet \"checkpoint\" med en vis forsinkelse af separate tr\u00e5de).<\/p>\n<p>Posterne i WAL opdeles i logiske og fysiske. Logiske er selve n\u00f8glerne og v\u00e6rdierne. Fysiske afspejler \u00e6ndringerne i siderne i det sidetilfredsstillende lager. Hvis logiske poster kan v\u00e6re nyttige i andre tilf\u00e6lde, er fysiske poster kun n\u00f8dvendige for genopretning i tilf\u00e6lde af nedbrud og inkluderer kun poster fra det seneste succesfulde checkpoint. Her vil vi ikke g\u00e5 ind i detaljerne og forklare, hvorfor det fungerer p\u00e5 denne m\u00e5de, men de, der er interesseret, kan henvise til den allerede n\u00e6vnte artikel 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 under overfladen<\/a><\/noindex>.<\/p>\n<p>P\u00e5 en logisk post kan der ofte v\u00e6re flere fysiske poster. Det vil sige, at for eksempel en put-operation i cachen involverer flere sider i sidehukommelsen (siden med selve dataene, siderne med indeksene, siderne med free-lister). I nogle syntetiske tests har jeg oplevet, at de fysiske poster udgjorde op til 90% af st\u00f8rrelsen p\u00e5 WAL-filen. Disse poster er dog kun n\u00f8dvendige i meget kort tid (som standard er intervallet mellem checkpoints 3 minutter). Det ville v\u00e6re logisk at fjerne disse data, efter de har mistet deres aktualitet. Det er netop, hvad WAL compaction-mekanismen g\u00f8r; den fjerner de fysiske poster og komprimerer de resterende logiske poster ved hj\u00e6lp af zip, hvilket resulterer i en betydelig reduktion af filst\u00f8rrelsen (nogle gange med flere faktorer).<\/p>\n<p>Den fysiske WAL best\u00e5r af flere segmenter (standard 10) af fast st\u00f8rrelse (standard 64 MB), som overskrives cirkul\u00e6rt. N\u00e5r det nuv\u00e6rende segment er fyldt, tildeles det f\u00f8lgende segment det aktuelle, og det fyldte segment kopieres til arkivet i en separat tr\u00e5d. WAL-komprimering arbejder allerede med arkiverede segmenter. Desuden sporer den i en separat tr\u00e5d udf\u00f8relsen af checkpointet og begynder komprimeringen af de arkiverede segmenter, som ikke l\u00e6ngere er n\u00f8dvendige.<\/p>\n<p><img decoding=\"async\" alt=\"Datakomprimering i Apache Ignite. Erfaringer fra Sber.\" src=\"\/wp-content\/uploads\/2020\/05\/ca8690ba7a350df9530f2ccf01c90975.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>Indflydelse p\u00e5 ydeevnen<\/h4>\n<p>\nDa WAL-komprimering k\u00f8rer i en separat tr\u00e5d, b\u00f8r den ikke have nogen direkte indflydelse p\u00e5 de udf\u00f8rte operationer. Men den giver alligevel en ekstra baggrundsbelastning p\u00e5 CPU'en (komprimering) og disken (l\u00e6sning af hvert WAL-segment fra arkivet og skrivning af komprimerede segmenter), s\u00e5 hvis systemet arbejder p\u00e5 gr\u00e6nsen af kapaciteten, vil det ogs\u00e5 medf\u00f8re en nedgradering af ydeevnen.<\/p>\n<h4>Hvordan man aktiverer og konfigurerer<\/h4>\n<p>\nWAL-komprimering kan aktiveres ved hj\u00e6lp af egenskaben <code>WalCompactionEnabled<\/code> i <code>DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)<\/code>). Desuden kan graden af komprimering angives med metoden DataStorageConfiguration.setWalCompactionLevel(), hvis standardv\u00e6rdien (BEST_SPEED) ikke er tilfredsstillende.<\/p>\n<h3>WAL-side snapshot komprimering<\/h3>\n<p><\/p>\n<h4>Hvordan fungerer det<\/h4>\n<p>\nTidligere har vi allerede afklaret, at WAL-poster opdeles i logiske og fysiske. For hver \u00e6ndring af hver side i sidehukommelsen oprettes en fysisk WAL-post. Fysiske poster opdeles igen i to underkategorier: page snapshot record og delta record. Hver gang vi \u00e6ndrer noget p\u00e5 en side og \u00e6ndrer den fra en ren til en besmittet tilstand, gemmes en fuld kopi af denne side i WAL (page snapshot record \u2014 snapshots af siden). Selvom vi kun \u00e6ndrer \u00e9n byte, vil WAL gemme en post, der er lidt st\u00f8rre end st\u00f8rrelsen af siden. Hvis vi derimod \u00e6ndrer noget p\u00e5 en allerede besmittet side, dannes der en delta record i WAL, der kun reflekterer \u00e6ndringerne i forhold til den tidligere tilstand af siden, men ikke hele siden. Da nulstillingen af siden fra besmittet til ren udf\u00f8res under checkpoint-processen, vil n\u00e6sten alle fysiske poster straks efter begyndelsen af checkpointet kun best\u00e5 af snapshots af siderne (da alle sider umiddelbart efter begyndelsen af checkpointet er rene), og efterh\u00e5nden som vi n\u00e6rmer os det n\u00e6ste checkpoint, begynder andelen af delta records at stige og nulstilles igen ved begyndelsen af det n\u00e6ste checkpoint. M\u00e5linger fra nogle syntetiske tests har vist, at andelen af snapshots af sider i den samlede m\u00e6ngde af fysiske poster n\u00e5r op p\u00e5 90%.<\/p>\n<p>Id\u00e9en om WAL page snapshot-komprimering er at komprimere snapshots af siderne ved hj\u00e6lp af et allerede eksisterende v\u00e6rkt\u00f8j til kompression af sider (se disk page compression). I dette tilf\u00e6lde gemmes WAL-posterne sekventielt i append-only-tilstand, og der er ikke behov for at binde posterne til gr\u00e6nserne for filsystemets blokke. Derfor, i mods\u00e6tning til mekanismen for disk page compression, har vi slet ikke brug for sparse-filer, hvilket betyder, at denne mekanisme ogs\u00e5 vil fungere p\u00e5 ikke-Linux OS. Desuden er det ikke l\u00e6ngere vigtigt, hvor meget vi har kunnet komprimere siden. Selv hvis vi har frigivet 1 byte, er det allerede et positivt resultat, og vi kan gemme de komprimerede data i WAL, i mods\u00e6tning til disk page compression, hvor vi kun gemmer den komprimerede side, hvis vi har frigivet mere end 1 blok i filsystemet.<\/p>\n<p>Sider er let komprimerbare data, og deres andel af den samlede WAL-st\u00f8rrelse er meget h\u00f8j. P\u00e5 denne m\u00e5de kan vi opn\u00e5 en betydelig reduktion af filst\u00f8rrelsen uden at \u00e6ndre formatet p\u00e5 WAL-filen. Komprimering af de logiske indsigter ville derimod kr\u00e6ve en \u00e6ndring af formatet og tab af kompatibilitet, for eksempel for eksterne brugere, som kunne v\u00e6re interesseret i logiske optegnelser, samtidig med at det ikke ville medf\u00f8re en v\u00e6sentlig reduktion af filens volumen.<\/p>\n<p>Som med disk sidekomprimering kan der til WAL side snapshot-komprimering benyttes komprimeringsalgoritmerne ZSTD, LZ4, Snappy samt tilstanden SKIP_GARBAGE.<\/p>\n<h4>Indflydelse p\u00e5 ydeevnen<\/h4>\n<p>\nSom man kan se, p\u00e5virker direkte aktivering af WAL side snapshot-komprimering kun de str\u00f8mme, der skriver data til sidememorien, det vil sige de str\u00f8mme, der \u00e6ndrer data i cachen. L\u00e6sning fra WAL fysiske optegnelser sker kun \u00e9n gang, n\u00e5r noden startes efter et nedbrud (og kun i tilf\u00e6lde af nedbrud under checkpoint-processen).<\/p>\n<p>Dette p\u00e5virker de str\u00f8mme, der \u00e6ndrer data, p\u00e5 f\u00f8lgende m\u00e5de: Vi f\u00e5r en negativ effekt (CPU) p\u00e5 grund af behovet for konstant at komprimere siden, f\u00f8r den skrives til disken, og en positiv effekt (disk IO) p\u00e5 grund af reduktionen af \u200b\u200bde data, der skrives. Derfor er det simpelt; hvis systemets ydeevne er begr\u00e6nset af CPU'en, f\u00e5r vi en lille degradation, hvis det er diskinput\/output \u2013 f\u00e5r vi en gevinst.<\/p>\n<p>Indirekte p\u00e5virker reduktionen af \u200b\u200bWAL-st\u00f8rrelsen ogs\u00e5 (positivt) de str\u00f8mme, der arkiverer WAL-segmenter, og de str\u00f8mme, der arbejder med WAL-komprimering.<\/p>\n<p>Virkelige ydeevnetests i vores milj\u00f8 med syntetiske data har vist en lille stigning (gennemstr\u00f8mningen er steget med 10%-15%, og latensen er faldet med 10%-15%).<\/p>\n<h4>Hvordan man aktiverer og konfigurerer<\/h4>\n<p>\nMinimumsversion af Apache Ignite: 2.8. Aktivering og konfiguration udf\u00f8res som f\u00f8lger:<\/p>\n<ul>\n<li>Modulet ignite-compression skal v\u00e6re i class-path. Som standard findes det i distribueringspakken af Apache Ignite i biblioteket libs\/optional og inkluderes ikke i class-path. Du kan blot flytte biblioteket op \u00e9t niveau i libs, s\u00e5 det automatisk inkluderes, n\u00e5r du starter via ignite.sh.<\/li>\n<li>Persistence skal v\u00e6re aktiveret (aktiveres via <code>DataRegionConfiguration.setPersistenceEnabled(true)<\/code>).<\/li>\n<li>Kompresseringsmetoden skal angives via metoden <code>DataStorageConfiguration.setWalPageCompression()<\/code>, som standard er komprimering deaktiveret (tilstand DISABLED).<\/li>\n<li>Valgfrit kan komprimeringsgraden angives via metoden <code>DataStorageConfiguration.setWalPageCompression()<\/code>, se de tilladte v\u00e6rdier for hver tilstand i javadoc til metoden.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Konklusion<\/h3>\n<p>\nDe diskutere mekanismer til datakomprimering i Apache Ignite kan bruges uafh\u00e6ngigt af hinanden, men enhver kombination er ogs\u00e5 acceptabel. Forst\u00e5elsen af deres arbejdsprincipper vil g\u00f8re det muligt at afg\u00f8re, hvor godt de passer til dine opgaver i dit milj\u00f8, og hvad du eventuelt m\u00e5 ofre ved deres brug. Disk sidekomprimering er beregnet til at komprimere det prim\u00e6re lager og kan give en gennemsnitlig kompressionsgrad. WAL side snapshot komprimering vil give en gennemsnitlig kompressionsgrad for allerede eksisterende WAL-filer, og vil sandsynligvis endda \u00f8ge ydeevnen. WAL komprimering vil ikke have en positiv effekt p\u00e5 ydeevnen, men vil maksimalt reducere st\u00f8rrelsen p\u00e5 WAL-filerne ved at fjerne fysiske poster.<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.3 - 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\/da\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47 Datakomprimering i Apache Ignite. Erfaring fra Sber | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/81936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=81936"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/81936\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/81937"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=81936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=81936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=81936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}