Upgrade für Faule: Wie PostgreSQL 12 die Leistung verbessert

PostgreSQL 12, die neueste Version der „weltbesten relationalen Open-Source-Datenbank“, erscheint in ein paar Wochen (wenn alles nach Plan läuft). Dies folgt dem üblichen Zeitplan, einmal im Jahr eine neue Version mit einer Menge neuer Funktionen zu veröffentlichen, und das ist ehrlich gesagt beeindruckend. Deshalb wurde ich ein aktives Mitglied der PostgreSQL-Community.

Meiner Meinung nach enthält PostgreSQL 12 im Gegensatz zu früheren Versionen nicht ein oder zwei revolutionäre Funktionen (wie Partitionierung oder Abfrageparallelität). Ich habe einmal gescherzt, dass das Hauptmerkmal von PostgreSQL 12 die größere Stabilität ist. Ist das nicht genau das, was Sie brauchen, wenn Sie die kritischen Daten Ihres Unternehmens verwalten?

Aber PostgreSQL 12 hört hier nicht auf: Mit neuen Funktionen und Verbesserungen werden Anwendungen leistungsfähiger, und alles, was Sie tun müssen, ist ein Upgrade!

(Na ja, vielleicht erstellen Sie die Indizes neu, aber in dieser Version ist es nicht so beängstigend, wie wir es gewohnt sind.)

Es wird großartig sein, PostgreSQL zu aktualisieren und sofort erhebliche Verbesserungen ohne unnötigen Aufwand zu genießen. Vor ein paar Jahren habe ich ein Upgrade von PostgreSQL 9.4 auf PostgreSQL 10 überprüft und gesehen, wie die Anwendung dank der verbesserten Abfrageparallelität in PostgreSQL 10 schneller wurde. Und was am wichtigsten ist: Von mir war fast nichts erforderlich (einfach einen Konfigurationsparameter festlegen). max_parallel_workers).

Stimmen Sie zu, es ist praktisch, wenn Anwendungen unmittelbar nach einem Upgrade besser funktionieren. Und wir bemühen uns sehr, die Benutzer zufrieden zu stellen, da es in PostgreSQL immer mehr davon gibt.

Wie kann Sie ein einfaches Upgrade auf PostgreSQL 12 glücklich machen? Ich sage es dir jetzt.

Wesentliche Verbesserungen bei der Indexierung

Ohne Indizierung kommt eine Datenbank nicht weit. Wie sonst können Sie schnell Informationen finden? Das grundlegende Indexierungssystem von PostgreSQL heißt B-Baum. Dieser Indextyp ist für Speichersysteme optimiert.

Wir verwenden einfach den Operator CREATE INDEX ON some_table (some_column), und PostgreSQL leistet viel Arbeit, um den Index auf dem neuesten Stand zu halten, während wir ständig Werte einfügen, aktualisieren und löschen. Alles funktioniert wie von selbst, wie von Zauberhand.

Aber PostgreSQL-Indizes haben ein Problem – sie sind aufgeblasen Sie beanspruchen zusätzlichen Speicherplatz und verringern die Leistung beim Datenabruf und bei der Aktualisierung. Mit „aufblähen“ meine ich die ineffektive Beibehaltung der Indexstruktur. Dies kann mit den Mülltupeln zusammenhängen, die entfernt werden – oder auch nicht VACUUM (Danke an Peter Gaghan für die Informationen)Peter Geoghegan)). Das Aufblähen des Index macht sich besonders bei Arbeitslasten bemerkbar, bei denen sich der Index aktiv ändert.

PostgreSQL 12 verbessert die Leistung von B-Tree-Indizes erheblich und Experimente mit Benchmarks wie TPC-C haben gezeigt, dass jetzt durchschnittlich 40 % weniger Speicherplatz verwendet werden. Jetzt verbringen wir weniger Zeit nicht nur mit der Pflege von B-Tree-Indizes (also mit Schreibvorgängen), sondern auch mit dem Abrufen von Daten, da die Indizes viel kleiner sind.

Anwendungen, die ihre Tabellen aktiv aktualisieren – typischerweise OLTP-Anwendungen (Echtzeit-Transaktionsverarbeitung) – wird die Festplatte nutzen und Anfragen viel effizienter verarbeiten. Je mehr Speicherplatz vorhanden ist, desto mehr Speicherplatz muss die Datenbank vergrößern, ohne dass die Infrastruktur aktualisiert werden muss.

Einige Upgrade-Strategien erfordern die Neuerstellung von B-Tree-Indizes, um diese Vorteile nutzen zu können (z. B. pg_upgrade erstellt die Indizes nicht automatisch neu). In früheren Versionen von PostgreSQL führte die Neuerstellung großer Indizes für Tabellen zu erheblichen Ausfallzeiten, da in der Zwischenzeit keine Änderungen vorgenommen werden konnten. Aber PostgreSQL 12 hat noch eine weitere coole Funktion: Jetzt können Sie Indizes parallel zum Befehl neu erstellen GLEICHZEITIG NEU INDEXIERENum Ausfallzeiten komplett zu vermeiden.

Es gibt weitere Verbesserungen an der Indexierungsinfrastruktur in PostgreSQL 12. Eine andere Sache, bei der es etwas Magie gab – Write-Ahead-Protokoll, auch bekannt als WAL (Write-Ahead-Protokoll). Ein Write-Ahead-Protokoll zeichnet jede Transaktion in PostgreSQL im Falle eines Fehlers und einer Replikation auf. Anwendungen nutzen es zur Archivierung und Wiederherstellung zu einem bestimmten Zeitpunkt. Natürlich wird das Write-Ahead-Protokoll auf die Festplatte geschrieben, was sich auf die Leistung auswirken kann.

PostgreSQL 12 hat den Overhead von WAL-Datensätzen reduziert, die von den GiST-, GIN- und SP-GiST-Indizes während der Indexerstellung erstellt werden. Dies bietet mehrere konkrete Vorteile: WAL-Datensätze beanspruchen weniger Speicherplatz und Daten werden schneller wiedergegeben, beispielsweise während einer Notfallwiederherstellung oder einer Point-in-Time-Wiederherstellung. Wenn Sie solche Indizes in Ihren Anwendungen verwenden (PostGIS-basierte Geodatenanwendungen verwenden beispielsweise häufig den GiST-Index), ist dies eine weitere Funktion, die das Erlebnis ohne Ihr Zutun erheblich verbessern wird.

Partitionierung – größer, besser, schneller

PostgreSQL 10 eingeführt deklarative Partitionierung. In PostgreSQL 11 ist die Verwendung viel einfacher geworden. In PostgreSQL 12 können Sie den Maßstab von Abschnitten ändern.

In PostgreSQL 12 ist die Leistung des Partitionierungssystems deutlich besser geworden, insbesondere wenn Tausende von Partitionen in der Tabelle vorhanden sind. Wenn eine Abfrage beispielsweise nur wenige Partitionen in einer Tabelle mit Tausenden davon betrifft, wird sie viel schneller ausgeführt. Bei dieser Art von Abfragen wird nicht nur die Leistung verbessert. Sie werden auch feststellen, wie schneller INSERT-Vorgänge bei Tabellen mit mehreren Partitionen sind.

Aufzeichnen von Daten mit COPY - Das ist übrigens eine tolle Möglichkeit Massendaten-Download und hier ist ein Beispiel JSON empfangen — Partitionierte Tabellen in PostgreSQL 12 sind ebenfalls effizienter geworden. Mit COPY war schon alles schnell, aber in PostgreSQL 12 fliegt es absolut.

Dank dieser Vorteile können Sie mit PostgreSQL noch größere Datensätze speichern und diese einfacher abrufen. Und kein Aufwand Ihrerseits. Wenn die Anwendung über viele Partitionen verfügt, beispielsweise zum Aufzeichnen von Zeitreihendaten, kann ein einfaches Upgrade die Leistung erheblich verbessern.

Auch wenn dies nicht gerade eine „Upgrade und genießen“-Verbesserung ist, können Sie mit PostgreSQL 12 Fremdschlüssel erstellen, die auf partitionierte Tabellen verweisen, was die Arbeit mit der Partitionierung zu einem Vergnügen macht.

WITH-Abfragen sind jetzt viel besser

Wenn Für integrierte allgemeine Tabellenausdrücke wurde ein Patch angewendet (auch bekannt als CTE, auch bekannt als WITH Queries), ich konnte es kaum erwarten, einen Artikel darüber zu schreiben wie zufrieden Anwendungsentwickler mit PostgreSQL waren. Dies ist eine dieser Funktionen, die die Anwendung beschleunigen. Es sei denn natürlich, Sie verwenden CTE.

Ich stelle oft fest, dass SQL-Neulinge gerne CTEs verwenden; wenn man sie auf eine bestimmte Art schreibt, fühlt es sich wirklich so an, als würde man ein zwingendes Programm schreiben. Persönlich habe ich diese Abfragen gerne umgeschrieben, um mich zurechtzufinden без CTE und steigern Sie die Produktivität. Jetzt ist alles anders.

Mit PostgreSQL 12 können Sie einen bestimmten CTE-Typ ohne Nebenwirkungen integrieren (SELECT), der nur einmal am Ende der Anfrage verwendet wird. Wenn ich die von mir neu geschriebenen CTE-Abfragen im Auge behalten würde, würden die meisten davon in diese Kategorie fallen. Dies hilft Entwicklern, klaren Code zu schreiben, der nun auch schnell läuft.

Darüber hinaus optimiert PostgreSQL 12 die SQL-Ausführung selbst, ohne dass Sie etwas tun müssen. 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 Unterstützung LLVM Die JIT-Kompilierung ist standardmäßig aktiviert. Zunächst erhalten Sie Unterstützung JIT Für einige interne Operationen und zweitens können Abfragen mit Ausdrücken (das einfachste Beispiel ist x + y) in Auswahllisten (die Sie nach SELECT haben), Aggregate, Ausdrücke mit WHERE-Klauseln und andere JIT verwenden, um die Leistung zu verbessern.

Da JIT in PostgreSQL 12 standardmäßig aktiviert ist, verbessert sich die Leistung von selbst. Ich empfehle jedoch, die Anwendung in PostgreSQL 11 zu testen, das JIT eingeführt hat, um die Abfrageleistung zu messen und zu sehen, ob Sie etwas optimieren müssen.

Was ist mit den restlichen neuen Funktionen in PostgreSQL 12?

PostgreSQL 12 bietet jede Menge coole neue Funktionen, von der Möglichkeit, JSON-Daten mithilfe von Standard-SQL/JSON-Routenausdrücken zu untersuchen, bis hin zur Multi-Faktor-Authentifizierung mit einem Parameter clientcert=verify-full, Spalten erstellt und vieles mehr. Genug für einen separaten Beitrag.

Wie PostgreSQL 10 wird auch PostgreSQL 12 die Gesamtleistung unmittelbar nach dem Upgrade verbessern. Sie können natürlich Ihren eigenen Weg gehen – testen Sie die Anwendung unter ähnlichen Bedingungen auf dem Produktionssystem, bevor Sie Verbesserungen aktivieren, wie ich es mit PostgreSQL 10 getan habe. Auch wenn PostgreSQL 12 bereits stabiler ist als ich erwartet hatte, sollten Sie beim Testen nicht faul sein Anwendungen gründlich durch, bevor sie in die Produktion freigegeben werden.

Source: habr.com