Транзакции в глобалите на InterSystems IRIS

СУБД InterSystems IRIS поддържа любопитни структури за съхранение на данни — глобали. По същество, те представляват многоуровневими ключове с различни допълнителни функции като транзакции, бързи функции за обход на данни, блокировки и собствен език ObjectScript.

Повече за глобалите в цикъла статии «Глобали — мечи-кладенци за съхранение на данни»:

Деревья. Част 1
Деревья. Част 2
Разредени масиви. Част 3

Интересно ми стана как са реализирани транзакциите в глобалите и какви особености съществуват. Все пак, това е съвсем различна структура за съхранение на данни в сравнение с обичайните таблици. Значително по-нискоуровнева.

Както е известно от теорията на релационните бази данни, добрата реализация на транзакции трябва да отговаря на изискванията ACID:

A — Atomic (атомарност). Записват се всички промени, направени в транзакцията, или нито една.

С — Consistency (консистентност). След приключване на транзакцията логическото състояние на БД трябва да бъде вътрешно непротиворечиво. Отчасти това изискване касае програмиста, но в случая на SQL-бази данни, то се отнася и за външните ключове.

I — Isolate (изолираност). Паралелно изпълняващите се транзакции не трябва да оказват влияние една на друга.

D — Durable (дълговечност). След успешно завършване на транзакцията, проблеми на по-ниските нива (например, авария на захранването) не трябва да оказват влияние на данните, променени от транзакцията.

Глобалите са нерелационни структури от данни. Те са създадени за свръхбърза работа на много ограничено оборудване. Нека разгледаме реализирането на транзакции в глобалите с помощта на официалния docker-образ на IRIS.

За поддръжка на транзакции в IRIS се използват командите: TSTART, TCOMMIT, TROLLBACK.

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

Тази команда е практически еквивалентна на forcibly shutting down power, тъй като изпраща сигнал за незабавно спиране на процеса SIGKILL.

Може ли транзакцията да е останала частично?

WRITE ^a(1), ^a(2), ^a(3)
^
 ^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)
^
 ^a(1)

Също така нищо не е останало.

2. Съвместимост

Тъй като в глобалите ключовете се правят и на глобалите (да напомня, че глобалът е по-нискостепенна структура за съхранение на данни от релационната таблица), за да се изпълни изискването за съвместимост, промяната на ключа трябва да се включи в същата транзакция, в която и промяната на глобала.

Например, имаме глобал ^person, в който съхраняваме личности и като ключ използваме ЕГН.

^person(1234567, ‘firstname’) = ‘Сергей’
^person(1234567, ‘lastname’) = ‘Каменев’
^person(1234567, ‘phone’) = ‘+74995555555
...

За да имаме бързо търсене по фамилия и име, направихме ключ ^index.

^index(‘Каменев’, ‘Сергей’, 1234567) = 1

За да е базата съвместима, трябва да добавяме личността по следния начин:

TSTART
^person(1234567, ‘firstname’) = ‘Сергей’
^person(1234567, ‘lastname’) = ‘Каменев’
^person(1234567, ‘phone’) = ‘+74995555555
^index(‘Каменев’, ‘Сергей’, 1234567) = 1
TCOMMIT

Съответно, при изтриване също трябва да използваме транзакция:

TSTART
Kill ^person(1234567)
ZKill ^index(‘Каменев’, ‘Сергей’, 1234567)
TCOMMIT

С други думи, изпълнението на изискването за съвместимост лежи изцяло на раменете на програмиста. Но когато става въпрос за глобали — това е нормално, предвид нискостепенната им природа.

3. Изолация

Тук започват дебрите. Много потребители работят едновременно в една и съща база, променят същите данни.

Ситуацията е сравнима с това, когато много потребители едновременно работят с един и същи кодов репозиторий и се опитват да вписват промени едновременно в много файлове.

Базата данни трябва да решава всичко това в реално време. Имайки предвид, че в сериозни компании дори има специален човек, който отговаря за контрола на версиите (за сливане на клонове, разрешаване на конфликти и т.н.), а БД всичко това трябва да извършва в реално време, става очевидна сложността на задачата и правилността на проектиране на базата данни и кода, който я обслужва.

Базата данни не може да разбере смисъла на действията, извършвани от потребителите, за да предотврати конфликти, когато те работят с едни и същи данни. Тя може само да анулира една транзакция, която противоречи на друга, или да ги изпълни последователно.

Още един проблем е, че по време на изпълнението на транзакция (преди комита), състоянието на базата може да е несъгласувано, затова е желателно да няма достъп до несъгласуваното състояние на базата данни от други транзакции, което се постига в релационните БД по много начини: създаване на моментни снимки, многоверсионност на редовете и т.н.

При паралелното изпълнение на транзакции е важно те да не си пречат. Това е свойството на изолация.

SQL определя 4 нива на изолация:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

Нека разгледаме всяко ниво по отделно. Разходите за реализация на всяко ниво нарастват почти експоненциално.

READ UNCOMMITTED — това е най-ниското ниво на изолация, но и най-бързото. Транзакции могат да четат изменения, направени от другите.

READ COMMITTED — това е следващото ниво на изолация, което е компромис. Транзакции не могат да четат изменения, направени от другите, преди комита, но могат да четат всякакви изменения, направени след комита.

Ако имаме дълга транзакция Т1, в течение на която са извършени комити в транзакциите Т2, Т3 ... Тn, които работят с едни и същи данни като Т1, то при заявка за данни в Т1 ще получаваме всеки път различен резултат. Този феномен се нарича неповторяемо четене.

REPEATABLE READ — на това ниво на изолация нямаме феномена на неповторяемо четене, благодарение на факта, че за всяка заявка за четене на данни се създава моментна снимка на резултатите и при повторно използване в същата транзакция се използват данните от снимката. Въпреки това, на това ниво на изолация е възможно четене на фантомни данни. Имат предвид четенето на нови редове, които са били добавени от паралелни фиксирани транзакции.

SERIALIZABLE — най-високото ниво на изолация. То се характеризира с това, че данните, които по някакъв начин се използват в транзакцията (четене или изменение), стават достъпни за други транзакции само след завършване на първата транзакция.

Нека първо разгледаме дали операцията в транзакцията е изолирана от основния поток. Ще отворим 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, които имат множество различни начини на приложение: можем да правим обикновени, инкрементни, множествени блокировки с команда LOCK.

По-ниските нива на изолация са компромиси, насочени към увеличаване скоростта на работа на базата данни.

Нека видим как можем да постигнем различни нива на изолация с помощта на блокировки.

Тази команда позволява да взимаме не само ексклузивни блокировки, необходими за промяна на данни, но и т.нар. shared, които могат да бъдат взимани паралелно от няколко потока, когато е необходимо да се четат данни, които не трябва да бъдат променяни от други процеси по време на четенето.

Повече информация за двуфазния метод на блокировки на български и английски езици:

→ Двуфазна блокировка
→ Two-phase locking

Сложността е в това, че по време на транзакцията състоянието на базата може да е несъгласувано, но тези несъгласувани данни са видими за други процеси. Как да избегнем това?

Ние ще създадем с помощта на блокировки такива прозорци на видимост, в които състоянието на базата ще бъде съгласувано. И всички достъпи до такива прозорци на съгласувано състояние ще бъдат контролирани от блокировки.

Споделени блокировки на същите данни многоразови — няколко процеса могат да ги вземат. Тези блокировки забраняват на другите процеси да променят данните, т.е. те се използват за формиране на прозорци с последователно състояние на БД.

Ексклузивни блокировки се използват за промяна на данни — такава блокировка може да бъде взета само от един процес. Ексклузивната блокировка може да бъде взета от:

1. Всякакъв процес, ако данните са свободни
2. Само този процес, който има на тези данни споделена блокировка и първи е заявил ексклузивна блокировка.

Колкото по-тясно е прозорецът на видимост, толкова по-дълго трябва да изчакват другите процеси, но толкова по-последователно може да бъде състоянието на БД в него.

READ_COMMITED — същността на това ниво е, че виждаме само комитираните данни от другите потоци. Ако данните в друга транзакция не са комитирани, виждаме тяхната стара версия.

Това ни позволява да паралелим работата вместо да чакаме освобождаването на блокировката.

Без специални хитрости няма да можем да видим старата версия на данните в IRIS, затова ще трябва да се справим с блокировки.

Съответно ще трябва с помощта на споделени блокировки да разрешим четенето на данни само в моменти на последователност.

Допускаме, че имаме база с потребители ^person, които превеждат пари помежду си.

Моментът на превод от персона 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)

Въпреки това, ако предположим, че операциите с БД се изпълняват практически мигновено (напомням, че глобалите — са много по-нискостепенна структура от релационната таблица), необходимостта от това ниво отпада.

REPEATABLE READ — в това ниво на изолация се допуска, че могат да бъдат извършени няколко четения на данни, които могат да бъдат променени от паралелни транзакции.

Съответно ще трябва да поставяме споделена блокировка за четене на данните, които променяме, и ексклузивни блокировки за данните, които променяме.

Оператор LOCK позволява в единствен оператор подробно да изброи всички необходими заключвания, които могат да бъдат много.

LOCK +^person(123, amount)#”S”
четене ^person(123, amount)

други операции (в това време паралелни потоци се опитват да променят ^person(123, amount), но не могат)

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 — ще трябва да поставим заключванията така, че в крайна сметка всички транзакции, които имат общи данни, да се изпълняват последователно. За този подход повечето заключвания трябва да бъдат ексклузивни и да се взимат на най-малките области на глобала за производителност.

Ако говорим за изтегляния на средства в глобала ^person, то за него е приемливо само нивото на изолация SERIALIZE, тъй като парите трябва да се харчат строго последователно, иначе е възможно да се изхарчи една и съща сума няколко пъти.

4. Дълговечност

Проведох тестове с рязко изключване на контейнера чрез

docker kill my-iris

Базата успешно издържа. Не бяха открити проблеми.

Заключение

За глобалите в InterSystems IRIS има поддръжка за транзакции. Те са наистина атомни и надеждни. За осигуряване на консистентност на базата данни при глобалите са необходими усилия от програмиста и използването на транзакции, тъй като не притежават сложни вградени конструкции като външни ключове.

Нивото на изолация при глобалите без използване на заключвания е READ UNCOMMITTED, а при използване на заключвания може да се осигури до нивото SERIALIZE.

Коректността и скоростта на работа на транзакции при глобалите значително зависят от майсторството на програмиста: колкото по-широко се използват споделени заключвания при четене, толкова по-високо е нивото на изолация, а колкото по-тесно се взимат ексклузивни заключвания, толкова по-голяма е бързодействието.

Източник: habr.com