Чоң көлөмдөгү маалыматтар менен иштөөдө кээде дискте мейкиндиктин жетишсиздиги көйгөйү келип чыгышы мүмкүн. Бул көйгөйдү чечүүнүн бир жолу - кысуу, анын жардамы менен, ошол эле жабдууларда сактоо көлөмүн көбөйтүүгө болот. Бул макалада биз Apache Igniteде маалыматтарды кысуу кантип иштээрин карап чыгабыз. Бул макалада продукт ичинде ишке ашырылган диск кысуу ыкмалары гана сүрөттөлөт. Маалыматты кысуунун башка ыкмалары (тармак аркылуу, эстутумда), ишке ашырылганбы же жокпу, ал чөйрөдөн тышкары калат.
Ошентип, туруктуу режим иштетилгенде, кэштердеги маалыматтардын өзгөрүшүнүн натыйжасында, Ignite дискке жаза баштайт:
- Кэштердин мазмуну
- Алдын ала журналды жазуу (мындан ары жөн гана WAL)
Бир топ убакыттан бери WAL кысуу механизми бар, ал WAL кысуу деп аталат. Жакында чыгарылган Apache Ignite 2.8 дисктеги маалыматтарды кысууга мүмкүндүк берген дагы эки механизмди киргизди: кэштердин мазмунун кысуу үчүн диск бетинин кысуу жана кээ бир WAL жазууларын кысуу үчүн WAL баракчасынын снапшотунун кысуу. Төмөндө ушул үч механизмдин бардыгы жөнүндө көбүрөөк маалымат.
Диск барагын кысуу
Бул кандай иштейт
Биринчиден, келгиле, Ignite маалыматтарды кантип сактаарын кыскача карап көрөлү. Барак эстутуму сактоо үчүн колдонулат. Барактын өлчөмү түйүндүн башында коюлат жана аны кийинки этаптарда өзгөртүүгө болбойт; ошондой эле, барактын өлчөмү файл тутумунун блогунун өлчөмүнөн эки жана бир эсе көп болушу керек. Барактар керектүү учурда дисктен RAMга жүктөлөт; дисктеги маалыматтардын көлөмү бөлүнгөн оперативдик эстутумдун көлөмүнөн ашып кетиши мүмкүн. Эгерде RAMда дисктен баракты жүктөө үчүн орун жетишсиз болсо, эски, колдонулбай калган барактар RAMдан чыгарылат.
Маалыматтар дискте төмөнкү формада сакталат: ар бир кэш тобунун ар бир бөлүгү үчүн өзүнчө файл түзүлөт, бул файлда барактар индекстин өсүү тартибинде биринин артынан бири пайда болот. Толук беттин идентификаторунда кэш тобунун идентификатору, бөлүмдүн номери жана файлдагы беттин индекси бар. Ошентип, толук беттин идентификаторун колдонуу менен биз ар бир барак үчүн файлды жана файлдагы офсетти уникалдуу түрдө аныктай алабыз. Сиз Apache Ignite Wiki макаласынан пейджинг эстутуму жөнүндө көбүрөөк окуй аласыз: .
Дисктин барагын кысуу механизми, сиз аты боюнча болжолдогондой, барак деңгээлинде иштейт. Бул механизм иштетилгенде, оперативдик эстутумдагы маалыматтар эч кандай кысуусуз эле иштетилет, бирок барактар RAMдан дискке сакталганда, алар кысылган.
Бирок ар бир баракты өз-өзүнчө кысуу бул маселени чечүү эмес; сиз кандайдыр бир жол менен алынган маалымат файлдарынын көлөмүн азайтышыңыз керек. Эгер барактын өлчөмү мындан ары бекитилбесе, биз файлга барактарды биринин артынан бири жаза албайбыз, анткени бул бир катар көйгөйлөрдү жаратышы мүмкүн:
- Барактын индексин колдонуу менен, анын файлда жайгашкан ордун эсептей албайбыз.
- Файлдын аягында жок жана өлчөмүн өзгөрткөн барактар менен эмне кылуу керектиги түшүнүксүз. Эгер барактын көлөмү азайса, ал бошоткон мейкиндик жок болот. Эгер барактын көлөмү чоңойсо, анда ал үчүн файлдан жаңы жерди издөө керек.
- Эгер барак файл тутумунун блогунун өлчөмүнөн эсе көп болбогон бир нече байт менен жылса, анда аны окуу же жазуу дагы бир файл тутумунун блогуна тийүүнү талап кылат, бул иштин начарлашына алып келиши мүмкүн.
Бул көйгөйлөрдү өз деңгээлинде чечпөө үчүн, Apache Ignite'де диск беттерин кысуу сейрек файлдар деп аталган файл тутумунун механизмин колдонот. Сейрек файл - бул кээ бир нөлгө толтурулган аймактарды "тешик" катары белгилей турган файл. Бул учурда, бул тешиктерди сактоо үчүн эч кандай файл тутумунун блоктору бөлүнбөйт, натыйжада дисктеги мейкиндик үнөмдөлөт.
Файлдык тутум блогун бошотуу үчүн, тешиктин өлчөмү файл тутумунун блогунан чоңураак же барабар болушу керек, бул барактын өлчөмүнө жана Apache Igniteге кошумча чектөө киргизет: кысуу кандайдыр бир эффектке ээ болушу үчүн, беттин өлчөмү файл тутумунун блогунун өлчөмүнөн катуураак болушу керек. Эгерде барактын өлчөмү блоктун өлчөмүнө барабар болсо, анда биз эч качан бир блокту бошотпойбуз, анткени бир блокту бошотуу үчүн кысылган барак 0 байт ээлеши керек. Эгерде барактын өлчөмү 2 же 4 блоктун өлчөмүнө барабар болсо, анда биздин баракчабыз тиешелүүлүгүнө жараша, жок дегенде 50% же 75% кысылган болсо, биз жок дегенде бир блокту бошотуп алабыз.
Ошентип, механизмдин ишинин акыркы сүрөттөлүшү: Дискке бет жазууда баракты кысуу аракети жасалат. Эгерде кысылган барактын көлөмү бир же бир нече файл тутумунун блокторун бошотууга мүмкүндүк берсе, анда барак кысылган формада жазылат жана бошотулган блоктордун ордуна "тешик" жасалат (системалык чалуу аткарылат). fallocate() тешик желеги менен). Эгерде кысылган барактын көлөмү блокторду бошотууга жол бербесе, барак кысылган бойдон сакталат. Бардык барак офсеттери кысуусуз эле, барактын индексин барактын өлчөмүнө көбөйтүү жолу менен эсептелет. Барактарды өз алдынча көчүрүү талап кылынбайт. Барактын офсеттери, кысуусуз эле, файл тутумунун блокторунун чектерине туура келет.
Учурдагы ишке ашырууда, Ignite Linux OS астында сейрек файлдар менен гана иштей алат; ошого ылайык, дисктин барагын кысуу ушул операциялык тутумда Ignite колдонулганда гана иштетилиши мүмкүн.
Диск барагын кысуу үчүн колдонула турган кысуу алгоритмдери: ZSTD, LZ4, Snappy. Мындан тышкары, иштөө режими (SKIP_GARBAGE) бар, мында калган маалыматтарга кысуу колдонулбастан, барактагы пайдаланылбаган мейкиндик гана ыргытылат, бул мурда саналып өткөн алгоритмдерге салыштырмалуу CPU жүгүн азайтат.
Performance Impact
Тилекке каршы, мен чыныгы стенддерде иш жүзүндөгү көрсөткүчтөрдү өлчөө жүргүзгөн жокмун, анткени биз бул механизмди өндүрүштө колдонууну пландаган жокпуз, бирок биз теориялык жактан кайсы жерден утулуп, кайдан утабыз деп божомолдоого болот.
Бул үчүн, биз барактарга киргенде кантип окуларын жана жазылганын эстешибиз керек:
- Окуу операциясын аткарып жатканда, ал адегенде оперативдүү эс тутумда изделет, издөө ийгиликсиз болсо, барак RAMга дисктен окууну аткарган ошол эле жип аркылуу жүктөлөт.
- Жазуу операциясы аткарылганда, оперативдүү эс тутумдагы барак кир деп белгиленет, бирок жазууну аткарган жип дароо дискке физикалык түрдө сакталбайт. Бардык кир барактар дискке кийинчерээк текшерүү процессинде өзүнчө жиптерде сакталат.
Ошентип, окуу операцияларына таасири:
- Позитивдүү (диск IO), окуу файл тутумунун блокторунун санынын азайышына байланыштуу.
- Терс (CPU), сейрек файлдар менен иштөө үчүн операциялык система талап кылган кошумча жүккө байланыштуу. Татаалыраак сейрек файл түзүмүн сактоо үчүн кошумча IO операциялары бул жерде кыйыр түрдө пайда болушу мүмкүн (тилекке каршы, мен сейрек файлдардын иштешинин бардык деталдары менен тааныш эмесмин).
- Терс (CPU), барактарды ачуу зарылдыгынан улам.
- Жазуу операцияларына эч кандай таасири жок.
- Өткөрүү пунктунун процессине таасири (бул жерде бардыгы окуу операцияларына окшош):
- Жазылган файл тутумунун блокторунун санынын азайышынан улам оң (диск IO).
- Терс (CPU, мүмкүн диск IO), сейрек файлдар менен иштөөдөн улам.
- Терс (CPU), баракты кысуу зарылдыгынан улам.
Таразанын кайсы тарабы таразаны оодарат? Мунун баары айлана-чөйрөгө көз каранды, бирок мен дисктин барагын кысуу көпчүлүк системалардын иштешинин начарлашына алып келет деп ишенем. Мындан тышкары, сейрек файлдар менен окшош ыкманы колдонгон башка DBMSs боюнча тесттер кысуу иштетилгенде аткаруунун төмөндөшүн көрсөтөт.
Кантип иштетүү жана конфигурациялоо керек
Жогоруда айтылгандай, диск беттерин кысуу колдогон Apache Ignite минималдуу версиясы 2.8 жана Linux операциялык тутуму гана колдоого алынат. Төмөнкүдөй иштетиңиз жана конфигурациялаңыз:
- Класстын жолунда күйгүзүүчү-кысуу модулу болушу керек. Демейки боюнча, ал libs/кошумча каталогдо Apache Ignite бөлүштүрүүдө жайгашкан жана класс жолунда камтылган эмес. Сиз жөн гана каталогду бир деңгээлге libsке жылдырсаңыз болот, андан кийин аны ignite.sh аркылуу иштеткенде, ал автоматтык түрдө иштетилет.
- Туруктуулукту иштетүү керек (Ишки аркылуу
DataRegionConfiguration.setPersistenceEnabled(true)). - Барактын өлчөмү файл тутумунун блогунун өлчөмүнөн чоңураак болушу керек (сиз аны колдонуу менен орното аласыз
DataStorageConfiguration.setPageSize()). - Маалыматтары кысылышы керек болгон ар бир кэш үчүн кысуу ыкмасын жана (милдеттүү эмес) кысуу деңгээлин (ыкмалар) конфигурациялашыңыз керек.
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
WAL тыгыздоо
Бул кандай иштейт
WAL деген эмне жана ал эмне үчүн керек? Абдан кыскача: бул акырында барактын сактагычын өзгөрткөн бардык окуяларды камтыган журнал. Бул биринчи кезекте жыгылган учурда калыбына келтирүү үчүн керек. Ар кандай операция, башкарууну колдонуучуга берүүдөн мурун, алгач WALда окуяны жазышы керек, ал иштебей калса, ал журналда ойнотулат жана колдонуучу ийгиликтүү жооп алган бардык операцияларды калыбына келтириши мүмкүн. дисктеги баракчанын сактагычында чагылдырууга убакыт болгон жок (жогоруда айтылгандай, барак дүкөнүнө иш жүзүндө жазуу өзүнчө жиптер менен бир аз кечигүү менен "текшерүү" деп аталган процессте жасалат).
WALдагы жазуулар логикалык жана физикалык болуп бөлүнөт. Логикалык ачкычтар жана баалуулуктар. Физикалык - барак дүкөнүндөгү барактардын өзгөрүүлөрүн чагылдырат. Логикалык жазуулар кээ бир башка учурларда пайдалуу болушу мүмкүн, бирок физикалык жазуулар авария болгон учурда калыбына келтирүү үчүн гана керек жана жазуулар акыркы ийгиликтүү текшерүү пунктунан кийин гана керек. Бул жерде биз майда-чүйдөсүнө чейин кирбейбиз жана анын эмне үчүн мындай иштээрин түшүндүрбөйбүз, бирок кызыккандар Apache Ignite Wikiдеги буга чейин айтылган макалага кайрыла алышат: .
Логикалык жазууда көбүнчө бир нече физикалык жазуулар бар. Башкача айтканда, мисалы, кэшке бир коюу операциясы барактын эс тутумундагы бир нече баракка (маалыматтын өзү бар барак, индекстери бар барактар, эркин тизмелери бар барактар) таасирин тийгизет. Кээ бир синтетикалык сыноолордо физикалык жазуулар WAL файлынын 90% га чейин ээлегенин байкадым. Бирок, алар өтө кыска убакытка керектелет (демейки боюнча, өткөрүү пункттарынын ортосундагы интервал 3 мүнөт). Өзүнүн актуалдуулугун жоготкондон кийин бул маалыматтардан арылуу логикага ылайыктуу болмок. WAL ныктоо механизми дал ушундай кылат: ал физикалык жазуулардан арылат жана zip аркылуу калган логикалык жазууларды кысып, файлдын көлөмү өтө олуттуу (кээде ондогон эсеге) кыскарат.
Физикалык жактан алганда, WAL тегерек түрдө үстүнө жазылган белгиленген өлчөмдөгү (демейки боюнча 10 МБ) бир нече сегменттерден (демейки боюнча 64) турат. Учурдагы сегмент толтурулгандан кийин, кийинки сегмент учурдагы катары дайындалат, ал эми толтурулган сегмент өзүнчө жип менен архивге көчүрүлөт. WAL тыгыздоо архив сегменттери менен мурунтан эле иштейт. Ошондой эле, өзүнчө жип катары, ал текшерүү пунктунун аткарылышын көзөмөлдөйт жана физикалык жазуулар кереги жок болгон архив сегменттеринде кысуу баштайт.
Performance Impact
WAL тыгыздоо өзүнчө жип катары иштегендиктен, аткарылып жаткан операцияларга түздөн-түз таасир тийгизбеши керек. Бирок ал дагы эле CPU (кысуу) жана дискке кошумча фондо жүктөйт (архивден ар бир WAL сегментин окуу жана кысылган сегменттерди жазуу), андыктан система максималдуу кубаттуулукта иштеп жатса, анда бул да иштин начарлашына алып келет.
Кантип иштетүү жана конфигурациялоо керек
Сиз мулк аркылуу WAL тыгыздалышын иштете аласыз WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Ошондой эле, DataStorageConfiguration.setWalCompactionLevel() ыкмасын колдонуп, демейки мааниге (BEST_SPEED) канааттанбасаңыз, кысуу деңгээлин орното аласыз.
WAL баракчасынын сүрөтүн кысуу
Бул кандай иштейт
WALда жазуулар логикалык жана физикалык болуп бөлүнөрүн биз буга чейин билдик. Ар бир бетке болгон ар бир өзгөртүү үчүн беттин эсинде физикалык WAL жазуусу түзүлөт. Физикалык жазуулар, өз кезегинде, ошондой эле 2 түргө бөлүнөт: баракчанын сүрөт жазуусу жана дельта жазуусу. Биз баракчадагы бир нерсени өзгөрткөн сайын жана аны таза абалдан кир абалга өткөргөн сайын, бул барактын толук көчүрмөсү WAL (баракчанын сүрөт жазуусу) ичинде сакталат. WALда бир гана байт өзгөрткөн күндө да, жазуу барактын өлчөмүнөн бир аз чоңураак болот. Эгерде биз ансыз деле булганган баракта бир нерсени өзгөртсөк, анда WALда дельта жазуусу түзүлөт, ал барактын мурунку абалына салыштырганда гана өзгөрүүлөрдү чагылдырат, бирок бүт баракты эмес. Барактардын абалын кирден тазага кайтаруу текшерүү пункту процессинде жүргүзүлүп жаткандыктан, текшерүү пункту башталгандан кийин дароо эле, дээрлик бардык физикалык жазуулар барактардын сүрөттөрүнөн гана турат (анткени текшерүү пункту башталгандан кийин дароо бардык барактар таза) , андан кийин биз кийинки өткөрүү пунктуна жакындаганыбызда, дельтанын рекорддук бөлүгү өсө баштайт жана кийинки текшерүү пунктунун башында кайра башталат. Кээ бир синтетикалык тесттердеги өлчөөлөр физикалык жазуулардын жалпы көлөмүндөгү баракчалардын үлүшү 90% жете турганын көрсөттү.
WAL беттин снапшоттарын кысуу идеясы даяр баракты кысуу куралын колдонуу менен барактын сүрөттөрүн кысуу болуп саналат (диск бетинин кысуусун караңыз). Ошол эле учурда, WALда жазуулар ырааттуу түрдө жалаң гана тиркеме режиминде сакталат жана жазууларды файл тутумунун блокторунун чектерине байланыштыруунун кереги жок, ошондуктан бул жерде диск баракты кысуу механизминен айырмаланып, бизге сейрек файлдардын кереги жок. бардыгы; ошого жараша, бул механизм Linux OS гана иштебейт. Мындан тышкары, биз үчүн баракты канчалык кысып алганыбыз маанилүү эмес. Биз 1 байтты бошоткон күндө да, бул оң натыйжа жана биз WALда кысылган маалыматтарды сактай алабыз, диск беттин кысуусунан айырмаланып, анда биз 1ден ашык файл тутумунун блогун бошотсок, кысылган баракты сактайбыз.
Барактар өтө кысылган маалыматтар, алардын жалпы WAL көлөмүндөгү үлүшү өтө жогору, ошондуктан WAL файл форматын өзгөртпөстөн, биз анын көлөмүн бир топ кыскарта алабыз. Кысуу, анын ичинде логикалык жазуулар форматты өзгөртүүнү жана шайкештикти жоготууну талап кылат, мисалы, логикалык жазууларга кызыккан тышкы керектөөчүлөр үчүн, бирок файлдын көлөмүнүн олуттуу кыскарышына алып келбейт.
Диск барагын кысуу сыяктуу эле, WAL баракчасынын снапшотун кысуу ZSTD, LZ4, Snappy кысуу алгоритмдерин, ошондой эле SKIP_GARBAGE режимин колдоно алат.
Performance Impact
WAL беттин снапшотунун кысуусун түздөн-түз иштетүү беттин эстутумуна маалыматтарды жаза турган жиптерге, башкача айтканда кэштердеги маалыматтарды өзгөрткөн жиптерге гана таасирин тийгизерин байкоо кыйын эмес. WALдан физикалык жазууларды окуу бир гана жолу болот, учурда түйүн кулагандан кийин көтөрүлөт (жана ал текшерүү учурунда түшүп калса гана).
Бул маалыматтарды өзгөртө турган жиптерге төмөнкүдөй таасир этет: дискке жазуудан мурда баракты кысуу зарылчылыгынан улам терс эффект (CPU) жана ал эми оң эффект (диск IO) көлөмүнүн азайышынан улам пайда болот. маалыматтар жазылган. Демек, бул жерде бардыгы жөнөкөй: эгерде системанын иштеши CPU тарабынан чектелсе, анда биз бир аз деградацияны алабыз, эгерде ал диск киргизүү/чыгаруу менен чектелсе, анда биз өсүш алабыз.
Кыйыр түрдө, WAL өлчөмүн азайтуу WAL сегменттерин архивге жана WAL тыгыздоо агымдарына таштаган агымдарга да (оң) таасирин тийгизет.
Синтетикалык маалыматтарды колдонуу менен биздин чөйрөбүздөгү реалдуу иштөө тесттери бир аз жогорулаганын көрсөттү (өткөрүү жөндөмдүүлүгү 10%-15% га көбөйдү, күтүү 10%-15% га азайды).
Кантип иштетүү жана конфигурациялоо керек
Минималдуу Apache Ignite версиясы: 2.8. Төмөнкүдөй иштетиңиз жана конфигурациялаңыз:
- Класстын жолунда күйгүзүүчү-кысуу модулу болушу керек. Демейки боюнча, ал libs/кошумча каталогдо Apache Ignite бөлүштүрүүдө жайгашкан жана класс жолунда камтылган эмес. Сиз жөн гана каталогду бир деңгээлге libsке жылдырсаңыз болот, андан кийин аны ignite.sh аркылуу иштеткенде, ал автоматтык түрдө иштетилет.
- Туруктуулукту иштетүү керек (Ишки аркылуу
DataRegionConfiguration.setPersistenceEnabled(true)). - кысуу режими ыкмасын колдонуу менен коюлушу керек
DataStorageConfiguration.setWalPageCompression(), кысуу демейки боюнча өчүрүлгөн (DISABLED режими). - Кошумча, сиз ыкманы колдонуу менен кысуу деңгээлин орното аласыз
DataStorageConfiguration.setWalPageCompression(), ар бир режим үчүн жарактуу маанилер үчүн ыкма үчүн javadoc караңыз.
жыйынтыктоо
Apache Igniteде каралып жаткан маалыматтарды кысуу механизмдери бири-биринен көз карандысыз колдонулушу мүмкүн, бирок алардын ар кандай айкалышы да алгылыктуу. Алардын кантип иштээрин түшүнүү сиздин чөйрөңүздөгү милдеттериңизге канчалык ылайыктуу экенин жана аларды колдонууда эмнени курмандыкка чалууга туура келерин аныктоого мүмкүндүк берет. Диск барагын кысуу негизги сактагычты кысуу үчүн иштелип чыккан жана орточо кысуу катышын бере алат. WAL баракчасынын сүрөтүн кысуу WAL файлдары үчүн орточо кысуу даражасын берет жана, кыязы, аткарууну жакшыртат. WAL компакттоо иштөөгө оң таасирин тийгизбейт, бирок физикалык жазууларды алып салуу менен WAL файлдарынын көлөмүн мүмкүн болушунча азайтат.
Source: www.habr.com