MVCC
Motivation
Lesende Transaktionen sind sehr häufig und verändern die Daten nicht.
Schreibende Operationen sollen auf einer Kopie der Daten arbeiten, damit Transaktionen die nur lesen niemals warten müssen.
Um diese Kopien zu verwalten und nach Ende ihrer Verwendung wieder zu löschen ist eine Garbage-Collection notwendig.
Basiskonzept
Jede Transaktion erhält eine ID die als Zeitstempel verwendet wird. Jedes Datenobjekt speichert die ID der Transaktionen die es zuletzt gelesen oder geschrieben haben.
Ablauf
Bei Zugriffen werden mehrere Varianten der Datenobjekte gespeichert. Jeder Eintrag verweist auf die vorherige Version. So kann stets die aktuellste Version gefunden werden, die jede Transaktion lesen darf.
Lesen
Beim Lesenden Zugriff wird der neueste Wert bestimmt, der zum Zeitpunkt des Lesens verfügbar sein sollte. In den Metadaten wird der Eintragt für den letzten Zugriff ggf. angepasst.
Beim Schreiben wird unterschieden, ob die Anfragende Transaktion bereits den neuesten schreibenden Zugriff durchgeführt hat.
- Falls gilt, wird der Wert aktualisiert und gesetzt.
- Andernfalls wird eine neue Kopie angelegt, die Zeitstempel werden eingetragen und ein Verweis auf die nächstältere Version gesetzt.
Klausuraufgabe
Zugriffe eines gegebenen Schedules mit MVCC verwalten und Daten mit Metadaten korrekt fortsetzen
Optimistische Techniken
Ausführung von Transaktionen in drei Phasen
- Lesephase (Bezogen auf Datenbank)
Es wird eine lokale Kopie erstellt und entsprechend bearbeitet. - Validierungsphase
Prüft auf Kollisionen mit parallel ablaufenden Transaktionen. Löst Konflikte durch Zurücksetzen von Transaktionen. - Schreibphase
Nach einer erfolgreichen Validierung kann in die Datenbank geschrieben werden. Lesetransaktionen werden ohne Aufwand beendet.
Da Transaktionen bei Problemen abgebrochen werden, ist dieser Ansatz nur sinnvoll, wenn Konflikte zwischen Transaktionen nur selten sind.
Da wenig Aufwand während dem Bearbeiten von Transaktionen notwendig ist, kann so sehr performant gearbeitet werden. Deadlocks, Dirty Reads und Kaskadierende Rollbacks werden dabei vermieden.
Rückwärtsorientierte Validierung
Um eine Transaktion zu validieren wird geprüft, ob in allen Änderungen , die seit Beginn von validiert wurden, Objekte vorkommen, die auch in verwendet werden. Falls keine Objekte geteilt sind, kann geschrieben werden. Sonst muss Zurückgerollt werden.
Diese Unschärfe ist eine Schwäche des Verfahrens. Es kann nicht genau bestimmt werden, was gelesen oder geschrieben wurde. Somit ist es nicht möglich präzise Korrekturen durchzuführen.
Da eventuelle Rücksetzungen erst zum Ende der Transaktion stattfindet, werden viele Arbeitsschritte unnötigerweise ausgeführt.
Da nur die aktuell validierende Transaktion zurückgerollt werden kann, besteht die Gefahr des Verhungerns. Besonders bei großen Transaktionen ist diese Gefahr relevant.
Vorwärtsorientierte Validierung
Zum Validierungszeitpunkt wird geprüft, ob eine andere, aktuell laufende Transaktion einen Wert gelesen hat, den die prüfende Transaktion verändern möchte.
So lässt sich einige Arbeit vermeiden da Konflikte früher erkannt werden. Außerdem kann die ältere Transaktion bevorzugt werden um das Verhungern zu vermeiden.
Kombinationen
Es gibt verschiedene Möglichkeiten die Vorteile von Pessimistischen und Optimistischen Techniken zu kombinieren. So wird die Geschwindigkeit der optimistischen Verfahren mit der Erfolgsrate der Pessimistischen kombiniert. Grundsätzlich kann z.B. immer Optimistisch gearbeitet werden und nur bei sehr langen oder fehlgeschlagenen Transaktionen auf ein pessimistisches Modell gewechselt werden.
Auch ist eine Strategie denkbar, bei der Zugriffe auf ‘Hot-Spots’ pessimistisch gehandhabt werden, während Arbeit auf seltener verwendeten Daten optimistisch und schnell ist.