Poziom izolacji

Poziom izolacji transakcji określa, jak bardzo równolegle wykonywane operacje mogą wpływać na siebie nawzajem.

Poziom izolacji a równoległe transakcje

Poziom izolacji transakcji jest ustawieniem systemu zarządzania bazą danych, które określa, jakie zmiany wykonane przez jedną transakcję mogą być obserwowane przez inne transakcje działające w tym samym czasie. Transakcja to logiczny zestaw operacji, który powinien zostać zatwierdzony jako całość albo wycofany. Izolacja nie oznacza całkowitego zakazu równoległej pracy. Określa raczej granice widoczności danych oraz sytuacje, w których jedna transakcja musi czekać na drugą.

Wybór poziomu izolacji wpływa na kompromis między spójnością odczytu a wydajnością. Silniejsza izolacja ogranicza ryzyko odczytania danych w trakcie ich zmiany, ale może zwiększać liczbę blokad, czas oczekiwania i prawdopodobieństwo zakleszczeń. Słabsza izolacja pozwala na większą równoległość, lecz może zwracać dane, które nie stanowią jeszcze trwałego wyniku zakończonej transakcji.

Cztery klasy anomalii odczytu

Najczęściej omawiane poziomy izolacji opisuje się za pomocą anomalii występujących przy równoległym dostępie. Odczyt brudny, czyli dirty read, polega na odczytaniu zmiany, której autor jeszcze nie zatwierdził. Jeżeli tamta transakcja zostanie wycofana, odczytująca transakcja opierała się na wartości, która nigdy nie stała się trwałą częścią danych.

Odczyt niepowtarzalny, czyli non-repeatable read, występuje wtedy, gdy dwukrotny odczyt tego samego wiersza w jednej transakcji zwraca różne wartości, ponieważ inna transakcja zmieniła i zatwierdziła ten wiersz pomiędzy odczytami. Odczyt fantomowy, określany jako phantom read, dotyczy zmiany zbioru wyników: ponowne wykonanie tego samego zapytania warunkowego może zwrócić dodatkowe wiersze albo nie zwrócić wiersza widocznego wcześniej, ponieważ inna transakcja dodała, usunęła lub zmieniła pasujący rekord.

W dokumentacji i implementacjach baz danych można spotkać cztery standardowe nazwy: read uncommitted, read committed, repeatable read oraz serializable. Nazwy opisują gwarancje logiczne, ale szczegóły realizacji zależą od konkretnego silnika. Baza może używać blokad, wersjonowania wierszy albo połączenia obu mechanizmów, dlatego identyczna nazwa poziomu nie zawsze oznacza taki sam koszt wykonania.

Od odczytu brudnego do wykonania szeregowego

Read uncommitted zapewnia najsłabszą izolację. Transakcja może odczytać dane zmienione przez inną transakcję przed jej zatwierdzeniem, co dopuszcza odczyty brudne. Taki tryb może ograniczać oczekiwanie na blokady, ale wynik zapytania może być chwilowy i niezgodny ze stanem, który ostatecznie pozostanie w bazie.

Read committed nie dopuszcza odczytu niezatwierdzonych zmian. Po zatwierdzeniu cudzej modyfikacji kolejne zapytanie może jednak zobaczyć nową wartość, dlatego w obrębie jednej transakcji nie jest zagwarantowany identyczny wynik każdego ponowionego odczytu. Ten poziom jest często stosowany w aplikacjach, w których pojedyncze odczyty muszą być oparte na zatwierdzonych danych, ale cała sekwencja zapytań nie musi przedstawiać jednego niezmiennego obrazu.

Repeatable read zapewnia, że wiersze odczytane przez transakcję nie zmienią się w sposób niewidoczny dla tej transakcji przed jej zakończeniem, lecz zachowanie wobec nowych wierszy pasujących do predykatu zależy od silnika. Serializable zapewnia efekt równoważny wykonaniu transakcji jedna po drugiej. Może to wymagać blokowania zakresów, wykrywania konfliktów wersji lub wycofywania transakcji, które naruszyłyby wymagany porządek.

Dobór ustawienia i diagnostyka konfliktów

Poziom izolacji powinien wynikać z rodzaju operacji, a nie z samej nazwy aplikacji. Odczyt raportowy może wymagać spójnego obrazu wielu tabel, natomiast krótka operacja aktualizująca pojedynczy rekord może potrzebować jedynie ochrony przed odczytem brudnym. Ważne jest także ograniczanie czasu trwania transakcji, szybkie zatwierdzanie lub wycofywanie zmian oraz wykonywanie zapytań w kolejności ograniczającej ryzyko wzajemnego oczekiwania.

Objawami niewłaściwego doboru izolacji mogą być niespójne wyniki dwóch zapytań, długie oczekiwanie na blokadę, zakleszczenie albo wycofanie transakcji po wykryciu konfliktu. Diagnostyka wymaga sprawdzenia logów silnika bazy danych, czasu trwania transakcji, zapytań wykonywanych równolegle i informacji o blokadach. Sama zmiana poziomu izolacji bez zrozumienia modelu danych może ukryć problem, lecz nie naprawi błędnej kolejności operacji ani niewłaściwego zakresu transakcji.