Fortgeschrittene Datenbankfunktionen in PostgreSQL PostgreSQL implementiert einen riesigen Funktionsumfang und bleibt dabei sehr nahe am SQL-Standard.

Präsentation zum Thema: "Fortgeschrittene Datenbankfunktionen in PostgreSQL PostgreSQL implementiert einen riesigen Funktionsumfang und bleibt dabei sehr nahe am SQL-Standard."—  Präsentation transkript:

1 Fortgeschrittene Datenbankfunktionen in PostgreSQL PostgreSQL implementiert einen riesigen Funktionsumfang und bleibt dabei sehr nahe am SQL-Standard. Dadurch ist es großen komerziellen Datenbanken wie Oracle oder DB/2 durchaus ebenbürtig.

2 26.03.2011 Agenda ● Mini-SQL-Einführung ● Sequenzen und Serien ● Window Functions ● Common Table Expressions und Recursive Queries ● Constraints ● Stored Procedures und User Defined Functions ● Trigger ● Locking und Prepared Transactions ● PITR und Hot-Standby

3 26.03.2011 SQL ganz kurz erklärt ● Datenbanken anlegen, befüllen, ändern und abfragen ● Interaktiv oder programmiert ● Standard mit vielen mehr oder weniger kompatiblen Implementierungen ● SQL stammt von SEQUEL ab, erfunden von Edgar F. Todd, 1975, bei IBM ● Aktueller Standard ist SQL-2008, ISO 9075 ● Viele DB implementieren SQL-92 oder SQL-99 + eigene Erweiterungen

4 26.03.2011 DDL – Data Definition Language ● Erstellen von Datenstrukturen ● CREATE DATABASE ● CREATE SCHEMA ● CREATE TABLE ● CREATE VIEW ● CREATE INDEX ● CREATE USER ● Und noch einige mehr... ● Ändern von Datenstrukturen ● ALTER TABLE

5 26.03.2011 DML – Data Manipulation Language ● INSERT ● SELECT ● Simpler Fall – eine Tabelle ● JOIN ● UNION ● SUBSELECT ● UPDATE ● DELETE ● COPY

6 26.03.2011 Sequenzen ● Datentyp „serial“ - Realisierung durch Sequence ● Auch selbständig sinnvoll, z.B. Vergabe von EAN-Nummern ● Startwert und Inkrement einstellbar ● Nachträglich ändern mit ALTER SEQUENCE ● Vergabe und Entnahme atomar mit nextval('sequence_name') ● Aktueller Wert mit currval('sequence_name') ● Abbruch der Transaktion – Sequence wird nicht rückgesetzt, man erhält also keine „dichten“ Werte

7 26.03.2011 Serien und Values ● generate_series(start, ende, inkrement) erzeugt eine Reihe von Zahlen ● Datumsfunktionen – Generieren von Datumswerten ● VALUES() liefert „anonymes“ Tupel ● Wie Tabelle mit genau einer Zeile benutzbar ● Aliasnamen zuweisbar

8 26.03.2011 Window Functions ● Ähnlich Aggregatfunktion, aber ohne Zusammenfassung der Zeilen einer Gruppe zu einer Ausgabezeile ● Vielfältige Anwendungsmöglichkeiten zur Zahlenanalyse ● Syntax: Funktionsaufruf gefolgt von OVER ● Arbeitet im Prinzip auf SELECT-Result, ähnlich ORDER BY ● PARTITION BY zergliedert in Gruppen ● Einige Window-Functions arbeiten auf Unterbereich der Partition, genannt „Window Frame“. Default dafür ist Anfang der Partition bis aktuelle Zeile, kann aber durch RANGE oder ROWS geändert werden ● Nur in Spaltenliste und globaler ORDER BY erlaubt

9 26.03.2011 Common Table Expressions ● WITH name AS (select....) SELECT … ● Ergibt sowas wie eine temp. Tabelle nur für die Dauer der Abfrage ● Macht u.U. komplizierte Abfragen mit geschachtelten Sub- Selects lesbarer ● Treiberprobleme, falls Result-Set nur für Statements erwartet werden, die mit SELECT oder CALL anfangen

10 26.03.2011 Rekursive Queries ● Common Table Expression mit RECURSIVE-Modifier ● Anwendungen: Hierarchien auflösen, z.B. Stücklisten ● Bestehen aus ● Nicht-rekursiver Teil ● UNION ALL ● Rekursiver Teil ● Rekursiver Teil muss irgendwann ohne weitere Ergebniszeilen enden, sonst Endlosschleife ● Evtl. ARRAY-Var. einführen und schon gesehene Keys merken ● Trick: LIMIT 100 außenrum, postgresql-Implementierung hört auf, wenn genug Rows geliefert wurden

11 26.03.2011 Constraints ● Stellen Datenkonsistenz sicher ● Kein Ersatz für Fehlerbehandlung in der Anwendung, aber gut gegen Programmierfehler, generische Clients und eigene Dummheit ● Check Constraints – Einhaltung von Wertgrenzen, Spalten- oder Tabellenconstraints ● NOT NULL Constraints – Muss-Felder ● UNIQUE-Constraints – eindeutige Schlüssel bzw. Werte ● Referential Constraints stellen sicher, dass referenzierte Rows auch wirklich vorhanden sind ● Namen vergeben!

12 26.03.2011 User Defined Functions ● „serverseitige Programmierung“ ● Funktionsarten: ● Pures SQL ● Prozedurale (PL/pgSQL, PL/Tcl) ● Interne ● C ● CREATE FUNCTION – viele Parameter – siehe Doku ● Overloading – gleiche Funktionsnamen bei unterschiedlichen Argumentlisten erlaubt

13 26.03.2011 Funktionen in SQL ● Dollar-Quoting ist sinnvoll ● Argument-Typen deklarieren ● Zugriff auf Argumente mit $1, $2 usw. ● Rückgabewert deklarieren mit RETURNS-Klausel ● Argument kann auch Composite-Typ sein, typischerweise eine Row. Zugriff auf Argumente mit $1.spaltenname ● Rückgabe von Composite-Typ ebenfalls möglich. Zugriff auf Einzelwerte dann bei Aufruf mit: SELECT (func(arg)).columnname; oder auch in funktionaler Notation: SELECT columnname(func(arg));

14 26.03.2011 Funktionen in prozeduralen Sprachen ● Sprachen sind durch ladbare Module implementiert: PL/pgSQL, PL/Tcl, PL/Perl und PL/Python standardmäßig mitgeliefert, andere verfügbar, eigene machbar ● Einmalige Installation je Datenbank: CREATE LANGUAGE plperl; ● Entsprechend weglöschen mit DROP LANGUAGE ● Alles, was in Datenbank template1 angelegt wird, wird beim Erstellen anderer Datenbanken geerbt

15 26.03.2011 PL/pgSQL ● SQL + Control Structures ● Für SQL-Kenner leicht zu erlernen/benutzen ● Erbt alle Typen, Operatoren und Funktionen von SQL ● Ab Version 9.0 standardmäßig installiert ● Blockstruktur: [label] [DECLARE declarations....] BEGIN statements.... END [label]; ● Sub-Blöcke (Scoping von Variablen...)

16 26.03.2011 PL/pgSQL 2 ● Argumente und Rückgabewerte mit Namen nutzbar, nicht nur mit $1 usw. ● Wie in SQL-Funktionen auch sind als Ausgabe auch Row- Typen oder Tabellen möglich ● Generische RECORD-Typ, der zur Aufnahme irgendwelcher Row-Typen dienen kann ● IF … THEN … ELSIF … THEN … ELSE ● PERFORM.... (SELECT und Ergebnis ignorieren) ● EXECUTE String [INTO target] [USING expression,...] ● BEGIN … EXCEPTION … END; ● RETURN expression; RETURN QUERY query; ● LOOP …; RETURN NEXT expression; END LOOP;

17 26.03.2011 Trigger ● Funktion soll automatisch ausgeführt werden, wenn etwas in der Datenbank geschieht ● Für INSERT, UPDATE, DELETE ● per-row: für jede eingefügte/modifizierte/gelöschte Zeile ● per-statement: unabhängig von Anzahl betroffener Zeilen ● Before- oder after-Trigger ● Before-insert und before-update Trigger können Zeile modifizieren, ehe diese in die DB geschrieben wird ● Before-Trigger können NULL zurückgeben, um Aktion zu übergehen

18 26.03.2011 Trigger und PL/pgSQL ● Trigger wird durch Anweisung CREATE TRIGGER in Datenbank registriert ● Die Trigger-Funktion muss vorher bereitgestellt werden ● PL/pgSQL eignet sich dazu besonders gut ● NEW Record enthält neue Daten für INSERT/UPDATE row-level ● OLD Record enthält alte Daten für UPDATE/DELETE row-level ● TG_*-Variablen enthalten weitere Angaben, z.B. Name des Triggers, before oder after, ausgeführte Datenbankoperation, betroffene Tabelle und Zusatz-Argumente für die Triggerfunktion ● Damit lassen sich auch generische Trigger-Funktionen schreiben, die sich in Triggern verschiedener Tabellen wiederverwenden lassen.

19 26.03.2011 Locking ● MVCC-Konzept von postgresql sorgt für wenige Blockaden, erfordern dafür aber regelmäßiges VACUUM ● SELECT … FOR UPDATE ● Verschiedene Aktionen, die nicht gleichzeitig laufen sollen: select pg_advisory_lock(1); … do something select pg_advisory_lock(1); ● Advisory locks existieren unabhängig von Transaktionsgrenzen ● Anwendungsbeispiel: Warenzuteilung soll nicht gleichzeitig zweimal loslaufen. Sperren aller beteiligten Aufträge/Lieferscheine sind aber weder einfach noch notwendig.

20 26.03.2011 Prepared Transactions ● Transaktionen über mehr als ein beteiligtes (Datenbank-) System ● Reihenfolge: ● Transaktion starten – BEGIN ● Irgendwas tun, wenn fertig dann PREPARE TRANSACTION – Eigene Transaktion ist hier beendet, Status steht auf Platte, es kann nix mehr schiefgehen, prophylaktisch ist Sichtbarkeit wie nach einem ROLLBACK ● Fremdes System macht irgendwas in einer eigenen Transaktion – OK => COMMIT PREPARED – Fehler oder timeout => ROLLBACK PREPARED – Kann auch von einer anderen Session erfolgen

21 26.03.2011 PITR ● Steht für „Point In Time Recovery“ ● In postgresql.conf setzen: – archive_mode = on – archive_command = 'cp %f /archiv-pfad/' ● Im laufenden Betrieb Datenbank-Dateien wegkopieren: – select pg_start_backup('identifier'); – /var/lib/postgresql/... kopieren (cp, tar, rsync) – select pg_stop_backup(); ● Zum Wiederherstellen – Verzeichnis zurückkopieren – recovery.conf: restore_command = 'cp /archiv-pfad/%f %p' – Datenbank starten

22 26.03.2011 Hot Standby und Streaming Replication ● Setzt auf PITR auf. ● Wiederherstellen wie bei PITR auf anderem Server ausführen ● Eintrag „standby mode = on“ in recovery.conf bewirkt, dass der Server nicht komplett durchstartet ● WAL-Einträge werden bei Streaming Replication direkt übers Netz durch Slave vom Master geholt ● Asynchron, aber sehr geringe Verzögerung ● Nur Read-Only Statements erlaubt, auch keine temp. Tabellen ● Failover durch Anlegen eines Trigger-Files ● Hostname übernehmen ● Clients verlieren nur aktuelle Transaktion, müssen sich aber neu verbinden.