, die neueste Version der „besten Open-Source relationalen Datenbank der Welt“, wird in ein paar Wochen veröffentlicht (wenn alles nach Plan läuft). Dies entspricht dem üblichen Zeitplan – einmal im Jahr erscheint eine neue Version mit einer Vielzahl neuer Funktionen, und ganz ehrlich, das ist beeindruckend. Deshalb bin ich ein aktives Mitglied der PostgreSQL-Gemeinschaft geworden.
Meiner Meinung nach enthält PostgreSQL 12, im Gegensatz zu früheren Versionen, nicht ein oder zwei revolutionäre Funktionen (wie zum Beispiel Partitionierung oder parallele Abfragen). Ich habe einmal scherzhaft gesagt, dass das Hauptmerkmal von PostgreSQL 12 eine höhere Stabilität ist. Und ist das nicht genau das, was man braucht, wenn man kritische Daten seines Unternehmens verwaltet?
Aber PostgreSQL 12 bleibt dabei nicht stehen: Mit neuen Funktionen und Verbesserungen werden Anwendungen besser funktionieren, und Sie müssen nur ein Upgrade durchführen!
(Nun, vielleicht auch die Indizes neu aufbauen, aber bei diesem Release ist es nicht so schlimm, wie wir es gewohnt sind.)
Es wäre großartig, PostgreSQL zu aktualisieren und sofort erhebliche Verbesserungen ohne viel Aufwand zu genießen. Vor einigen Jahren habe ich das Upgrade von PostgreSQL 9.4 auf PostgreSQL 10 analysiert und gesehen, wie sich die Anwendung dank des verbesserten Parallelismus von Abfragen in PostgreSQL 10 beschleunigt hat. Und das Beste: Ich musste fast nichts tun (einfach nur die Konfigurationsparameter anpassen). max_parallel_workers).
Zugegeben, es ist praktisch, wenn die Anwendungen sofort nach dem Upgrade besser laufen. Wir geben unser Bestes, um die Nutzer zufriedenzustellen, denn die Zahl der PostgreSQL-Nutzer wächst ständig.
Wie wird ein einfaches Upgrade auf PostgreSQL 12 Sie glücklich machen? Lassen Sie es mich Ihnen erzählen.
Wesentliche Verbesserungen bei der Indizierung
Ohne Indizierung kommt eine Datenbank nicht weit. Wie sonst finden wir Informationen schnell? Das fundamentale Indizierungssystem von PostgreSQL heißt . Dieser Indextyp ist für Speichersysteme optimiert.
Wir verwenden einfach den Befehl CREATE INDEX ON some_table (some_column), und PostgreSQL erledigt die mühsame Arbeit, um die Aktualität des Indexes zu gewährleisten, während wir ständig Werte einfügen, aktualisieren und löschen. Alles läuft wie von selbst, fast wie zaubern.
PostgreSQL-Indizes haben jedoch ein Problem – sie und nehmen zusätzlichen Speicherplatz auf der Festplatte in Anspruch, wodurch die Leistung bei der Datenabfrage und -aktualisierung sinkt. Mit 'Aufblähen' meine ich die ineffiziente Pflege der Indexstruktur. Dies kann mit den nicht mehr benötigten Tupeln zusammenhängen, die entfernt werden (Danke an Peter Geoghegan für die Information ()). Das Aufblähen des Indexes ist insbesondere bei Arbeitslasten bemerkbar, in denen der Index aktiv verändert wird.
PostgreSQL 12 verbessert die Handhabung von B-Baum-Indizes erheblich, und Experimente mit TPC-C-Tests haben gezeigt, dass der Platz jetzt im Durchschnitt um 40 % geringer genutzt wird. Jetzt verschwenden wir weniger Zeit nicht nur mit der Pflege der B-Baum-Indizes (also bei Schreibvorgängen), sondern auch bei der Datenabfrage, da die Indizes wesentlich kleiner geworden sind.
Anwendungen, die ihre Tabellen aktiv aktualisieren – in der Regel handelt es sich dabei um OLTP-Anwendungen () – nutzen den Speicherplatz auf der Festplatte erheblich effizienter und können Anfragen besser verarbeiten. Je mehr Platz auf der Festplatte vorhanden ist, desto mehr Raum hat die Datenbank für Wachstum, ohne dass eine Infrastruktur-Upgrade erforderlich ist.
Einige Upgrade-Strategien erfordern das Neuaufbauen von B-Baum-Indizes, um von diesen Vorteilen zu profitieren (zum Beispiel, stellt die Indizes nicht automatisch neu auf). In früheren Versionen von PostgreSQL führte das Neuaufbauen großer Indizes in Tabellen zu erheblichen Ausfallzeiten, da während dieser Zeit keine Änderungen vorgenommen werden konnten. Doch in PostgreSQL 12 gibt es ein weiteres cooles Feature: Nun können Indizes parallel mit dem Befehl neu aufgebaut werden, um ganz auf Ausfallzeiten zu verzichten.
PostgreSQL 12 bietet auch andere Verbesserungen der Indexierungs-Infrastruktur. Ein weiteres Stück Magie ist das , auch bekannt als WAL (Write-Ahead Log). Das Write-Ahead Log zeichnet jede Transaktion in PostgreSQL für den Fall eines Ausfalls und für die Replikation auf. Anwendungen nutzen es zur Archivierung und . Natürlich wird das Write-Ahead Log auf die Festplatte geschrieben, was sich auf die Leistung auswirken kann.
In PostgreSQL 12 wurden die Kosten für WAL-Einträge, die durch GiST-, GIN- und SP-GiST-Indizes beim Erstellen eines Indexes entstehen, reduziert. Dies bietet mehrere spürbare Vorteile: WAL-Einträge benötigen weniger Speicherplatz auf der Festplatte, und die Daten können schneller wiederhergestellt werden, beispielsweise während einer Wiederherstellung nach einem Ausfall oder einer zeitbasierten Wiederherstellung. Wenn Sie solche Indizes in Ihren Anwendungen verwenden (zum Beispiel verwenden geo-räumliche Anwendungen auf Basis von PostGIS häufig den GiST-Index), ist dies ein weiteres Feature, das die Leistung erheblich verbessert, ohne dass Sie dafür zusätzlichen Aufwand betreiben müssen.
Partitionierung – mehr, besser, schneller
In PostgreSQL 10 wurde . In PostgreSQL 11 wurde die Anwendung deutlich vereinfacht. In PostgreSQL 12 kann die Größe der Partitionen angepasst werden.
In PostgreSQL 12 wurde die Leistung des Partitionierungssystems deutlich verbessert, insbesondere wenn eine Tabelle Tausende von Partitionen enthält. Wenn eine Abfrage nur einige Partitionen in einer solchen Tabelle betrifft, wird sie deutlich schneller ausgeführt. Die Leistung wurde nicht nur für diese Art von Abfragen verbessert.
Die Datenübertragung mit — übrigens, das ist eine hervorragende Methode und hier ist ein Beispiel — in partitionierten Tabellen in PostgreSQL 12 ist ebenfalls effizienter geworden. Mit COPY war es bereits schnell, aber in PostgreSQL 12 ist es äußerst schnell.
Dank dieser Vorteile können in PostgreSQL noch größere Datensätze gespeichert werden, und die Abrufbarkeit wurde einfacher. Und das ganz ohne Aufwand Ihrerseits. Wenn Ihre Anwendung viele Partitionen hat, zum Beispiel zur Speicherung von Zeitreihendaten, wird ein einfacher Upgrade die Leistung erheblich verbessern.
Obwohl diese Verbesserung nicht ganz in die Kategorie "Upgrade und freuen" fällt, ermöglicht PostgreSQL 12 das Erstellen von Fremdschlüsseln, die auf partitionierte Tabellen verweisen, sodass die Arbeit mit Partitionierung einfach Freude bereitet.
WITH-Abfragen sind deutlich verbessert worden.
Wenn (auch bekannt als CTE oder WITH-Abfragen), ich konnte es kaum erwarten, einen Artikel darüber zu schreiben, Dies ist eines dieser Features, die die Anwendung beschleunigen können. Vorausgesetzt, Sie verwenden CTE.
Ich merke oft, dass Anfänger in SQL gerne CTE verwenden: Wenn man sie auf eine bestimmte Weise schreibt, spürt man direkt, dass man ein imperatives Programm schreibt. Ich persönlich habe es geliebt, diese Abfragen umzuschreiben, um ohne CTE auszukommen und die Leistung zu steigern. Heute ist alles anders. ohne CTE und die Leistung steigern. Jetzt ist alles anders.
Mit PostgreSQL 12 lassen sich bestimmte Arten von CTE ohne Nebenwirkungen einbetten.SELECT), der nur einmal näher am Ende der Abfrage verwendet wird. Wenn ich die Abfragen mit CTE, die ich umgeschrieben habe, nachverfolgen würde, würden die meisten davon in diese Kategorie fallen. Das hilft Entwicklern, verständlichen Code zu schreiben, der jetzt auch noch schnell arbeitet.
Darüber hinaus optimiert PostgreSQL 12 die Ausführung von SQL selbst, sodass Sie nichts tun müssen. Und obwohl ich wahrscheinlich jetzt solche Abfragen nicht mehr optimieren muss, ist es großartig, dass PostgreSQL weiterhin an der Optimierung von Abfragen arbeitet.
Just-in-Time (JIT) – jetzt standardmäßig aktiviert
In Systemen mit PostgreSQL 12 mit Unterstützung für ist die JIT-Kompilierung standardmäßig aktiviert. Zunächst erhalten Sie Unterstützung für einige interne Operationen und außerdem können 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 JIT zur Leistungssteigerung nutzen.
Da JIT in PostgreSQL 12 standardmäßig aktiviert ist, wird die Leistung automatisch verbessert. Ich empfehle jedoch, die Anwendung in PostgreSQL 11 zu testen, wo JIT erstmals eingeführt wurde, um die Abfrageleistung zu messen und herauszufinden, ob Anpassungen nötig sind.
Und was ist mit den anderen neuen Funktionen von PostgreSQL 12?
PostgreSQL 12 bietet viele neue, interessante Funktionen – von der Möglichkeit, JSON-Daten mit den Standard-SQL/JSON-Pfad-Ausdrücken zu durchsuchen, bis hin zur mehrstufigen Authentifizierung mit dem Parameter clientcert=verify-full, den erzeugten Spalten und vielem mehr. Das wäre einen eigenen Beitrag wert.
Wie schon bei PostgreSQL 10 wird PostgreSQL 12 die Gesamtleistung sofort nach dem Upgrade steigern. Natürlich können Sie es auf Ihre Weise machen – testen Sie die Anwendung unter ähnlichen Bedingungen in Ihrem produktiven System, bevor Sie die Verbesserungen aktivieren, so wie ich es mit PostgreSQL 10 gemacht habe. Auch wenn PostgreSQL 12 jetzt stabiler ist, als ich angenommen hatte, scheuen Sie sich nicht, Ihre Anwendungen gründlich zu testen, bevor Sie sie in die Produktion geben.
Quelle: habr.com
