InterSystems IRIS DBMS-ն ապահովում է տվյալների պահպանման հետաքրքիր կառուցվածքներ՝ գլոբալներ: Ըստ էության, դրանք բազմամակարդակ ստեղներ են՝ տարբեր լրացուցիչ առավելություններով՝ գործարքների տեսքով, տվյալների ծառերի, կողպեքների և սեփական ObjectScript լեզվով անցնելու արագ գործառույթներով:
Կարդացեք ավելին գլոբալների մասին «Գլոբալները տվյալների պահպանման համար գանձ-սրեր են» հոդվածաշարում.
Ինձ հետաքրքրեց, թե ինչպես են գործարքները իրականացվում գլոբալներում, ինչ առանձնահատկություններ կան։ Ի վերջո, սա բոլորովին այլ կառուցվածք է տվյալների պահպանման համար, քան սովորական աղյուսակները: Շատ ավելի ցածր մակարդակ.
Ինչպես հայտնի է հարաբերական տվյալների բազաների տեսությունից, գործարքների լավ իրականացումը պետք է բավարարի պահանջներին :
Ա - ատոմային (ատոմականություն): Գործարքում կատարված բոլոր փոփոխությունները կամ ընդհանրապես չկան, գրանցվում են:
Գ - հետևողականություն: Գործարքի ավարտից հետո տվյալների բազայի տրամաբանական վիճակը պետք է ներքին համահունչ լինի: Շատ առումներով այս պահանջը վերաբերում է ծրագրավորողին, բայց SQL տվյալների բազաների դեպքում այն վերաբերում է նաև օտար բանալիներին։
Ես - Մեկուսանալ: Զուգահեռաբար կատարվող գործարքները չպետք է ազդեն միմյանց վրա։
D - երկարակյաց: Գործարքի հաջող ավարտից հետո ավելի ցածր մակարդակներում առկա խնդիրները (օրինակ, հոսանքի խափանումը) չպետք է ազդեն գործարքի կողմից փոխված տվյալների վրա:
Գլոբալները ոչ հարաբերական տվյալների կառուցվածքներ են: Դրանք նախատեսված էին շատ սահմանափակ սարքավորումների վրա գերարագ աշխատելու համար: Դիտարկենք գործարքների իրականացումը գլոբալներում՝ օգտագործելով .
IRIS-ում գործարքներն աջակցելու համար օգտագործվում են հետևյալ հրամանները. , , .
1. Ատոմականություն
Ստուգելու ամենահեշտ ձևը ատոմականությունն է: Մենք ստուգում ենք տվյալների բազայի վահանակից:
Kill ^a
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TCOMMITԱյնուհետև մենք եզրակացնում ենք.
Write ^a(1), “ ”, ^a(2), “ ”, ^a(3)Մենք ստանում ենք.
1 2 3Ամեն ինչ լավ է. Ատոմականությունը պահպանվում է. բոլոր փոփոխությունները գրանցվում են:
Եկեք բարդացնենք առաջադրանքը, ներկայացնենք սխալ և տեսնենք, թե ինչպես է պահպանվում գործարքը, մասամբ կամ ընդհանրապես:
Եկեք նորից ստուգենք ատոմականությունը.
Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3Այնուհետև մենք ուժով կկանգնեցնենք կոնտեյները, կգործարկենք այն և կտեսնենք։
docker kill my-irisԱյս հրամանը գրեթե համարժեք է ուժային անջատմանը, քանի որ այն ուղարկում է SIGKILL ազդանշան՝ գործընթացը անմիջապես դադարեցնելու համար:
Միգուցե գործարքը մասամբ պահպանվե՞լ է։
WRITE ^a(1), ^a(2), ^a(3)
^
<UNDEFINED> ^a(1)- Ոչ, չի պահպանվել:
Փորձենք վերադարձնել հրամանը.
Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TROLLBACK
WRITE ^a(1), ^a(2), ^a(3)
^
<UNDEFINED> ^a(1)Ոչինչ նույնպես չի պահպանվել։
2. Հետևողականություն
Քանի որ գլոբալների վրա հիմնված տվյալների բազաներում բանալիները պատրաստվում են նաև գլոբալների վրա (հիշեցնեմ, որ գլոբալը տվյալների պահպանման ավելի ցածր մակարդակի կառույց է, քան հարաբերական աղյուսակը), հետևողականության պահանջը բավարարելու համար պետք է ներառել բանալու փոփոխություն։ նույն գործարքում, ինչպես գլոբալ փոփոխությունը:
Օրինակ, մենք ունենք գլոբալ ^ անձ, որտեղ մենք պահում ենք անհատականություններ և օգտագործում ենք TIN-ը որպես բանալի:
^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
...Ազգանունով և անունով արագ որոնում ունենալու համար մենք պատրաստեցինք ^index ստեղնը։
^index(‘Kamenev’, ‘Sergey’, 1234567) = 1Որպեսզի տվյալների բազան համահունչ լինի, մենք պետք է ավելացնենք անձը հետևյալ կերպ.
TSTART
^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
^index(‘Kamenev’, ‘Sergey’, 1234567) = 1
TCOMMITՀամապատասխանաբար, ջնջելիս մենք պետք է օգտագործենք նաև գործարք.
TSTART
Kill ^person(1234567)
ZKill ^index(‘Kamenev’, ‘Sergey’, 1234567)
TCOMMITԱյլ կերպ ասած, հետևողականության պահանջի կատարումն ամբողջությամբ դրված է ծրագրավորողի ուսերին։ Բայց երբ խոսքը գնում է գլոբալների մասին, դա նորմալ է, նրանց ցածր մակարդակի պատճառով:
3. Մեկուսացում
Այստեղից է սկսվում վայրի բնությունը: Շատ օգտատերեր միաժամանակ աշխատում են նույն տվյալների բազայում՝ փոխելով նույն տվյալները։
Իրավիճակը համեմատելի է այն իրավիճակի հետ, երբ շատ օգտատերեր միաժամանակ աշխատում են նույն կոդի պահոցով և փորձում են միաժամանակ փոփոխություններ կատարել բազմաթիվ ֆայլերում։
Տվյալների բազան պետք է ամեն ինչ դասավորի իրական ժամանակում: Հաշվի առնելով, որ լուրջ ընկերություններում կա նույնիսկ հատուկ անձ, ով պատասխանատու է տարբերակների վերահսկման համար (ճյուղերի միաձուլում, կոնֆլիկտներ լուծելու և այլն), և տվյալների բազան պետք է անի այս ամենը իրական ժամանակում, առաջադրանքի բարդությունն ու ճիշտությունը: տվյալների բազայի ձևավորում և կոդ, որը ծառայում է դրան:
Տվյալների բազան չի կարող հասկանալ օգտատերերի կողմից կատարված գործողությունների իմաստը, որպեսզի խուսափեն կոնֆլիկտներից, եթե նրանք աշխատում են նույն տվյալների վրա: Այն կարող է հետարկել միայն մեկ գործարք, որը հակասում է մյուսին, կամ կատարել դրանք հաջորդաբար:
Մյուս խնդիրն այն է, որ գործարքի կատարման ժամանակ (մինչ commit-ը) տվյալների բազայի վիճակը կարող է անհամապատասխան լինել, ուստի ցանկալի է, որ մյուս գործարքները մուտք չունենան տվյալների բազայի անհամապատասխան վիճակին, որը ձեռք է բերվում հարաբերական տվյալների բազաներում: շատ առումներով՝ նկարների ստեղծում, բազմատեսակ տողեր և այլն:
Զուգահեռաբար գործարքներ կատարելիս մեզ համար կարևոր է, որ դրանք միմյանց չխանգարեն։ Սա մեկուսացման հատկությունն է։
SQL-ը սահմանում է մեկուսացման 4 մակարդակ.
- ԱՆՎԱՐ ԱՆՎԱՐ
- ԱՆՎԱՐ ՀԱՆԴԵՍ
- ԿՐԿՆՎԵԼԻ ԿԱՐԴԱՑՈՒՄ
- ՍԵՐԻԱԼԱՑՎԱԾ
Եկեք նայենք յուրաքանչյուր մակարդակին առանձին: Յուրաքանչյուր մակարդակի իրականացման ծախսերը աճում են գրեթե էքսպոնենցիալ:
ԱՆՎԱՐ ԱՆՎԱՐ - սա մեկուսացման ամենացածր մակարդակն է, բայց միևնույն ժամանակ ամենաարագը: Գործարքները կարող են կարդալ միմյանց կողմից կատարված փոփոխությունները:
ԱՆՎԱՐ ՀԱՆԴԵՍ մեկուսացման հաջորդ աստիճանն է, որը փոխզիջումային է: Գործարքները չեն կարող կարդալ միմյանց փոփոխությունները մինչև commit-ը, բայց նրանք կարող են կարդալ ցանկացած փոփոխություն, որը կատարվել է կատարելուց հետո:
Եթե մենք ունենք երկարատև T1 գործարք, որի ընթացքում տեղի են ունեցել commit-ներ T2, T3 ... Tn գործարքներում, որոնք աշխատել են նույն տվյալների հետ, ինչ T1-ը, ապա T1-ում տվյալներ պահանջելիս մենք ամեն անգամ կստանանք այլ արդյունք: Այս երեւույթը կոչվում է չկրկնվող ընթերցում։
ԿՐԿՆՎԵԼԻ ԿԱՐԴԱՑՈՒՄ — Այս մեկուսացման մակարդակում մենք չունենք չկրկնվող ընթերցման երևույթ, քանի որ տվյալներ կարդալու յուրաքանչյուր հարցման համար ստեղծվում է արդյունքի տվյալների պատկերը, իսկ նույն գործարքում նորից օգտագործելու դեպքում՝ պատկերից ստացված տվյալները։ է օգտագործվում. Այնուամենայնիվ, հնարավոր է կարդալ ֆանտոմային տվյալները այս մեկուսացման մակարդակում: Սա վերաբերում է նոր տողերի ընթերցմանը, որոնք ավելացվել են զուգահեռ կատարված գործարքներով:
ՍԵՐԻԱԼԱՑՎԱԾ - մեկուսացման ամենաբարձր մակարդակը. Այն բնութագրվում է նրանով, որ գործարքի մեջ որևէ կերպ օգտագործվող տվյալները (կարդալով կամ փոփոխելով) հասանելի են դառնում այլ գործարքների համար միայն առաջին գործարքի ավարտից հետո:
Նախ, եկեք պարզենք, թե արդյոք գործարքի մեջ կա գործողությունների մեկուսացում հիմնական թեմայից: Եկեք բացենք 2 տերմինալային պատուհան։
Kill ^t
Write ^t(1)
2
TSTART
Set ^t(1)=2Մեկուսացում չկա. Մեկ շարանը տեսնում է, թե ինչ է անում երկրորդը, ով բացել է գործարքը:
Տեսնենք, թե արդյոք տարբեր թելերի գործարքները տեսնում են, թե ինչ է կատարվում դրանց ներսում։
Եկեք բացենք 2 տերմինալային պատուհան և զուգահեռաբար բացենք 2 գործարք։
kill ^t
TSTART
Write ^t(1)
3
TSTART
Set ^t(1)=3
Զուգահեռ գործարքները տեսնում են միմյանց տվյալները: Այսպիսով, մենք ստացանք ամենապարզ, բայց նաև ամենաարագ մեկուսացման մակարդակը՝ ԿԱՐԴԱՑԵՔ ՉՊԱՏԱՍԽԱՆՎԵԼ:
Սկզբունքորեն դա կարելի էր ակնկալել գլոբալների համար, որոնց համար կատարումը միշտ առաջնահերթություն է եղել:
Իսկ եթե մեզ անհրաժեշտ լինի մեկուսացման ավելի բարձր մակարդակ գլոբալների վրա գործողություններում:
Այստեղ դուք պետք է մտածեք, թե ինչու են ընդհանրապես անհրաժեշտ մեկուսացման մակարդակները և ինչպես են դրանք աշխատում:
Մեկուսացման ամենաբարձր մակարդակը՝ ՍԵՐԻԱԼԻԶՈՒՄ, նշանակում է, որ զուգահեռ կատարված գործարքների արդյունքը համարժեք է դրանց հաջորդական կատարմանը, ինչը երաշխավորում է բախումների բացակայությունը։
Մենք կարող ենք դա անել՝ օգտագործելով խելացի կողպեքները ObjectScript-ում, որոնք ունեն շատ տարբեր կիրառումներ. դուք կարող եք կատարել կանոնավոր, աստիճանական, բազմակի կողպում հրամանի միջոցով: .
Մեկուսացման ցածր մակարդակները փոխզիջումներ են, որոնք նախատեսված են տվյալների բազայի արագությունը բարձրացնելու համար:
Տեսնենք, թե ինչպես կարող ենք հասնել մեկուսացման տարբեր մակարդակների՝ օգտագործելով կողպեքներ:
Այս օպերատորը թույլ է տալիս վերցնել ոչ միայն բացառիկ կողպեքներ, որոնք անհրաժեշտ են տվյալների փոփոխման համար, այլև այսպես կոչված համօգտագործվող կողպեքներ, որոնք կարող են զուգահեռաբար վերցնել մի քանի թելեր, երբ անհրաժեշտ է կարդալ տվյալներ, որոնք չպետք է փոխվեն ընթերցման գործընթացում այլ գործընթացներով:
Լրացուցիչ տեղեկություններ ռուսերեն և անգլերեն լեզուներով երկփուլ արգելափակման մեթոդի մասին.
→
→
Դժվարությունն այն է, որ գործարքի ընթացքում տվյալների բազայի վիճակը կարող է անհամապատասխան լինել, բայց այս անհամապատասխան տվյալները տեսանելի են այլ գործընթացների համար: Ինչպե՞ս խուսափել սրանից:
Օգտագործելով կողպեքներ, մենք կստեղծենք տեսանելիության պատուհաններ, որոնցում տվյալների բազայի վիճակը կլինի հետևողական: Իսկ համաձայնեցված պետության տեսանելիության նման պատուհանների բոլոր մուտքերը կվերահսկվեն կողպեքներով։
Միևնույն տվյալների վրա համօգտագործվող կողպեքները կարող են կրկնակի օգտագործել, քանի որ դրանք կարող են տեղի ունենալ մի քանի գործընթացներով: Այս կողպեքները թույլ չեն տալիս այլ գործընթացներին փոխել տվյալները, այսինքն. դրանք օգտագործվում են տվյալների բազայի հետևողական վիճակի պատուհաններ ձևավորելու համար:
Տվյալների փոփոխության համար օգտագործվում են բացառիկ կողպեքներ. միայն մեկ գործընթաց կարող է նման կողպեք վերցնել: Բացառիկ կողպեքը կարելի է վերցնել՝
- Ցանկացած գործընթաց, եթե տվյալները անվճար են
- Միայն այն գործընթացը, որն ունի ընդհանուր կողպեք այս տվյալների վրա և առաջինն էր, որ պահանջեց բացառիկ կողպեք:
Որքան նեղ է տեսանելիության պատուհանը, այնքան ավելի երկար պետք է սպասեն մյուս գործընթացները, բայց այնքան ավելի հետևողական կարող է լինել տվյալների բազայի վիճակը դրա ներսում:
READ_COMMITTED — Այս մակարդակի էությունն այն է, որ մենք տեսնում ենք միայն այլ թելերից ստացված տվյալներ: Եթե մեկ այլ գործարքի տվյալները դեռ չեն կատարվել, ապա մենք տեսնում ենք դրա հին տարբերակը:
Սա մեզ թույլ է տալիս զուգահեռացնել աշխատանքը՝ կողպեքի բացմանը սպասելու փոխարեն:
Առանց հատուկ հնարքների մենք չենք կարողանա տեսնել տվյալների հին տարբերակը IRIS-ում, ուստի ստիպված կլինենք բավարարվել կողպեքներով։
Համապատասխանաբար, մենք ստիպված կլինենք օգտագործել ընդհանուր կողպեքներ, որպեսզի թույլ տանք տվյալների կարդալ միայն հետևողականության պահերին:
Ենթադրենք, մենք ունենք օգտվողների բազա ^մարդ, ովքեր գումար են փոխանցում միմյանց։
123 անձից 242 անձի փոխանցման պահը.
LOCK +^person(123), +^person(242)
Set ^person(123, amount) = ^person(123, amount) - amount
Set ^person(242, amount) = ^person(242, amount) + amount
LOCK -^person(123), -^person(242)Մինչև դեբետավորումը 123 անձից գումար պահանջելու պահը պետք է ուղեկցվի բացառիկ բլոկով (լռելյայն).
LOCK +^person(123)
Write ^person(123)Եվ եթե ձեզ անհրաժեշտ է ցույց տալ հաշվի կարգավիճակը ձեր անձնական հաշվում, ապա կարող եք օգտագործել ընդհանուր կողպեք կամ ընդհանրապես չօգտագործել այն.
LOCK +^person(123)#”S”
Write ^person(123)Այնուամենայնիվ, եթե ենթադրենք, որ տվյալների բազայի գործողությունները կատարվում են գրեթե ակնթարթորեն (հիշեցնեմ, որ գլոբալները շատ ավելի ցածր մակարդակի կառուցվածք են, քան հարաբերական աղյուսակը), ապա այս մակարդակի անհրաժեշտությունը նվազում է։
ԿՐԿՆՎԵԼԻ ԿԱՐԴԱՑՈՒՄ - Մեկուսացման այս մակարդակը թույլ է տալիս տվյալների բազմակի ընթերցումներ, որոնք կարող են փոփոխվել միաժամանակյա գործարքներով:
Համապատասխանաբար, մենք պետք է ընդհանուր կողպեք դնենք մեր փոխած տվյալների ընթերցման համար և բացառիկ կողպեքներ՝ մեր փոխած տվյալների վրա:
Բարեբախտաբար, LOCK օպերատորը թույլ է տալիս մեկ հայտարարության մեջ մանրամասն թվարկել բոլոր անհրաժեշտ կողպեքները, որոնցից շատերը կարող են լինել։
LOCK +^person(123, amount)#”S”
чтение ^person(123, amount)այլ գործողություններ (այս պահին զուգահեռ շղթաները փորձում են փոխել ^person(123, գումարը), բայց չեն կարող)
LOCK +^person(123, amount)
изменение ^person(123, amount)
LOCK -^person(123, amount)
чтение ^person(123, amount)
LOCK -^person(123, amount)#”S”Ստորակետերով առանձնացված կողպեքները թվարկելիս դրանք վերցվում են հաջորդաբար, բայց եթե դուք դա անում եք.
LOCK +(^person(123),^person(242))ապա դրանք միանգամից վերցվում են ատոմային եղանակով։
ՍԵՐԻԱԼԱՑՆԵԼ — մենք ստիպված կլինենք կողպեքներ դնել այնպես, որ ի վերջո բոլոր գործարքները, որոնք ունեն ընդհանուր տվյալներ, կատարվեն հաջորդաբար: Այս մոտեցման համար կողպեքների մեծ մասը պետք է լինի բացառիկ և կատարվի գլոբալ ամենափոքր տարածքների վրա:
Եթե խոսենք գլոբալ ^ անձի մեջ միջոցների դեբետավորման մասին, ապա դրա համար ընդունելի է միայն SERIALIZE մեկուսացման մակարդակը, քանի որ գումարը պետք է ծախսվի խիստ հաջորդական, հակառակ դեպքում հնարավոր է մի քանի անգամ ծախսել նույն գումարը։
4. Երկարակեցություն
Ես փորձարկումներ եմ անցկացրել տարայի կոշտ կտրվածքով, օգտագործելով
docker kill my-irisՀենակետը լավ հանդուրժեց նրանց։ Խնդիրներ չեն հայտնաբերվել։
Ամփոփում
Գլոբալների համար InterSystems IRIS-ն ունի գործարքների աջակցություն: Նրանք իսկապես ատոմային են և հուսալի: Գլոբալների վրա հիմնված տվյալների բազայի հետևողականությունն ապահովելու համար պահանջվում են ծրագրավորողների ջանքեր և գործարքների օգտագործում, քանի որ այն չունի բարդ ներկառուցված կառուցվածքներ, ինչպիսիք են արտաքին բանալիները:
Գլոբալների մեկուսացման մակարդակն առանց կողպեքների օգտագործման READ UNCOMMITED է, և կողպեքներ օգտագործելիս այն կարող է ապահովվել մինչև SERIALIZE մակարդակը:
Գլոբալների վրա գործարքների ճիշտությունն ու արագությունը շատ է կախված ծրագրավորողի հմտությունից. որքան ավելի լայնորեն օգտագործվեն ընդհանուր կողպեքները կարդալիս, այնքան բարձր է մեկուսացման մակարդակը, և որքան ավելի նեղ բացառիկ կողպեքներ են վերցվում, այնքան ավելի արագ է կատարումը:
Source: www.habr.com