Компресија података у Апацхе Игните-у. Сберово искуство

Када радите са великим количинама података, понекад се може појавити проблем недостатка простора на диску. Један од начина да се реши овај проблем је компресија, захваљујући којој, на истој опреми, можете себи приуштити повећање запремине складиштења. У овом чланку ћемо погледати како компресија података функционише у Апацхе Игните-у. Овај чланак ће описати само методе компресије диска примењене у оквиру производа. Друге методе компресије података (преко мреже, у меморији), без обзира да ли су примењене или не, остаће ван опсега.

Дакле, са укљученим режимом постојаности, као резултат промена у подацима у кеш меморији, Игните почиње да пише на диск:

1. Садржај кеша
2. Врите Ахеад Лог (у даљем тексту једноставно ВАЛ)

Већ неко време постоји механизам за ВАЛ компресију, који се зове ВАЛ сабијање. Недавно објављени Апацхе Игните 2.8 увео је још два механизма који вам омогућавају да компримујете податке на диску: компресију странице на диску за компримовање садржаја кеша и компресију снимака ВАЛ страница за компримовање неких ВАЛ уноса. Више детаља о сва три ова механизма у наставку.

Компресија странице на диску

Како ово ради

Прво, хајде да укратко погледамо како Игните чува податке. Меморија страница се користи за складиштење. Величина странице је постављена на почетку чвора и не може се мењати у каснијим фазама; такође, величина странице мора бити степен два и вишеструка величина блока система датотека. Странице се учитавају у РАМ са диска по потреби; величина података на диску може премашити количину додељене РАМ меморије. Ако у РАМ-у нема довољно простора за учитавање странице са диска, старе странице које се више не користе биће избачене из РАМ-а.

Подаци се чувају на диску у следећем облику: засебна датотека се креира за сваку партицију сваке групе кеша; у овој датотеци странице се појављују једна за другом у растућем индексном редоследу. Идентификатор целе странице садржи идентификатор кеш групе, број партиције и индекс странице у датотеци. Дакле, користећи идентификатор целе странице, можемо јединствено одредити датотеку и помак у датотеци за сваку страницу. Можете прочитати више о меморији страничне меморије у чланку Апацхе Игните Вики: Игните Персистент Сторе - испод хаубе.

Механизам компресије странице на диску, као што можете претпоставити из имена, ради на нивоу странице. Када је овај механизам омогућен, подаци у РАМ меморији се обрађују као што јесу, без икакве компресије, али када се странице сачувају из РАМ-а на диск, оне се компресују.

Али компресовање сваке странице појединачно није решење за проблем; морате некако да смањите величину резултујућих датотека са подацима. Ако величина странице више није фиксна, више не можемо писати странице у датотеку једну за другом, јер то може створити бројне проблеме:

• Користећи индекс странице, нећемо моћи да израчунамо помак по којем се налази у датотеци.
• Није јасно шта радити са страницама које нису на крају датотеке и мењају њихову величину. Ако се величина странице смањи, простор који је ослободио нестаје. Ако се величина странице повећа, потребно је да за њу потражите ново место у датотеци.
• Ако се страница помера за број бајтова који није вишеструки од величине блока система датотека, тада ће за читање или писање захтевати додиривање још једног блока система датотека, што може довести до деградације перформанси.

Да би се избегло решавање ових проблема на сопственом нивоу, компресија странице диска у Апацхе Игните-у користи механизам система датотека који се зове ретке датотеке. Ретка датотека је она у којој се неки региони испуњени нулом могу означити као „рупе“. У овом случају, блокови система датотека неће бити додељени за складиштење ових рупа, што ће резултирати уштедом простора на диску.

Логично је да да би се ослободио блок система датотека, величина рупе мора бити већа или једнака блоку система датотека, што намеће додатно ограничење на величину странице и Апацхе Игните: да би компресија имала било какав ефекат, величина странице мора бити стриктно већа од величине блока система датотека. Ако је величина странице једнака величини блока, онда никада нећемо моћи да ослободимо један блок, јер да би се ослободио један блок, компримована страница мора да заузме 0 бајтова. Ако је величина странице једнака величини 2 или 4 блока, већ ћемо моћи да ослободимо бар један блок ако је наша страница компримована на најмање 50%, односно 75%.

Дакле, коначни опис како механизам функционише: Приликом писања странице на диск, покушава се компресовати страница. Ако величина компресоване странице дозвољава ослобађање једног или више блокова система датотека, тада се страница пише у компримованом облику, а на месту ослобођених блокова се прави „рупа“ (извршава се системски позив fallocate() са заставицом за бушење). Ако величина компресоване странице не дозвољава да се блокови ослободе, страница се чува каква јесте, некомпримована. Сви помаци странице се израчунавају на исти начин као и без компресије, множењем индекса странице са величином странице. Није потребно премештање страница на своју руку. Померања страница, баш као и без компресије, падају на границе блокова система датотека.

У тренутној имплементацији, Игните може да ради само са ретким датотекама под Линук ОС-ом; сходно томе, компресија странице на диску може бити омогућена само када се користи Игните на овом оперативном систему.

Алгоритми компресије који се могу користити за компресију страница на диску: ЗСТД, ЛЗ4, Снаппи. Поред тога, постоји режим рада (СКИП_ГАРБАГЕ), у коме се само неискоришћени простор на страници избацује без примене компресије на преостале податке, што смањује оптерећење ЦПУ-а у поређењу са претходно наведеним алгоритмима.

Утицај на перформансе

Нажалост, нисам спровео стварна мерења перформанси на стварним трибинама, јер не планирамо да користимо овај механизам у производњи, али теоретски можемо да спекулишемо где ћемо изгубити, а где победити.

Да бисмо то урадили, морамо запамтити како се странице читају и пишу када им се приступа:

• Када се изврши операција читања, она се прво претражује у РАМ-у; ако је претрага неуспешна, страница се учитава у РАМ са диска од стране исте нити која обавља читање.
• Када се изврши операција писања, страница у РАМ-у је означена као прљава, али страница није физички сачувана на диск одмах од стране нити која врши упис. Све прљаве странице се чувају на диску касније у процесу контролне тачке у одвојеним нитима.

Дакле, утицај на операције читања је:

• Позитивно (ДИСК ИО), због смањења броја читаних блокова система датотека.
• Негативно (ЦПУ), због додатног оптерећења потребног оперативном систему за рад са ретким датотекама. Такође је могуће да ће се додатне ИО операције имплицитно појавити овде да би се сачувала сложенија ретка структура датотека (нажалост, нисам упознат са свим детаљима о томе како ретке датотеке функционишу).
• Негативно (ЦПУ), због потребе за декомпресијом страница.
• Нема утицаја на операције писања.
• Утицај на процес контролне тачке (овде је све слично операцијама читања):
• Позитивно (ДИСК ИО), због смањења броја уписаних блокова система датотека.
• Негативно (ЦПУ, могуће диск ИО), због рада са ретким датотекама.
• Негативно (ЦПУ), због потребе за компресијом странице.

Која страна скале ће преокренути вагу? Све ово у великој мери зависи од окружења, али сам склон да верујем да ће компресија странице на диску највероватније довести до деградације перформанси на већини система. Штавише, тестови на другим ДБМС-овима који користе сличан приступ са ретким датотекама показују пад перформанси када је компресија омогућена.

Како омогућити и конфигурисати

Као што је горе поменуто, минимална верзија Апацхе Игните-а која подржава компресију страница на диску је 2.8 и подржан је само Линук оперативни систем. Омогућите и конфигуришите на следећи начин:

• Мора постојати модул компресије паљења у путањи класе. Подразумевано се налази у Апацхе Игните дистрибуцији у либс/опционом директоријуму и није укључена у путању класе. Можете једноставно да померите директоријум за један ниво навише у либс и онда када га покренете кроз игните.сх он ће бити аутоматски омогућен.
• Постојаност мора бити омогућена (Омогућено преко DataRegionConfiguration.setPersistenceEnabled(true)).
• Величина странице мора бити већа од величине блока система датотека (можете је поставити помоћу DataStorageConfiguration.setPageSize() ).
• За сваки кеш чији подаци треба да се компримују, морате да конфигуришете метод компресије и (опционо) ниво компресије (методе CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

ВАЛ сабијање

Како ово ради

Шта је ВАЛ и зашто је потребан? Врло кратко: ово је дневник који садржи све догађаје који на крају мењају складиштење странице. Потребан је првенствено да би се могао опоравити у случају пада. Свака операција, пре него што кориснику да контролу, мора прво да забележи догађај у ВАЛ-у, како би се у случају неуспеха могла репродуковати у дневнику и вратити све операције за које је корисник добио успешан одговор, чак и ако су ове операције није имао времена да се одрази на складиште страница на диску (већ горе је описано да се стварно уписивање у складиште страница врши у процесу који се назива „контролна тачка“ са извесним кашњењем од стране одвојених нити).

Уноси у ВАЛ-у се деле на логичке и физичке. Булове вредности су сами кључеви и вредности. Физички – одражава промене на страницама у продавници страница. Док логички записи могу бити корисни у неким другим случајевима, физички записи су потребни само за опоравак у случају пада, а записи су потребни само од последње успешне контролне тачке. Овде нећемо улазити у детаље и објашњавати зашто то функционише на овај начин, али заинтересовани могу да погледају већ поменути чланак на Апацхе Игните Вики: Игните Персистент Сторе - испод хаубе.

Често постоји неколико физичких записа по логичком запису. То јест, на пример, једна операција стављања у кеш утиче на неколико страница у меморији страница (страница са самим подацима, странице са индексима, странице са слободним листама). У неким синтетичким тестовима открио сам да физички записи заузимају до 90% ВАЛ датотеке. Међутим, они су потребни за веома кратко време (подразумевано, интервал између контролних тачака је 3 минута). Било би логично да се отарасите ових података након што изгубе релевантност. Управо то ради механизам за сабијање ВАЛ-а: ослобађа се физичких записа и компримује преостале логичке записе помоћу зип-а, док је величина датотеке веома значајно смањена (понекад и десетинама пута).

Физички, ВАЛ се састоји од неколико сегмената (10 подразумевано) фиксне величине (подразумевано 64МБ), који се кружно преписују. Чим се тренутни сегмент попуни, следећи сегмент се додељује као текући, а попуњени сегмент се копира у архиву посебном нитом. ВАЛ сабијање већ ради са сегментима архиве. Такође, као посебна нит, прати извршавање контролне тачке и почиње компресију у сегментима архиве за које физички записи више нису потребни.

Утицај на перформансе

Пошто ВАЛ сабијање ради као засебна нит, не би требало да има директног утицаја на операције које се изводе. Али и даље додатно оптерећује ЦПУ (компресија) и диск (читање сваког ВАЛ сегмента из архиве и писање компримованих сегмената), тако да ако систем ради на свом максималном капацитету, то ће такође довести до деградације перформанси.

Како омогућити и конфигурисати

Можете омогућити сабијање ВАЛ-а помоћу својства WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Такође, користећи методу ДатаСторагеЦонфигуратион.сетВалЦомпацтионЛевел(), можете подесити ниво компресије ако нисте задовољни подразумеваном вредношћу (БЕСТ_СПЕЕД).

ВАЛ компресија снимака странице

Како ово ради

Већ смо сазнали да се у ВАЛ записима деле на логичке и физичке. За сваку промену сваке странице, физички ВАЛ запис се генерише у меморији странице. Физички записи се такође деле на 2 подтипа: запис снимака странице и делта запис. Сваки пут када променимо нешто на страници и пребацимо је из чистог у прљаво стање, комплетна копија ове странице се чува у ВАЛ-у (запис снимака странице). Чак и ако променимо само један бајт у ВАЛ-у, запис ће бити нешто већи од величине странице. Ако нешто променимо на већ прљавој страници, у ВАЛ-у се формира делта запис који одражава само промене у поређењу са претходним стањем странице, али не и целу страницу. Пошто се ресетовање стања страница са прљавих на чисте врши током процеса контролне тачке, одмах након почетка контролне тачке, скоро сви физички записи ће се састојати само од снимака страница (пошто су све странице одмах након почетка контролне тачке чисте) , онда како се приближавамо следећој контролној тачки, разломак делта записа почиње да расте и поново се ресетује на почетку следеће контролне тачке. Мерења у неким синтетичким тестовима показала су да удео снимака страница у укупном обиму физичких записа достиже 90%.

Идеја компресије ВАЛ снимака страница је да компримује снимке страница користећи готов алат за компресију страница (погледајте компресију странице на диску). Истовремено, у ВАЛ-у, записи се чувају секвенцијално у режиму само додавања и нема потребе да се записи везују за границе блокова система датотека, тако да овде, за разлику од механизма компресије странице на диску, нису нам потребне ретке датотеке на све; сходно томе, овај механизам ће радити не само на ОС Линук-у. Осим тога, више нам није важно колико смо успели да компримујемо страницу. Чак и ако смо ослободили 1 бајт, ово је већ позитиван резултат и можемо сачувати компримоване податке у ВАЛ-у, за разлику од компресије странице на диску, где чувамо компримовану страницу само ако смо ослободили више од 1 блока система датотека.

Странице су веома компресибилни подаци, њихов удео у укупном обиму ВАЛ-а је веома висок, тако да без промене формата ВАЛ датотеке можемо добити значајно смањење његове величине. Компресија, укључујући логичке записе, захтевала би промену формата и губитак компатибилности, на пример, за спољне кориснике који би могли бити заинтересовани за логичке записе, али не би довело до значајног смањења величине датотеке.

Као и код компресије диск странице, ВАЛ компресија снимака страница може да користи ЗСТД, ЛЗ4, Снаппи алгоритме компресије, као и режим СКИП_ГАРБАГЕ.

Утицај на перформансе

Није тешко приметити да директно омогућавање ВАЛ компресије снимака странице утиче само на нити које уписују податке у меморију странице, односно на оне које мењају податке у кеш меморији. Читање физичких записа из ВАЛ-а се дешава само једном, у тренутку када се чвор подигне након пада (и само ако падне током контролне тачке).

Ово утиче на нити које мењају податке на следећи начин: добијамо негативан ефекат (ЦПУ) због потребе да сваки пут компресујемо страницу пре уписивања на диск и позитиван ефекат (диск ИО) због смањења количине подаци написани. Сходно томе, овде је све једноставно: ако су перформансе система ограничене ЦПУ-ом, добијамо благу деградацију, ако је ограничено И/О диском, добијамо повећање.

Индиректно, смањење величине ВАЛ-а такође утиче (позитивно) на токове који избацују ВАЛ сегменте у архиву и токове сажимања ВАЛ-а.

Тестови стварних перформанси у нашем окружењу коришћењем синтетичких података показали су благи пораст (пропусност повећана за 10%-15%, кашњење је смањено за 10%-15%).

Како омогућити и конфигурисати

Минимална верзија Апацхе Игните: 2.8. Омогућите и конфигуришите на следећи начин:

• Мора постојати модул компресије паљења у путањи класе. Подразумевано се налази у Апацхе Игните дистрибуцији у либс/опционом директоријуму и није укључена у путању класе. Можете једноставно да померите директоријум за један ниво навише у либс и онда када га покренете кроз игните.сх он ће бити аутоматски омогућен.
• Постојаност мора бити омогућена (Омогућено преко DataRegionConfiguration.setPersistenceEnabled(true)).
• Режим компресије се мора подесити помоћу методе DataStorageConfiguration.setWalPageCompression(), компресија је подразумевано онемогућена (ДИСАБЛЕД моде).
• Опционо, можете подесити ниво компресије користећи методу DataStorageConfiguration.setWalPageCompression(), погледајте јавадоц за метод за важеће вредности за сваки режим.

Закључак

Разматрани механизми компресије података у Апацхе Игните-у могу се користити независно један од другог, али је прихватљива и свака њихова комбинација. Разумевање начина на који функционишу ће вам омогућити да утврдите колико су погодни за ваше задатке у вашем окружењу и шта ћете морати да жртвујете када их користите. Компресија странице на диску је дизајнирана да компримује главну меморију и може дати средњи однос компресије. Компресија снимка ВАЛ странице ће дати просечан степен компресије за ВАЛ датотеке, а највероватније ће чак и побољшати перформансе. Збијање ВАЛ-а неће имати позитиван ефекат на перформансе, али ће смањити величину ВАЛ датотека што је више могуће уклањањем физичких записа.

Извор: ввв.хабр.цом