Компресија на податоци во Apache Ignite. Искуството на Сбер

Кога работите со големи количини на податоци, понекогаш може да се појави проблем со недостаток на простор на дискот. Еден начин да се реши овој проблем е компресија, благодарение на што, на истата опрема, можете да си дозволите да го зголемите обемот на складирање. Во оваа статија, ќе погледнеме како функционира компресија на податоци во Apache Ignite. Оваа статија ќе ги опише само методите за компресија на дискот имплементирани во производот. Други методи за компресија на податоци (преку мрежа, во меморија), без разлика дали се имплементирани или не, ќе останат надвор од опсегот.

Значи, со вклучен режим на упорност, како резултат на промените во податоците во кешот, Ignite започнува да пишува на дискот:

1. Содржина на кешот
2. Напиши евиденција однапред (во натамошниот текст едноставно WAL)

Веќе подолго време постои механизам за WAL компресија, наречен WAL набивање. Неодамна објавениот Apache Ignite 2.8 воведе уште два механизми кои ви дозволуваат да ги компресирате податоците на дискот: компресија на страницата на дискот за компресирање на содржината на кешот и компресија на слика од страницата WAL за компресирање на некои WAL записи. Повеќе детали за сите три од овие механизми подолу.

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

Како го прави ова дело

Прво, ајде да погледнеме многу краток како Ignite складира податоци. Меморијата на страниците се користи за складирање. Големината на страницата е поставена на почетокот на јазолот и не може да се менува во подоцнежните фази; исто така, големината на страницата мора да биде моќност од два и повеќекратна од големината на блокот на датотечниот систем. Страниците се вчитуваат во RAM од дискот по потреба; големината на податоците на дискот може да ја надмине количината на доделената RAM меморија. Ако нема доволно простор во RAM меморијата за да се вчита страница од дискот, старите, веќе не користените страници ќе бидат исфрлени од RAM меморијата.

Податоците се складираат на дискот во следнава форма: се создава посебна датотека за секоја партиција на секоја кеш група; во оваа датотека, страниците се појавуваат една по друга во растечки редослед на индекси. Идентификаторот на целосната страница содржи идентификатор на кеш групата, број на партиција и индекс на страница во датотеката. Така, користејќи го идентификаторот на целосната страница, можеме уникатно да ја одредиме датотеката и поместувањето во датотеката за секоја страница. Можете да прочитате повеќе за меморијата за страничење во статијата Apache Ignite Wiki: Ignite Persistent Store - под хаубата.

Механизмот за компресија на страницата на дискот, како што може да претпоставите од името, работи на ниво на страница. Кога овој механизам е овозможен, податоците во RAM меморијата се обработуваат како што се, без никаква компресија, но кога страниците се зачувуваат од RAM меморија на диск, тие се компресирани.

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

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

За да избегнете решавање на овие проблеми на свое ниво, компресијата на страницата на дискот во Apache Ignite користи механизам на датотечен систем наречен ретки датотеки. Ретка датотека е онаа во која некои региони исполнети со нула може да се означат како „дупки“. Во овој случај, нема да се доделат блокови на датотечниот систем за складирање на овие дупки, што резултира со заштеда на простор на дискот.

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

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

Во тековната имплементација, Ignite може да работи само со ретки датотеки под Linux OS; соодветно, компресијата на страницата на дискот може да се овозможи само кога се користи Ignite на овој оперативен систем.

Алгоритми за компресија што може да се користат за компресија на страници на дискот: ZSTD, LZ4, Snappy. Дополнително, постои режим на работа (SKIP_GARBAGE), во кој само неискористениот простор на страницата се исфрла без да се примени компресија на преостанатите податоци, што го намалува оптоварувањето на процесорот во споредба со претходно наведените алгоритми.

Влијание врз перформансите

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

За да го направите ова, треба да запомниме како страниците се читаат и пишуваат кога се пристапува:

• При извршување на операцијата за читање, прво се пребарува во RAM меморијата; ако пребарувањето е неуспешно, страницата се вчитува во RAM меморијата од дискот преку истата нишка што го врши читањето.
• Кога се извршува операција за запишување, страницата во RAM меморијата е означена како валкана, но страницата не е физички зачувана на дискот веднаш од нишката што го извршува запишувањето. Сите валкани страници се зачувуваат на дискот подоцна во процесот на контролната точка во посебни нишки.

Значи, влијанието врз операциите за читање е:

• Позитивен (диск IO), поради намалување на бројот на прочитани блокови на датотечниот систем.
• Негативно (процесорот), поради дополнителното оптоварување што го бара оперативниот систем за работа со ретки датотеки. Исто така, можно е тука имплицитно да се појават дополнителни операции за IO за да се зачува посложена структура на ретки датотеки (за жал, не сум запознаен со сите детали за тоа како функционираат ретки датотеки).
• Негативен (процесор), поради потребата за декомпресија на страници.
• Нема влијание врз операциите за запишување.
• Влијание врз процесот на контролниот пункт (сè овде е слично на операциите за читање):
• Позитивен (диск IO), поради намалување на бројот на пишани блокови на датотечен систем.
• Негативно (процесорот, можеби IO на дискот), поради работа со ретки датотеки.
• Негативен (процесор), поради потребата за компресија на страницата.

Која страна на вагата ќе ја преврти вагата? Сето ова многу зависи од околината, но јас сум склон да верувам дека компресијата на страницата на дискот најверојатно ќе доведе до деградација на перформансите на повеќето системи. Покрај тоа, тестовите на други DBMS кои користат сличен пристап со ретки датотеки покажуваат пад на перформансите кога е овозможена компресија.

Како да овозможите и конфигурирате

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

• Мора да има модул за компресија на запалување во класната патека. Стандардно, тој се наоѓа во дистрибуцијата Apache Ignite во директориумот libs/опционален и не е вклучен во патеката за класа. Можете едноставно да го преместите директориумот едно ниво нагоре на libs, а потоа кога ќе го извршите преку ignite.sh тој автоматски ќе биде овозможен.
• Упорноста мора да биде овозможена (Овозможено преку DataRegionConfiguration.setPersistenceEnabled(true)).
• Големината на страницата мора да биде поголема од големината на блокот на датотечниот систем (можете да ја поставите користејќи DataStorageConfiguration.setPageSize() ).
• За секој кеш чии податоци треба да се компресираат, мора да го конфигурирате методот на компресија и (опционално) нивото на компресија (методи CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

WAL набивање

Како го прави ова дело

Што е WAL и зошто е потребно? Многу кратко: ова е дневник кој ги содржи сите настани што на крајот го менуваат складирањето на страницата. Потребно е првенствено за да може да се опорави во случај на пад. Секоја операција, пред да му даде контрола на корисникот, мора прво да сними настан во WAL, така што во случај на неуспех, да може да се репродуцира во дневникот и да се обноват сите операции за кои корисникот добил успешен одговор, дури и ако овие операции немав време да се рефлектира во складирањето на страниците на дискот (веќе погоре Опишано е дека вистинското пишување во продавницата на страници се врши во процес наречен „проверка“ со одредено задоцнување со посебни нишки).

Записите во WAL се поделени на логички и физички. Буловите се самите клучеви и вредности. Физички - ги одразува промените на страниците во продавницата на страници. Додека логичките записи можат да бидат корисни за некои други случаи, физичките записи се потребни само за обновување во случај на несреќа, а записите се потребни само од последната успешна контролна точка. Овде нема да навлегуваме во детали и да објасниме зошто тоа функционира на овој начин, но заинтересираните можат да се повикаат на веќе споменатата статија на Apache Ignite Wiki: Ignite Persistent Store - под хаубата.

Често има неколку физички записи по логички запис. Тоа е, на пример, една операција за ставање во кешот влијае на неколку страници во меморијата на страниците (страница со самите податоци, страници со индекси, страници со слободни списоци). Во некои синтетички тестови, открив дека физичките записи зафаќаат до 90% од датотеката WAL. Сепак, тие се потребни за многу кратко време (стандардно, интервалот помеѓу контролните точки е 3 минути). Би било логично да се ослободите од овие податоци откако ќе ја изгубите нејзината важност. Токму тоа го прави механизмот за набивање WAL: се ослободува од физичките записи и ги компресира преостанатите логички записи користејќи zip, додека големината на датотеката се намалува многу значително (понекогаш и за десетици пати).

Физички, WAL се состои од неколку сегменти (10 стандардно) со фиксна големина (64 MB стандардно), кои се препишани на кружен начин. Штом тековниот сегмент е пополнет, следниот сегмент се доделува како тековен, а пополнетиот сегмент се копира во архивата со посебна нишка. WAL набивањето веќе работи со архивски сегменти. Исто така, како посебна нишка, го следи извршувањето на контролната точка и започнува со компресија во архивските сегменти за кои повеќе не се потребни физички записи.

Влијание врз перформансите

Бидејќи WAL набивањето работи како посебна нишка, не треба да има директно влијание врз операциите што се изведуваат. Но, сепак става дополнително оптоварување во позадина на процесорот (компресија) и дискот (читање на секој сегмент на WAL од архивата и пишување на компресираните сегменти), па ако системот работи со својот максимален капацитет, тоа исто така ќе доведе до деградација на перформансите.

Како да овозможите и конфигурирате

Можете да овозможите WAL набивање користејќи го имотот WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Исто така, користејќи го методот DataStorageConfiguration.setWalCompactionLevel(), можете да го поставите нивото на компресија ако не сте задоволни со стандардната вредност (BEST_SPEED).

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

Како го прави ова дело

Веќе дознавме дека во WAL записите се поделени на логички и физички. За секоја промена на секоја страница, се генерира физички WAL запис во меморијата на страницата. Физичките записи, пак, се исто така поделени на 2 подтипови: запис од снимки од страница и запис од делта. Секој пат кога менуваме нешто на страницата и го префрламе од чиста состојба во валкана состојба, комплетната копија од оваа страница се зачувува во WAL (запис за слика на страницата). Дури и ако сменивме само еден бајт во WAL, записот ќе биде малку поголем од големината на страницата. Ако смениме нешто на веќе валкана страница, во WAL се формира делта запис, кој ги рефлектира само промените во споредба со претходната состојба на страницата, но не и целата страница. Бидејќи ресетирањето на состојбата на страниците од валкани на чисти се врши за време на процесот на контролната точка, веднаш по почетокот на контролната точка, речиси сите физички записи ќе се состојат само од снимки од страници (бидејќи сите страници веднаш по почетокот на контролната точка се чисти) , потоа како што се приближуваме до следниот контролен пункт, делта запис на делта почнува да расте и повторно да се ресетира на почетокот на следната контролна точка. Мерењата на некои синтетички тестови покажаа дека уделот на снимки од страници во вкупниот обем на физички записи достигнува 90%.

Идејата за компресија на снимки од страницата WAL е да се компресираат снимките од страницата со помош на подготвена алатка за компресија на страници (видете компресија на страницата на дискот). Во исто време, во WAL, записите се зачувуваат последователно во режим само за додавање и нема потреба да се врзуваат записите со границите на блоковите на датотечниот систем, така што овде, за разлика од механизмот за компресија на страницата на дискот, не ни требаат ретки датотеки на сите; соодветно, овој механизам ќе работи не само на оперативниот систем Linux. Освен тоа, веќе не ни е важно колку сме успеале да ја компресираме страницата. Дури и да ослободиме 1 бајт, ова е веќе позитивен резултат и можеме да зачуваме компресирани податоци во WAL, за разлика од компресијата на страницата на дискот, каде што ја зачувуваме компресираната страница само ако ослободиме повеќе од 1 блок датотечен систем.

Страниците се многу компресивни податоци, нивниот удел во вкупниот волумен на WAL е многу висок, така што без промена на форматот на датотеката WAL можеме да добиеме значително намалување на неговата големина. Компресијата, вклучително и логичките записи, ќе бара промена во форматот и губење на компатибилноста, на пример, за надворешни потрошувачи кои можеби се заинтересирани за логички записи, но нема да доведе до значително намалување на големината на датотеката.

Како и кај компресијата на страницата на дискот, за компресирањето на снимки од страницата WAL може да се користат алгоритмите за компресија ZSTD, LZ4, Snappy, како и режимот SKIP_GARBAGE.

Влијание врз перформансите

Не е тешко да се забележи дека директното овозможување на WAL компресија на слики од страницата влијае само на нишките што запишуваат податоци во меморијата на страниците, односно на оние нишки што ги менуваат податоците во кешот. Читањето физички записи од WAL се случува само еднаш, во моментот кога јазолот се подига по пад (и само ако падне за време на контролен пункт).

Ова влијае на нишките кои ги менуваат податоците на следниов начин: добиваме негативен ефект (CPU) поради потребата да се компресира страницата секој пат пред да се запише на дискот и позитивен ефект (диск IO) поради намалување на количината на податоци напишани. Според тоа, сè е едноставно овде: ако перформансите на системот се ограничени од процесорот, добиваме мала деградација, ако е ограничена со влез/излез на дискот, добиваме зголемување.

Индиректно, намалувањето на големината на WAL, исто така, влијае (позитивно) на потоци што ги фрлаат сегментите на WAL во архивата и во тековите за набивање на WAL.

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

Како да овозможите и конфигурирате

Минимална верзија на Apache Ignite: 2.8. Овозможете и конфигурирајте на следниов начин:

• Мора да има модул за компресија на запалување во класната патека. Стандардно, тој се наоѓа во дистрибуцијата Apache Ignite во директориумот libs/опционален и не е вклучен во патеката за класа. Можете едноставно да го преместите директориумот едно ниво нагоре на libs, а потоа кога ќе го извршите преку ignite.sh тој автоматски ќе биде овозможен.
• Упорноста мора да биде овозможена (Овозможено преку DataRegionConfiguration.setPersistenceEnabled(true)).
• Режимот на компресија мора да се постави со користење на методот DataStorageConfiguration.setWalPageCompression(), компресијата е стандардно оневозможена (ИСКЛУЧЕН режим).
• По избор, можете да го поставите нивото на компресија користејќи го методот DataStorageConfiguration.setWalPageCompression(), видете го Javadoc за методот за валидни вредности за секој режим.

Заклучок

Разгледаните механизми за компресија на податоци во Apache Ignite може да се користат независно еден од друг, но секоја нивна комбинација е исто така прифатлива. Разбирањето како тие функционираат ќе ви овозможи да одредите колку се соодветни за вашите задачи во вашата околина и што ќе треба да жртвувате кога ги користите. Компресирањето на страницата на дискот е дизајнирано да го компресира главното складирање и може да даде среден сооднос на компресија. Компресирањето на снимката на страницата WAL ќе даде просечен степен на компресија за WAL-датотеките и најверојатно дури и ќе ги подобри перформансите. Набивањето на WAL нема да има позитивен ефект врз перформансите, но ќе ја намали големината на WAL-датотеките што е можно повеќе со отстранување на физичките записи.

Извор: www.habr.com