PostgreSQL - Aktuelle Entwicklungen

PostgreSQL ist ein objektrelationales Datenbankverwaltungssystem. Es unterstützt SQL92 und SQL99 und bietet viele moderne Fähigkeiten, wie komplexe Anfragen, Fremdschlüssel, Trigger, Sichten, transaktionale Integrität und Multiversionskontrolle. Außerdem ist PostgreSQL auf einzigartige Weise vom Benutzer erweiterbar, zum Beispiel mit Datentypen, Funktionen, Operatoren, Aggregatfunktionen, Indexmethoden oder prozeduralen Sprachen. Dieser Artikel gibt einen Überblick über die Neuerungen im Umfeld von PostgreSQL, stellt einige Features der aktuellen Release PostgreSQL 7.4 vor und gibt einen Ausblick auf zukünftige Entwicklungen. Außerdem wird noch etwas ausführlicher auf das Thema Replikation eingegangen.

Die nächste PostgreSQL-Release wird einen nativen Windows-Port haben. Dies ist eine der größten Portierungsprojekte in der Geschichte dieser Software. Zwar ist es schon seit 1998 möglich, PostgreSQL auf Windows einzusetzen, aber geschieht dies unter Verwendung des Toolkits Cygwin, welches verschiedene Probleme mit der Performance, Benutzerfreundlichkeit und Lizenz mit sich bringt. Für Entwicklung und Experimentierung ist der Cygwin-Port durchaus geeignet, für den Produktionseinsatz aber nicht zu empfehlen.

Bereits vor zwei Jahren wurden zwei unabhängige kommerzielle Windows-Portierungen unternommen, und zwar von den Firmen SRA und PeerDirect, welche den Code kurz darauf auch der Community zur Verfügung stellten. Für eine direkte Integration war der Code leider nicht geeignet, wodurch sich die eigentlich schon länger geplante offizielle Portierung mehrmals verschob. Die Community entwickelt auf Basis dieser existierenden Erfahrungen eine Windows-Portierung, die mit dem bisherigen Code verträglicher ist und den zukünftigen Wartungsaufwand reduzieren soll.

Wichtige Probleme bei der Erstellung des Ports waren:

Was ganz und gar abzuwarten ist, ist ob, wie von einigen gehofft, der Windows-Port die Verbreitung von PostgreSQL tatsächlich proportional zum Marktanteil dieses Betriebssystems erhöhen wird, oder ob, wie von anderen befürchtet, die Entwickler und Anwender in Zukunft mit Supportanfragen von unbedarften Windows-Anwendern überflutet werden. Sicherlich eröffnet der Windows-Port auf jeden Fall einen interessanten neuen Horizont für das PostgreSQL-Projekt.

Die kommende PostgreSQL-Release verwendet eine neue Cache-Replacement-Strategie ARC (Adaptive Replacement Cache) als Ersatz für die bisherige Strategie LRU (Least Recently Used). Im Gegensatz zu LRU betrachtet ARC nicht nur die Zeit des letzten Zugriffs sondern auch die Haufigkeit des Zugriffs und passt sich automatisch auf eine ideale Balance zwischen diesen beiden Faktoren an. Dadurch wird auch verhindert, dass ein sequenzieller Scan oder ein Vacuum-Prozess den Cache-Inhalt zerstört. Trotzdem hat der Algorithmus wie LRU eine lineare Komplexität und verlangt im Gegensatz zu den meisten anderen Strategien keine manuelle Feinabstimmung. Die Autoren des ARC-Algorithmus erwarten eine Steigerung der Cache-Treffer-Raten in alle Anwendungsfällen gegenüber LRU und Tests der PostgreSQL-Implementierung lassen auf ähnliche positive Ergebnisse schließen.

Das Tunen von fast gleichzeitigen Schreibzugriffen von verschiedenen Sitzungen hat schon zu abenteuerlich anmutenden Konfigurationsparametern in PostgreSQL geführt. Als hoffentlich endgültige Lösung dieses Problems wird es einen Hintergrundprozess geben, der schmutzige Seiten aus dem Cache in einem Durchgang schreibt. Das reduziert die Interprozesskommunikation der PostgreSQL-Prozesse und ermöglicht bessere Kooperation mit dem Kernel, dem PostgreSQL-Cache und dem verbesserten Vacuum. Diverse Fine-Tuning-Möglichkeiten werden auch hier gegeben sein.

Vacuum war lange Zeit eines der großen Problemthemen bei PostgreSQL. Seit Version 7.2 benötigt Vacuum allerdings keine Tabellensperren mehr und behindert daher auch die normale Datenbankaktivität nicht mehr. Verbesserungsmöglichkeiten ergeben sich vielmehr bei der Administration. Mittelfristiges Ziel ist es, Vacuum in einen mehr oder weniger automatisch nebenbei laufenden Garbage-Collection-Prozess umzuwandeln. Einen ersten Schritt in diese Richtung gab es in Version 7.4 mit dem Programm pg_autovacuum. Dieses Programm überwacht alle Tabellen in einem PostgreSQL-Server automatisch auf Schreibaktivitäten und löst nach einer voreingestellten Anzahl von Schreibzugriffen automatisch ein VACUUM und ein ANALYZE aus. Zur Zeit ist es ein normales Client-Programm welches im contrib-Verzeichnis des PostgreSQL-Source-Tree vertrieben wird. Aktuell wird es in den PostgreSQL-Server integriert, wo es noch bessere Konfigurations- und Analyse-Möglichkeiten haben wird und (noch) einfacher zu installieren sein wird. Allerdings ist der Einsatz auch heute schon äußerst empfehlenswert.

Darüber hinaus wird auch der Vacuum-Prozess selbst weiter optimiert. So wird man in der nächsten Release den Vacuum-Prozess “ drosseln ” können, das heißt er verzögert sich selbst, um den Durchsatz der normalen Datenbankaktivität weniger zu beeinträchtigen. Dies ist eine ziemlich einfache aber wirkungsvolle Optimierung. Zusammen mit dem neuen Background Writer und dem neuen ARC-Cache konnten die Antwortzeiten in einer TPC-C-Benchmark mit Vacuum-Dauerbetrieb um über 80% gesenkt werden.

Die kontinuierliche Verbesserung der Performance ist seit jeher eines der Hauptaspekte bei der Entwicklung von PostgreSQL. Neben einigen einschneidenden strukturellen Veränderungen (z.B. MVCC, WAL, Vacuum, Background Writer) handelt es sich dabei größtenteils um Detailarbeiten, bei denen durch Profilanalysen immer neue Schwachstellen entlarvt werden, welche nach der Beseitigung wiederum durch neue Kandidaten abgelöst werden. Dabei geht es zum Teil um algorithmische Verbesserungen, teilweise aber auch um compilernahe Optimierungen und Tricks, wie zum Beispiel das Alignment bestimmter Speicherstellen. Denn trotzdem das Datenbanksystem in der Regel I/O-bound ist, lässt sich nach wie vor viel CPU-Zeit einsparen.

Einige Beispiele aus PostgreSQL 7.4:

Einige Beispiele aus dem aktuellen Entwicklungsbranch:

Durch immer neue Entwicklungen im Datenbankserver, Änderungen in den Betriebssystemen und neue Hardware ist davon auszugehen, dass sich dieser Tuning-Prozess unbegrenzt fortsetzen wird. Allerdings führt dies auch zu einer stetig wachsenden Zahl an Tuning-Parametern, die sich mittlerweile nur noch schwierig überblicken lassen. Eine Herausforderung für die Zukunft wird es daher sein, dem Anwender bessere Werkzeuge in die Hand zu geben um diese Tuning-Parameter zu verwalten, oder noch bessere Optimierungsmethoden zu verwenden, die sich selbst tunen können.

Für PostgreSQL gibt es diverse Plugins, die es ermöglichen, benutzerdefinierte Funktionen in verschiedenen Programmiersprachen zu schreiben. Schon länger dabei sind PL/pgSQL, Tcl, Perl und Python; mittlerweile gibt es auch Plugins für Ruby, die Sprache R für statistische Berechnungen, und sogar einen Plugin für Shell-Skripte. Zur Zeit gibt es außerdem zwei Projekte, die an Plugins arbeiten, die das Schreiben von benutzerdefinierten Funktionen in Java ermöglichen werden.

PL/Java von Thomas Hallgren implementiert das bekannte Modell: der PostgreSQL-Prozess lädt den Interpreter der Sprache, in diesem Fall eine Java Virtual Machine, und führt darüber den Funktionscode aus, in diesem Fall über das Java Native Interface (JNI). Dadurch läuft der Java-Code im Serverprozess und hat direkten Zugriff auf die Strukturen des Servers. (Natürlich schützt der PL/Java-Plugin den Server vor zerstörerischen Zugriffen aus User-Code.) Unter anderem steht auch ein JDBC-Treiber zur Verfügung, mit dem man aus Java-Funktionen im Server Datenbankanfragen ausführen kann. Eine Beta-Version von PL/Java ist seit Anfang dieses Jahres verfügbar. Für die Zukunft geplant sind unter anderem die Möglichkeit, Java-Funktionen mit GCJ in Binärcode zu kompilieren und mit dem bekannten Mechanismus für C-Funktionen zu laden.

Das Projekt PL/J von Laszlo Hornyak geht einen anderen Weg: Funktionen werden über RPC auf einem speziell für diese Aufgabe laufenden Server ausgeführt. Dadurch muss nicht für jeden PostgreSQL-Serverprozess eine Java Virtual Machine gestartet werden, wodurch CPU-Zyklen und Hauptspeicher gespart werden können. Außerdem ist der PostgreSQL-Server dadurch besser gegen Abstürze der Java Virtual Machine geschützt. Theoretisch ist diese Methode sogar noch flexibler: man kann nicht nur Java mit PostgreSQL benutzen sondern möglicherweise auch andere Sprachen und andere Datenbanksysteme. Allerdings ergibt sich bei dieser Lösung natürlich ein erhöhter Kommunikationsaufwand und höhere Komplexität. PL/J ist zur Zeit noch in der Entwicklung.

Welcher dieser Ansätze sich durchsetzen wird ist zur Zeit noch völlig offen. Beide Projekte versuchen, den SQL/Java-Standard aus SQL 2003 zu befolgen, so dass eine gewisse Kompatibilität zu erwarten ist.

Mit geschachtelten Transaktionen ist es möglich, innerhalb einer Transaktion Subtransaktionen auszuführen. Damit kann man größere Aufgaben in kleinere Teilaufgaben zerlegen, die einzeln abgearbeitet werden können und dabei gegebenenfalls einzeln abgebrochen und wiederholt werden können. An geschachtelten Transaktionen für PostgreSQL wird zur Zeit gearbeitet. Ob das Feature für die nächste Release fertig wird ist zur Zeit nicht klar. Ein anspruchsvolleres Ziel von geschachtelten Transaktionen ist, dass die Subtransaktionen teilweise parallel ausgeführt werden können. Derartige Funktionalität ist zur Zeit noch nicht geplant.

Point-in-Time Recovery (PITR) bezieht sich auf die Fähigkeit des Datenbanksystems, beliebige Zustände in der Vergangenheit wiederherstellen zu können. Das wird normalerweise so implementiert, dass alle Datenbankaktivität in einem Log gespeichert wird, der dann sozusagen in umgekehrter Reihenfolge abgespielt werden kann um alle Aktivitäten bis zum gewünschten Punkt rückgängig zu machen. Es handelt sich dabei, um ein zweites, gröberes Sicherheitsnetz, neben der Möglichkeit unerwünschte aber noch nicht abgeschlossene Transaktionen zurückrollen zu können. Außerdem lassen sich so inkrementelle Backups realisieren.

Der PostgreSQL-Server pflegt sowieso schon einen Log aller Datenbankaktivität, nämlich den Write-Ahead Log (WAL), der für das Roll Forward (Redo) im Falle eines Absturzes gehalten wird. Dieser Log lässt sich auch für das von PITR benötigte Rollback (Undo) verwenden; entsprechende kleinere Anpassungen sind bereits getätigt worden. Die restliche Arbeit, um das Feature PITR abschließen zu können, besteht hauptsächlich in der Entwicklung von Administrationswerkzeugen zum Sichern und Wiedereinspielen des Logs. Viel Wert wird insbesondere darauf gelegt, eine möglichst allgemein gehaltene Schnittstelle anzubieten, in die auch externe Backup-Software eingebunden werden kann. Diese Arbeit ist zur Zeit im Gang und wird wahrscheinlich zur neuen Release abgeschlossen sein.

Replikation ist eines der meistdiskutiertesten Themen im Umfeld von PostgreSQL. Einerseits wird es von vielen Benutzern als eines der wichtigsten Features eines Datenbankmanagementsystems gesehen, andererseits kann die Entwicklergruppe bis heute keine abschließende Empfehlung und keinen definitiven Ausblick zu diesem Thema geben. In diesem Abschnitt werde ich erklären wie es zu dieser Situation gekommen ist und welche Lösungen dem Anwender heute zur Verfügung stehen.

Die nächste Release, welche wahrscheinlich PostgreSQL 7.5 heißen wird, wird später in diesem Jahr erwartet. Die Beta-Phase, in der keine neuen Features mehr hinzukommen, soll im Juni oder Juli starten; die endgültige Release kann dann etwa im September oder Oktober erwartet werden. Welche der zur Zeit in Entwicklung befindlichen Features in dieser Release enthalten sein werden ist noch offen; es kommt darauf an, wie schnell die diversen noch ausstehenden Probleme gelöst werden können. Die Erfahrungen der Vergangenheit haben gezeigt, dass es alles in allem besser ist, sich an feste Daten zu halten als unbegrenzt auf die Fertigstellung bestimmter Features zu warten. Wer aktuelle Informationen zu dem einen oder anderen Feature haben möchte, der sollte die Mailingliste pgsql-announce lesen, wo unter anderem wöchentliche Nachrichten aus der Entwicklung gepostet werden.

Hans-Jürgen Schönig für spontane und ausführliche Erläuterungen des einen oder anderen Features

Dave Cramer für seine Erklärungen bezügliches des Zustandes von PL/J und PL/Java

Bruce Momjian für diverse Zusammenfassungen, Webseiten und Vorträge mit vielen Erklärungen

Allen anderen die über die Jahre offen kommuniziert und gewissenhaft dokumentiert haben, damit man auch im Nachhinein noch darüber berichten kann