, najnovejša različica »najboljše odprtokodne relacijske baze podatkov na svetu«, bo izšla čez nekaj tednov (če bo šlo vse po načrtih). To sledi običajnemu razporedu izdaje nove različice s tono novih funkcij enkrat letno, in odkrito povedano, to je impresivno. Zato sem postal aktiven član skupnosti PostgreSQL.
Po mojem mnenju za razliko od prejšnjih izdaj PostgreSQL 12 ne vsebuje ene ali dveh revolucionarnih funkcij (kot je particioniranje ali paralelizem poizvedb). Nekoč sem se šalil, da je glavna značilnost PostgreSQL 12 večja stabilnost. Ali ni to tisto, kar potrebujete, ko upravljate ključne podatke svojega podjetja?
Toda PostgreSQL 12 se tu ne ustavi: z novimi funkcijami in izboljšavami bodo aplikacije delovale bolje, in vse kar morate storiti je nadgraditi!
(No, morda ponovno zgradite indekse, vendar v tej izdaji ni tako strašljivo, kot smo vajeni.)
Odlično bo nadgraditi PostgreSQL in takoj uživati v bistvenih izboljšavah brez nepotrebnega napora. Pred nekaj leti sem pregledal nadgradnjo s PostgreSQL 9.4 na PostgreSQL 10 in videl, kako se je aplikacija pospešila zahvaljujoč izboljšanemu paralelizmu poizvedb v PostgreSQL 10. In kar je najpomembneje, od mene ni bilo zahtevano skoraj nič (samo nastavite konfiguracijski parameter max_parallel_workers).
Strinjam se, priročno je, ko aplikacije delujejo bolje takoj po nadgradnji. In zelo se trudimo ugoditi uporabnikom, saj jih ima PostgreSQL čedalje več.
Kako vas lahko preprosta nadgradnja na PostgreSQL 12 osreči? zdaj ti bom povedal.
Glavne izboljšave indeksiranja
Brez indeksiranja baza podatkov ne bo prišla daleč. Kako drugače lahko hitro najdete informacije? Osnovni sistem indeksiranja PostgreSQL se imenuje . Ta vrsta indeksa je optimizirana za sisteme za shranjevanje.
Preprosto uporabimo operater CREATE INDEX ON some_table (some_column), in PostgreSQL opravi veliko dela, da ohranja indeks posodobljen, medtem ko nenehno vstavljamo, posodabljamo in brišemo vrednosti. Vse deluje samo od sebe, kot po čarovniji.
Toda indeksi PostgreSQL imajo eno težavo - oni ter zasedejo dodaten prostor na disku in zmanjšajo zmogljivost pri pridobivanju in posodabljanju podatkov. Z "napihnjenostjo" mislim na neučinkovito vzdrževanje strukture indeksa. To je lahko – ali pa tudi ne – povezano s torkami smeti, ki jih odstrani (hvala Petru Gaghanu za informacije))). Napihnjenost indeksa je še posebej opazna pri delovnih obremenitvah, kjer se indeks aktivno spreminja.
PostgreSQL 12 močno izboljša zmogljivost indeksov B-drevesa, poskusi z merili uspešnosti, kot je TPC-C, pa so pokazali, da se zdaj v povprečju porabi 40 % manj prostora. Sedaj porabimo manj časa ne samo za vzdrževanje indeksov B-drevesa (torej za zapisovalne operacije), ampak tudi za pridobivanje podatkov, ker so indeksi veliko manjši.
Aplikacije, ki aktivno posodabljajo svoje tabele – običajno aplikacije OLTP () - bo uporabljal disk in obdelal zahteve veliko bolj učinkovito. Več kot je prostora na disku, več prostora mora baza podatkov rasti brez nadgradnje infrastrukture.
Nekatere strategije nadgradnje zahtevajo ponovno izgradnjo indeksov B-drevesa, da bi izkoristili te prednosti (npr. ne bo samodejno obnovil indeksov). V prejšnjih različicah PostgreSQL je vnovična izgradnja velikih indeksov na tabelah povzročila znatne izpade, ker medtem ni bilo mogoče izvesti sprememb. Toda PostgreSQL 12 ima še eno kul funkcijo: zdaj lahko ponovno zgradite indekse vzporedno z ukazom da se popolnoma izognete izpadom.
Obstajajo še druge izboljšave infrastrukture indeksiranja v PostgreSQL 12. Še ena stvar, kjer je bilo nekaj čarovnije - , tudi WAL (dnevnik vnaprejšnjega pisanja). Dnevnik vnaprejšnjega pisanja beleži vsako transakcijo v PostgreSQL v primeru napake in replikacije. Aplikacije ga uporabljajo za arhiviranje in . Seveda se dnevnik vnaprejšnjega pisanja zapiše na disk, kar lahko vpliva na zmogljivost.
PostgreSQL 12 je zmanjšal obremenitev zapisov WAL, ki jih ustvarijo indeksi GiST, GIN in SP-GiST med gradnjo indeksa. To zagotavlja več oprijemljivih prednosti: zapisi WAL zavzamejo manj prostora na disku in podatki se hitreje predvajajo, na primer med obnovitvijo po nesreči ali obnovo v trenutku. Če uporabljate takšne indekse v svojih aplikacijah (na primer geoprostorske aplikacije, ki temeljijo na PostGIS, pogosto uporabljajo indeks GiST), je to še ena funkcija, ki bo bistveno izboljšala izkušnjo brez kakršnega koli truda z vaše strani.
Particioniranje - večje, boljše, hitrejše
Predstavljen PostgreSQL 10 . V PostgreSQL 11 je postalo veliko lažje za uporabo. V PostgreSQL 12 lahko spremenite obseg odsekov.
V PostgreSQL 12 je zmogljivost sistema particioniranja postala bistveno boljša, še posebej, če je v tabeli na tisoče particij. Na primer, če poizvedba vpliva le na nekaj particij v tabeli s tisoči particij, se bo izvedla veliko hitreje. Učinkovitost ni izboljšana samo za te vrste poizvedb. Opazili boste tudi, kako hitrejše so operacije INSERT v tabelah z več particijami.
Snemanje podatkov z uporabo - mimogrede, to je odličen način in tukaj je primer — tudi particionirane tabele v PostgreSQL 12 so postale učinkovitejše. Pri COPY je bilo že vse hitro, v PostgreSQL 12 pa naravnost leti.
Zahvaljujoč tem prednostim lahko PostgreSQL shrani še večje nabore podatkov in olajša njihovo pridobivanje. In brez truda z vaše strani. Če ima aplikacija veliko particij, kot je snemanje podatkov časovnih vrst, bo preprosta nadgradnja bistveno izboljšala njeno delovanje.
Čeprav to ni ravno izboljšava "nadgradi in uživaj", vam PostgreSQL 12 omogoča ustvarjanje tujih ključev, ki se sklicujejo na particionirane tabele, zaradi česar je particioniranje užitek delati.
Poizvedbe WITH so pravkar postale veliko boljše
Pri (alias CTE, alias WITH queries), sem komaj čakal, da napišem članek o tem . To je ena tistih funkcij, ki bo pospešila aplikacijo. Razen seveda, če uporabljate CTE.
Pogosto ugotovim, da novinci v SQL radi uporabljajo CTE; če jih napišete na določen način, se res zdi, kot da pišete nujen program. Osebno sem rad prepisal te poizvedbe, da bi se lahko premikal brez CTE in povečati produktivnost. Zdaj je vse drugače.
PostgreSQL 12 vam omogoča vgradnjo določene vrste CTE brez stranskih učinkov (SELECT), ki se uporabi samo enkrat na koncu zahteve. Če bi spremljal poizvedbe CTE, ki sem jih prepisal, bi jih večina spadala v to kategorijo. To razvijalcem pomaga pri pisanju jasne kode, ki zdaj tudi deluje hitro.
Poleg tega PostgreSQL 12 optimizira samo izvajanje SQL, ne da bi vam bilo treba storiti kar koli. In čeprav mi zdaj verjetno ne bo treba optimizirati takšnih poizvedb, je super, da PostgreSQL še naprej dela na optimizaciji poizvedb.
Just-in-Time (JIT) – zdaj privzeto
V sistemih PostgreSQL 12 s podporo Prevajanje JIT je privzeto omogočeno. Najprej dobite podporo za nekatere notranje operacije in drugič, poizvedbe z izrazi (najenostavnejši primer je x + y) na seznamih izbir (ki jih imate po SELECT), agregati, izrazi s členi WHERE in drugi lahko uporabljajo JIT za izboljšanje zmogljivosti.
Ker je JIT privzeto omogočen v PostgreSQL 12, se bo zmogljivost izboljšala sama od sebe, vendar priporočam, da preizkusite aplikacijo v PostgreSQL 11, ki je predstavil JIT, da izmerite zmogljivost poizvedb in ugotovite, ali morate kaj prilagoditi.
Kaj pa ostale nove funkcije v PostgreSQL 12?
PostgreSQL 12 ima ogromno kul novih funkcij, od zmožnosti pregleda podatkov JSON z uporabo standardnih izrazov poti SQL/JSON do večfaktorske avtentikacije s parametrom clientcert=verify-full, ustvarili stolpce in še veliko več. Dovolj za ločeno objavo.
Tako kot PostgreSQL 10 bo tudi PostgreSQL 12 izboljšal splošno zmogljivost takoj po nadgradnji. Seveda imate lahko svojo pot – preizkusite aplikacijo pod podobnimi pogoji na produkcijskem sistemu, preden omogočite izboljšave, kot sem naredil s PostgreSQL 10. Tudi če je PostgreSQL 12 že bolj stabilen, kot sem pričakoval, ne bodite leni pri testiranju aplikacije temeljito preučite, preden jih daste v proizvodnjo.
Vir: www.habr.com