HighLoad++, Միխայիլ Տյուլենև (MongoDB). Պատճառահետևանքային հետևողականություն. տեսությունից մինչև պրակտիկա

Հաջորդ HighLoad++ համաժողովը կանցկացվի 6 թվականի ապրիլի 7-ին և 2020-ին Սանկտ Պետերբուրգում։
Մանրամասներ և տոմսեր по ссылке. HighLoad++ Սիբիր 2019. Դահլիճ «Կրասնոյարսկ». հունիսի 25, ժամը 12:00։ Թեզեր և ներկայացում.

Պատահում է, որ գործնական պահանջները հակասում են տեսությանը, որտեղ առևտրային արտադրանքի համար կարևոր ասպեկտները հաշվի չեն առնվում։ Այս խոսակցությունը ներկայացնում է առևտրային արտադրանքի պահանջների վրա հիմնված ակադեմիական հետազոտությունների վրա հիմնված պատճառահետևանքային հետևողականության բաղադրիչներ ստեղծելու տարբեր մոտեցումների ընտրության և համադրման գործընթաց: Լսողները կծանոթանան տրամաբանական ժամացույցների, կախվածության հետևման, համակարգի անվտանգության, ժամացույցի համաժամացման և ինչու MongoDB-ի որոշ լուծումների վրա հիմնված տեսական մոտեցումների մասին:

Միխայիլ Տյուլենևը (այսուհետ՝ Մ.Տ.). – Ես կխոսեմ պատճառահետևանքային հետևողականության մասին. սա մի առանձնահատկություն է, որը մենք աշխատել ենք MongoDB-ում: Ես աշխատում եմ բաշխված համակարգերի խմբում, մենք դա արել ենք մոտ երկու տարի առաջ:

Ընթացքում ես ստիպված էի ծանոթանալ բազմաթիվ ակադեմիական հետազոտությունների հետ, քանի որ այս հատկանիշը բավականին լավ է ուսումնասիրվել: Պարզվեց, որ ոչ մի հոդված չի տեղավորվում այն ​​ամենի մեջ, ինչ պահանջվում է արտադրության տվյալների բազայում՝ պայմանավորված շատ կոնկրետ պահանջներով, որոնք հավանաբար առկա են ցանկացած արտադրական հավելվածում:

Ես կխոսեմ այն ​​մասին, թե ինչպես մենք՝ որպես ակադեմիական հետազոտության սպառողներ, պատրաստում ենք դրանից մի բան, որը կարող ենք այնուհետև ներկայացնել մեր օգտատերերին որպես պատրաստի ուտեստ, որը հարմար է և անվտանգ օգտագործման համար:

Պատճառահետևանքային հետևողականություն. Եկեք սահմանենք հասկացությունները

Սկսելու համար, ես ուզում եմ ընդհանուր առմամբ ասել, թե ինչ է պատճառահետևանքային հետևողականությունը: Կան երկու կերպարներ՝ Լեոնարդ և Փենին (հեռուստասերիալ «Մեծ պայթյունի տեսություն»).

Ենթադրենք, Փեննին Եվրոպայում է, և Լեոնարդը ցանկանում է նրան անակնկալ երեկույթ կազմակերպել: Եվ նա չի կարող ավելի լավ բան մտածել, քան նրան իր ընկերների ցուցակից հանելն ու իր բոլոր ընկերներին թարմացում ուղարկելով թարմացումների մասին՝ «Եկեք ուրախացնենք Պեննիին»: (նա Եվրոպայում է, մինչ նա քնում է, նա չի տեսնում այս ամենը և չի կարող տեսնել, քանի որ այնտեղ չէ): Ի վերջո, նա ջնջում է այս գրառումը, ջնջում այն ​​Feed-ից և վերականգնում է մուտքը, որպեսզի նա ոչինչ չնկատի և սկանդալ չլինի:
Այս ամենը լավ է, բայց եկեք ենթադրենք, որ համակարգը բաշխված է, և ամեն ինչ մի փոքր սխալ է ընթանում: Կարող է, օրինակ, պատահել, որ Փենիի մուտքի սահմանափակումը տեղի է ունեցել այս գրառման հայտնվելուց հետո, եթե իրադարձությունները կապված չեն պատճառահետևանքով: Փաստորեն, սա օրինակ է, երբ բիզնես ֆունկցիան իրականացնելու համար պահանջվում է պատճառահետևանքային հետևողականություն (այս դեպքում):

Իրականում դրանք տվյալների բազայի բավականին ոչ տրիվիալ հատկություններ են. շատ քչերն են աջակցում դրանց: Անցնենք մոդելներին։

Հետևողականության մոդելներ

Ի՞նչ է կոնկրետ տվյալների բազաներում հետևողականության մոդելը: Սրանք մի քանի երաշխիքներ են, որոնք տալիս է բաշխված համակարգը, թե ինչ տվյալներ կարող է ստանալ հաճախորդը և ինչ հաջորդականությամբ:

Սկզբունքորեն, բոլոր հետևողականության մոդելները հանգում են նրան, թե որքանով է բաշխված համակարգը նման համակարգին, որն աշխատում է, օրինակ, նոութբուքի մեկ հանգույցի վրա: Եվ ահա թե ինչպես է համակարգը, որն աշխատում է հազարավոր աշխարհաբաշխված «հանգույցների» վրա, նման է նոութբուքին, որտեղ այս բոլոր հատկությունները սկզբունքորեն կատարվում են ավտոմատ կերպով:

Հետևաբար, հետևողականության մոդելները կիրառվում են միայն բաշխված համակարգերի համար: Բոլոր համակարգերը, որոնք նախկինում գոյություն ունեին և գործում էին նույն ուղղահայաց մասշտաբով, նման խնդիրներ չեն ունեցել: Կար մեկ Buffer Cache, և ամեն ինչ միշտ կարդացվում էր դրանից:

Մոդել Strong

Իրականում, հենց առաջին մոդելը Strong-ն է (կամ վերելքի ունակության գիծը, ինչպես հաճախ կոչվում է): Սա հետևողականության մոդել է, որն ապահովում է, որ յուրաքանչյուր փոփոխություն, երբ հաստատվի, որ այն տեղի է ունեցել, տեսանելի է համակարգի բոլոր օգտագործողների համար:

Սա ստեղծում է տվյալների բազայի բոլոր իրադարձությունների գլոբալ կարգը: Սա շատ ուժեղ հետևողականության հատկություն է և, ընդհանուր առմամբ, շատ թանկ է: Այնուամենայնիվ, այն շատ լավ է աջակցվում: Դա պարզապես շատ թանկ է և դանդաղ, այն պարզապես հազվադեպ է օգտագործվում: Սա կոչվում է բարձրանալու ունակություն:

Կա մեկ այլ, ավելի ուժեղ հատկություն, որն ապահովված է Spanner-ում, որը կոչվում է External Consistency: Մենք դրա մասին կխոսենք մի փոքր ուշ:

Պատճառական

Հաջորդը Causal-ն է, ինչի մասին էի խոսում: Ուժեղ և պատճառական միջև կան ևս մի քանի ենթամակարդակներ, որոնց մասին ես չեմ խոսի, բայց դրանք բոլորը հանգում են պատճառահետևանքային: Սա կարևոր մոդել է, քանի որ այն ամենաուժեղն է բոլոր մոդելներից, ամենաուժեղ հետևողականությունը ցանցի կամ միջնապատերի առկայության դեպքում:

Պատճառահետևանքները իրականում իրավիճակ են, երբ իրադարձությունները կապված են պատճառահետևանքային կապով: Շատ հաճախ դրանք ընկալվում են որպես Կարդացեք ձեր իրավունքները հաճախորդի տեսանկյունից: Եթե ​​հաճախորդը դիտարկել է որոշ արժեքներ, նա չի կարող տեսնել արժեքներ, որոնք եղել են անցյալում: Նա արդեն սկսում է տեսնել նախածանցային ընթերցումներ: Ամեն ինչ գալիս է նույն բանին:
Պատճառները՝ որպես հետևողականության մոդել, սերվերի վրա իրադարձությունների մասնակի դասավորությունն է, որի դեպքում բոլոր հաճախորդների իրադարձությունները դիտվում են նույն հաջորդականությամբ: Այս դեպքում Լեոնարդն ու Պեննին։

Վերջապես

Երրորդ մոդելը «Eventual Consistency» է: Սա այն է, ինչ բացարձակապես բոլոր բաշխված համակարգերը աջակցում են, նվազագույն մոդելը, որն ընդհանրապես իմաստ ունի: Դա նշանակում է հետևյալը. երբ մենք ունենք որոշակի փոփոխություններ տվյալների մեջ, ինչ-որ պահի դրանք դառնում են հետևողական։

Նման պահին նա ոչինչ չի ասում, այլապես կվերածվեր Արտաքին հետևողականության. դա բոլորովին այլ պատմություն կլիներ։ Այնուամենայնիվ, սա շատ տարածված մոդել է, ամենատարածվածը: Լռելյայնորեն, բաշխված համակարգերի բոլոր օգտվողներն օգտագործում են «Eventual Consistency»:

Ես ուզում եմ մի քանի համեմատական ​​օրինակներ բերել.

Ի՞նչ են նշանակում այս սլաքները:

• Լատենտություն. Քանի որ հետևողականության ուժը մեծանում է, այն դառնում է ավելի մեծ՝ հասկանալի պատճառներով. դուք պետք է ավելի շատ գրառումներ կատարեք, կլաստերում մասնակցող բոլոր հոսթներից և հանգույցներից հաստատում ստանաք, որ տվյալներն արդեն կան: Ըստ այդմ, «Eventual Consistency»-ն ունի ամենաարագ պատասխանը, քանի որ այնտեղ, որպես կանոն, կարելի է նույնիսկ հիշել, և դա, սկզբունքորեն, բավական կլինի:
• Առկայություն: Եթե ​​մենք դա հասկանում ենք որպես ցանցի ընդմիջումների, միջնորմների կամ ինչ-որ խափանումների առկայության դեպքում արձագանքելու համակարգի կարողություն, ապա անսարքության հանդուրժողականությունը մեծանում է, քանի որ հետևողականության մոդելը նվազում է, քանի որ մեզ համար բավական է, որ մեկ հյուրընկալող ապրի և միևնույն ժամանակ: ժամանակը որոշակի տվյալներ է տալիս: Eventual Consistency-ն ընդհանրապես ոչինչ չի երաշխավորում տվյալների վերաբերյալ. դա կարող է լինել ցանկացած բան:
• Անոմալիաներ. Միաժամանակ, իհարկե, անոմալիաների թիվն ավելանում է։ Strong Consistency-ում դրանք գրեթե ընդհանրապես չպետք է գոյություն ունենան, բայց «Eventual Consistency»-ում դրանք կարող են լինել ամեն ինչ: Հարց է առաջանում՝ ինչո՞ւ են մարդիկ ընտրում «Eventual Consistency»-ն, եթե այն պարունակում է անոմալիաներ: Պատասխանն այն է, որ «Eventual Consistency» մոդելները կիրառելի են, և կան անոմալիաներ, օրինակ՝ կարճ ժամանակահատվածում. հնարավոր է օգտագործել հրաշագործը՝ կարդալու և քիչ թե շատ հետևողական տվյալներ կարդալու համար. Հաճախ հնարավոր է օգտագործել ամուր հետևողականության մոդելներ: Գործնականում դա աշխատում է, և հաճախ անոմալիաների քանակը ժամանակի մեջ է սահմանափակվում:

CAP թեորեմ

Երբ տեսնում եք հետևողականություն, մատչելիություն բառերը, ի՞նչ է ձեր մտքով անցնում: Ճիշտ է, CAP թեորեմ: Հիմա ես ուզում եմ ցրել առասպելը... Դա ես չեմ, դա Մարտին Կլեպմանն է, ով հրաշալի հոդված է գրել, հրաշալի գիրք:

CAP թեորեմը 2000-ականներին ձևակերպված սկզբունք է, որ հետևողականություն, հասանելիություն, բաժանումներ. վերցրեք ցանկացած երկու, և դուք չեք կարող ընտրել երեքը: Դա որոշակի սկզբունք էր. Այն որպես թեորեմ ապացուցվեց մի քանի տարի անց Գիլբերտի և Լինչի կողմից։ Այնուհետև սա սկսեց օգտագործվել որպես մանտրա - համակարգերը սկսեցին բաժանվել CA, CP, AP և այլն:

Այս թեորեմն իրականում ապացուցվել է հետևյալ դեպքերի համար... Նախ՝ Հասանելիությունը դիտարկվել է ոչ որպես շարունակական արժեք՝ զրոյից մինչև հարյուրավոր (0 - համակարգը «մեռած է», 100 - արագ արձագանքում է, մենք սովոր ենք այդպես դիտարկել) , բայց որպես ալգորիթմի հատկություն, որը երաշխավորում է, որ իր բոլոր կատարումների համար այն վերադարձնում է տվյալներ։

Պատասխանի ժամանակի մասին խոսք չկա ընդհանրապես։ Կա մի ալգորիթմ, որը վերադարձնում է տվյալները 100 տարի հետո՝ բացարձակապես հրաշալի հասանելի ալգորիթմ, որը CAP թեորեմի մի մասն է։
Երկրորդ. թեորեմն ապացուցվել է նույն բանալի արժեքների փոփոխությունների համար, չնայած այն հանգամանքին, որ այդ փոփոխությունները չափափոխելի են: Սա նշանակում է, որ իրականում դրանք գործնականում չեն օգտագործվում, քանի որ մոդելները տարբերվում են «Eventual Consistency», «Strong Consistency» (գուցե):

Ինչի՞ համար է այս ամենը: Ավելին, CAP թեորեմը հենց այն ձևով, որով այն ապացուցվել է գործնականում կիրառելի չէ և հազվադեպ է օգտագործվում: Տեսական տեսքով դա ինչ-որ կերպ սահմանափակում է ամեն ինչ։ Ստացվում է որոշակի սկզբունք, որը ինտուիտիվորեն ճիշտ է, բայց ընդհանուր առմամբ ապացուցված չէ։

Պատճառահետևանքային հետևողականությունը ամենաուժեղ մոդելն է

Այն, ինչ տեղի է ունենում հիմա, այն է, որ դուք կարող եք ստանալ բոլոր երեք բաները՝ հետևողականություն, հասանելիություն՝ օգտագործելով միջնորմները: Մասնավորապես, պատճառահետևանքային հետևողականությունը ամենաուժեղ հետևողականության մոդելն է, որը դեռևս գործում է միջնորմների առկայության դեպքում (ցանցում ընդմիջումներ): Այդ իսկ պատճառով այն այդքան մեծ հետաքրքրություն է ներկայացնում, և դրա համար էլ մենք վերցրինք այն։

Նախ՝ այն հեշտացնում է հավելված մշակողների աշխատանքը։ Մասնավորապես, սերվերի կողմից մեծ աջակցության առկայությունը. երբ մեկ հաճախորդի ներսում տեղի ունեցող բոլոր գրառումները երաշխավորված են նույն հաջորդականությամբ մեկ այլ հաճախորդի վրա: Երկրորդ՝ դիմանում է միջնորմներին։

MongoDB ներքին խոհանոց

Հիշելով, որ ճաշ է, տեղափոխվում ենք խոհանոց։ Ես ձեզ կասեմ համակարգի մոդելի մասին, մասնավորապես, թե ինչ է MongoDB-ն նրանց համար, ովքեր առաջին անգամ են լսում նման տվյալների բազայի մասին:

MongoDB-ն (այսուհետ՝ «MongoDB») բաշխված համակարգ է, որն աջակցում է հորիզոնական մասշտաբմանը, այսինքն՝ բեկորացմանը. և յուրաքանչյուր բեկորի մեջ այն նաև աջակցում է տվյալների ավելորդությանը, այսինքն՝ կրկնօրինակմանը:

Sharding-ը MongoDB-ում (ոչ հարաբերական տվյալների բազա) կատարում է ավտոմատ հավասարակշռում, այսինքն՝ փաստաթղթերի յուրաքանչյուր հավաքածու (կամ «աղյուսակ» հարաբերական տվյալների առումով) բաժանվում է մասերի, և սերվերը դրանք ավտոմատ կերպով տեղափոխում է բեկորների միջև:

Query Router-ը, որը բաշխում է հարցումները, հաճախորդի համար որոշակի հաճախորդ է, որի միջոցով այն աշխատում է: Այն արդեն գիտի, թե որտեղ և ինչ տվյալներ են գտնվում, և բոլոր հարցումներն ուղղում է ճիշտ բեկորին:

Մեկ այլ կարևոր կետ. MongoDB-ն միայնակ վարպետ է: Կա մեկ Առաջնային. այն կարող է վերցնել գրառումներ, որոնք աջակցում են այն ստեղներին, որոնք պարունակում է: Դուք չեք կարող Multi-master գրել:

Մենք թողարկեցինք 4.2 - այնտեղ նոր հետաքրքիր բաներ հայտնվեցին: Մասնավորապես, նրանք տեղադրեցին Lucene - որոնում - մասնավորապես գործարկվող java ուղղակիորեն Mongo-ի մեջ, և այնտեղ հնարավոր եղավ որոնումներ կատարել Lucene-ի միջոցով, ինչպես որ Elastica-ում:

Եվ նրանք պատրաստեցին նոր արտադրանք՝ Charts, այն հասանելի է նաև Atlas-ում (Mongo-ի սեփական Cloud): Նրանք ունեն անվճար մակարդակ, դուք կարող եք խաղալ դրա հետ: Ինձ շատ դուր եկավ Charts - տվյալների վիզուալիզացիա, շատ ինտուիտիվ:

Բաղադրիչներ Պատճառահետևանքային հետևողականություն

Ես հաշվել եմ մոտ 230 հոդված, որոնք հրապարակվել են այս թեմայով՝ Լեսլի Լամպերթից: Այժմ իմ հիշողությունից ձեզ կփոխանցեմ այս նյութերից որոշ հատվածներ։

Ամեն ինչ սկսվեց Լեսլի Լամպերթի հոդվածից, որը գրվել է 1970-ականներին։ Ինչպես տեսնում եք, այս թեմայի վերաբերյալ որոշ հետազոտություններ դեռ շարունակվում են: Այժմ պատճառահետևանքային հետևողականությունը հետաքրքրություն է առաջացնում բաշխված համակարգերի զարգացման հետ կապված:

Սահմանափակումները

Ի՞նչ սահմանափակումներ կան: Սա իրականում հիմնական կետերից մեկն է, քանի որ այն սահմանափակումները, որ սահմանում է արտադրական համակարգը, խիստ տարբերվում են ակադեմիական հոդվածներում առկա սահմանափակումներից։ Նրանք հաճախ բավականին արհեստական ​​են:

• Նախ, «MongoDB»-ն միայնակ վարպետ է, ինչպես արդեն ասացի (սա մեծապես պարզեցնում է):
• Մենք կարծում ենք, որ համակարգը պետք է ապահովի մոտ 10 հազար բեկորներ։ Մենք չենք կարող որևէ ճարտարապետական ​​որոշում կայացնել, որը բացահայտորեն կսահմանափակի այս արժեքը:
• Մենք ունենք ամպ, բայց մենք ենթադրում ենք, որ մարդը դեռ պետք է հնարավորություն ունենա, երբ նա ներբեռնում է երկուական տարբերակ, գործարկում այն ​​իր նոութբուքում, և ամեն ինչ հիանալի է աշխատում:
• Մենք ենթադրում ենք մի բան, որը հետազոտությունը հազվադեպ է ենթադրում. արտաքին հաճախորդները կարող են անել այն, ինչ ցանկանում են: MongoDB-ն բաց կոդ է: Համապատասխանաբար, հաճախորդները կարող են լինել այնքան խելացի և զայրացած. նրանք կարող են ցանկանալ կոտրել ամեն ինչ: Մենք ենթադրում ենք, որ բյուզանդական ֆեյլորները կարող են ծագել:
• Արտաքին հաճախորդների համար, որոնք գտնվում են պարագծից դուրս, կա մի կարևոր սահմանափակում. եթե այս գործառույթն անջատված է, ապա չպետք է կատարողականի վատթարացում նկատվի:
• Մեկ այլ կետ ընդհանրապես հակաակադեմիական է՝ նախորդ և ապագա տարբերակների համատեղելիությունը։ Հին դրայվերները պետք է աջակցեն նոր թարմացումներին, իսկ տվյալների բազան պետք է աջակցի հին դրայվերներին:

Ընդհանուր առմամբ, այս ամենը սահմանափակումներ է դնում։

Պատճառահետևանքային հետևողականության բաղադրիչներ

Այժմ ես կխոսեմ որոշ բաղադրիչների մասին: Եթե ​​հաշվի առնենք պատճառահետևանքային հետևողականությունը ընդհանուր առմամբ, մենք կարող ենք ընտրել բլոկներ: Մենք ընտրեցինք որոշակի բլոկին պատկանող աշխատանքներից. Կախվածության հետևում, ժամացույցների ընտրություն, ինչպես կարելի է այս ժամացույցները համաժամեցնել միմյանց հետ և ինչպես ենք ապահովում անվտանգությունը.

Ամբողջական կախվածության հետևում

Ինչու է դա անհրաժեշտ: Այնպես որ, երբ տվյալները կրկնօրինակվում են, յուրաքանչյուր գրառում, յուրաքանչյուր տվյալների փոփոխություն պարունակում է տեղեկատվություն այն մասին, թե ինչ փոփոխություններից է կախված: Առաջին և միամիտ փոփոխությունն այն է, երբ յուրաքանչյուր հաղորդագրություն, որը պարունակում է գրառում, պարունակում է տեղեկատվություն նախորդ հաղորդագրությունների մասին.

Այս օրինակում գանգուր փակագծերի թիվը ռեկորդային թվերն են: Երբեմն արժեքներով այս գրառումները նույնիսկ փոխանցվում են ամբողջությամբ, երբեմն որոշ տարբերակներ փոխանցվում են: Հիմնական բանն այն է, որ յուրաքանչյուր փոփոխություն պարունակում է տեղեկատվություն նախորդի մասին (ակնհայտորեն այս ամենը կրում է իր մեջ):

Ինչու՞ մենք որոշեցինք չօգտագործել այս մոտեցումը (ամբողջական հետևում): Ակնհայտորեն, քանի որ այս մոտեցումն անիրագործելի է. սոցիալական ցանցի ցանկացած փոփոխություն կախված է այդ սոցիալական ցանցի բոլոր նախորդ փոփոխություններից՝ փոխանցելով, ասենք, Facebook-ը կամ VKontakte-ն ամեն թարմացումով: Այնուամենայնիվ, շատ հետազոտություններ կան Full Dependency Tracking-ի վերաբերյալ. դրանք նախասոցիալական ցանցեր են, որոշ իրավիճակներում այն ​​իսկապես աշխատում է:

Բացահայտ կախվածության հետևում

Հաջորդն ավելի սահմանափակ է։ Այստեղ դիտարկվում է նաև տեղեկատվության փոխանցումը, բայց միայն այն, ինչը ակնհայտորեն կախված է: Թե ինչից է կախված, որպես կանոն, որոշվում է Դիմումով։ Երբ տվյալները կրկնօրինակվում են, հարցումը պատասխաններ է տալիս միայն այն դեպքում, երբ նախորդ կախվածությունները բավարարված են, այսինքն՝ ցուցադրված: Սա է էությունը, թե ինչպես է գործում պատճառահետևանքային հետևողականությունը:

Նա տեսնում է, որ 5-րդ գրառումը կախված է 1, 2, 3, 4 գրառումներից, համապատասխանաբար, նա սպասում է, մինչև հաճախորդը մուտք ունենա Փենիի մուտքի որոշմամբ կատարված փոփոխություններին, երբ բոլոր նախորդ փոփոխություններն արդեն անցել են տվյալների բազայում:

Սա նույնպես մեզ չի համապատասխանում, քանի որ դեռ շատ տեղեկատվություն կա, և դա կդանդաղեցնի իրադարձությունները: Մեկ այլ մոտեցում էլ կա...

Lamport Ժամացույց

Նրանք շատ հին են։ Lamport Clock-ը նշանակում է, որ այդ կախվածությունները ծալված են սկալյար ֆունկցիայի մեջ, որը կոչվում է Lamport Clock:

Սկալյար ֆունկցիան ինչ-որ վերացական թիվ է: Այն հաճախ կոչվում է տրամաբանական ժամանակ: Յուրաքանչյուր իրադարձության հետ այս հաշվիչը մեծանում է: Հաշվիչը, որը ներկայումս հայտնի է գործընթացին, ուղարկում է յուրաքանչյուր հաղորդագրություն: Հասկանալի է, որ գործընթացները կարող են չհամաժամեցվել, դրանք կարող են ունենալ բոլորովին այլ ժամանակներ։ Այնուամենայնիվ, համակարգը ինչ-որ կերպ հավասարակշռում է ժամացույցը նման հաղորդագրությունների միջոցով: Ի՞նչ է տեղի ունենում այս դեպքում:

Ես բաժանեցի այդ մեծ բեկորը երկու մասի, որպեսզի պարզ լինի. Ընկերները կարող են ապրել մի հանգույցում, որը պարունակում է հավաքածուի մի մասը, և Feed-ը կարող է ապրել մեկ այլ հանգույցում, որը պարունակում է այս հավաքածուի մի մասը: Պարզ է, թե ինչպես կարող են հունից դուրս գալ։ Սկզբում Feed-ը կասի՝ «Replicated», իսկ հետո՝ Friends: Եթե ​​համակարգը որևէ երաշխիք չտրամադրի, որ Feed-ը չի ցուցադրվի այնքան ժամանակ, քանի դեռ չեն առաքվել նաև Friends-ի կախվածությունները Friends հավաքածուում, ապա մենք կունենանք հենց այն իրավիճակը, որը ես նշեցի:

Դուք տեսնում եք, թե ինչպես է Feed-ի հաշվիչի ժամանակը տրամաբանորեն մեծանում.

Այսպիսով, այս Lamport Ժամացույցի և պատճառահետևանքային հետևողականության հիմնական հատկությունը (բացատրված է Lamport Clock-ի միջոցով) սա է. եթե մենք ունենք իրադարձություններ A և B, և իրադարձություն B կախված է իրադարձություն A*-ից, ապա հետևում է, որ իրադարձության A-ի տրամաբանական ժամանակը փոքր է, քան LogicalTime իրադարձություն B-ից:

* Երբեմն ասում են նաև, որ A-ն տեղի է ունեցել B-ից առաջ, այսինքն, A-ն եղել է B-ից առաջ - սա որոշակի հարաբերություն է, որը մասամբ պատվիրում է իրադարձությունների ամբողջ շարքը, որը տեղի է ունեցել ընդհանրապես:

Հակառակը ճիշտ չէ։ Սա իրականում Lamport Clock-ի հիմնական թերություններից մեկն է՝ մասնակի պատվեր: Գոյություն ունի համաժամանակյա իրադարձությունների մասին հասկացություն, այսինքն՝ իրադարձություններ, որոնցում ոչ (A-ն տեղի է ունեցել B-ից առաջ), ոչ էլ (A-ն եղել է B-ից առաջ): Օրինակ կարող է լինել Լեոնարդի զուգահեռ ավելացումը մեկ ուրիշի որպես ընկեր (նույնիսկ ոչ թե Լեոնարդի, այլ Շելդոնի, օրինակ):
Սա այն հատկությունն է, որը հաճախ օգտագործվում է Lamport-ի ժամացույցների հետ աշխատելիս. նրանք հատուկ նայում են ֆունկցիային և դրանից եզրակացնում են, որ միգուցե այդ իրադարձությունները կախված են: Որովհետև ճանապարհներից մեկը ճիշտ է. եթե LogicalTime A-ն փոքր է LogicalTime B-ից, ապա B-ն չի կարող տեղի ունենալ A-ից առաջ; իսկ եթե ավելին, ապա գուցե:

Վեկտոր Ժամացույց

Lamport ժամացույցի տրամաբանական զարգացումը վեկտորային ժամացույցն է: Նրանք տարբերվում են նրանով, որ այստեղ գտնվող յուրաքանչյուր հանգույց պարունակում է իր առանձին ժամացույցը, և դրանք փոխանցվում են որպես վեկտոր։
Այս դեպքում տեսնում եք, որ վեկտորի զրոյական ինդեքսը պատասխանատու է Feed-ի համար, իսկ վեկտորի առաջին ինդեքսը՝ Friends-ի համար (այս հանգույցներից յուրաքանչյուրը): Եվ հիմա դրանք կավելանան. «Feed»-ի զրոյական ինդեքսը գրելիս մեծանում է՝ 1, 2, 3:

Ինչու՞ է վեկտորային ժամացույցը ավելի լավ: Քանի որ դրանք թույլ են տալիս պարզել, թե որ իրադարձություններն են միաժամանակ և երբ են դրանք տեղի ունենում տարբեր հանգույցներում: Սա շատ կարևոր է MongoDB-ի նման համօգտագործման համակարգի համար: Սակայն մենք սա չընտրեցինք, թեև դա հրաշալի բան է, և հիանալի է ստացվում, և երևի կսազեր մեզ...

Եթե ​​մենք ունենք 10 հազար բեկոր, մենք չենք կարող փոխանցել 10 հազար բաղադրիչ, նույնիսկ եթե այն սեղմենք կամ ինչ-որ այլ բան առաջ քաշենք, օգտակար բեռնվածությունը դեռ մի քանի անգամ փոքր կլինի այս ամբողջ վեկտորի ծավալից: Ուստի, մեր սրտերն ու ատամները կրճտացնելով, մենք թողեցինք այս մոտեցումը և անցանք մյուսին։

Բաց TrueTime: Ատոմային ժամացույց

Ես ասացի, որ Սպանների մասին պատմություն կլինի: Սա հիանալի բան է, ուղղակի XNUMX-րդ դարից. ատոմային ժամացույցներ, GPS համաժամացում:

Ո՞րն է գաղափարը: «Spanner»-ը Google-ի համակարգ է, որը վերջերս նույնիսկ հասանելի է դարձել մարդկանց համար (նրանք SQL են ավելացրել դրան): Այնտեղ յուրաքանչյուր գործարք ունի որոշակի ժամանակի կնիք: Քանի որ ժամանակը համաժամանակացված է*, յուրաքանչյուր իրադարձության կարող է նշանակվել որոշակի ժամանակ. ատոմային ժամացույցներն ունեն սպասման ժամանակ, որից հետո երաշխավորված է «կատարվելու» այլ ժամանակ:

Այսպիսով, պարզապես գրելով տվյալների շտեմարան և սպասելով որոշ ժամանակ, միջոցառման սերիականացումը ավտոմատ կերպով երաշխավորվում է: Նրանք ունեն ամենաուժեղ Consistency մոդելը, որը կարելի է սկզբունքորեն պատկերացնել՝ դա Արտաքին հետևողականությունն է:

* Սա Lampart ժամացույցների հիմնական խնդիրն է. դրանք երբեք սինխրոն չեն բաշխված համակարգերում: Նրանք կարող են շեղվել; նույնիսկ NTP-ի հետ նրանք դեռ այնքան էլ լավ չեն աշխատում: «Spanner»-ն ունի ատոմային ժամացույց և համաժամացումը, կարծես թե, միկրովայրկյան է։

Ինչո՞ւ չընտրեցինք։ Մենք չենք ենթադրում, որ մեր օգտվողներն ունեն ներկառուցված ատոմային ժամացույց: Երբ դրանք հայտնվեն, ներկառուցված լինելով յուրաքանչյուր նոութբուքի մեջ, կլինի ինչ-որ սուպեր սառը GPS համաժամացման, ապա այո... Բայց առայժմ լավագույնը, որ հնարավոր է Amazon-ն է, Base Stations-ը՝ ֆանատիկոսների համար... Այսպիսով, մենք օգտագործեցինք այլ ժամացույցներ: .

Հիբրիդ Ժամացույց

Սա իրականում այն ​​է, ինչ նշում է MongoDB-ում, երբ ապահովում է պատճառահետևանքային հետևողականությունը: Ինչպե՞ս են դրանք հիբրիդային: Հիբրիդը սկալյար արժեք է, բայց այն ունի երկու բաղադրիչ.

• Առաջինը Յունիքսի դարաշրջանն է (քանի վայրկյան է անցել «համակարգչային աշխարհի սկզբից»):
• Երկրորդը որոշակի աճ է, նաև 32-բիթանոց անստորագիր միջերես:

Այսքանը, իրականում: Կա այս մոտեցումը. այն մասը, որը պատասխանատու է ժամանակի համար, անընդհատ համաժամացվում է ժամացույցի հետ. ամեն անգամ, երբ թարմացում է տեղի ունենում, այս հատվածը համաժամացվում է ժամացույցի հետ և պարզվում է, որ ժամանակը միշտ քիչ թե շատ ճիշտ է, և աճը թույլ է տալիս տարբերակել իրադարձությունները, որոնք տեղի են ունեցել ժամանակի նույն կետում:

Ինչու՞ է սա կարևոր MongoDB-ի համար: Քանի որ դա թույլ է տալիս ժամանակի որոշակի կետում ստեղծել ինչ-որ պահուստային ռեստորաններ, այսինքն՝ իրադարձությունը ինդեքսավորվում է ժամանակով: Սա կարևոր է, երբ անհրաժեշտ են որոշակի իրադարձություններ. Տվյալների բազայի համար իրադարձությունները տվյալների բազայի փոփոխություններն են, որոնք տեղի են ունեցել ժամանակի որոշակի ընդմիջումներով:

Ես ձեզ կասեմ ամենակարևոր պատճառը միայն ձեզ համար (խնդրում եմ, ոչ մեկին մի ասեք): Մենք դա արեցինք, քանի որ այսպիսի տեսք ունեն կազմակերպված, ինդեքսավորված տվյալները MongoDB OpLog-ում: OpLog-ը տվյալների կառուցվածք է, որը պարունակում է տվյալների բազայի բացարձակապես բոլոր փոփոխությունները. դրանք սկզբում գնում են OpLog, այնուհետև կիրառվում են հենց Storage-ի վրա, եթե դա կրկնվող ամսաթիվ է կամ բեկոր:

Սա էր հիմնական պատճառը։ Այնուամենայնիվ, կան նաև գործնական պահանջներ տվյալների բազայի մշակման համար, ինչը նշանակում է, որ այն պետք է լինի պարզ՝ փոքր կոդ, հնարավորինս քիչ կոտրված բաներ, որոնք պետք է վերագրվեն և փորձարկվեն: Այն փաստը, որ մեր օպլոգները ինդեքսավորվում էին հիբրիդային ժամացույցներով, շատ օգնեց և թույլ տվեց մեզ ճիշտ ընտրություն կատարել: Այն իսկապես արդյունք տվեց և ինչ-որ կերպ կախարդական կերպով աշխատեց հենց առաջին նախատիպի վրա: Շատ թույն էր։

Ժամացույցի համաժամացում

Գիտական ​​գրականության մեջ նկարագրված են համաժամացման մի քանի մեթոդներ: Ես խոսում եմ համաժամացման մասին, երբ մենք ունենք երկու տարբեր բեկորներ: Եթե ​​կա մեկ կրկնօրինակ հավաքածու, որևէ համաժամացման կարիք չկա. սա «մեկ վարպետ» է; մենք ունենք OpLog, որի մեջ ընկնում են բոլոր փոփոխությունները. այս դեպքում ամեն ինչ արդեն հաջորդաբար պատվիրված է հենց «Oplog»-ում: Բայց եթե մենք ունենք երկու տարբեր բեկորներ, այստեղ ժամանակի համաժամացումը կարևոր է: Այստեղ ավելի շատ օգնեց վեկտորային ժամացույցը: Բայց մենք դրանք չունենք:

Երկրորդը հարմար է՝ սա «Heartbeats» է։ Հնարավոր է փոխանակել որոշ ազդանշաններ, որոնք տեղի են ունենում ժամանակի յուրաքանչյուր միավորի վրա: Բայց սրտի բաբախյունը չափազանց դանդաղ է, մենք չենք կարող մեր հաճախորդին ուշացում ապահովել:

Իսկական ժամանակը, իհարկե, հրաշալի բան է։ Բայց, նորից, սա, հավանաբար, ապագան է... Թեև դա արդեն կարելի է անել Ատլասում, արդեն կան արագ «Amazon» ժամանակի համաժամանակիչներ: Բայց դա հասանելի չի լինի բոլորին:

Բամբասանքն այն է, երբ բոլոր հաղորդագրությունները ներառում են ժամանակ: Սա մոտավորապես այն է, ինչ մենք օգտագործում ենք: Յուրաքանչյուր հաղորդագրություն հանգույցների միջև, վարորդը, տվյալների հանգույցի երթուղիչը, բացարձակապես ամեն ինչ MongoDB-ի համար ինչ-որ տարր է, տվյալների բազայի բաղադրիչ, որը պարունակում է ժամացույց, որն աշխատում է: Նրանք ամենուր հիբրիդային ժամանակի իմաստ ունեն, այն փոխանցվում է։ 64 բիթ? Սա թույլ է տալիս, սա հնարավոր է։

Ինչպե՞ս է այդ ամենը աշխատում միասին:

Այստեղ ես նայում եմ մեկ կրկնօրինակների հավաքածու՝ մի փոքր ավելի հեշտացնելու համար: Կան Առաջնային և Երկրորդական: Երկրորդականը կրկնօրինակում է և միշտ չէ, որ ամբողջությամբ համաժամանակացվում է Հիմնականի հետ:

«Primery»-ի մեջ ներդիր է տեղի ունենում որոշակի ժամանակային արժեքով: Այս ներդիրը մեծացնում է ներքին հաշվարկը 11-ով, եթե սա առավելագույնն է: Կամ այն ​​կստուգի ժամացույցի արժեքները և կհամաժամեցվի ժամացույցի հետ, եթե ժամացույցի արժեքներն ավելի մեծ են: Սա թույլ է տալիս կազմակերպել ըստ ժամանակի:

Այն բանից հետո, երբ նա կատարում է ձայնագրությունը, տեղի է ունենում մի կարևոր պահ. Ժամացույցը գտնվում է «MongoDB»-ում և ավելանում է միայն «Oplog»-ին գրելու դեպքում։ Սա այն իրադարձությունն է, որը փոխում է համակարգի վիճակը։ Բացարձակապես բոլոր դասական հոդվածներում իրադարձություն է համարվում, երբ հաղորդագրությունը հարվածում է հանգույցին. հաղորդագրությունը հասել է, ինչը նշանակում է, որ համակարգը փոխել է իր վիճակը:

Դա պայմանավորված է նրանով, որ հետազոտության ընթացքում լիովին պարզ չէ, թե ինչպես է մեկնաբանվելու այս հաղորդագրությունը։ Մենք հաստատ գիտենք, որ եթե այն արտացոլված չէ «Oplog»-ում, ապա այն որևէ կերպ չի մեկնաբանվի, իսկ համակարգի վիճակի փոփոխությունը միայն «Oplog»-ում մուտք է։ Սա մեզ համար պարզեցնում է ամեն ինչ. մոդելը պարզեցնում է այն և թույլ է տալիս կազմակերպել այն մեկ կրկնօրինակների հավաքածուի և շատ այլ օգտակար բաների մեջ:

«Oplog»-ում արդեն գրված արժեքը վերադարձվում է. մենք գիտենք, որ «Oplog»-ն արդեն պարունակում է այս արժեքը, և դրա ժամանակը 12 է: Այժմ, ասենք, ընթերցումը սկսվում է մեկ այլ հանգույցից (երկրորդական), և այն փոխանցում է ClusterTime-ից հետո: Հաղորդագրություն. Նա ասում է. «Ինձ պետք է այն ամենը, ինչ տեղի է ունեցել առնվազն 12-ից հետո կամ տասներկուսին» (տե՛ս վերևի նկարը):

Սա այն է, ինչ կոչվում է պատճառահետևանքային հետևողական (CAT): Տեսականորեն նման հասկացություն կա, որ սա ժամանակի որոշակի հատված է, որն ինքնին համահունչ է։ Այս դեպքում կարելի է ասել, որ սա համակարգի վիճակն է, որը նկատվել է 12-րդ պահին։

Այժմ այստեղ դեռ ոչինչ չկա, քանի որ այս տեսակը նմանակում է իրավիճակը, երբ Ձեզ անհրաժեշտ է Երկրորդականը՝ առաջնայինից տվյալները կրկնօրինակելու համար: Նա սպասում է... Եվ հիմա տվյալները հասել են. նա հետ է վերադարձնում այս արժեքները:

Դա մոտավորապես այդպես է ամեն ինչ աշխատում: Գրեթե.

Ի՞նչ է նշանակում «գրեթե»: Ենթադրենք, կա մարդ, ով կարդացել և հասկացել է, թե ինչպես է այս ամենը աշխատում։ Ես հասկացա, որ ամեն անգամ, երբ ClusterTime-ը տեղի է ունենում, այն թարմացնում է ներքին տրամաբանական ժամացույցը, իսկ հետո հաջորդ մուտքն ավելանում է մեկով: Այս գործառույթը վերցնում է 20 տող: Ենթադրենք, այս մարդը փոխանցում է ամենամեծ 64-բիթանոց թիվը՝ մինուս մեկ:

Ինչու՞ «մինուս մեկ»: Քանի որ ներքին ժամացույցը կփոխարինվի այս արժեքի մեջ (ակնհայտ է, որ սա ամենամեծ հնարավորն է և ավելի մեծ է, քան ընթացիկ ժամանակը), ապա «Oplog»-ում մուտք կկատարվի, և ժամացույցը կավելացվի մեկ այլ միավորով, և արդեն կա: լինի առավելագույն արժեք (պարզապես կան բոլոր միավորները, այլ տեղ գնալու տեղ չկա) , unsaint ints):

Հասկանալի է, որ սրանից հետո համակարգը դառնում է բացարձակապես անհասանելի որևէ բանի համար։ Այն կարելի է միայն բեռնաթափել և մաքրել՝ շատ ձեռքի աշխատանք: Ամբողջական հասանելիություն.

Ավելին, եթե սա կրկնվում է մեկ այլ տեղ, ապա ամբողջ կլաստերը պարզապես ընկնում է: Բացարձակապես անընդունելի իրավիճակ, որը ցանկացած մարդ կարող է կազմակերպել շատ արագ և հեշտությամբ։ Ուստի այս պահը մենք համարեցինք ամենակարեւորներից մեկը։ Ինչպե՞ս կանխել այն:

Մեր ճանապարհը clusterTime-ի ստորագրումն է

Այսպես է այն փոխանցվում հաղորդագրության մեջ (կապույտ տեքստից առաջ): Բայց մենք նաև սկսեցինք ստեղծել ստորագրություն (կապույտ տեքստ).

Ստորագրությունը ստեղծվում է բանալիով, որը պահվում է տվյալների բազայի ներսում՝ ապահով պարագծի ներսում. ինքնին ստեղծվում և թարմացվում է (օգտատերերը դրա մասին ոչինչ չեն տեսնում): Հաշ է ստեղծվում, և յուրաքանչյուր հաղորդագրություն ստորագրվում է ստեղծման ժամանակ և վավերացվում է ստացվելիս:
Հավանաբար մարդկանց մտքերում հարց է ծագում. «Որքանո՞վ է սա դանդաղեցնում իրերը»: Ես ձեզ ասացի, որ այն պետք է արագ աշխատի, հատկապես այս հատկանիշի բացակայության դեպքում:

Ի՞նչ է նշանակում այս դեպքում օգտագործել պատճառահետևանքային հետևողականություն: Սա afterClusterTime պարամետրը ցույց տալու համար: Առանց դրա, այն, այնուամենայնիվ, պարզապես արժեքներ կփոխանցի: Բամբասելը, սկսած 3.6 տարբերակից, միշտ աշխատում է։

Եթե ​​հեռանանք ստորագրությունների մշտական ​​գեներացիայից, ապա դա կդանդաղեցնի համակարգը նույնիսկ մեր մոտեցումներին ու պահանջներին չհամապատասխանող հատկանիշի բացակայության դեպքում։ Ուրեմն ի՞նչ արեցինք։

Արա՛ դա արագ:

Դա բավականին պարզ բան է, բայց հնարքը հետաքրքիր է. ես կկիսվեմ այն, գուցե ինչ-որ մեկին կհետաքրքրի:
Մենք ունենք հեշ, որը պահպանում է ստորագրված տվյալները: Բոլոր տվյալները անցնում են քեշի միջով: Քեշը նշում է ոչ թե կոնկրետ ժամանակը, այլ Range-ը: Երբ որոշակի արժեք է հասնում, մենք ստեղծում ենք միջակայք, քողարկում ենք վերջին 16 բիթերը և ստորագրում ենք այս արժեքը.

Ստանալով նման ստորագրություն՝ մենք արագացնում ենք համակարգը (համեմատաբար) 65 հազար անգամ։ Այն հիանալի է աշխատում. երբ մենք փորձարկումներ էինք անում, ժամանակն իրականում կրճատվում էր 10 հազար անգամ, երբ մենք ունեինք հաջորդական թարմացում: Հասկանալի է, որ երբ նրանք հակասում են, դա չի աշխատում: Բայց շատ գործնական դեպքերում դա աշխատում է: Range ստորագրության համադրությունը ստորագրության հետ լուծեց անվտանգության խնդիրը։

Ի՞նչ ենք մենք սովորել:

Դասեր, որոնք մենք քաղեցինք սրանից.

• Պետք է կարդալ նյութեր, պատմություններ, հոդվածներ, քանի որ շատ հետաքրքիր բաներ ունենք։ Երբ մենք աշխատում ենք ինչ-որ ֆունկցիայի վրա (հատկապես հիմա, երբ գործարքներ ենք կատարել և այլն), պետք է կարդալ և հասկանալ: Դա ժամանակ է պահանջում, բայց իրականում դա շատ օգտակար է, քանի որ պարզ է դարձնում, թե որտեղ ենք մենք: Մենք կարծես նոր բան չգտանք. մենք պարզապես վերցրինք բաղադրիչները:

  Ընդհանրապես, մտածելու որոշակի տարբերություն կա, երբ կա ակադեմիական կոնֆերանս (օրինակ՝ Սիգմոն)՝ բոլորը կենտրոնանում են նոր գաղափարների վրա։ Ի՞նչ նորություն կա մեր ալգորիթմի մասին: Այստեղ առանձնապես նոր բան չկա։ Նորույթը ավելի շուտ կայանում է նրանում, թե ինչպես ենք մենք համատեղել գոյություն ունեցող մոտեցումները: Հետեւաբար, առաջինը դասականները կարդալն է՝ սկսած Լամփարթից։

• Արտադրության մեջ պահանջները բոլորովին այլ են։ Համոզված եմ, որ ձեզնից շատերը բախվում են ոչ թե «գնդաձև» տվյալների բազաներին վերացական վակուումում, այլ սովորական, իրական բաների, որոնք խնդիրներ ունեն հասանելիության, հետաձգման և սխալների հանդուրժողականության հետ:
• Վերջին բանն այն է, որ մենք պետք է տարբեր գաղափարներ նայեինք և մի քանի բոլորովին տարբեր հոդվածներ միավորենք մեկ մոտեցման մեջ՝ միասին: Ստորագրելու գաղափարը, օրինակ, ընդհանուր առմամբ ծագել է մի հոդվածից, որտեղ դիտարկվում է Պաքսոսի արձանագրությունը, որը ոչ բյուզանդական անհաջողակների համար գտնվում է թույլտվության արձանագրության մեջ, բյուզանդականների համար՝ թույլտվության արձանագրությունից դուրս... Ընդհանրապես, մենք հենց դա է: ավարտվեց անելով:

  Այստեղ բացարձակապես ոչ մի նոր բան չկա։ Բայց հենց որ բոլորը խառնեցինք... Դա նույնն է, ինչ ասենք, որ Օլիվիե աղցանի բաղադրատոմսը անհեթեթություն է, քանի որ ձուն, մայոնեզն ու վարունգն արդեն հորինված են... Նույն պատմության մասին է խոսքը։

Ես կավարտեմ սրանով: Շնորհակալություն!

Հարցեր

Հարց հանդիսատեսից (այսուհետ՝ Բ). - Շնորհակալություն, Միխայիլ, զեկույցի համար: Ժամանակի մասին թեման հետաքրքիր է։ Դուք օգտագործում եք բամբասանքը: Նրանք ասացին, որ յուրաքանչյուրն ունի իր ժամանակը, բոլորը գիտեն իրենց տեղական ժամանակը: Ինչպես հասկանում եմ, մենք ունենք վարորդ. կարող են լինել շատ հաճախորդներ վարորդներով, հարցումներ ծրագրողներ նույնպես, բեկորներ նույնպես... Իսկ ինչի՞ է հանգում համակարգը, եթե հանկարծ մենք ունենք անհամապատասխանություն. ինչ-որ մեկը որոշում է, որ դա նախատեսված է մի րոպե առաջ, մեկը մեկ րոպե ետ? որտե՞ղ ենք հայտնվելու։

MT: - Իսկապես հիանալի հարց է: Ես պարզապես ուզում էի խոսել բեկորների մասին: Եթե ​​ես ճիշտ եմ հասկանում հարցը, ապա մենք ունենք հետևյալ իրավիճակը՝ կա բեկոր 1 և բեկոր 2, ընթերցումը տեղի է ունենում այս երկու բեկորներից՝ դրանք անհամապատասխանություն ունեն, միմյանց հետ չեն փոխազդում, քանի որ իրենց իմացած ժամանակը տարբեր է. հատկապես այն ժամանակ, երբ դրանք գոյություն ունեն օպլոգներում:
Ենթադրենք, որ բեկոր 1-ը կազմել է միլիոն ձայնագրություն, բեկոր 2-ն ընդհանրապես ոչինչ չի արել, և հարցումը հասել է երկու բեկորի: Իսկ առաջինն ունի ավելի քան մեկ միլիոն afterClusterTime: Նման իրավիճակում, ինչպես բացատրեցի, բեկոր 2-ը երբեք ընդհանրապես չի արձագանքի։

IN: – Ես ուզում էի իմանալ, թե ինչպես են նրանք համաժամանակացվում և ընտրում մեկ տրամաբանական ժամանակ:

MT: - Շատ հեշտ է համաժամանակացնել: Շարդը, երբ afterClusterTime-ը գալիս է նրա մոտ, և նա ժամանակ չի գտնում «Oplog»-ում, նախաձեռնում է ոչ մի հաստատում: Այսինքն՝ նա ձեռքերով իր ժամանակը բարձրացնում է այս արժեքին։ Սա նշանակում է, որ այն չունի այս հարցումին համապատասխանող իրադարձություններ: Նա արհեստականորեն ստեղծում է այս իրադարձությունը և այդպիսով դառնում Պատճառահետևողական:

IN: – Իսկ եթե սրանից հետո նրան ինչ-որ այլ իրադարձություններ գան, որոնք ինչ-որ տեղ կորել են ցանցում:

MT: – Շարդը նախագծված է այնպես, որ նրանք այլեւս չգան, քանի որ այն միայնակ վարպետ է: Եթե ​​արդեն ստորագրել է, ուրեմն չեն գա, հետո կգան։ Չի կարող պատահել, որ ինչ-որ բան ինչ-որ տեղ խրվի, հետո նա չգրի, և հետո այս իրադարձությունները հասնեն, և պատճառահետևանքային հետևողականությունը խախտվի: Երբ նա չի գրում, նրանք բոլորը պետք է հաջորդեն (նա կսպասի նրանց):

IN: – Ես մի քանի հարց ունեմ հերթերի հետ կապված։ Պատճառահետևանքային հետևողականությունը ենթադրում է, որ կա գործողությունների որոշակի հերթ, որոնք պետք է կատարվեն: Ի՞նչ կլինի, եթե մեր փաթեթներից մեկը անհետանա: Ահա գալիս է 10-րդը, 11-ը... 12-ը անհետացել է, իսկ մնացածը սպասում են, որ դա իրականանա։ Եվ հանկարծ մեր մեքենան մահացավ, մենք ոչինչ չենք կարող անել: Կա՞ արդյոք այն հերթի առավելագույն երկարությունը, որը կուտակվում է նախքան կատարելը: Ի՞նչ ճակատագրական ձախողում է տեղի ունենում, երբ որևէ պետություն կորչում է: Ավելին, եթե գրենք, որ ինչ-որ նախկին վիճակ կա, ուրեմն ինչ-որ կերպ պետք է սկսել դրանից։ Բայց նրանք նրան չհեռացրին։

MT: - Նաև հիանալի հարց: Ինչ ենք մենք անում? MongoDB-ն ունի քվորում գրել, քվորում կարդալ հասկացությունը: Ո՞ր դեպքերում կարող է հաղորդագրություն կորցնել: Երբ գրելը քվորում չէ, կամ երբ կարդալը քվորում չէ (մի տեսակ աղբ կարող է նաև մնալ):
Պատճառահետևանքային հետևողականության մասով իրականացվել է մեծ փորձնական թեստ, որի արդյունքն այն է, որ այն դեպքում, երբ գրելն ու կարդալը քվորում չեն, տեղի են ունենում պատճառահետևանքային հետևողականության խախտումներ։ Հենց այն, ինչ ասում եք!

Մեր խորհուրդը. Պատճառահետևանքային հետևողականություն օգտագործելիս օգտագործեք առնվազն քվորումի ընթերցում: Այս դեպքում ոչինչ չի կորչի, նույնիսկ եթե կորում է քվորումի գրառումը... Սա ուղղանկյուն իրավիճակ է՝ եթե օգտատերը չի ցանկանում, որ տվյալները կորչեն, նա պետք է օգտագործի քվորումի գրառումը։ Պատճառահետևանքային հետևողականությունը չի երաշխավորում ամրությունը: Երկարակեցությունը երաշխավորված է կրկնօրինակման և վերարտադրության հետ կապված մեքենաների միջոցով:

IN: – Երբ մենք ստեղծում ենք մի օրինակ, որը մեզ համար կատարում է sharding (համապատասխանաբար ոչ թե master, այլ slave), այն հիմնվում է իր սեփական մեքենայի Unix ժամանակի կամ «վարպետի» ժամանակի վրա. Արդյո՞ք այն համաժամացվում է առաջին անգամ, թե պարբերաբար:

MT: -Հիմա պարզաբանեմ. Շարդ (այսինքն՝ հորիզոնական բաժանում) – այնտեղ միշտ առաջնային է: Իսկ բեկորը կարող է ունենալ «վարպետ», և կարող են լինել կրկնօրինակներ: Բայց բեկորը միշտ աջակցում է ձայնագրմանը, քանի որ այն պետք է աջակցի որոշ տիրույթի (բեկորն ունի Առաջնային):

IN: – Այսինքն՝ ամեն ինչ կախված է զուտ «վարպետից»: Արդյո՞ք վարպետության ժամանակը միշտ օգտագործվում է:

MT: -Այո: Դուք կարող եք փոխաբերական իմաստով ասել. ժամացույցը տկտկում է, երբ մուտք է լինում «վարպետ», «Օպլոգ»:

IN: – Մենք ունե՞նք հաճախորդ, որը միանում է և կարիք չունի որևէ բան իմանալու ժամանակի մասին:

MT: - Դուք ընդհանրապես ոչինչ իմանալու կարիք չունեք: Եթե ​​խոսենք այն մասին, թե ինչպես է այն աշխատում հաճախորդի վրա. երբ հաճախորդը ցանկանում է օգտագործել պատճառահետևանքային հետևողականությունը, նա պետք է բացի նիստ: Այժմ ամեն ինչ կա. գործարքներ սեսիայում և իրավունքներ ստանալ... Սեսիան հաճախորդի հետ տեղի ունեցող տրամաբանական իրադարձությունների դասավորությունն է:

Եթե ​​նա բացում է այս նիստը և այնտեղ ասում է, որ ուզում է պատճառահետևանքային հետևողականություն (եթե նիստը լռելյայն աջակցում է պատճառահետևանքային հետևողականությանը), ամեն ինչ ինքնաբերաբար է աշխատում: Վարորդը հիշում է այս ժամանակը և ավելացնում այն, երբ ստանում է նոր հաղորդագրություն։ Այն հիշում է, թե նախորդը ինչ պատասխան է վերադարձրել տվյալները վերադարձնող սերվերից: Հաջորդ հարցումը կպարունակի afterCluster («այսից ավելի ժամանակ»):

Հաճախորդը բացարձակապես ոչինչ իմանալու կարիք չունի: Սա լիովին անթափանց է նրա համար: Եթե ​​մարդիկ օգտագործում են այս հատկանիշները, ի՞նչ կարող են անել: Նախ, դուք կարող եք ապահով կարդալ երկրորդականները. կարող եք գրել Primary-ին և կարդալ աշխարհագրորեն կրկնվող երկրորդականներից և վստահ լինել, որ այն աշխատում է: Միևնույն ժամանակ, սեսիաները, որոնք ձայնագրվել են Հիմնականում, կարող են նույնիսկ տեղափոխվել Երկրորդական, այսինքն՝ կարող եք օգտագործել ոչ թե մեկ նիստ, այլ մի քանիսը:

IN: – Համակարգչային գիտության նոր շերտը՝ CRDT (Conflict-free Replicated Data Types) տվյալների տեսակները, սերտորեն առնչվում է «Eventual Condity» թեմային: Դուք մտածե՞լ եք այս տեսակի տվյալների բազայում ինտեգրելու մասին և ի՞նչ կարող եք ասել դրա մասին:

MT: - Լավ հարց է! CRDT-ն իմաստ ունի գրելու կոնֆլիկտների համար. MongoDB-ում՝ միայնակ վարպետ:

IN: - Ես մի հարց ունեմ deops-ից. Իրական աշխարհում կան նման ճիզվիտական ​​իրավիճակներ, երբ տեղի է ունենում բյուզանդական ձախողում, և չար մարդիկ պաշտպանված պարագծի ներսում սկսում են խոթել արձանագրությունը, հատուկ ձևով ուղարկել արհեստների փաթեթներ:

MT: – Չար մարդիկ շրջապատի ներսում նման են տրոյական ձիու: Չար մարդիկ շրջապատի ներսում կարող են շատ վատ բաներ անել:

IN: – Պարզ է, որ սերվերի վրա, կոպիտ ասած, անցք թողնելը, որի միջով կարող ես փղերի կենդանաբանական այգի դնել և ընդմիշտ փլուզել ամբողջ կլաստերը... Ձեռքով վերականգնման համար ժամանակ կպահանջվի... Սա, մեղմ ասած, սխալ. Մյուս կողմից, սա հետաքրքիր է՝ իրական կյանքում, գործնականում լինում են իրավիճակներ, երբ բնականաբար նման ներքին հարձակումներ են տեղի ունենում։

MT: – Քանի որ իրական կյանքում ես հազվադեպ եմ հանդիպում անվտանգության խախտումների, չեմ կարող ասել, թե արդյոք դրանք տեղի են ունենում: Բայց եթե խոսենք զարգացման փիլիսոփայության մասին, ապա մենք մտածում ենք այսպես. իսկ պարագծի ներսում դուք կարող եք անել այն, ինչ ուզում եք: Հասկանալի է, որ կան օգտատերեր՝ միայն դիտելու ունակությամբ, և կան օգտատերեր, որոնք կարող են ջնջել գրացուցակը։

Կախված իրավունքներից՝ օգտվողների վնասը կարող է լինել մկնիկը կամ փիղը: Հասկանալի է, որ լիարժեք իրավունքներ ունեցող օգտատերը կարող է ընդհանրապես ամեն ինչ անել։ Սահմանափակ իրավունքներով օգտվողը կարող է զգալիորեն ավելի քիչ վնաս պատճառել: Մասնավորապես, դա չի կարող կոտրել համակարգը։

IN: – Պաշտպանված պարագծում ինչ-որ մեկը փորձել է անսպասելի արձանագրություններ ստեղծել սերվերի համար՝ սերվերն ամբողջությամբ ոչնչացնելու համար, և եթե հաջողակ եք, ապա ամբողջ կլաստերը... Երբևէ ստացե՞լ է այդքան «լավը»:

MT: «Ես երբեք նման բաների մասին չեմ լսել». Այն, որ դուք կարող եք խափանել սերվերը այս կերպ, գաղտնիք չէ: Ներսում ձախողում, պրոտոկոլից լինելը, լիազորված օգտատեր լինելը, ով կարող է նման բան գրել հաղորդագրության մեջ... Իրականում, դա անհնար է, քանի որ այն դեռ կստուգվի։ Հնարավոր է անջատել այս նույնականացումը այն օգտատերերի համար, ովքեր դա չեն ցանկանում, ապա դա նրանց խնդիրն է. նրանք, կոպիտ ասած, իրենք են քանդել պատերը, և կարող ես այնտեղ մի փիղ հրել, որը ոտնակոխ կանի... Բայց, ընդհանուր առմամբ, կարելի է վերանորոգողի հագուստ հագնվել, արի ու հանիր։

IN: - Շնորհակալություն զեկույցի համար: Սերգեյ (Յանդեքս). Mong-ում կա հաստատուն, որը սահմանափակում է Replica Set-ում քվեարկող անդամների թիվը, և այս հաստատունը 7 է (յոթ): Ինչու է սա հաստատուն: Ինչու՞ սա ինչ-որ պարամետր չէ:

MT: – Մենք ունենք Replica Sets 40 հանգույցներով: Միշտ մեծամասնություն կա։ Չգիտեմ, թե որ տարբերակը...

IN: – Replica Set-ում դուք կարող եք գործարկել ոչ քվեարկող անդամներ, բայց կան առավելագույնը 7 քվեարկող անդամներ: Ինչպե՞ս կարող ենք գոյատևել անջատումը այս դեպքում, եթե մեր Replica Set-ը տարածված է 3 տվյալների կենտրոններում: Տվյալների մի կենտրոնը հեշտությամբ կարող է անջատվել, իսկ մյուս մեքենան կարող է ընկնել:

MT: – Սա արդեն մի փոքր դուրս է զեկույցի շրջանակներից։ Սա ընդհանուր հարց է։ Միգուցե ես ձեզ ավելի ուշ ասեմ այդ մասին:

Մի քանի գովազդ 🙂

Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, ամպային VPS մշակողների համար $4.99-ից, մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. Ամբողջ ճշմարտությունը VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19 դոլարից կամ ինչպես կիսել սերվերը: (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):

Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 հեռուստացույց $199-ից Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին Ինչպես կառուցել ենթակառուցվածքի կորպ. դաս՝ 730 եվրո արժողությամբ Dell R5xd E2650-4 v9000 սերվերների օգտագործմամբ մեկ կոպեկի համար:

Source: www.habr.com