Suure andmemahuga töötamisel võib mõnikord tekkida kettaruumipuuduse probleem. Üks võimalus selle probleemi lahendamiseks on tihendamine, tänu millele saate samadel seadmetel lubada salvestusmahtude suurendamist. Selles artiklis vaatleme, kuidas andmete tihendamine Apache Ignite'is töötab. Selles artiklis kirjeldatakse ainult tootes rakendatud ketta tihendamise meetodeid. Muud andmete tihendamise meetodid (võrgu kaudu, mälus), olenemata sellest, kas need on rakendatud või mitte, jäävad reguleerimisalast välja.
Seega, kui püsivusrežiim on lubatud, hakkab Ignite vahemälus olevate andmete muutumise tulemusena kettale kirjutama:
- Vahemälu sisu
- Kirjuta ette logi (edaspidi lihtsalt WAL)
WAL-i tihendamiseks on juba mõnda aega olnud mehhanism, mida nimetatakse WAL-i tihendamiseks. Hiljuti välja antud Apache Ignite 2.8 tutvustas veel kahte mehhanismi, mis võimaldavad teil kettal andmeid tihendada: kettalehe tihendus vahemälu sisu tihendamiseks ja WAL-lehe hetktõmmise tihendamine mõnede WAL-kirjete tihendamiseks. Lisateavet kõigi nende kolme mehhanismi kohta leiate allpool.
Kettalehe tihendamine
Kuidas see töötab
Kõigepealt vaatame väga lühidalt, kuidas Ignite andmeid salvestab. Lehekülje mälu kasutatakse salvestamiseks. Lehekülje suurus määratakse sõlme alguses ja seda ei saa hilisemates etappides muuta; samuti peab lehe suurus olema kahe astmega ja failisüsteemi ploki suuruse kordne. Lehed laaditakse RAM-i kettalt vastavalt vajadusele; kettal olevate andmete maht võib ületada eraldatud RAM-i. Kui RAM-is pole piisavalt ruumi lehe kettalt laadimiseks, tõstetakse vanad, enam mittekasutatud lehed RAM-ist välja.
Andmed salvestatakse kettale järgmisel kujul: iga vahemälugrupi iga partitsiooni jaoks luuakse eraldi fail, selles failis kuvatakse lehed üksteise järel kasvavas indeksi järjekorras. Täielik lehe identifikaator sisaldab faili vahemälurühma identifikaatorit, partitsiooni numbrit ja leheindeksit. Seega, kasutades täislehe identifikaatorit, saame iga lehe jaoks faili ja nihke failis üheselt määrata. Lisateavet otsimismälu kohta saate lugeda Apache Ignite Wiki artiklist: .
Ketta lehtede tihendamise mehhanism, nagu nimest võib arvata, töötab lehe tasemel. Kui see mehhanism on lubatud, töödeldakse RAM-is olevaid andmeid ilma pakkimiseta, kuid kui lehed salvestatakse RAM-ist kettale, siis need tihendatakse.
Kuid iga lehe eraldi tihendamine ei ole probleemi lahendus, peate tekkivate andmefailide suurust kuidagi vähendama. Kui lehe suurus pole enam fikseeritud, ei saa me enam lehti üksteise järel faili kirjutada, kuna see võib tekitada mitmeid probleeme:
- Leheküljeindeksit kasutades ei saa me arvutada nihet, mille võrra see failis asub.
- Pole selge, mida teha lehtedega, mis ei asu faili lõpus ja muudavad nende suurust. Kui lehe suurus väheneb, kaob vabastatud ruum. Kui lehe suurus suureneb, peate selle jaoks failis uue koha otsima.
- Kui leht liigub baitide arvu võrra, mis ei ole failisüsteemi ploki suuruse kordne, tuleb selle lugemiseks või kirjutamiseks puudutada veel ühte failisüsteemi plokki, mis võib viia jõudluse halvenemiseni.
Et vältida nende probleemide lahendamist omal tasemel, kasutab Apache Ignite'i kettalehtede tihendamine failisüsteemi mehhanismi, mida nimetatakse hõredaks failiks. Hõredad failid on failid, milles mõned nulliga täidetud piirkonnad saab märkida "aukudeks". Sel juhul ei eraldata nende aukude salvestamiseks failisüsteemi plokke, mis säästab kettaruumi.
On loogiline, et failisüsteemi ploki vabastamiseks peab augu suurus olema failisüsteemiplokist suurem või sellega võrdne, mis seab lehe suurusele ja Apache Ignite'ile täiendava piirangu: et tihendamine avaldaks mingit mõju, lehe suurus peab olema rangelt suurem failisüsteemi ploki suurusest. Kui lehe suurus on võrdne ploki suurusega, ei saa me kunagi vabastada ühtegi plokki, kuna ühe ploki vabastamiseks peab tihendatud leht hõivama 0 baiti. Kui lehe suurus on võrdne 2 või 4 ploki suurusega, saame juba vabastada vähemalt ühe ploki, kui meie leht on tihendatud vastavalt vähemalt 50% või 75%.
Seega lõplik kirjeldus mehhanismi toimimisest: Lehe kettale kirjutamisel üritatakse leht kokku suruda. Kui tihendatud lehe suurus võimaldab vabastada ühe või mitu failisüsteemi plokki, siis kirjutatakse leht tihendatud kujul ja vabastatud plokkide asemele tehakse “auk” (käitatakse süsteemikutse fallocate() augu lipuga). Kui tihendatud lehe suurus ei võimalda plokke vabastada, salvestatakse leht sellisena, nagu see on, tihendamata. Kõik lehekülje nihked arvutatakse samamoodi nagu ilma tihendamiseta, korrutades leheindeksi lehekülje suurusega. Lehtede ümberpaigutamine pole vajalik. Lehekülje nihked, nagu ka ilma tihendamiseta, langevad failisüsteemi plokkide piiridesse.
Praeguses teostuses saab Ignite töötada ainult hõredate failidega Linux OS-is; vastavalt sellele saab kettalehtede tihendamise lubada ainult siis, kui kasutate Ignite'i selles operatsioonisüsteemis.
Tihendusalgoritmid, mida saab kasutada kettalehtede tihendamiseks: ZSTD, LZ4, Snappy. Lisaks on olemas töörežiim (SKIP_GARBAGE), mille puhul visatakse välja ainult kasutamata ruum, ilma ülejäänud andmetele tihendamata, mis vähendab protsessori koormust võrreldes eelnevalt loetletud algoritmidega.
Mõju jõudlusele
Reaalseid jõudlusmõõtmisi ma reaalsetel stendidel kahjuks ei teinud, kuna meil pole plaanis seda mehhanismi tootmises kasutada, kuid teoreetiliselt võime spekuleerida, kus kaotame ja kus võidame.
Selleks peame meeles pidama, kuidas lehti juurde pääsedes loetakse ja kirjutatakse:
- Lugemistoimingu tegemisel otsitakse seda esmalt RAM-ist, kui otsing ebaõnnestub, laaditakse leht kettalt RAM-i sama lõime kaudu, mis lugemist teostab.
- Kirjutamistoimingu sooritamisel märgitakse RAM-is olev leht määrdunudks, kuid kirjutamist teostav lõim ei salvesta lehte kohe füüsiliselt kettale. Kõik määrdunud lehed salvestatakse kettale hiljem kontrollpunkti protsessis eraldi lõimedena.
Seega on mõju lugemistoimingutele järgmine:
- Positiivne (ketta IO), loetud failisüsteemi plokkide arvu vähenemise tõttu.
- Negatiivne (CPU), kuna operatsioonisüsteem vajab hõredate failidega töötamiseks täiendavat koormust. Samuti on võimalik, et keerukama hõreda failistruktuuri salvestamiseks ilmuvad siia vaikimisi täiendavad IO-toimingud (kahjuks ei ole ma kursis kõigi hõredate failide toimimise üksikasjadega).
- Negatiivne (CPU), kuna on vaja lehti lahti pakkida.
- See ei mõjuta kirjutamistoiminguid.
- Mõju kontrollpunkti protsessile (siin on kõik sarnane lugemistoimingutega):
- Positiivne (ketas IO), kirjutatud failisüsteemi plokkide arvu vähenemise tõttu.
- Negatiivne (CPU, võimalik, et ketta IO), hõredate failidega töötamise tõttu.
- Negatiivne (CPU), lehe tihendamise vajaduse tõttu.
Kummal pool skaalat kallutab? See kõik sõltub suuresti keskkonnast, kuid kaldun uskuma, et kettalehe tihendamine põhjustab suure tõenäosusega enamiku süsteemide jõudluse halvenemist. Lisaks näitavad teiste DBMS-ide testid, mis kasutavad sarnast lähenemist hõredate failidega, jõudluse langust, kui tihendamine on lubatud.
Kuidas lubada ja konfigureerida
Nagu eespool mainitud, on Apache Ignite'i minimaalne versioon, mis toetab kettalehtede tihendamist, 2.8 ja toetatakse ainult Linuxi operatsioonisüsteemi. Lubage ja konfigureerige järgmiselt.
- Klassiteel peab olema süüte tihendamise moodul. Vaikimisi asub see Apache Ignite'i distributsioonis libs/optional kataloogis ega sisaldu klassiteel. Saate kataloogi lihtsalt ühe taseme võrra kõrgemale liigutada libsidesse ja kui käivitate selle saidi ignite.sh kaudu, lubatakse see automaatselt.
- Püsivus peab olema lubatud (Lubatud kaudu
DataRegionConfiguration.setPersistenceEnabled(true)). - Lehekülje suurus peab olema suurem kui failisüsteemi ploki suurus (saate seda määrata kasutades
DataStorageConfiguration.setPageSize()). - Iga vahemälu jaoks, mille andmeid tuleb tihendada, peate konfigureerima tihendusmeetodi ja (valikuliselt) tihendustaseme (meetodid
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
WAL tihendus
Kuidas see töötab
Mis on WAL ja miks seda vaja on? Väga lühidalt: see on logi, mis sisaldab kõiki sündmusi, mis lõpuks muudavad lehe salvestusruumi. Seda on vaja eelkõige selleks, et kukkumise korral taastuda. Iga toiming peab enne kasutajale juhtimise andmist salvestama sündmuse WAL-i, et tõrke korral saaks seda logis taasesitada ja taastada kõik toimingud, millele kasutaja sai eduka vastuse, isegi kui need toimingud ei olnud aega lehe kettale salvestamises kajastuda (juba ülalpool on kirjeldatud, et tegelik kirjutamine lehehoidlasse toimub protsessis, mida nimetatakse "kontrollpunktiks" teatud viivitusega eraldi lõimede kaupa).
WAL-i kirjed jagunevad loogilisteks ja füüsilisteks. Booleanid on võtmed ja väärtused ise. Füüsiline – kajastab lehepoe lehtede muudatusi. Kuigi loogilised kirjed võivad mõnel muul juhul kasulikud olla, on füüsilisi kirjeid vaja ainult krahhi korral taastamiseks ja kirjeid on vaja alles pärast viimast edukat kontrollpunkti. Siin me ei lasku detailidesse ja selgitame, miks see nii töötab, kuid huvilised võivad viidata juba mainitud Apache Ignite Wiki artiklile: .
Ühe loogilise kirje kohta on sageli mitu füüsilist kirjet. See tähendab, et näiteks üks vahemällu paigutamise operatsioon mõjutab mitut lehekülge lehemälus (lehekülg andmetega, lehekülgede registritega, vabade loenditega lehed). Mõne sünteetilise testi käigus leidsin, et füüsilised kirjed hõivasid kuni 90% WAL-failist. Neid on aga vaja väga lühikest aega (vaikimisi on kontrollpunktide vahe 3 minutit). Loogiline oleks nendest andmetest pärast asjakohasuse kaotamist lahti saada. Täpselt seda teeb WAL-i tihendusmehhanism: see vabaneb füüsilistest kirjetest ja tihendab ülejäänud loogilised kirjed zip-i abil, samal ajal kui faili suurus väheneb oluliselt (mõnikord kümneid kordi).
Füüsiliselt koosneb WAL mitmest fikseeritud suurusega segmendist (vaikimisi 10) (vaikimisi 64 MB), mis kirjutatakse ringikujuliselt üle. Niipea kui praegune segment on täidetud, määratakse järgmine segment praeguseks ja täidetud segment kopeeritakse arhiivi eraldi lõime abil. WAL-tihendamine töötab juba arhiivisegmentidega. Samuti jälgib see eraldi lõimena kontrollpunkti täitmist ja alustab tihendamist arhiivisegmentides, mille jaoks füüsilisi kirjeid enam vaja pole.
Mõju jõudlusele
Kuna WAL-tihendamine toimub eraldi keermega, ei tohiks see otseselt mõjutada tehtavaid toiminguid. Kuid see annab ikkagi täiendava taustakoormuse protsessorile (tihendus) ja kettale (iga WAL-segmendi lugemine arhiivist ja tihendatud segmentide kirjutamine), nii et kui süsteem töötab maksimaalse võimsusega, põhjustab see ka jõudluse halvenemist.
Kuidas lubada ja konfigureerida
Atribuuti kasutades saate lubada WAL-i tihendamise WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Samuti saate meetodi DataStorageConfiguration.setWalCompactionLevel() abil määrata tihendustaseme, kui te ei ole vaikeväärtusega (BEST_SPEED) rahul.
WAL-lehe hetktõmmise tihendamine
Kuidas see töötab
Oleme juba avastanud, et WAL-is jagunevad kirjed loogilisteks ja füüsilisteks. Iga lehe muudatuse jaoks luuakse lehe mällu füüsiline WAL-kirje. Füüsilised kirjed jagunevad omakorda samuti 2 alamtüüpi: lehe hetktõmmise kirje ja deltakirje. Iga kord, kui muudame lehel midagi ja viime selle puhtast olekust määrdunud olekusse, salvestatakse selle lehe täielik koopia WAL-i (lehe hetktõmmise kirje). Isegi kui muutsime WAL-is ainult ühte baiti, on kirje lehe suurusest veidi suurem. Kui muudame midagi niigi määrdunud lehel, moodustatakse WAL-is deltakirje, mis kajastab ainult lehe eelmise olekuga võrreldes tehtud muudatusi, kuid mitte kogu lehte. Kuna lehtede oleku lähtestamine määrdunud olekust puhtaks toimub kontrollpunkti protsessi käigus, siis kohe pärast kontrollpunkti algust koosnevad peaaegu kõik füüsilised kirjed ainult lehtede hetktõmmistest (kuna kõik lehed vahetult pärast kontrollpunkti algust on puhtad) , siis kui läheneme järgmisele kontrollpunktile, hakkab delta kirje murdosa järgmise kontrollpunkti alguses kasvama ja uuesti lähtestama. Mõnede sünteetiliste testide mõõtmised näitasid, et lehtede hetktõmmiste osakaal füüsiliste kirjete kogumahust ulatub 90%-ni.
WAL-i lehe hetktõmmiste tihendamise idee seisneb lehtede hetktõmmiste tihendamises valmis lehe tihendamise tööriista abil (vt kettalehe tihendamine). Samal ajal salvestatakse WAL-is kirjed järjestikku ainult lisamisrežiimis ja kirjeid pole vaja siduda failisüsteemi plokkide piiridega, seega pole siin erinevalt kettalehe tihendamise mehhanismist vaja hõredaid faile kõik; vastavalt sellele ei tööta see mehhanism mitte ainult OS Linuxis. Lisaks pole meie jaoks enam oluline, kui palju saime lehte tihendada. Isegi kui vabastasime 1 baidi, on see juba positiivne tulemus ja me saame tihendatud andmeid salvestada WAL-i, erinevalt kettalehe tihendamisest, kus salvestame tihendatud lehe ainult siis, kui vabastasime rohkem kui 1 failisüsteemi ploki.
Lehed on väga tihendatavad andmed, nende osakaal WAL-i kogumahus on väga suur, nii et ilma WAL-failivormingut muutmata saame selle suurust oluliselt vähendada. Pakkimine, sealhulgas loogilised kirjed, nõuaks vormingu muutmist ja ühilduvuse kadumist, näiteks välistarbijate jaoks, kes võivad olla huvitatud loogilistest kirjetest, kuid see ei tooks kaasa faili suuruse märkimisväärset vähenemist.
Nagu kettalehtede tihendamise puhul, saab ka WAL-lehe hetktõmmise tihendamisel kasutada ZSTD, LZ4, Snappy tihendusalgoritme ja ka režiimi SKIP_GARBAGE.
Mõju jõudlusele
Pole raske märgata, et WAL-lehe hetktõmmise tihendamise otsene lubamine mõjutab ainult lõime, mis kirjutavad andmeid lehe mällu, st neid lõime, mis muudavad vahemälu andmeid. Füüsiliste kirjete lugemine WAL-ist toimub ainult üks kord, hetkel tõstetakse sõlm pärast kukkumist (ja ainult siis, kui see langeb kontrollpunkti ajal).
See mõjutab lõime, mis muudavad andmeid järgmiselt: saame negatiivse efekti (CPU), mis tuleneb vajadusest leht iga kord enne kettale kirjutamist tihendada, ja positiivse efekti (ketta IO), mis tuleneb ketta mahu vähenemisest. andmed kirjutatud. Sellest lähtuvalt on siin kõik lihtne: kui süsteemi jõudlust piirab protsessor, saame väikese halvenemise, kui seda piirab ketta sisend/väljund, saame tõusu.
Kaudselt mõjutab WAL-i suuruse vähendamine (positiivselt) ka vooge, mis viivad WAL-i segmendid arhiivi ja WAL-i tihendusvoogudesse.
Sünteetilisi andmeid kasutanud reaalsed jõudlustestid meie keskkonnas näitasid kerget tõusu (läbilaskvus suurenes 10%-15%, latentsus vähenes 10%-15%).
Kuidas lubada ja konfigureerida
Minimaalne Apache Ignite'i versioon: 2.8. Lubage ja konfigureerige järgmiselt.
- Klassiteel peab olema süüte tihendamise moodul. Vaikimisi asub see Apache Ignite'i distributsioonis libs/optional kataloogis ega sisaldu klassiteel. Saate kataloogi lihtsalt ühe taseme võrra kõrgemale liigutada libsidesse ja kui käivitate selle saidi ignite.sh kaudu, lubatakse see automaatselt.
- Püsivus peab olema lubatud (Lubatud kaudu
DataRegionConfiguration.setPersistenceEnabled(true)). - Tihendusrežiim tuleb seadistada meetodi abil
DataStorageConfiguration.setWalPageCompression(), pakkimine on vaikimisi keelatud (DISABLED režiim). - Soovi korral saate meetodi abil määrata tihendustaseme
DataStorageConfiguration.setWalPageCompression(), vaadake iga režiimi jaoks kehtivate väärtuste meetodi javadocist.
Järeldus
Vaatlusaluseid andmete tihendamise mehhanisme Apache Ignite'is saab kasutada üksteisest sõltumatult, kuid vastuvõetav on ka nende mis tahes kombinatsioon. Nende toimimise mõistmine võimaldab teil kindlaks teha, kui sobivad need teie keskkonnas teie ülesannete täitmiseks ja mida peate nende kasutamisel ohverdama. Kettalehe tihendamine on loodud põhimälu tihendamiseks ja võib anda keskmise tihendusastme. WAL-lehe hetktõmmise tihendamine annab WAL-failidele keskmise tihendusastme ja suure tõenäosusega isegi parandab jõudlust. WAL-i tihendamine ei avalda jõudlusele positiivset mõju, kuid vähendab füüsiliste kirjete eemaldamise kaudu WAL-failide suurust nii palju kui võimalik.
Allikas: www.habr.com