Kur punoni me sasi të mëdha të dhënash, ndonjëherë mund të lindë problemi i mungesës së hapësirës në disqe. Një nga mënyrat për të zgjidhur këtë problem është kompresimi, i cili lejon që të rritet kapaciteti i ruajtjes në të njëjtin ekip. 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 realizuara brenda produktit për kompresimin në disk. Metodat e tjera të kompresimit të të dhënave (përmes rrjetit, në memorie) si të realizuara ashtu edhe jo do të mbeten jashtë kornizës.
Pra, me modulin e aktivizuar të persistence, si rezultat i ndryshimeve të të dhënave në cache, Ignite fillon të shkruajë në disk:
- PĂ«rmbajtja e caches
- Dita e regjistrimit të parashikueshëm (Write Ahead Log, më pas thjesht WAL)
Për kompresimin e WAL ka një mekanizëm që ekziston prej kohësh, i quajtur kompresimi i WAL. Në Apache Ignite 2.8 që sapo doli në treg, u shfaqën edhe dy mekanizma që lejojnë kompresimin e të dhënave në disk, kjo është kompresimi i faqes së diskut për kompresimin e përmbajtjes së caches dhe kompresimi i snapshot-it të faqes WAL për kompresimin e disa regjistrimeve WAL. Më poshtë do të flasim më shumë për këta tre mekanizma.
Kompresimi i faqes së diskut
Si funksionon
Fillimi, le të flasim shumë shkurt për mënyrën si e ruan Ignite të dhënat. Përdoret memoria me faqe për ruajtje. Madhësia e faqes përcaktohet në fillim të nodit dhe nuk mund të ndryshohet në faza të mëvonshme; gjithashtu, madhësia e faqes duhet të jetë një fuqi e dyshes dhe shumëfish i madhësisë së bllokut të sistemit të skedarëve. Faqet ngjiten në RAM nga disku sipas nevojës, madhësia e të dhënave në disk mund të tejkalojë vëllimin e RAM-së së dedikuar. Në rast se nuk ka mjaft vend në RAM për të ngarkuar një faqe nga disku, faqet e vjetra, që nuk përdoren më, do të zëvendësohen nga RAM.
Të dhënat ruhen në disk në këtë formë: për çdo parti të çdo grupi cache krijohet një skedar i veçantë, në këtë skedar, në rendin rritës të indeksit, njëra pas tjetrës ndodhen faqet. Identifikuesi i plotë i faqes përfshin identifikuesin e grupit cache, numrin e partisë dhe indeksin e faqes në skedar. Prandaj, përmes identifikuesit të plotë të faqes, ne mund të përcaktojmë në mënyrë unike skedarin dhe offsetin në skedar për secilën faqe. më shumë rreth strukturës së memories me faqe mund të lexoni në artikullin në Apache Ignite Wiki: .
Mekanizmi i kompresimit të faqeve të diskut, siç mund të kuptohet nga emri, funksionon në nivelin e faqeve. Kur aktivizohet ky mekanizëm, puna me të dhënat në RAM bëhet siç është, pa asnjë lloj kompresimi, por në momentin e ruajtjes së faqeve nga RAM në disk, ndodh kompresimi i tyre.
Por kompresimi i secilës faqe veç e veç nuk është zgjidhje për problemin; duhet të gjejmë një mënyrë për të zvogëluar madhësinë e skedave përfundimtare me të dhëna. Nëse madhësia e faqes nuk është më fikse, nuk mund të shkruajmë faqet në skedë njëra pas tjetrës, pasi kjo mund të sjellë një sërë problemesh:
- Nuk do të jemi në gjendje të llogarisim offset-in përmes indeksit të faqes ku ndodhet ajo në skedë.
- Nuk është e qartë se çfarë duhet të bëjmë me faqet që ndodhen jo në fund të skedës dhe ndryshojnë madhësinë e tyre. Nëse madhësia e faqes zvogëlohet, hapësira që ajo lirohet humbet. Nëse madhësia e faqes rritet, nevojitet të kërkojmë një vend të ri për të në skedë.
- Nëse faqja zhvendoset në një numër që nuk është shumëfish i madhësisë së bllokut të sistemit të skedarëve, për ta lexuar ose shkruar atë do të nevojitet të preken një bllok më shumë, çka mund të çojë në degradimin e performancës.
Për të mos e zgjidhur këtë problem në nivelin tuaj, kompresimi i faqeve të diskut në Apache Ignite përdor një mekanizëm të sistemit të skedarëve të quajtur skedarë të rrallë. Skedari i rrallë (sparse) është një skedar në të cilin disa zona të mbushura me zero mund të shënohen si "humbje". Kështu, blloket e sistemit të skedarëve për ruajtjen e këtyre humbjeve nuk do të alokohen, duke arritur kështu një kursim hapësire në disk.
ĂshtĂ« logjike qĂ« pĂ«r tĂ« liruar njĂ« blok tĂ« sistemit tĂ« skedarĂ«ve, madhĂ«sia e vrimĂ«s duhet tĂ« jetĂ« mĂ« e madhe ose e barabartĂ« me blokun e sistemit tĂ« skedarĂ«ve, çka vĂ« njĂ« kufizim shtesĂ« mbi madhĂ«sinĂ« e faqeve nĂ« Apache Ignite: qĂ« kompresimi tĂ« ketĂ« ndonjĂ« efekt, Ă«shtĂ« e nevojshme qĂ« madhĂ«sia e faqes tĂ« jetĂ« rreptĂ«sisht mĂ« e madhe se madhĂ«sia e blokut tĂ« sistemit tĂ« skedarĂ«ve. NĂ«se madhĂ«sia e faqes Ă«shtĂ« e barabartĂ« me madhĂ«sinĂ« e blokut, ne kurrĂ« nuk do tĂ« mund tĂ« lirojnĂ« asnjĂ« bllok, sepse pĂ«r tĂ« liruar njĂ« bllok tĂ« vetĂ«m Ă«shtĂ« e nevojshme qĂ« faqja e kompresuar tĂ« zĂ«rĂ« 0 byte. NĂ«se madhĂ«sia e faqes Ă«shtĂ« e barabartĂ« me madhĂ«sinĂ« e 2 ose 4 blloqeve, ne tashmĂ« do tĂ« mund tĂ« lirojmĂ« tĂ« paktĂ«n njĂ« bllok nĂ«se faqja jonĂ« kompresohet tĂ« paktĂ«n nĂ« 50% ose 75% pĂ«rkatĂ«sisht.
Pra, përmbledhja përfundimtare e funksionimit të mekanizmit: Kur shkruhet një faqe në disk, bëhet përpjekje për ta kompresuar faqen. Nëse madhësia e faqes së kompresuar lejon lirimin e një ose më shumë blloqeve të sistemit të skedarëve, faqja shkruhet në formë të kompresuar, dhe në vendin e blloqeve të lira shpërthehet një "vrimë" (kryhet thirrja sistemore fallocate() me flamurin «punch hole»). Nëse dimensioni i faqes së tkurrur nuk lejon lëshimin e blloqeve, faqja ruhet ashtu siç është, në formë të pa tkurrur. Të gjitha offsetet e faqeve llogariten gjithashtu si pa kompresim, duke shumëzuar indeksin e faqes me madhësinë e faqes. Nuk kërkohet asnjë relokim i faqeve me forcat e veta. Offsetet e faqeve ashtu si pa kompresim bien brenda kufijve të blloqeve të sistemit të skedarit.
Në realizimin e tanishëm, Ignite është në gjendje të punojë me skedarë sparse vetëm nën OS Linux, përkatësisht kompresimi i faqes së 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 faqes së diskut: ZSTD, LZ4, Snappy. Për më tepër, ka një mënyrë pune (SKIP_GARBAGE), në të cilën vetëm hidhen vendet e pafshirë në faqe pa aplikuar kompresim në të dhënat e mbetura, që lejon të zvogëlohet ngarkesa në CPU krahasuar me algoritmet e përmendura më parë.
Ndikimi në performancë
Fatkeqësisht nuk kam realizuar matje të performancës në ambiente reale, pasi nuk parashikohet përdorimi i këtij mekanizmi në prodhim, por mund të diskutojmë në mënyrë teorike se ku do të humbim dhe ku do të fitonim.
Për këtë na nevojitet të kujtojmë se si realizohet leximi dhe shkruarja e faqeve gjatë qasjes ndaj tyre:
- Kur kryhet operacioni i leximit, fillimisht kërkohet në RAM; nëse kërkimi dështoi, faqja ngarkohet në RAM nga disku nga të njëjtin proces që kryen leximin.
- Kur kryhet operacioni i shkruarjes, faqja në RAM dëshmohet si e ndyrë, ndërkohë që ruajtja fizike e faqes në disk nuk ndodh menjëherë në procesin që realizon shkruarjen. Të gjitha faqet e ndyrë ruhen në disk më vonë gjatë procesit të pikë-kontrollit nga procese të ndara.
Pra, ndikimi në operacionet e leximit:
- Pozitiv (disk IO), për shkak të reduktimit të numrit të blloqeve të lexuar nga sistemi i skedarëve.
- Negative (CPU), due to the additional load required by the operating system to work with sparse files. It is also possible that additional IO operations will implicitly occur to save the more complex structure of the sparse file (I am unfortunately not familiar with all the details of how sparse files work).
- Negative (CPU), due to the need to decompress pages.
- There is no impact on write operations.
- Effect on the checkpoint process (here everything is similar to read operations):
- Positive (disk IO), due to the reduction in the number of blocks written to the file system.
- Negative (CPU, possibly disk IO), due to working with sparse files.
- Negative (CPU), due to the need to compress pages.
Which side of the scale will tip? This largely depends on the environment, but I lean towards the belief that disk page compression will lead to performance degradation in most systems. Moreover, tests on other databases using a similar approach with sparse files show a decrease in performance when compression is enabled.
How to enable and configure
Siç është përmendur më parë, versioni minimal i Apache Ignite që mbështet kompresimin e faqeve të diskut është 2.8 dhe mbështetet vetëm nga sistemi operativ Linux. Aktivimi dhe konfigurimi realizohen si më poshtë:
- Në class-path duhet të jetë moduli ignite-compression. Në default, ai ndodhet në shpërndarjen e Apache Ignite në katalogun libs/optional dhe nuk përfshihet në class-path. Mund ta transferoni thjesht katalogun një nivel lart në libs dhe atëherë, gjatë ekzekutimit përmes ignite.sh, do të përfshihet automatikisht.
- Persistenca duhet të jetë e mundësuar (Aktivizohet përmes
DataRegionConfiguration.setPersistenceEnabled(true)). - Këndi i faqes duhet të jetë më i madh se madhësia e bllokut të sistemit të skedarëve (mund të përcaktohet përmes
DataStorageConfiguration.setPageSize()). - Për çdo cache, të dhënat e të cilit duhet të kompresohen, është e nevojshme të konfigurohet metoda e kompresimit dhe (opsionale) niveli i kompresimit në konfiguracion (metodat
CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()).
Kompaktimi i WAL
Si funksionon
ĂfarĂ« Ă«shtĂ« WAL dhe pĂ«rse Ă«shtĂ« e nevojshme? ShumĂ« shkurt: Ă«shtĂ« njĂ« regjistĂ«r ku regjistrohen tĂ« gjitha ngjarjet qĂ« ndyshojnĂ« nĂ« fund depozitimin e faqes. Ai Ă«shtĂ« i nevojshĂ«m kryesisht pĂ«r mundĂ«sinĂ« e rikuperimit nĂ« rast rĂ«nieje. Ădo operacion, para se t'i japĂ« kontrollin pĂ«rdoruesit, duhet fillimisht tĂ« regjistrojĂ« njĂ« ngjarje nĂ« WAL, nĂ« mĂ«nyrĂ« qĂ« nĂ« rast rĂ«nieje tĂ« ketĂ« mundĂ«si tĂ« riprodhojĂ« nĂ«pĂ«rmjet regjistrit dhe tĂ« rikuperojĂ« tĂ« gjithĂ« operacionet pĂ«r tĂ« cilat pĂ«rdoruesi ka marrĂ« njĂ« pĂ«rgjigje tĂ« suksesshme, edhe nĂ«se kĂ«to operacione nuk kanĂ« arritur tĂ« reflektohen nĂ« depozitimin e faqes nĂ« disk (mĂ« sipĂ«r Ă«shtĂ« pĂ«rshkruar se regjistrimi efektiv nĂ« depozitimin e faqes realizohet nĂ« njĂ« proces tĂ« quajtur "checkpoint" me njĂ« vonesĂ« nga disa rrjedha tĂ« veçanta).
Shënimet në WAL ndahen në logjike dhe fizike. Logjike janë vetë çelësat dhe vlerat. Fizike pasqyrojnë ndryshimet e faqeve në magazinën e faqeve. Nëse shënimet logjike mund të jenë të dobishme për raste të tjera, shënimet fizike janë të nevojshme vetëm për rikuperimin në rast të rënies dhe kërkojnë shënime vetëm nga pika e fundit e suksesshme të kontrollit. Këtu nuk do të thellohemi në detaje dhe të shpjegojmë pse kjo funksionon kështu, por ata që janë të interesuar mund të referohen në artikullin e përmendur më parë në Apache Ignite Wiki: .
Një regjistër logjik shpesh ka disa regjistra fizikë. Pra, për shembull, një operacion 'put' në cache prek disa faqe në memorjen e faqeve (faqen me të dhëna, faqet me indekse, faqet me lista të lira). Në disa teste sintetike, kam vënë re se regjistrat fizikë zinin deri në 90% të volumit të skedarit WAL. Megjithatë, ata nevojiten për një kohë shumë të shkurtër (si parazgjedhje, intervali midis pikave të kontrollit është 3 minuta). Ishte logjike që të hiqeshin këta të dhëna pas humbjes së rëndësisë së tyre. Pikërisht këtë bëjnë mekanizmat e kompresimit WAL; ata heqin regjistrat fizikë dhe shkrin regjistrat logjikë të mbetur me zip, duke reduktuar ndjeshëm madhësinë e skedarit (ndonjëherë në dhjetëra herë).
WAL fizikisht përbëhet nga disa segmente (për default 10) me madhësi fikse (për default 64MB), të cilat ripërzihen në mënyrë ciklike. Sa herë që segmenti aktual mbushet, i caktohet segmenti pasues, dhe segmenti i mbushur kopjohet në arkiv me një rrjedhë të veçantë. Kompaktimi i WAL tashmë punon me segmentet arkivore. Gjithashtu, në një rrjedhë të veçantë, ai ndjek realizimin e pikës kontrolli dhe fillon kompresimin për segmentet arkivore, për të cilat regjistrimet fizike nuk janë më të nevojshme.
Ndikimi në performancë
Duke qenë se kompaktimi i WAL punon në një rrjedhë të veçantë, nuk duhet të ketë ndikim të drejtpërdrejtë në operacionet që ekzekutohen. Megjithatë, ai jep një ngarkesë shtesë në sfond për CPU (kompresimi) dhe diskun (leximi i çdo segmenti WAL nga arkiva dhe shkruajti i segmenteve të kompresuar), prandaj nëse sistemi punon në kufijtë e mundësive, ai gjithashtu do të çojë në degradimin e performancës.
How to enable and configure
Mund të aktivizoni kompaktimin e WAL me anë të pronës WalCompactionEnabled në DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Gjithashtu, me metodën DataStorageConfiguration.setWalCompactionLevel() mund të përcaktoni nivelin e kompresimit, nëse nuk jeni të kënaqur me vlerën e paracaktuar (BEST_SPEED).
Kompresimi i snapshot-it të faqes WAL
Si funksionon
Kemi zbuluar tashmĂ« se regjistrimet WAL ndahen nĂ« logjike dhe fizike. PĂ«r çdo ndryshim nĂ« secilĂ«n faqe nĂ« memorien e faqes krijohet njĂ« regjistĂ«r fizik WAL. Regjistrimet fizike po ashtu ndahen nĂ« dy nĂ«nkategoritĂ«: regjistri i snapshots tĂ« faqeve dhe regjistri delta. Ădo herĂ« qĂ« ndryshojmĂ« diçka nĂ« faqe dhe e çojmĂ« atĂ« nga njĂ« gjendje tĂ« pastĂ«r nĂ« njĂ« tĂ« ndotur, nĂ« WAL ruhet njĂ« kopje e plotĂ« e kĂ«saj faqeje (regjistri i snapshots tĂ« faqeve). Edhe nĂ«se ne kemi ndryshuar vetĂ«m njĂ« byte, nĂ« WAL do tĂ« ruhet njĂ« regjistĂ«r qĂ« Ă«shtĂ« pak mĂ« i madh se madhĂ«sia e faqes. NĂ«se ndryshojmĂ« diçka nĂ« njĂ« faqe qĂ« tashmĂ« Ă«shtĂ« e ndotur, atĂ«herĂ« nĂ« WAL formohet regjistri delta, nĂ« tĂ« cilin janĂ« reflektuar vetĂ«m ndryshimet krahasuar me gjendjen e mĂ«parshme tĂ« faqes, por jo e gjithĂ« faqja. Duke qenĂ« se rinovimi i gjendjeve tĂ« faqeve nga e ndotura nĂ« tĂ« pastĂ«r realizohet gjatĂ« procesit tĂ« kontrollit, menjĂ«herĂ« pas fillimit tĂ« kontrollit praktikisht tĂ« gjithĂ« regjistrat fizikĂ« do tĂ« pĂ«rbĂ«hen vetĂ«m nga snapshots tĂ« faqeve (sepse tĂ« gjitha faqet menjĂ«herĂ« pas fillimit tĂ« kontrollit janĂ« tĂ« pastra). MĂ« pas, ndĂ«rsa afrohemi drejt kontrollit tjetĂ«r, shuma e regjistrave delta fillon tĂ« rritet dhe pĂ«rsĂ«ri ri-inizializohet nĂ« fillimin e kontrollit tjetĂ«r. Matjet nĂ« disa teste sintetike kanĂ« treguar se shuma e snapshots tĂ« faqeve nĂ« vĂ«llimin e pĂ«rgjithshĂ«m tĂ« regjistrave fizikĂ« arrin nĂ« 90%.
Ideja e kompresimit të snapshot-eve të faqes WAL qëndron në kompresimin e snapshot-eve të faqeve duke përdorur një mjet tashmë të gatshëm për kompresim (shih kompresimin e faqeve të diskut). Kështu, në regjistrimet e WAL ruhet njëpasnjërisht në një mënyrë append-only dhe nuk ka nevojë për lidhjen e regjistrimeve me kufijtë e blloqeve të sistemit të skedarëve, prandaj këtu, ndryshe nga mekanizmi i kompresimit të faqeve të diskut, nuk kemi nevojë për skedarë sparse, kështu që ky mekanizëm do të funksionojë jo vetëm në OS Linux. Për më tepër, nuk është e rëndësishme se sa shumë arritëm të comprimojmë faqen. Edhe nëse çlirojmë 1 byte, kjo është një rezultat pozitiv dhe ne mund të ruajmë të dhënat e kompresuara në WAL, ndryshe nga kompresimi i faqeve të diskut, ku ruajmë faqen e kompresuar vetëm nëse çliruar më shumë se 1 bllok të sistemit të skedarëve.
Faqet â janĂ« tĂ« dhĂ«na qĂ« kompresohen mirĂ«, pjesa e tyre nĂ« volumin e pĂ«rgjithshĂ«m tĂ« WAL Ă«shtĂ« shumĂ« e lartĂ«, kĂ«shtu qĂ«, duke mos ndryshuar formatin e skedarit WAL, mund tĂ« arrijmĂ« njĂ« reduktim tĂ« rĂ«ndĂ«sishĂ«m tĂ« madhĂ«sisĂ« sĂ« tij. Kompresimi, pĂ«rfshirĂ« regjistrat logjikĂ«, do tĂ« kĂ«rkonte njĂ« ndryshim tĂ« formatit dhe humbje tĂ« kompatibilitetit, pĂ«r shembull, pĂ«r konsumatorĂ«t e jashtĂ«m, tĂ« cilĂ«ve mund t'u interesojnĂ« regjistrat logjikĂ«, pa sjellĂ« njĂ« ulje tĂ« dukshme tĂ« volumin tĂ« skedarit.
Ashtu si për kompresimin e faqeve disk, për kompresimin e skenave të faqeve WAL mund të përdoren algoritme kompresimi ZSTD, LZ4, Snappy, si dhe moda SKIP_GARBAGE.
Ndikimi në performancë
Siç është e lehtë të vërehet, aktivizimi i drejtpërdrejtë i kompresimit të skenave të faqeve WAL ndikon vetëm në rrjedhat që shkruajnë të dhëna në memory page, domethënë në ato rrjedha që ndryshojnë të dhënat në cache. Leximi i regjistrave fizikë WAL ndodh vetëm një herë, në momentin e ngjitjes së nodit pas rënies (dhe vetëm në rastin e rënies gjatë kontrollit).
Përfluxet që ndryshojnë të dhënat ndikojnë kështu: ne marrim një efekt negativ (CPU) për shkak të nevojës për të kompresuar faqen përpara 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, këtu është e thjeshtë; nëse performanca e sistemit është e varur nga CPU, kemi një degradim të vogël, ndërsa nëse është e varur nga hyrja/dalja diskore, kemi një rritje.
Indirekt, zvogëlimi i madhësisë së WAL gjithashtu ndikon (pozitivisht) në ato flukse që hedhin në arkiv segmentet e WAL dhe në flukset e kompresimit të WAL.
Testet e vërteta të performancës në mjedisin tonë me të dhëna sintetikë treguan një rritje të vogël (transmetimi u rrit me 10%-15%, ndërsa latenca u zvogëlua me 10%-15%).
How to enable and configure
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ë default, ai ndodhet në shpërndarjen e Apache Ignite në katalogun libs/optional dhe nuk përfshihet në class-path. Mund ta transferoni thjesht katalogun një nivel lart në libs dhe atëherë, gjatë ekzekutimit përmes ignite.sh, do të përfshihet automatikisht.
- Persistenca duhet të jetë e mundësuar (Aktivizohet përmes
DataRegionConfiguration.setPersistenceEnabled(true)). - Duhet të caktohet një mënyrë kompresimi me anë të metodës
DataStorageConfiguration.setWalPageCompression(), si parazgjedhje kompresimi është i çaktivizuar (nata DISABLED). - Opsionalisht, mund të caktosh shkallën e kompresimit me anë të metodës
DataStorageConfiguration.setWalPageCompression(), vlerat e pranueshme për secilën nga mënyrat mund të shihen në javadoc të metodës.
PĂ«rfundimi
Mekanizmat e shqyrtuar të kompresimit të të dhënave në Apache Ignite mund të përdoren në mënyrë të pavarur nga njëri-tjetri, por gjithashtu janë të pranueshme çdo kombinim i tyre. Kuptimi i parimeve të funksionimit të tyre do të lejojë të përcaktohet se sa mirë i përshtaten detyrave tuaja në ambientin tuaj dhe çfarë do të duhet të sakrifikoni gjatë përdorimit të tyre. Kompresimi i faqeve disk është i destinuar për kompresimin e ruajtjes kryesore dhe mund të ofrojë një shkallë mesatare të kompresimit. Kompresimi i snapshots të faqeve WAL do të ofrojë një shkallë mesatare të kompresimit për skedarët WAL, për më tepër, ka të ngjarë ta përmirësojë performancën. Kompaktimi WAL nuk do të ndikojë pozitivisht në performancë, por do të reduktojë sa më shumë që të jetë e mundur madhësinë e skedarëve WAL duke eliminuar regjistrimet fizike.
Burimi: habr.com
