Gagnaþjöppun í Apache Ignite. Reynsla Sber

Þegar unnið er með mikið magn af gögnum getur stundum komið upp vandamál vegna skorts á plássi. Ein leið til að leysa þetta vandamál er þjöppun, þökk sé henni, á sama búnaði, hefur þú efni á að auka geymslumagn. Í þessari grein munum við skoða hvernig gagnaþjöppun virkar í Apache Ignite. Þessi grein mun aðeins lýsa diskþjöppunaraðferðum sem innleiddar eru í vörunni. Aðrar aðferðir við gagnaþjöppun (í gegnum netið, í minni), hvort sem þær eru framkvæmdar eða ekki, verða áfram utan gildissviðs.

Svo, með þrautseigju virka, vegna breytinga á gögnum í skyndiminni, byrjar Ignite að skrifa á diskinn:

1. Innihald skyndiminni
2. Write Ahead Log (hér eftir einfaldlega WAL)

Það hefur verið kerfi fyrir WAL þjöppun í nokkuð langan tíma núna, sem kallast WAL þjöppun. Nýlega útgefin Apache Ignite 2.8 kynnti tvö kerfi til viðbótar sem gerir þér kleift að þjappa gögnum á disk: þjöppun á disksíðu til að þjappa innihaldi skyndiminni og þjöppun WAL síðu skyndimynd til að þjappa sumum WAL færslum. Nánari upplýsingar um allar þrjár þessar aðferðir hér að neðan.

Þjöppun á disksíðu

Hvernig virkar þetta

Fyrst skulum við skoða mjög stuttlega hvernig Ignite geymir gögn. Síðuminni er notað til geymslu. Síðustærðin er stillt í byrjun hnútsins og ekki er hægt að breyta henni á síðari stigum; einnig verður síðustærðin að vera tvö veldi og margfeldi af blokkastærð skráarkerfisins. Síðum er hlaðið inn í vinnsluminni af diski eftir þörfum; stærð gagna á diski getur farið yfir magn úthlutaðs vinnsluminni. Ef það er ekki nóg pláss í vinnsluminni til að hlaða síðu af diski, verða gamlar síður sem ekki eru lengur notaðar fjarlægðar úr vinnsluminni.

Gögnin eru geymd á diski á eftirfarandi formi: Sérstök skrá er búin til fyrir hverja skiptingu hvers skyndiminnihóps; í þessari skrá birtast síður hver á eftir annarri í hækkandi skráarröð. Heildarsíðuauðkenni inniheldur skyndiminnishópaauðkenni, skiptingarnúmer og síðuvísitölu í skránni. Þannig, með því að nota heilsíðuauðkennið, getum við ákvarðað skrána á einstakan hátt og frávikið í skránni fyrir hverja síðu. Þú getur lesið meira um síðuminnið í Apache Ignite Wiki greininni: Ignite Persistent Store - undir húddinu.

Þjöppunarbúnaður fyrir disksíðu, eins og þú gætir giska á út frá nafninu, virkar á síðustigi. Þegar þetta kerfi er virkt eru gögn í vinnsluminni unnin eins og þau eru, án nokkurrar þjöppunar, en þegar síður eru vistaðar frá vinnsluminni á disk, eru þær þjappaðar.

En að þjappa hverri síðu fyrir sig er ekki lausn á vandamálinu; þú þarft einhvern veginn að minnka stærð gagnaskránna sem myndast. Ef síðustærðin er ekki lengur föst getum við ekki lengur skrifað síður í skrána hverja af annarri, þar sem þetta getur skapað fjölda vandamála:

• Með því að nota síðuvísitöluna munum við ekki geta reiknað út frávikið sem það er staðsett í skránni.
• Ekki er ljóst hvað á að gera við síður sem eru ekki aftast í skránni og breyta stærð þeirra. Ef síðustærðin minnkar hverfur plássið sem það losaði. Ef síðustærðin stækkar þarftu að leita að nýjum stað í skránni fyrir hana.
• Ef síða færist um fjölda bæta sem er ekki margfeldi af stærð skráarkerfisblokkarinnar, þá þarf að snerta einn skráarkerfisreit til viðbótar við lestur eða ritun, sem getur leitt til skerðingar á frammistöðu.

Til að forðast að leysa þessi vandamál á eigin stigi, notar þjöppun diskasíðu í Apache Ignite skráarkerfiskerfi sem kallast dreifðar skrár. Dreifð skrá er skrá þar sem hægt er að merkja sum núllfyllt svæði sem "göt". Í þessu tilviki verður engum skráarkerfisblokkum úthlutað til að geyma þessar holur, sem leiðir til sparnaðar á diskplássi.

Það er rökrétt að til að losa skráarkerfisblokk þarf stærð gatsins að vera stærri en eða jöfn skráarkerfisblokkinni, sem setur viðbótartakmörkun á síðustærð og Apache Ignite: til að þjöppun hafi einhver áhrif, síðustærðin verður að vera stranglega stærri en stærð skráakerfisblokkarinnar. Ef síðustærðin er jöfn blokkastærðinni, þá munum við aldrei geta losað einn blokk, þar sem til að losa einn blokk verður þjappað síðan að taka 0 bæti. Ef síðustærðin er jöfn stærðinni 2 eða 4 blokkir, munum við nú þegar geta losað að minnsta kosti einn blokk ef síðunni okkar er þjappað niður í að minnsta kosti 50% eða 75%, í sömu röð.

Þannig er endanleg lýsing á því hvernig vélbúnaðurinn virkar: Þegar síðu er skrifað á disk er reynt að þjappa síðunni saman. Ef stærð þjöppuðu síðunnar gerir kleift að losa einn eða fleiri skráarkerfisblokkir, þá er síðan skrifuð í þjöppuðu formi og "gat" er gert í stað losuðu blokkanna (kerfiskall er keyrt fallocate() með kýla holu fánanum). Ef stærð þjöppuðu síðunnar gerir ekki kleift að losa blokkina er síðan vistuð eins og hún er, óþjappuð. Allar hliðarfærslur eru reiknaðar á sama hátt og án þjöppunar, með því að margfalda síðuvísitöluna með síðustærðinni. Enginn flutningur á síðum er nauðsynlegur á eigin spýtur. Síðujöfnun, rétt eins og án þjöppunar, falla á mörk skráarkerfisblokka.

Í núverandi útfærslu getur Ignite aðeins unnið með dreifðar skrár undir Linux OS; í samræmi við það er aðeins hægt að virkja þjöppun á disksíðu þegar Ignite er notað á þessu stýrikerfi.

Þjöppunaralgrím sem hægt er að nota fyrir þjöppun á disksíðu: ZSTD, LZ4, Snappy. Að auki er rekstrarhamur (SKIP_GARBAGE), þar sem aðeins ónotuðu plássi á síðunni er hent út án þess að beita þjöppun á gögnin sem eftir eru, sem dregur úr álagi á örgjörvan miðað við áður skráð reiknirit.

Áhrif á árangur

Því miður gerði ég ekki raunverulegar frammistöðumælingar á raunverulegum áhorfendum, þar sem við ætlum ekki að nota þetta kerfi í framleiðslu, en við getum fræðilega velt fyrir okkur hvar við munum tapa og hvar við munum vinna.

Til að gera þetta þurfum við að muna hvernig síður eru lesnar og skrifaðar þegar þær eru opnaðar:

• Þegar lesaðgerð er framkvæmd er fyrst leitað í vinnsluminni; ef leitin tekst ekki er síðan hlaðið inn í vinnsluminni af diski með sama þræði sem framkvæmir lesturinn.
• Þegar skrifaðgerð er framkvæmd er síðan í vinnsluminni merkt sem óhrein, en síðan er ekki líkamlega vistað á disk strax af þráðnum sem framkvæmir ritunina. Allar óhreinar síður eru vistaðar á disk síðar í eftirlitsferlinu í aðskildum þræði.

Þannig að áhrifin á lestraraðgerðir eru:

• Jákvætt (diskur IO), vegna fækkunar á fjölda lesna skráakerfisblokka.
• Neikvætt (CPU), vegna viðbótarálags sem stýrikerfið þarf til að vinna með dreifðar skrár. Það er líka mögulegt að viðbótar IO aðgerðir muni óbeint birtast hér til að vista flóknari dreifðari skráarskipulag (því miður er ég ekki kunnugur öllum smáatriðum um hvernig dreifðar skrár virka).
• Neikvætt (CPU), vegna nauðsyn þess að þjappa síður niður.
• Það hefur engin áhrif á ritunaraðgerðir.
• Áhrif á eftirlitsferlið (allt hér er svipað og lestraraðgerðir):
• Jákvætt (diskur IO), vegna fækkunar á fjölda skrifaðra skráakerfisblokka.
• Neikvætt (CPU, hugsanlega diskur IO), vegna þess að vinna með dreifðar skrár.
• Neikvætt (CPU), vegna þörf fyrir síðuþjöppun.

Hvor hlið kvarðans mun halla á kvarðann? Þetta veltur allt mjög á umhverfinu, en ég hallast að því að þjöppun á disksíðum muni líklega leiða til skerðingar á frammistöðu á flestum kerfum. Þar að auki sýna próf á öðrum DBMS sem nota svipaða nálgun með dreifðum skrám lækkun á frammistöðu þegar þjöppun er virkjuð.

Hvernig á að virkja og stilla

Eins og fyrr segir er lágmarksútgáfan af Apache Ignite sem styður þjöppun diskasíðu 2.8 og aðeins Linux stýrikerfið er stutt. Virkjaðu og stilltu sem hér segir:

• Það verður að vera kveikjuþjöppunareining í bekkjarslóðinni. Sjálfgefið er að það er staðsett í Apache Ignite dreifingunni í libs/valfrjálsu möppunni og er ekki innifalið í class-path. Þú getur einfaldlega fært möppuna upp um eitt stig í libs og svo þegar þú keyrir hana í gegnum ignite.sh verður hún sjálfkrafa virkjuð.
• Viðhald verður að vera virkt (Virkt með DataRegionConfiguration.setPersistenceEnabled(true)).
• Síðustærðin verður að vera stærri en blokkastærð skráakerfisins (þú getur stillt hana með því að nota DataStorageConfiguration.setPageSize() ).
• Fyrir hvert skyndiminni þar sem þarf að þjappa gögnum verður þú að stilla þjöppunaraðferðina og (valfrjálst) þjöppunarstigið (aðferðir CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

WAL þjöppun

Hvernig virkar þetta

Hvað er WAL og hvers vegna er þörf á því? Í stuttu máli: þetta er log sem inniheldur alla atburði sem að lokum breyta geymsluplássinu. Það er fyrst og fremst þörf til að geta jafnað sig ef falli. Sérhver aðgerð, áður en notandanum er stjórnað, verður fyrst að skrá atburð í WAL, þannig að ef bilun kemur upp er hægt að spila hana í skránni og endurheimta allar aðgerðir sem notandinn fékk árangursríkt svar við, jafnvel þótt þessar aðgerðir hafði ekki tíma til að endurspeglast í geymsluplássinu á disknum (þegar hér að ofan. Því hefur verið lýst að raunveruleg ritun í síðugeymsluna fer fram í ferli sem kallast "checkpointing" með nokkurri töf með aðskildum þráðum).

Færslum í WAL er skipt í rökrétt og líkamlegt. Boolean eru lykillinn og gildin sjálf. Líkamlegt - endurspeglar breytingar á síðum í síðuversluninni. Þó að rökréttar færslur geti verið gagnlegar í sumum öðrum tilvikum, eru líkamlegar færslur aðeins nauðsynlegar til að endurheimta ef um hrun er að ræða og skrár eru aðeins nauðsynlegar frá síðasta árangursríka eftirlitsstað. Hér verður ekki farið í smáatriði og útskýrt hvers vegna þetta virkar svona, en áhugasamir geta vísað til áðurnefndrar greinar á Apache Ignite Wiki: Ignite Persistent Store - undir húddinu.

Það eru oft nokkrar líkamlegar skrár á hverja rökrétta skrá. Það er til dæmis að ein aðgerð í skyndiminni hefur áhrif á nokkrar síður í minni síðu (síðu með gögnunum sjálfum, síður með skrám, síður með frjálsum listum). Í sumum tilbúnum prófum fann ég að líkamlegar skrár tóku allt að 90% af WAL skránni. Hins vegar er þörf á þeim í mjög stuttan tíma (sjálfgefið er bil á milli eftirlitsstöðva 3 mínútur). Það væri rökrétt að losa sig við þessi gögn eftir að hafa misst mikilvægi þeirra. Þetta er nákvæmlega það sem WAL þjöppunarbúnaðurinn gerir: hann losar sig við líkamlegar færslur og þjappar saman rökréttum færslum sem eftir eru með zip, á meðan skráarstærðin minnkar mjög verulega (stundum tugum sinnum).

Líkamlega samanstendur WAL af nokkrum hlutum (10 sjálfgefið) af fastri stærð (64MB sjálfgefið), sem er skrifað yfir á hringlaga hátt. Um leið og núverandi hluti er fylltur er næsta hluta úthlutað sem núverandi og fyllti hluti er afritaður í skjalasafnið með sérstökum þræði. WAL þjöppun vinnur nú þegar með skjalasafnshlutum. Einnig, sem sérstakur þráður, fylgist það með framkvæmd eftirlitsstaðarins og byrjar þjöppun í skjalasafnshlutum sem ekki er lengur þörf á líkamlegum gögnum fyrir.

Áhrif á árangur

Þar sem WAL þjöppun gengur sem sérstakur þráður ætti ekki að hafa bein áhrif á aðgerðirnar sem eru framkvæmdar. En það setur samt aukið bakgrunnsálag á CPU (þjöppun) og disk (les hvern WAL hluta úr skjalasafninu og skrifar þjappaða hlutana), þannig að ef kerfið keyrir á hámarksgetu mun það einnig leiða til skerðingar á afköstum.

Hvernig á að virkja og stilla

Þú getur virkjað WAL þjöppun með því að nota eignina WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Einnig, með því að nota DataStorageConfiguration.setWalCompactionLevel() aðferðina, geturðu stillt þjöppunarstigið ef þú ert ekki ánægður með sjálfgefið gildi (BEST_SPEED).

WAL síðu skyndimynd þjöppun

Hvernig virkar þetta

Við höfum þegar komist að því að í WAL er færslum skipt í rökrétt og líkamlegt. Fyrir hverja breytingu á hverri síðu er líkamleg WAL-skrá búin til í síðuminni. Líkamlegum gögnum er aftur á móti einnig skipt í 2 undirgerðir: blaðsíðumyndaskrá og deltaskráningu. Í hvert skipti sem við breytum einhverju á síðu og flytjum það úr hreinu ástandi í óhreint ástand er heilt afrit af þessari síðu geymt í WAL (page snapshot record). Jafnvel þótt við breyttum aðeins einu bæti í WAL, verður skráin aðeins stærri en síðustærðin. Ef við breytum einhverju á þegar óhreinum síðu, myndast deltaskrá í WAL, sem endurspeglar aðeins breytingar miðað við fyrri stöðu síðunnar, en ekki alla síðuna. Þar sem að endurstilla ástand síðna úr óhreinum í hreint er framkvæmt meðan á eftirlitsstöðinni stendur, strax eftir að eftirlitsstöðin hefst, munu næstum allar líkamlegar færslur aðeins samanstanda af skyndimyndum af síðum (þar sem allar síður strax eftir upphaf eftirlitsstöðvar eru hreinar) , síðan þegar við nálgumst næsta eftirlitspunkt, byrjar deltaskráningarhlutfallið að vaxa og endurstillast aftur í upphafi næsta eftirlitsstaðar. Mælingar í sumum tilbúnum prófum sýndu að hlutdeild skyndimynda síðu í heildarmagni líkamlegra skráa nær 90%.

Hugmyndin um þjöppun WAL síðumynda er að þjappa blaðsíðumyndum með því að nota tilbúið síðuþjöppunartól (sjá þjöppun disksíðu). Á sama tíma, í WAL, eru færslur vistaðar í röð í „append-only“ ham og það er engin þörf á að binda færslur við mörk skráakerfisblokka, þannig að hér, ólíkt disksíðuþjöppunarbúnaðinum, þurfum við ekki dreifðar skrár á allt; í samræmi við það mun þetta kerfi virka ekki aðeins á OS Linux. Þar að auki skiptir okkur ekki lengur máli hversu mikið við gátum þjappað síðunni saman. Jafnvel þótt við losuðum 1 bæti, þá er þetta nú þegar jákvæð niðurstaða og við getum vistað þjöppuð gögn í WAL, ólíkt þjöppun disksíðu, þar sem við vistum þjöppuðu síðuna aðeins ef við losuðum meira en 1 skráarkerfisblokk.

Síður eru mjög samþjöppanleg gögn, hlutdeild þeirra í heildarmagni WAL er mjög mikil, þannig að án þess að breyta WAL skráarsniðinu getum við dregið verulega úr stærð þess. Þjöppun, þ.mt rökréttar færslur, myndi krefjast breytinga á sniði og taps á eindrægni, til dæmis fyrir utanaðkomandi neytendur sem gætu haft áhuga á rökréttum færslum, en myndi ekki leiða til verulegrar minnkunar á skráarstærð.

Eins og með þjöppun á disksíðu, getur WAL síðu skyndimyndaþjöppun notað ZSTD, LZ4, Snappy þjöppunaralgrím, sem og SKIP_GARBAGE ham.

Áhrif á árangur

Það er ekki erfitt að taka eftir því að það að virkja beint WAL síðu skyndimyndaþjöppun hefur aðeins áhrif á þræði sem skrifa gögn í síðuminni, það er þá þræði sem breyta gögnum í skyndiminni. Lestur líkamlegra skráa frá WAL á sér stað aðeins einu sinni, á því augnabliki sem hnúturinn er hækkaður eftir fall (og aðeins ef hann fellur á eftirlitsstöð).

Þetta hefur áhrif á þræði sem breyta gögnum á eftirfarandi hátt: við fáum neikvæð áhrif (CPU) vegna þess að þurfa að þjappa síðunni í hvert skipti áður en þú skrifar á disk, og jákvæð áhrif (diskur IO) vegna minnkunar á magni af gögn skrifuð. Í samræmi við það er allt einfalt hér: ef afköst kerfisins eru takmörkuð af örgjörvanum fáum við smá niðurbrot, ef það er takmarkað af diski I/O fáum við aukningu.

Óbeint hefur minnkun WAL-stærð einnig áhrif á (jákvæð) strauma sem dumpa WAL-hlutum í skjalasafnið og WAL-þjöppunarstrauma.

Raunframmistöðupróf í umhverfi okkar með tilbúnum gögnum sýndu lítilsháttar aukningu (afköst jókst um 10%-15%, leynd minnkaði um 10%-15%).

Hvernig á að virkja og stilla

Lágmarks Apache Ignite útgáfa: 2.8. Virkjaðu og stilltu sem hér segir:

• Það verður að vera kveikjuþjöppunareining í bekkjarslóðinni. Sjálfgefið er að það er staðsett í Apache Ignite dreifingunni í libs/valfrjálsu möppunni og er ekki innifalið í class-path. Þú getur einfaldlega fært möppuna upp um eitt stig í libs og svo þegar þú keyrir hana í gegnum ignite.sh verður hún sjálfkrafa virkjuð.
• Viðhald verður að vera virkt (Virkt með DataRegionConfiguration.setPersistenceEnabled(true)).
• Stilla verður þjöppunarhaminn með aðferðinni DataStorageConfiguration.setWalPageCompression(), þjöppun er sjálfgefið óvirk (Óvirkjað stilling).
• Valfrjálst geturðu stillt þjöppunarstigið með aðferðinni DataStorageConfiguration.setWalPageCompression(), sjá javadoc fyrir aðferðina fyrir gild gildi fyrir hverja stillingu.

Ályktun

Hægt er að nota yfirvegaða gagnaþjöppunarkerfi í Apache Ignite óháð hvort öðru, en hvaða samsetning þeirra er einnig ásættanleg. Að skilja hvernig þau virka mun gera þér kleift að ákvarða hversu hentug þau eru fyrir verkefni þín í umhverfi þínu og hverju þú þarft að fórna þegar þú notar þau. Disksíðuþjöppun er hönnuð til að þjappa aðalgeymslunni og getur gefið miðlungs þjöppunarhlutfall. Skyndimyndaþjöppun WAL síðu mun gefa meðalþjöppun fyrir WAL skrár og mun líklegast jafnvel bæta árangur. WAL þjöppun mun ekki hafa jákvæð áhrif á afköst, en mun minnka stærð WAL skráa eins mikið og mögulegt er með því að fjarlægja líkamlegar skrár.

Heimild: www.habr.com