Մեծ ծավալի տվյալների հետ աշխատելիս երբեմն կարող է առաջանալ սկավառակի տարածության պակասի խնդիր: Այս խնդրի լուծման ուղիներից մեկը սեղմումն է, որի շնորհիվ նույն սարքավորման վրա կարող եք ձեզ թույլ տալ մեծացնել պահեստավորման ծավալները։ Այս հոդվածում մենք կանդրադառնանք, թե ինչպես է աշխատում տվյալների սեղմումը Apache Ignite-ում: Այս հոդվածը նկարագրելու է միայն սկավառակի սեղմման մեթոդները, որոնք իրականացվել են արտադրանքի ներսում: Տվյալների սեղմման այլ մեթոդներ (ցանցով, հիշողության մեջ), անկախ նրանից՝ իրականացված են, թե ոչ, կմնան շրջանակից դուրս:
Այսպիսով, երբ միացված է համառ ռեժիմը, քեշերում տվյալների փոփոխությունների արդյունքում, Ignite-ը սկսում է գրել սկավառակի վրա.
- Քեշերի բովանդակությունը
- Գրել առաջ գրանցամատյան (այսուհետ՝ պարզապես WAL)
Արդեն բավական ժամանակ է, ինչ գոյություն ունի WAL սեղմման մեխանիզմ, որը կոչվում է WAL սեղմում: Վերջերս թողարկված Apache Ignite 2.8-ը ներկայացրեց ևս երկու մեխանիզմ, որոնք թույլ են տալիս սեղմել տվյալները սկավառակի վրա՝ սկավառակի էջի սեղմում քեշի բովանդակությունը սեղմելու համար և WAL էջի նկարի սեղմում՝ WAL-ի որոշ գրառումներ սեղմելու համար: Այս բոլոր երեք մեխանիզմների մասին ավելի մանրամասն ստորև:
Սկավառակի էջի սեղմում
Ինչպես է այն աշխատում
Նախ, եկեք շատ կարճ նայենք, թե ինչպես է Ignite-ը պահպանում տվյալները: Էջի հիշողությունը օգտագործվում է պահեստավորման համար: Էջի չափը սահմանվում է հանգույցի սկզբում և չի կարող փոխվել հետագա փուլերում, ինչպես նաև էջի չափը պետք է լինի երկու հզորություն և ֆայլային համակարգի բլոկի չափի բազմապատիկ: Անհրաժեշտության դեպքում էջերը բեռնվում են RAM սկավառակից, տվյալների չափը սկավառակի վրա կարող է գերազանցել հատկացված RAM-ի քանակը: Եթե RAM-ում բավարար տարածք չկա սկավառակից էջ բեռնելու համար, հին, այլևս չօգտագործված էջերը կհեռացվեն RAM-ից:
Տվյալները սկավառակի վրա պահվում են հետևյալ ձևով. յուրաքանչյուր քեշ խմբի յուրաքանչյուր բաժանման համար ստեղծվում է առանձին ֆայլ, այս ֆայլում էջերը հայտնվում են մեկը մյուսի հետևից՝ աճող ինդեքսային կարգով: Ամբողջ էջի նույնացուցիչը պարունակում է քեշի խմբի նույնացուցիչը, բաժանման համարը և ֆայլի էջի ինդեքսը: Այսպիսով, օգտագործելով էջի ամբողջական նույնացուցիչը, մենք կարող ենք եզակիորեն որոշել ֆայլը և ֆայլի օֆսեթը յուրաքանչյուր էջի համար: Էջավորման հիշողության մասին ավելին կարող եք կարդալ Apache Ignite Wiki հոդվածում. .
Սկավառակի էջի սեղմման մեխանիզմը, ինչպես կարող եք կռահել անունից, աշխատում է էջի մակարդակով: Երբ այս մեխանիզմը միացված է, 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), էջի սեղմման անհրաժեշտության պատճառով:
Կշեռքի ո՞ր կողմը կթեքի կշեռքը: Այս ամենը շատ կախված է շրջակա միջավայրից, բայց ես հակված եմ հավատալու, որ սկավառակի էջի սեղմումը, ամենայն հավանականությամբ, կհանգեցնի արդյունավետության վատթարացման համակարգերի մեծ մասում: Ավելին, այլ DBMS-ների վրա փորձարկումները, որոնք օգտագործում են նմանատիպ մոտեցում նոսր ֆայլերի հետ, ցույց են տալիս կատարողականի անկում, երբ սեղմումը միացված է:
Ինչպես միացնել և կարգավորել
Ինչպես նշվեց վերևում, Apache Ignite-ի նվազագույն տարբերակը, որն աջակցում է սկավառակի էջի սեղմմանը, 2.8 է և աջակցվում է միայն Linux օպերացիոն համակարգը: Միացնել և կարգավորել հետևյալ կերպ.
- Դասընթացի մեջ պետք է լինի բռնկման սեղմման մոդուլ: Լռելյայնորեն այն գտնվում է Apache Ignite բաշխման մեջ libs/ընտրովի գրացուցակում և ներառված չէ դասի ուղու մեջ։ Դուք պարզապես կարող եք գրացուցակը մեկ մակարդակ վերև տեղափոխել 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 խտացումն արդեն աշխատում է արխիվային հատվածների հետ: Բացի այդ, որպես առանձին թեմա, այն վերահսկում է անցակետի կատարումը և սկսում սեղմումը արխիվային հատվածներում, որոնց համար ֆիզիկական գրառումներն այլևս կարիք չունեն:
Կատարման ազդեցություն
Քանի որ 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/ընտրովի գրացուցակում և ներառված չէ դասի ուղու մեջ։ Դուք պարզապես կարող եք գրացուցակը մեկ մակարդակ վերև տեղափոխել libs, այնուհետև, երբ այն գործարկեք ignite.sh-ի միջոցով, այն ավտոմատ կերպով միացված կլինի:
- Համառությունը պետք է միացված լինի (Միացված է միջոցով
DataRegionConfiguration.setPersistenceEnabled(true)). - Սեղմման ռեժիմը պետք է սահմանվի մեթոդով
DataStorageConfiguration.setWalPageCompression(), սեղմումն անջատված է լռելյայնորեն (DISABLED ռեժիմ): - Ընտրովի, դուք կարող եք սահմանել սեղմման մակարդակը՝ օգտագործելով մեթոդը
DataStorageConfiguration.setWalPageCompression(), տես javadoc-ը յուրաքանչյուր ռեժիմի համար վավեր արժեքների մեթոդի համար:
Ամփոփում
Apache Ignite-ում դիտարկված տվյալների սեղմման մեխանիզմները կարող են օգտագործվել միմյանցից անկախ, սակայն դրանց ցանկացած համակցություն նույնպես ընդունելի է։ Հասկանալը, թե ինչպես են դրանք աշխատում, թույլ կտա ձեզ որոշել, թե որքանով են դրանք հարմար ձեր միջավայրում կատարվող առաջադրանքների համար և ինչ պետք է զոհաբերեք դրանք օգտագործելիս: Սկավառակի էջի սեղմումը նախատեսված է հիմնական պահեստը սեղմելու համար և կարող է տալ միջին սեղմման հարաբերակցություն: WAL էջի նկարի սեղմումը կտա WAL ֆայլերի սեղմման միջին աստիճան և, ամենայն հավանականությամբ, նույնիսկ կբարելավի կատարումը: WAL սեղմումը դրական ազդեցություն չի ունենա կատարման վրա, բայց հնարավորինս կնվազեցնի WAL ֆայլերի չափը՝ հեռացնելով ֆիզիկական գրառումները:
Source: www.habr.com