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 որպես հիմնական պահեստ
Մեր հաճախորդներից մեկը բժշկական գիտական սարքավորումների խոշոր մատակարար է ԱՄՆ-ից: Նրանք օգտագործում են 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՝ տվյալների բազայի «պատկերապատկեր», որը նման է կոշտ սկավառակի տվյալների բազայի կրկնօրինակմանը, կամ գրել գործարքներ (տեղեկամատյաններ)՝ վերագործարկումից հետո տվյալները վերականգնելու համար:
Սխալ հանդուրժող հավելվածներ ստեղծելու համար
Եկեք պատկերացնենք սխալներին հանդուրժող վեբ հավելվածի դասական ճարտարապետությունը: Այն աշխատում է այսպես. բոլոր հարցումները բաշխվում են սերվերների միջև վեբ հավասարակշռողի կողմից: Այս համակարգը կայուն է, քանի որ սերվերները կրկնօրինակում են միմյանց և ապահովում են կրկնօրինակում միջադեպերի դեպքում:
Բեռնվածության հավասարակշռիչը մեկ սեսիայից բոլոր հարցումները ուղղորդում է միայն մեկ սերվերի։ Սա կպչուն սեսիայի մեխանիզմ է. յուրաքանչյուր սեսիա պարտավոր է սերվեր, որտեղ այն տեղականորեն պահվում և մշակվում է։
Ի՞նչ է պատահում, երբ նրանցից մեկը ձախողվում է։ սերվերներ?
Ծառայությունը չի ազդի, քանի որ ճարտարապետությունը կրկնօրինակված է: Բայց մենք կկորցնենք մեռած սերվերի նիստերի ենթաբազմություն:. Եվ միևնույն ժամանակ այն օգտատերերը, ովքեր կապված են այս նիստերի հետ։ Օրինակ, հաճախորդը պատվեր է տալիս և հանկարծ դուրս է նետվում գրասենյակից: Նա դժգոհ կլինի, երբ նորից մուտք գործի և հայտնաբերի, որ պետք է ամեն ինչ նորից անի:
Պահանջվում է վեբ հավելված՝ մեծ թվով օգտատերերի աջակցելու և «չդանդաղեցնելու» համար, որպեսզի նրանք կարողանան հարմարավետ աշխատել։ Բայց եթե մերժեք, յուրաքանչյուր հաջորդ խնդրանքով նստաշրջանի պահեստի հետ հաղորդակցվելու համար ծախսվող ժամանակը կավելանա: Սա մեծացնում է այլ օգտվողների միջին ուշացումը: Բայց նրանք չեն ցանկանում ավելի երկար սպասել, քան սովոր են:
Այս խնդիրը կարող է լուծվել այնպես, ինչպես արեց մեր մեկ այլ հաճախորդ՝ ԱՄՆ-ից խոշոր PASS մատակարարը: Այն օգտագործում է In-Memory՝ վեբ սեսիաները հավաքելու համար: Դա անելու համար այն պահում է դրանք ոչ թե տեղական, այլ կենտրոնական՝ In-Memory կլաստերում: Այս դեպքում նիստերը հասանելի են շատ ավելի արագ, քանի որ դրանք արդեն RAM-ում են:
Երբ սերվերն իջնում է, հավասարակշռողն անջատված սերվերից հարցումներ է ուղարկում այլ սերվերներ, ինչպես դասական ճարտարապետության դեպքում: Բայց կա մի կարևոր տարբերություն. նիստերը պահվում են In-Memory կլաստերում և սերվերները մուտք ունեն դեպի վթարված սերվերի նիստերը:
Այս ճարտարապետությունը մեծացնում է ամբողջ համակարգի սխալների հանդուրժողականությունը: Ավելին, կարելի է ամբողջությամբ հրաժարվել կպչուն նիստերի մեխանիզմից։
Հիբրիդային գործարքների վերլուծական մշակում (HTAP)
Սովորաբար, գործարքային և վերլուծական համակարգերը պահվում են առանձին: Երբ նրանք առանձնանում են, հիմնական բազան անցնում է ծանրաբեռնվածության: Վերլուծական մշակման համար տվյալները պատճենվում են կրկնօրինակի վրա, որպեսզի վերլուծական մշակումը չխանգարի գործարքների գործընթացներին: Բայց պատճենահանումը գալիս է ուշացումով - առանց հետաձգման անհնար է կրկնօրինակել: Եթե մենք դա անենք համաժամանակյա, դա նույնպես կդանդաղեցնի հիմնական բազան, և մենք ոչ մի շահում չենք ստանա:
HTAP-ում ամեն ինչ այլ կերպ է աշխատում. տվյալների նույն պահեստն օգտագործվում է հավելվածներից գործարքային բեռի և վերլուծական հարցումների համար, որոնց կատարումը կարող է երկար ժամանակ պահանջել: Երբ տվյալները գտնվում են RAM-ում, վերլուծական հարցումներն ավելի արագ են կատարվում, և տվյալների բազայով սերվերը բեռնվում է ավելի քիչ (միջինում):
Հիբրիդային մոտեցումը «կոտրում է պատը» գործարքների մշակման և վերլուծության միջև: Եթե մենք կատարում ենք վերլուծություն նույն պահեստում, ապա վերլուծական հարցումները կատարվում են RAM-ի տվյալների վրա: Դրանք շատ ավելի ճշգրիտ են, ավելի մեկնաբանելի և ադեկվատ։
In-Memory լուծումների ինտեգրում
(համեմատաբար) պարզ ճանապարհն է զարգացնել ամեն ինչ զրոյից. Մենք տվյալները պահում ենք սկավառակի վրա և պահում տաք տվյալները հիշողության մեջ: Սա օգնում է ձեզ գոյատևել սերվերի վերագործարկումից կամ անջատումներից:
Այստեղ գործում է երկու հիմնական սցենար, երբ տվյալները պահվում են սկավառակի վրա: Առաջինում մենք ցանկանում ենք գոյատևել կլաստերի կամ մասերի խափանումներից կամ նորմալ վերագործարկումներից. մենք ցանկանում ենք այն օգտագործել որպես պարզ տվյալների բազա: Երկրորդ սցենարում, երբ չափազանց շատ տվյալներ կան, դրանց մի մասը գտնվում է հիշողության մեջ:
Եթե հնարավոր չէ ամեն ինչ կառուցել զրոյից, ապա հնարավոր է ինտեգրել In-Memory-ը գոյություն ունեցող գոյություն ունեցող ճարտարապետություն. Բայց ոչ բոլոր In-Memory լուծումներն են հարմար դրա համար: Կան երեք պարտադիր պայման. In-Memory լուծումը պետք է աջակցի.
- տվյալների բազայի հետ միանալու ստանդարտ եղանակ, որը կլինի դրա տակ (օրինակ, MySQL);
- ստանդարտ հարցման լեզու՝ պահեստավորման հետ փոխազդեցության տրամաբանությունը վերագրելուց և փոփոխելուց խուսափելու համար.
- գործառնականություն - պահպանել փոխազդեցության իմաստաբանությունը:
Եթե երեք պայմաններն էլ կատարվեն, ապա հնարավոր է ինտեգրում։ Մենք տեղադրում ենք In-Memory Data Grid-ը հավելվածի և տվյալների բազայի միջև: Այժմ գրելու հարցումները կփոխանցվեն ներքևի շտեմարան, իսկ կարդալու հարցումները կփոխանցվեն տվյալների բազա, եթե տվյալները քեշում չեն:
Եթե դուք կարևորում եք տվյալներին արագ մուտք գործելը և դրանց մշակումը, օրինակ՝ բիզնես վերլուծության համար, կարող եք մտածել In-Memory-ի ներդրման մասին։ Եվ իրականացման համար, նոր ճարտարապետություն նախագծելիս կարող եք օգտագործել երկու մեթոդներն էլ։
Source: www.habr.com
