Gründe für PostgreSQL

In den letzten Jahren hat sich Open Source immer weiter in die große und bunte Businesswelt vorgewagt und ist mittlerweile für viele Firmen ein fester Bestandteil der IT-Landschaft geworden. In diesem Artikel wollen wir einige Argumente auflisten, die für PostgreSQL sprechen.

Wir werden immer wieder gefragt, welche Argumente besonders für PostgreSQL sprechen und welche Unterschiede zu MySQL besonders relevant sind. Ich habe die häufigsten Fragen zu einer kleinen Sammlung zusammen gestellt und sie unter dem Gesichtspunkt einer breiteren Betrachung beantwortet.

  1. PostgreSQL ist ein freies Community Projekt
    Viele Unternehmen haben mittlerweile erkannt, dass man mit “Open Source” durchaus erfolgreich sein kann. Deshalb ist das “Open Source Stellen” von Software zu einer sehr löblichen Mode geworden. Bei aller der Freude über “Open Source” darf man jedoch eine Kleinigkeit nicht vergessen: Open Source bedeutet im Wesentlichen nur, dass der Code einsehbar ist – mit einem Community Projekt hat das im herkömmlichen Sinne noch nicht viel zu tun. Viele Hersteller drücken Produkte unter dem Deckmantel “Open Source” in den Markt – sind jedoch meilenweit von echten Community Projekten entfernt. Sieht man sich beispielsweise den Source Code von “Ingres” an, wird man erkennen, dass der “Code” zu einem großen Teil aus nicht enden wollenden Copyright Anmerkungen besteht. Setzt man ein derartiges Produkt ein, hat man zwar Zugang zum Code – im Wesentlichen ist man jedoch wieder an ein einziges Unternehmen gebunden.Bei PostgreSQL ist das anders. PostgreSQL ist in keinster Weise von einem einzelnen Unternehmen kontrolliert. Das bedeutet, dass das Produkt keinen Marketingdoktrinen unterliegt und die Entwicklung keinem Kapitelgeber ausgeliefert ist. Die Entwicklung kann folglich nach rein technischen Gesichtspunkten erfolgen. Das impliziert auch, dass PostgreSQL nicht “pleite” gehen kann. In Zeiten von Firmenübernahmen ist das ein ganz wesentliches Argument für den Einsatz von PostgreSQL. Für den langfristigen Einsatz ist es sehr wichtig sicherstellen, dass man nicht einem einzigen Anbieter auf Gedeih und Verderb ausgeliefert ist. Sie haben also die Wahl, mit welchem Partner Sie zusammenarbeiten wollen, wenn Sie PostgreSQL einsetzen wollen. Für mich als PostgreSQL Consultant und Supporter ist meine eigene Ersetzbarkeit eines der stärksten Argumente.
  2. Kompromisslose Stabilität
    PostgreSQL setzt auf kompromisslose Stabilität. PostgreSQL ist problemlos in der Lage Stromausfälle und Systemausfälle wegzustecken, OHNE inkonsistent zu werden und OHNE Daten zu verlieren. Sind Daten erst einmal geschrieben, kann kein Datensatz verloren gehen.
    Das ist besonders — aber nicht nur — bei kritischen Datenbeständen von Bedeutung. Denn: Wer verliert schon gerne Daten?
  3. Stabile und langfristige Entwicklung
    Wie bereits im letzten Abschnitt kurz angedeutet, wird PostgreSQL nach rein technischen Gesichtspunkten entwickelt. Üblicherweise gibt es ein bis zwei große Releases pro Jahr. Der Release-Zyklus setzt sich auf einer Phase intensiver Entwicklung, dem “Feature Freeze” sowie einer ausgedehnten Beta-Phase zusammen.Während der Entwicklungsphase werden üblicherweise zahlreiche Patches gepostet und je nach Umfang und Güte entweder aufgenommen, auf die Warteliste gesetzt oder einfach wieder verworfen. Im nächsten Schritt folgt der so genannte “Feature Freeze”: In dieser Phase werden keine neuen Funktionalitäten mehr aufgenommen, sondern es wird nur mehr Bestehendes überarbeitet, verbessert, integriert, getestet und dokumentiert.

    Abschließend folgt eine Beta-Phase, die beendet wird, wenn über einen bestimmten Zeitraum hinweg keine Bugs mehr gefunden werden. Es folgt der offizielle Release. Sofern es nach dem Release Bugs gibt, werden entsprechende Service-Releases veröffentlicht. Dabei ist besonders wichtig zu bemerken, dass ein Service-Release niemals zusätzliche Funktionalität bietet. Das stellt sicher, dass Updates keine bestehenden Applikationen beeinträchtigen können. In diesem Punkt unterscheidet sich PostgreSQL grundlegend von so mancher “Enterprise”-Datenbank. Ich erinnere mich an einen konkreten Fall bei einem deutschen Kunden: Nach dem Update einer zentralen Datenbank von Version 15.0.1 auf 15.0.2 war eine Applikation auf einmal komplett von der Rolle und offerierte der staunenden Belegschaft Syntax Fehler. Nach intensiver — und teurer — Recherche musste man feststellen, dass sich die Parserlogik von 15.0.1 und 15.0.2 verändert hatte. Probleme dieser Art sind bei PostgreSQL undenkbar und ich kann mich an keinen Fall in meiner 8-jährigen PostgreSQL Karriere erinnern, wo ein derartiges Problem aufgetreten wäre.

  4. Restriktive Patchpolitik
    Entscheidet man sich, Patches für PostgreSQL zu schreiben, wird man sehr schnell erkennen, dass es durchaus schwierig ist, die PostgreSQL Community davon zu überzeugen, Code aufzunehmen. Das hat relativ einfache Gründe: Ist eine Funktionalität einmal aufgenommen, ist es de facto nicht mehr möglich, das entsprechende Feature zu entfernen: “If we accept that, we have to support it forever” — diesen Satz bekam ich einmal zu lesen. Bei jedem Patch stellt sich immer wieder die Frage: Rechtfertigt die zusätzliche Funktionalität die zusätzliche Komplexität? Sofern der Nutzen eines Features nicht groß genug ist, wird es einfach verworfen. Das mag zwar kurzfristig frustrierend sein – sorgt aber langfristig dafür, dass der Code sauber und vor allem wartbar bleibt.Betrachtet man das Ganze aus der Sicht des professionellen Anwenders ergeben sich einige Vorteile: Stellt eine aktuelle Version von PostgreSQL eine gewisse Funktionalität zur Verfügung, kann man sich darauf verlassen, dass diese auch in Zukunft erhalten bleibt. Das stellt sicher, dass Ihr Investment auf Jahre gesichert ist. Viele Benutzer diverser Office Produkte erinnern sich vielleicht noch voller Schmerzen an selbstgeschriebene Makros, die es zu migrieren galt – diese Probleme bleiben Ihnen bei PostgreSQL erspart.
  5. Für große und kleine Datenmengen
    PostgreSQL wurde von Beginn an für große Datenmengen konzipiert. Die Grundidee ist sehr einfach: Funktioniert ein System für große Anwendungen, wird es für kleine Anwendungen erst recht funktionieren. Andere Hersteller gehen einen anderen Weg: Optimiert man für kleine, schnelle Anwendungen, bedeutet das nicht zwingend, dass das System auch bei großen Datenmengen funktioniert.Das Fassungsvermögen einer PostgreSQL Datenbank ist gewaltig: Pro Tabelle können bis zu 128 Terabyte gespeichert werden (bei 32 kb Blocksize). Die Anzahl der Tabellen ist de facto unlimitiert. Die Kapazität einer PostgreSQL Datenbank überschreitet die Leistungsfähigkeit modernster Hardware somit um einige Zehnerpotenzen.

    Auch die Größe einzelner Datensätze ist gewaltig: Ein einzelner Datensatz innerhalb einer Tabelle kann bis zu 1.6 Terabyte groß sein. Eine Tabelle kann bis zu 1600 Spalten enthalten. Versucht man mehr als 1600 Spalten in eine Tabelle zu packen, sollte man eher daran gehen, das Datenmodell zu überdenken.

  6. Hohe Skalierbarkeit
    Die Möglichkeit viele Daten zu speichern, sagt jedoch noch nicht viel über die Güte einer Datenbank aus. Neben dem reinen Fassungsvermögen ist vor allem das Verhalten unter großer Last von Bedeutung. Die PostgreSQL Community legt größten Wert auf die Möglichkeit, so viele Anfragen wie möglich gleichzeitig zu beantworten. Wir haben in den letzten Jahren Datenbanken gesehen, die Connectionpools mit 6.000 – 10.000 gleichzeitig offene Datenbankverbindungen bedient haben. Bei keiner dieser Anwendungen hat sich die Architektur von PostgreSQL jemals als Bottleneck erwiesen.Um unter hoher Last gut skalieren zu können, bedarf es guter interner Mechanismen. Speziell das Locking ist von zentraler Bedeutung: Viele kommerzielle Datenbanken implementieren lediglich einfache Locking Mechanismen. PostgreSQL stellt 8 Ebenen von Locks zur Verfügung, die es ermöglich, sehr fein festzulegen, wie eine Zeile gesperrt werden soll (Im Vergleich: Sybase bietet ledliglich 2 Arten von Locks, die man nutzen kann, um eine Zeile zu sperren).
  7. Ausgefeilte Security Konzepte
    Wenn man ein relationales Datenbanksystem professionell betreiben möchte, kommt man kaum daran vorbei, sich mit Security und Benutzerrechten auseinander zu setzen. PostgreSQL bietet sehr einfache aber mächtige Mechanismen, um Benutzer entsprechend mit Privilegien auszustatten. Trotz der vielseitigen Möglichkeiten hat das Entwicklungsteam keineswegs auf die einfache Handhabung vergessen.Betreibt man eine unkritische Datenbankanwendung, hat PostgreSQL den Vorteil, dass sich das Rechtesystem nicht wie bei vielen anderen Datenbanksystemen zu sehr in den Vordergrund drängt. Wenn man im Begriffe ist, ein System zu installieren, ist es nicht unbedingt notwendig, Benutzerrechte zu definieren – es ist mit wenigen Handgriffen möglich, ein produktives System aufzusetzen, ohne sich mit Berechtigungen quälen zu müssen. Das verringert den administrativen Aufwand — man wird also keineswegs zwangsbeglückt.
  8. Einfache Erweiterbarkeit
    Oft zeichnen sich große, geschäftskritische Systeme nicht nur dadurch aus, dass große Datenmengen zu verwalten sind. In vielen Fällen wirft die Komplexität einer Anwendung viel schwerwiegendere Fragen auf als die schiere Datenmenge. Flexibilität und Erweiterbarkeit sind bei vielen Unternehmen eine zentrale Angelegenheit und entscheiden oft über die Einsatzfähigkeit einer Softwarelösung.PostgreSQL verfolgt einen modularen Einsatz und bietet dem Benutzer die Möglichkeit, sehr schnell Erweiterungen zu implementieren.

    Die einfachste Form ist die Verwendung von Stored Procedures: Im Prinzip ist es möglich, Stored Procedures in jeder beliebigen Programmiersprache zu schreiben. In der Regel wird man sich auf PL/pgSQL (das ist die von den meisten Benutzern verwendete Sprache) beschränken – prinzipiell ist es jedoch möglich, bestehende Business Logik direkt im Server auszuführen.Stored Procedures reichen jedoch oft nicht aus, um eine komplexe Anwendung abzubilden. Um diesem Umstand Rechnung zu tragen, besteht sogar die Möglichkeit, eigene Operatoren und Datentypen zu definieren. Das ist vor allem für Spezialanwendungen von großer Bedeutung. Sofern auch das nicht reicht, kann man sich für den Notfall auch mal schnell eine eigene Programmiersprache entwerfen oder sich ein eigenes Character Set bauen. Die Idee mit der eigenen Programmiersprache mag auf den ersten Blick durchaus etwas sonderbar klingen – in der Praxis tun sich dadurch jedoch unzählige Möglichkeiten auf: Skype hat sich beispielsweise eine kleine serverseitige Programmiersprache gebastelt, die dem Unternehmen hilft, Datenbankabfragen effizient und einfach auf verschiedenste Rechner zu verteilen (siehe “PL/Proxy”). Vergleicht man die Kosten und die Flexibilität dieses Ansatzes mit “herkömmlichen” Techniken zur Skalierung einer Anwendung, wird man sehr schnell erkennen, wie gut PostgreSQL in der Lage ist, die Anforderung eines Unternehmens zu meistern.