, den senaste versionen av "världens bästa relationsdatabas med öppen källkod", kommer ut om ett par veckor (om allt går enligt plan). Detta följer det vanliga schemat för att släppa en ny version med massor av nya funktioner en gång om året, och ärligt talat, det är imponerande. Det var därför jag blev en aktiv medlem i PostgreSQL-communityt.
Enligt min åsikt, till skillnad från tidigare utgåvor, innehåller PostgreSQL 12 inte en eller två revolutionerande funktioner (som partitionering eller frågeparallellism). Jag skämtade en gång om att huvudfunktionen i PostgreSQL 12 är större stabilitet. Är det inte det du behöver när du hanterar ditt företags kritiska data?
Men PostgreSQL 12 slutar inte där: med nya funktioner och förbättringar kommer applikationer att prestera bättre, och allt du behöver göra är att uppgradera!
(Tja, kanske bygga om indexen, men i den här utgåvan är det inte så skrämmande som vi är vana vid.)
Det kommer att vara fantastiskt att uppgradera PostgreSQL och omedelbart njuta av betydande förbättringar utan onödigt krångel. För några år sedan granskade jag en uppgradering från PostgreSQL 9.4 till PostgreSQL 10 och såg hur applikationen accelererade tack vare den förbättrade frågeparallellen i PostgreSQL 10. Och viktigast av allt, nästan ingenting krävdes av mig (ställ bara in en konfigurationsparameter max_parallel_workers).
Håller med, det är bekvämt när applikationer fungerar bättre direkt efter en uppgradering. Och vi försöker mycket hårt för att göra användarna nöjda, eftersom PostgreSQL har fler och fler av dem.
Så hur kan en enkel uppgradering till PostgreSQL 12 göra dig lycklig? Jag ska berätta nu.
Stora indexeringsförbättringar
Utan indexering kommer en databas inte att gå långt. Hur kan du annars snabbt hitta information? PostgreSQL:s grundläggande indexeringssystem kallas . Denna typ av index är optimerad för lagringssystem.
Vi använder helt enkelt operatören CREATE INDEX ON some_table (some_column), och PostgreSQL gör mycket arbete för att hålla indexet uppdaterat samtidigt som vi ständigt infogar, uppdaterar och tar bort värden. Allt fungerar av sig självt, som genom ett trollslag.
Men PostgreSQL-index har ett problem - de och ta upp extra diskutrymme och minska prestandan för datahämtning och uppdatering. Med "bloat" menar jag att ineffektivt upprätthålla indexstrukturen. Detta kan - eller kanske inte - vara relaterat till soptuplarna som den tar bort (tack till Peter Gaghan för informationen))). Indexuppsvällning är särskilt märkbar i arbetsbelastningar där indexet aktivt förändras.
PostgreSQL 12 förbättrar avsevärt prestandan för B-trädindex, och experiment med riktmärken som TPC-C har visat att i genomsnitt 40 % mindre utrymme nu används. Nu lägger vi mindre tid på att underhålla B-tree-index (det vill säga på skrivoperationer), utan också på att hämta data, eftersom indexen är mycket mindre.
Applikationer som aktivt uppdaterar sina tabeller - vanligtvis OLTP-applikationer () - kommer att använda disk- och processförfrågningar mycket mer effektivt. Ju mer diskutrymme, desto mer utrymme har databasen för att växa utan att uppgradera infrastrukturen.
Vissa uppgraderingsstrategier kräver ombyggnad av B-tree-index för att dra nytta av dessa fördelar (t.ex. kommer inte att bygga om index automatiskt). I tidigare versioner av PostgreSQL resulterade ombyggnad av stora index på tabeller i betydande driftstopp eftersom ändringar inte kunde göras under tiden. Men PostgreSQL 12 har en annan cool funktion: nu kan du bygga om index parallellt med kommandot för att helt undvika stillestånd.
Det finns andra förbättringar av indexeringsinfrastrukturen i PostgreSQL 12. En annan sak där det fanns lite magi - , aka WAL (skriv-förut-logg). En framskrivningslogg registrerar varje transaktion i PostgreSQL i händelse av fel och replikering. Applikationer använder det för arkivering och . Naturligtvis skrivs framskrivningsloggen till disk, vilket kan påverka prestandan.
PostgreSQL 12 har minskat overheaden för WAL-poster som skapas av GiST-, GIN- och SP-GiST-indexen under indexkonstruktion. Detta ger flera påtagliga fördelar: WAL-poster tar upp mindre diskutrymme och data spelas upp snabbare, till exempel under katastrofåterställning eller punktåterställning. Om du använder sådana index i dina applikationer (till exempel PostGIS-baserade geospatiala applikationer använder GiST index mycket), är detta ytterligare en funktion som kommer att förbättra upplevelsen avsevärt utan någon ansträngning från din sida.
Partitionering - större, bättre, snabbare
PostgreSQL 10 introduceras . I PostgreSQL 11 har det blivit mycket lättare att använda. I PostgreSQL 12 kan du ändra skalan på sektioner.
I PostgreSQL 12 har prestandan för partitioneringssystemet blivit betydligt bättre, speciellt om det finns tusentals partitioner i tabellen. Till exempel, om en fråga bara påverkar ett fåtal partitioner i en tabell med tusentals av dem, kommer den att köras mycket snabbare. Prestanda förbättras inte bara för dessa typer av frågor. Du kommer också att märka hur snabbare INSERT-operationer är på tabeller med flera partitioner.
Spela in data med hjälp av – förresten, det här är ett bra sätt och här är ett exempel — partitionerade tabeller i PostgreSQL 12 har också blivit mer effektiva. Med COPY var allt redan snabbt, men i PostgreSQL 12 flyger det absolut.
Tack vare dessa fördelar låter PostgreSQL dig lagra ännu större datamängder och göra dem lättare att hämta. Och ingen ansträngning från din sida. Om applikationen har många partitioner, till exempel inspelning av tidsseriedata, kommer en enkel uppgradering att förbättra dess prestanda avsevärt.
Även om detta inte precis är en "uppgradering och njut"-förbättring låter PostgreSQL 12 dig skapa främmande nycklar som refererar till partitionerade tabeller, vilket gör partitionering till ett nöje att arbeta med.
WITH queries har precis blivit mycket bättre
När (aka CTE, aka WITH queries), jag kunde inte vänta med att skriva en artikel om . Detta är en av de funktioner som kommer att påskynda applikationen. Såvida du inte använder CTE förstås.
Jag tycker ofta att nybörjare till SQL älskar att använda CTE:er; om du skriver dem på ett visst sätt känns det verkligen som att du skriver ett imperativt program. Personligen gillade jag att skriva om dessa frågor för att komma runt без CTE och öka produktiviteten. Nu är allt annorlunda.
PostgreSQL 12 låter dig infoga en specifik typ av CTE utan biverkningar (SELECT), som endast används en gång nära slutet av begäran. Om jag höll reda på CTE-frågorna jag skrev om skulle de flesta av dem falla i den här kategorin. Detta hjälper utvecklare att skriva tydlig kod som nu också går snabbt.
Dessutom optimerar PostgreSQL 12 SQL-exekveringen själv, utan att du behöver göra något. Och även om jag förmodligen inte kommer att behöva optimera sådana frågor nu, är det bra att PostgreSQL fortsätter att arbeta med frågeoptimering.
Just-in-Time (JIT) - nu standard
På PostgreSQL 12-system med stöd JIT-kompilering är aktiverad som standard. Först och främst får du stöd för vissa interna operationer, och för det andra, frågor med uttryck (det enklaste exemplet är x + y) i urvalslistor (som du har efter SELECT), aggregat, uttryck med WHERE-satser och andra kan använda JIT för att förbättra prestandan.
Eftersom JIT är aktiverat som standard i PostgreSQL 12 kommer prestandan att förbättras av sig själv, men jag rekommenderar att du testar applikationen i PostgreSQL 11, som introducerade JIT, för att mäta frågeprestanda och se om du behöver justera något.
Hur är det med resten av de nya funktionerna i PostgreSQL 12?
PostgreSQL 12 har massor av coola nya funktioner, från möjligheten att undersöka JSON-data med standard SQL/JSON-ruttuttryck till multifaktorautentisering med en parameter clientcert=verify-full, skapade kolumner och mycket mer. Tillräckligt för ett separat inlägg.
Liksom PostgreSQL 10 kommer PostgreSQL 12 att förbättra den övergripande prestandan direkt efter uppgraderingen. Du kan naturligtvis ha din egen väg - testa applikationen under liknande förhållanden i produktionssystemet innan du möjliggör förbättringar, som jag gjorde med PostgreSQL 10. Även om PostgreSQL 12 redan är stabilare än jag förväntade mig, var inte lat med att testa applikationer noggrant innan de släpps i produktion.
Källa: will.com