PostgreSQL 12 , die neueste Version der "weltweit besten relationalen Open-Source-Datenbank", erscheint in ein paar Wochen (wenn alles nach Plan läuft). Dies entspricht dem üblichen Zeitplan - einmal im Jahr erscheint eine neue Version mit vielen neuen Funktionen, die ehrlich gesagt beeindruckend ist. Daher wurde ich ein aktives Mitglied der PostgreSQL-Community.
Meiner Meinung nach enthält PostgreSQL 12 im Gegensatz zu früheren Versionen keine oder zwei revolutionäre Funktionen (wie Partitionierung oder Parallelität von Abfragen). Ich habe einmal gescherzt, dass das Hauptmerkmal von PostgreSQL 12 mehr Stabilität ist. Benötigen Sie das nicht, wenn Sie wichtige Geschäftsdaten verwalten?
PostgreSQL 12 ist jedoch nicht darauf beschränkt: Mit neuen Funktionen und Verbesserungen funktionieren Anwendungen besser und Sie müssen nur ein Upgrade durchführen!
(Nun, vielleicht sogar die Indizes neu erstellen, aber in dieser Version ist es nicht mehr so beängstigend wie früher.)
Es wird großartig sein, PostgreSQL zu aktualisieren und sofort signifikante Verbesserungen ohne unnötige Gesten zu genießen. Vor einigen Jahren habe ich das Upgrade von PostgreSQL 9.4 auf PostgreSQL 10 analysiert und festgestellt, wie sich die Anwendung aufgrund der verbesserten Abfrageparallelität in PostgreSQL 10 beschleunigt hat. Und vor allem war für mich fast nichts erforderlich (setzen Sie einfach den Konfigurationsparameter max_parallel_workers ).
Stimmen Sie zu, es ist praktisch, wenn Anwendungen direkt nach dem Upgrade besser funktionieren. Und wir bemühen uns sehr, den Benutzern zu gefallen, da PostgreSQL mehr davon hat.
Und wie macht Sie ein einfaches Upgrade auf PostgreSQL 12 glücklich? Ich werde es dir jetzt sagen.
Wichtige Indizierungsverbesserungen
Ohne Indizierung geht die Datenbank nicht weit. Und wie kann man sonst schnell Informationen finden? Das grundlegende PostgreSQL-Indizierungssystem heißt B-Tree . Diese Art von Index ist für Speichersysteme optimiert.
Wir verwenden nur die CREATE INDEX ON some_table (some_column) , und PostgreSQL hält den Index hervorragend auf dem neuesten Stand, während wir ständig Werte einfügen, aktualisieren und löschen. Alles funktioniert von selbst wie von Zauberhand.
PostgreSQL-Indizes haben jedoch ein Problem: Sie werden aufgebläht und beanspruchen zusätzlichen Speicherplatz, und die Leistung beim Abrufen und Aktualisieren von Daten wird verringert. Mit "Aufblähen" meine ich die ineffektive Aufrechterhaltung der Indexstruktur. Es kann an Mülltupeln liegen, die VACUUM entfernt (danke für die Informationen an Peter Geoghegan ). Das Aufblähen des Index macht sich insbesondere bei Workloads bemerkbar, bei denen sich der Index aktiv ändert.
PostgreSQL 12 verbessert die Leistung von B-Tree-Indizes erheblich, und Experimente mit Tests wie TPC-C haben gezeigt, dass der Speicherplatz jetzt durchschnittlich um 40% weniger genutzt wird. Jetzt verbringen wir weniger Zeit nicht nur mit der Pflege von B-Tree-Indizes (dh mit Schreibvorgängen), sondern auch mit dem Extrahieren von Daten, da die Indizes viel kleiner geworden sind.
Anwendungen, die ihre Tabellen aktiv aktualisieren - normalerweise OLTP-Anwendungen ( Echtzeit-Transaktionsverarbeitung ) - sind bei der Verwendung der Festplatte und der Verarbeitung von Anforderungen wesentlich effizienter. Je mehr Speicherplatz vorhanden ist, desto mehr Speicherplatz verfügt die Datenbank für Wachstum, ohne die Infrastruktur zu aktualisieren.
Bei einigen Upgrade-Strategien müssen B-Tree-Indizes neu erstellt werden, um diese nutzen zu können (z. B. erstellt pg_upgrade Indizes nicht automatisch neu). In früheren Versionen von PostgreSQL führte die Neuerstellung großer Indizes in Tabellen zu erheblichen Ausfallzeiten, da zu diesem Zeitpunkt keine Änderungen möglich waren. PostgreSQL 12 hat jedoch noch einen weiteren coolen Trick: Sie können jetzt Indizes parallel zum Befehl REINDEX CONCURRENTLY neu erstellen , um Ausfallzeiten vollständig zu vermeiden.
PostgreSQL 12 bietet weitere Verbesserungen an der Indizierungsinfrastruktur. Eine andere Sache, die ohne Magie nicht auskommen könnte, ist das Write-Ahead-Protokoll, das auch WAL (Write-Ahead-Protokoll) ist. Ein Write-Ahead-Protokoll zeichnet jede Transaktion in PostgreSQL im Falle eines Fehlers und einer Replikation auf. Anwendungen verwenden es zum Sichern und Wiederherstellen zu einem bestimmten Zeitpunkt . Natürlich wird das Write-Ahead-Protokoll auf die Festplatte geschrieben, was die Leistung beeinträchtigen kann.
PostgreSQL 12 hat den Overhead von WALs reduziert, die von den Indizes GiST, GIN und SP-GiST beim Erstellen des Index erstellt wurden. Dies bietet mehrere greifbare Vorteile: WAL-Datensätze belegen weniger Speicherplatz und Daten werden schneller reproduziert, z. B. während der Wiederherstellung nach einem Fehler oder zu einem bestimmten Zeitpunkt. Wenn Sie solche Indizes in Ihren Anwendungen verwenden (z. B. verwenden PostGIS-basierte Geodatenanwendungen häufig den GiST-Index), ist dies eine weitere Funktion, die die Leistung ohne Ihren Aufwand erheblich verbessert.
Partitionierung - größer, besser, schneller
PostgreSQL 10 führte die deklarative Partitionierung ein . PostgreSQL 11 hat die Verwendung erheblich vereinfacht. In PostgreSQL 12 können Sie die Skalierung von Abschnitten ändern.
In PostgreSQL 12 ist die Leistung des Partitionierungssystems viel besser, insbesondere wenn die Tabelle Tausende von Abschnitten enthält. Wenn eine Abfrage beispielsweise nur wenige Abschnitte in einer Tabelle betrifft, in denen Tausende vorhanden sind, wird sie viel schneller ausgeführt. Die Leistung wurde nicht nur für diese Art von Abfragen verbessert. Sie werden auch feststellen, wie sich INSERT-Operationen in Tabellen mit vielen Partitionen beschleunigt haben.
Das Schreiben von Daten mit COPY - dies ist übrigens eine großartige Möglichkeit, Daten in großen Mengen zu laden, und hier ein Beispiel für den Empfang von JSON - in partitionierten Tabellen in PostgreSQL 12 ist ebenfalls effizienter geworden. Mit COPY war alles so schnell, aber in PostgreSQL 12 fliegt es.
Dank dieser Vorteile kann PostgreSQL noch größere Datensätze speichern und das Abrufen erleichtern. Und keine Anstrengung von Ihrer Seite. Wenn die Anwendung beispielsweise viele Abschnitte enthält, werden Zeitreihendaten aufgezeichnet. Durch ein einfaches Upgrade wird die Leistung erheblich verbessert.
Und obwohl diese Verbesserung nicht ausschließlich aus der Kategorie „Upgrade und Freude“ stammt, können Sie in PostgreSQL 12 Fremdschlüssel erstellen, die auf partitionierte Tabellen verweisen, sodass die Arbeit mit der Partitionierung ein Vergnügen ist.
MIT Abfragen sind viel besser
Als der Patch auf die integrierten generischen Tabellenausdrücke angewendet wurde (es handelt sich um CTEs, es handelt sich auch um WITH-Abfragen), wollte ich unbedingt einen Artikel darüber schreiben, wie begeistert Anwendungsentwickler mit PostgreSQL waren . Dies ist eine dieser Funktionen, die die Anwendung beschleunigen. Es sei denn, Sie verwenden natürlich CTE.
Ich stelle oft fest, dass SQL-Neulinge gerne CTE verwenden: Wenn Sie sie auf eine bestimmte Weise schreiben, haben Sie direkt das Gefühl, ein zwingendes Programm zu schreiben. Ich persönlich habe es geliebt, diese Abfragen neu zu schreiben, um auf CTE zu verzichten und die Leistung zu steigern. Jetzt ist alles anders.
Mit PostgreSQL 12 können Sie einen bestimmten CTE-Typ ohne Nebenwirkungen ( SELECT ) einbetten, der gegen Ende der Abfrage nur einmal verwendet wird. Wenn ich Statistiken über Anfragen mit CTEs führen würde, die ich neu geschrieben habe, würden die meisten von ihnen in diese Kategorie fallen. Dies hilft Entwicklern, verständlichen Code zu schreiben, der jetzt auch schnell funktioniert.
Darüber hinaus optimiert PostgreSQL 12 die Ausführung von SQL selbst, Sie müssen nichts tun. Und obwohl ich solche Abfragen jetzt wahrscheinlich nicht optimieren muss, ist es großartig, dass PostgreSQL weiterhin an der Abfrageoptimierung arbeitet.
Just-in-Time (JIT) - Jetzt Standard
Auf PostgreSQL 12-Systemen mit LLVM- Unterstützung ist die JIT-Kompilierung standardmäßig aktiviert. Erstens erhalten Sie JIT- Unterstützung für einige interne Operationen und zweitens Abfragen mit Ausdrücken (das einfachste Beispiel ist x + y) in den Auswahllisten (die Sie nach SELECT haben), Aggregaten, Ausdrücken mit WHERE-Klauseln und anderen kann JIT verwenden, um die Leistung zu verbessern.
Da JIT standardmäßig in PostgreSQL 12 enthalten ist, verbessert sich die Leistung von selbst. Ich empfehle jedoch, die Anwendung in PostgreSQL 11 zu testen, wo JIT gerade erschienen ist, um die Abfrageleistung zu messen und festzustellen, ob Sie etwas optimieren müssen.
Aber was ist mit den anderen neuen Funktionen von PostgreSQL 12?
PostgreSQL bietet 12 Tonnen cooler neuer Funktionen - von der Möglichkeit, JSON-Daten mithilfe von Standard-SQL / JSON-Routenausdrücken zu untersuchen, bis hin zur Multi-Faktor-Authentifizierung mit dem Parameter clientcert=verify-full , erstellten Spalten und vielem mehr. Genug für einen separaten Beitrag.
Wie PostgreSQL 10 verbessert PostgreSQL 12 die Gesamtleistung direkt nach dem Upgrade. Natürlich können Sie Ihren eigenen Weg gehen - testen Sie die Anwendung unter ähnlichen Bedingungen im Arbeitssystem, bevor Sie die Verbesserungen aktivieren, wie ich es mit PostgreSQL 10 getan habe. Auch wenn PostgreSQL 12 bereits stabiler ist als erwartet, sollten Sie nicht faul sein, die Anwendungsqualität zu testen. bevor sie in der Produktion freigegeben werden.