In-Memory-ը կոնցեպտների հավաքածու է տվյալների պահպանման համար, երբ դրանք պահվում են հավելվածի RAM-ում, իսկ սկավառակն օգտագործվում է կրկնօրինակման համար: Դասական մոտեցումներում տվյալները պահվում են սկավառակի վրա, իսկ հիշողությունը պահվում է քեշում։ Օրինակ՝ տվյալների մշակման համար նախատեսված վեբ հավելվածը պահանջում է դրանք պահեստավորել. այն ստանում է այն, փոխակերպում է այն և շատ տվյալներ փոխանցվում են ցանցով: In-Memory-ում հաշվարկներն ուղարկվում են տվյալներ՝ պահեստ, որտեղ դրանք մշակվում են, և ցանցն ավելի քիչ բեռնված է:
Ի՞նչ այլ հնարավորություններ կան In-Memory-ի հետ և ինչպիսի՞ մոտեցում է սա: Վլադիմիր Պլիգին - GridGain-ի ինժեներ: Այս վերանայման նյութը օգտակար կլինի վեբ հավելվածների backend մշակողների համար, ովքեր չեն աշխատել In-Memory-ի հետ և ցանկանում են փորձել կամ հետաքրքրված են ծրագրային ապահովման մշակման և ճարտարապետության նախագծման ժամանակակից միտումներով:
Նշում. Հոդվածը հիմնված է #GetIT Conf-ում Վլադիմիրի զեկույցի սղագրության վրա: Մինչ ինքնամեկուսացման ներդրումը, մենք պարբերաբար հանդիպումներ և կոնֆերանսներ էինք կազմակերպում ծրագրավորողների համար Մոսկվայում և Սանկտ Պետերբուրգում. քննարկում էինք միտումները, զարգացման ընթացիկ խնդիրները, խնդիրները և դրանց լուծումները: Այժմ հնարավոր չէ համաժողով անցկացնել, բայց ժամանակն է կիսվել անցյալի օգտակար նյութերով:
Ով և ինչպես է օգտագործում In-Memory-ը
In-Memory-ն առավել հաճախ օգտագործվում է այնտեղ, որտեղ անհրաժեշտ է օգտատիրոջ արագ փոխազդեցություն կամ մեծ քանակությամբ տվյալների մշակում:
- Բանկեր օգտագործել In-Memory-ը, օրինակ՝ նվազեցնելու հետաձգումները, երբ հաճախորդներն օգտագործում են հավելվածներ կամ վերլուծելու հաճախորդին նախքան վարկ տրամադրելը:
- Fintech օգտագործում է In-Memory-ը՝ բարելավելու ծառայությունների և հավելվածների աշխատանքը բանկերի համար, որոնք աութսորսինգ են տրամադրում տվյալների մշակումն ու վերլուծությունը:
- Ապահովագրական ընկերություններՀաշվարկել ռիսկերը, օրինակ՝ վերլուծելով հաճախորդների տվյալները մի քանի տարիների ընթացքում:
- Լոգիստիկ ընկերություններ. Նրանք մշակում են բազմաթիվ տվյալներ, օրինակ՝ հազարավոր պարամետրերով բեռնափոխադրումների և ուղևորափոխադրումների օպտիմալ երթուղիները հաշվարկելու և բեռնափոխադրումների կարգավիճակին հետևելու համար։
- Մանրածախ. In-Memory լուծումներն օգնում են հաճախորդներին ավելի արագ սպասարկել և մշակել մեծ ծավալի տեղեկատվություն՝ առաքումներ, հաշիվ-ապրանքագրեր, գործարքներ, պահեստներում հազարավոր ապրանքների առկայություն և վերլուծական հաշվետվությունների պատրաստում:
- В iot In-Memory-ը փոխարինում է ավանդական տվյալների բազաներին:
- Դեղագործական ընկերությունները օգտագործում են In-Memory-ը, օրինակ, դեղամիջոցների կոմպոզիցիաների համակցությունները տեսակավորելու համար:
Ես ձեզ կասեմ մի քանի օրինակ, թե ինչպես են մեր հաճախորդներն օգտագործում In-Memory լուծումները և ինչպես կարող եք դրանք իրականացնել ինքներդ:
Հիշողության մեջ որպես հիմնական պահեստ
Մեր հաճախորդներից մեկը բժշկական գիտական սարքավորումների խոշոր մատակարար է ԱՄՆ-ից: Նրանք օգտագործում են In-Memory լուծումը որպես տվյալների հիմնական պահեստ: Բոլոր տվյալները պահվում են սկավառակի վրա, և ակտիվորեն օգտագործվող տվյալների ենթաբազմությունը պահվում է RAM-ում: Պահեստավորման հասանելիության մեթոդները ստանդարտ են՝ GDBC (Generic Database Connector) և SQL հարցումների լեզուն:
Հավաքականորեն սա կոչվում է In-Memory Database (IMDB) կամ Memory-Centric Storage: Լուծումների այս դասը բազմաթիվ անուններ ունի, սրանք միակը չեն։
IMDB-ի առանձնահատկությունները.
- Տվյալները, որոնք պահվում են In-Memory-ում և մուտք են գործում SQL-ի միջոցով, նույնն են, ինչ մյուս մոտեցումներում: Դրանք սինխրոնիզացված են, տարբեր է միայն մատուցման եղանակը, դիմելու եղանակը։ Գործառնականությունը գործում է տվյալների միջև:
- IMDB-ն ավելի արագ է, քան հարաբերական տվյալների շտեմարանները, քանի որ ավելի արագ է RAM-ից տեղեկատվություն ստանալը, քան սկավառակից:
- Ներքին օպտիմալացման ալգորիթմներն ավելի քիչ հրահանգներ ունեն:
- IMDB-ները հարմար են հավելվածներում տվյալների, իրադարձությունների և գործարքների կառավարման համար:
IMDB-ները մասամբ աջակցում են ACID՝ ատոմականություն, հետևողականություն և մեկուսացում: Բայց նրանք չեն աջակցում «երկարակեցություն» - երբ հոսանքն անջատված է, բոլոր տվյալները կորչում են: Խնդիրը լուծելու համար դուք կարող եք օգտագործել snapshots՝ տվյալների բազայի «պատկերապատկեր», որը նման է կոշտ սկավառակի տվյալների բազայի կրկնօրինակին, կամ գրանցել գործարքներ (տեղեկամատյաններ)՝ վերագործարկումից հետո տվյալները վերականգնելու համար:
Սխալ հանդուրժող հավելվածներ ստեղծելու համար
Եկեք պատկերացնենք սխալների հանդուրժող վեբ հավելվածի դասական ճարտարապետությունը: Այն աշխատում է այսպես. բոլոր հարցումները բաշխվում են վեբ հավասարակշռողի կողմից սերվերների միջև: Այս համակարգը կայուն է, քանի որ սերվերները կրկնօրինակում են միմյանց և կրկնօրինակում են միջադեպերի դեպքում:
Հավասարակշռողն ուղղորդում է բոլոր հարցումները մեկ նստաշրջանից խիստ մեկ սերվեր: Սա Stick Sesion մեխանիզմ է. յուրաքանչյուր նիստ կապված է սերվերի հետ, որտեղ այն պահվում և մշակվում է տեղում:
Ի՞նչ է տեղի ունենում, երբ սերվերներից մեկը ձախողվում է:
Ծառայությունը չի ազդի, քանի որ ճարտարապետությունը կրկնօրինակված է: Բայց մենք կկորցնենք մեռած սերվերի նիստերի ենթաբազմությունը. Եվ միևնույն ժամանակ այն օգտատերերը, ովքեր կապված են այս նիստերի հետ։ Օրինակ, հաճախորդը պատվեր է տալիս և հանկարծ նրան դուրս է շպրտում գրասենյակից: Նա դժգոհ կլինի, երբ նորից մուտք գործի և հայտնաբերի, որ ամեն ինչ նորից պետք է արվի:
Պահանջվում է վեբ հավելված՝ մեծ թվով օգտատերերի աջակցելու և արագությունը չդանդաղեցնելու համար, որպեսզի նրանք կարողանան հարմարավետ աշխատել։ Բայց եթե այն մերժվի, յուրաքանչյուր հաջորդ խնդրանքով կմեծանա նիստերի խանութի հետ շփվելու ժամանակը: Սա մեծացնում է այլ օգտվողների միջին ուշացումը: Բայց նրանք չեն ցանկանում ավելի երկար սպասել, քան սովոր են:
Այս խնդիրը կարող է լուծվել ինչպես մեր մյուս հաճախորդը՝ ԱՄՆ-ից մեծ PASS մատակարարը: Այն օգտագործում է In-Memory՝ վեբ նիստերը հավաքելու համար: Դա անելու համար այն պահում է դրանք ոչ թե տեղական, այլ կենտրոնական՝ In-Memory կլաստերում: Այս դեպքում նիստերը հասանելի են շատ ավելի արագ, քանի որ դրանք արդեն RAM-ում են:
Երբ սերվերը խափանում է, հավասարակշռողը վթարված սերվերից հարցումներ է ուղարկում այլ սերվերներ, ինչպես դասական ճարտարապետության մեջ: Բայց կա մի կարևոր տարբերություն. նիստերը պահվում են In-Memory կլաստերում և սերվերները մուտք ունեն դեպի ընկած սերվերի նիստերը:
Այս ճարտարապետությունը մեծացնում է ամբողջ համակարգի սխալների հանդուրժողականությունը: Ավելին, կարելի է ընդհանրապես հրաժարվել stick նիստի մեխանիզմից։
Հիբրիդային գործարքների վերլուծական մշակում (HTAP)
Սովորաբար, գործարքային և վերլուծական համակարգերը պահվում են առանձին: Երբ նրանք առանձնանում են, հիմնական բազան անցնում է ծանրաբեռնվածության: Վերլուծական մշակման համար տվյալները պատճենվում են կրկնօրինակի վրա, որպեսզի վերլուծական մշակումը չխանգարի գործարքների գործընթացներին: Բայց պատճենահանումը տեղի է ունենում ուշացումով. անհնար է կրկնել առանց հետաձգման: Եթե մենք դա անենք համաժամանակյա, դա նույնպես կդանդաղեցնի հիմնական բազան, և մենք ոչ մի շահում չենք ստանա:
HTAP-ում ամեն ինչ այլ կերպ է աշխատում. տվյալների նույն պահեստն օգտագործվում է հավելվածներից գործարքային բեռի և վերլուծական հարցումների համար, որոնց ավարտը կարող է երկար ժամանակ պահանջվել: Երբ տվյալները գտնվում են RAM-ում, վերլուծական հարցումներն ավելի արագ են կատարվում, և տվյալների բազայով սերվերը ավելի քիչ բեռնված է (միջինում):
Հիբրիդային մոտեցումը քանդում է գործարքների մշակման և վերլուծության միջև պատը: Եթե մենք կատարում ենք վերլուծություն նույն պահեստում, ապա վերլուծական հարցումները գործարկվում են RAM-ի տվյալների վրա: Դրանք շատ ավելի ճշգրիտ են, ավելի մեկնաբանելի և ադեկվատ։
In-Memory լուծումների ինտեգրում
(համեմատաբար) պարզ միջոց - զարգացնել ամեն ինչ զրոյից. Մենք տվյալները պահում ենք սկավառակի վրա և պահում տաք տվյալները հիշողության մեջ: Սա օգնում է գոյատևել սերվերի վերագործարկումից կամ անջատումներից:
Այստեղ գործում է երկու հիմնական սցենար, երբ տվյալները պահվում են սկավառակի վրա: Առաջինում մենք ցանկանում ենք գոյատևել կլաստերի կամ մասերի խափանումներից կամ կանոնավոր վերագործարկումներից. մենք ցանկանում ենք այն օգտագործել որպես պարզ տվյալների բազա: Երկրորդ սցենարում, երբ չափազանց շատ տվյալներ կան, դրանց մի մասը գտնվում է հիշողության մեջ:
Եթե հնարավոր չէ ամեն ինչ կառուցել զրոյից, ապա հնարավոր է ինտեգրել In-Memory-ն արդեն իսկ գոյություն ունեցող ճարտարապետություն. Բայց ոչ բոլոր In-Memory լուծումներն են հարմար դրա համար: Կան երեք պարտադիր պայման. In-Memory լուծումը պետք է աջակցի.
- տվյալների բազայի միացման ստանդարտ եղանակ, որը գտնվում է դրա տակ (օրինակ, MySQL);
- ստանդարտ հարցման լեզու, որպեսզի չվերագրվի և չփոխի պահեստի հետ փոխգործակցության տրամաբանությունը.
- գործարքային - պահպանել փոխազդեցության իմաստաբանությունը:
Եթե երեք պայմաններն էլ կատարվեն, ապա հնարավոր է ինտեգրում։ Մենք տեղադրում ենք In-Memory Data Grid-ը հավելվածի և տվյալների բազայի միջև: Այժմ գրելու հարցումները կփոխանցվեն հիմքում ընկած տվյալների բազային, իսկ կարդալու հարցումները կփոխանցվեն հիմքում ընկած տվյալների բազային, եթե տվյալները քեշում չեն:
Եթե ձեզ համար կարևոր է տվյալների արագ մուտքը և դրանց մշակումը, օրինակ՝ բիզնեսի վերլուծության համար, կարող եք մտածել In-Memory-ի ներդրման մասին: Իսկ իրականացման համար դուք կարող եք օգտագործել երկու մեթոդն էլ նոր ճարտարապետություն նախագծելիս։
Source: www.habr.com