ტრანზაქციები InterSystems IRIS globals-ში

InterSystems IRIS DBMS მხარს უჭერს საინტერესო სტრუქტურებს მონაცემების შესანახად - გლობალებში. არსებითად, ეს არის მრავალ დონის გასაღებები სხვადასხვა დამატებითი სიკეთეებით ტრანზაქციების სახით, სწრაფი ფუნქციები მონაცემთა ხეების გადასასვლელად, საკეტები და საკუთარი ObjectScript ენა.

წაიკითხეთ მეტი გლობალების შესახებ სტატიების სერიაში „გლობალები არის საგანძური ხმლები მონაცემების შესანახად“:

Ხეები. Ნაწილი 1
Ხეები. Ნაწილი 2
მწირი მასივები. ნაწილი 3

დავინტერესდი, როგორ ხორციელდება ტრანზაქციები გლობალებში, რა მახასიათებლებია. ყოველივე ამის შემდეგ, ეს არის სრულიად განსხვავებული სტრუქტურა მონაცემების შესანახად, ვიდრე ნაცნობი ცხრილები. გაცილებით დაბალი დონე.

როგორც ცნობილია რელაციური მონაცემთა ბაზების თეორიიდან, ტრანზაქციების კარგი განხორციელება უნდა აკმაყოფილებდეს მოთხოვნებს ACID:

ა - ატომური (ატომური). ტრანზაქციაში შეტანილი ყველა ცვლილება ან საერთოდ არ არის ჩაწერილი.

გ - თანმიმდევრულობა. ტრანზაქციის დასრულების შემდეგ, მონაცემთა ბაზის ლოგიკური მდგომარეობა უნდა იყოს შიდა თანმიმდევრული. ბევრი თვალსაზრისით ეს მოთხოვნა ეხება პროგრამისტს, მაგრამ SQL მონაცემთა ბაზების შემთხვევაში ის ასევე ეხება უცხო კლავიშებს.

მე - იზოლირება. პარალელურად მიმდინარე ტრანზაქციებმა არ უნდა იმოქმედოს ერთმანეთზე.

D - გამძლე. ტრანზაქციის წარმატებით დასრულების შემდეგ, დაბალ დონეზე არსებულმა პრობლემებმა (მაგალითად, დენის უკმარისობა) არ უნდა იმოქმედოს ტრანზაქციის მიერ შეცვლილ მონაცემებზე.

გლობალები არარელაციური მონაცემთა სტრუქტურებია. ისინი შექმნილია იმისთვის, რომ ძალიან სწრაფად იმუშაონ ძალიან შეზღუდულ აპარატურაზე. მოდით შევხედოთ ტრანზაქციების განხორციელებას გლობალებში გამოყენებით ოფიციალური IRIS დოკერის სურათი.

IRIS-ში ტრანზაქციების მხარდასაჭერად გამოიყენება შემდეგი ბრძანებები: TSTART, TCOMMIT, ტროლბეკი.

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)

- არა, არ გადარჩა.

მოდით ვცადოთ rollback ბრძანება:

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. იზოლაცია

აქედან იწყება ველური ბუნება. ბევრი მომხმარებელი ერთდროულად მუშაობს იმავე მონაცემთა ბაზაზე, ცვლის ერთსა და იმავე მონაცემებს.

სიტუაცია შედარებულია, როდესაც ბევრი მომხმარებელი ერთდროულად მუშაობს იმავე კოდის საცავთან და ცდილობს ერთდროულად შეიტანოს ცვლილებები ბევრ ფაილში.

მონაცემთა ბაზამ უნდა დაალაგოს ეს ყველაფერი რეალურ დროში. იმის გათვალისწინებით, რომ სერიოზულ კომპანიებში არის სპეციალური ადამიანიც კი, რომელიც პასუხისმგებელია ვერსიის კონტროლზე (ტოტების შერწყმა, კონფლიქტების მოგვარება და ა.შ.) და მონაცემთა ბაზამ ეს ყველაფერი რეალურ დროში უნდა გააკეთოს, დავალების სირთულე და სისწორე. მონაცემთა ბაზის დიზაინი და კოდი, რომელიც მას ემსახურება.

მონაცემთა ბაზას არ შეუძლია გაიგოს მომხმარებლების მიერ შესრულებული მოქმედებების მნიშვნელობა, რათა თავიდან აიცილონ კონფლიქტები, თუ ისინი მუშაობენ იმავე მონაცემებზე. მას შეუძლია გააუქმოს მხოლოდ ერთი ტრანზაქცია, რომელიც ეწინააღმდეგება მეორეს, ან შეასრულოს ისინი თანმიმდევრულად.

კიდევ ერთი პრობლემა ის არის, რომ ტრანზაქციის შესრულებისას (დასრულებამდე) მონაცემთა ბაზის მდგომარეობა შეიძლება იყოს არათანმიმდევრული, ამიტომ სასურველია სხვა ტრანზაქციებს არ ჰქონდეთ წვდომა მონაცემთა ბაზის არათანმიმდევრულ მდგომარეობაზე, რაც მიიღწევა რელაციურ მონაცემთა ბაზებში. მრავალი თვალსაზრისით: სნეპშოტების შექმნა, მწკრივების მრავალვერსია და ა.შ.

ტრანზაქციების პარალელურად განხორციელებისას ჩვენთვის მნიშვნელოვანია, რომ მათ ხელი არ შეუშალონ ერთმანეთს. ეს არის იზოლაციის თვისება.

SQL განსაზღვრავს იზოლაციის 4 დონეს:

• წაიკითხეთ დაუსრულებლად
• წაიკითხეთ ჩადენილი
• განმეორებადი წაკითხვა
• სერიალიზაციადი

მოდით შევხედოთ თითოეულ დონეს ცალკე. თითოეული დონის განხორციელების ხარჯები თითქმის ექსპონენტურად იზრდება.

წაიკითხეთ დაუსრულებლად - ეს არის იზოლაციის ყველაზე დაბალი დონე, მაგრამ ამავე დროს ყველაზე სწრაფი. ტრანზაქციებს შეუძლია ერთმანეთის მიერ განხორციელებული ცვლილებების წაკითხვა.

წაიკითხეთ ჩადენილი არის იზოლაციის შემდეგი დონე, რომელიც კომპრომისია. ტრანზაქციებს არ შეუძლია წაიკითხოს ერთმანეთის ცვლილებები ჩადენამდე, მაგრამ მათ შეუძლიათ წაიკითხონ ნებისმიერი ცვლილება, რომელიც განხორციელდა ჩადენის შემდეგ.

თუ გვაქვს გრძელი ტრანზაქცია T1, რომლის დროსაც ტრანზაქციებში ჩაბარებები ხდებოდა 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

პარალელური გარიგებები ხედავენ ერთმანეთის მონაცემებს. ასე რომ, ჩვენ მივიღეთ უმარტივესი, მაგრამ ასევე ყველაზე სწრაფი იზოლაციის დონე, READ UNCOMMITED.

პრინციპში, ეს შეიძლება მოსალოდნელი იყოს გლობალებისთვის, რომელთა შესრულება ყოველთვის პრიორიტეტული იყო.

რა მოხდება, თუ გვჭირდება იზოლაციის უფრო მაღალი დონე გლობალურ ოპერაციებში?

აქ თქვენ უნდა იფიქროთ იმაზე, თუ რატომ არის საერთოდ საჭირო იზოლაციის დონეები და როგორ მუშაობს ისინი.

იზოლაციის უმაღლესი დონე, SERIALIZE, ნიშნავს, რომ პარალელურად განხორციელებული ტრანზაქციების შედეგი მათი თანმიმდევრული შესრულების ტოლფასია, რაც გარანტიას იძლევა შეჯახების არარსებობას.

ჩვენ შეგვიძლია ამის გაკეთება ObjectScript-ში ჭკვიანი საკეტების გამოყენებით, რომლებსაც აქვთ მრავალი განსხვავებული გამოყენება: შეგიძლიათ გააკეთოთ რეგულარული, ინკრემენტული, მრავალჯერადი ჩაკეტვა ბრძანებით. საკეტი.

იზოლაციის ქვედა დონეები არის კომპრომისები, რომლებიც შექმნილია მონაცემთა ბაზის სიჩქარის გასაზრდელად.

ვნახოთ, როგორ მივაღწიოთ იზოლაციის სხვადასხვა დონეს საკეტების გამოყენებით.

ეს ოპერატორი საშუალებას გაძლევთ აიღოთ არა მხოლოდ მონაცემთა შესაცვლელად საჭირო ექსკლუზიური საკეტები, არამედ ეგრეთ წოდებული გაზიარებული საკეტები, რომლებსაც შეუძლიათ პარალელურად აიღოთ რამდენიმე თემა, როდესაც მათ სჭირდებათ მონაცემების წაკითხვა, რომლებიც არ უნდა შეიცვალოს სხვა პროცესებით წაკითხვის პროცესში.

დამატებითი ინფორმაცია ორფაზიანი ბლოკირების მეთოდის შესახებ რუსულ და ინგლისურ ენებზე:

→ ორფაზიანი ბლოკირება
→ ორფაზიანი საკეტი

სირთულე ის არის, რომ ტრანზაქციის დროს მონაცემთა ბაზის მდგომარეობა შეიძლება არათანმიმდევრული იყოს, მაგრამ ეს არათანმიმდევრული მონაცემები ჩანს სხვა პროცესებისთვის. როგორ ავიცილოთ თავიდან ეს?

საკეტების გამოყენებით ჩვენ შევქმნით ხილვადობის ფანჯრებს, რომლებშიც მონაცემთა ბაზის მდგომარეობა იქნება თანმიმდევრული. და შეთანხმებული სახელმწიფოს ხილვადობის ასეთ ფანჯრებზე ყველა წვდომა გაკონტროლდება საკეტებით.

ერთსა და იმავე მონაცემებზე გაზიარებული საკეტები ხელახლა გამოყენებადია — მათ შეუძლიათ რამდენიმე პროცესის გადატანა. ეს საკეტები ხელს უშლის სხვა პროცესებს მონაცემების შეცვლას, ე.ი. ისინი გამოიყენება მონაცემთა ბაზის თანმიმდევრული მდგომარეობის ფანჯრების შესაქმნელად.

ექსკლუზიური საკეტები გამოიყენება მონაცემთა ცვლილებისთვის - მხოლოდ ერთ პროცესს შეუძლია მიიღოს ასეთი დაბლოკვა. ექსკლუზიური საკეტის აღება შესაძლებელია:

1. ნებისმიერი პროცესი, თუ მონაცემები უფასოა
2. მხოლოდ იმ პროცესს, რომელსაც აქვს საერთო დაბლოკვა ამ მონაცემებზე და იყო პირველი, ვინც მოითხოვა ექსკლუზიური დაბლოკვა.

რაც უფრო ვიწროა ხილვადობის ფანჯარა, მით უფრო გრძელია სხვა პროცესების მოლოდინი, მაგრამ მით უფრო თანმიმდევრული შეიძლება იყოს მონაცემთა ბაზის მდგომარეობა მასში.

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 დონემდე.

გლობალებზე ტრანზაქციების სისწორე და სიჩქარე დიდად არის დამოკიდებული პროგრამისტის უნარზე: რაც უფრო ფართოდ გამოიყენება საკეტები კითხვისას, მით უფრო მაღალია იზოლაციის დონე და რაც უფრო ვიწრო ექსკლუზიური საკეტები იქნება აღებული, მით უფრო სწრაფია შესრულება.

წყარო: www.habr.com