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

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

Повече за глобалите в серия статии „Глобали - магически мечове за съхранение на данни“:

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

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

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

A — Атомарност. Записват се всички промени, направени в транзакцията, или не се записва нищо.

С — Последователност. След завършване на транзакцията логичното състояние на базата данни трябва да бъде вътрешно последователно. В много отношения това изискване касае програмиста, но в случая с SQL бази данни то се отнася и за външните ключове.

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

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

Глобалите са нерелационни структури от данни. Те са създадени за свръхбърза работа на много ограничен хардуер. Нека да разгледаме реализирането на транзакции в глобалите с помощта на официалния 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

Тази команда е практически еквивалентна на насилственото изключване на захранването, тъй като изпраща сигнал за незабавно спиране на процеса 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') = '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 нива на изолация:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

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

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

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

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

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

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

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

Убий ^t

Напиши ^t(1)
2

TSTART
Задай ^t(1)=2

Няма изолация. Един поток вижда какво прави вторият, който е отворил транзакцията.

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

Ще отворим 2 терминала и ще стартираме 2 паралелни транзакции.

убий ^t
TSTART
Напиши ^t(1)
3

TSTART
Задай ^t(1)=3

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

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

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

Тук е важно да се замислим защо изобщо са необходими нивата на изолация и как работят.

Най-високото ниво на изолация 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”
читeне ^person(123, amount)

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

LOCK +^person(123, amount)
промяна ^person(123, amount)
LOCK -^person(123, amount)

читeне ^person(123, amount)
LOCK -^person(123, amount)#”S”

При изброяването на блокировките с запетая те се взимат последователно, а ако се направи така:

LOCK +(^person(123),^person(242))

те се взимат атомарно всичките веднага.

СЕРИАЛИЗАЦИЯ — ще трябва да настроим блокировките така, че в крайна сметка всички транзакции, които имат общи данни, да се извършват последователно. За този подход повечето блокировки трябва да бъдат ексклузивни и да се взимат на най-малките области на глобала за производителност.

Ако говорим за тегления на средства в глобала ^person, то за него е приемлив само нивото на изолация СЕРИАЛИЗАЦИЯ, тъй като парите трябва да се харчат строго последователно, в противен случай е възможно да се изразходва една и съща сума няколко пъти.

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

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

docker kill my-iris

Базата ги пренесе добре. Проблеми не бяха установени.

Заключение

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

Нивото на изолация на глобалите без използване на блокировки — това е ЧЕТЕНЕ НЕПОДПИЧЕН, а при използване на блокировки може да се осигури дори до нивото СЕРИАЛИЗАЦИЯ.

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

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