Nadogradnja za lijene: kako PostgreSQL 12 poboljšava performanse

Nadogradnja za lijene: kako PostgreSQL 12 poboljšava performanse

PostgreSQL 12, najnovija verzija "najbolje relacijske baze podataka otvorenog koda na svijetu", izlazi za nekoliko tjedana (ako sve bude išlo po planu). Ovo slijedi uobičajeni raspored izdavanja nove verzije s hrpom novih značajki jednom godišnje, i iskreno, to je impresivno. Zato sam postao aktivan član PostgreSQL zajednice.

Po mom mišljenju, za razliku od prethodnih izdanja, PostgreSQL 12 ne sadrži jednu ili dvije revolucionarne značajke (poput particioniranja ili paralelizma upita). Jednom sam se našalio da je glavna značajka PostgreSQL 12 veća stabilnost. Nije li to ono što vam treba kada upravljate ključnim podacima za svoje poslovanje?

Ali PostgreSQL 12 tu ne staje: s novim značajkama i poboljšanjima, aplikacije će raditi bolje, i sve što trebate učiniti je nadograditi!

(Pa, možda ponovno izgraditi indekse, ali u ovom izdanju to nije tako strašno kao što smo navikli.)

Bit će sjajno nadograditi PostgreSQL i odmah uživati ​​u značajnim poboljšanjima bez nepotrebne muke. Prije nekoliko godina pregledao sam nadogradnju s PostgreSQL 9.4 na PostgreSQL 10 i vidio kako se aplikacija ubrzala zahvaljujući poboljšanom paralelizmu upita u PostgreSQL 10. I, što je najvažnije, od mene se nije tražilo gotovo ništa (samo postavi konfiguracijski parametar max_parallel_workers).

Slažem se, zgodno je kada aplikacije rade bolje odmah nakon nadogradnje. I jako se trudimo zadovoljiti korisnike, jer ih PostgreSQL ima sve više i više.

Dakle, kako vas jednostavna nadogradnja na PostgreSQL 12 može usrećiti? Sad ću ti reći.

Glavna poboljšanja indeksiranja

Bez indeksiranja, baza podataka neće daleko stići. Kako inače možete brzo pronaći informacije? PostgreSQL-ov temeljni sustav indeksiranja zove se B-stablo. Ova vrsta indeksa je optimizirana za sustave pohrane.

Jednostavno koristimo operator CREATE INDEX ON some_table (some_column), a PostgreSQL puno radi kako bi indeks bio ažuran dok neprestano umećemo, ažuriramo i brišemo vrijednosti. Sve radi samo od sebe, kao čarolijom.

Ali PostgreSQL indeksi imaju jedan problem - oni su napuhani i zauzimaju dodatni prostor na disku i smanjuju performanse dohvaćanja i ažuriranja podataka. Pod "napuhnutim" mislim na neučinkovito održavanje strukture indeksa. To može - ali ne mora - biti povezano s torkama smeća koje uklanja VAKUUM (hvala Peteru Gaghanu na informacijama)Peter Geoghegan)). Povećanje indeksa posebno je vidljivo u radnim opterećenjima gdje se indeks aktivno mijenja.

PostgreSQL 12 uvelike poboljšava performanse indeksa B-stabla, a eksperimenti s mjerilima poput TPC-C pokazali su da se sada u prosjeku koristi 40% manje prostora. Sada trošimo manje vremena ne samo na održavanje indeksa B-stabla (to jest, na operacije pisanja), već i na dohvaćanje podataka, jer su indeksi puno manji.

Aplikacije koje aktivno ažuriraju svoje tablice - obično OLTP aplikacije (obrada transakcija u stvarnom vremenu) - koristit će disk i puno učinkovitije obrađivati ​​zahtjeve. Što je više prostora na disku, to baza podataka ima više prostora za rast bez nadogradnje infrastrukture.

Neke strategije nadogradnje zahtijevaju ponovnu izgradnju indeksa B-stabla kako bi se iskoristile te prednosti (npr. pg_upgrade neće automatski ponovno izgraditi indekse). U prethodnim verzijama PostgreSQL-a, ponovna izgradnja velikih indeksa na tablicama rezultirala je značajnim zastojem jer se u međuvremenu nisu mogle izvršiti promjene. Ali PostgreSQL 12 ima još jednu zgodnu značajku: sada možete ponovno graditi indekse paralelno s naredbom REINDEXIRANJE ISTODOBNOkako biste u potpunosti izbjegli zastoje.

Postoje i druga poboljšanja infrastrukture indeksiranja u PostgreSQL 12. Još jedna stvar u kojoj je bilo magije - zapisnik unaprijed, poznat i kao WAL (dnevnik pisanja unaprijed). Dnevnik pisanja unaprijed bilježi svaku transakciju u PostgreSQL u slučaju kvara i replikacije. Aplikacije ga koriste za arhiviranje i oporavak u određenom trenutku. Naravno, zapisnik pisanja unaprijed zapisuje se na disk, što može utjecati na performanse.

PostgreSQL 12 smanjio je opterećenje WAL zapisa koje kreiraju GiST, GIN i SP-GiST indeksi tijekom konstrukcije indeksa. Ovo pruža nekoliko opipljivih prednosti: WAL zapisi zauzimaju manje prostora na disku, a podaci se reproduciraju brže, primjerice tijekom oporavka od katastrofe ili oporavka u određenom trenutku. Ako koristite takve indekse u svojim aplikacijama (na primjer, geoprostorne aplikacije temeljene na PostGIS-u često koriste GiST indeks), ovo je još jedna značajka koja će značajno poboljšati iskustvo bez ikakvog napora s vaše strane.

Particioniranje - veće, bolje, brže

Predstavljen PostgreSQL 10 deklarativno particioniranje. U PostgreSQL 11 postao je mnogo lakši za korištenje. U PostgreSQL 12 možete promijeniti veličinu odjeljaka.

U PostgreSQL 12, izvedba sustava particioniranja postala je znatno bolja, pogotovo ako u tablici ima tisuće particija. Na primjer, ako upit utječe na samo nekoliko particija u tablici s tisućama njih, izvršit će se puno brže. Izvedba nije poboljšana samo za ove vrste upita. Također ćete primijetiti koliko su brže operacije INSERT na tablicama s više particija.

Snimanje podataka pomoću KOPIRATI - usput, ovo je sjajan način skupno preuzimanje podataka a evo i primjera primanje JSON-a — particionirane tablice u PostgreSQL 12 također su postale učinkovitije. Uz COPY sve je već bilo brzo, ali u PostgreSQL 12 apsolutno leti.

Zahvaljujući ovim prednostima, PostgreSQL vam omogućuje pohranu čak i većih skupova podataka i olakšava njihovo dohvaćanje. I bez truda s vaše strane. Ako aplikacija ima mnogo particija, kao što je snimanje vremenskih nizova podataka, jednostavna nadogradnja značajno će poboljšati njenu izvedbu.

Iako ovo nije baš poboljšanje "nadogradi i uživaj", PostgreSQL 12 omogućuje stvaranje stranih ključeva koji referenciraju particionirane tablice, čineći particioniranje užitkom za rad.

WITH upitima upravo je postalo puno bolje

Kada primijenjena je zakrpa za ugrađene izraze zajedničke tablice (aka CTE, ili WITH upitima), jedva sam čekao da napišem članak o tome koliko su bili sretni programeri aplikacija s PostgreSQL-om. Ovo je jedna od onih značajki koje će ubrzati aplikaciju. Osim, naravno, ako ne koristite CTE.

Često otkrijem da početnici u SQL-u vole koristiti CTE-ove; ako ih napišete na određeni način, stvarno se čini kao da pišete imperativ program. Osobno sam volio prepisivati ​​ove upite kako bih se snašao bez CTE i povećati produktivnost. Sada je sve drugačije.

PostgreSQL 12 omogućuje vam da ugradite određenu vrstu CTE-a bez nuspojava (SELECT), koji se koristi samo jednom pred kraj zahtjeva. Kad bih pratio CTE upite koje sam prepisao, većina bi ih spadala u ovu kategoriju. To pomaže razvojnim programerima da napišu jasan kod koji sada također radi brzo.

Štoviše, PostgreSQL 12 optimizira samo izvršavanje SQL-a, a da vi ne morate ništa učiniti. I premda sada vjerojatno neću morati optimizirati takve upite, super je što PostgreSQL nastavlja raditi na optimizaciji upita.

Just-in-Time (JIT) - sada zadano

Na PostgreSQL 12 sustavima s podrškom LLVM JIT kompilacija je omogućena prema zadanim postavkama. Prije svega, dobivate podršku JIT za neke interne operacije, i drugo, upiti s izrazima (najjednostavniji primjer je x + y) u popisima odabira (koje imate nakon SELECT), agregati, izrazi s klauzulama WHERE i drugi mogu koristiti JIT za poboljšanje performansi.

Budući da je JIT omogućen prema zadanim postavkama u PostgreSQL-u 12, izvedba će se poboljšati sama od sebe, ali preporučujem da testirate aplikaciju u PostgreSQL-u 11, koji je uveo JIT, kako biste izmjerili izvedbu upita i vidjeli trebate li nešto podesiti.

Što je s ostalim novim značajkama u PostgreSQL 12?

PostgreSQL 12 ima gomilu cool novih značajki, od mogućnosti ispitivanja JSON podataka korištenjem standardnih SQL/JSON izraza rute do višefaktorske provjere autentičnosti s parametrom clientcert=verify-full, kreirao kolumne i još mnogo toga. Dovoljno za poseban post.

Kao i PostgreSQL 10, PostgreSQL 12 će poboljšati ukupne performanse odmah nakon nadogradnje. Vi, naravno, možete imati svoj vlastiti put - testirajte aplikaciju pod sličnim uvjetima na proizvodnom sustavu prije nego omogućite poboljšanja, kao što sam ja učinio s PostgreSQL 10. Čak i ako je PostgreSQL 12 već stabilniji nego što sam očekivao, nemojte biti lijeni u testiranju aplikacije temeljito, prije nego što ih pustite u proizvodnju.

Izvor: www.habr.com

Dodajte komentar