ACID – jest to akronim od angielskich słów: Atomicity (atomowość), Consisteny (spójność), Isolation (izolacja) oraz Durability (trwałość). Cztery człony akronimu mówią o zasadach gwarantujących poprawne przetwarzanie transakcji.
Hipotetyczna sytuacja w aplikacji (tabela oraz transakcja)
Atomowość (Atomicy)
Atomicity (atomowość) – mówi o tym, że albo wykona się każdy element transakcji, albo żaden. Przykładowo gdyby w powyższym przykładzie udało się pobrać z konta A 500 zł, a z
jakiegoś powodu (np. braku takiego konta) nie udało się dodać 500 zł do salda konta A to cała transakcja powinna zostać wycofana – konto A nie powinno być pomniejszone o 500 zł.
Spójność (Consistency)
Consistency (spójność) – po wykonaniu (i w trakcie) transakcji nie będzie anomalii. Przykładowo jeśli w drugim update’cie zamiast balance + 500 byłoby 'consistency’ :
UPDATE account SET balance = 'consistency' WHERE id = 2;To będzie to naruszenie spójności danych (na poziomie typu danych w kolumnie) i zostanie rzucony błąd (a dzięki atomowości, cała transakcja zostanie wycofana). Spójność także dotyczy takich aspektów jak więzy integralności (na przykład klucz obcy czy unikalny indeks).
Izolacja (Isolation)
Mowa tutaj o izolacji operacji pomiędzy dwoma (lub więcej) transakcjami – a dokładnie o poziomie izolacji pomiędzy nimi. Wyróżnia się cztery główne poziomy izolacji (zaczynając od najmniej rygorystycznych a kończąc na pełnej serializowalności):
Read Uncommitted
Read Committed
Repeatable Read
Serializable
Warto wspomnieć o tym, że im wyższy poziom izloacji zostanie wybrany tym większa będzie rywalizacja o dostęp do danych pomiędzy różnymi transakcjami. A przez co system będzie z dużym prawdopodobieństwem działał wolniej.
Trwałość (Durability)
Baza danych powinna zapewniać trwałość danych – jako, że zatwierdzone (commit) dane nie zawsze od razu trafiają do nośnika (mogą być przez jeszcze jakiś czas przetrzymywane w pamięci), to ta cecha mówi właśnie o przeniesieniu danych zatwierdzonych w transakcji (commit) do jakiegoś nośnika danych. Czyli jeśli baza danych zapewnia trwałość, to możemy być pewni, że po zakończeniu transakcji, dane na pewno zostaną utrwalone na jakimś nośniku.
Jak jest to rozwiązane?
Silniki baz danych rozwiązują problem trwałości na różne sposoby. I tak przykładowo Oracle używa redo log, SQL Server używa transaction log, PostgreSQL używa Write-Ahead Log (WAL) a MySQL wykorzystuje redo log oraz global redo buffer.
Asynchroniczne utrwalanie danych
Niektóre silniki baz danych (SQL Server, PostgreSQL, MySQL) pozwalają na rozluźnienie wymagania trwałości, poprzez asynchroniczne utrwalanie zatwierdzonych (commit) danych. Ma to na celu przyspieszenie działania systemu – poprzez rzadsze wykonywanie zapisu na nośniku. Niestety trzeba mieć z tyłu głowy, że takie rozluźnianie trwałości powoduje to, że dane dłużej przebywają w pamięci i mogą zostać bezpowrotnie utracone.