, den nyeste versjonen av "verdens beste åpen kildekode-relasjonsdatabase," kommer ut om et par uker (hvis alt går etter planen). Dette følger den vanlige planen med å gi ut en ny versjon med massevis av nye funksjoner en gang i året, og ærlig talt, det er imponerende. Det er derfor jeg ble et aktivt medlem av PostgreSQL-fellesskapet.
Etter min mening, i motsetning til tidligere utgivelser, inneholder ikke PostgreSQL 12 en eller to revolusjonerende funksjoner (som partisjonering eller spørringsparallellisme). Jeg spøkte en gang med at hovedfunksjonen til PostgreSQL 12 er større stabilitet. Er det ikke det du trenger når du administrerer virksomhetens kritiske data?
Men PostgreSQL 12 stopper ikke der: med nye funksjoner og forbedringer vil applikasjoner yte bedre, og alt du trenger å gjøre er å oppgradere!
(Vel, kanskje gjenoppbygge indeksene, men i denne utgivelsen er det ikke så skummelt som vi er vant til.)
Det vil være flott å oppgradere PostgreSQL og umiddelbart nyte betydelige forbedringer uten unødvendig oppstyr. For noen år siden gjennomgikk jeg en oppgradering fra PostgreSQL 9.4 til PostgreSQL 10 og så hvordan applikasjonen ble raskere takket være den forbedrede spørringsparallellen i PostgreSQL 10. Og, viktigst av alt, var nesten ingenting nødvendig fra meg (bare angi en konfigurasjonsparameter max_parallel_workers).
Enig, det er praktisk når applikasjoner fungerer bedre umiddelbart etter en oppgradering. Og vi prøver veldig hardt å glede brukerne, fordi PostgreSQL har flere og flere av dem.
Så hvordan kan en enkel oppgradering til PostgreSQL 12 gjøre deg glad? Jeg skal fortelle deg det nå.
Store indekseringsforbedringer
Uten indeksering vil en database ikke gå langt. Hvordan ellers kan du raskt finne informasjon? PostgreSQLs grunnleggende indekseringssystem kalles . Denne typen indeks er optimalisert for lagringssystemer.
Vi bruker bare operatøren CREATE INDEX ON some_table (some_column), og PostgreSQL gjør mye arbeid for å holde indeksen oppdatert mens vi hele tiden setter inn, oppdaterer og sletter verdier. Alt fungerer av seg selv, som ved et trylleslag.
Men PostgreSQL-indekser har ett problem - de og ta opp ekstra diskplass og redusere ytelsen til datainnhenting og oppdatering. Med "oppblåsthet" mener jeg ineffektivt vedlikehold av indeksstrukturen. Dette kan - eller kanskje ikke - være relatert til søppeltuplene som den fjerner (takk til Peter Gaghan for informasjonen))). Indeksoppblåsthet er spesielt merkbart i arbeidsbelastninger der indeksen aktivt endrer seg.
PostgreSQL 12 forbedrer ytelsen til B-treindekser betraktelig, og eksperimenter med benchmarks som TPC-C har vist at det nå i gjennomsnitt brukes 40 % mindre plass. Nå bruker vi mindre tid ikke bare på å vedlikeholde B-tree-indekser (det vil si på skriveoperasjoner), men også på å hente data, fordi indeksene er mye mindre.
Programmer som aktivt oppdaterer tabellene sine - vanligvis OLTP-applikasjoner () - vil bruke disk og behandle forespørsler mye mer effektivt. Jo mer diskplass, jo mer plass har databasen til å vokse uten å oppgradere infrastrukturen.
Noen oppgraderingsstrategier krever gjenoppbygging av B-tree-indekser for å dra nytte av disse fordelene (f.eks. vil ikke gjenoppbygge indekser automatisk). I tidligere versjoner av PostgreSQL resulterte gjenoppbygging av store indekser på tabeller i betydelig nedetid fordi endringer ikke kunne gjøres i mellomtiden. Men PostgreSQL 12 har en annen kul funksjon: nå kan du gjenoppbygge indekser parallelt med kommandoen for å unngå nedetid helt.
Det er andre forbedringer av indekseringsinfrastrukturen i PostgreSQL 12. En annen ting hvor det var litt magi - , også kjent som WAL (forhåndsskrivelogg). En fremskrivningslogg registrerer hver transaksjon i PostgreSQL i tilfelle feil og replikering. Applikasjoner bruker den til arkivering og . Selvfølgelig skrives fremskrivningsloggen til disk, noe som kan påvirke ytelsen.
PostgreSQL 12 har redusert overheaden til WAL-poster som opprettes av GiST-, GIN- og SP-GiST-indeksene under indekskonstruksjon. Dette gir flere konkrete fordeler: WAL-poster tar opp mindre diskplass, og data spilles av raskere, for eksempel under katastrofegjenoppretting eller punkt-i-tidsgjenoppretting. Hvis du bruker slike indekser i applikasjonene dine (for eksempel PostGIS-baserte geospatiale applikasjoner bruker GiST-indeksen mye), er dette en annen funksjon som vil forbedre opplevelsen betydelig uten noen anstrengelse fra din side.
Partisjonering - større, bedre, raskere
PostgreSQL 10 introdusert . I PostgreSQL 11 har det blitt mye enklere å bruke. I PostgreSQL 12 kan du endre skalaen på seksjoner.
I PostgreSQL 12 har ytelsen til partisjonssystemet blitt betydelig bedre, spesielt hvis det er tusenvis av partisjoner i tabellen. For eksempel, hvis en spørring påvirker bare noen få partisjoner i en tabell med tusenvis av dem, vil den utføres mye raskere. Ytelsen er ikke bare forbedret for denne typen søk. Du vil også legge merke til hvor raskere INSERT-operasjoner er på tabeller med flere partisjoner.
Registrering av data ved hjelp av – Dette er forresten en flott måte og her er et eksempel — partisjonerte tabeller i PostgreSQL 12 har også blitt mer effektive. Med COPY var alt allerede raskt, men i PostgreSQL 12 flyr det absolutt.
Takket være disse fordelene lar PostgreSQL deg lagre enda større datasett og gjøre dem enklere å hente. Og ingen innsats fra din side. Hvis applikasjonen har mange partisjoner, for eksempel registrering av tidsseriedata, vil en enkel oppgradering forbedre ytelsen betydelig.
Selv om dette ikke akkurat er en "oppgradering og nyt"-forbedring, lar PostgreSQL 12 deg lage fremmednøkler som refererer til partisjonerte tabeller, noe som gjør partisjonering til en fornøyelse å jobbe med.
WITH queries ble akkurat mye bedre
Når (aka CTE, aka WITH queries), jeg kunne ikke vente med å skrive en artikkel om . Dette er en av funksjonene som vil øke hastigheten på applikasjonen. Med mindre du selvfølgelig bruker CTE.
Jeg opplever ofte at nybegynnere til SQL elsker å bruke CTE-er; hvis du skriver dem på en bestemt måte, føles det virkelig som om du skriver et imperativt program. Personlig likte jeg å omskrive disse spørringene for å komme meg rundt без CTE og øke produktiviteten. Nå er alt annerledes.
PostgreSQL 12 lar deg legge inn en spesifikk type CTE uten bivirkninger (SELECT), som bare brukes én gang nær slutten av forespørselen. Hvis jeg holdt styr på CTE-spørringene jeg skrev om, ville de fleste av dem falle inn i denne kategorien. Dette hjelper utviklere med å skrive tydelig kode som nå også kjører raskt.
Dessuten optimerer PostgreSQL 12 selve SQL-kjøringen, uten at du trenger å gjøre noe. Og selv om jeg sannsynligvis ikke trenger å optimalisere slike spørringer nå, er det flott at PostgreSQL fortsetter å jobbe med spørringsoptimalisering.
Just-in-Time (JIT) - nå standard
På PostgreSQL 12-systemer med støtte JIT-kompilering er aktivert som standard. Først og fremst får du støtte for noen interne operasjoner, og for det andre kan spørringer med uttrykk (det enkleste eksemplet er x + y) i utvalgslister (som du har etter SELECT), aggregater, uttrykk med WHERE-klausuler og andre kan bruke JIT for å forbedre ytelsen.
Siden JIT er aktivert som standard i PostgreSQL 12, vil ytelsen forbedres av seg selv, men jeg anbefaler å teste applikasjonen i PostgreSQL 11, som introduserte JIT, for å måle søkeytelse og se om du trenger å justere noe.
Hva med resten av de nye funksjonene i PostgreSQL 12?
PostgreSQL 12 har massevis av kule nye funksjoner, fra muligheten til å undersøke JSON-data ved å bruke standard SQL/JSON-ruteuttrykk til multifaktorautentisering med en parameter clientcert=verify-full, opprettet kolonner og mye mer. Nok for et eget innlegg.
I likhet med PostgreSQL 10 vil PostgreSQL 12 forbedre den generelle ytelsen umiddelbart etter oppgraderingen. Du kan selvfølgelig ha din egen vei - test applikasjonen under lignende forhold på produksjonssystemet før du aktiverer forbedringer, som jeg gjorde med PostgreSQL 10. Selv om PostgreSQL 12 allerede er mer stabil enn jeg forventet, ikke vær lat med å teste applikasjoner grundig før de slippes ut i produksjon.
Kilde: www.habr.com