Niepodzielność, spójność, izolacja i trwałość to filary, które chronią transakcje bazodanowe przed popadnięciem w chaos. Właściwości te stanowią podstawę niezawodnych systemów baz danych, zapewniając, że każda operacja jest zgodna z zasadami. W ten sposób możemy precyzyjnie obsłużyć każdą awarię i nie pozostawić żadnej transakcji niekompletnej lub w uszkodzonym stanie. Gdyby nie ACID, świat danych byłby bałaganem w połowie wykonanych działań, niespójnych rekordów i utraty danych, które mogłyby rzucić na kolana nawet najprostszy system.

Poniżej, omówimy każdą z właściwości składającą się na ten kwaśno-brzmiący akronim, objaśniając przy tym ich rolę w utrzymaniu porządku w świecie danych. Od niepodzielności atomowości do zapewnienia trwałości, zasady te współpracują ze sobą. Robią to, aby upewnić się, że każda transakcja jest wykonywana poprawnie, nawet w obliczu awarii systemu lub nieoczekiwanych błędów. Po drodze poruszymy również kwestię tego, w jaki sposób ACID kontrastuje z bardziej zrelaksowanymi modelami, takimi jak ostateczna spójność (Eventual Consistency), w których kompromis między ścisłą spójnością a wysoką dostępnością kształtuje wydajność.

Atomicity czyli niepodzielność

Zacznijmy od litery „A”. Angielski termin „Atomicity” odnoszący się do transakcji bazodanowych pochodzi od pojęcia „atomu” w fizyce. Implikuje on niepodzielność, ponieważ pozwala na łatwą wizualizację ogromu konsekwencji jakie przynieść za sobą może fragmentacja transakcji. W DBMS (eng. Database Management Systems – Systemach zarządzania bazami danych)- atomowość gwarantuje, że w ramach danej transakcji wszystkie części muszą zakończyć się sukcesem. W przeciwnym razie, będzie to wyglądać tak, jakby żadna z nich nigdy nie miała miejsca.

Przychodzi tu na myśl przykład, prosta transakcja finansowa. Powiedzmy, że 100 zł wędruje z konta A na konto B. Transakcja ta składa się z dwóch operacji: obciążenia konta A i przyznania tej kwoty na koncie B. Niepodzielność gwarantuje, że obie te akcje zostaną wykonane całkowicie albo wcale. Jeśli, powiedzmy, nad światem technologii zbiorą się ciemne chmury i uznanie konta B się nie powiedzie po tym, jak konto A już zostało obciążone, niepodzielność cofnie całą operację. 100 zł wraca na konto A, jakby nigdy nic się nie wydarzyło – bilans przywrócony, finansowa katastrofa zażegnana.

Jak osiągnąć niepodzielność?

• Logi transakcji rejestrują każdą zmianę, jaką transakcja wprowadza do bazy danych przed faktycznym wdrożeniem zmian. Jeśli transakcja się nie powiedzie, system używa tych logów do cofnięcia wszystkiego, utrzymując bazę danych czystą od wszelkich efektów transakcji w połowie upieczonych.
• Dwufazowy protokół zatwierdzania (2PC) składa się z dwóch faz. W „fazie przygotowawczej” każdy węzeł zaangażowany w transakcję wyraża zgodę na jej zatwierdzenie lub porzucenie. Jeśli każdy węzeł podniesie kciuk w górę, przechodzą do „fazy zatwierdzania”. Tam zmiany są wprowadzane lokalnie w każdym węźle, a ich pomyślne zakończenie jest potwierdzane. Metoda ta zapewnia, że każda część transakcji zostanie w pełni zatwierdzona lub wycofana, bez żadnych odstępstw.
• Mechanizmy blokujące uniemożliwiają innym transakcjom dostęp do danych, których dotyczy bieżąca transakcja. Blokując dane do wyłącznego dostępu podczas wykonywania transakcji, system zapewnia, że żadna inna transakcja nie może ingerować, utrzymując w ten sposób atomowość. Blokady są zazwyczaj utrzymywane do momentu zatwierdzenia lub wycofania transakcji, zapewniając spójność danych.
• Rejestrowanie z wyprzedzeniem to metoda, w której zmiany są najpierw rejestrowane w logu, jeszcze zanim trafią do bazy danych. Zapewnia to, że baza zawsze może powrócić do spójnego stanu w przypadku awarii dzięki zapisom w logach. Możemy ich użyć do ponownego wykonania operacji transakcji od początku lub do ich całkowitego wycofania.
• Shadow Paging, w przeciwieństwie do logowania, polega na utrzymywaniu dodatkowej kopii stron bazy danych zmodyfikowanych podczas transakcji. Ta kopia, „Shadow Page”, jest aktualizowana o zmiany w miarę postępu transakcji. Dopiero po pomyślnym zatwierdzeniu transakcji „Shadow Pages” zastępują oryginalne strony w bazie danych. Jeśli transakcja nie powiedzie się, system odrzuca te strony, zapewniając, że baza danych nie odzwierciedla żadnych częściowych aktualizacji.

Spójność

Spójność w systemach bazodanowych gwarantuje, że wszystkie transakcje niezawodnie przestrzegają reguł i ograniczeń bazy danych, utrzymując stabilne i wolne od błędów środowisko. Kiedy transakcja zostaje uruchomiona, ma obowiązek dopilnować, aby każdy bajt i bit, którego dotknie, był zgodny z ustalonymi normami. Dzięki temu „chroni” poprawność i niezawodność bazy danych. Jeśli transakcja odważy się naruszyć którąkolwiek z zasad, natychmiast staje się „winowajcą”, a system szybko wraca do spokojnego stanu sprzed tego incydentu.

Na przykład: prosta transakcja bankowa, w której środki przechodzą z jednego konta na drugie. Spójna transakcja oznaczałaby, że całkowity bilans przed i po transakcji pozostaje taki sam. Transakcja musi odjąć środki tu, i dodać je tam, ogólna suma jest jednak identyczna przed i po transakcji. To odzwierciedla jedną z najprostszych form ograniczeń integralności — zachowanie równowagi.

Jak osiąga się spójność?

• Ograniczenia to zasady zdefiniowane w schemacie bazy danych, które określają dozwolone wartości dla określonych pól. Mogą obejmować:

Ograniczenia unikalności, aby zapobiec duplikatom.

Ograniczenia warunkowe (CHECK) do walidacji danych według określonego warunku.

Klucze obce, które zapewniają utrzymanie relacji między tabelami.

System zarządzania bazą danych (DBMS) automatycznie sprawdza te ograniczenia podczas transakcji. Jeśli transakcja narusza którekolwiek z nich, cała transakcja zostaje wycofana do stanu sprzed rozpoczęcia.

• Wyzwalacze to zautomatyzowane procedury, których zadaniem jest wykonywanie operacji w odpowiedzi na określone zmiany w bazie danych, takie jak aktualizacje lub wstawienia. W ten sposób wyzwalacze zapewniają realizację reguł biznesowych, wspierając spójność. Wyzwalacz może, na przykład, automatycznie aktualizować poziomy zapasów po zarejestrowaniu sprzedaży.
• Procedury składowane łączą złożone operacje w pojedyncze, wykonywalne skrypty, zmniejszając ryzyko błędów manualnych i utrzymując spójność danych.
• Poziomy izolacji określają, na ile transakcja jest odizolowana od zmian dokonywanych przez inne transakcje. DBMS oferuje różne poziomy izolacji, które pozwalają na wybór między wydajnością a spójnością.
• Mechanizmy odzyskiwania wykorzystują dzienniki transakcji i kopie zapasowe, aby zapewnić przywrócenie bazy danych do spójnego stanu po awarii. Dzienniki te rejestrują stan bazy danych przed i po przetworzeniu transakcji. W przypadku awarii systemu te zapisy są wykorzystywane do przywrócenia bazy danych do ostatniego znanego spójnego stanu przez cofnięcie lub ponowne wykonanie transakcji.
• Kontrola współbieżności z użyciem wielu wersji danych (MVCC), stosowana w niektórych zaawansowanych bazach danych, przechowuje wiele wersji danych. Dzięki temu operacje odczytu mają dostęp do wersji danych, która była spójna na początku transakcji, co pozwala uniknąć blokowania danych dla odczytów i poprawia wydajność bez utraty spójności.

Izolacja

Główna rola izolacji w transakcjach bazodanowych sprowadza się do odpowiedzi na pytanie: kiedy zmiany dokonane przez jedną transakcję stają się widoczne dla innych? Izolacja zapewnia, że transakcje nie ujawniają wzajemnie swoich zmian przedwcześnie. W przeciwnym razie mogłoby dojść do różnych problemów związanych ze współbieżnością, takich jak:

• Brudne odczyty (dirty reads): Pojawiają się, gdy transakcja odczytuje dane zmodyfikowane przez inną transakcję, która nie została jeszcze zatwierdzona. Może to prowadzić do błędów, jeśli pierwsza transakcja podejmuje decyzje na podstawie niezatwierdzonych zmian, które mogą zostać wycofane.
• Niewyznaczone odczyty: Transakcja otrzymuje odpowiedź z bazy danych, wraca po powtórny odczyt i dostaje inny wynik, ponieważ w międzyczasie inna transakcja zmodyfikowała dane.
• Widma: Transakcja zlicza wiersze spełniające określone kryteria, tylko po to, by przy kolejnym sprawdzeniu odkryć, że liczba się zmieniła, ponieważ inna transakcja dodała lub usunęła wiersze.
• Anomalie szeregowania: Gdy transakcje wykonują się bez zachowania ścisłego porządku, kończy się to chaosem — jak nieuporządkowana bitwa, w której nic nie trafia tam, gdzie powinno.

Poziomy izolacji w bazie danych zarządzają stopniem interakcji między transakcjami. Wyższy poziom izolacji oznacza, że transakcje działają bardziej „w próżni,” chronione przed aktywnością innych, co może spowolnić operacje, ponieważ baza danych musi włożyć więcej wysiłku, by utrzymać ich rozdzielność.

Ostateczny wybór poziomu izolacji zależy od specyficznych wymagań aplikacji, w tym od akceptowalnego ryzyka anomalii danych w stosunku do potrzeby jednoczesnego dostępu do danych.

Jak osiąga się izolację?

• Mechanizmy blokowania, podobnie jak w przypadku niepodzielności, polegają na ograniczeniu dostępu do danych wykorzystywanych przez daną transakcję. Blokady mogą być stosowane na różnych poziomach szczegółowości, od całej bazy danych po konkretne wiersze, a nawet kolumny.
• Porządkowanie według znaczników czasowych przypisuje każdej transakcji unikalny znacznik czasowy, który określa kolejność wykonywania. Transakcje są przetwarzane na podstawie ich znaczników czasowych, co oznacza, że starsze transakcje mają priorytet, a nowsze nie mogą „przeskakiwać kolejki” i naruszać wcześniej ustalonych działań.
• Izolacja migawkowa korzysta z koncepcji MVCC, ale zapewnia, że wszystkie operacje odczytu w transakcji widzą dane tak, jak wyglądały na początku transakcji. Ten poziom izolacji wspiera spójność odczytów bez konieczności stosowania rozległych blokad, co poprawia wydajność.
• Szeregowalność przetwarza transakcje sekwencyjnie, jedna po drugiej, co skutecznie eliminuje możliwość wzajemnego wpływu transakcji. Osiąga się to poprzez traktowanie konfliktów transakcyjnych w taki sposób, że sprawia to wrażenie, jakby transakcje były przetwarzane pojedynczo, w kolejności.

Trwałość

Trwałość polega na zapewnieniu, że po zatwierdzeniu transakcji pozostaje ona w tym stanie, na stałe. Powinna być trwale zapisana i odporna na późniejsze awarie systemu, takie jak przerwy w dostawie prądu czy awarie.

Główne zadanie trwałości to umieszczenie każdej zakończonej transakcji w niezawodnej, nieulotnej pamięci, po to aby jej zapis nie zniknął, gdy system zostanie wyłączony. Ta trwałość gwarantuje, że bez względu na to, jakie elektroniczne kataklizmy dotkną system, będzie on mógł się „obudzić”, otrzepać z cyfrowego kurzu i pamiętać wszystko, co wydarzyło się do ostatniej zatwierdzonej transakcji. Niczym niezłomna pamięć, która, nawet w obliczu chaosu, nie zapomina danych i obietnic.

Na przykład…

Weźmy pod uwagę system bankowy, w którym użytkownik przelewa środki z jednego konta na drugie. Transakcja obejmuje obciążenie jednego konta i uznanie drugiego. Po potwierdzeniu transakcji i aktualizacji sald system musi zapewnić, że te zmiany zostaną trwale zapisane. Jeśli zaraz po zakończeniu transakcji, ale przed jej zapisaniem na dysku, wystąpi awaria zasilania lub systemu, trwałość gwarantuje, że efekty transakcji nie zostaną utracone.

Kiedy system odzyskuje sprawność, wykorzystuje dzienniki lub inne mechanizmy, aby przywrócić lub dokończyć zapis transakcji, zapewniając, że salda kont odzwierciedlają przelew dokładnie tak, jakby zakłócenie nigdy nie miało miejsca.

Jak osiągnąć trwałość?

• Logowanie z wyprzedzeniem (Write-Ahead Logging) opiera się na prostej, lecz kluczowej zasadzie: najpierw zapisz swoje zamiary w logu, a dopiero potem wprowadź je w bazie danych. Gdyby rzeczywistość (czyli system) nagle się „zbuntowała” i zawiesiła, log ten pozwala odtworzyć ostatni spójny stan bazy danych przed nastaniem chaosu.
• Logi redo są używane do ponownego wykonania operacji, aby przywrócić bazę do aktualnego stanu. Logi undo mogą cofnąć zmiany do poprzedniego stanu, jeśli wymaga tego transakcja. Te logi są kluczowe dla procesów odzyskiwania, zapewniając, że żadna zatwierdzona transakcja nie zostanie utracona, ponieważ baza danych może zawsze wrócić do spójnego stanu po awarii.
• Punkty kontrolne są tworzone okresowo jako migawki bazy danych w określonym momencie. Zawierają one informacje o zapisanych danych i wszelkich oczekujących zmianach zapisanych w logach. W przypadku ponownego uruchomienia systemu baza danych wykorzystuje najnowszy punkt kontrolny i logi, aby szybko przywrócić bazę do ostatniego spójnego stanu.
• Replikacja polega na utrzymywaniu kopii danych na wielu maszynach lub systemach magazynowania. Ta redundancja zapewnia, że jeśli jedna część systemu zawiedzie, inne części mogą kontynuować działanie bez utraty danych.
• Protokoły, takie jak protokół dwufazowego zatwierdzania (dla baz danych rozproszonych), zapewniają, że wszystkie uczestniczące węzły albo zatwierdzą, albo wycofają zmiany wspólnie.

Korzyści wynikające z właściwości ACID

Właściwości składające się na ten akronim wspólnie zapewniają niezawodne działanie baz danych oraz bezpieczeństwo i efektywność transakcji, przynosząc wiele korzyści.

Niezawodność i integralność

Właściwości ACID zapewniają, że transakcje są przetwarzane w sposób niezawodny, utrzymując integralność bazy danych nawet w obliczu chaosu — czy to podczas awarii systemu, czy w przypadku nagłej przerwy w dostawie prądu. Ta niezłomna niezawodność jest nieoceniona dla każdego, kto zarządza kluczowymi danymi, takimi jak dane finansowe, wrażliwe informacje osobowe czy szczegóły codziennych operacji biznesowych.

Przewidywalność transakcji

Dzięki egzekwowaniu właściwości ACID, programiści i administratorzy baz danych mogą znacznie łatwiej przewidywać zachowanie transakcji. Taka przewidywalność ułatwia debugowanie oraz poprawę wydajności aplikacji, ponieważ znane są już standardowe zachowania bazy danych i przewidywalne wyniki transakcji.

Spójność danych między aplikacjami

Pod czujnym okiem spójności, tylko najlepsze dane przechodzą dalej. Każdy fragment danych musi przejść rygorystyczne testy zgodności z zasadami, ograniczeniami i wyzwalaczami, zanim trafi na „scenę” bazy danych. Zapobiega to anomaliom danych i błędom integralności.

Zwiększona odporność na awarie

Właściwości trwałości i niepodzielności zwiększają odporność systemu na awarie. Modyfikacje dokonane przez transakcje, które zakończą się sukcesem, są trwałe, nawet w przypadku awarii systemu zaraz po zakończeniu transakcji. Oznacza to, że procesy odzyskiwania są prostsze i bardziej niezawodne, co zmniejsza ryzyko utraty danych.

Uproszczone tworzenie aplikacji

Dzięki zapewnieniu integralności transakcji na poziomie bazy danych, właściwości ACID zwalniają programistów z obowiązku implementowania tych kontroli w logice aplikacji. To uproszczenie pozwala im skupić się bardziej na logice biznesowej aplikacji, zamiast na złożonościach związanych ze spójnością danych i procesami odzyskiwania.

Wady właściwości ACID

Chociaż właściwości ACID przynoszą wiele korzyści dla systemów zarządzania bazami danych, wiążą się również z pewnymi wyzwaniami i kompromisami, szczególnie w zakresie wydajności, skalowalności i złożoności systemu.

Obciążenie wydajności

Ścisłe egzekwowanie właściwości ACID może powodować znaczne obciążenie wydajności. Operacje takie jak logowanie, blokowanie i utrzymywanie logów transakcji w celu zapewnienia niepodzielności i trwałości wymagają dodatkowego czasu przetwarzania i zasobów. W środowiskach o dużej liczbie transakcji, gdzie szybki dostęp do danych i ich aktualizacje są kluczowe, może to przypominać poruszanie się przez „morze melasy”.

Problemy ze skalowalnością

Skalowanie bazy danych zgodnej z ACID może być równie skomplikowane, jak koordynacja grupowego projektu w różnych strefach czasowych, zwłaszcza w przypadku rozproszonych systemów bazodanowych. Wymóg ścisłej spójności i poziomów izolacji może ograniczać zdolność bazy danych do efektywnego rozwoju na wiele węzłów. W miarę jak bazy danych rosną i pojawia się więcej węzłów, utrzymanie spójności i synchronizacji między nimi staje się bardziej złożone i wymaga więcej zasobów.

Złożoność zarządzania i projektowania

Implementacja i utrzymanie właściwości ACID wymaga zaawansowanych technik zarządzania oraz złożonej architektury. Każdy element układanki musi idealnie do siebie pasować.

Na przykład protokół dwufazowego zatwierdzania, niezbędny do zapewnienia niepodzielności w rozproszonych systemach, jest trudny do wdrożenia i zarządzania. Dodatkowo, potrzeba obsługi różnych aspektów transakcji, takich jak mechanizmy wycofywania czy kontrola współbieżności, zwiększa złożoność projektowania i obsługi bazy danych.

Ograniczenia współbieżności

Izolacja pomaga zapobiegać wzajemnemu zakłócaniu się transakcji, ale może również powodować wąskie gardła. Mechanizmy blokowania chronią integralność danych, jednak mogą spowalniać dostęp, powodując, że transakcje ustawiają się w kolejce niczym klienci przed otwarciem sklepu.

Wymagania zasobów

Utrzymanie trwałości i niepodzielności jest „zasobożerne” — może pochłaniać zasoby systemowe szybciej niż darmowy bufet, wpływając na ogólną wydajność bazy danych i zwiększając koszty operacyjne, zwłaszcza w systemach o dużej liczbie transakcji.

Zmniejszona elastyczność

Sztywna struktura niezbędna do utrzymania właściwości ACID może ograniczać aplikacje, które wymagają elastyczności i szybkiego czasu reakcji. Ta sztywność może czasem utrudniać wydajność i użyteczność w sytuacjach, gdzie kluczowe jest szybkie przetwarzanie danych.

Trudności w środowiskach rozproszonych

Utrzymanie właściwości ACID w środowiskach rozproszonych jest szczególnie trudne. Konieczność stosowania globalnych blokad i skoordynowanych zatwierdzeń może prowadzić do zwiększonej złożoności i ryzyka wystąpienia zakleszczeń, zwłaszcza w geograficznie rozproszonych bazach danych, gdzie istotną rolę odgrywa opóźnienie sieci.

Ostateczna spójność (Eventual Consistency)

Ostateczna spójność to model najczęściej spotykany w obliczeniach rozproszonych, którego celem jest osiągnięcie spójności bazy danych w dłuższym czasie. W tym modelu baza danych nie musi być natychmiastowo spójna po dokonaniu transakcji lub aktualizacji. Zamiast tego system gwarantuje, że jeśli do danych nie są wprowadzane nowe aktualizacje, ostatecznie wszystkie odczyty tych danych zwrócą ostatnią zaktualizowaną wartość. Podejście to jest zasadniczo inne niż właściwości ACID.

Ostateczna spójność pozwala na wyższy poziom dostępności i może poprawić wydajność w sieciach rozproszonych, gdzie propagacja danych między węzłami wymaga czasu. Model ten jest szczególnie przydatny w sytuacjach, gdzie system może tolerować pewien stopień opóźnienia w spójności danych między węzłami. Z tego powodu ostateczna spójność jest często akceptowalna w systemach takich jak kanały w mediach społecznościowych, gdzie dostęp do najnowszych danych nie jest kluczowy dla działania aplikacji.

Różnice w stosunku do właściwości ACID

W debacie między ACID a ostateczną spójnością, każdy model oferuje unikalne zalety i wyzwania. Szczególnie gdy porównujemy ich wpływ na spójność, dostępność, wydajność i złożoność systemu.

Spójność vs. dostępność

ACID ceni sobie zasady. Utrzymuje, że każda transakcja musi przenieść bazę danych z jednego poprawnego stanu do drugiego, nie naruszając żadnych zasad integralności, których skrupulatnie przestrzega. Ta dbałość o szczegóły czasem przekłada się jednak na poświęcenie dostępności, zwłaszcza gdy sieć postanowi zrobić sobie przerwę.

W przypadku podziału sieci ACID może zablokować zasoby, aby zachować czystość danych. To jak zamknięcie drogi, ponieważ jeden sygnalizator przestał działać. Ostateczna spójność jest bardziej elastycznym rozwiązaniem. Rozprowadza aktualizacje między węzłami w swoim własnym tempie, pozwalając systemowi zachować spokój i pozostawać online, nawet jeśli oznacza to, że dane mogą być chwilowo niespójne. W podejściu tym akceptuje się pewien stopień niedoskonałości danych, dopóki użytkownicy mogą nadal korzystać z usługi.

Wpływ na wydajność

Implikacje wydajnościowe ACID są znaczące, głównie ze względu na narzut wprowadzany przez mechanizmy niezbędne do zapewnienia niezawodnego przetwarzania transakcji. Mowa tutaj o mechanizmach takich jak blokowanie i logowanie. Czym jest ACID w kontekście baz danych? Te procesy, kluczowe dla utrzymania niepodzielności i trwałości, mogą spowalniać system, zwłaszcza w sytuacjach z częstymi operacjami zapisu.

W przeciwieństwie do tego, ostateczna spójność zazwyczaj wykazuje lepsze wskaźniki wydajności, szczególnie w środowiskach z intensywnymi operacjami zapisu. Bez konieczności natychmiastowego zapewnienia spójności na wszystkich węzłach, systemy korzystające z ostatecznej spójności zmniejszają opóźnienia przetwarzania transakcji. W efekcie umożliwiają szybsze reakcje i bardziej płynne doświadczenie użytkownika.

Złożoność systemu i narzut

Zarządzanie systemem zgodnym z ACID nie jest sprawą prostą. Tego typu systemy wymagają zaawansowanych protokołów zarządzania transakcjami, zdolnych do obsługi wycofywania operacji oraz wspierających solidne procedury zatwierdzania, takie jak protokół dwufazowego zatwierdzania. Dodatkowo, konieczne jest kompleksowe przetwarzanie błędów, aby poradzić sobie z różnymi sytuacjami, które mogą zagrozić integralności transakcji. Ta złożoność może zwiększać koszty i wymagania zasobowe związane z utrzymaniem takich systemów.

Z drugiej strony, systemy wdrażające ostateczną spójność mają zazwyczaj prostszą architekturę zarządzania transakcjami. Choć mniej wymagają natychmiastowej synchronizacji, wymagają jednak starannego projektowania, jeśli chodzi o efektywne zarządzanie i rozwiązywanie niespójności oraz konfliktów danych, które naturalnie pojawiają się w systemach bez rygorystycznych kontroli spójności.