, die neueste Version der „besten relationalen Open-Source-Datenbank der Welt“, wird in ein paar Wochen erscheinen (wenn alles nach Plan läuft). Das entspricht dem gewohnten Zeitplan — jedes Jahr kommt eine neue Version mit einer Fülle neuer Funktionen heraus, und ehrlich gesagt, das ist beeindruckend. Deshalb bin ich ein aktives Mitglied der PostgreSQL-Community geworden.
Meiner Meinung nach enthält PostgreSQL 12 im Gegensatz zu früheren Versionen nicht eine oder zwei revolutionäre Funktionen (wie zum Beispiel Partitionierung oder Parallelabfragen). Ich habe einmal gesagt, dass das Hauptmerkmal von PostgreSQL 12 eine größere Stabilität ist. Und ist das nicht genau das, was man braucht, wenn man kritische Geschäftsdaten verwaltet?
Aber PostgreSQL 12 beschränkt sich nicht darauf: Mit neuen Funktionen und Verbesserungen werden Anwendungen besser funktionieren, und von Ihnen wird nur ein Upgrade verlangt!
(Nun, vielleicht müssen Sie die Indizes auch neu aufbauen, aber in dieser Version ist das nicht so dramatisch, wie wir es gewohnt sind.)
Es wäre großartig, PostgreSQL zu aktualisieren und sofort signifikante Verbesserungen ohne großen Aufwand zu genießen. Vor einigen Jahren habe ich das Upgrade von PostgreSQL 9.4 auf PostgreSQL 10 analysiert und gesehen, wie sich die Anwendungsleistung dank des verbesserten Parallelismus der Abfragen in PostgreSQL 10 beschleunigte. Und das Wichtigste: Es war kaum etwas von mir erforderlich (man musste nur einen Konfigurationsparameter einstellen. max_parallel_workers).
Stimmen Sie zu, es ist praktisch, wenn die Anwendungen direkt nach dem Upgrade besser funktionieren. Und wir bemühen uns sehr, die Benutzer zu erfreuen, denn die Zahl der PostgreSQL-Anwender wächst ständig.
Und wie wird ein einfaches Upgrade auf PostgreSQL 12 Sie glücklich machen? Lassen Sie es mich Ihnen erzählen.
Erhebliche Verbesserungen der Indizierung
Ohne Indizierung kommt eine Datenbank nicht weit. Wie sonst soll man Informationen schnell finden? Das fundamentale Indizierungssystem von PostgreSQL wird als bezeichnet. Dieser Indextyp ist für Speichersysteme optimiert.
Wir verwenden einfach den Operator CREATE INDEX ON some_table (some_column), und PostgreSQL erledigt die meiste Arbeit, um sicherzustellen, dass der Index aktuell bleibt, während wir ständig Werte einfügen, aktualisieren und löschen. Es funktioniert wie von Zauberhand.
Aber Indizes in PostgreSQL haben ein Problem — sie und nehmen zusätzlichen Speicherplatz auf der Festplatte ein, während die Leistung beim Abrufen und Aktualisieren von Daten nachlässt. Mit "Aufblähen" meine ich die ineffiziente Pflege der Indexstruktur. Dies kann mit überflüssigen Tupeln in Zusammenhang stehen, die entfernt werden. (Danke für die Informationen an Peter Geoghegan ()). Das Aufblähen des Index ist besonders bemerkbar bei Arbeitslasten, in denen der Index aktiv verändert wird.
PostgreSQL 12 verbessert die Leistung von B-Baum-Indizes erheblich, und Experimente mit TPC-C-ähnlichen Tests haben gezeigt, dass im Durchschnitt 40% weniger Speicherplatz verwendet wird. Nun verbringen wir weniger Zeit nicht nur mit der Wartung von B-Baum-Indizes (also mit Schreiboperationen), sondern auch mit dem Abrufen von Daten, da die Indizes viel kleiner geworden sind.
Anwendungen, die aktiv ihre Tabellen aktualisieren – typischerweise OLTP-Anwendungen () – werden die Festplatte viel effizienter nutzen und Anfragen verarbeiten. Je mehr Platz auf der Festplatte, desto mehr Raum hat die Datenbank für Wachstum, ohne die Infrastruktur aufzurüsten.
Einige Upgrade-Strategien erfordern einen Neuaufbau der B-Baum-Indizes, um von diesen Vorteilen zu profitieren (zum Beispiel, stellt die Indizes nicht automatisch wieder her). In früheren Versionen von PostgreSQL führte der Neuaufbau großer Indizes in Tabellen zu erheblichen Ausfallzeiten, da während dieser Zeit keine Änderungen vorgenommen werden konnten. Aber in PostgreSQL 12 gibt es noch ein weiteres großartiges Feature: Jetzt können Indizes parallel mit dem Befehl , um Ausfallzeiten vollständig zu vermeiden.
In PostgreSQL 12 gibt es auch weitere Verbesserungen der Indexinfrastruktur. Ein weiteres Thema, wo ein wenig Magie im Spiel ist, ist , auch bekannt als WAL (Write-Ahead-Log). Das Journal für vorauseilende Aufzeichnungen protokolliert jede Transaktion in PostgreSQL für den Fall eines Ausfalls und zur Replikation. Anwendungen nutzen es zur Archivierung und . Natürlich wird das vorauseilende Journal auf die Festplatte geschrieben, was sich auf die Leistung auswirken kann.
In PostgreSQL 12 wurden die WAL-Kosten, die durch GiST-, GIN- und SP-GiST-Indizes bei der Indexerstellung entstehen, verringert. Dies bietet mehrere greifbare Vorteile: WAL-Einträge nehmen weniger Speicherplatz auf der Festplatte ein, und Daten werden schneller wiederhergestellt, beispielsweise während der Wiederherstellung nach einem Ausfall oder der zeitlich begrenzten Wiederherstellung. Wenn Sie solche Indizes in Ihren Anwendungen verwenden (zum Beispiel nutzen geospatial Anwendungen auf Basis von PostGIS häufig den GiST-Index), ist dies ein weiteres Merkmal, das die Leistung erheblich verbessert, ohne dass Sie großen Aufwand leisten müssen.
Partitionierung – mehr, besser, schneller
In PostgreSQL 10 wurde eingeführt . In PostgreSQL 11 wurde es deutlich einfacher zu nutzen. In PostgreSQL 12 können Sie die Größe der Partitionen ändern.
In PostgreSQL 12 wurde die Leistung des Partitionierungssystems erheblich verbessert, insbesondere wenn Tabellen Tausende von Partitionen enthalten. Wenn eine Abfrage nur einige Partitionen in einer Tabelle betrifft, in der es Tausende gibt, wird sie viel schneller ausgeführt. Die Leistung wurde nicht nur für solche Abfragetypen verbessert. Auch die INSERT-Operationen in Tabellen mit vielen Partitionen wurden beschleunigt.
Das Datenbankeinfügen durch ist übrigens eine großartige Möglichkeit und hier ist ein Beispiel in partitionierte Tabellen in PostgreSQL 12 ebenfalls effektiver gemacht hat. Mit COPY war es schon immer schnell, aber in PostgreSQL 12 ist es einfach blitzschnell.
Dank dieser Vorteile können in PostgreSQL noch größere Datensätze gespeichert und einfacher abgerufen werden. Und das ganz ohne großen Aufwand Ihrerseits. Wenn eine Anwendung viele Partitionen hat, beispielsweise bei der Speicherung von Zeitreihendaten, führt ein einfacher Upgrade zu einer erheblichen Leistungsverbesserung.
Und obwohl diese Verbesserung nicht ganz in die Kategorie 'Wir haben ein Upgrade gemacht und freuen uns' fällt, können in PostgreSQL 12 Fremdschlüssel erstellt werden, die auf partitionierte Tabellen verweisen, sodass die Arbeit mit Partitionierung viel Freude bereitet.
WITH-Abfragen sind viel besser geworden
Wenn (auch bekannt als CTE, auch bekannt als WITH-Abfragen), ich konnte es kaum erwarten, einen Artikel darüber zu schreiben, . Dies ist eines dieser Merkmale, die die Anwendung beschleunigen werden. Wenn Sie natürlich CTE verwenden.
Ich stelle oft fest, dass Neulinge in SQL gerne CTE verwenden: Wenn man sie auf gewisse Weise schreibt, hat man das Gefühl, man schreibe ein imperatives Programm. Ich persönlich habe es geliebt, diese Abfragen umzuschreiben, um damit auszukommen ohne CTE und die Leistung zu steigern. Jetzt ist alles anders.
PostgreSQL 12 ermöglicht es, einen bestimmten Typ von CTE ohne Nebenwirkungen einzubetten (SELECT), der nur einmal näher am Ende der Abfrage verwendet wird. Wenn ich eine Statistik über CTE-Abfragen führen würde, die ich umgeschrieben habe, würden die meisten in diese Kategorie fallen. Das hilft Entwicklern, verständlichen Code zu schreiben, der jetzt auch schnell funktioniert.
Darüber hinaus optimiert PostgreSQL 12 die Ausführung von SQL selbst, sodass Sie nichts tun müssen. Und obwohl ich jetzt wahrscheinlich nicht mehr solche Abfragen optimieren muss, ist es großartig, dass PostgreSQL weiterhin an der Optimierung von Abfragen arbeitet.
Just-in-Time (JIT) – jetzt standardmäßig aktiviert
In PostgreSQL 12-Systemen mit Unterstützung für JIT-Kompilierung ist standardmäßig aktiviert. Erstens erhalten Sie Unterstützung für für einige interne Operationen, und zweitens können Abfragen mit Ausdrücken (ein einfaches Beispiel ist x + y) in den Auswahllisten (die Sie nach SELECT haben), Aggregaten, Ausdrücken mit WHERE-Klauseln und anderen JIT zur Leistungssteigerung nutzen.
Da JIT in PostgreSQL 12 standardmäßig aktiviert ist, wird die Leistung von selbst verbessert, aber ich empfehle, die Anwendung in PostgreSQL 11 zu testen, wo JIT gerade erst eingeführt wurde, um die Leistung der Abfragen zu messen und herauszufinden, ob etwas angepasst werden muss.
Was ist mit den anderen neuen Features von PostgreSQL 12?
PostgreSQL 12 bietet eine Menge neuer cooler Funktionen – vom Erkunden von JSON-Daten mit standardisierten SQL/JSON-Pfad-Ausdrücken bis hin zu Mehrfaktorauthentifizierung mit der Option clientcert=verify-full, erzeugten Spalten und vielem mehr. Das ist genug für einen eigenen Beitrag.
Wie PostgreSQL 10 wird PostgreSQL 12 die allgemeine Leistung sofort nach dem Upgrade steigern. Ihr könnt natürlich euren eigenen Weg haben – testet die Anwendung unter ähnlichen Bedingungen in einem produktiven System, bevor ihr die Verbesserungen aktiviert, wie ich es mit PostgreSQL 10 getan habe. Selbst wenn PostgreSQL 12 jetzt stabiler ist, als ich es vermutete, scheut euch nicht, die Anwendungen gründlich zu testen, bevor ihr sie in die Produktion gebt.
Quelle: habr.com
