Pufferpool
Der Pufferpool ist der Pufferspeicher eines Datenbankmanagementsystems (DBMS). Häufig verwendete Teile einer Datenbank werden im Arbeitsspeicher zwischengelagert. Dadurch kann die Anzahl von Zugriffen auf die Festplatte und damit die dafür benötigte Zeit reduziert werden.
Konzept des Pufferpools
Der Pufferpool ist ein Cache, der Teile einer Datenbank im Arbeitsspeicher zwischenlagert. Dabei werden die Lokalitätseigenschaften der Prozesse ausgenutzt, welche auf die Datenbank zugreifen. Die Geschwindigkeit kann so gegenüber dem direkten Festplattenzugriff deutlich gesteigert werden.
Funktionsweise
Ein DBMS verwaltet die Informationen der Datenbank in Dateneinheiten fester Größe. Diese werden als Seiten oder Pages bezeichnet. In einer Seite könnten z. B. mehrere Zeilen einer Tabelle enthalten sein. Auf dem Festspeicher werden Daten blockweise gespeichert. Die Größe einer Seite ist meist ein Vielfaches der Größe eines Datenblockes der Festplatte.
Die Verdrängungsstrategie entscheidet, welche Seite im Pufferpool ersetzt wird, falls eine Seite von der Festplatte in den Pufferpool geladen werden soll. In der Regel kommt LRU (Least Recently Used) zum Einsatz.
Anforderungen an den Pufferpool
Die vier ACID-Eigenschaften definieren die Anforderungen an Transaktionen. Insbesondere die beiden Eigenschaften Atomarität und Dauerhaftigkeit haben Auswirkungen auf den Pufferpool. Die Isolation ist nicht Aufgabe des Pufferpools. Diese muss über Locking-Algorithmen erreicht werden.
Bei dem Betrieb eines DBMS können viele Probleme auftreten, welche dazu führen, dass der Arbeitsspeicher verlorengeht. So zum Beispiel Ausfälle der Stromversorgung, defekte Computerkomponenten, Softwarefehler etc. Geht der Arbeitsspeicher verloren, so verliert man den Pufferpool und insbesondere all jene Seiten, welche verändert, aber noch nicht zurück auf die Festplatte geschrieben wurden.
Gehörten diese Daten zu einer erfolgreich beendeten Transaktion, ist die ACID-Anforderung der Dauerhaftigkeit nicht erfüllt. Außerdem darf dabei die ACID-Eigenschaft der Atomarität nicht verletzt werden. Die Änderungen an der Datenbank von Transaktionen, welche zum Zeitpunkt des Ausfalls nicht erfolgreich abgeschlossen waren, müssen vollständig rückgängig gemacht werden können.
Verschiedene Pufferpool-Umsetzungen[1]
Die Art, wie ein Pufferpool implementiert wird, kann sich von DBMS zu DBMS stark unterscheiden. Für einige Methoden und Strategien werden im Zusammenhang mit dem Pufferpool spezielle Begriffe eingesetzt.
Force/No-Force
Die Force-Methode ist eine einfache Methode, um die Dauerhaftigkeit von Transaktionen zu gewährleisten. Dazu werden am Ende einer Transaktion (während des commit-Prozesses) alle Seiten, welche während der Transaktion verändert wurden, auf die Festplatte geschrieben. Die Verwendung der Force-Methode führt somit dazu, dass für jede verändernde Transaktion (relativ langsame) Schreiboperationen notwendig sind.
Entsprechend gibt es die No-Force-Methode. Dabei brauchen am Ende einer Transaktion keine Seiten auf die Festplatte geschrieben zu werden. Verändern mehrere Transaktionen dieselbe Seite, so braucht diese nicht jedes Mal gespeichert zu werden. Die Leistung des DBMS kann somit erhöht werden. Allerdings bietet No-Force keine garantierte Dauerhaftigkeit; diese muss anderweitig sichergestellt werden.
Steal / No-Steal
Mit der No-Steal-Methode kann auf einfache Weise die Atomarität der Transaktionen gewährleistet werden. Solange die Transaktion noch aktiv ist, werden die veränderten Seiten der Transaktion nicht auf die Festplatte übertragen. Alle Veränderungen geschehen ausschließlich im Pufferpool. Bei einem Ausfall geht der Pufferpool verloren und die Veränderungen aller laufenden Transaktionen mit ihm. Dies kommt einem Rollback dieser Transaktionen gleich. Auf der Festplatte befinden sich somit nur Seiten vollständiger Transaktionen. Die Atomarität ist somit gewährleistet.
Die No-Steal-Methode hat den Nachteil, dass viele Seiten im Pufferpool blockiert sind. Denn wenn die Änderungen nicht auf die Festplatte übertragen werden dürfen, kann die Seite auch nicht aus dem Pufferpool entfernt werden, um einer anderen Seite Platz zu machen. Der Platz im Pufferpool kann dadurch schnell an seine Grenzen kommen. Die Menge der Daten, welche in einer Transaktion verändert werden kann, ist durch die Größe des Pufferpools beschränkt.
Die meisten Veränderungen müssen aber später sowieso in den Sekundärspeicher geschrieben werden, da Abbrüche von Transaktionen die Ausnahme darstellen. Diese Seiten im Pufferpool zu halten, ist deshalb meistens unnötig. Entsprechend erlaubt die Steal-Methode, Seiten laufender Transaktionen auf die Festplatte zu schreiben. Man stiehlt einer laufenden Transaktion sozusagen einen Platz im Pufferpool. Der Pufferpool kann dadurch effizienter genutzt werden. Die Atomarität ist aber nicht mehr gewährleistet und muss anders umgesetzt werden.
Kombinationen
In der Praxis wird meist die Kombinationen Force und No-Steal oder No-Force und Steal verwendet. Force und No-Steal ist einfach umzusetzen, erreicht aber nicht die Leistung von No-Force und Steal. Insbesondere können bei Force und No-Steal keine zwei Transaktionen auf derselben Seite im Pufferpool arbeiten. Bei den großen DBMS Systemen wird aus diesem Grund meist No-Force und Steal verwendet, auch wenn dieses aufwendiger in der Entwicklung ist. Ein bekannter Algorithmus um die ACID-Eigenschaften trotz No-Force und Steal zu erhalten ist ARIES (Algorithms for Recovery and Isolation Exploiting Semantics). Dieser basiert auf einem Protokoll, welches sowohl das Wiederherstellen als auch das Rückgängigmachen von Veränderungen ermöglicht, um nach einem Ausfall wieder einen den ACID-Eigenschaften entsprechenden Stand zu erhalten.
Konfiguration
Die meisten DBMS bieten Möglichkeiten, den Pufferpool auf die eigenen Bedürfnisse anzupassen. Der wichtigste Parameter ist die Größe des Pufferpools. Je mehr Seiten er aufnehmen kann, desto schneller kann mit der Datenbank gearbeitet werden, allerdings steigt auch der Bedarf an Arbeitsspeicher.
Bei einigen DBMS können auch die Methoden zur Erhaltung der ACID-Eigenschaften manipuliert werden. Insbesondere Systeme, welche die No-Force- und Steal-Methoden verwenden, bieten meistens eine Möglichkeit an, um eine Datensicherung im laufenden Betrieb zu ermöglichen. Dabei werden die ACID-Eigenschaften auch erhalten, wenn vom Festspeicher eine Kopie erstellt wird, während das DBMS läuft. Dies wird als Hot-Backup bezeichnet.
Einzelnachweise
- Theo Härder und Erhard Rahm: Datenbanksysteme, Konzepte und Techniken der Implementierung, 2. Auflage (2001)