, najnovije izdanje "najbolje svjetske relacijske baze podataka otvorenog koda", izlazi za nekoliko sedmica (ako sve bude po planu). Ovo prati uobičajeni raspored – nova verzija sa puno novih funkcija izlazi jednom godišnje i, iskreno, impresivna je. Zbog toga sam postao aktivan član PostgreSQL zajednice.
Po mom mišljenju, za razliku od prošlih izdanja, PostgreSQL 12 ne sadrži jednu ili dvije revolucionarne karakteristike (kao što je particioniranje ili paralelizam upita). Jednom sam se našalio da je glavna karakteristika PostgreSQL 12 veća stabilnost. Nije li to ono što vam treba kada upravljate kritičnim podacima vašeg poslovanja?
Ali PostgreSQL 12 nije ograničen na ovo: s novim funkcijama i poboljšanjima, aplikacije će raditi bolje, Sve što trebate učiniti je nadograditi!
(Pa, možda čak i ponovo izgraditi indekse, ali u ovom izdanju to nije tako strašno kao što smo navikli.)
Bilo bi sjajno nadograditi PostgreSQL i odmah uživati u značajnim poboljšanjima bez nepotrebnih pokreta. Prije nekoliko godina analizirao sam nadogradnju sa PostgreSQL 9.4 na PostgreSQL 10 i vidio koliko je aplikacija brža zbog poboljšanog paralelizma upita u PostgreSQL 10. I, što je najvažnije, od mene se gotovo ništa nije tražilo (samo postavim konfiguracijski parametar max_parallel_workers).
Slažem se, zgodno je kada aplikacije bolje rade odmah nakon nadogradnje. I veoma se trudimo da zadovoljimo korisnike, jer ih PostgreSQL ima sve više.
I kako vas jednostavna nadogradnja na PostgreSQL 12 usrećuje? Sad ću ti reći.
Velika poboljšanja indeksiranja
Bez indeksiranja baza podataka neće ići daleko. Kako inače možete brzo pronaći informacije? Poziva se osnovni PostgreSQL sistem indeksiranja . Ovaj tip indeksa je optimizovan za sisteme skladištenja.
Koristimo samo operatera CREATE INDEX ON some_table (some_column), a PostgreSQL odlično radi na održavanju indeksa ažurnim dok mi konstantno ubacujemo, ažuriramo i brišemo vrijednosti. Sve funkcioniše samo po sebi, poput magije.
Ali PostgreSQL indeksi imaju jedan problem - oni i zauzimaju dodatni prostor na disku, a performanse izdvajanja i ažuriranja podataka su smanjene. Pod "naduvavanjem" mislim na neefikasno održavanje strukture indeksa. Ovo može, ali i ne mora biti povezano sa smećem torkama koje (hvala Peteru Gaganu na informacijama))). Nadimanje indeksa je posebno uočljivo u radnim opterećenjima gdje se indeks aktivno mijenja.
PostgreSQL 12 uvelike poboljšava performanse indeksa B-stabla, a eksperimenti sa testovima poput TPC-C pokazali su da se prostor sada koristi, u prosjeku, 40% manje. Sada trošimo manje vremena ne samo na održavanje indeksa B-stabla (tj. operacije pisanja), već i na dohvaćanje podataka, jer su indeksi postali mnogo manji.
Aplikacije koje aktivno ažuriraju svoje tabele su obično OLTP aplikacije () će biti mnogo efikasnije u smislu korištenja diska i obrade upita. Što je više prostora na disku, baza podataka ima više prostora za rast bez nadogradnje infrastrukture.
Neke strategije nadogradnje zahtijevaju da ponovo izgradite indekse B-stabla kako biste iskoristili ove prednosti (na primjer, neće automatski ponovo izgraditi indekse). U prethodnim verzijama PostgreSQL-a, ponovna izgradnja velikih indeksa na tabelama je rezultirala značajnim zastojima jer se tokom tog vremena nisu mogle napraviti nikakve promjene. Ali PostgreSQL 12 ima još jednu sjajnu osobinu: sada možete ponovo izgraditi indekse paralelno sa komandom kako biste u potpunosti izbjegli zastoje.
PostgreSQL 12 ima i druga poboljšanja infrastrukture za indeksiranje. Još jedna stvar u kojoj je bilo neke magije - , aka WAL (log za upisivanje unaprijed). Dnevnik pisanja unaprijed zapisuje svaku transakciju u PostgreSQL u slučaju neuspjeha i replikacije. Aplikacije ga koriste za arhiviranje i . Naravno, zapisnik unaprijed zapisuje se na disk, a to može utjecati na performanse.
PostgreSQL 12 je smanjio troškove WAL zapisa koje kreiraju GiST, GIN i SP-GiST indeksi kada se indeks gradi. Ovo ima nekoliko opipljivih prednosti: WAL zapisi zauzimaju manje prostora na disku, a podaci se reproduciraju brže, kao što je prelazak na grešku ili oporavak u trenutku. Ako koristite takve indekse u svojim aplikacijama (na primjer, geoprostorne aplikacije zasnovane na PostGIS-u dosta koriste GiST indeks), ovo je još jedna karakteristika koja će uvelike poboljšati performanse bez ikakvog napora s vaše strane.
Particioniranje - veće, bolje, brže
Predstavljen PostgreSQL 10 . U PostgreSQL 11 postalo je mnogo lakše za korištenje. U PostgreSQL 12, možete skalirati particije.
U PostgreSQL 12, performanse sistema particioniranja su značajno poboljšane, posebno kada postoje hiljade particija u tabeli. Na primjer, ako upit utiče na samo nekoliko particija u tabeli sa hiljadama njih, on će se izvršavati mnogo brže. Poboljšanja performansi nisu ograničena na ove vrste upita. Također ćete primijetiti koliko su brže INSERT operacije na tablicama s mnogo particija.
Pisanje podataka pomoću - Usput, ovo je odličan način i evo primjera - na particionirane tabele u PostgreSQL 12 je takođe postalo efikasnije. Sve je bilo brzo sa COPY, ali u PostgreSQL 12 potpuno leti.
Ove prednosti omogućavaju PostgreSQL-u da pohrani još veće skupove podataka i olakšava njihovo preuzimanje. I bez truda sa vaše strane. Ako aplikacija ima mnogo sekcija, na primjer, piše podatke o vremenskim serijama, jednostavna nadogradnja će značajno poboljšati njene performanse.
I dok ovo nije baš poboljšanje za nadogradnju i uživanje, u PostgreSQL 12 možete kreirati strane ključeve koji se odnose na particionirane tabele kako bi rad sa particioniranjem bio užitak.
SA upitima je postalo mnogo bolje
Kada (aka CTE, aka WITH queries), žudio sam da napišem članak o tome kako . Ovo je jedna od onih karakteristika koje će ubrzati aplikaciju. Osim ako, naravno, ne koristite CTE.
Često primjećujem da početnici u SQL-u vole koristiti CTE: ako ih napišete na određeni način, osjećate se kao da pišete imperativ program. Lično, volio sam da prepišem ove upite da bih se mogao zaobići bez CTE i povećanje produktivnosti. Sada je sve drugačije.
PostgreSQL 12 vam omogućava da ugradite određeni tip CTE bez nuspojava (SELECT), koji se koristi samo jednom pri kraju zahtjeva. Da sam pratio CTE upite koje sam prepisao, većina njih bi spadala u ovu kategoriju. Ovo pomaže programerima da pišu jasan kod koji je sada i brz.
Štaviše, PostgreSQL 12 optimizuje samo izvršavanje SQL-a, ne morate ništa da radite. Iako sada vjerovatno neću morati optimizirati takve upite, sjajno je što PostgreSQL nastavlja raditi na optimizaciji upita.
Just-in-Time (JIT) - sada je zadana vrijednost
Na PostgreSQL 12 sistemima sa podrškom JIT kompilacija je podrazumevano omogućena. Prvo, dobijate podršku za neke interne operacije, i drugo, upiti s izrazima (najjednostavniji primjer je x + y) na listama odabira (koje imate nakon SELECT), agregatima, izrazima sa WHERE klauzulama i drugi mogu koristiti JIT za poboljšanje performansi.
Pošto je JIT podrazumevano omogućen u PostgreSQL 12, performanse će se poboljšati same po sebi, ali predlažem da testirate aplikaciju u PostgreSQL 11, gde je JIT prvi put uveden, kako biste izmerili performanse upita i videli da li je potrebno nešto podesiti.
Ali šta je sa ostalim novim karakteristikama PostgreSQL 12?
PostgreSQL 12 ima gomilu sjajnih novih funkcija, od mogućnosti pregledavanja JSON podataka korištenjem standardnih SQL/JSON izraza rute do višefaktorske autentifikacije pomoću clientcert=verify-full, generirane kolone i još mnogo toga. Dovoljno za poseban post.
Kao i PostgreSQL 10, PostgreSQL 12 će poboljšati ukupne performanse odmah nakon nadogradnje. Naravno, možete imati svoj način - testirajte aplikaciju pod sličnim uslovima na proizvodnom sistemu pre nego što omogućite poboljšanja, kao što sam uradio sa PostgreSQL 10. Čak i ako je PostgreSQL 12 već stabilniji nego što sam očekivao, nemojte biti lijeni testirati aplikacije pa, prije nego što ih puste u proizvodnju.
izvor: www.habr.com