MVCC kann auf verschiedene Arten implementiert werden. Die einzige Voraussetzung ist, dass irgendwie ältere Zeilenversionen verfügbar sind.
Zum Beispiel speichert SQL Server sie in einer temporären Datenbank, die zurückgesetzt wird, wenn der Server neu gestartet wird.
Postgres speichert Zeilenversionen als versteckte Zeilen direkt im B-Baum. Es fügt dem Baum eine verborgene Schlüsselspalte hinzu. Beim Lesen vom Baum wird nur die Version angezeigt, die logisch gesehen werden sollte.
RavenDBs Voron verwaltet B-Tree-Seiten als unveränderbare Daten. Schriftsätze erzeugen völlig neue Bäume. MVCC wird daher als Lesen von dem korrekten unveränderlichen Baum implementiert.
Datenbanken sperren physische Strukturen selten für längere Zeit. Es ist keine gute Idee, den Datenbankclient zu aktivieren, um den Fortschritt für interne Datenbankstrukturen zu stoppen. Interne Strukturen sind normalerweise sehr kurz gesperrt. Logische Zeilensperren werden getrennt behandelt.
Wenn ich raten musste concurrency control on search structures bezieht sich auf physikalische Thread-Sicherheit. In der Regel ist MVCC nicht erforderlich, da mehrere Versionen nicht verwaltet werden müssen. Normale In-Memory-Sperren sind für kurze Zugriffe ausreichend.