Kur punoni me sasi të mëdha të të dhënave, ndonjëherë mund të lindë ndjeshëm problemi i mungesës së hapësirës në disqe. Një nga mënyrat për ta zgjidhur këtë problem është kompresimi, i cili bëhet i mundur që, në të njëjtin ekip, të lejohet rritja e kapacitetit të ruajtjes. Në këtë artikull do të shqyrtojmë se si funksionon kompresimi i të dhënave në Apache Ignite. Artikulli do të përshkruajë vetëm metodat e implementuara brenda produktit për kompresimin në disk. Mënyra të tjera të kompresimit të të dhënave (në rrjet, në memorje) si të implementuara, ashtu dhe jo, do të mbeten jashtë kësaj përmbledhjeje.
Pra, kur është aktivizuar modaliteti i përhershmërisë, si rezultat i ndryshimit të të dhënave në cache, Ignite fillon të shkruajë në disk:
- PĂ«rmbajtja e caches
- Dayelli i shkruar përpara (Write Ahead Log, më pas vetëm WAL)
Për kompresimin e WAL, ka një mekanizëm që është krijuar për një kohë të gjatë dhe quhet kompresimi i WAL. Në Apache Ignite 2.8 që sapo doli, u prezantuan edhe dy mekanizma të tjerë që lejojnë kompresimin e të dhënave në disk, ky është kompresimi i faqes së diskut për kompresimin e përmbajtjes së caches dhe kompresimi i snapshot-it të faqes së WAL për kompresimin e disa regjistrimeve të WAL. Më shumë rreth këtyre tre mekanizmave më poshtë.
Kompresimi i faqes së diskut
Si funksionon kjo
Për të filluar, le të ndalemi shumë shkurt te mënyra se si Ignite ruan të dhënat. Për ruajtje përdoret memorie faqore. Madhësia e faqes përcaktohet në fillim të nodit dhe nuk mund të ndryshohet më vonë, gjithashtu madhësia e faqes duhet të jetë një fuqi e dyjes dhe e shumëfishueshme me madhësinë e bllokut të sistemit të skedarit. Faqet ngarkohen në RAM nga disku sipas nevojës, madhësia e të dhënave në disk mund të tejkalojë kapacitetin e RAM të alokuar. Në rast të mungesës së hapësirës në RAM për ngarkimin e një faqe nga disku, faqet e vjetra, të cilat nuk përdoren më, do të zëvendësohen nga RAM.
Në disk, të dhënat ruhen në këtë formë: për çdo parti të çdo grupi cache krijohet një skedar i veçantë, në këtë skedar, në rendin në rritje të indeksit, faqet vendosen njëra pas tjetrës. Identifikuesi i plotë i faqes përfshin identifikuesin e grupit të caches, numrin e partisë dhe indeksin e faqes në skedar. Kështu, me identifikuesin e plotë të faqes mund të përcaktojmë qartë skedarin dhe offset-in në skedar për secilën faqe. Më shumë rreth organizimit të memories faqore mund të lexoni në artikullin në Apache Ignite Wiki: .
Mekanizmi i kompresimit të faqeve disk, siç mund të kuptohet nga emri, punon në nivelin e faqeve. Kur aktivizohet ky mekanizëm, puna me të dhënat në RAM bëhet ashtu siç është, pa ndonjë kompresim, por në momentin e ruajtjes së faqeve nga RAM në disk, ato kompresohen.
Por, kompresimi i çdo faqeje në mënyrë të veçantë nuk është zgjidhja e problemit; na nevojitet një mënyrë për të reduktuar përmasat e skedarëve përfundimtarë me të dhëna. Nëse përmasat e faqeve nuk mbeten fikse, ne nuk mund të shkruajmë faqet në skedar njëra pas tjetrës, pasi kjo mund të shkaktojë një seri problemesh:
- Ne nuk do të jemi në gjendje të llogarisim offsetin se ku ndodhet një faqe në skedar duke përdorur indeksin e faqeve.
- Nuk është e qartë se çfarë të bëjmë me faqet që ndodhen jo në fund të skedarit dhe ndryshojnë përmasat e tyre. Nëse përmasat e faqes zvogëlohen, vendi që ajo lirohet humbet. Nëse përmasat e faqes rriten, për të duhet të kërkojmë një vend të ri në skedar.
- Nëse faqja lëviz në një numër bajtësh që nuk është shumëfish i përmasës së bllokut të skedarit, për leximin ose shkruajtjen e saj do të kërkohet të preket një bllok më shumë i skedarit, gjë që mund të çojë në shkallëzimin e performancës.
Për të mos i zgjidhur këto probleme në nivelin e tij, kompresimi i faqeve disk në Apache Ignite përdor një mekanizëm të sistemit të skedarëve të quajtur skedarë sparse. Skedari sparse është një skedar, në të cilin disa regjione të mbushura me zero mund të shënohen si "vrima". Kështu, blloket e sistemit të skedarëve për ruajtjen e këtyre vrimave nuk do të akordohen, duke rezultuar në kursim të hapësirës në disk.
ĂshtĂ« logjike qĂ« pĂ«r tĂ« liruar njĂ« bllok tĂ« sistemit tĂ« skedarĂ«ve, pĂ«rmasa e vrimĂ«s duhet tĂ« jetĂ« mĂ« e madhe ose e barabartĂ« me bllokun e sistemit tĂ« skedarĂ«ve, gjĂ« qĂ« imponon njĂ« kufizim shtesĂ« nĂ« pĂ«rmasĂ«n e faqeve nĂ« Apache Ignite: pĂ«r kompresimi qĂ« tĂ« ketĂ« ndonjĂ« efekt, Ă«shtĂ« e nevojshme qĂ« pĂ«rmasa e faqeve tĂ« jetĂ« rreptĂ«sisht mĂ« e madhe se pĂ«rmasa e bllokut tĂ« sistemit tĂ« skedarĂ«ve. NĂ«se pĂ«rmasa e faqeve Ă«shtĂ« e barabartĂ« me pĂ«rmasĂ«n e bllokut, ne kurrĂ« nuk do tĂ« jemi nĂ« gjendje tĂ« lirojmĂ« asnjĂ« bllok, pasi pĂ«r tĂ« liruar njĂ« bllok tĂ« vetĂ«m, pĂ«rfaqĂ«simi i kompresuar duhet tĂ« zĂ«rĂ« 0 bajtĂ«. NĂ«se pĂ«rmasa e faqeve Ă«shtĂ« e barabartĂ« me pĂ«rmasĂ«n e 2 ose 4 blloqeve, ne do tĂ« jemi nĂ« gjendje tĂ« lironim tĂ« paktĂ«n njĂ« bllok nĂ«se faqja jonĂ« kompresohet tĂ« paktĂ«n deri nĂ« 50% ose 75% pĂ«rkatĂ«sisht.
Pra kësaj, përmbledhja përfundimtare e funksionit të mekanizmit është: Kur regjistrohet një faqe në disk, bëhet një përpjekje për ta kompresuar atë. Nëse madhësia e faqes së kompresuar lejon që të çlirohen një apo më shumë bllokë të sistemit të skedarëve, faqja shkruhet në formë të kompresuar dhe në vendin e bllokëve të çliruar bëhet një "gjurmë" (kryhet një thirrje sistemike) fallocate() me flamurin "punch hole". Nëse madhësia e faqes së kompresuar nuk lejon çlirimin e bllokëve, faqja ruhet siç është, në formë të pakompresuar. Të gjitha offsetet e faqeve llogariten ashtu siç janë pa kompresim, duke shumëzuar indeksin e faqeve me madhësinë e faqes. Nuk kërkohet asnjë rilokim i faqeve nga ana e përdoruesit. Offsetet e faqeve, ashtu si pa kompresim, kalojnë në kufijtë e bllokëve të sistemit të skedarëve.
Në implementimin aktual, Ignite mund të punojë me skedarët sparse vetëm nën OS Linux, kështu që kompresimi i faqeve të diskut mund të aktivizohet vetëm kur përdoret Ignite në këtë sistem operativ.
Algoritmet e kompresimit që mund të përdoren për kompresimin e faqeve të diskut: ZSTD, LZ4, Snappy. Përveç kësaj, ekziston një regjimi operativ (SKIP_GARBAGE), ku thjesht hidhet hapësira e pavendosur brenda faqes pa aplikuar kompresim mbi të dhënat e mbetura, që lejon të ulet ngarkesa mbi CPU në krahasim me algoritmet e përmendura më parë.
Ndikimi në performancë
Fatkeqësisht, nuk kam kryer matje të faktike të performancës në stendat reale, pasi të përdorim këtë mekanizëm në prodhim nuk është planifikuar, por mund të spekulojmë teoretikisht se ku do të humbasim dhe ku do të fitojmë.
Për këtë, na nevojitet të kujtojmë se si kryhet leximi dhe regjistrimi i faqeve gjatë qasjes ndaj tyre:
- Gjatë kryerjes së operacionit të leximit, së pari bëhet kërkimi i tij në RAM; nëse kërkimi përfundon dështueshëm, faqeja ngarkohet në RAM nga disku nga po ai rrjedh që kryen leximin.
- Gjatë kryerjes së operacionit të regjistrimit, faqja në RAM shënohet si "e ndotur"; megjithatë, ruajtja fizike e faqes në disk nuk ndodh menjëherë në rrjedhën që kryen regjistrimin. Të gjitha faqet e ndotura ruhet në disk më vonë gjatë procesit të kontrollit nga rrjedha të veçanta.
Pra, ndikimi në operacionet e leximit:
- Pozitiv (disk IO), për shkak të reduktimit të numrit të bllokëve të lexuar të sistemit të skedarëve.
- Negativ (CPU), për shkak të ngarkesës shtesë të nevojshme për sistemin operativ për të punuar me skedarët sparse. Gjithashtu, është e mundur që këtu të shfaqen në mënyrë implikative operacione të tjera IO për ruajtjen e strukturës më të komplikuar të skedarëve sparse (fatkeqësisht, nuk jam i njohur me të gjitha detajet e funksionimit të skedarëve sparse).
- Negativ (CPU), për shkak të nevojës për dekompresimin e faqeve.
- Nuk ka ndikim në operacionet e shkrimit.
- Ndikimi në procesin e kontrollit (këtu gjithçka është e ngjashme me operacionet e leximit):
- Pozitiv (disk IO), për shkak të zvogëlimit të numrit të blloqeve të shkruara të sistemit të skedarëve.
- Negativ (CPU, ndoshta disk IO), për shkak të punës me skedarët sparse.
- Negativ (CPU), për shkak të nevojës për kompresimin e faqeve.
Cila do të jetë pesha më e rëndë? Kjo varet shumë nga mjedisi, por unë prirem të mendoj se kompresimi i faqeve të diskut do të çojë më shumë në degradimin e performancës në shumicën e sistemeve. Sidomos pasi testet në DBMS të tjera që përdorin një qasje të ngjashme me skedarët sparse tregojnë rënien e performancës kur kompresimi është aktivizuar.
Si të aktivizoni dhe konfiguroni
Siç u tha më lart, versioni minimal i Apache Ignite që mbështet kompresimin e faqeve të diskut: 2.8 dhe mbështetet vetëm nga sistemi operativ Linux. Aktivizimi dhe konfigurimi bëhet si më poshtë:
- Në class-path duhet të jetë moduli ignite-compression. Në mënyrë që kjo të ndodhë, ai ndodhet në shpërndarjen e Apache Ignite në direktorinë libs/optional dhe nuk përfshihet në class-path. Thjesht mund ta shkoni direktorinë një nivel më lart në libs dhe atëherë gjatë nisjes përmes ignite.sh, do të aktivizohet automatikisht.
- Përshtatja duhet të jetë e aktivizuar (Aktivizohet përmes
DataRegionConfiguration.setPersistenceEnabled(true)). - TĂ« ŃĐ°Đ·ĐŒĐ”ŃĐ° e faqes duhet tĂ« jetĂ« mĂ« e madhe se pĂ«rmasat e bllokut tĂ« sistemit tĂ« skedarĂ«ve (mund tĂ« caktohet pĂ«rmes
DataStorageConfiguration.setPageSize()). - Për çdo cache, të dhënat e të cilit duhet të kompresohen, duhet të konfigurohet në mënyrë që të përcaktohet metoda e kompresimit dhe (opsionale) niveli i kompresimit (metodat
CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()).
Kompaktimi i WAL
Si funksionon kjo
ĂfarĂ« Ă«shtĂ« WAL dhe pĂ«rse Ă«shtĂ« e nevojshme? ShumĂ« shkurt: Ă«shtĂ« njĂ« regjistĂ«r nĂ« tĂ« cilin kalojnĂ« tĂ« gjitha ngjarjet qĂ« e ndryshojnĂ« pĂ«rfundimisht magazinĂ«n e faqeve. Kjo Ă«shtĂ« e nevojshme kryesisht pĂ«r mundĂ«sinĂ« e riparimit nĂ« rast rĂ«nie. Cdo operacion para se tĂ« dorĂ«zojĂ« menaxhimin te pĂ«rdoruesi duhet sĂ« pari tĂ« regjistrojĂ« ngjarjen nĂ« WAL, nĂ« mĂ«nyrĂ« qĂ« nĂ« rast rĂ«nie tĂ« jetĂ« e mundur tĂ« rikthejĂ« pĂ«rmes regjistrit dhe tĂ« rikthejĂ« tĂ« gjitha operacionet pĂ«r tĂ« cilat pĂ«rdoruesi mori njĂ« pĂ«rgjigje tĂ« suksesshme, edhe nĂ«se kĂ«to operacione nuk e arritĂ«n ende tĂ« pasqyrohen nĂ« magazinĂ«n e faqeve nĂ« disk (mĂ« sipĂ«r Ă«shtĂ« pĂ«rshkruar se regjistrimi aktual nĂ« magazinĂ«n e faqeve kryhet nĂ« njĂ« proces qĂ« quhet "checkpoint" me ndonjĂ« vonesĂ« nga proceset e veçanta).
Regjistrimet në WAL ndahen në logjike dhe fizike. Logjike - janë çelësat dhe vlerat e vetë. Fizike - reflektosh ndryshimet e faqeve në magazinën e faqeve. Nëse regjistrimet logjike mund të jenë të dobishme për disa raste, regjistrimet fizike janë të nevojshme vetëm për riparim në rast rënie dhe duhen regjistrime vetëm që nga përfundimi i fundit i suksesshëm të checkpoint-it. Këtu nuk do të hyjmë në detaje dhe shpjegojmë pse kjo funksionon kështu, por ata që janë të interesuar mund të referohen në artikullin e tashmë përmendur në Apache Ignite Wiki: .
Për një regjistrim logjik shpesh ka disa regjistrime fizike. Pra, për shembull, një operacion put në cache preku disa faqe në memorien e faqeve (faqen me të dhënat vetë, faqet me indekset, faqet me liste të lirë). Në disa teste sintetike, mu ka rezultuar se regjistrimet fizike përbënin deri në 90% të volumit të skedarit WAL. Në të njëjtën kohë, ato nevojiten vetëm për një periudhë të shkurtër kohore (sipërfaqja e intervalit mes checkpoint-eve është 3 minuta). Logjike do të ishte të eliminoheshin këto të dhëna pas humbjes së aktualitetit të tyre. Kjo është pikërisht ajo që realizon mekanizmi i kompresimit të WAL-it, duke eliminuar regjistrimet fizike dhe duke kompresuar me zip regjistrimet logjike që mbeten, duke zvogëluar kështu ndjeshëm madhësinë e skedarit (herë pas here deri në dhjetëra herë).
Fizikisht, WAL përbëhet nga disa segmente (sipërfaqësisht 10) me madhësi fikse (sipërfaqësisht 64Mb), të cilat rikuperohen në mënyrë ciklike. Sapo segmenti aktual të mbushet, segmenti tjetër i tij caktohet si aktual, ndërsa segmenti i mbushur kopjohet në arkiv nga një rrjedhë e veçantë. Kompresimi i WAL tashmë punon me segmentet arkivore. Gjithashtu, përmes një rrjedhe të veçantë, monitoron përfundimin e pikëkontrollit dhe fillon kompresimin e segmenteve arkivore, regjistrimet fizike për të cilat nuk janë më të nevojshme.
Ndikimi në performancë
Duke pasur parasysh se kompresimi i WAL funksionon në një rrjedhë të veçantë, nuk duhet të ketë ndonjë ndikim të drejtpërdrejtë mbi operacionet në zhvillim. Megjithatë, ai shpërndan një ngarkesë shtesë në CPU (kompresimi) dhe disk (leximi i çdo segmenti të WAL nga arkivi dhe regjistrimi i segmenteve të kompresuara), kështu që nëse sistemi punon në kufijtë e mundësive, ai gjithashtu do të çojë në degradimin e performancës.
Si të aktivizoni dhe konfiguroni
Aktivizoni kompresimin e WAL duke përdorur pronën WalCompactionEnabled në DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Po ashtu, me metodën DataStorageConfiguration.setWalCompactionLevel() mund të caktoni nivelin e kompresimit, nëse nuk jeni të kënaqur me vlerën e paracaktuar (BEST_SPEED).
Kompresimi i snapshot-it të faqeve WAL
Si funksionon kjo
MĂ« parĂ« kemi zbuluar se regjistrimet WAL ndahen nĂ« logjike dhe fizike. PĂ«r çdo ndryshim tĂ« çdo faqeje nĂ« memorinĂ« e faqeve krijohet njĂ« regjistĂ«r fizik WAL. Regjistrat fizikĂ« gjithashtu ndahen nĂ« dy nĂ«nllojra: regjistri i snapshot-it tĂ« faqes dhe regjistri delta. Ădo herĂ« kur kemi njĂ« ndryshim nĂ« njĂ« faqe dhe e çojmĂ« atĂ« nga njĂ« gjendje tĂ« pastĂ«r nĂ« njĂ« gjendje tĂ« ndotur, nĂ« WAL ruhet njĂ« kopje e plotĂ« e kĂ«saj faqeje (regjistri i snapshot-it tĂ« faqes â snapshot i faqes). Edhe nĂ«se ne ndryshojmĂ« vetĂ«m njĂ« bajt, nĂ« WAL do tĂ« ruhet njĂ« regjistĂ«r pak mĂ« i madh se madhĂ«sia e faqes. NĂ«se kemi njĂ« ndryshim nĂ« njĂ« faqe qĂ« tashmĂ« Ă«shtĂ« e ndotur, atĂ«herĂ« nĂ« WAL formohet njĂ« regjistĂ«r delta, nĂ« tĂ« cilin pasqyrohen vetĂ«m ndryshimet krahasuar me gjendjen e mĂ«parshme tĂ« faqes, por jo e gjithĂ« faqja nĂ« tĂ«rĂ«si. Pasi qĂ« rivendosja e gjendjeve tĂ« faqeve nga e ndotur nĂ« tĂ« pastĂ«r kryhet gjatĂ« procesit tĂ« kontrollit, menjĂ«herĂ« pas fillimit tĂ« kontrollit, praktisht tĂ« gjithĂ« regjistrat fizikĂ« do tĂ« pĂ«rbĂ«hen vetĂ«m nga snapshot-e tĂ« faqeve (pasi tĂ« gjitha faqet menjĂ«herĂ« pas fillimit tĂ« kontrollit janĂ« tĂ« pastra), pastaj me kalimin e kohĂ«s drejt kontrollit tĂ« ardhshĂ«m, pjesa e regjistrave delta fillon tĂ« rritet dhe pĂ«rsĂ«ri rivendoset nĂ« fillim tĂ« kontrollit tĂ« ardhshĂ«m. Matjet nĂ« disa teste sintetike kanĂ« treguar se pjesa e snapshot-eve tĂ« faqeve nĂ« vĂ«llimin e pĂ«rgjithshĂ«m tĂ« regjistrave fizikĂ« arrin deri nĂ« 90%.
Ideja e kompresimit të snapshot-it të faqes WAL është të kompresojë snapshot-et e faqeve duke përdorur një mjet tashmë të gatshëm për kompresimin e faqeve (shih disk page compression). Në këtë rast, regjistrat në WAL ruhen radhazi në mënyrë append-only dhe nuk ka nevojë për lidhjen e regjistrave me kufijtë e blloqeve të sistemit të skedarëve, kështu që këtu, në ndryshim nga mekanizmi i kompresimit të faqeve disk, ne nuk kemi nevojë për skedarë sparse, kështu që ky mekanizëm do të punojë jo vetëm në sistemin operativ Linux. Për më tepër, nuk ka rëndësi se sa shumë kemi arritur të kompresojmë faqen. Edhe nëse ne lirojmë 1 bajt kjo është gjithashtu një rezultat pozitiv dhe ne mund të ruajmë në WAL të dhëna të kompresuara, në ndryshim nga kompresimi i faqes disk, ku ruajmë faqen e kompresuar vetëm nëse lirojmë më shumë se 1 bllok të sistemit të skedarëve.
Faqet janë të dhëna që mund të kompresohen mirë, pjesa e tyre në vëllimin e përgjithshëm të WAL është shumë e lartë, kështu që pa ndryshuar formatin e skedarit WAL mund të arrijmë një reduktim të konsiderueshëm të madhësisë së tij. Kompresimi i regjistrimeve logjike gjithashtu do të kërkonte ndryshimin e formatit dhe humbjen e kompatibilitetit, për shembull, për konsumatorët e jashtëm që mund të jenë të interesuar për regjistrimet logjike, duke mos sjellë një ulje të konsiderueshme të vëllimit të skedarit.
Përveç kompresimit të faqeve disk, për kompresimin e snapshots të faqeve WAL mund të përdoren algoritme kompresimi ZSTD, LZ4, Snappy, si dhe moda SKIP_GARBAGE.
Ndikimi në performancë
Siç nuk është e vështirë të vini re, aktivizimi direkt i kompresimit të snapshots të faqeve WAL ndikon vetëm te proceset që shkruajnë të dhëna në memorien e faqeve, pra tek ato procese që ndryshojnë të dhënat në cache. Leximi nga WAL i regjistrimeve fizike ndodh vetëm një herë, në momentin e ngjalljes së nyjës pas rënies (dhe vetëm në rastin e rënies gjatë procesit të kontrollit).
PĂ«r proceset qĂ« ndryshojnĂ« tĂ« dhĂ«nat, kjo ndikon nĂ« kĂ«tĂ« mĂ«nyrĂ«: ne pĂ«rfitojmĂ« njĂ« efekt negativ (CPU) pĂ«r shkak tĂ« nevojĂ«s pĂ«r tĂ« kompresuar çdo herĂ« faqen para se ta shkruajmĂ« nĂ« disk dhe njĂ« efekt pozitiv (disk IO) pĂ«r shkak tĂ« reduktimit tĂ« sasisĂ« sĂ« tĂ« dhĂ«nave qĂ« shkruhen. Prandaj, gjithçka Ă«shtĂ« e thjeshtĂ«, nĂ«se performanca e sistemit preket nga CPU, kemi njĂ« degradim tĂ« vogĂ«l, nĂ«se nga hyrja/dalja nĂ« disk â kemi njĂ« rritje.
Përmes reduktimit të madhësisë së WAL, gjithashtu ndikojnë (pozitivisht) proceset që dërgojnë në arkiv segmentet WAL dhe proceset e kompaktimit të WAL.
Testet reale të performancës në ambientin tonë me të dhëna sintetike treguan një rritje të vogël (thrputi u rrit nga 10%-15%, latency u reduktua nga 10%-15%).
Si të aktivizoni dhe konfiguroni
Versioni minimal i Apache Ignite: 2.8. Aktivizimi dhe konfigurimi bëhet si më poshtë:
- Në class-path duhet të jetë moduli ignite-compression. Në mënyrë që kjo të ndodhë, ai ndodhet në shpërndarjen e Apache Ignite në direktorinë libs/optional dhe nuk përfshihet në class-path. Thjesht mund ta shkoni direktorinë një nivel më lart në libs dhe atëherë gjatë nisjes përmes ignite.sh, do të aktivizohet automatikisht.
- Përshtatja duhet të jetë e aktivizuar (Aktivizohet përmes
DataRegionConfiguration.setPersistenceEnabled(true)). - Duhet të specifikohet moda e kompresimit me metodën
DataStorageConfiguration.setWalPageCompression(), siç është çaktivizuar kompresimi në mënyrë parazgjedhjeje (në modalitetin DISABLED). - Mund të specifikohet në mënyrë opsionale shkalla e kompresimit me metodën
DataStorageConfiguration.setWalPageCompression(), vlerat e pranueshme për secilën nga modalitetet shihni në javadoc të metodës.
PĂ«rfundim
Mekanizmat e shqyrtuara për kompresimin e të dhënave në Apache Ignite mund të përdoren të pavarura nga njëra-tjetra, por gjithashtu janë të pranueshme edhe çdo kombinim i tyre. Kuptimi i parimeve të funksionimit të tyre do të ndihmojë në përcaktimin e përshtatshmërisë së tyre për nevojat tuaja në ambientin tuaj dhe çfarë do t'ju duhet të sakrifikoni për t'i përdorur ato. Kompresimi i faqeve të diskut është i destinuar për kompresimin e ruajtjes kryesore dhe mund të sigurojë një shkallë mesatare kompresimi. Kompresimi i snapshot-eve të faqeve WAL do të ofrojë një shkallë mesatare kompresimi për skedarët WAL, duke rritur me të gjitha gjasat edhe performancën. Kompresimi i WAL nuk do të ndikojë pozitivisht në performancë, por do të reduktojë maksimalisht madhësinë e skedarëve WAL përmes fshirjes së regjistrimeve fizike.
Burimi: habr.com
