Multiversion Concurrency Control (MVCC)

Multiversion Concurrency Control (MVCC) – technika zarządzania współbieżnym dostępem w systemach systemach zarządzania bazą danych (DBMS), polegająca na przechowywaniu wielu wersji jednego wiersza danych. Dzięki temu operacje odczytu nie blokują operacji zapisu i odwrotnie, co pozwala na zwiększenie przepustowości i skrócenie czasu oczekiwania w środowiskach o dużej liczbie jednoczesnych transakcji.

Historia

Pierwsze koncepcje MVCC pojawiły się w latach 1975‑1980 w systemach baz danych takich jak Ingres oraz w badaniach nad systemami rekordowymi. Pełnoprawny opis techniki został przedstawiony w pracach Jima Graya i Andreas’a Reutera w latach 1981. Od tego czasu MVCC zostało zaimplementowane w wielu popularnych systemach, m.in. w PostgreSQL, Oracle Database, MySQL (silnik InnoDB) oraz Microsoft SQL Server (tryb snapshot isolation).

Podstawowe zasady

Wersjonowanie wierszy – każdy wiersz przechowuje dodatkowe informacje o czasie transakcji, w której został utworzony i (ewentualnie) usunięty.
Widoczność wersji – transakcja widzi tylko te wersje wierszy, które były zatwierdzone przed jej rozpoczęciem (tzw. snapshot).
Brak blokad przy odczycie – odczyt nie wymaga zakładania blokad współdzielonych, co eliminuje problem deadlocków w scenariuszach zdominowanych przez zapytania SELECT.
Mechanizm usuwania starych wersji – po zakończeniu wszystkich transakcji, które jeszcze mogą potrzebować danej wersji, stare wiersze są usuwane w procesie zwanym garbage collection (czasem określanym jako vacuum).

Implementacja

W praktyce MVCC wykorzystuje jedną z dwóch metod przechowywania wersji:

Timestampy – każda transakcja otrzymuje unikalny znacznik czasu (lub numer sekwencyjny). Wiersz zawiera pola xmin i xmax, określające odpowiednio transakcję, która wiersz utworzyła i transakcję, która go usunęła.
Numery wersji (row versioning) – wiersze mają dodatkowe pola typu rowid oraz cmin/cmax (jak w PostgreSQL) lub SCN w Oracle, które pełnią podobną rolę.

Przykład działania

Załóżmy, że w bazie istnieje wiersz A z wartością 10. Transakcja T1 rozpoczyna się w czasie t1 i odczytuje A. W tym samym czasie transakcja T2 (czas t2 > t1) aktualizuje A do 20. W wyniku MVCC T1 nadal widzi wersję 10, natomiast T2 oraz wszystkie późniejsze transakcje widzą wartość 20. Gdy T1 zakończy się commit, nie pojawia się konflikt, ponieważ operacje odczytu nie blokują zapisu.

Porównanie z innymi metodami kontroli współbieżności

Cecha	MVCC	Lock‑Based (Two‑Phase Locking)	Optimistic Concurrency Control
Blokowanie odczytu	brak	blokada współdzielona	brak (sprawdzanie przy commit)
Wydajność przy wielu odczytach	wysoka	może spadać	zależna od konfliktów
Zużycie pamięci/dysku	większe (przechowywanie wersji)	niższe	średnie
Skalowalność pozioma	dobrze wspierana (np. w systemach NoSQL)	ograniczona	zależna od liczby konfliktów

Zastosowania i implementacje

Wielu dostawców baz danych oferuje własne warianty MVCC:

PostgreSQL – klasyczna implementacja oparta na xmin/xmax oraz procesie VACUUM.
Oracle Database – tzw. read consistency oparta na SCN (System Change Number).
MySQL (silnik InnoDB) – implementacja MVCC z wersjami zapisywanymi w undo log.
Microsoft SQL Server – tryb snapshot isolation wprowadzony od wersji 2005.
SQLite – od wersji 3.7.0 obsługuje MVCC w trybie WAL (write‑ahead logging).

Korzyści

Wysoka wydajność w środowiskach z dużą liczbą jednoczesnych zapytań typu SELECT.
Redukcja liczby deadlocków i głodzenia procesów.
Lepsze wsparcie dla poziomu izolacji snapshot isolation i serializable bez konieczności długotrwałego utrzymywania blokad.

Wady i ograniczenia

Wymagane dodatkowe miejsce na dysku do przechowywania starych wersji.
Potrzeba okresowego czyszczenia nieużywanych wersji, co może generować dodatkowy narzut obliczeniowy (proces vacuum w PostgreSQL).
W niektórych scenariuszach aktualizacje „write‑write” mogą wymagać detekcji konfliktów, co wprowadza koszt przy potwierdzaniu transakcji (commit‑time checking).

Rozwój i perspektywy

W ostatnich latach MVCC stało się podstawą nie tylko tradycyjnych relacyjnych systemów, ale także nowoczesnych baz danych typu NoSQL, takich jak Cassandra czy CockroachDB. Rozwój technik multi‑version concurrency control łączy się z rosnącym zapotrzebowaniem na skalowalne, rozproszone systemy o wysokiej dostępności.