Mehrversionsparallelitätskontrolle (MCC oder MVCC), im Datenbankfeld der Informatik, ist eine durch Datenbankverwaltungssysteme allgemein verwendete Parallelitätskontrollmethode, um gleichzeitigen Zugang zur Datenbank und auf Programmiersprachen zur Verfügung zu stellen, um transactional Gedächtnis durchzuführen.

Zum Beispiel wird eine Datenbank Aktualisierungen nicht durch das Löschen eines alten Stückes von Daten und das Überschreiben davon mit einem neuen, aber stattdessen durch die Markierung der alten Daten als veraltet und das Hinzufügen der neueren Version durchführen. So gibt es vielfache versorgte Versionen, aber nur ein sind letzt. Das erlaubt der Datenbank, oben zu vermeiden, Löcher im Gedächtnis oder den Plattenstrukturen auszufüllen, aber verlangt (allgemein), dass das System durch regelmäßig kehrt und die alten, veralteten Datengegenstände löscht. Für eine dokumentenorientierte Datenbank wie CouchDB erlaubt es auch dem System, Dokumente durch das Schreiben kompletter Dokumente auf aneinander grenzende Abteilungen der Platte — wenn aktualisiert, zu optimieren, das komplette Dokument kann aber nicht Bit umgeschrieben werden, und Stücke ausgeschnitten oder haben in einer verbundenen, aneinander nichtgrenzenden Datenbankstruktur aufrechterhalten.

MVCC stellt auch potenziellem Punkt rechtzeitig konsequente Ansichten zur Verfügung. Lesen Sie tatsächlich Transaktionen unter MVCC normalerweise verwenden einen Zeitstempel oder Transaktionspersonalausweis, um zu bestimmen, welcher Staat des DB zu lesen, und diese Versionen der Daten las. Das vermeidet, Schlösser für gelesene Transaktionen zu führen, weil schreibt, kann auf Grund von den alten Versionen isoliert werden, die, aber nicht durch einen Prozess von Schlössern oder mutexes aufrechterhalten werden. Schreibt betreffen zukünftige Version, aber am Transaktionspersonalausweis, an dem das gelesene arbeitet, wie man versichert, entspricht alles, weil das Schreiben an einem späteren Transaktionspersonalausweis vorkommt.

Mit anderen Worten stellt MVCC jedem Benutzer zur Verfügung, der mit der Datenbank mit einem Schnellschuss der Datenbank für diese Person verbunden ist, um damit zu arbeiten. Irgendwelche Änderungen haben Testament nicht gemacht, von anderen Benutzern der Datenbank gesehen werden, bis die Transaktion begangen worden ist.

Durchführung

MVCC verwendet Zeitstempel oder zunehmende Transaktionspersonalausweise, um transactional Konsistenz zu erreichen. MVCC stellt sicher, dass eine Transaktion nie auf einen Datenbankgegenstand durch das Aufrechterhalten mehrerer Versionen eines Gegenstands warten muss. Jede Version würde einen schreiben Zeitstempel haben, und sie würde eine Transaktion (T) lassen liest die neuste Version eines Gegenstands, der dem Transaktionszeitstempel (TS (T)) vorangeht.

Wenn eine Transaktion (T) einem Gegenstand schreiben will, und wenn es eine andere Transaktion (T) gibt, muss der Zeitstempel von T dem Zeitstempel von T vorangehen (d. h., TS (T))) für den Gegenstand schreiben Operation, um erfolgreich zu sein. Der sagen soll, dass ein Schreiben nicht vollenden kann, wenn es hervorragende Transaktionen mit einem früheren Zeitstempel gibt.

Jeder Gegenstand würde auch einen gelesenen Zeitstempel haben, und wenn eine Transaktion T hat schreiben wollen, um P einzuwenden, und der Zeitstempel dieser Transaktion früher ist als der gelesene Zeitstempel des Gegenstands (TS (T), wird abgebrochen und wiederangefangen. Sonst schafft T eine neue Version von P und setzt die Lesen/Schreiben-Zeitstempel von P zum Zeitstempel der Transaktion TS (T).

Der offensichtliche Nachteil zu diesem System ist die Kosten, vielfache Versionen von Gegenständen in der Datenbank zu versorgen. Andererseits liest werden nie blockiert, der für Arbeitspensen wichtig sein kann, die größtenteils mit lesenden Werten von der Datenbank verbunden sind. MVCC ist im Einführen wahrer Schnellschuss-Isolierung, etwas besonders geschickt, was andere Methoden der Parallelitätskontrolle oft entweder unvollständig oder mit hohen Leistungskosten tun.

Beispiel

In der Zeit = "t1" konnte der Staat einer Datenbank sein:

Das zeigt an, dass der aktuelle Satz dieser Datenbank (vielleicht eine Schlüsselwert-Lager-Datenbank) Gegenstand 1 = "Hallo", Gegenstand 2 = "Bar" ist. Vorher war Gegenstand 1 "Foo", aber dieser Wert ist ersetzt worden. Es wird nicht gelöscht, weil die Datenbank vielfache Versionen hält, aber es wird später gelöscht.

Wenn eine lange laufende Transaktion eine gelesene Operation anfängt, wird sie an der Transaktion "t1" funktionieren und diesen Staat sehen. Wenn es eine gleichzeitige Aktualisierung gibt (während der gelesene Langzeittransaktion), der Gegenstand 2 löscht und Gegenstand 3 = "Foo-Bar" hinzufügt, wird der Datenbankstaat ähnlich sein:

Jetzt gibt es eine neue Version bezüglich des Transaktionspersonalausweises "t2". Bemerken Sie kritisch, dass die gelesene Langzeittransaktion noch Zugang zu einem zusammenhängenden Schnellschuss des Systems an "t1" hat, wenn auch die schreiben Transaktion Daten bezüglich "t2" hinzugefügt hat, so ist die gelesene Transaktion im Stande, in der Isolierung von der Aktualisierungstransaktion zu laufen, die die "T2"-Werte geschaffen hat. Das ist, wie MVCC isoliert erlaubt, liest SÄURE ohne irgendwelche Schlösser. (Bemerken Sie jedoch, dass die schreiben Transaktion wirklich Schlösser verwenden muss.)

Geschichte

Mehrversionsparallelitätskontrolle wird in einem Detail in der 1981 "Papierparallelitätskontrolle in Verteilten Datenbanksystemen" von Philip Bernstein und Nathan Goodman beschrieben, der dann von Computer Corporation Amerikas angestellt ist. Bernstein und das Papier von Goodman zitieren eine 1978-Doktorarbeit durch David P. Reed, der ganz klar MVCC beschreibt und es als eine ursprüngliche Arbeit fordert.

Datenbanken mit MVCC

• Altibase
• DB von Berkeley
• Bigdata
• CouchDB
• IBM DB2 - seit IBM DB2 9.7 LUW ("Cobra") unter dem CS Isolierungsniveau - in der zurzeit begangenen Weise
• IBM Cognos TM1 - in Versionen 9.5.2 und.
• Sprühregen
• eXtremeDB
• Baltimore-Trupial
• FLAIM
• Version von GE Smallworld geführter Datenladen
• H2 Datenbankmotor - experimentell seit der Version 1.0.57 (2007-08-25)
• MDB
• Hawtdb
• HSQLDB - mit der Version 2.0 anfangend
• Ingres
• InterBase - alle Versionen
• Server von MarkLogic

• Meronymy SPARQL Datenbankserver
• Microsoft SQL Server - mit dem SQL Server 2005 anfangend
• MySQL, wenn verwendet, mit InnoDB, Falken oder Archiv-Lagerungsmotoren.
• Netezza
• ObjectStore
• Orakel-Datenbank - alle Versionen seit dem Orakel 3
• OrientDB
• PostgreSQL
• Rdb/ELN
• RDM eingebetteter
• ECHTER Server
• ScimoreDB
• sones GraphDB
• Sybase SQL überall
• Sybase IQ
• ThinkSQL
• Zope Gegenstand-Datenbank

Andere Software mit MVCC

• JBoss Geheimes Lager - v 3.0
• Infinispan
• EHcache - v 1.6.0-beta4
• Clojure - Sprachsoftware transactional Gedächtnis
• Umsturz - und viele andere Quelle codiert Behältnisse
• pojo-mvcc - eine MVCC Leichtgewichtsdurchführung, die in Java geschrieben ist

Siehe auch

• Zeitstempel-basierte Parallelitätskontrolle
• Clojure
• Read-Copy-Update
• Vektor-Uhr

Weiterführende Literatur

• Gerhard Weikum, Gottfried Vossen, Informationssysteme von Transactional: Theorie, Algorithmen, und die Praxis der Parallelitätskontrolle und Wiederherstellung, Morgan Kaufmann, 2002, internationale Standardbuchnummer 1-55860-508-8