Multiversion Concurrency Control

Multiversion Concurrency Control (MVCC, MCC, multi-generational concurrency control) ist ein Verfahren aus der Datenbanktechnik, das dazu dient, konkurrierende Zugriffe auf eine Datenbank möglichst effizient auszuführen, ohne zu blockieren oder die Konsistenz der Datenbank zu gefährden.

Dabei wird sichergestellt, dass lesende Zugriffe nie auf Schreibvorgänge in Datenbankobjekten warten müssen. Zu diesem Zweck werden intern verschiedene Versionen eines Objektes gehalten, die z. B. durch Zeitstempel oder fortlaufend erhöhte Transaktionsnummern voneinander unterschieden werden. Jede Objektversion hat dann einen Zeitstempel vom Zeitpunkt ihres Schreibens durch eine beliebige Transaktion T_bel, auf diese Weise kann Transaktion T_i die jeweils aktuelle Version des Objektes lesen, deren Zeitstempel kleiner ist als TS(T_i), d. h., die von der Transaktion

<math>\text{T}_\text{j}\text{ mit }j=\underset{\forall\,\text{bel}}{\text{maxarg}}\left\{ \text{TS}\left(T_\text{bel}\right) : \text{TS}\left(T_\text{bel}\right) < \text{TS}\left(T_i\right) \right\}</math>

geschrieben wurde.

Jedes Objekt P besitzt ebenso einen Lese-Zeitstempel RTS(P) (read timestamp), der den Startzeitstempel TS(T_neu) derjenigen Transaktion T_neu angibt, die P zuletzt gelesen hat. Wenn T_i dieses Objekt P ändert und TS(T_i) < RTS(P)=TS(T_neu) gilt, dann wird die Transaktion T_i abgebrochen und neu gestartet. Andernfalls erstellt T_i eine neue Version von P und setzt den Lese-Schreib-Zeitstempel von P auf TS(T_i).

MVCC ist klar abzugrenzen vom Isolationslevel Read Uncommitted, welches ebenfalls sicherstellt, dass lesende Zugriffe nie auf Schreibvorgänge warten müssen. Im Gegensatz zu Read Uncommitted gewährleistet MVCC jedoch immer eine konsistente Sicht auf die Daten. Die Verwendung von MVCC schließt das Isolationslevel Read Uncommitted somit grundsätzlich aus, da keine Dirty Reads mehr möglich sind.

Der Nachteil dieses Systems sind die Kosten, um viele verschiedene Versionen eines Objekts in der Datenbank zu halten. Auf der anderen Seite werden lesende Zugriffe nie blockiert, was sehr wichtig bei ausgelasteten Datenbanken sein kann, in denen sehr häufig nur gelesen wird.

Datenbanken mit MVCC

Viele der heute erhältlichen Datenbanksysteme implementieren diese Technik:

ArangoDB<ref>ArangoDB GmbH: Basics and Terminology · ArangoDB v3.2.9 Documentation. Archiviert vom Vorlage:IconExternal am 13. Dezember 2017; abgerufen am 9. Juli 2025 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)). </ref>
Berkeley DB<ref><templatestyles src="Webarchiv/styles.css" />Berkeley DB Reference Guide: Degrees of Isolation (Memento des Vorlage:IconExternal vom 27. Juni 2007 im Internet Archive) Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/oracle.com</ref>
CouchDB<ref>Eventual Consistency. Abgerufen am 9. Juli 2025. </ref>
CortexDB
Elasticsearch
Firebird (Datenbank)<ref>White paper by Roman Rokytskyy <templatestyles src="Webarchiv/styles.css" />Firebird and Multi Version Concurrency Control (Memento des Vorlage:IconExternal vom 9. Juni 2007 im Internet Archive) Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/firebirdsql.org</ref>
FLAIM
GraphDB (sones GmbH)<ref>sones/GraphDB at master · sones/sones. Abgerufen am 9. Juli 2025 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)). </ref>
H2 Database Engine (experimentell ab Version 1.0.57 (25. August 2007))<ref>Advanced. Abgerufen am 9. Juli 2025. </ref>
InterBase (alle Versionen)<ref name="IBMVCC">Bill Todd: InterBase: What Sets It Apart. 2000, archiviert vom Vorlage:IconExternal (nicht mehr online verfügbar) am 26. Februar 2006; abgerufen am 19. September 2020. Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/dbginc.com </ref>
Microsoft SQL Server (ab SQL Server 2005, allerdings verwenden ältere Versionen u. a. row-level-locking)
MySQL, wenn man die InnoDB<ref>MySQL 5.1 Reference Manual, Section 14.2.12: Implementation of Multi-Versioning</ref> oder Falcon<ref>MySQL 5.1 Reference Manual, @1@2Vorlage:Toter Link/mysql.orgSection 14.6.1: Falcon Features (Seite nicht mehr abrufbar, festgestellt im Mai 2019. Suche im Internet Archive (T))Vorlage:Toter Link/archivebot</ref> storage engine verwendet.
ObjectStore (nur im Lesemodus)<ref name="ObjectStoreMVCC">ObjectStore Advanced C++ User’s Guide, <templatestyles src="Webarchiv/styles.css" />chapter two (Memento des Vorlage:IconExternal vom 23. August 2007 im Internet Archive) Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/progress.com</ref>
Oracle<ref>Oracle Database Concepts, Chapter 9 Data Concurrency and Consistency docs.oracle.com Multiversion Read Consistency</ref>
OrientDB
PostgreSQL<ref>Concurrency Control. 7. Februar 2013, abgerufen am 9. Juli 2025 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)). </ref> und PostgreSQL Derivate wie Netezza
SAP HANA
Spanner (Google)
ThinkSQL
Zope Object Database

Siehe auch

Einzelnachweise