🥇Компресия на данни в Apache Ignite. Опит на Сбера

При работа с големи обеми данни понякога може да се появи проблем с недостатъчно място на дисковете. Един от начините за решаване на този проблем е компресията, благодарение на която, на същото оборудване, можем да си позволим увеличаване на капацитета за съхранение. В тази статия ще разгледаме как работи компресията на данни в Apache Ignite. В статията ще бъдат описани само начините за компресия, реализирани в продукта. Други начини за компресия на данни (по мрежата, в паметта), както реализирани, така и не, ще останат извън обхвата.

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

Съдържание на кешовете
Журнал на предварителното записване (Write Ahead Log, по-нататък просто WAL)

За компресия на WAL вече отдавна съществува механизъм, наречен WAL компакция. В наскоро излязлата версия Apache Ignite 2.8 се появиха още два механизма, позволяващи да се компресират данните на диска, а именно компресия на страници на диска за компресия на съдържанието на кешовете и компресия на моментни снимки на страници на WAL за компресия на определени записи на WAL. Подробно за всичките три механизма по-долу.

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

Как работи това

Първо, много накратко ще разгледаме как Ignite съхранява данни. За съхранение се използва странична памет. Размерът на страницата се задава при стартиране на възела и не може да бъде променен на по-късни етапи, също така размерът на страницата трябва да бъде степен на две и кратен на размера на блока на файловата система. Страниците се зареждат в RAM от диска при необходимост; размерът на данните на диска може да надвишава обема на наличната RAM. При недостатъчно място в RAM за зареждане на страница от диска, старите, вече не използвани страници ще бъдат изречени от RAM.

На диска данните се съхраняват по следния начин: за всяка партиция на всяка кеш група се създава отделен файл, в този файл, в ред на нарастващ индекс, една след друга идват страниците. Пълният идентификатор на страницата съдържа идентификатора на кеш групата, номера на партицията и индекса на страницата във файла. По този начин, с пълния идентификатор на страницата, можем недвусмислено да определим файла и офсета в него за всяка страница. По-подробно за устройството на страничната памет можете да прочетете в статията в Apache Ignite Wiki: Ignite Персистентно хранилище — зад кулисите.

Механизм на компресия на страниците на диска, както може да се предположи от името, работи на ниво страница. При активиране на този механизъм работата с данни в RAM се извършва такава, каквато е, без никаква компресия, но в момента на запазване на страниците от RAM на диска се осъществява тяхното компресиране.

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

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

За да не решавате тези проблеми сами на своето ниво, компресията на страниците на диска в Apache Ignite използва механизъм на файловата система, наречен разредени файлове. Разреден файл (sparse file) е такъв файл, в който някои, заполнени с нули региони могат да бъдат обозначени като "дупки". При това блоковете на файловата система, необходими за съхранение на тези дупки, няма да бъдат запазени, в резултат на което се постига икономия на дисково пространство.

Логично е, че за да освободим блок на файловата система, размерът на дупката трябва да бъде равен или по-голям от блока на файловата система, което налага допълнително ограничение на размера на страниците в Apache Ignite: за да има компресията някакъв ефект, е необходимо размерът на страницата да е строго по-голям от размера на блока на файловата система. Ако размерът на страницата е равен на размера на блока, никога няма да можем да освободим нито един блок, тъй като за да освободим един блок, е необходимо компресирана страница да заема 0 байта. Ако размерът на страницата е равен на размера на 2 или 4 блока, вече ще можем да освободим поне един блок, ако страницата ни се компресира най-малко до 50% или 75% съответно.

Следователно, окончателното описание на работата на механизма: Когато страницата се записва на диска, се прави опит да се компресира страницата. Ако размерът на компресираната страница позволява освобождаването на един или повече блока от файловата система, страницата се записва в компресиран вид, а на мястото на освободените блокове се пробива 'дупка' (извършва се системен повик) fallocate() с флага 'punch hole'). Ако размерът на компресираната страница не позволява освобождаването на блокове, страницата се съхранява така, както е, в неконпресиран вид. Всички офсети на страниците се смятат, както и без компресия, чрез умножаване на индекса на страницата по размера на страницата. Никаква релакация на страниците не се изисква. Офсети на страниците, както и без компресия, попада на границите на блоковете на файловата система.

В текущата реализация Ignite може да работи със sparse файлове само под ОС Linux, съответно disk page compression може да бъде активиран само при използване на Ignite на тази операционна система.

Алгоритмите за компресия, които могат да се използват за disk page compression: ZSTD, LZ4, Snappy. Освен това има режим на работа (SKIP_GARBAGE), при който се изхвърля само неизползваното място в страницата без прилагане на компресия върху останалите данни, което позволява да се намали натоварването на CPU в сравнение с предходно споменатите алгоритми.

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

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

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

При извършване на операцията за четене първо се извършва нейното търсене в RAM, ако търсенето не е успешно, страницата се зарежда в RAM от диска от същия поток, който извършва четенето.
При извършване на операцията за запис страницата в RAM се маркира като мръсна, като физическото запазване на страницата на диска не се извършва веднага в потока, който извършва записа. Всички мръсни страници се запазват на диска по-късно в процеса на чекпоинт от отделни потоци.

Следователно, влиянието върху операциите по четене:

Положително (disk IO), благодарение на намаляването на броя на прочетените блокове от файловата система.
Отрицателно (CPU) поради допълнителното натоварване, необходимо на операционната система за работа с sparse файлове. Също така е възможно тук да се появят неявно допълнителни IO операции за запазване на по-сложна структура на sparse файла (за всички детайли на работа с sparse файлове не съм запознат).
Отрицателно (CPU) поради необходимостта от декомпресия на страниците.
Няма влияние върху операциите за запис.
Влияние върху процеса на чекпоинт (тук всичко е аналогично на операциите за четене):
Положително (disk IO) поради намаляване на броя записани блокове на файловата система.
Отрицателно (CPU, възможно disk IO) поради работа със sparse файлове.
Отрицателно (CPU) поради необходимостта от компресия на страниците.

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

Как да включите и настроите

Както беше споменато по-горе, минималната версия на Apache Ignite, която поддържа компресия на disk page: 2.8 и се поддържа само на операционната система Linux. Включването и настройването се извършва по следния начин:

В class-path трябва да има модул ignite-compression. По подразбиране той се намира в дистрибуцията на Apache Ignite в директория libs/optional и не се включва в class-path. Можете просто да пренесете директорията на едно ниво нагоре в libs и тогава при стартиране през ignite.sh той автоматично ще бъде включен.
Persistence трябва да бъде включен (включва се чрез DataRegionConfiguration.setPersistenceEnabled(true)).
Размерът на страницата трябва да бъде по-голям от размера на блока на файловата система (може да се зададе с помощта на DataStorageConfiguration.setPageSize() ).
За всеки кеш, данните на който трябва да се компресират, е необходимо в конфигурацията да се настрои методът на компресия и (по желание) нивото на компресия (методи CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()).

WAL компресия

Как работи това

Какво е WAL и защо е нужен? Много накратко: това е журнал, в който попадат всички събития, променящи в крайна сметка страничното хранилище. Нужен е предимно за възможността за възстановяване в случай на срив. Всяка операция, преди да предаде управлението на потребителя, трябва първо да запише събитието в WAL, за да има възможност в случай на срив да възпроизведе журнала и да възстанови всички операции, за които потребителят е получил успешен отговор, дори ако тези операции не са успели да се отразят в страничното хранилище на диска (по-горе беше описано, че действителната запис в страничното хранилище се извършва в процес, наречен „чекпоинт“ с известно закъснение от отделни потоци).

Записи в WAL се делят на логически и физически. Логическите — това са самите ключове и стойности. Физическите — отразяват промените в страниците на страничното хранилище. Докато логическите записи могат да бъдат полезни и за други случаи, физическите записи са необходими само за възстановяване в случай на срив и са нужни само записи от момента на последния успешен чекпоинт. Тук няма да влизаме в подробности и да обясняваме защо това работи именно така, но заинтересованите могат да се обърнат към вече споменатата статия в Apache Ignite Wiki: Ignite Персистентно хранилище — зад кулисите.

На една логическа запис често се падат няколко физически записа. Тоест, например, една операция put в кеша засяга няколко страници в страничната памет (страницата с данните, страниците с индекси, страниците с free-list-и). В някои синтетични тестове установих, че физическите записи заемат до 90% от обема на WAL файла. При това те са нужни само за много кратко време (по подразбиране интервалът между чекпоинтите е 3 минути). Логично би било от тези данни след загубата на актуалността им да се избавим. Именно това извършва механизмът WAL компакция, който се освобождава от физическите записи и компресира останалите логически записи с помощта на zip, при което размерът на файла значително намалява (понякога десетки пъти).

Физически WAL се състои от няколко сегмента (по подразбиране 10) с фиксиран размер (по подразбиране 64Мб), които се перезаписват циклично. След като текущият сегмент е запълнен, на него се назначава следващият сегмент, а запълненият сегмент се копира в архив чрез отделен поток. WAL компактиране вече работи с архивните сегменти. Също така, чрез отделен поток, той следи изпълнението на чекпоинта и започва компресията на архивните сегменти, физическите записи, за които вече не са нужни.

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

Тъй като WAL компактиране работи чрез отделен поток, не трябва да има пряко влияние върху изпълняваните операции. Но все пак то дава допълнителна фоново натоварване на CPU (компресия) и диск (четене на всеки 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) заради необходимостта всеки път да компресираме страницата преди запис на диска и положителен ефект (дисков вход/изход) заради намаляване на количеството записвани данни. Съответно, тук е просто: ако производителността на системата зависи от CPU, получаваме малка деградация; ако от дисковия вход/изход — получаваме покачване.

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

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

Как да включите и настроите

Минималната версия на Apache Ignite: 2.8. Включването и настройката се извършват по следния начин:

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

Заключение

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

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