Uppgradering för lata: hur PostgreSQL 12 förbättrar prestandan

PostgreSQL 12, den senaste versionen av "världens bästa relationsdatabas med öppen källkod" släpps om ett par veckor (om allt går enligt plan). Detta följer det vanliga schemat — en ny version med massor av nya funktioner släpps en gång om året, och ärligt talat är det imponerande. Därför har jag blivit en aktiv medlem i PostgreSQL-gemenskapen.

Jag tycker att, till skillnad från tidigare versioner, så innehåller PostgreSQL 12 inga enstaka revolutionerande funktioner (som partitionering eller parallell begäran). Jag skämtade en gång om att den största grejen med PostgreSQL 12 är ökad stabilitet. Och är inte det precis vad man behöver när man hanterar kritiska data för verksamheten?

Men PostgreSQL 12 stannar inte där: med de nya funktionerna och förbättringarna kommer appar att prestera bättre, och allt som krävs av dig är att uppgradera!

(Nåväl, kanske även bygga om indexen, men i den här versionen är det inte så skrämmande som vi är vana vid.)

Det kommer att bli fantastiskt — att uppgradera PostgreSQL och direkt få njuta av betydande förbättringar utan extra ansträngning. För några år sedan analyserade jag uppgraderingen från PostgreSQL 9.4 till PostgreSQL 10 och såg hur applikationen accelererade tack vare förbättrad parallellism av förfrågningar i PostgreSQL 10. Och viktigast av allt, det krävdes nästan inget av mig (bara ställa in en konfigurationsparameter. max_parallel_workers).

Håller du med om att det är bekvämt när applikationerna fungerar bättre direkt efter uppgraderingen? Och vi strävar verkligen efter att glädja våra användare, för PostgreSQL får fler och fler användare.

Och hur kommer en enkel uppgradering till PostgreSQL 12 att göra dig lycklig? Låt mig förklara.

Betydande förbättringar av indexering

Utan indexering kommer databasen inte långt. Hur annars kan man snabbt hitta information? Det grundläggande indexeringssystemet i PostgreSQL kallas B-träd. Denna typ av index är optimerad för lagringssystem.

Vi använder helt enkelt kommandot CREATE INDEX ON some_table (some_column), och PostgreSQL gör det tunga arbetet att hålla indexet aktuellt medan vi ständigt sätter in, uppdaterar och tar bort värden. Allt fungerar automatiskt, som av magi.

Men indexen i PostgreSQL har ett problem — de växer. och tar upp onödig plats på disken, medan prestandan för datainhämtning och uppdatering minskar. Med "uppsvällning" menar jag ineffektiv hantering av indexstrukturen. Detta kan ha – eller inte ha – att göra med skräpkartor som tas bort VACUUM (tack för informationen Peter Geoghegan (Peter Geoghegan)). Uppsvällning av index är särskilt märkbar i arbetsbelastningar där indexet aktivt ändras.

PostgreSQL 12 förbättrar väsentligt hanteringen av B-träd-index, och experiment med tester som TPC-C har visat att utrymmet nu används i genomsnitt 40% mindre. Nu spenderar vi mindre tid inte bara på att underhålla B-träd-index (det vill säga skrivoperationer), utan även på datainhämtning, eftersom indexen har blivit mycket mindre.

Applikationer som aktivt uppdaterar sina tabeller – vanligtvis OLTP-applikationer (behandling av transaktioner i realtid) – kommer att använda disken mycket mer effektivt och hantera förfrågningar. Ju mer utrymme som finns på disken, desto mer utrymme har databasen för att växa utan att uppgradera infrastrukturen.

Vissa uppgraderingsstrategier kräver att B-träd-indexen byggs om för att dra nytta av dessa fördelar (till exempel, pg_upgrade bygger inte om index automatiskt). I tidigare versioner av PostgreSQL ledde ombyggnation av stora index i tabeller till betydande stillestånd, eftersom inga ändringar kunde göras under den tiden. Men i PostgreSQL 12 finns det en annan fantastisk funktion: nu kan man bygga om index parallellt med kommandot REINDEX CONCURRENTLY, för att helt undvika stillestånd.

I PostgreSQL 12 finns det också andra förbättringar av indexeringsinfrastrukturen. En annan sak där det inte saknas magi är journal med förhandsinspelning, även kallad WAL (write-ahead log). Loggen för förhandspostning registrerar varje transaktion i PostgreSQL för eventuella krasch- och replikationsfall. Applikationer använder den för arkivering och återställning vid en viss tidpunkt. Självklart skrivs loggen för förhandspostning till disken, vilket kan påverka prestandan.

I PostgreSQL 12 minskade kostnaderna för WAL-poster som skapas av GiST-, GIN- och SP-GiST-index vid indexbyggande. Detta ger flera märkbara fördelar: WAL-posterna tar mindre plats på disken och data återställs snabbare, till exempel under en återställning efter krasch eller en tidsåterställning. Om du använder sådana index i dina applikationer (till exempel, geospatiala applikationer som använder PostGIS använder mycket GiST-index), är det ytterligare en funktion som kommer att förbättra din verksamhet avsevärt utan några ansträngningar från din sida.

Partitionering - mer, bättre, snabbare

I PostgreSQL 10 introducerades deklara partitionering. I PostgreSQL 11 blev det mycket enklare att använda. I PostgreSQL 12 kan du ändra skalningen av partitioner.

I PostgreSQL 12 blev prestandan för partitionssystemet betydligt bättre, särskilt om det finns tusentals partitioner i tabellen. Till exempel, om en fråga berör bara några få partitioner i en tabell med tusentals, kommer den att köras mycket snabbare. Prestandan har förbättrats inte bara för sådana typer av frågor. Du kommer också att märka hur INSERT-operationer i tabeller med många partitioner har blivit snabbare.

Att skriva data med COPY — för övrigt, det är ett utmärkt sätt för massöverföring av data och här är ett exempel på JSON — i partitionerade tabeller i PostgreSQL 12 blev det också mer effektivt. Med COPY var det snabbt redan, och i PostgreSQL 12 går det verkligen snabbt.

Tack vare dessa fördelar kan PostgreSQL lagra ännu större datamängder, och det har blivit enklare att hämta dem. Och inga ansträngningar från din sida. Om din applikation har många partitioner, till exempel, om den skriver tidsseriedata, kommer en enkel uppgradering väsentligt att förbättra dess prestanda.

Och även om denna förbättring inte riktigt hör till kategorin 'uppgraderade och jublar', kan du i PostgreSQL 12 skapa främmande nycklar som refererar till partitionerade tabeller, vilket gör att arbete med partitionering blir en ren njutning.

WITH-frågor har blivit mycket bättre

När en patch för inbyggda generiska tabelluttryck har tillämpats (även kända som CTE, även kända som WITH-frågor), jag har länge velat skriva en artikel om hur glada utvecklarna av applikationer är med PostgreSQL . Det här är en av de funktioner som kommer att snabba upp applikationen. Om du använder CTE, förstås..

Jag märker ofta att nybörjare i SQL gillar att använda CTE: om man skriver dem på ett visst sätt känns det som att man skriver ett imperativt program. Personligen gillade jag att skriva om dessa frågor för att klara mig utan CTE och öka prestandan. Nu är allt annorlunda.

PostgreSQL 12 tillåter inbäddning av en viss typ av CTE utan bieffekter (VÄLJ), som endast används en gång mot slutet av frågan. Om jag skulle hålla statistik över frågor med CTE som jag skrev om, skulle de flesta av dem hamna i den kategorin. Detta hjälper utvecklare att skriva tydlig kod som nu också fungerar snabbt.

Dessutom optimerar PostgreSQL 12 SQL-exekveringen själv, du behöver inte göra något. Och även om jag nu förmodligen inte behöver optimera sådana frågor, är det bra att PostgreSQL fortsätter att arbeta med optimeringarna.

Just-in-Time (JIT) – är nu som standard

I PostgreSQL 12-system med stöd för LLVM JIT-kompilering är aktiverad som standard. Först och främst får du stöd för JIT för vissa interna operationer, och för det andra kan frågor med uttryck (det enklaste exemplet är x + y) i vallistor (som kommer efter SELECT), aggregat, uttryck med WHERE-klausuler och mer använda JIT för att öka prestandan.

Eftersom JIT är aktiverat som standard i PostgreSQL 12, förbättras prestandan automatiskt, men jag rekommenderar att testa applikationen i PostgreSQL 11, där JIT just introducerades, för att mäta prestandan hos frågorna och se om något behöver justeras.

Men vad sägs om de andra nya funktionerna i PostgreSQL 12?

I PostgreSQL 12 finns det massor av nya häftiga funktioner – från möjligheten att utforska JSON-data med hjälp av standard SQL/JSON-vägar till multifaktorautentisering med parameter clientcert=verify-full, genererade kolumner och mycket mer. Det räcker för ett eget inlägg.

Precis som PostgreSQL 10 kommer PostgreSQL 12 att öka den övergripande prestandan direkt efter uppgraderingen. Du kan såklart ha din egen väg – testa applikationen under liknande förhållanden i produktionssystemet innan du aktiverar förbättringarna, som jag gjorde med PostgreSQL 10. Även om PostgreSQL 12 redan nu är stabilare än jag hade förväntat mig, tveka inte att kvalitets testa applikationer innan du släpper dem i produktion.

Källa: habr.com