🥇Компресия на данни в 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 Persistent Store — под капака.

Механизм disk page compression, както подсказва името, работи на странично ниво. При активиране на този механизъм работата с данни в RAM се извършва без компресия, но при запазване на страниците от RAM на диск се извършва тяхното компресиране.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Както вече беше споменато, минималната версия на Apache Ignite, която поддържа компресия на дискови страници: 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 Persistent Store — под капака.

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

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

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

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

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

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

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

Как работи

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

Идеята на сжатие на WAL page snapshot е да се компресират снэпшотите на страниците, използвайки вече наличен инструмент за компресия на страниците (вж. disk page compression). При това записите в WAL се съхраняват последователно в режим append-only и няма необходимост от свързване на записите с границите на блоковете на файловата система, следователно тук, в отличие от механизма на disk page compression, не са необходими sparse файлове, съответно този механизъм ще работи не само на ОС Linux. Освен това вече не е важно колко силно сме успели да компресираме страницата. Дори ако освободим 1 байт, това вече е положителен резултат и можем да съхраняваме компресирани данни в WAL, за разлика от disk page compression, където запазваме компресирана страница само ако сме освободили повече от 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