, den nyeste version af "verdens bedste relationsdatabase med åben kildekode" lanceres om et par uger (hvis alt går som planlagt). Dette passer til den sædvanlige tidsplan — en ny version med masser af nye funktioner udgives hvert år, og ærligt talt er det imponerende. Derfor blev jeg en aktiv medlem af PostgreSQL-fællesskabet.
Efter min mening indeholder PostgreSQL 12, i modsætning til tidligere versioner, ikke en eller to revolutionerende funktioner (som f.eks. partitionering eller forespørgsels parallellisering). Jeg spøgte engang med, at den største funktion i PostgreSQL 12 er større stabilitet. Er det ikke netop det, man har brug for, når man håndterer kritiske data for sin virksomhed?
Men PostgreSQL 12 stopper ikke der: med de nye funktioner og forbedringer vil applikationerne fungere bedre, og alt hvad du behøver at gøre, er at opgradere!
(Nå, måske også genopbygge indekserne, men i denne udgivelse er det ikke så slemt, som vi er vant til.)
Det vil være fantastisk — at opgradere til PostgreSQL og straks nyde betydelige forbedringer uden unødvendige anstrengelser. For nogle år siden analyserede jeg opdateringen fra PostgreSQL 9.4 til PostgreSQL 10 og så, hvordan applikationen blev hurtigere takket være den forbedrede forespørgsels parallellisering i PostgreSQL 10. Og vigtigst af alt, der blev næsten ikke krævet noget fra mig (bare indstille en konfigurationsparameter, max_parallel_workers).
Enig, det er praktisk, når applikationerne fungerer bedre lige efter opgraderingen. Og vi gør virkelig vores bedste for at glæde brugerne, da der bliver flere og flere af dem, der bruger PostgreSQL.
Og hvordan en enkel opgradering til PostgreSQL 12 vil gøre dig glad? Det vil jeg nu fortælle om.
Betydelige forbedringer i indeksering
Uden indeksering kommer databasen ikke langt. Hvordan kan man ellers hurtigt finde information? Det fundamentale indekseringssystem i PostgreSQL kaldes . Denne type indeks er optimeret til lagringssystemer.
Vi bruger blot operatoren CREATE INDEX ON some_table (some_column), og PostgreSQL udfører det store arbejde med at holde indekset aktuelt, mens vi konstant indsætter, opdaterer og sletter værdier. Alt fungerer af sig selv, som ved magi.
Men indekserne i PostgreSQL har ét problem — de og optager unødvendig plads på disken, og ydeevnen ved dataudtrækning og opdatering falder. Med "opblæsning" henviser jeg til ineffektiv vedligeholdelse af indeksstrukturen. Dette kan være — eller ikke være — forbundet med affaldstuplet, som fjernes (tak for informationen til Peter Geoghegan ()). Opblæsning af indekset er især mærkbar i arbejdsbelastninger, hvor indekset aktivt ændres.
PostgreSQL 12 forbedrer markant ydeevnen af B-træ indeks, og eksperimenter med TPC-C tests har vist, at pladsen nu anvendes, i gennemsnit, 40% mindre. Vi bruger nu mindre tid ikke kun på vedligeholdelse af B-træ indekser (dvs. skriveoperationer), men også på dataudtrækning, da indekserne er blevet meget mindre.
Applikationer, der aktivt opdaterer deres tabeller — typisk OLTP-applikationer () — vil langt mere effektivt bruge disken og behandle forespørgsler. Jo mere plads der er på disken, jo mere plads har databasen til at vokse uden opgradering af infrastrukturen.
Nogle opgraderingsstrategier kræver, at B-træ indekserne genopbygges for at drage fordel af disse fordele (f.eks. genopbygger ikke indeksene automatisk). I tidligere versioner af PostgreSQL førte genopbygning af store indekser i tabeller til betydelige nedetider, da ændringer ikke kunne foretages i mellemtiden. Men i PostgreSQL 12 er der endnu en fantastisk funktion: nu kan indekser genopbygges parallelt med kommandoen , så man helt undgår nedetid.
PostgreSQL 12 har også andre forbedringer i indekseringsinfrastrukturen. Endnu en ting, hvor magi ikke udeblev, er , også kaldet WAL (write-ahead log). Forhåndsskrivningsloggen registrerer hver transaktion i PostgreSQL i tilfælde af fejl og replikering. Applikationer bruger den til arkivering og . Selvfølgelig skrives forhåndsskrivningsloggen til disken, hvilket kan påvirke ydeevnen.
I PostgreSQL 12 er omkostningerne for WAL-poster, der genereres af GiST-, GIN- og SP-GiST-indekserne, blevet reduceret ved opbygningen af indekser. Dette giver flere mærkbare fordele: WAL-posterne fylder mindre på disken, og dataene genoprettes hurtigere, for eksempel under fejlgendannelse eller gendannelse til et tidspunkt. Hvis du bruger sådanne indekser i dine applikationer (for eksempel de geospatiale applikationer baseret på PostGIS bruger meget GiST-indekset), er det endnu en funktion, der vil forbedre ydeevnen uden nogen anstrengelse fra din side.
Partitionering — mere, bedre, hurtigere
I PostgreSQL 10 blev der introduceret . I PostgreSQL 11 blev det meget nemmere at bruge. I PostgreSQL 12 kan sektionernes størrelse ændres.
I PostgreSQL 12 er ydeevnen for partitionssystemet blevet betydeligt bedre, især hvis tabellen har tusindvis af sektioner. For eksempel, hvis en forespørgsel kun berører et par sektioner i en tabel med tusindvis, vil den blive udført meget hurtigere. Ydeevnen er forbedret ikke kun for sådanne typer forespørgsler. Du vil også bemærke, hvordan INSERT-operationer i tabeller med mange sektioner er blevet hurtigere.
Dataindsætning ved hjælp af — for resten, dette er en fantastisk måde og her er et eksempel — i partitionsbaserede tabeller er blevet mere effektiv i PostgreSQL 12. Med COPY var det allerede hurtigt, men i PostgreSQL 12 er det virkelig hurtigt.
Takket være disse fordele kan PostgreSQL gemme datasæt af endnu større størrelse, og det er blevet lettere at hente dem. Og ingen anstrengelse fra din side. Hvis din applikation har mange sektioner, for eksempel hvis den indlæser tidsseriedata, vil en simpel opgradering forbedre dens ydeevne betydeligt.
Og selvom denne forbedring ikke helt falder ind under kategorien 'vi opgraderede og glæder os', kan man i PostgreSQL 12 oprette fremmednøgler, der refererer til partitionsbaserede tabeller, så arbejdet med partitionering bliver en fornøjelse.
WITH-forespørgsler er blevet meget bedre
Når (de kaldes også CTE, også kaldet WITH-forespørgsler), og jeg kunne ikke vente med at skrive en artikel om, . Dette er en af de funktioner, der vil fremskynde applikationen. Hvis du selvfølgelig bruger CTE.
Jeg bemærker ofte, at nybegyndere med SQL elsker at bruge CTE: hvis de skrives på en bestemt måde, føles det faktisk, som om man skriver et imperativt program. Personligt kunne jeg lide at omskrive disse forespørgsler for at undgå uden CTE og øge ydeevnen. Nu er alt anderledes.
PostgreSQL 12 gør det muligt at indlejre en bestemt type CTE uden bivirkninger (SELECT), som kun anvendes én gang tættere på slutningen af forespørgslen. Hvis jeg havde ført statistik over CTE-forespørgsler, som jeg har omskrevet, ville de fleste af dem være i denne kategori. Det hjælper udviklere med at skrive forståelig kode, der nu også kører hurtigt.
Desuden optimerer PostgreSQL 12 udførelsen af SQL selv, så du behøver ikke at gøre noget. Og selvom jeg sikkert ikke længere behøver at optimere sådanne forespørgsler, er det godt, at PostgreSQL fortsætter med at arbejde på optimering af forespørgsler.
Just-in-Time (JIT) - nu som standard
I systemer med PostgreSQL 12, der understøtter JIT-kompilering er aktiveret som standard. For det første får du støtte til til nogle interne operationer, og for det andet kan forespørgsler med udtryk (det enkleste eksempel er x + y) i udvalgslisterne (som står efter SELECT), aggregeringer, udtryk med WHERE-klausuler og andre bruge JIT til ydeevneforbedringer.
Da JIT er aktiveret som standard i PostgreSQL 12, vil ydeevnen forbedres automatisk, men jeg anbefaler at teste applikationen i PostgreSQL 11, hvor JIT lige er blevet introduceret, for at måle ydeevnen for forespørgsler og finde ud af, om der er behov for justeringer.
Hvad med de øvrige nye funktioner i PostgreSQL 12?
PostgreSQL 12 har en masse nye spændende funktioner - fra muligheden for at arbejde med JSON-data ved hjælp af standard SQL/JSON ruteudtryk til multifaktorautentifikation med parameteren clientcert=verify-full, genererede kolonner og meget mere. Det er nok til et separat indlæg.
Ligesom PostgreSQL 10 vil PostgreSQL 12 straks forbedre den samlede ydeevne efter opgraderingen. Du har selvfølgelig din egen vej - test applikationen under lignende forhold i dit produktionssystem, før du aktiverer forbedringerne, som jeg gjorde med PostgreSQL 10. Selvom PostgreSQL 12 allerede nu er mere stabil, end jeg havde antaget, så lad være med at spare på den grundige test af applikationerne, før du sender dem i produktion.
Kilde: habr.com
