Ասում են՝ կյանքում ամեն ինչ արժե գոնե մեկ անգամ փորձել։ Իսկ եթե դուք սովոր եք աշխատել հարաբերական DBMS-ների հետ, ապա արժե ծանոթանալ NoSQL-ին գործնականում, առաջին հերթին գոնե ընդհանուր զարգացման համար։ Այժմ այս տեխնոլոգիայի արագ զարգացման շնորհիվ այս թեմայի շուրջ բազմաթիվ հակասական կարծիքներ և բուռն բանավեճեր կան, ինչը հատկապես մեծացնում է հետաքրքրությունը։
Եթե խորանաք այս բոլոր վեճերի էության մեջ, ապա կտեսնեք, որ դրանք առաջանում են սխալ մոտեցման պատճառով։ Նրանք, ովքեր օգտագործում են NoSQL տվյալների բազաները հենց այնտեղ, որտեղ իրենց անհրաժեշտ է, գոհ են և ստանում են այս լուծումից բոլոր առավելությունները: Եվ փորձարարները, ովքեր ապավինում են այս տեխնոլոգիային որպես համադարման, որտեղ այն ընդհանրապես կիրառելի չէ, հիասթափված են՝ կորցնելով հարաբերական տվյալների բազաների ուժեղ կողմերը՝ առանց էական օգուտներ ստանալու:
Ես ձեզ կպատմեմ Cassandra DBMS-ի վրա հիմնված լուծումներ իրականացնելու մեր փորձի մասին. ինչի հետ մենք ստիպված էինք դիմակայել, ինչպես դուրս եկանք բարդ իրավիճակներից, արդյոք կարողացանք օգուտ քաղել NoSQL-ից և որտեղ պետք է լրացուցիչ ջանքեր/միջոցներ ներդնենք: .
Նախնական խնդիրն է ստեղծել համակարգ, որը ձայնագրում է զանգերը ինչ-որ պահեստում:
Համակարգի շահագործման սկզբունքը հետևյալն է. Ներածումը ներառում է հատուկ կառուցվածք ունեցող ֆայլեր, որոնք նկարագրում են զանգի կառուցվածքը: Այնուհետև հավելվածը ապահովում է, որ այս կառուցվածքը պահպանվի համապատասխան սյունակներում: Հետագայում պահպանված զանգերն օգտագործվում են բաժանորդների համար երթևեկության սպառման մասին տեղեկատվությունը ցուցադրելու համար (վճարումներ, զանգեր, մնացորդի պատմություն):
Միանգամայն պարզ է, թե ինչու են նրանք ընտրել Կասանդրան. նա գրում է ավտոմատի պես, հեշտությամբ մասշտաբային է և հանդուրժող սխալների նկատմամբ:
Այսպիսով, սա այն է, ինչ մեզ տվեց փորձը
Այո, ձախողված հանգույցը ողբերգություն չէ: Սա է Կասանդրայի մեղքի հանդուրժողականության էությունը: Բայց հանգույցը կարող է կենդանի լինել և միևնույն ժամանակ սկսել տուժել կատարման մեջ. Ինչպես պարզվեց, դա անմիջապես ազդում է ամբողջ կլաստերի աշխատանքի վրա:
Կասանդրան չի պաշտպանի ձեզ այնտեղ, որտեղ Oracle-ը փրկեց ձեզ իր սահմանափակումներով. Եվ եթե հավելվածի հեղինակը դա նախապես չի հասկացել, ապա Կասանդրայի համար ժամանած դուբլը բնօրինակից վատը չէ։ Երբ այն հասնի, մենք այն կդնենք:
IB-ին կտրականապես դուր չեկավ ազատ Cassandra-ն առանց տուփի. Չկա օգտվողների գործողությունների գրանցում, իրավունքների տարբերակում. Զանգերի մասին տեղեկատվությունը համարվում է անձնական տվյալ, ինչը նշանակում է, որ այն որևէ կերպ պահանջելու/փոխելու բոլոր փորձերը պետք է գրանցվեն՝ հետագա աուդիտի հնարավորությամբ: Բացի այդ, դուք պետք է տեղյակ լինեք տարբեր օգտատերերի համար տարբեր մակարդակներում իրավունքները առանձնացնելու անհրաժեշտության մասին: Պարզ օպերացիոն ինժեները և սուպեր ադմինը, ով կարող է ազատորեն ջնջել ստեղնային տարածքը, տարբեր դերեր, տարբեր պարտականություններ և իրավասություններ են: Առանց մուտքի իրավունքների նման տարբերակման տվյալների արժեքն ու ամբողջականությունը անմիջապես կասկածի տակ կդնեն ավելի արագ, քան ՑԱՆԿԱՑԱԾ հետևողականության մակարդակի դեպքում:
Մենք հաշվի չենք առել, որ զանգերը պահանջում են ինչպես լուրջ վերլուծություն, այնպես էլ պարբերական նմուշառում տարբեր պայմանների համար: Քանի որ ընտրված գրառումներն այնուհետև պետք է ջնջվեն և վերագրվեն (որպես առաջադրանքի մաս, մենք պետք է աջակցենք տվյալների թարմացման գործընթացին, երբ տվյալները ի սկզբանե սխալ են մուտքագրել մեր հանգույցը), Կասանդրան այստեղ մեր ընկերը չէ: Կասանդրան նման է խոզաբուծության. հարմար է իրերը դնել, բայց դրա մեջ չես կարող հաշվել:
Մենք բախվեցինք տվյալների փորձարկման գոտիներ փոխանցելու խնդրի հետ (5 հանգույց թեստում ընդդեմ 20-ի` ավարտական երեկոյում): Այս դեպքում աղբանոցը չի կարող օգտագործվել:
Կասանդրային գրվող հավելվածի տվյալների սխեմայի թարմացման խնդիրը: Հետ վերադարձը կառաջացնի մեծ թվով տապանաքարեր, որոնք կարող են հանգեցնել արտադրողականության կորստի անկանխատեսելի ձևերով:. Cassandra-ն օպտիմիզացված է ձայնագրման համար, և գրելուց առաջ շատ չի մտածում։ Ցանկացած գործողություն, որտեղ առկա տվյալներ կան, նույնպես ձայնագրություն է։ Այսինքն՝ ջնջելով ավելորդը՝ մենք պարզապես կարտադրենք էլ ավելի շատ ձայնագրություններ, և դրանցից միայն մի քանիսը կնշվեն տապանաքարերով։
Տեղադրման ժամանակ ընդհատումներ: Կասանդրան գեղեցիկ է ձայնագրության մեջ, բայց երբեմն մուտքային հոսքը կարող է զգալիորեն գլուխ հանել նրան. Դա տեղի է ունենում, երբ հավելվածը սկսում է պտտվել մի քանի գրառումների շուրջ, որոնք ինչ-ինչ պատճառներով չեն կարող տեղադրվել: Եվ մեզ անհրաժեշտ կլինի իրական DBA, որը կվերահսկի gc.log-ը, համակարգի և վրիպազերծման տեղեկամատյանները դանդաղ հարցումների, խտացման սպասվող չափումների համար:
Մի քանի տվյալների կենտրոններ կլաստերում: Որտեղի՞ց կարդալ և որտեղից գրել:
Միգուցե բաժանվել կարդալու և գրելու: Իսկ եթե այո, գրելու կամ կարդալու դիմումին ավելի մոտ DC պետք է լինի: Եվ մի՞թե մենք չենք ունենա իրական պառակտված ուղեղ, եթե ընտրենք սխալ հետևողականության մակարդակ: Կան շատ հարցեր, շատ անհայտ կարգավորումներ, հնարավորություններ, որոնց հետ դուք իսկապես ուզում եք խճճել:
Ինչպես մենք որոշեցինք
Հանգույցի սուզումը կանխելու համար մենք անջատեցինք SWAP-ը. Իսկ հիմա, եթե հիշողության պակաս կա, հանգույցը պետք է իջնի և չստեղծի մեծ gc դադարներ։
Այսպիսով, մենք այլևս չենք հիմնվում տվյալների բազայում տրամաբանության վրա: Հավելվածների մշակողները վերապատրաստվում են իրենց և սկսում են ակտիվորեն նախազգուշական միջոցներ ձեռնարկել սեփական ծածկագրում: Տվյալների պահպանման և մշակման իդեալական հստակ տարանջատում:
Մենք աջակցություն ենք գնել DataStax-ից: Boxed Cassandra-ի մշակումն արդեն դադարել է (վերջին հանձնումը եղել է 2018 թվականի փետրվարին)։ Միևնույն ժամանակ, Datastax-ն առաջարկում է գերազանց ծառայություն և մեծ թվով փոփոխված և հարմարեցված լուծումներ առկա IP լուծումների համար:
Ուզում եմ նաև նշել, որ Կասանդրան այնքան էլ հարմար չէ ընտրության հարցումների համար։ Իհարկե, CQL-ը մեծ առաջընթաց է օգտատերերի համար (համեմատած Trift-ի հետ): Բայց եթե դուք ունեք ամբողջ բաժանմունքներ, որոնք սովոր են նման հարմար միացումների, անվճար զտում ըստ ցանկացած դաշտի և հարցումների օպտիմալացման հնարավորությունների, և այս բաժիններն աշխատում են բողոքների և պատահարների լուծման ուղղությամբ, ապա Cassandra-ի վերաբերյալ լուծումը նրանց թշնամական և հիմար է թվում: Եվ մենք սկսեցինք որոշել, թե ինչպես պետք է մեր գործընկերները նմուշներ պատրաստեն։
Մենք դիտարկել ենք երկու տարբերակ, առաջին տարբերակում մենք զանգեր ենք գրում ոչ միայն C*-ով, այլ նաև արխիվացված Oracle տվյալների բազայում։ Միայն, ի տարբերություն C*-ի, այս տվյալների բազան պահում է զանգերը միայն ընթացիկ ամսվա համար (զանգերի պահպանման բավարար խորություն վերալիցքավորման դեպքերի համար): Այստեղ մենք անմիջապես տեսանք հետևյալ խնդիրը. եթե մենք գրում ենք սինխրոն, ապա մենք կորցնում ենք C*-ի բոլոր առավելությունները՝ կապված արագ տեղադրման հետ, եթե ասինխրոն ենք գրում, երաշխիք չկա, որ բոլոր անհրաժեշտ զանգերն ընդհանրապես մուտք են գործել Oracle։ Մեկ պլյուս կար, բայց մեծը՝ շահագործման համար մնում է նույն ծանոթ PL/SQL Developer-ը, այսինքն՝ մենք գործնականում իրականացնում ենք «Facade» օրինակը: Այլընտրանքային տարբերակ: Մենք ներդրում ենք մեխանիզմ, որը բեռնաթափում է C*-ից զանգերը, Oracle-ի համապատասխան աղյուսակներից հանում է որոշակի տվյալներ հարստացման համար, միանում ստացված նմուշներին և տալիս մեզ արդյունքը, որն այնուհետև մենք ինչ-որ կերպ օգտագործում ենք (ետ գլորել, կրկնել, վերլուծել, հիանալ): Դեմ. գործընթացը բավականին բազմաքայլ է, և բացի այդ, շահագործման աշխատակիցների համար ինտերֆեյս չկա:
Ի վերջո, մենք կանգ առանք երկրորդ տարբերակի վրա. Apache Spark-ը օգտագործվել է տարբեր տարաներից նմուշառելու համար: Մեխանիզմի էությունը վերածվել է Java կոդի, որը, օգտագործելով նշված ստեղները (բաժանորդ, զանգի ժամանակ - բաժնի ստեղներ) դուրս է բերում տվյալները C*-ից, ինչպես նաև ցանկացած այլ տվյալների բազայից հարստացնելու համար անհրաժեշտ տվյալներ: Որից հետո այն միացնում է դրանք իր հիշողության մեջ և արդյունքը ցուցադրում ստացված աղյուսակում: Մենք կայծի վրա գծեցինք վեբ երես, և այն բավականին օգտագործելի ստացվեց:
Արդյունաբերական թեստային տվյալների թարմացման խնդիրը լուծելիս մենք կրկին դիտարկեցինք մի քանի լուծումներ: Ինչպես փոխանցումը Sstloader-ի միջոցով, այնպես էլ փորձարկման գոտում կլաստերը երկու մասի բաժանելու տարբերակը, որոնցից յուրաքանչյուրը հերթափոխով պատկանում է գովազդայինի հետ նույն կլաստերին, այդպիսով սնուցվում է դրանով: Թեստը թարմացնելիս նախատեսվում էր դրանք փոխանակել՝ թեստում աշխատած մասը մաքրվում է և մտնում արտադրության, իսկ մյուսը սկսում է աշխատել տվյալների հետ առանձին։ Այնուամենայնիվ, նորից մտածելուց հետո մենք ավելի ռացիոնալ գնահատեցինք այն տվյալները, որոնք արժե փոխանցել, և հասկացանք, որ զանգերն ինքնին թեստերի համար անհամապատասխան միավոր են, անհրաժեշտության դեպքում արագ ձևավորվում են, և հենց գովազդային տվյալների հավաքածուն արժեք չունի փոխանցելու համար: փորձարկում. Կան մի քանի պահեստային առարկաներ, որոնք արժե տեղափոխել, բայց դրանք բառացիորեն մի քանի սեղան են, և ոչ շատ ծանր: Հետեւաբար մենք Որպես լուծում, Spark-ը կրկին օգնության եկավ, որի օգնությամբ մենք գրեցինք և սկսեցինք ակտիվորեն օգտագործել աղյուսակների միջև տվյալների փոխանցման սցենար, պրոմ-թեստ:
Մեր ներկայիս տեղակայման քաղաքականությունը մեզ թույլ է տալիս աշխատել առանց հետադարձումների: Պրոմոյից առաջ պարտադիր փորձարկում է, որտեղ սխալն այնքան էլ թանկ չէ։ Անհաջողության դեպքում դուք միշտ կարող եք բաց թողնել գործերի տարածությունը և սկզբից գլորել ամբողջ սխեման:
Cassandra-ի շարունակական հասանելիությունն ապահովելու համար ձեզ անհրաժեշտ է dba և ոչ միայն նա: Յուրաքանչյուր ոք, ով աշխատում է հավելվածի հետ, պետք է հասկանա, թե որտեղ և ինչպես նայել ներկա իրավիճակին և ինչպես ժամանակին ախտորոշել խնդիրները։ Դա անելու համար մենք ակտիվորեն օգտագործում ենք DataStax OpsCenter-ը (աշխատանքային բեռների կառավարում և մոնիտորինգ), Cassandra Driver համակարգի չափումները (C*-ում գրելու ժամկետների քանակը, C*-ից կարդալու ժամկետների քանակը, առավելագույն հետաձգումը և այլն), վերահսկում ենք աշխատանքը: հավելվածի ինքնին, աշխատելով Cassandra-ի հետ:
Երբ մտածեցինք նախորդ հարցի մասին, հասկացանք, թե որտեղ կարող է լինել մեր հիմնական ռիսկը: Սրանք տվյալների ցուցադրման ձևեր են, որոնք ցուցադրում են տվյալներ մի քանի անկախ հարցումներից դեպի պահեստ: Այս կերպ մենք կարող ենք բավականին անհամապատասխան տեղեկատվություն ստանալ: Բայց այս խնդիրը նույնքան արդիական կլիներ, եթե մենք աշխատեինք միայն մեկ տվյալների կենտրոնի հետ: Այսպիսով, այստեղ ամենախելամիտը, իհարկե, խմբաքանակային ֆունկցիա ստեղծելն է երրորդ կողմի հավելվածի տվյալների ընթերցման համար, որը կապահովի տվյալների ստացումը մեկ ժամանակահատվածում: Ինչ վերաբերում է կատարողականության առումով ընթերցանության և գրելու բաժանմանը, ապա այստեղ մեզ կանգնեցրեց այն ռիսկը, որ DC-ների միջև կապի որոշակի կորստի դեպքում մենք կարող ենք հայտնվել երկու կլաստերների հետ, որոնք լիովին անհամապատասխան են միմյանց:
Արդյունքում՝ առայժմ դադարեցվել է EACH_QUORUM գրելու հետևողականության մակարդակում, կարդալու համար՝ LOCAL_QUORUM
Համառոտ տպավորություններ և եզրակացություններ
Ստացված լուծումը գործառնական աջակցության և հետագա զարգացման հեռանկարների տեսանկյունից գնահատելու համար մենք որոշեցինք մտածել, թե էլ որտեղ կարելի է նման զարգացում կիրառել։
Անմիջապես, այնուհետև տվյալների գնահատում այնպիսի ծրագրերի համար, ինչպիսին է «Վճարիր, երբ հարմար է» (մենք բեռնում ենք տեղեկատվությունը C*-ում, հաշվարկ՝ օգտագործելով Spark սկրիպտները), պահանջների հաշվառում՝ ըստ տարածքի, դերերի պահպանում և օգտատերերի մուտքի իրավունքի հաշվարկում՝ ըստ դերի։ մատրիցա.
Ինչպես տեսնում եք, երգացանկը լայն է և բազմազան։ Իսկ եթե ընտրենք NoSQL-ի կողմնակիցների/հակառակորդների ճամբարը, ապա կմիանանք համախոհներին, քանի որ ստացել ենք մեր առավելությունները և հենց այնտեղ, որտեղ սպասում էինք։
Անգամ Cassandra-ի տարբերակը թույլ է տալիս իրական ժամանակում հորիզոնական մասշտաբել՝ բացարձակապես ցավազուրկ լուծելով համակարգում տվյալների ավելացման հարցը։ Մենք կարողացանք տեղափոխել զանգերի ագրեգատների հաշվարկման շատ մեծ բեռնված մեխանիզմը առանձին շղթայի մեջ, ինչպես նաև առանձնացնել կիրառման սխեման և տրամաբանությունը՝ ազատվելով տվյալների բազայում հատուկ գործեր և օբյեկտներ գրելու վատ պրակտիկայից: Մենք հնարավորություն ստացանք ընտրելու և կազմաձևելու, արագացնելու, թե որ DC-ների վրա ենք կատարել հաշվարկներ և որոնց վրա տվյալները կգրանցենք, մենք ապահովագրվեցինք ինչպես առանձին հանգույցների, այնպես էլ ընդհանուր առմամբ DC-ի խափանումներից:
Կիրառելով մեր ճարտարապետությունը նոր նախագծերի վրա և արդեն ունենալով որոշակի փորձ, ես կցանկանայի անմիջապես հաշվի առնել վերը նկարագրված նրբությունները և կանխել որոշ սխալներ, հարթել որոշ սուր անկյուններ, որոնցից ի սկզբանե հնարավոր չէր խուսափել:
Օրինակ, ժամանակին հետևեք Կասանդրայի թարմացումներինքանի որ մեր ստացած խնդիրներից շատերն արդեն հայտնի էին և շտկված:
Մի դրեք և՛ տվյալների բազան, և՛ Spark-ը նույն հանգույցների վրա (կամ խստորեն բաժանեք թույլատրելի ռեսուրսների օգտագործման քանակով), քանի որ Spark-ը կարող է ավելի շատ OP ուտել, քան սպասվում էր, և մենք արագորեն կստանանք թիվ 1 խնդիրը մեր ցուցակից:
Բարելավել մոնիտորինգը և գործառնական իրավասությունը ծրագրի փորձարկման փուլում: Սկզբում հնարավորինս հաշվի առեք մեր լուծման բոլոր պոտենցիալ սպառողները, քանի որ հենց դրանից է կախված լինելու տվյալների բազայի կառուցվածքը:
Պտտեք ստացված շղթան մի քանի անգամ հնարավոր օպտիմալացման համար: Ընտրեք, թե որ դաշտերը կարող են սերիականացվել: Հասկանալ, թե ինչ լրացուցիչ աղյուսակներ պետք է կազմենք, որպեսզի առավելագույնս ճիշտ և օպտիմալ կերպով հաշվի առնենք, և այնուհետև խնդրանքով տրամադրենք պահանջվող տեղեկատվությունը (օրինակ՝ ենթադրելով, որ մենք կարող ենք նույն տվյալները պահել տարբեր աղյուսակներում՝ հաշվի առնելով տարբեր բաշխումները՝ համաձայն տարբեր չափանիշներ, մենք կարող ենք զգալիորեն խնայել պրոցեսորի ժամանակը կարդալու հարցումների համար):
ոչ վատ Անմիջապես տրամադրեք TTL-ի միացում և հնացած տվյալների մաքրում:
Կասանդրայից տվյալներ ներբեռնելիս Հավելվածի տրամաբանությունը պետք է աշխատի FETCH սկզբունքով, որպեսզի ոչ բոլոր տողերը միանգամից բեռնվեն հիշողության մեջ, այլ ընտրվեն խմբաքանակով:
Ցանկալի է նախագիծը նկարագրված լուծմանը տեղափոխելուց առաջ ստուգեք համակարգի սխալների հանդուրժողականությունը՝ մի շարք վթարի թեստեր անցկացնելով, ինչպիսիք են տվյալների կորուստը մեկ տվյալների կենտրոնում, վնասված տվյալների վերականգնումը որոշակի ժամանակահատվածում, ցանցի դուրս գալը տվյալների կենտրոնների միջև: Նման փորձարկումները ոչ միայն թույլ կտան գնահատել առաջարկվող ճարտարապետության դրական և բացասական կողմերը, այլև լավ տաքացման պրակտիկա կապահովեն դրանք վարող ինժեներների համար, և ձեռք բերված հմտությունը հեռու կլինի ավելորդ լինելուց, եթե համակարգի խափանումները վերարտադրվեն արտադրության մեջ:
Եթե մենք աշխատում ենք կրիտիկական տեղեկատվության հետ (օրինակ՝ բիլինգի տվյալները, բաժանորդների պարտքի հաշվարկը), ապա արժե ուշադրություն դարձնել նաև գործիքներին, որոնք կնվազեցնեն DBMS-ի առանձնահատկությունների պատճառով առաջացող ռիսկերը: Օրինակ, օգտագործեք nodesync կոմունալ ծրագիրը (Datastax)՝ մշակելով դրա օգտագործման օպտիմալ ռազմավարություն, որպեսզի հետևողականության համար Կասանդրայի վրա ավելորդ բեռ մի՛ ստեղծեք և օգտագործել այն միայն որոշակի աղյուսակների համար որոշակի ժամանակահատվածում:
Ի՞նչ է պատահում Կասանդրային կյանքի վեց ամսից հետո: Ընդհանուր առմամբ չլուծված խնդիրներ չկան։ Մենք նաև թույլ չենք տվել որևէ լուրջ վթար կամ տվյալների կորուստ: Այո, մենք պետք է մտածեինք նախկինում չծագված որոշ խնդիրների փոխհատուցման մասին, բայց ի վերջո դա մեծապես չմթագրեց մեր ճարտարապետական լուծումը։ Եթե ցանկանում եք և չեք վախենում ինչ-որ նոր բան փորձելուց, և միևնույն ժամանակ չեք ցանկանում շատ հիասթափվել, ապա պատրաստվեք այն փաստին, որ ոչինչ անվճար չէ: Դուք պետք է հասկանաք, խորամուխ լինեք փաստաթղթերի մեջ և հավաքեք ձեր անհատական փոցխն ավելի շատ, քան հին ժառանգական լուծումներում, և ոչ մի տեսություն ձեզ նախապես չի ասի, թե որ փոցխն է ձեզ սպասում:
Source: www.habr.com