, ultima versiune a „cele mai bune baze de date relaționale din lume cu cod sursă deschis” va fi lansată în aproximativ două sau trei săptămâni (dacă totul decurge conform planului). Aceasta se aliniază cu programul obișnuit — o nouă versiune cu o mulțime de noi funcționalități este lansată o dată pe an și, să fim sinceri, este impresionant. De aceea am devenit un membru activ al comunității PostgreSQL.
În opinia mea, spre deosebire de versiunile anterioare, PostgreSQL 12 nu conține una sau două funcții revoluționare (precum, de exemplu, partiționarea sau paralelismul interogărilor). Am glumit odată că principala caracteristică a PostgreSQL 12 este stabilitatea crescută. Și, nu este acest lucru necesar atunci când gestionezi date critice pentru afacerea ta?
Însă PostgreSQL 12 nu se oprește aici: cu noile funcționalități și îmbunătățiri, aplicațiile vor funcționa mai bine, iar de la tine se cere doar să faci un upgrade!
(Poate, ar trebui să reconstruiești indexurile, dar în această versiune nu este la fel de complicat cum eram obișnuiți.)
Ar fi grozav — să faci upgrade la PostgreSQL și să te bucuri imediat de îmbunătățiri semnificative fără prea multe eforturi. Cu câțiva ani în urmă, am analizat actualizarea de la PostgreSQL 9.4 la PostgreSQL 10 și am observat cum aplicația a accelerat datorită îmbunătățirii paralelismului interogărilor în PostgreSQL 10. Și, cel mai important, nu mi s-a cerut aproape nimic (doar să setez parametrul de configurare max_parallel_workers).
Este convenabil, nu-i așa, când aplicațiile funcționează mai bine imediat după upgrade. Și ne străduim foarte mult să încântăm utilizatorii, deoarece la PostgreSQL numărul lor crește constantly.
Și cum va face un simplu upgrade la PostgreSQL 12 să fii fericit? Îți voi explica acum.
Îmbunătățiri serioase ale indexării
Fără indexare, baza de date nu va merge prea departe. Cum altfel să găsim rapid informațiile? Sistemul fundamental de indexare PostgreSQL se numește . Acest tip de index este optimizat pentru sistemele de stocare.
Folosim pur și simplu operatorul CREATE INDEX ON some_table (some_column), iar PostgreSQL face toată munca grea pentru a menține indexul actualizat, în timp ce noi continuăm să inserăm, actualizăm și să eliminăm valori. Totul funcționează de la sine, ca prin magie.
Dar indexurile PostgreSQL au o problemă — ele și ocupă spațiu inutil pe disc, iar performanța extragerii și actualizării datelor scade. Prin „umflare” mă refer la menținerea ineficientă a structurii indexului. Aceasta poate fi — dar nu trebuie să fie — legată de tuplurile de gunoi care sunt eliminate (mulțumiri pentru informații lui Peter Geoghegan ()). Umflarea indexului este deosebit de evidentă în sarcinile de lucru în care indexul este modificat activ.
PostgreSQL 12 îmbunătățește semnificativ funcționarea indicilor de tip B-tree, iar experimentele cu teste de tip TPC-C au arătat că acum se folosește, în medie, cu 40% mai puțin spațiu. Acum consumăm mai puțin timp nu doar pentru întreținerea indicilor de tip B-tree (adică pentru operațiile de scriere), ci și pentru extragerea datelor, deoarece indicii au devenit mult mai mici.
Aplicațiile care își actualizează activ tabelele — de obicei sunt aplicații OLTP () — vor utiliza mult mai eficient discul și vor prelucra cererile. Cu cât este mai mult spațiu pe disc, cu atât baza de date are mai multă capacitate de creștere fără a upgradui infrastructura.
Anumite strategii de upgrade necesită reconstruirea indicilor de tip B-tree pentru a profita de aceste avantaje (de exemplu, nu va reconstrui indicii automat). În versiunile anterioare de PostgreSQL, reconstruirea indicilor mari în tabele ducea la timp de nefuncționare semnificativ, deoarece în acest timp nu se puteau face modificări. Dar în PostgreSQL 12 există o altă caracteristică interesantă: acum se pot reconstrui indicii în paralel cu comanda , pentru a evita complet nefuncționarea.
În PostgreSQL 12 există și alte îmbunătățiri ale infrastructurii de indexare. O altă chestiune, unde nu au lipsit trucurile, este , cunoscut și sub denumirea de WAL (write-ahead log). Jurnalul de scriere anticipată înregistrează fiecare tranzacție din PostgreSQL pentru cazul unei defecțiuni și pentru replicare. Aplicațiile îl folosesc pentru arhivare și . Desigur, jurnalul de scriere anticipată este scris pe disc, ceea ce poate afecta performanța.
În PostgreSQL 12, costurile înregistrărilor WAL create de indecșii GiST, GIN și SP-GiST la construirea unui index au fost reduse. Aceasta oferă câteva avantaje semnificative: înregistrările WAL ocupă mai puțin spațiu pe disc, iar datele sunt reproduceți mai repede, de exemplu, în timpul recuperării după o defecțiune sau a restaurării la un moment dat. Dacă utilizați astfel de indecși în aplicațiile dvs. (de exemplu, aplicațiile geospațiale bazate pe PostGIS folosesc mult indexul GiST), aceasta este o altă funcționalitate care va îmbunătăți semnificativ performanța fără a necesita eforturi din partea dvs.
Partiționarea — mai mult, mai bine, mai rapid
În PostgreSQL 10 a apărut . În PostgreSQL 11, a devenit mult mai ușor de utilizat. În PostgreSQL 12, se poate schimba scala secțiunilor.
În PostgreSQL 12, performanța sistemului de partiționare a devenit semnificativ mai bună, mai ales dacă în tabel există mii de secțiuni. De exemplu, dacă o interogare afectează doar câteva secțiuni într-un tabel cu mii de secțiuni, va fi executată mult mai repede. Performanța a fost îmbunătățită nu doar pentru acest tip de interogări. Veți observa, de asemenea, cât de mult s-au accelerat operațiile INSERT în tabelele cu multe secțiuni.
Încărcarea datelor prin — de altfel, este o modalitate excelentă și iată un exemplu — în tabelele partiționate din PostgreSQL 12 a devenit, de asemenea, mai eficient. Cu COPY era deja rapid, iar în PostgreSQL 12 este pur și simplu fulgerător.
Datorită acestor avantaje, în PostgreSQL pot fi stocate seturi de date și mai mari, iar extragerea lor a devenit mai simplă. Și fără niciun efort din partea dvs. Dacă aplicația are multe secțiuni, de exemplu, aceasta înregistrează date de serii temporale, o simplă actualizare va îmbunătăți semnificativ performanța sa.
Și deși această îmbunătățire nu face parte din categoria „am actualizat și ne bucurăm”, în PostgreSQL 12, se pot crea chei externe care fac referire la tabelele partiționate, astfel încât lucrul cu partiționarea să fie o plăcere.
Interogările WITH au devenit mult mai bune
Când (de asemenea, CTE, cunoscute și sub numele de interogări WITH), abia așteptam să scriu un articol despre asta, . Aceasta este una dintre acele caracteristici care vor accelera aplicația. Dacă, desigur, folosiți CTE.
Observ că adesea începătorii în SQL iubesc să folosească CTE: dacă le scrii într-un anumit mod, simți că scrii un program imperativ. Personal, îmi plăcea să rescriu aceste interogări pentru a le face fără CTE și pentru a crește performanța. Acum, lucrurile stau altfel.
PostgreSQL 12 permite încorporarea unui anumit tip de CTE fără efecte secundare (SELECT), care este folosit o singură dată, mai aproape de finalul interogării. Dacă aș fi ținut statistici cu interogările CTE pe care le-am rescris, majoritatea ar fi intrat în această categorie. Acest lucru ajută dezvoltatorii să scrie un cod clar, care acum funcționează și rapid.
Mai mult, PostgreSQL 12 optimizează executarea SQL singur, nu va trebui să faci nimic. Și deși acum probabil nu voi mai avea nevoie să optimizăm astfel de interogări, e minunat că PostgreSQL continuă să lucreze la optimizarea interogărilor.
Just-in-Time (JIT) — acum este activat în mod implicit
În sistemele PostgreSQL 12 cu suport pentru compilarea JIT este activată în mod implicit. În primul rând, obții suport pentru pentru unele operațiuni interne, iar în al doilea rând, interogările cu expresii (cel mai simplu exemplu — x + y) din listele de selecție (care sunt după SELECT), agregate, expresii cu clauze WHERE și altele pot folosi JIT pentru a îmbunătăți performanța.
Dat fiind că JIT este activat în PostgreSQL 12 în mod implicit, performanța se va îmbunătăți de la sine, dar îți recomand să testezi aplicația în PostgreSQL 11, unde JIT a apărut pentru prima dată, pentru a măsura performanța interogărilor și a afla dacă trebuie să ajustezi ceva.
Dar ce zici de celelalte caracteristici noi din PostgreSQL 12?
PostgreSQL 12 are o mulțime de caracteristici noi interesante — de la posibilitatea de a explora datele JSON folosind expresii SQL/JSON standard până la autentificarea multi-factor cu parametru clientcert=verify-full, coloane generate și multe altele. E suficient pentru un post separat.
Ca și PostgreSQL 10, PostgreSQL 12 va îmbunătăți performanța generală imediat după upgrade. Desigur, poți avea propria ta metodă — testează aplicația în condiții similare în sistemul de producție înainte de a activa îmbunătățirile, așa cum am făcut eu cu PostgreSQL 10. Chiar dacă PostgreSQL 12 este deja mai stabil decât mă așteptam, nu te lenevi să testezi aplicațiile cu atenție înainte de a le lansa în producție.
Sursa: habr.com
