, 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
