Դեռևս «Մեր գաղտնի տիեզերքը. բջիջի թաքնված կյանքը» ֆիլմից
Ներդրումային բիզնեսը բանկային աշխարհի ամենաբարդ ոլորտներից մեկն է, քանի որ կան ոչ միայն վարկեր, փոխառություններ և ավանդներ, այլ նաև արժեթղթեր, արժույթներ, ապրանքներ, ածանցյալ գործիքներ և բոլոր տեսակի բարդություններ՝ կառուցվածքային արտադրանքի տեսքով:
Վերջին շրջանում մենք նկատում ենք բնակչության ֆինանսական գրագիտության աճ։ Ավելի ու ավելի շատ մարդիկ են ներգրավվում արժեթղթերի շուկաներում առևտրի մեջ: Անհատական ներդրումային հաշիվները հայտնվել են ոչ վաղ անցյալում: Նրանք թույլ են տալիս առևտուր անել արժեթղթերի շուկաներում և կամ ստանալ հարկային նվազեցումներ, կամ խուսափել հարկեր վճարելուց: Եվ բոլոր հաճախորդները, ովքեր գալիս են մեզ մոտ, ցանկանում են կառավարել իրենց պորտֆելը և տեսնել հաշվետվությունները իրական ժամանակում: Ավելին, ամենից հաճախ այս պորտֆելը բազմապրոդուկտ է, այսինքն՝ մարդիկ տարբեր բիզնես ուղղությունների հաճախորդներ են։
Բացի այդ, աճում են ինչպես ռուսաստանյան, այնպես էլ արտասահմանյան կարգավորիչների կարիքները:
Ընթացիկ կարիքները բավարարելու և ապագա արդիականացման հիմքերը դնելու համար մենք մշակել ենք ներդրումային բիզնեսի առանցք՝ հիմնված Tarantool-ի վրա:
Որոշ վիճակագրություն. Alfa-Bank-ի ներդրումային բիզնեսը բրոքերային ծառայություններ է մատուցում ֆիզիկական և իրավաբանական անձանց՝ տարբեր արժեթղթերի շուկաներում առևտուր իրականացնելու հնարավորություն, արժեթղթերի պահպանման դեպոզիտար ծառայություններ, մասնավոր և խոշոր կապիտալ ունեցող անձանց հավատարմագրային կառավարման ծառայություններ, այլ ընկերությունների համար արժեթղթերի թողարկման ծառայություններ։ . Alfa-Bank-ի ներդրումային բիզնեսը ներառում է վայրկյանում ավելի քան 3 հազար գնանշումներ, որոնք ներբեռնվում են տարբեր առևտրային հարթակներից։ Աշխատանքային օրվա ընթացքում բանկի կամ նրա հաճախորդների անունից շուկաներում կնքվում է ավելի քան 300 հազար գործարք։ Արտաքին և ներքին հարթակներում վայրկյանում տեղի է ունենում մինչև 5 հազար պատվերի կատարում։ Միևնույն ժամանակ, բոլոր հաճախորդները՝ և՛ ներքին, և՛ արտաքին, ցանկանում են իրական ժամանակում տեսնել իրենց դիրքերը:
նախապատմությանը
Ինչ-որ տեղ 2000-ականների սկզբից մեր ներդրումային բիզնեսի ոլորտները զարգանում էին ինքնուրույն՝ բորսայական առևտուր, բրոքերային ծառայություններ, արժույթի առևտուր, արժեթղթերի և տարբեր ածանցյալ գործիքների արտաբորսային առևտուր: Արդյունքում մենք ընկել ենք ֆունկցիոնալ հորերի թակարդը։ Ինչ է դա? Բիզնեսի յուրաքանչյուր գիծ ունի իր սեփական համակարգերը, որոնք կրկնօրինակում են միմյանց գործառույթները: Յուրաքանչյուր համակարգ ունի իր տվյալների մոդելը, թեև դրանք գործում են նույն հասկացություններով՝ գործարքներ, գործիքներ, կոնտրագենտներ, գնանշումներ և այլն: Եվ երբ յուրաքանչյուր համակարգ զարգանում էր ինքնուրույն, ի հայտ եկավ տեխնոլոգիաների բազմազան կենդանաբանական այգի:
Բացի այդ, համակարգերի կոդային բազան արդեն բավականին հնացած է, քանի որ որոշ ապրանքներ առաջացել են 1990-ականների կեսերին։ Եվ որոշ ոլորտներում դա դանդաղեցրեց զարգացման գործընթացը, և կատարողական խնդիրներ կային:
Նոր լուծման պահանջներ
Գործարարները հասկացել են, որ տեխնոլոգիական վերափոխումը կենսական նշանակություն ունի հետագա զարգացման համար: Մեզ առաջադրանքներ տրվեցին.
- Հավաքեք բոլոր բիզնես տվյալները մեկ, արագ պահեստավորման և տվյալների մեկ մոդելի մեջ:
- Մենք չպետք է կորցնենք կամ փոխենք այս տեղեկատվությունը:
- Տվյալները պետք է տարբերակել, քանի որ ցանկացած պահի կարգավորողը կարող է նախորդ տարիների վիճակագրություն խնդրել։
- Մենք ոչ միայն պետք է բերենք նոր, մոդայիկ DBMS, այլ ստեղծենք հարթակ բիզնեսի խնդիրների լուծման համար:
Բացի այդ, մեր ճարտարապետները սահմանում են իրենց պայմանները.
- Նոր լուծումը պետք է լինի ձեռնարկատիրական կարգի, այսինքն՝ այն արդեն փորձարկվի որոշ խոշոր ընկերություններում։
- Լուծման գործառնական ռեժիմը պետք է լինի կարևոր առաքելություն: Սա նշանակում է, որ մենք պետք է միաժամանակ ներկա գտնվենք մի քանի տվյալների կենտրոններում և հանգիստ վերապրենք տվյալների մեկ կենտրոնի անջատումը:
- Համակարգը պետք է լինի հորիզոնական մասշտաբային: Փաստն այն է, որ մեր բոլոր ներկայիս համակարգերը միայն ուղղահայաց մասշտաբային են, և մենք արդեն հարվածում ենք առաստաղին՝ ապարատային հզորության ցածր աճի պատճառով: Հետևաբար, եկել է պահը, երբ գոյատևելու համար մենք պետք է ունենանք հորիզոնական մասշտաբային համակարգ:
- Ի միջի այլոց, մեզ ասացին, որ լուծումը պետք է լինի էժան։
Մենք գնացինք ստանդարտ ճանապարհով. ձևակերպեցինք պահանջները և կապ հաստատեցինք գնումների բաժնի հետ: Այնտեղից մենք ստացանք այն ընկերությունների ցանկը, որոնք, ընդհանուր առմամբ, պատրաստ են դա անել մեզ համար։ Խնդրի մասին պատմեցինք բոլորին, վեցից ստացանք լուծումների գնահատականը։
Բանկում մենք չենք ընդունում որևէ մեկի խոսքը, մենք սիրում ենք ամեն ինչ ինքներս փորձարկել: Ուստի մեր մրցութային մրցույթի պարտադիր պայմանը եղել է բեռնվածության թեստեր անցնելը։ Մենք ձևակերպել ենք բեռնվածության փորձարկման առաջադրանքներ, և վեց ընկերություններից երեքն արդեն համաձայնել են իրենց միջոցներով ներդնել հիշողության տեխնոլոգիաների վրա հիմնված նախատիպ լուծում՝ այն փորձարկելու համար:
Ես ձեզ չեմ ասի, թե ինչպես ենք մենք փորձարկել ամեն ինչ և որքան ժամանակ է պահանջվել, ես պարզապես ամփոփեմ. բեռնվածության թեստերում լավագույն կատարումը ցույց է տվել Mail.ru Group-ի մշակման թիմի Tarantool-ի վրա հիմնված նախատիպ լուծումը: Մենք պայմանագիր ստորագրեցինք և սկսեցինք զարգացումը։ Mail.ru Group-ից չորս հոգի էին, իսկ Alfa-Bank-ից՝ երեք մշակող, երեք համակարգի վերլուծաբան, լուծումների ճարտարապետ, ապրանքի սեփականատեր և Scrum վարպետ։
Հաջորդիվ ես ձեզ կպատմեմ այն մասին, թե ինչպես է աճել մեր համակարգը, ինչպես է այն զարգացել, ինչ ենք արել և ինչու հենց այդպես:
Զարգացում
Առաջին հարցը, որ մենք ինքներս մեզ տվեցինք, այն էր, թե ինչպես ստանալ տվյալներ մեր ներկայիս համակարգերից: Մենք որոշեցինք, որ HTTP-ն բավականին հարմար է մեզ համար, քանի որ բոլոր ներկայիս համակարգերը շփվում են միմյանց հետ՝ ուղարկելով XML կամ JSON HTTP-ով։
Մենք օգտագործում ենք Tarantool-ում ներկառուցված HTTP սերվերը, քանի որ մեզ պետք չէ դադարեցնել SSL նիստերը, և դրա կատարումը մեզ բավարար է։
Ինչպես արդեն ասացի, մեր բոլոր համակարգերը ապրում են տվյալների տարբեր մոդելներում, և մուտքագրման ժամանակ մենք պետք է օբյեկտը բերենք այն մոդելին, որը մենք նկարագրում ենք: Անհրաժեշտ էր լեզու, որը թույլ կտար տվյալների փոխակերպումը: Ընտրեցինք հրամայական Լուա. Մենք գործարկում ենք տվյալների փոխակերպման բոլոր ծածկագրերը ավազարկղում. սա ապահով վայր է, որից այն կողմ գործող կոդը չի անցնում: Դա անելու համար մենք պարզապես բեռնում ենք անհրաժեշտ կոդը՝ ստեղծելով այնպիսի գործառույթներ, որոնք չեն կարող որևէ բան արգելափակել կամ թողնել:
Փոխակերպումից հետո տվյալները պետք է ստուգվեն մեր ստեղծած մոդելի հետ համապատասխանության համար: Մենք երկար քննարկեցինք, թե ինչպիսին պետք է լինի մոդելը և ինչ լեզվով նկարագրենք այն։ Մենք ընտրեցինք Apache Avro-ն, քանի որ լեզուն պարզ է և ունի աջակցություն Tarantool-ից: Մոդելի և մաքսային կոդի նոր տարբերակները կարող են գործարկվել օրական մի քանի անգամ, նույնիսկ ծանրաբեռնվածության տակ կամ առանց, օրվա ցանկացած ժամի և շատ արագ հարմարվել փոփոխություններին:
Ստուգումից հետո տվյալները պետք է պահպանվեն: Մենք դա անում ենք vshard-ի միջոցով (մենք ունենք բեկորների աշխարհա-ցրված կրկնօրինակներ):
Ավելին, յուրահատկությունն այնպիսին է, որ մեզ տվյալներ ուղարկող համակարգերի մեծամասնությանը չի հետաքրքրում՝ մենք ստացել ենք դրանք, թե ոչ։ Դրա համար մենք հենց սկզբից վերանորոգման հերթ ենք իրականացրել։ Ինչ է դա? Եթե ինչ-ինչ պատճառներով օբյեկտը չի ենթարկվում տվյալների վերափոխման կամ ստուգման, մենք դեռ հաստատում ենք ստացումը, բայց միևնույն ժամանակ օբյեկտը պահպանում ենք վերանորոգման հերթում: Այն հետևողական է և գտնվում է բիզնեսի տվյալների հիմնական պահեստում: Մենք անմիջապես դրա համար գրեցինք ադմինիստրատորի ինտերֆեյս, տարբեր չափումներ և ահազանգեր: Արդյունքում մենք չենք կորցնում տվյալները։ Նույնիսկ եթե աղբյուրում ինչ-որ բան փոխվել է, եթե տվյալների մոդելը փոխվել է, մենք անմիջապես կհայտնաբերենք այն և կարող ենք հարմարվել:
Այժմ դուք պետք է սովորեք, թե ինչպես վերականգնել պահպանված տվյալները: Մենք ուշադիր վերլուծեցինք մեր համակարգերը և տեսանք, որ Java-ի և Oracle-ի դասական փաթեթը անպայման պարունակում է ինչ-որ ORM, որը փոխակերպում է տվյալները հարաբերականից օբյեկտի: Ուրեմն ինչու՞ անմիջապես օբյեկտներ չտալ համակարգերին գրաֆիկի տեսքով: Այսպիսով, մենք ուրախությամբ ընդունեցինք GraphQL-ը, որը բավարարում էր մեր բոլոր կարիքները: Այն թույլ է տալիս ստանալ տվյալներ գրաֆիկների տեսքով և դուրս հանել միայն այն, ինչ ձեզ հարկավոր է հենց հիմա: Դուք նույնիսկ կարող եք տարբերակել API-ն բավականին մեծ ճկունությամբ:
Գրեթե անմիջապես հասկացանք, որ մեր արդյունահանվող տվյալները բավարար չեն։ Մենք ստեղծեցինք գործառույթներ, որոնք կարող են կապված լինել մոդելի օբյեկտների հետ՝ ըստ էության, հաշվարկված դաշտեր: Այսինքն՝ դաշտին կցում ենք որոշակի ֆունկցիա, որն, օրինակ, հաշվարկում է միջին գնանշման գինը։ Իսկ տվյալներ պահանջող արտաքին սպառողը նույնիսկ չգիտի, որ սա հաշվարկված դաշտ է։
Իրականացրել է նույնականացման համակարգ:
Հետո նկատեցինք, որ մեր որոշման մեջ բյուրեղացան մի քանի դերեր։ Դերը ֆունկցիաների մի տեսակ ագրեգատոր է։ Որպես կանոն, դերերն ունեն սարքավորումների օգտագործման տարբեր պրոֆիլներ.
- T-Connect. կարգավորում է մուտքային կապերը, CPU-ն սահմանափակ է, հիշողության ցածր սպառում, քաղաքացիություն չունեցող:
- IB-Core. փոխակերպում է Tarantool արձանագրության միջոցով ստացած տվյալները, այսինքն՝ գործում է աղյուսակներով: Այն նաև չի պահում վիճակը և մասշտաբային է:
- Պահպանում. միայն պահպանում է տվյալները, չի օգտագործում որևէ տրամաբանություն: Այս դերն իրականացնում է ամենապարզ միջերեսները: Ընդարձակելի vshard-ի շնորհիվ:
Այսինքն, օգտագործելով դերեր, մենք անջատեցինք կլաստերի տարբեր մասերը միմյանցից, որոնք կարող են մասշտաբավորվել միմյանցից անկախ:
Այսպիսով, մենք ստեղծել ենք ասինխրոն գործարքային տվյալների հոսքի ձայնագրում և վերանորոգման հերթ՝ ադմինիստրատորի միջերեսով: Ձայնագրությունը բիզնեսի տեսանկյունից ասինխրոն է. եթե մեզ երաշխավորված է տվյալներ գրել մեզ համար, անկախ նրանից, թե որտեղ, ապա մենք դա կհաստատենք։ Եթե այն չի հաստատվել, ապա ինչ-որ բան սխալ է տեղի ունեցել, և տվյալները պետք է ուղարկվեն: Սա ասինխրոն ձայնագրությունն է։
Փորձարկում
Ծրագրի հենց սկզբից մենք որոշեցինք, որ փորձելու ենք իրականացնել թեստային զարգացում։ Մենք գրում ենք միավորի թեստեր Lua-ում՝ օգտագործելով tarantool/tap frame-ը, իսկ Python-ում ինտեգրման թեստերը՝ օգտագործելով pytest շրջանակը: Միևնույն ժամանակ, մենք ներգրավում ենք և՛ մշակողներին, և՛ վերլուծաբաններին ինտեգրացիոն թեստեր գրելիս:
Ինչպե՞ս ենք մենք օգտագործում թեստային զարգացումը:
Եթե ցանկանում ենք ինչ-որ նոր հատկություն, ապա նախ փորձում ենք դրա համար թեստ գրել: Երբ մենք վրիպակ ենք հայտնաբերում, նախ թեստ ենք գրում և հետո միայն ուղղում այն: Սկզբում դժվար է այսպես աշխատել, կա թյուրիմացություն աշխատակիցների կողմից, նույնիսկ դիվերսիա. Միայն այս «հետո»-ն գրեթե երբեք չի գալիս։
Հետևաբար, դուք պետք է ստիպեք ինքներդ ձեզ նախ գրել թեստեր և խնդրեք ուրիշներին դա անել: Հավատացեք ինձ, թեստի վրա հիմնված զարգացումը օգուտներ է բերում նույնիսկ կարճաժամկետ հեռանկարում: Դուք կզգաք, որ ձեր կյանքն ավելի հեշտ է դարձել։ Մենք զգում ենք, որ կոդի 99%-ն այժմ ծածկված է թեստերով: Սա շատ բան է թվում, բայց մենք ոչ մի խնդիր չունենք. թեստերը կատարվում են յուրաքանչյուր commit-ի վրա:
Այնուամենայնիվ, այն, ինչ մենք ամենաշատն ենք սիրում, ծանրաբեռնվածության փորձարկումն է, մենք այն համարում ենք ամենակարևորը և պարբերաբար իրականացնում:
Ես ձեզ մի փոքրիկ պատմություն կպատմեմ այն մասին, թե ինչպես ենք մենք իրականացրել առաջին տարբերակներից մեկի բեռնվածության փորձարկման առաջին փուլը: Մենք համակարգը տեղադրեցինք մշակողի նոութբուքում, միացրինք բեռնվածությունը և ստացանք վայրկյանում 4 հազար գործարք: Լավ արդյունք նոութբուքի համար: Մենք այն տեղադրեցինք չորս սերվերից բաղկացած վիրտուալ բեռնվածքի նստարանին, ավելի թույլ, քան արտադրության մեջ: Տեղադրված է նվազագույնի: Մենք գործարկում ենք այն, և մենք ավելի վատ արդյունք ենք ստանում, քան նոութբուքի վրա մեկ թեմայում: Շոկային բովանդակություն.
Մենք շատ տխուր էինք։ Մենք նայում ենք սերվերի բեռնվածությանը, բայց պարզվում է, որ դրանք անգործուն են:
Մենք զանգահարում ենք մշակողներին, և նրանք մեզ բացատրում են Java-ի աշխարհից եկած մարդկանց, որ Tarantool-ը մեկ թելային է: Այն կարող է արդյունավետորեն օգտագործվել միայն մեկ պրոցեսորի միջուկի կողմից բեռնվածության տակ: Այնուհետև մենք տեղակայեցինք Tarantool-ի առավելագույն հնարավոր քանակությունը յուրաքանչյուր սերվերի վրա, միացրինք բեռնվածությունը և արդեն ստացանք վայրկյանում 14,5 հազար գործարք:
Նորից բացատրեմ. Ռեսուրսները տարբեր կերպ օգտագործող դերերի բաժանման պատճառով մեր դերերը, որոնք պատասխանատու են կապերի մշակման և տվյալների փոխակերպման համար, բեռնում էին միայն պրոցեսորը և խիստ համաչափ բեռին:
Այս դեպքում հիշողությունը օգտագործվել է միայն մուտքային կապերի և ժամանակավոր օբյեկտների մշակման համար։
Ընդհակառակը, պահեստավորման սերվերների վրա պրոցեսորի ծանրաբեռնվածությունն ավելացել է, բայց շատ ավելի դանդաղ, քան կապերը մշակող սերվերների վրա:
Իսկ հիշողության սպառումն աճել է բեռնված տվյալների քանակի ուղիղ համեմատությամբ:
Ծառայություններ
Մեր նոր արտադրանքը հատուկ որպես կիրառական հարթակ մշակելու համար մենք ստեղծեցինք բաղադրիչ՝ դրա վրա ծառայություններ և գրադարաններ տեղակայելու համար:
Ծառայությունները պարզապես կոդի փոքր կտորներ չեն, որոնք գործում են որոշ դաշտերում: Դրանք կարող են լինել բավականին մեծ և բարդ կառուցվածքներ, որոնք կլաստերի մաս են կազմում, ստուգում են հղման տվյալները, գործարկում բիզնեսի տրամաբանությունը և վերադարձնում պատասխանները: Մենք նաև արտահանում ենք ծառայությունների սխեման GraphQL, և սպառողը ստանում է տվյալների համընդհանուր մուտքի կետ՝ ամբողջ մոդելի ներդաշնակությամբ: Շատ հարմարավետ է։
Քանի որ ծառայությունները պարունակում են շատ ավելի շատ գործառույթներ, մենք որոշեցինք, որ պետք է լինեն գրադարաններ, որտեղ մենք կտեղափոխենք հաճախ օգտագործվող ծածկագիրը: Մենք դրանք ավելացրել ենք անվտանգ միջավայր՝ նախապես ստուգելով, որ այն մեզ համար ոչինչ չի կոտրում։ Եվ հիմա մենք կարող ենք լրացուցիչ միջավայրեր հատկացնել գործառույթներին գրադարանների տեսքով:
Մենք ցանկանում էինք ունենալ հարթակ ոչ միայն պահեստավորման, այլ նաև հաշվարկների համար: Եվ քանի որ մենք արդեն ունեինք մի փունջ կրկնօրինակներ և բեկորներ, մենք իրականացրեցինք մի տեսակ բաշխված հաշվարկ և այն անվանեցինք քարտեզի կրճատում, քանի որ այն նման էր բնօրինակ քարտեզի կրճատմանը:
Հին համակարգեր
Մեր հին համակարգերից ոչ բոլորը կարող են զանգահարել մեզ HTTP-ով և օգտագործել GraphQL, չնայած նրանք աջակցում են արձանագրությանը: Հետևաբար, մենք ստեղծեցինք մեխանիզմ, որը թույլ է տալիս տվյալների վերարտադրումը այս համակարգերում:
Եթե մեզ մոտ ինչ-որ բան փոխվում է, եզակի գործարկիչները գործարկվում են Storage դերում, և փոփոխություններով հաղորդագրությունը հայտնվում է մշակման հերթում: Այն ուղարկվում է արտաքին համակարգ՝ օգտագործելով առանձին վերարտադրողի դերը: Այս դերը չի պահում վիճակը:
Նոր բարելավումներ
Ինչպես հիշում եք, բիզնեսի տեսանկյունից մենք ասինքրոն ձայնագրություն ենք արել։ Բայց հետո հասկացան, որ դա բավարար չի լինի, քանի որ կա համակարգերի մի դաս, որոնք պետք է անհապաղ պատասխան ստանան գործողության կարգավիճակի մասին։ Այսպիսով, մենք ընդլայնեցինք մեր GraphQL-ը և ավելացրինք մուտացիաները: Դրանք օրգանապես տեղավորվում են տվյալների հետ աշխատելու առկա պարադիգմում: Մեզ համար սա և՛ կարդալու, և՛ գրելու մեկ կետ է մեկ այլ դասի համակարգերի համար:
Մենք նաև հասկացանք, որ միայն ծառայությունները մեզ չեն բավարարի, քանի որ բավականին ծանր հաշվետվություններ կան, որոնք պետք է պատրաստել օրը, շաբաթը, ամիսը մեկ անգամ։ Սա կարող է երկար ժամանակ տևել, և հաշվետվությունները կարող են նույնիսկ արգելափակել Tarantool-ի իրադարձությունների հանգույցը: Հետևաբար, մենք ստեղծեցինք առանձին դերեր՝ ժամանակացույց և վազող: Վազողները պետություն չեն պահում: Նրանք կատարում են ծանր առաջադրանքներ, որոնք մենք չենք կարող հաշվարկել թռիչքի ժամանակ: Եվ ժամանակացույցի դերը վերահսկում է այս առաջադրանքների գործարկման ժամանակացույցը, որը նկարագրված է կազմաձևում: Առաջադրանքները պահվում են նույն տեղում, ինչ բիզնեսի տվյալները: Երբ գալիս է ճիշտ ժամանակը, ժամանակացույցը վերցնում է առաջադրանքը, տալիս այն ինչ-որ վազորդի, որը հաշվում է այն և պահպանում արդյունքը:
Ոչ բոլոր առաջադրանքները պետք է կատարվեն ժամանակացույցով: Որոշ զեկույցներ պետք է կարդալ ըստ պահանջի: Հենց որ այս պահանջը հասնում է, առաջադրանք է ստեղծվում ավազատուփում և ուղարկվում է վազողին՝ կատարման: Որոշ ժամանակ անց օգտատերը ստանում է ասինխրոն պատասխան, որ ամեն ինչ հաշվարկված է, և հաշվետվությունը պատրաստ է։
Սկզբում մենք հավատարիմ էինք բոլոր տվյալները պահելու, դրանք տարբերակելու և չջնջելու պարադիգմին: Բայց կյանքում ժամանակ առ ժամանակ դեռ պետք է ինչ-որ բան ջնջել, հիմնականում ինչ-որ հում կամ միջանկյալ տեղեկատվություն: Հիմնվելով ժամկետանց տվյալների վրա՝ մենք ստեղծել ենք պահեստը հնացած տվյալներից մաքրելու մեխանիզմ:
Մենք նաև հասկանում ենք, որ վաղ թե ուշ կգա մի իրավիճակ, երբ հիշողության մեջ տվյալները պահելու համար բավարար տարածք չի լինի, բայց, այնուամենայնիվ, տվյալները պետք է պահվեն։ Այս նպատակների համար մենք շուտով կստեղծենք սկավառակի պահեստավորում:
Ամփոփում
Մենք սկսեցինք տվյալներ մեկ մոդելի մեջ բեռնելու առաջադրանքով և երեք ամիս ծախսեցինք դրանք մշակելու համար: Մենք ունեինք տվյալների մատակարարման վեց համակարգ: Ամբողջ փոխակերպման ծածկագիրը մեկ մոդելի կազմում է մոտ 30 հազար տող Լուայում: Իսկ աշխատանքների մեծ մասը դեռ առջեւում է։ Երբեմն հարեւան թիմերի մոտիվացիայի պակաս է զգացվում, իսկ գործը բարդացնող հանգամանքները շատ են։ Եթե երբևէ հանդիպել եք նմանատիպ առաջադրանքի, ապա դրա իրականացման համար ձեզ նորմալ թվացող ժամանակը բազմապատկեք երեքով կամ նույնիսկ չորսով:
Հիշեք նաև, որ բիզնես գործընթացներում առկա խնդիրները չեն կարող լուծվել նոր DBMS-ի միջոցով, նույնիսկ շատ արդյունավետ: Թե ինչ նկատի ունեմ? Մեր նախագծի սկզբում մենք հաճախորդների մոտ տպավորություն ստեղծեցինք, որ այժմ մենք բերելու ենք նոր արագ տվյալների բազա և կապրենք: Գործընթացներն ավելի արագ կընթանան, ամեն ինչ լավ կլինի։ Իրականում տեխնոլոգիան չի լուծում այն խնդիրները, որոնք ունեն բիզնես գործընթացները, քանի որ բիզնես գործընթացները մարդիկ են։ Եվ դուք պետք է աշխատեք մարդկանց հետ, ոչ թե տեխնոլոգիայի:
Թեստի վրա հիմնված զարգացումը կարող է ցավոտ և ժամանակատար լինել վաղ փուլերում: Բայց դրա դրական ազդեցությունը նկատելի կլինի նույնիսկ կարճաժամկետ հեռանկարում, երբ որևէ բան պետք չի լինի ռեգրեսիոն թեստ անցկացնելու համար։
Չափազանց կարևոր է բեռների փորձարկումն իրականացնել զարգացման բոլոր փուլերում: Որքան շուտ նկատեք ճարտարապետության որոշ թերություն, այնքան ավելի հեշտ կլինի այն շտկել, ինչը ձեզ հետագայում շատ ժամանակ կխնայի:
Լուայի հետ ոչ մի վատ բան չկա: Յուրաքանչյուրը կարող է սովորել գրել դրանում՝ Java ծրագրավորող, JavaScript ծրագրավորող, Python ծրագրավորող, front-end կամ back-end: Դրա վրա նույնիսկ մեր վերլուծաբաններն են գրում.
Երբ մենք խոսում ենք այն մասին, որ մենք չունենք SQL, դա սարսափեցնում է մարդկանց: «Ինչպե՞ս եք տվյալներ ստանում առանց SQL-ի: Սա հնարավո՞ր է: Անշուշտ։ OLTP դասի համակարգում SQL-ն անհրաժեշտ չէ: Կա այլընտրանքային տարբերակ՝ լեզվի ձևով, որն անմիջապես ձեզ վերադարձնում է փաստաթղթակենտրոն տեսակետ: Օրինակ, GraphQL. Եվ կա այլընտրանք՝ բաշխված հաշվարկների տեսքով։
Եթե հասկանում եք, որ ձեզ անհրաժեշտ է մասշտաբավորել, ապա նախագծեք ձեր լուծումը Tarantool-ում այնպես, որ այն կարողանա զուգահեռ աշխատել Tarantool-ի տասնյակ օրինակների վրա: Եթե դա չանեք, հետագայում դժվար և ցավոտ կլինի, քանի որ Tarantool-ը կարող է արդյունավետորեն օգտագործել միայն մեկ պրոցեսորի միջուկը:
Source: www.habr.com