Co się wydarzy, gdy w naszym systemie bazodanowym wystąpi awaria? Czy operacje, które są w trakcie przetwarzania zostaną wykonane, a może dojdzie do ich anulowania?

No właśnie, zwykle rzeczywistości nie jest tak kolorowa jak byśmy chcieli, awarie się zdarzały, zdarzają i zdarzać będą. Jednak czy można zrobić coś co gwarantowałoby wykonanie operacji lub jej wycofanie w momencie awarii?

W takich sytuacjach przychodzi nam z pomocą mechanizm zwany transakcjami.

Czym jest transakcja?

To nic innego jak metoda wykorzystywana przez aplikację do grupowania, operacji odczytu i zapisu w jedną logiczną jednostkę. 

Wynikiem transakcji jest jeden z dwóch stanów: Sukces (transakcja jest zatwierdzana) lub Porażka (transakcja jest anulowana lub wycofywana).

To może przykład?

Zerknijmy na klasyczny przykład transakcji: transakcja bankowa wymiany środków pomiędzy dwoma kontami, Kontem A i Kontem B.

• Właściciel Konta A chce przelać 100 PLN na Konto B
• Generalnie mamy w tym przykładzie dwa podejścia.

Podejście 1:

Operacja 1: Stan Konta A = Stan Konta A - 100 PLN;

Operacja 2: Stan Konta B = Stan Konta B + 100 PLN;

Podejście 2:

Operacja 1: Stan Konta B = Stan Konta B + 100 PLN;

Operacja 2: Stan Konta A = Stan Konta A - 100 PLN;

W rzeczywistości, cała operacja jest troszkę bardziej skomplikowana (dochodzą sprawdzenia, reguły biznesowe i prawne banku itp.), jednak idea jest ta sama.

• Jeżeli dojdzie do awarii w trakcie wykonywania operacji, mamy problem. Albo 100 PLN wyparuje z Konta A i nie pojawi się na Koncie B, lub pojawi się na Koncie B, ale stan Konta A nie zostanie zmieniony.
• Z pomocą przychodzi transakcja, która obejmując wykonanie operacji w jednym z Podejść, gwarantuje: wykonanie obu operacji z sukcesem (COMMIT), lub brak zmian w stanach obu Kont (cofnięcie zmian / ROLLBACK)  

BEGIN [TRANSACTION]

            StanKontaA = StanKontaA - 100;

            StanKontaB = StanKontaB + 100;

END [TRANSACTION] (COMMIT)

Czy Transakcja to lek na całe zło? 

Transakcje podobnie jak każda inna rzecz mają swoje zalety i ograniczenia. Nie zawsze są odpowiedzią na każdą bolączkę, a już napewno nie są całkowicie darmowe (np. w kontekście wydajności).

Czy w takim razie potrzebujesz transakcji? Żeby sobie na to jednoznacznie odpowiedzieć musimy zrozumieć detale i smaczki jakie stoją za “gwarancjami bezpieczeństwa”.

Gwarancje są z nami od 1983 🙂 znasz je pod akronim - ACID 

A (Atomicity) / Atomowść

C (Consistency) / Spójność

I (Isolation) / Izolacja 

D (Durability) / Trwałość

Są zestawem mechanizmów zapewniania odporności na błędy. Czym są składowe tego akronimu i jaki to ma realny wpływ na naszą pracę, o tym poniżej.

A - ATOMICITY - ATOMOWOŚĆ

To zapewnienie, że operacja lub zestaw operacji objętych transakcją zostanie wykonana w całości lub anulowana.

Przykład:

OPERACJA 1 ————————-> SUKCES (np. INSERT)

OPERACJA 2 ————————-> SUKCES (np. DELETE)

OPERACJA 3 ————————-> PORAŻKA (np. INSERT - do archiwum)

OPERACJA 4 ————————-> SUKCES (np. UPDATE na danych dodanych do archiwum)

Dla baz które zapewniają atomowość, w powyższym przykładzie transakcja zostanie anulowana a wykonane zmiany cofnięte ROLLBACK. Gdyby wszystkie operacje zakończyły się sukcesem transakcja zostałaby zaakceptowana COMMIT.

W przypadku braku atomowości, przy jednoczesnym błędzie jednej lub kilku operacji, trudno będzie ustalić jakie dokładnie akcje zostały wykonane (chyba, że wyniki akcji byłyby oczywiste). Ponowna próba wykonania tej samej transakcji może doprowadzić do błędów w danych (nadpisanie wartości, dodanie wartości i pojawienie się duplikatów etc.).

C - CONSISTENCY - SPÓJNOŚĆ

Spójność w zależności od kontekstu jest rozumiana w inny sposób, w teorii ACID consistency odpowiada za fakt, że “baza jest w dobrym stanie” i tak naprawdę powinna być traktowana jako właściwość aplikacji a nie cecha bazy danych.

Co to znaczy właściwość aplikacji i baza w dobrym stanie?

Właściwością aplikacji, może być fakt iż w przykładzie transakcji bankowej, saldo konta z którego wysyłamy pieniądze musi pozwalać na dokonanie operacji. Tzn. po wykonaniu operacji stan konta musi być nieujemny (zakładamy, że nie mamy żadnych limitów kredytowych itp.)

Jest to po prostu jakiś zestaw reguł których należy przestrzegać określonych w ramach aplikacji. Spełnienie reguły definiuje fakt iż baza jest w dobrym stanie. 

W większości wypadków to twórca aplikacji określa reguły i to on jest odpowiedzialny za ich przestrzeganie (może zrzucić część odpowiedzialności na bazę w postaci, TRIGGERÓW (wyzwalaczy), CONSTRAINTS (ograniczeń np. kluczy obcych czy unikalnych) etc.) jednak z przyczyn błędu w aplikacji dojdzie do zapisu błędnych danych sama baza danych Cię przed tym nie powstrzyma.

I - ISOLATION - IZOLACJA

Izolacja oznacza, że jednocześnie wykonywane transakcje są od siebie odizolowane - nie mogą mieć na siebie wpływu. Jest to szczególnie ważne w sytuacji dostępu do tego samego zasobu (tej samej tabeli) w przypadku dostępu do różnych obiektów konflikt nie będzie występował.

Inna definicja to taka w której izolacja jest gwarantem w którym równoległy sposób  wykonania transakcji pozostawi bazę danych w takim stanie stanie jakby operacje zostały wykonane w sposób sekwencyjny. 

Warto pamiętać, że jest izolacja to wymiana integralności bazy kosztem wydajności.

Przykład:

D - DURABILITY - TRWAŁOŚĆ

Trwałość to obietnica, że po udanym zaakceptowaniu transakcji zapisane dane nie zostaną zapomniane (bez względu na sytuacje awaryjne - awaria sprzętu / bazy).

Można to uzyskać przez zapisanie danych na dyski (SSD / HDD) + dodanie operacji do dziennika logów WAL (Write Ahead Log - operacja jest najpierw zapisywana do dziennika kolejno wykonywana) lub przez replikację bazy danych.