Компресиране на данни в Apache Ignite. Опитът на Sber

Когато работите с големи обеми данни, понякога може да възникне проблемът с липсата на дисково пространство. Един от начините за решаване на този проблем е компресията, благодарение на която на същото оборудване можете да си позволите да увеличите обемите на съхранение. В тази статия ще разгледаме как работи компресирането на данни в 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), поради намаляване на броя на прочетените блокове на файловата система.
• Отрицателна (CPU), поради допълнителното натоварване, необходимо на операционната система за работа с редки файлове. Възможно е също така тук косвено да се появят допълнителни IO операции, за да се запази по-сложна разредена файлова структура (за съжаление, не съм запознат с всички подробности за това как работят разредените файлове).
• Отрицателна (CPU), поради необходимостта от декомпресиране на страници.
• Няма влияние върху операциите за запис.
• Въздействие върху процеса на контролна точка (всичко тук е подобно на операциите за четене):
• Положителна (диск IO), поради намаляване на броя на записаните блокове на файловата система.
• Отрицателна (CPU, вероятно диск IO), поради работа с разредени файлове.
• Отрицателна (CPU), поради необходимостта от компресиране на страницата.

Коя страна на везната ще наклони везната? Всичко това много зависи от средата, но съм склонен да вярвам, че компресирането на дискови страници най-вероятно ще доведе до влошаване на производителността на повечето системи. Освен това, тестовете на други СУБД, които използват подобен подход с редки файлове, показват спад в производителността, когато компресията е активирана.

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

Както бе споменато по-горе, минималната версия на Apache Ignite, която поддържа компресиране на дискови страници, е 2.8 и се поддържа само операционната система Linux. Активирайте и конфигурирайте, както следва:

• Трябва да има модул за компресиране на запалване в пътя на класа. По подразбиране той се намира в дистрибуцията на Apache Ignite в директорията libs/optional и не е включен в class-path. Можете просто да преместите директорията едно ниво нагоре към 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 по подразбиране) с фиксиран размер (64MB по подразбиране), които се презаписват по кръгов начин. Веднага след като текущият сегмент се запълни, следващият сегмент се присвоява като текущ и попълненият сегмент се копира в архива от отделна нишка. Уплътняването на WAL вече работи с архивни сегменти. Освен това, като отделна нишка, той следи изпълнението на контролната точка и започва компресиране в архивни сегменти, за които вече не са необходими физически записи.

Въздействие върху производителността

Тъй като уплътняването на WAL се изпълнява като отделна нишка, не трябва да има пряко въздействие върху извършваните операции. Но все още поставя допълнително фоново натоварване на процесора (компресия) и диска (четене на всеки WAL сегмент от архива и запис на компресираните сегменти), така че ако системата работи на максималния си капацитет, това също ще доведе до влошаване на производителността.

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

Можете да активирате уплътняването на WAL, като използвате свойството WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Освен това, като използвате метода DataStorageConfiguration.setWalCompactionLevel(), можете да зададете нивото на компресия, ако не сте доволни от стойността по подразбиране (BEST_SPEED).

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

Как работи

Вече разбрахме, че в WAL записите се делят на логически и физически. За всяка промяна на всяка страница се генерира физически WAL запис в паметта на страницата. Физическите записи от своя страна също се разделят на 2 подтипа: запис на моментна снимка на страница и делта запис. Всеки път, когато променим нещо на страница и я прехвърлим от чисто състояние в мръсно състояние, пълно копие на тази страница се съхранява в WAL (запис на моментна снимка на страница). Дори ако сме променили само един байт в WAL, записът ще бъде малко по-голям от размера на страницата. Ако променим нещо на вече мръсна страница, в WAL се формира делта запис, който отразява само промените спрямо предишното състояние на страницата, но не и цялата страница. Тъй като нулирането на състоянието на страниците от мръсни към чисти се извършва по време на процеса на контролна точка, веднага след началото на контролната точка, почти всички физически записи ще се състоят само от моментни снимки на страници (тъй като всички страници непосредствено след началото на контролната точка са чисти) , след това, когато наближаваме следващата контролна точка, частта от делта запис започва да расте и се нулира отново в началото на следващата контролна точка. Измерванията в някои синтетични тестове показаха, че делът на моментните снимки на страници в общия обем на физическите записи достига 90%.

Идеята на компресирането на моментни снимки на страници WAL е да компресирате моментни снимки на страници с помощта на готов инструмент за компресиране на страници (вижте компресиране на страници на дискове). В същото време в WAL записите се записват последователно в режим само за добавяне и няма нужда да се свързват записи към границите на блоковете на файловата система, така че тук, за разлика от механизма за компресиране на страницата на диска, не се нуждаем от редки файлове на всички; съответно този механизъм ще работи не само на OS Linux. Освен това за нас вече няма значение колко сме успели да компресираме страницата. Дори и да сме освободили 1 байт, това вече е положителен резултат и можем да запазим компресирани данни в WAL, за разлика от компресията на дискова страница, където запазваме компресираната страница само ако сме освободили повече от 1 блок на файловата система.

Страниците са силно компресируеми данни, техният дял в общия WAL обем е много висок, така че без да променяме WAL файловия формат, можем да постигнем значително намаляване на неговия размер. Компресирането, включително логическите записи, би изисквало промяна във формата и загуба на съвместимост, например за външни потребители, които може да се интересуват от логически записи, но няма да доведе до значително намаляване на размера на файла.

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

Въздействие върху производителността

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

Това засяга нишките, които променят данните по следния начин: получаваме отрицателен ефект (CPU) поради необходимостта от компресиране на страницата всеки път преди запис на диска и положителен ефект (IO на диска) поради намаляване на количеството записани данни. Съответно тук всичко е просто: ако производителността на системата е ограничена от процесора, получаваме леко влошаване, ако е ограничена от I/O на диска, получаваме увеличение.

Косвено, намаляването на размера на WAL също засяга (положително) потоците, които изхвърлят WAL сегменти в архива и потоците за уплътняване на WAL.

Реалните тестове за производителност в нашата среда, използвайки синтетични данни, показаха леко увеличение (производителността се увеличи с 10%-15%, латентността намаля с 10%-15%).

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

Минимална версия на Apache Ignite: 2.8. Активирайте и конфигурирайте, както следва:

• Трябва да има модул за компресиране на запалване в пътя на класа. По подразбиране той се намира в дистрибуцията на Apache Ignite в директорията libs/optional и не е включен в class-path. Можете просто да преместите директорията едно ниво нагоре към libs и след това, когато я стартирате през ignite.sh, тя автоматично ще бъде активирана.
• Постоянството трябва да бъде активирано (Активирано чрез DataRegionConfiguration.setPersistenceEnabled(true)).
• Режимът на компресиране трябва да бъде зададен с помощта на метода DataStorageConfiguration.setWalPageCompression(), компресията е деактивирана по подразбиране (режим DISABLED).
• По желание можете да зададете нивото на компресия, като използвате метода DataStorageConfiguration.setWalPageCompression(), вижте javadoc за метода за валидни стойности за всеки режим.

Заключение

Разгледаните механизми за компресиране на данни в Apache Ignite могат да се използват независимо един от друг, но всяка комбинация от тях също е приемлива. Разбирането как работят те ще ви позволи да определите доколко са подходящи за вашите задачи във вашата среда и какво ще трябва да пожертвате, когато ги използвате. Компресирането на дискови страници е предназначено да компресира основното хранилище и може да даде средно съотношение на компресия. Компресирането на моментна снимка на WAL страница ще даде средна степен на компресия за WAL файлове и най-вероятно дори ще подобри производителността. Уплътняването на WAL няма да има положителен ефект върху производителността, но ще намали размера на WAL файловете възможно най-много чрез премахване на физически записи.

Източник: www.habr.com