{"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\/nl\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","title":{"rendered":"Gegevenscompressie in Apache Ignite. Ervaring van Sberbank","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Gegevenscompressie in Apache Ignite. Ervaring van Sberbank\" src=\"\/wp-content\/uploads\/2020\/05\/0e26c686b1f29e88e6be4b8df81ab668.jpg\" style=\"display:block;margin: 0 auto;\" \/>Bij het werken met grote hoeveelheden gegevens kan het probleem van onvoldoende schijfruimte soms urgent worden. Een van de oplossingen voor dit probleem is compressie, waarmee u op dezelfde hardware de opslagcapaciteit kunt vergroten. In dit artikel zullen we bekijken hoe gegevenscompressie in Apache Ignite werkt. We beschrijven alleen de compressiemethoden die binnen het product zijn ge\u00efmplementeerd. Andere methoden voor gegevenscompressie (over het netwerk, in het geheugen), zowel ge\u00efmplementeerd als niet, vallen buiten de scope.<\/p>\n<p>Dus, wanneer de persistentiemodus is ingeschakeld, begint Ignite, als gevolg van gegevenswijzigingen in de caches, met schrijven naar de schijf:<\/p>\n<ol>\n<li>De inhoud van de caches<\/li>\n<li>Het Write Ahead Log (WAL)<\/li>\n<\/ol>\n<p>\nVoor de compressie van WAL bestaat al geruime tijd een mechanisme genaamd WAL-compactie. In het onlangs uitgebrachte Apache Ignite 2.8 zijn er nog twee mechanismen toegevoegd die het mogelijk maken om gegevens op de schijf te comprimeren: disk page compression voor het comprimeren van de inhoud van caches en WAL page snapshot compression voor het comprimeren van bepaalde WAL-invoer. Hieronder meer over deze drie mechanismen.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Disk page compression<\/h3>\n<p><\/p>\n<h4>Hoe het werkt<\/h4>\n<p>\nLaten we kort kijken naar hoe Ignite gegevens opslaat. Voor opslag wordt paginageheugen gebruikt. De paginagrootte wordt ingesteld bij de opstart van de knooppunt en kan op een later stadium niet meer worden gewijzigd. Bovendien moet de paginagrootte een macht van twee zijn en een veelvoud van de bestandssysteemblokkengrootte. Bladzijdes worden indien nodig vanuit de schijf naar RAM geladen, de hoeveelheid gegevens op de schijf kan de toegekende RAM-overstijgen. Bij onvoldoende RAM-ruimte voor het laden van een pagina vanaf de schijf zullen oude, niet meer gebruikte pagina's uit de RAM worden verdrongen.<\/p>\n<p>Op de schijf worden gegevens als volgt opgeslagen: voor elke partitie van elke cachegroep wordt een apart bestand aangemaakt, in dit bestand volgen pagina's in volgorde van stijgende index. De volledige identificatie van een pagina bevat het identificatienummer van de cachegroep, het partitie-nummer en de index van de pagina in het bestand. Zo kunnen we aan de hand van de volledige identificatie van de pagina het bestand en de offset in het bestand voor elke pagina eenduidig bepalen. Meer details over de opbouw van paginageheugen kunnen worden gelezen in een artikel op de 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 achter de schermen<\/a><\/noindex>.<\/p>\n<p>Het mechanisme voor schijfpagina-compressie, zoals de naam al aangeeft, werkt op paginaniveau. Wanneer dit mechanisme is ingeschakeld, worden de gegevens in RAM zoals ze zijn verwerkt, zonder enige compressie, maar op het moment dat pagina's van RAM naar schijf worden opgeslagen, worden ze gecomprimeerd.<\/p>\n<p>Maar het comprimeren van elke pagina afzonderlijk is nog niet de oplossing voor het probleem; we moeten de uiteindelijke bestandsgrootte van de gegevens verkleinen. Als de grootte van een pagina niet meer vastligt, kunnen we de pagina's niet een voor een in een bestand schrijven, omdat dit een reeks problemen kan veroorzaken:<\/p>\n<ul>\n<li>We zullen met een paginavoorziening niet het offset kunnen berekenen waarop deze zich in het bestand bevindt.<\/li>\n<li>Het is onduidelijk wat te doen met pagina's die zich niet aan het einde van het bestand bevinden en hun grootte wijzigen. Als de grootte van een pagina afneemt, gaat de ruimte die deze vrijmaakt verloren. Als de grootte van een pagina toeneemt, moet er al een nieuwe plaats in het bestand voor worden gezocht.<\/li>\n<li>Als een pagina verschuift op een aantal bytes dat geen veelvoud is van de grootte van het bestandssysteemblock, dan is het mogelijk dat voor het lezen of schrijven ervan, meer dan \u00e9\u00e9n block van het bestandssysteem moet worden geraakt, wat kan leiden tot prestatieverlies.<\/li>\n<\/ul>\n<p>\nOm deze problemen op zijn eigen niveau niet zelf op te lossen, gebruikt disk page compression in Apache Ignite een bestandssysteemmechanisme dat sparse bestanden wordt genoemd. Een sparse (sparsity) bestand is een bestand waarin sommige regio's, gevuld met nullen, als 'gaten' kunnen worden gemarkeerd. In dit geval zullen er geen bestandssysteemblokken worden toegewezen voor het opslaan van deze gaten, waardoor er ruimte op de schijf wordt bespaard.<\/p>\n<p>Logisch is dat om een bestandssysteemblock vrij te maken, de grootte van het gat groter of gelijk moet zijn aan de grootte van het bestandssysteemblock, wat een zus\u00e4tzliche beperking oplegt aan de grootte van pagina's in Apache Ignite: om enige compressie-effect te hebben, moet de grootte van een pagina strikt groter zijn dan de grootte van het bestandssysteemblock. Als de grootte van een pagina gelijk is aan de grootte van het block, kunnen we nooit een block vrijmaken, want om een enkel block vrij te maken, moet de gecomprimeerde pagina 0 bytes in beslag nemen. Als de grootte van een pagina gelijk is aan de grootte van 2 of 4 blocks, kunnen we minimaal \u00e9\u00e9n block vrijmaken als onze pagina minimaal met 50% of 75% wordt gecomprimeerd.<\/p>\n<p>Dus, de uiteindelijke beschrijving van de werking van het mechanisme: Bij het opslaan van een pagina op de schijf, wordt geprobeerd de pagina te comprimeren. Als de grootte van de gecomprimeerde pagina het mogelijk maakt om een of meer blokken van het bestandssysteem vrij te maken, wordt de pagina gecomprimeerd opgeslagen op de plaats van de vrijgemaakte blokken, waarbij er een \"gat\" wordt gemaakt (een systeemoproep wordt uitgevoerd) <code>fallocate()<\/code> met de vlag \"punch hole\"). Als de grootte van de gecomprimeerde pagina niet genoeg is om blokken vrij te maken, wordt de pagina opgeslagen zoals deze is, in ongecomprimeerde vorm. Alle offset-waarden van pagina's worden net als zonder compressie berekend door de paginindex met de paginagrootte te vermenigvuldigen. Er is geen relocatie van pagina's vereist. De offset-waarden van pagina's komen, net als zonder compressie, op de grenzen van blokken in het bestandssysteem.<\/p>\n<p><img decoding=\"async\" alt=\"Gegevenscompressie in Apache Ignite. Ervaring van Sberbank\" src=\"\/wp-content\/uploads\/2020\/05\/6a6c6ad83d3b8591f76b9343ff067746.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nIn de huidige implementatie kan Ignite alleen werken met sparse bestanden onder Linux, waardoor schijfpagina-compressie alleen kan worden ingeschakeld bij gebruik van Ignite op dit besturingssysteem.<\/p>\n<p>Compressie-algoritmen die kunnen worden gebruikt voor schijfpagina-compressie zijn: ZSTD, LZ4, Snappy. Daarnaast is er een werkmodus (SKIP_GARBAGE) waarbij alleen ongebruikt ruimte op de pagina wordt verwijderd zonder compressie toe te passen op de resterende gegevens, wat de belasting op de CPU vermindert in vergelijking met de eerder genoemde algoritmen.<\/p>\n<h4>Invloed op prestaties <\/h4>\n<p>\nHelaas heb ik geen daadwerkelijke prestatiemeting op de echte systemen uitgevoerd, omdat dit mechanisme niet in productie zal worden gebruikt, maar we kunnen theoretisch nadenken over waar we zullen verliezen en waar we zullen winnen.<\/p>\n<p>Hiervoor moeten we ons herinneren hoe het lezen en schrijven van pagina's wordt uitgevoerd bij toegang tot hen:<\/p>\n<ul>\n<li>Bij het uitvoeren van een leesbewerking wordt eerst gezocht in het RAM; als de zoektocht onbevredigend is, wordt de pagina in RAM van de schijf geladen door dezelfde thread die de leesbewerking uitvoert.<\/li>\n<li>Bij het uitvoeren van een schrijfbewerking wordt de pagina in RAM gemarkeerd als vervuild, terwijl de fysieke opslag van de pagina op de schijf niet onmiddellijk wordt uitgevoerd door de thread die de schrijfbewerking uitvoert. Alle vervuilde pagina's worden later in het proces van checkpointing door aparte threads naar de schijf opgeslagen.<\/li>\n<\/ul>\n<p>\nDus, de invloed op leesbewerkingen:<\/p>\n<ul>\n<li>Positief (disk IO), dankzij de vermindering van het aantal gelezen blokken van het bestandssysteem.<\/li>\n<li>Negatief (CPU), door de extra belasting die nodig is voor het besturingssysteem om met sparse bestanden te werken. Het is ook mogelijk dat hier impliciet extra IO-bewerkingen optreden om een complexere structuur van sparse bestanden op te slaan (ik ben helaas niet bekend met alle details van het werken met sparse bestanden).<\/li>\n<li>Negatief (CPU), door de noodzaak om pagina's te decomprimeren.<\/li>\n<li>Er zijn geen invloeden op schrijfoperaties.<\/li>\n<li>Invloed op het checkpointproces (hier is alles vergelijkbaar met leesbewerkingen):<\/li>\n<li>Positief (disk IO), dankzij de vermindering van het aantal geschreven blokken van het bestanden systeem.<\/li>\n<li>Negatief (CPU, mogelijk disk IO), door het werken met sparse bestanden.<\/li>\n<li>Negatief (CPU), door de noodzaak om pagina's te comprimeren.<\/li>\n<\/ul>\n<p>\nWelke schaal zal zwaarder wegen? Dit hangt sterk af van de omgeving, maar ik neig ernaar te denken dat disk page compressie waarschijnlijk zal leiden tot een degradatie van de prestaties op de meeste systemen. Vooral omdat tests op andere DBMS'en die een vergelijkbare aanpak met sparse bestanden gebruiken, een daling van de prestaties laten zien bij ingeschakelde compressie.<\/p>\n<h4>Hoe in te schakelen en te configureren<\/h4>\n<p>\nZoals eerder gezegd, de minimale versie van Apache Ignite die disk page compressie ondersteunt: 2.8 en wordt alleen ondersteund door het besturingssysteem Linux. Inschakelen en configureren gebeurt als volgt:<\/p>\n<ul>\n<li>In de class-path moet de module ignite-compression zijn. Standaard bevindt deze zich in de distributie van Apache Ignite in de directory libs\/optional en wordt niet opgenomen in de class-path. Je kunt de directory eenvoudig \u00e9\u00e9n niveau omhoog verplaatsen in libs en dan zal hij automatisch worden opgenomen bij het starten met ignite.sh.<\/li>\n<li>Persistence moet ingeschakeld zijn (dit kan worden ingeschakeld via <code>DataRegionConfiguration.setPersistenceEnabled(true))<\/code>.<\/li>\n<li>De pagina-grootte moet groter zijn dan de block-grootte van het bestanden systeem (dit kan worden ingesteld met <code>DataStorageConfiguration.setPageSize()<\/code> ).<\/li>\n<li>Voor elke cache waarvan de gegevens gecomprimeerd moeten worden, moet je in de configuratie de compressiemethode en (optioneel) het compressieniveau instellen (methodes <code>CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()<\/code>).<\/li>\n<\/ul>\n<p><\/p>\n<h3>WAL compressie<\/h3>\n<p><\/p>\n<h4>Hoe het werkt<\/h4>\n<p>\nWat is WAL en waarom is het nodig? Heel kort gezegd: het is een logboek waarin alle gebeurtenissen worden vastgelegd die de paginadata uiteindelijk veranderen. Het is voornamelijk nodig voor het herstel in geval van een storing. Elke bewerking moet eerst een gebeurtenis in de WAL vastleggen voordat de controle aan de gebruiker wordt overgedragen, zodat we bij een storing de log kunnen afspelen en alle bewerkingen kunnen herstellen waarvoor de gebruiker een succesvolle respons heeft ontvangen, zelfs als deze bewerkingen niet tijdig zijn vastgelegd in de paginadata op disk (zoals eerder vermeld, wordt de feitelijke vastlegging in de paginadata uitgevoerd in een proces dat \u2018checkpoint\u2019 wordt genoemd, met enige vertraging door afzonderlijke threads).<\/p>\n<p>In de WAL worden de vastleggingen onderverdeeld in logische en fysieke. Logische vastlegggingen zijn de werkelijke sleutels en waarden. Fysieke vastlegggingen weerspiegelen de wijzigingen van pagina's in de paginadata. Terwijl logische vastlegggingen ook voor andere doeleinden nuttig kunnen zijn, zijn fysieke vastlegggingen alleen nodig voor herstel in geval van een storing en zijn ze alleen vereist vanaf het laatste succesvolle checkpoint. We zullen hier niet in detail treden om uit te leggen waarom dit zo werkt, maar belangstellenden kunnen verwijzen naar het reeds genoemde artikel op de 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 achter de schermen<\/a><\/noindex>.<\/p>\n<p>Voor \u00e9\u00e9n logische opname zijn er vaak meerdere fysieke opnames. Dit betekent bijvoorbeeld dat \u00e9\u00e9n put-operatie in de cache meerdere pagina's in het paginageheugen be\u00efnvloedt (de pagina met de eigenlijke gegevens, pagina's met indexen, pagina's met free-lists). Bij sommige synthetische tests ontdekte ik dat fysieke opnames tot 90% van het volume van het WAL-bestand in beslag namen. Deze gegevens zijn echter maar een korte tijd relevant (de standaardinterval tussen checkpoints is 3 minuten). Het zou logisch zijn om deze gegevens te verwijderen zodra ze niet meer actueel zijn. Dit is precies wat het mechanisme voor WAL-compactie doet: het verwijdert fysieke opnames en comprimeert de overgebleven logische opnames met behulp van zip, waardoor de bestandsgrootte aanzienlijk wordt verminderd (soms met tientallen keren).<\/p>\n<p>Fysiek bestaat WAL uit verschillende segmenten (standaard 10) van vaste grootte (standaard 64 MB), die in een cirkel worden herschreven. Zodra het huidige segment vol is, wordt het volgende segment toegewezen en het ingevulde segment wordt in een aparte stroom naar de archief gekopieerd. WAL-compactie werkt al met archiefsegmenten. Ook in een aparte stroom houdt het de voortgang van de checkpoint in de gaten en begint het met de compressie van archiefsegmenten waarvoor fysieke records al niet meer nodig zijn.<\/p>\n<p><img decoding=\"async\" alt=\"Gegevenscompressie in Apache Ignite. Ervaring van Sberbank\" src=\"\/wp-content\/uploads\/2020\/05\/ca8690ba7a350df9530f2ccf01c90975.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>Invloed op prestaties<\/h4>\n<p>\nAangezien WAL-compactie in een aparte stroom werkt, zou er geen directe invloed op de uit te voeren operaties moeten zijn. Maar het zorgt wel voor een extra achtergrondbelasting op de CPU (compressie) en de schijf (lezen van elk WAL-segment uit het archief en schrijven van de gecomprimeerde segmenten), dus als het systeem aan de grenzen van zijn mogelijkheden werkt, zal het ook leiden tot prestatieverlies.<\/p>\n<h4>Hoe in te schakelen en te configureren<\/h4>\n<p>\nWAL-compactie kan worden ingeschakeld met behulp van de eigenschap <code>WalCompactionEnabled<\/code> in <code>DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)<\/code>). Ook kan met de methode DataStorageConfiguration.setWalCompactionLevel() het compressieniveau worden ingesteld, als de standaardwaarde (BEST_SPEED) niet wenselijk is.<\/p>\n<h3>WAL-pagina snapshot compressie<\/h3>\n<p><\/p>\n<h4>Hoe het werkt<\/h4>\n<p>\nEerder hebben we vastgesteld dat WAL-gegevens zijn onderverdeeld in logische en fysieke gegevens. Voor elke wijziging van elke pagina in het geheugen wordt er een fysieke WAL-registratie gemaakt. Fysieke registraties zijn ook weer onderverdeeld in twee subtypen: page snapshot record en delta record. Elke keer dat we iets op een pagina wijzigen en deze van een schone naar een vuile staat overbrengen, wordt er een volledige kopie van die pagina opgeslagen in de WAL (page snapshot record - een snapshot van de pagina). Zelfs als we slechts \u00e9\u00e9n byte wijzigen, wordt er in de WAL een registratie opgeslagen die iets groter is dan de grootte van de pagina. Wanneer we echter iets veranderen op een al vuile pagina, wordt er in de WAL een delta record aangemaakt waarin alleen de wijzigingen ten opzichte van de vorige staat van de pagina zijn vastgelegd, maar niet de gehele pagina. Aangezien de reset van de pagina's van vuil naar schoon plaatsvindt tijdens het checkpoint-proces, zullen vrijwel alle fysieke registraties direct na het begin van het checkpoint uit alleen snapshots van pagina's bestaan (aangezien alle pagina's direct na het begin van het checkpoint schoon zijn), en naarmate we dichter bij het volgende checkpoint komen, begint het aandeel delta records toe te nemen en wordt dit opnieuw gereset aan het begin van het volgende checkpoint. Metingen in sommige synthetische tests hebben aangetoond dat het aandeel snapshots van pagina's in het totale volume van fysieke registraties tot 90% kan oplopen.<\/p>\n<p>Het idee van WAL page snapshot compressie is om snapshots van pagina's te comprimeren met behulp van een reeds bestaand hulpmiddel voor pagina-compressie (zie disk page compression). De WAL-registraties worden hierbij opeenvolgend in een append-only modus opgeslagen en er is geen noodzaak om registraties aan de grenzen van de bestandssysteemblokken te koppelen, zodat we, in tegenstelling tot het mechanisme voor disk page compressie, hier absoluut geen sparse bestanden nodig hebben; daarom zal dit mechanisme ook niet alleen op Linux-OS werken. Bovendien maakt het niet meer uit hoe sterk we de pagina hebben kunnen comprimeren. Zelfs als we 1 byte hebben vrijgemaakt, is dat al een positief resultaat en kunnen we de samengeperste gegevens in de WAL opslaan, in tegenstelling tot disk page compressie, waar we alleen een samengeperste pagina opslaan als we meer dan 1 blok van het bestandssysteem hebben vrijgemaakt.<\/p>\n<p>Pagina's zijn goed comprimeerbare gegevens, en hun aandeel in het totale volume van de WAL is zeer hoog, waardoor we, zonder het formaat van het WAL-bestand te wijzigen, een aanzienlijke vermindering van de grootte kunnen bereiken. Compressie van logische records zou daarentegen een wijziging van het formaat vereisen, wat compatibiliteitsverlies met zich meebrengt, bijvoorbeeld voor externe consumenten die mogelijk ge\u00efnteresseerd zijn in logische records, zonder dat dit een significante vermindering van het bestandsgrootte oplevert.<\/p>\n<p>Net als voor disk page compressie kunnen voor WAL page snapshot compressie compressie-algoritmen zoals ZSTD, LZ4, Snappy en de SKIP_GARBAGE-modus worden gebruikt.<\/p>\n<h4>Invloed op prestaties<\/h4>\n<p>\nZoals gemakkelijk te merken is, heeft de directe inschakeling van WAL page snapshot compressie alleen invloed op de stromen die gegevens in de pagina-geheugen schrijven, dat wil zeggen op de stromen die gegevens in de caches wijzigen. Lezen uit de WAL van fysieke records gebeurt slechts \u00e9\u00e9n keer, op het moment dat de node weer opstart na een ongeval (en alleen in het geval van een ongeval tijdens een checkpoint).<\/p>\n<p>Dit heeft de volgende invloed op de gegevenswijzigende stromen: we krijgen een negatief effect (CPU) door de noodzaak om telkens de pagina te comprimeren voordat deze op schijf wordt geschreven en een positief effect (disk IO) door de vermindering van het aantal geschreven gegevens. Het is dus eenvoudig: als de systeemperformance afhankelijk is van de CPU, hebben we een kleine degradatie, als het van de schijfinvoer\/-uitvoer afhankelijk is, hebben we een verbetering.<\/p>\n<p>Indirect leidt de vermindering van de grootte van de WAL ook tot een positieve invloed op de stromen die WAL-segmenten naar archief verplaatsen en op de WAL-compaction-stromen.<\/p>\n<p>Echte prestatiemetingen in onze omgeving met synthetische gegevens toonden een lichte verbetering aan (de throughput nam met 10%-15% toe, de latentie nam met 10%-15% af).<\/p>\n<h4>Hoe in te schakelen en te configureren<\/h4>\n<p>\nMinimale versie van Apache Ignite: 2.8. Inschakelen en configureren gebeurt als volgt:<\/p>\n<ul>\n<li>In de class-path moet de module ignite-compression zijn. Standaard bevindt deze zich in de distributie van Apache Ignite in de directory libs\/optional en wordt niet opgenomen in de class-path. Je kunt de directory eenvoudig \u00e9\u00e9n niveau omhoog verplaatsen in libs en dan zal hij automatisch worden opgenomen bij het starten met ignite.sh.<\/li>\n<li>Persistence moet ingeschakeld zijn (dit kan worden ingeschakeld via <code>DataRegionConfiguration.setPersistenceEnabled(true)<\/code>).<\/li>\n<li>Er moet een compressiemodus worden ingesteld met behulp van de methode <code>DataStorageConfiguration.setWalPageCompression()<\/code>, standaard is compressie uitgeschakeld (modus DISABLED).<\/li>\n<li>Optioneel kan de compressiegraad worden ingesteld met behulp van de methode <code>DataStorageConfiguration.setWalPageCompression()<\/code>, de toegestane waarden voor elk van de modi vind je in de javadoc van de methode.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Conclusie<\/h3>\n<p>\nDe besproken compressiemechanismen in Apache Ignite kunnen onafhankelijk van elkaar worden gebruikt, maar ook in combinatie. Het begrijpen van de principes van hun werking stelt u in staat om te bepalen hoe goed ze passen bij uw taken in uw omgeving en waar u op moet besparen bij hun gebruik. Disk page compressie is bedoeld voor de compressie van de primaire opslag en kan een gemiddelde compressiegraad bieden. WAL page snapshot compressie biedt een gemiddelde compressiegraad voor WAL-bestanden en kan bovendien de prestaties mogelijk verbeteren. WAL-compactie heeft geen positieve invloed op de prestaties, maar zal de grootte van WAL-bestanden maximaliseren door fysieke records te verwijderen.<br \/>\n<br \/>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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\udd47Gegevenscompressie in Apache Ignite. Ervaringen van Sber | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/81936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=81936"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/81936\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/81937"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=81936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=81936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=81936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}