Über unsMediaKontaktImpressum
Dirk Krautschick 18. Mai 2021

Beyond PostgreSQL – Einblicke in die Erweiterbarkeit von PostgreSQL

Zu den bekannten Eigenschaften von PostgreSQL gehört es, eine schlanke und modulare Datenbank zu sein. In einer Zeit, in der DevOps, Virtualisierung und Containerplattformen immer wichtigere Themen sind, ist dies ein ausschlaggebender Faktor bei der Wahl von Software-Plattformen. Um dies nachhaltig sicherzustellen, kann PostgreSQL über weitere Software-Bausteine oder einer eingebauten Erweiterungsschnittstelle mit zusätzlichen Funktionen ergänzt werden. Dieser Ansatz wird aber gerade in den Kreisen von IT-Entscheider:innen kontrovers diskutiert und führt leider zu Entscheidungen gegen den Einsatz von PostgreSQL als alternativem Datenbanksystem.

Dieser Artikel ist der Start einer 5-teiligen Serie. Er fördert ein Verständnis über die Philosophie und das Konzept der Erweiterbarkeit von PostgreSQL. In den weiteren Serienteilen wird jeweils auf Empfehlungen für Extensions und Tools näher eingegangen. Dies soll Anreize und Inspiration bieten und damit zu besseren Entscheidungsfindungen beitragen.

Aspekte der Erweiterbarkeit

Grundsätzlich beherrscht PostgreSQL ohne installierte Erweiterungen (Extensions) selbstverständlich vieles, was von einem modernen relationalen Datenbankmanagementsystem erwartet wird. Dies gilt sowohl für die Community-Versionen als auch für die kommerziellen Varianten. Es wird bewusst auf eine Überfrachtung mit Features und Tools verzichtet.

Der Vorteil wird bereits bei den ersten Schritten sichtbar. Eine frische PostgreSQL-Installation ist mit einer Standard-Datenbank wesentlich platzsparender als bei anderen Datenbanken, wie z. B. Oracle oder MySQL (s. Tabelle 1).

Tabelle 1: Vergleich vom Storage-Bedarf von Software und Default-Datenbank unter Linux

RDBMSSoftwareDefault-Datenbank
Oracle 19.710 GB6,1 GB
MySQL 8.0182 MB173 MB
MariaDB 10.3122 MB122 MB
MS SQL Server 20191,1 GB90 MB
PostgreSQL 13.229 MB43 MB

Zu Beginn wird ein Datenbankadministrator beim Einsatz von PostgreSQL in der Regel keine Features vermissen. Grundlegend stellt diese eher konservativen Philosophie der PostgreSQL-Entwickler:innen somit erstmal kein Nachteil dar. Erst bei speziellen Anwendungsfällen oder besonders im Administrationsalltag stößt die Datenbanklösung an ihre Grenzen und der Aufschrei nach Lösungen wird laut.

Der alltägliche Einsatz von PostgreSQL lebt daher von einer gewissen Erweiterbarkeit. In erster Linie wird dies von einer eingebauten Extension-Schnittstelle gelöst. Hier werden über zusätzliche Module datenbankinterne Funktionen ermöglicht. Dabei kann es sich im einfachsten Fall um die Ergänzung in Form von SQL-Skripten, Datentypen oder erweiterten Views handeln. Die funktionale Ausprägung geht aber noch deutlich weiter und so können genauso komplexere Features hinzugefügt werden, die grundlegende Funktionalitäten ergänzen oder verändern.

Mit der PostGIS-Erweiterung für die Unterstützung von Spatial- und Geodaten innerhalb der Datenbanken hat man ein gutes Beispiel, wie umfangreich eine Erweiterung sein kann und wie ein komplettes Set an fachlicher Funktionalität hinzugefügt werden kann. Zudem ist die PostGIS-Erweiterung durchaus konkurrenzfähig zu kommerziellen Alternativen.

In der Praxis ergänzt auch noch eine große Auswahl zusätzlicher und teilweise unabhängiger Softwaretools die Möglichkeiten, die PostgreSQL bei Themen wie z. B. Betrieb, Monitoring und Verwaltung bietet.

Ein weiterer Vorteil der Extensions ist natürlich die Möglichkeit, eigene Entwicklungen und Ideen einfließen zu lassen. Da hier das Open-Source-Mindset eine starke Rolle spielt, können viele Inspirationen und eigene Ideen umgesetzt werden. Es existiert eine einheitliche Vorgabe, die dabei hilft, mit überschaubarem Aufwand Module oder Funktionen zusammenzufassen und als Extension zu verpacken.

Installation der Extensions

Die Installation von Extensions läuft ähnlich, wie auch bei anderen Software-Produkten oder -Bibliotheken. Die jeweiligen Pakete können entweder manuell oder auch über verfügbare Repositorys installiert werden. Hier kann es eventuell Abhängigkeiten geben, die entsprechend berücksichtigt werden müssen. Sollte ein Repository oder ein entsprechendes Paket nicht vorhanden sein, kann in nahezu allen Fällen der Quellcode der Extension heruntergeladen und selbst kompiliert werden.

Was die Verfügbarkeit von Extensions und der Installations-Optionen an geht, so ist es mit Linux leichter als bei der Verwendung von Windows. Bei Windows muss in der Regel selbst kompiliert werden oder man nutzt zum Beispiel die Möglichkeiten vom Stack Builder der Firma EnterpriseDB, der mit den Windows-Installationspaketen von PostgreSQL mitgeliefert wird. Hierbei handelt es sich um einen grafischen Paketmanager, der unter anderem auch Erweiterungen bereitstellt.

Mit dem offiziell von der PostgreSQL-Community verwalteten postgresql-contrib-Paket wird eine grundlegende Auswahl an häufig verwendeten Erweiterungen zur Verfügung gestellt. Die Suche nach Erweiterungen sollte hier angesetzt werden und gerade bei den ersten Schritten finden sich hier viele Möglichkeiten, um bereits einige Anwendungsfälle abzubilden.

Wird bei den Recherchen oder im contrib-Paket nicht die passende Erweiterung gefunden, so empfiehlt sich als nächster Schritt ein Blick in das offizielle PostgreSQL-eXtension-Network, die zentrale Plattform für die Verwaltung von Extensions für Entwickler:innen [1]. Zurzeit sind dort weit über 300 Extensions gelistet und gepflegt.

Die hier verfügbaren Extensions können auch direkt über einen eigenen Client gesucht und installiert werden. Diese pgxnclient kann man entweder direkt über ein Repository oder über den Python-Paketmanager installieren (s. Listing 1).

Listing 1: Installation PGXN Client unter Linux, Beispiel CentOs 8

# sudo pip3 install pgxnclient
 
   oder
 
# sudo dnf install -y pgxnclient.x86_64
…
# pgxn --version
pgxnclient 1.3
# pgxn --help
usage: pgxnclient [--version] [--help] COMMAND ...
 
Interact with the PostgreSQL Extension Network (PGXN).
 
optional arguments:
  --version  print the version number and exit
  --help     show this help message and exit
 
available commands:
  COMMAND    the command to execute. The complete list is available using
             `pgxn help --all`. Builtin commands are:
    check    run a distribution's test
    download
             download a distribution from the network
    help     display help and other program information
    info     print information about a distribution
    install  download, build and install a distribution
    load     load a distribution's extensions into a database
    mirror   return information about the available mirrors
    search   search in the available extensions
    uninstall
             remove a distribution from the system
    unload   unload a distribution's extensions from a database

Sind Extensions installiert, kann sich ein:e an der Datenbank angemeldete:r Nutzer:in mit der View pg_available_extensions einen Überblick verschaffen, welche Extensions in welcher Version verfügbar und somit für die Datenbanken aktivierbar sind (s. Listing 2):

Listing 2 : Anzeige von verfügbaren Extensions

[local]:5432 postgres@postgres=# select * from pg_available_extensions;
 
      name      | default_version   | installed_version |           comment
----------------+-------------------+-------------------+--------------------------------
plpgsql         | 1.0               | 1.0               | PL/pgSQL procedural language
adminpack       | 2.1               |                   | administrative functions for PostgreSQL
…
pg_qualstats    | 2.0.2             |                   | An extension collecting statistics…
powa            | 4.1.2             |                   | PostgreSQL Workload Analyser-core
(55 rows)

Wenn nicht anders angegeben, sind die relevanten Dateien der jeweiligen Extension im Software-Verzeichnis von PostgreSQL im Unterordner ./share/extension abgelegt. Dort werden die Extensions jeweils anhand eines Control-Files für die grundlegenden Informationen der jeweiligen Extension und den dazu gehörigen SQL-Skripten erkannt (s. Listing 3):

Listing 3 : Extensions Ordner und Dateien

postgres@localhost /usr/pgsql-13 ]# tree
.
├── bin
├── doc
├── include
├── lib
└── share
    ├── contrib
    ├── extension
    │   ├── pg_stat_statements--1.4.sql
    │   ├── pg_stat_statements.control
    │   ├── pg_wait_sampling--1.1.sql
    │   ├── pg_wait_sampling.control
    │   ├── plpgsql--1.0.sql
    │   ├── plpgsql.control
    │   ├── postgres_fdw--1.0.sql
    │   ├── postgres_fdw.control
    ├── information_schema.sql
    ├── locale
    ├── man
    ├── timezonesets
    └── tsearch_data

Verwaltung von Extensions

Die Aktivierung einer Extension ist denkbar einfach. Wichtig ist, dass die Extension jeweils pro Datenbank bzw. pro Template aktiviert werden muss. Letzteres bietet eine praktische Möglichkeit, bestimmte Datenbank-Templates mit einer Auswahl an Extensions zu bestücken und daraus dann die jeweiligen Datenbanken zu generieren.

Auf einer verbundenen Datenbank kann mit CREATE EXTENSION <extension_name>; die gewünschte installierte Extension aktiviert werden. Hierfür ist in den meisten Fällen die Superuser-Rolle notwendig. Seit der PostgreSQL-Version 13 können aber Extensions im Control File auch als so genannte "Trusted Extensions" markiert werden, die anderen Usern mit einem CREATE-Privileg in der Datenbank auch die Möglichkeit zur Aktivierung bietet.

Es ist zu beachten, dass bei einigen Extensions in der Konfigurationsdatei – im Standard-Fall die Datei postgresql.conf im Data-Verzeichnis des PostgreSQL-Clusters – Anpassungen gemacht werden müssen, die auch einen Neustart des Clusters verlangen. Im üblichen Fall ist die Änderung auf den Parameter shared_preload_libriaries beschränkt, wo bestimmte Extensions angegeben werden müssen. Dazu kommen noch etwaige Parametrisierungen der jeweiligen Extensions, die auch in der PostgreSQL-Konfigurationsdatei integriert werden können oder müssen.

Sind die Extensions in der Datenbank aktiviert, kann dies, wie bereits im Listing 2, am Beispiel der installierten Version 1.0 von plpsql geprüft werden. Dies lässt sich auch einfacher innerhalb der psql-Kommandozeile mit dem Befehl \dx anzeigen (s. Listing 4).

Listing 4 : Anzeige von installierten Extensions

[local]:5432 postgres@postgres=# \dx
 
                 List of installed extensions
 
  Name      | Version   |   Schema      |         Description
------------+-----------+---------------+----------------------
 plpgsql    | 1.0       | pg_catalog    | PL/pgSQL procedural language
 
(1 row)

Das Entfernen von Extensions ist im gewohnten SQL-Syntax genau so einfach. Mit DROP EXTENSION <extension name> CASCADE; wird die Extension wieder aus der Datenbank gelöscht und steht nicht mehr zur Verfügung. Die Ergänzung mit CASCADE sorgt dafür, dass alle relevanten Datenbank-Objekte ebenfalls entfernt werden.

Die systemweite Aktualisierung einer Extension über beispielsweise die Betriebssystem-Paketverwaltung wird nicht automatisch bis hin zur ausgerollten Fassung in der Datenbank durchgereicht. Hier muss diese Extension dann auch in der Datenbank mit einem Befehl ALTER EXTENSION <extension_name> UPDATE TO '<neue_version>'; aktualisiert werden.

Mit ähnlichen Befehlen kann es auch sein, dass weiterer Einfluss auf die Konfiguration, den Zustand oder den Inhalt der Extension genommen werden kann. Auch hier lässt sich dies mit der gewohnten SQL-Syntax problemlos bewerkstelligen. Beispielsweise kann mit ALTER EXTENSION <extension_name> ADD VIEW <schema_name.view_name>; eine bestimmte View zu einer Extension hinzugefügt werden, was mit anderen Objektarten identisch funktioniert.

Das Entfernen von Extensions ist im gewohnten SQL-Syntax genau so einfach. Mit DROP EXTENSION <extension name> CASCADE; wird die Extension wieder aus der Datenbank gelöscht und steht nicht mehr zur Verfügung. Die Ergänzung mit CASCADE sorgt dafür, dass alle relevanten Datenbank-Objekte mit-entfernt werden.

Die systemweite Aktualisierung einer Extension über beispielsweise die Betriebssystem-Paketverwaltung wird nicht automatisch bis hin zur ausgerollten Fassung in der Datenbank durchgereicht. Hier muss diese Extension dann auch in der Datenbank mit einem Befehl ALTER EXTENSION <extension_name> UPDATE TO '<neue_version>'; aktualisiert werden.

Mit ähnlichen Befehlen kann es auch sein, dass weiterer Einfluss auf die Konfiguration, den Zustand oder den Inhalt der Extension genommen werden kann. Auch hier lässt sich dies mit der gewohnten SQL-Syntax problemlos bewerkstelligen. Beispielsweise kann mit ALTER EXTENSION <extension_name> ADD VIEW <schema_name.view_name>; eine bestimmte View zu einer Extension hinzugefügt werden, was mit anderen Objektarten identisch funktioniert.

Tooling

Zusätzlich zu der integrierten Erweiterungsschnittstelle finden sich um PostgreSQL auch eine große Anzahl an hilfreichen Tools. Wo die Extensions meist feinmechanischere Funktionen innerhalb der Datenbanken bereitstellen, helfen solche Tools, die Steuerung von außerhalb zu verbessern, zu vereinfachen oder überhaupt in bestimmten Situationen zu ermöglichen.

In den populären Betriebsthemen wie Hochverfügbarkeit, Monitoring, Performance-Analytics und Backup/Recovery gibt es daher jeweils eine große Auswahl an Software-Produkten, die direkt mit dem Datenbanksystem interagieren können. Die damit entstehende Vielfalt ist auch hier häufig ein kontroverses Thema bei Entscheider:innen, bietet aber andersherum die Möglichkeit zur Wahl einer passenden Lösung für den jeweils eigenen Anwendungsfall. Häufig werden solche Lösungen auch mit einer zusammengehörigen Extension kombiniert.

Fazit

Auch wenn die Sorgen vor zu vielen Komponenten und Support-Faktoren von IT-Entscheider:innen durchaus nachvollzogen werden können, trübt diese Angst aber zu sehr das Gesamtbild und verdeckt die positiven Aspekte und Chancen. PostgreSQL bietet eine hohe Anzahl an sehr etablierten Erweiterungen und Zusatzlösungen, die sowohl durch die Community als auch durch kommerzielle Support-Anbieter unterstützt werden. Diese Vielfalt sollte viel mehr als Flexibilität und nicht als Risiko für Software-Wildwuchs gesehen werden. Die Erweiterbarkeit von PostgreSQL ist eine eindeutige Stärke des Datenbanksystems und bietet durch die Anpassungsfähigkeit viele Möglichkeiten.
 
In den kommenden Wochen wird es an dieser Stelle weitere Artikel geben, die jeweils eine Auswahl von Extensions und Tools vorstellen und beschreiben. Diese Auswahl entspricht der persönlichen Praxis-Empfehlung des Verfassers. Die Artikel-Serie soll einen Einblick in die Vielfalt und Vorteile der Erweiterungsmöglichkeit von PostgreSQL geben und zusätzlich durch Erfahrung aus der Praxis als kleine Vorauswahl künftige Entscheidungen vereinfachen oder sogar direkt Anreize schaffen.

Demnächst

Teil 2: Erweiterungen und Tools für Administration und Allgemeines
Teil 3: Erweiterungen und Tools für Monitoring und Performance-Analyse
Teil 4: Erweiterungen und Tools für Backup, Recovery und Hochverfügbarkeit
Teil 5: Erweiterungen und Tools für Security und Auditing

Quellen
  1. PostgreSQL-eXtension-Network

weitere Informationen:

Autor

Dirk Krautschick

Dirk Krautschick hat sich entschieden, die Begeisterung für Datenbanktechnologien und seine Fähigkeiten als Consultant unter Anderem im Finanz- und Energiesektor einzusetzen und stetig weiter zu vertiefen.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben