KWAS

W przypadku innych zastosowań zobacz Kwas (ujednoznacznienie) .

W informatyce ACID ( niepodzielność , spójność , izolacja , trwałość ) to zestaw właściwości transakcji bazodanowych mających na celu zagwarantowanie ważności danych pomimo błędów, awarii zasilania i innych nieszczęść. W kontekście baz danych sekwencja operacji na bazie danych, która spełnia właściwości ACID (którą można postrzegać jako pojedynczą operację logiczną na danych) nazywana jest transakcją . Na przykład przelew środków z jednego konta bankowego na inny, nawet obejmujący wiele zmian, takich jak obciążenie jednego konta i uznanie drugiego, jest pojedynczą transakcją.

W 1983 roku Andreas Reuter i Theo Härder ukuli akronim ACID , opierając się na wcześniejszej pracy Jima Graya , który opisując koncepcję transakcji, nazwał atomowość, spójność i trwałość, ale nie izolację. Te cztery właściwości są głównymi gwarancjami paradygmatu transakcji, który wpłynął na wiele aspektów rozwoju systemów bazodanowych.

Według Graya i Reutera IBM Information Management System obsługiwał transakcje ACID już w 1973 roku (chociaż akronim powstał później).

Charakterystyka

Charakterystyka tych czterech właściwości określonych przez Reutera i Härdera jest następująca:

Atomowość

Główny artykuł: atomowość (systemy baz danych)

Transakcje często składają się z wielu wyciągów . Atomicity gwarantuje, że każda transakcja jest traktowana jako pojedyncza „jednostka”, która albo całkowicie się powiedzie, albo całkowicie się nie powiedzie: jeśli którakolwiek z instrukcji składających się na transakcję nie zostanie zakończona, cała transakcja kończy się niepowodzeniem, a baza danych pozostaje niezmieniona. System atomowy musi gwarantować atomowość w każdej sytuacji, w tym w przypadku awarii zasilania, błędów i awarii. Gwarancja niepodzielności zapobiega częściowym aktualizacjom bazy danych, co może powodować większe problemy niż całkowite odrzucenie całej serii. W rezultacie transakcja nie może być obserwowana przez innego klienta bazy danych. W jednym momencie jeszcze się nie wydarzyło, aw następnym już się wydarzyło w całości (lub nic się nie wydarzyło, jeśli transakcja była anulowana w toku).

Konsystencja

Główny artykuł: Spójność (systemy baz danych)

Spójność zapewnia, że ​​transakcja może przenieść bazę danych tylko z jednego spójnego stanu do innego, zachowując niezmienniki bazy danych : wszelkie dane zapisywane w bazie danych muszą być ważne zgodnie ze wszystkimi zdefiniowanymi regułami, w tym ograniczeniami , kaskadami , wyzwalaczami i dowolną ich kombinacją. Zapobiega to uszkodzeniu bazy danych przez nielegalną transakcję. Integralność referencyjna gwarantuje relację klucz podstawowy – klucz obcy .

Izolacja

Główny artykuł: Izolacja (systemy baz danych)

Transakcje są często wykonywane jednocześnie (np. jednoczesne odczytywanie i zapisywanie wielu transakcji do tabeli). Izolacja zapewnia, że ​​jednoczesne wykonywanie transakcji pozostawia bazę danych w takim samym stanie, jaki zostałby uzyskany, gdyby transakcje były wykonywane sekwencyjnie. Izolacja jest głównym celem kontroli współbieżności ; w zależności od zastosowanego poziomu izolacji skutki niekompletnej transakcji mogą nie być widoczne dla innych transakcji.

Trwałość

Główny artykuł: Trwałość (systemy baz danych)

Trwałość gwarantuje, że raz zatwierdzona transakcja pozostanie zatwierdzona nawet w przypadku awarii systemu (np. przerwy w dostawie prądu lub awarii ). Zwykle oznacza to, że zrealizowane transakcje (lub ich efekty) są zapisywane w pamięci nieulotnej . [ potrzebne źródło ]

Przykłady

Poniższe przykłady dodatkowo ilustrują właściwości ACID. W tych przykładach tabela bazy danych ma dwie kolumny, A i B. Ograniczenie integralności wymaga, aby suma wartości w A i B wynosiła 100. Poniższy kod SQL tworzy tabelę w sposób opisany powyżej: 

             UTWÓRZ  TABELĘ  test kwasowy  (  A  LICZBA CAŁKOWITA  ,  LICZBA CAŁKOWITA  B  ,  SPRAWDŹ  (  A  +  B  =  100  ));

Atomowość

Niepodzielność to gwarancja, że ​​seria operacji na bazie danych w niepodzielnej transakcji zostanie wykonana albo wszystkie (operacja pomyślna), albo żadna (operacja nieudana). Szereg operacji nie może być rozdzielony i tylko część z nich jest wykonywana, co sprawia, że ​​szereg operacji jest „niepodzielny”. Gwarancja niepodzielności zapobiega częściowym aktualizacjom bazy danych, co może powodować większe problemy niż całkowite odrzucenie całej serii. Innymi słowy atomowość oznacza niepodzielność i nieredukowalność. Alternatywnie możemy powiedzieć, że transakcja logiczna może składać się z kilku transakcji fizycznych. Jeżeli i dopóki nie zostaną wykonane wszystkie fizyczne transakcje składowe, transakcja logiczna nie nastąpi.

Przykładem transakcji atomowej jest przelew pieniężny z rachunku bankowego A na rachunek B. Składa się on z dwóch operacji, wypłaty pieniędzy z rachunku A i zapisania ich na rachunek B. Nie chcielibyśmy, aby kwota została usunięta z rachunku A przed jesteśmy pewni, że został on również przekazany na konto B. Wykonanie tych operacji w transakcji atomowej zapewnia, że ​​baza danych pozostaje w spójnym stanie , to znaczy, że pieniądze nie są ani obciążane, ani uznawane, jeśli którakolwiek z tych dwóch operacji się nie powiedzie.

Brak spójności

Spójność to bardzo ogólne pojęcie, które wymaga, aby dane spełniały wszystkie zasady walidacji. W poprzednim przykładzie sprawdzanie poprawności jest wymaganiem, aby A + B = 100 . Wszystkie reguły walidacji muszą zostać sprawdzone, aby zapewnić spójność. Załóżmy, że transakcja próbuje odjąć 10 od A bez zmiany B . Ponieważ spójność jest sprawdzana po każdej transakcji, wiadomo, że A + B = 100 przed rozpoczęciem transakcji. Jeśli transakcja pomyślnie usunie 10 z A , zostanie osiągnięta niepodzielność. Jednak sprawdzenie poprawności wykaże, że A + B = 90 , co jest niezgodne z regułami bazy danych. Cała transakcja musi zostać anulowana, a wiersze, których to dotyczy, muszą zostać przywrócone do stanu sprzed transakcji. Gdyby istniały inne ograniczenia, wyzwalacze lub kaskady, każda pojedyncza operacja zmiany zostałaby sprawdzona w taki sam sposób jak powyżej przed zatwierdzeniem transakcji. Podobne problemy mogą pojawić się w przypadku innych ograniczeń. Mogliśmy wymagać, aby typy danych zarówno A , jak i B były liczbami całkowitymi. Gdybyśmy wtedy wpisali np. wartość 13,5 dla A , transakcja zostanie anulowana lub system może wygenerować alert w postaci wyzwalacza (o ile/kiedy wyzwalacz został tak zapisany). Innym przykładem mogą być ograniczenia integralności, które nie pozwalają nam usunąć wiersza w jednej tabeli, do którego klucza podstawowego odwołuje się co najmniej jeden klucz obcy w innych tabelach.

Awaria izolacji

Aby zademonstrować izolację, zakładamy, że dwie transakcje są wykonywane w tym samym czasie, a każda z nich próbuje zmodyfikować te same dane. Jeden z nich musi czekać, aż drugi zakończy, aby zachować izolację.

Rozważ dwie transakcje:

  • T 1 przenosi 10 z A do B.
  • T 2 przenosi 20 z B do A.

Łącznie istnieją cztery działania:

  1. T 1 odejmuje 10 od A.
  2. T 1 dodaje 10 do B.
  3. T2 odejmuje 20 od B.
  4. T2 dodaje 20 do A.

Jeśli te operacje są wykonywane po kolei, izolacja jest zachowana, chociaż T2 musi czekać. Zastanów się, co się stanie, jeśli T 1 zawiedzie w połowie. Baza danych eliminuje efekty T 1 , a T 2 widzi tylko prawidłowe dane.

Przeplatając transakcje, rzeczywista kolejność działań może być następująca:

  1. T 1 odejmuje 10 od A.
  2. T2 odejmuje 20 od B.
  3. T2 dodaje 20 do A.
  4. T 1 dodaje 10 do B.

Ponownie rozważ, co się stanie, jeśli T1 zawiedzie podczas modyfikowania B w kroku 4. Zanim T1 zawiedzie , T2 już zmodyfikował A; nie można go przywrócić do wartości sprzed T 1 bez pozostawienia nieprawidłowej bazy danych. Jest to znane jako konflikt zapisu-zapisu , [ potrzebne źródło ] , ponieważ dwie transakcje próbowały dokonać zapisu w tym samym polu danych. W typowym systemie problem zostałby rozwiązany przez powrót do ostatniego znanego dobrego stanu, anulowanie nieudanej transakcji T1 i wznowienie przerwanej transakcji T2 ze stanu dobrego.

Błąd trwałości

Rozważmy transakcję, która przenosi 10 z A do B. Najpierw usuwa 10 z A, a następnie dodaje 10 do B. W tym momencie użytkownik otrzymuje informację, że transakcja zakończyła się sukcesem. Jednak zmiany są nadal umieszczane w kolejce w buforze dysku , czekając na zatwierdzenie na dysku. Awaria zasilania i zmiany są tracone, ale użytkownik zakłada (co zrozumiałe), że zmiany się utrzymują.

Realizacja

Przetwarzanie transakcji często wymaga sekwencji operacji, które mogą się nie powieść z wielu powodów. Na przykład system może nie mieć wolnego miejsca na swoich dyskach lub mógł zużyć przydzielony czas procesora. Istnieją dwie popularne rodziny technik: rejestrowanie z wyprzedzeniem i stronicowanie w tle . W obu przypadkach należy uzyskać blokady na wszystkich informacjach, które mają być aktualizowane, oraz w zależności od poziomu izolacji, ewentualnie na wszystkich danych, które można odczytać. W rejestrowaniu zapisu z wyprzedzeniem trwałość jest gwarantowana przez skopiowanie oryginalnych (niezmienionych) danych do dziennika przed zmianą bazy danych. [ wątpliwe – dyskutuj ] Umożliwia to powrót bazy danych do spójnego stanu w przypadku awarii. W shadowingu aktualizacje są stosowane do częściowej kopii bazy danych, a nowa kopia jest aktywowana po zatwierdzeniu transakcji.

Blokowanie a multiwersjonowanie

Wiele baz danych polega na blokowaniu w celu zapewnienia możliwości ACID. Blokowanie oznacza, że ​​transakcja oznacza dane, do których uzyskuje dostęp, tak aby DBMS wiedział, że nie może pozwolić innym transakcjom na ich modyfikację, dopóki pierwsza transakcja nie powiedzie się lub nie. Blokada musi być zawsze uzyskana przed przetwarzaniem danych, w tym danych, które są odczytywane, ale nie są modyfikowane. Nietrywialne transakcje zwykle wymagają dużej liczby blokad, co powoduje znaczne koszty ogólne, a także blokuje inne transakcje. Na przykład, jeśli użytkownik A przeprowadza transakcję, która musi odczytać wiersz danych, które użytkownik B chce zmodyfikować, użytkownik B musi poczekać, aż transakcja użytkownika A zostanie zakończona. Aby zagwarantować pełną izolację, często stosuje się blokowanie dwufazowe .

Alternatywą dla blokowania jest wielowersyjna kontrola współbieżności , w której baza danych zapewnia każdej transakcji odczytu poprzednią, niezmodyfikowaną wersję danych, która jest modyfikowana przez inną aktywną transakcję. Dzięki temu czytniki mogą działać bez uzyskiwania blokad, tj. transakcje zapisu nie blokują transakcji odczytu, a czytniki nie blokują pisarzy. Wracając do przykładu, gdy transakcja użytkownika A żąda danych, które modyfikuje użytkownik B, baza danych udostępnia A wersję tych danych, które istniały, gdy użytkownik B rozpoczynał transakcję. Użytkownik A uzyskuje spójny widok bazy danych, nawet jeśli inni użytkownicy zmieniają dane. Jedna implementacja, a mianowicie izolacja migawek , rozluźnia właściwość izolacji.

Transakcje rozproszone

Główny artykuł: Transakcja rozproszona

Zagwarantowanie właściwości ACID w transakcji rozproszonej w rozproszonej bazie danych , w której żaden pojedynczy węzeł nie jest odpowiedzialny za wszystkie dane mające wpływ na transakcję, stwarza dodatkowe komplikacje. Połączenia sieciowe mogą ulec awarii lub jeden węzeł może pomyślnie zakończyć swoją część transakcji, a następnie będzie musiał wycofać swoje zmiany z powodu awarii w innym węźle. Protokół zatwierdzania dwufazowego (nie mylić z blokowaniem dwufazowym ) zapewnia niepodzielność transakcji rozproszonych , aby zapewnić, że każdy uczestnik transakcji zgadza się, czy transakcja powinna zostać zatwierdzona, czy nie. W skrócie, w pierwszej fazie jeden węzeł (koordynator) przepytuje pozostałe węzły (uczestnicy) i dopiero gdy wszystkie odpowiadają, że są przygotowane, koordynator w drugiej fazie formalizuje transakcję.

Zobacz też

Pobrano z „ https://en.wikipedia.org/w/index.php?title=ACID&oldid=1126480788 ”