Cloud-First-Strategien sind inzwischen die Regel und nicht mehr die Ausnahme und Workloads verlagern sich damit in die Cloud – auch Datenbanken. Dort geht es ... (mehr)

Neue Abfragesprache

PostgreSQL 12 implementiert mit dem neuen Datentyp "jsonpath" die per SQL/JSON-definierte Abfragesprache "JSON Path". In Kombination mit dem "jsonb"-Datentyp kann der Administrator JSON-Dokumente, die er in Verbindung mit relationalen Daten und umfangreichen Abfrage- und Filtermöglichkeiten in PostgreSQL ablegen möchte, über entsprechende SQL-Abfragen verarbeiten.

Neue Funktionen wie "jsonb_path_query()", "jsonb_path_exists()", "jsonb_path_match()" sowie "jsonb_path_query_array()" und "jsonb_path_query_first()" lassen sich in SQL-Abfragen verwenden, um JSON-Dokumente auf entsprechende Attribute und Bedingungen zu prüfen. Ferner unterstützt PostgreSQL mittels der Operatoren "@@" und "@?" das Verwenden von JSON-Path- Ausdrücken direkt in Abfrageprädikaten. Bild 4 zeigt ein Beispiel mit einer Tabelle namens "movies", die eine Spalte "movie" mit einem JSON-Dokument speichert, dass jeweils einen einzelnen Film beschreibt.

Die Abfragen filtern Filme nach entsprechenden Kriterien. Zum einen alle Dokumente, die einen Film nach 2001 enthalten, sowie alle Filme aus dem Jahr 1968. Zum anderen eine komplexere Filterbedingung, die die Dokumente nach einem regulären Ausdruck (like_regex) und dem Jahr 1968 gleichzeitig filtert. Der "@?"-Operator akzeptiert links einen "jsonb"-Typ sowie als rechten Operanden einen Filterausdruck vom Typ "jsonpath". Der "@?"-Operator prüft, ob ein "jsonpath"- Ausdruck überhaupt einen Treffer zurückliefert. Im Gegensatz hierzu prüft der "@@"-Operator nur das erste Ergebnis des Filterausdrucks, daher kann auch "NULL" als Endergebnis entstehen.

Hinter beiden Operatoren stecken die Funktionen "jsonb_path_exists()" sowie "jsonb_path_match()". Über die Operatorklasse "jsonb_path_ops", die beide Operatoren enthält, lassen sich entsprechende JSON-Path-Ausdrücke mittels GIN-Indexen indizieren. Komplexere Ausdrücke, die Teile aus JSON-Dokumenten vom Typ "jsonb" extrahieren, sind beispielsweise mit der Funktion "jsonb_path_query()" realisierbar. Die Funktionalität ist sehr vielfältig, deshalb lohnt sich auf jeden Fall ein Blick in die Dokumentation [1].

Bild 4: JSON-Path-Filter selektieren bestimmte Attribute eines Films.

Zentrale Konfigurationsdatei

Der Zusammenschluss der Konfigurationsdateien "postgresql.conf " und "recovery. conf" hat weitreichende Konsequenzen hinsichtlich der Kompatibilität und Funktionalität von hochverfügbaren Umgebungen mit PostgreSQL. Letztere implementierte bis einschließlich PostgreSQL 11 sämtliche Parametrisierung für Archivund Standbysysteme. Dadurch steuerte die Datenbank zuvor Recovery- oder Streaming- Standby-Systeme je nach Anforderung. Das alltägliche Arbeiten hat jedoch gezeigt, dass es teilweise recht umständlich ist, mehrere Konfigurationsdateien zu verwalten. Ferner war die Implementierung der recovery.conf-Datei im Vergleich zum Verwalten von Parametern per postgresql. conf nur über eben diese Datei möglich. So ließ sich das Setzen von Parametern wie "restore_command" oder "primary_ conninfo" nur über das Editieren der recovery. conf-Datei lösen; der SQL-Befehl "ALTER SYSTEM" blieb außen vor.

Mit dem Vereinheitlichen der beiden Konfigurationen kümmert sich nun die zentrale Konfigurationsdatei postgresql.conf um sämtliche Parameter von recovery.conf. Dies bedeutet auch, dass die Konfiguration entsprechender Parameter identisch zu allen anderen bisherigen Parametern erfolgt. Dies schließt wie bereits erwähnt "ALTER SYSTEM" per SQL mit ein, es lassen sich aber auch Parameter einfach per SQL via "SHOW" abfragen. Die recovery.conf-Datei ist nicht mehr nutzbar und PostgreSQL 12 verweigert bei einer entsprechenden Präsenz den Start.

Administratoren müssen daher beim Upgrade die Konfiguration anpassen. Das Vereinheitlichen der beiden Konfigurationsdateien hat auch den Wegfall des Parameters "standby_mode" zur Folge. Dieser sorgte in den älteren Versionen dafür, dass beispielsweise ein Streaming-Standbyserver kontinuierlich Transaktionslogs konsumierte. Ob ein Server nun diese Standbyfunktionalität oder Recovery nutzen soll, steuern die neuen Signaldateien "recovery.signal" oder "standby.signal". Letztere hat Präzedenz, wenn beide vorhanden sind.

PostgreSQL-spezifische Clustermanager wie "Patroni" oder "repmgr" unterstützen natürlich die neue Funktionalität bereits. Aber auch Backupsoftware muss der ITVerantwortliche für das reibungslose Recovery anpassen. Bekannte Angebote wie "barman" oder "pgbackrest" sind hier selbstverständlich schon vorbereitet.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023