Koncepcja KWASU

3.1 Pojawienie się KWASU

Skrót ACID pojawił się po raz pierwszy w 1983 roku w artykule Theo Haerdera i Andreasa Reutera. Aby uprościć tekst i uczynić go bardziej przekonującym, podam tłumaczenie fragmentu tego artykułu (z niewielkimi skrótami). W tym fragmencie wykorzystano przykład transakcji bankowej, w której pieniądze są przesyłane z jednego konta na drugie.

Koncepcja transakcji, która w przykładzie obejmuje wszystkie interakcje z bazą danych pomiędzy $BEGIN_TRANSACTIONi $COMMIT_TRANSACTION, wymaga, aby wszystkie akcje były wykonywane niepodzielnie: albo wszystkie akcje są odpowiednio odzwierciedlone w stanie bazy danych, albo nic się nie dzieje. Jeśli w dowolnym momencie przed dotarciem do $COMMIT_TRANSACTIONużytkownika użytkownik wprowadzi oświadczenie ERRORzawierające $RESTORE_TRANSACTION, to żadne zmiany nie zostaną odzwierciedlone w bazie danych.

Aby osiągnąć tę niepodzielność, transakcja musi mieć następujące cztery właściwości:

Atomowość (atomowość). Transakcja musi być typu „wszystko albo nic” opisanego powyżej i bez względu na to, co się stanie, użytkownik musi wiedzieć, w jakim stanie jest transakcja.

Spójność (Konsystencja). Transakcja, która osiąga swój normalny koniec transakcji (EOT) i tym samym zatwierdza swoje wyniki, zachowuje spójność bazy danych. Innymi słowy, każda udana transakcja z definicji generuje tylko prawidłowe wyniki. Ten warunek jest niezbędny do obsługi czwartej właściwości - trwałości.

Izolacja (izolacja). Zdarzenia występujące w ramach transakcji muszą być ukryte przed innymi współbieżnie wykonywanymi transakcjami. Gdyby ten warunek nie został spełniony, to z przyczyn wymienionych powyżej transakcja byłaby niemożliwa do powrotu do początku. Aby osiągnąć izolację, stosuje się metody zwane synchronizacją ...

Trwałość (Trwałość). Po zakończeniu transakcji i zatwierdzeniu jej wyników w bazie danych system musi zapewnić, że wyniki te przetrwają wszelkie kolejne awarie. Ponieważ nie ma zakresu kontroli obejmującego zestawy transakcji, system zarządzania bazą danych (DBMS) nie ma kontroli poza granicami transakcji.

Dlatego użytkownik musi mieć gwarancję, że jeśli system poinformuje go, że coś się stało, to to „coś” wydarzyło się naprawdę. Ponieważ z definicji każda (zakończona pomyślnie - S.K.) transakcja jest poprawna, skutki nieuchronnie pojawiających się błędnych transakcji (tj.

3.2 Pojawienie się transakcji

Te cztery właściwości — niepodzielność, spójność, izolacja i trwałość (ACID) — opisują podstawowe cechy paradygmatu transakcyjnego, które wpływają na wiele aspektów projektowania systemów baz danych. Dlatego uważamy, że zdolność dowolnego systemu do obsługi transakcji jest probierzem (test ACID) jakości tego systemu.

Prosty program PL/1-SQL, który przenosi środki z jednego konta na drugie.

FUNDS_TRANSFER. PROCEDURE,
 $BEGIN_TRANSACTION;
 ON ERROR DO;                                   /* in case of error */
          $RESTORE_TRANSACTION,                 /* undo all work */
          GET INPUT MESSAGE;                    /* reacquire input */
          PUT MESSAGE ('TRANSFER FAILED');      /* report failure */
          GO TO COMMIT;
          END;
 GET INPUT MESSAGE;                             /* get and parse input */
 EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
  AMOUNT FROM MESSAGE,
 $UPDATE ACCOUNTS                               /* do debit */
              SET BALANCE ffi BALANCE - AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
 $UPDATE ACCOUNTS                               /* do credit */
              SET BALANCE = BALANCE + AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
 $INSERT INTO HISTORY                           /* keep audit trail */
    <DATE, MESSAGE>;
 PUT MESSAGE ('TRANSFER DONE');                 /* report success */
COMMIT:                                         /* commit updates */
 $COMMIT_TRANSACTION;
 END;                                           /* end of program */

Podałem przykład tego kodu, aby przypomnieć, że w rzeczywistości właściwości ACID z jednej strony można uznać za wymagania dla każdego DBMS, który twierdzi, że obsługuje transakcje, a z drugiej strony za definicję transakcji w system bazy danych . Ta definicja jest w pełni zgodna ze światową praktyką. Trudno sobie np. wyobrazić, że klient dokonując transakcji bankowej (czy to przy pomocy kasjera na żywo, czy korzystając z bankowości internetowej) nie oczekuje od banku spełnienia wszystkich właściwości ACID. Bank, który nie obsługuje właściwości ACID dla swoich transakcji, w najlepszym przypadku straci klientów, aw najgorszym zbankrutuje.

3.3 Łączność ACID

Bardzo ważne jest, aby właściwości ACID były nierozłączne, odrzucenie którejkolwiek z nich powoduje, że pozostałe kombinacje są bez znaczenia. W szczególności, jeśli odrzucimy właściwość spójności (w znaczeniu, w jakim została użyta w powyższym cytacie), to utracimy kryterium poprawności transakcji. System bazy danych nie będzie w stanie w żaden sensowny sposób decydować, czy transakcje są dozwolone, czy nie, a wszelkie sprawdzenia poprawności operacji wykonywanych w bieżącym stanie bazy danych będą musiały być wykonywane w kodzie aplikacji.

Musisz zrozumieć, że w tym przypadku mówimy o logicznej spójności. Klient banku potrzebuje, aby bank działał według ustalonych przez niego i znanych klientom zasad, tak aby niemożliwe było wykonanie jakiejkolwiek transakcji naruszającej te zasady, tak aby następna transakcja tego samego klienta była realizowana w środowisku uzgodnionym zgodnie z tymi zasadami.

Klient sklepu internetowego potrzebuje, aby zamówiony i opłacony przez niego towar został mu dostarczony terminowo (zgodnie z ustalonymi i znanymi klientowi zasadami). W przeciwnym razie nie zaufa temu sklepowi. Jednocześnie ani klienta banku, ani klienta sklepu internetowego nie obchodzi wewnętrzna kuchnia przedsiębiorstwa, jakie działania wewnętrzne są podejmowane w celu sfinalizowania jego transakcji. Klienta nie obchodzi, jak zachowana jest fizyczna spójność tego przedsiębiorstwa, jak wykonywane są operacje w warstwie fizycznej.

Jeśli DBMS dba o zachowanie logicznej spójności transakcji (i bazy danych), to aplikacje stają się prostsze, bardziej zrozumiałe i bardziej niezawodne. Cała logika obszaru aplikacji (bank, sklep, magazyn, itp.) dotycząca transakcji i aktualnego stanu danych trafia do systemu bazodanowego. A wymagania wobec tego systemu są bardzo proste: obsługa transakcji ACID z uwzględnieniem reguł spójności dostarczonych w bazie danych przez aplikację. Z mojego punktu widzenia odrzucanie transakcji ACID przysparza niesłychanych trudności twórcom aplikacji, którzy chcąc nie chcąc, sami będą musieli zaimplementować coś podobnego, aby zaspokoić naturalne potrzeby swoich klientów.

I jeszcze raz zauważam, że właściwości ACID w rzeczywistości definiują pojęcie transakcji. Moim zdaniem, aby choć w części móc mówić o systemie zarządzania danymi transakcyjnymi, w którym nie jest obsługiwana właściwość spójności transakcji, bezwzględnie konieczne jest zdefiniowanie, co w tym przypadku należy rozumieć pod pojęciem transakcja.

Niestety, dzisiaj w wielu przypadkach (w szczególności jest to charakterystyczne dla kierunku NoSQL) mówi się o wspieraniu aplikacji OLTP, nie precyzując w ogóle, o jakie transakcje chodzi. Dlatego też w tym artykule będę używał kombinacji ACID transakcja w odniesieniu do rzeczywistych transakcji, a termin bez zastrzeżeń transakcja będzie używany w sensie nieformalnym, różnym w różnych kontekstach.

Zajmijmy się teraz „twierdzeniem” CAP i spróbujmy dowiedzieć się, co oznacza spójność w sensie Brewera.