, den seneste version af "verdens bedste open source relationsdatabase," udkommer om et par uger (hvis alt går efter planen). Dette følger den sædvanlige tidsplan med at udgive en ny version med et væld af nye funktioner en gang om året, og ærligt talt, det er imponerende. Det er derfor, jeg blev et aktivt medlem af PostgreSQL-fællesskabet.
Efter min mening, i modsætning til tidligere udgivelser, indeholder PostgreSQL 12 ikke en eller to revolutionerende funktioner (som partitionering eller forespørgselsparallelisme). Jeg spøgte engang med, at hovedtræk ved PostgreSQL 12 er større stabilitet. Er det ikke det, du har brug for, når du administrerer din virksomheds kritiske data?
Men PostgreSQL 12 stopper ikke der: med nye funktioner og forbedringer vil applikationer yde bedre, og alt hvad du skal gøre er at opgradere!
(Nå, måske genopbygge indekserne, men i denne udgivelse er det ikke så skræmmende, som vi er vant til.)
Det vil være fantastisk at opgradere PostgreSQL og straks nyde betydelige forbedringer uden unødigt besvær. For et par år siden gennemgik jeg en opgradering fra PostgreSQL 9.4 til PostgreSQL 10 og så, hvordan applikationen accelererede takket være den forbedrede forespørgselsparallelisme i PostgreSQL 10. Og vigtigst af alt krævede jeg næsten intet af mig (bare sæt en konfigurationsparameter max_parallel_workers).
Enig, det er praktisk, når applikationer fungerer bedre umiddelbart efter en opgradering. Og vi prøver meget hårdt på at behage brugerne, fordi PostgreSQL har flere og flere af dem.
Så hvordan kan en simpel opgradering til PostgreSQL 12 gøre dig glad? Jeg fortæller dig det nu.
Store indekseringsforbedringer
Uden indeksering kommer en database ikke langt. Hvordan kan du ellers hurtigt finde information? PostgreSQL's fundamentale indekseringssystem kaldes . Denne type indeks er optimeret til lagersystemer.
Vi bruger simpelthen operatøren CREATE INDEX ON some_table (some_column), og PostgreSQL gør en masse arbejde for at holde indekset opdateret, mens vi konstant indsætter, opdaterer og sletter værdier. Alt fungerer af sig selv, som ved et trylleslag.
Men PostgreSQL-indekser har et problem - de og optager ekstra diskplads og reducerer ydeevnen af datahentning og opdatering. Med "bloat" mener jeg ineffektiv vedligeholdelse af indeksstrukturen. Dette kan - eller måske ikke - være relateret til de affaldstupler, som den fjerner (tak til Peter Gaghan for informationen))). Indeksbloat er især mærkbar i arbejdsbelastninger, hvor indekset aktivt ændrer sig.
PostgreSQL 12 forbedrer i høj grad ydeevnen af B-træ-indekser, og eksperimenter med benchmarks som TPC-C har vist, at der nu i gennemsnit bruges 40 % mindre plads. Nu bruger vi mindre tid ikke kun på at vedligeholde B-træindekser (det vil sige på skriveoperationer), men også på at hente data, fordi indekserne er meget mindre.
Programmer, der aktivt opdaterer deres tabeller - typisk OLTP-applikationer () - vil bruge disk og behandle anmodninger meget mere effektivt. Jo mere diskplads, jo mere plads har databasen til at vokse uden at opgradere infrastrukturen.
Nogle opgraderingsstrategier kræver genopbygning af B-træ-indekser for at drage fordel af disse fordele (f.eks. vil ikke genopbygge indekser automatisk). I tidligere versioner af PostgreSQL resulterede genopbygning af store indekser på tabeller i betydelig nedetid, fordi ændringer ikke kunne foretages i mellemtiden. Men PostgreSQL 12 har en anden cool funktion: nu kan du genopbygge indekser parallelt med kommandoen for helt at undgå nedetid.
Der er andre forbedringer til indekseringsinfrastrukturen i PostgreSQL 12. En anden ting, hvor der var noget magi - , alias WAL (fremskrivningslog). En fremskrivningslog registrerer hver transaktion i PostgreSQL i tilfælde af fejl og replikering. Applikationer bruger det til arkivering og . Selvfølgelig skrives fremskrivningsloggen til disken, hvilket kan påvirke ydeevnen.
PostgreSQL 12 har reduceret overheaden af WAL-poster, der oprettes af GiST-, GIN- og SP-GiST-indekserne under indekskonstruktion. Dette giver flere håndgribelige fordele: WAL-registreringer optager mindre diskplads, og data afspilles hurtigere, f.eks. under gendannelse efter katastrofer eller gendannelse på tidspunkter. Hvis du bruger sådanne indekser i dine applikationer (for eksempel bruger PostGIS-baserede geospatiale applikationer GiST-indekset meget), er dette en anden funktion, der vil forbedre oplevelsen markant uden nogen indsats fra din side.
Partitionering - større, bedre, hurtigere
PostgreSQL 10 introduceret . I PostgreSQL 11 er det blevet meget nemmere at bruge. I PostgreSQL 12 kan du ændre skalaen af sektioner.
I PostgreSQL 12 er partitioneringssystemets ydeevne blevet markant bedre, især hvis der er tusindvis af partitioner i tabellen. For eksempel, hvis en forespørgsel kun påvirker nogle få partitioner i en tabel med tusindvis af dem, vil den udføres meget hurtigere. Ydeevnen er ikke kun forbedret for disse typer forespørgsler. Du vil også bemærke, hvor hurtigere INSERT-operationer er på tabeller med flere partitioner.
Optagelse af data vha - forresten, det er en fantastisk måde og her er et eksempel — partitionerede tabeller i PostgreSQL 12 er også blevet mere effektive. Med COPY var alt allerede hurtigt, men i PostgreSQL 12 flyver det absolut.
Takket være disse fordele giver PostgreSQL dig mulighed for at gemme endnu større datasæt og gøre dem nemmere at hente. Og ingen indsats fra din side. Hvis applikationen har mange partitioner, såsom registrering af tidsseriedata, vil en simpel opgradering forbedre dens ydeevne betydeligt.
Selvom dette ikke ligefrem er en "opgradering og nyd"-forbedring, giver PostgreSQL 12 dig mulighed for at oprette fremmednøgler, der refererer til partitionerede tabeller, hvilket gør partitionering til en fornøjelse at arbejde med.
MED forespørgsler er lige blevet meget bedre
Hvornår (aka CTE, aka WITH queries), jeg kunne ikke vente med at skrive en artikel om . Dette er en af de funktioner, der vil fremskynde applikationen. Medmindre du selvfølgelig bruger CTE.
Jeg oplever ofte, at nybegyndere til SQL elsker at bruge CTE'er; hvis du skriver dem på en bestemt måde, føles det virkelig som om du skriver et bydende program. Personligt kunne jeg godt lide at omskrive disse forespørgsler for at komme rundt без CTE og øge produktiviteten. Nu er alt anderledes.
PostgreSQL 12 giver dig mulighed for at inline en specifik type CTE uden bivirkninger (SELECT), som kun bruges én gang nær slutningen af anmodningen. Hvis jeg holdt styr på de CTE-forespørgsler, jeg omskrev, ville de fleste af dem falde ind under denne kategori. Dette hjælper udviklere med at skrive tydelig kode, der nu også kører hurtigt.
Desuden optimerer PostgreSQL 12 selve SQL-udførelsen, uden at du behøver at gøre noget. Og selvom jeg nok ikke får brug for at optimere sådanne forespørgsler nu, er det dejligt, at PostgreSQL fortsætter med at arbejde med forespørgselsoptimering.
Just-in-Time (JIT) - nu standard
På PostgreSQL 12-systemer med support JIT-kompilering er aktiveret som standard. Først og fremmest får du støtte for nogle interne operationer, og for det andet kan forespørgsler med udtryk (det enkleste eksempel er x + y) i udvalgte lister (som du har efter SELECT), aggregater, udtryk med WHERE-sætninger og andre kan bruge JIT til at forbedre ydeevnen.
Da JIT er aktiveret som standard i PostgreSQL 12, forbedres ydeevnen af sig selv, men jeg anbefaler at teste applikationen i PostgreSQL 11, som introducerede JIT, for at måle forespørgselsydeevne og se, om du har brug for at justere noget.
Hvad med resten af de nye funktioner i PostgreSQL 12?
PostgreSQL 12 har et væld af fede nye funktioner, fra evnen til at undersøge JSON-data ved hjælp af standard SQL/JSON-ruteudtryk til multi-faktor-godkendelse med en parameter clientcert=verify-full, oprettede kolonner og meget mere. Nok til et separat indlæg.
Ligesom PostgreSQL 10 vil PostgreSQL 12 forbedre den samlede ydeevne umiddelbart efter opgraderingen. Du kan selvfølgelig have din egen vej - test applikationen under lignende forhold på produktionssystemet, før du aktiverer forbedringer, som jeg gjorde med PostgreSQL 10. Selvom PostgreSQL 12 allerede er mere stabil, end jeg havde forventet, skal du ikke være doven med at teste applikationer grundigt, før de frigives til produktion.
Kilde: www.habr.com