, cea mai recentă versiune a „cea mai bună bază de date relațională open source din lume”, va apărea în câteva săptămâni (dacă totul decurge conform planului). Aceasta urmează programul obișnuit de lansare a unei noi versiuni cu o mulțime de funcții noi o dată pe an și, sincer, 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ă caracteristici revoluționare (cum ar fi partiționarea sau paralelismul de interogări). Am glumit odată că principala caracteristică a PostgreSQL 12 este o mai mare stabilitate. Nu de asta aveți nevoie atunci când gestionați datele critice ale afacerii dvs.?
Dar PostgreSQL 12 nu se oprește aici: cu noi funcții și îmbunătățiri, aplicațiile vor funcționa mai bine, și tot ce trebuie să faci este să faci upgrade!
(Ei bine, poate reconstruiți indecșii, dar în această versiune nu este atât de înfricoșător pe cât ne-am obișnuit.)
Va fi grozav să actualizați PostgreSQL și să vă bucurați imediat de îmbunătățiri semnificative fără agitație inutilă. Acum câțiva ani, am revizuit o actualizare de la PostgreSQL 9.4 la PostgreSQL 10 și am văzut cum aplicația sa accelerat datorită paralelismului îmbunătățit al interogărilor din PostgreSQL 10. Și, cel mai important, aproape nimic nu mi-a fost cerut (doar setați un parametru de configurare). max_parallel_workers).
De acord, este convenabil când aplicațiile funcționează mai bine imediat după o actualizare. Și încercăm din greu să mulțumim utilizatorii, deoarece PostgreSQL are din ce în ce mai mulți dintre ei.
Deci, cum vă poate face fericit un simplu upgrade la PostgreSQL 12? Vă spun acum.
Îmbunătățiri majore de indexare
Fără indexare, o bază de date nu va merge departe. Cum altfel poți găsi rapid informații? Sistemul de indexare fundamental al PostgreSQL este numit . Acest tip de index este optimizat pentru sistemele de stocare.
Pur și simplu folosim operatorul CREATE INDEX ON some_table (some_column), iar PostgreSQL face mult de lucru pentru a menține indexul la zi în timp ce inserăm, actualizăm și ștergem constant valori. Totul funcționează de la sine, ca prin magie.
Dar indexurile PostgreSQL au o problemă - ei și ocupă spațiu suplimentar pe disc și reduc performanța de recuperare și actualizare a datelor. Prin „umflare” mă refer la menținerea ineficientă a structurii indexului. Acest lucru poate - sau nu - să fie legat de tuplurile de gunoi pe care le elimină (mulțumesc lui Peter Gaghan pentru informații))). Balonarea indexului este vizibilă în special în sarcinile de lucru în care indicele se schimbă în mod activ.
PostgreSQL 12 îmbunătățește foarte mult performanța indicilor B-tree, iar experimentele cu benchmark-uri precum TPC-C au arătat că acum este utilizat în medie cu 40% mai puțin spațiu. Acum petrecem mai puțin timp nu doar pentru menținerea indicilor B-tree (adică operațiunilor de scriere), ci și pentru preluarea datelor, deoarece indicii sunt mult mai mici.
Aplicații care își actualizează în mod activ tabelele - de obicei aplicații OLTP () - va folosi discul și va procesa cererile mult mai eficient. Cu cât este mai mult spațiu pe disc, cu atât mai mult spațiu are baza de date pentru a crește fără a actualiza infrastructura.
Unele strategii de actualizare necesită reconstruirea indicilor B-tree pentru a profita de aceste beneficii (de ex. nu va reconstrui automat indicii). În versiunile anterioare de PostgreSQL, reconstruirea indecșilor mari pe tabele a dus la un timp de nefuncționare semnificativ, deoarece între timp nu s-au putut face modificări. Dar PostgreSQL 12 are o altă caracteristică grozavă: acum puteți reconstrui indecși în paralel cu comanda pentru a evita complet timpul de nefuncţionare.
Există și alte îmbunătățiri ale infrastructurii de indexare în PostgreSQL 12. Un alt lucru în care era ceva magie - , alias WAL (jurnal de scriere înainte). Un jurnal de scriere anticipată înregistrează fiecare tranzacție în PostgreSQL în caz de eșec și replicare. Aplicațiile îl folosesc pentru arhivare și . Desigur, jurnalul de scriere anticipată este scris pe disc, ceea ce poate afecta performanța.
PostgreSQL 12 a redus supraîncărcarea înregistrărilor WAL care sunt create de indecșii GiST, GIN și SP-GiST în timpul construcției indexului. Acest lucru oferă mai multe beneficii tangibile: înregistrările WAL ocupă mai puțin spațiu pe disc, iar datele sunt redate mai rapid, cum ar fi în timpul recuperării în caz de dezastru sau al recuperării la un moment dat. Dacă utilizați astfel de indici în aplicațiile dvs. (de exemplu, aplicațiile geospațiale bazate pe PostGIS folosesc foarte mult indexul GiST), aceasta este o altă caracteristică care va îmbunătăți semnificativ experiența fără niciun efort din partea dvs.
Partiționare - mai mare, mai bună, mai rapidă
PostgreSQL 10 a fost introdus . În PostgreSQL 11 a devenit mult mai ușor de utilizat. În PostgreSQL 12 puteți schimba scara secțiunilor.
În PostgreSQL 12, performanța sistemului de partiționare a devenit semnificativ mai bună, mai ales dacă există mii de partiții în tabel. De exemplu, dacă o interogare afectează doar câteva partiții dintr-un tabel cu mii de ele, se va executa mult mai rapid. Performanța nu este îmbunătățită doar pentru aceste tipuri de interogări. Veți observa, de asemenea, cât de rapide sunt operațiunile INSERT pe tabele cu mai multe partiții.
Înregistrarea datelor folosind - apropo, aceasta este o modalitate grozavă si iata un exemplu — tabelele partiționate din PostgreSQL 12 au devenit, de asemenea, mai eficiente. Cu COPY totul era deja rapid, dar în PostgreSQL 12 zboară absolut.
Datorită acestor avantaje, PostgreSQL vă permite să stocați seturi de date și mai mari și să le faceți mai ușor de preluat. Și fără efort din partea ta. Dacă aplicația are multe partiții, cum ar fi înregistrarea datelor din seria temporală, o simplă actualizare îi va îmbunătăți semnificativ performanța.
Deși aceasta nu este tocmai o îmbunătățire „upgrade și bucurați-vă”, PostgreSQL 12 vă permite să creați chei străine care fac referire la tabele partiționate, făcând partiționarea o plăcere să lucrați.
CU interogări tocmai s-au îmbunătățit mult
Când (aka CTE, aka WITH queries), abia așteptam să scriu un articol despre . Aceasta este una dintre acele caracteristici care vor accelera aplicația. Dacă, desigur, nu utilizați CTE.
De multe ori găsesc că începătorilor în SQL le place să folosească CTE-uri; dacă le scrii într-un anumit fel, chiar simt că ai scrie un program imperativ. Personal, mi-a plăcut să rescriu aceste interogări pentru a ocoli fără CTE și creșterea productivității. Acum totul este diferit.
PostgreSQL 12 vă permite să introduceți un anumit tip de CTE fără efecte secundare (SELECT), care este folosit o singură dată aproape de sfârșitul cererii. Dacă aș ține evidența interogărilor CTE pe care le-am rescris, majoritatea s-ar încadra în această categorie. Acest lucru îi ajută pe dezvoltatori să scrie cod clar, care acum rulează și rapid.
Mai mult, PostgreSQL 12 optimizează execuția SQL în sine, fără ca tu să fii nevoit să faci nimic. Și deși probabil că nu va trebui să optimizez astfel de interogări acum, este grozav că PostgreSQL continuă să lucreze la optimizarea interogărilor.
Just-in-Time (JIT) - acum implicit
Pe sisteme PostgreSQL 12 cu suport Compilarea JIT este activată în mod implicit. În primul rând, primești sprijin pentru unele operații interne și, în al doilea rând, interogări cu expresii (cel mai simplu exemplu este x + y) în listele select (pe care le aveți după SELECT), agregate, expresii cu clauze WHERE și altele pot folosi JIT pentru a îmbunătăți performanța.
Deoarece JIT este activat în mod implicit în PostgreSQL 12, performanța se va îmbunătăți de la sine, dar recomand să testați aplicația în PostgreSQL 11, care a introdus JIT, pentru a măsura performanța interogărilor și a vedea dacă trebuie să reglați ceva.
Dar restul noilor funcții din PostgreSQL 12?
PostgreSQL 12 are o mulțime de caracteristici noi interesante, de la capacitatea de a examina datele JSON folosind expresii de rută SQL/JSON standard până la autentificarea cu mai mulți factori cu un parametru clientcert=verify-full, a creat coloane și multe altele. Suficient pentru o postare separată.
La fel ca PostgreSQL 10, PostgreSQL 12 va îmbunătăți performanța generală imediat după actualizare. Desigur, puteți avea propria cale - testați aplicația în condiții similare pe sistemul de producție înainte de a activa îmbunătățiri, așa cum am făcut cu PostgreSQL 10. Chiar dacă PostgreSQL 12 este deja mai stabil decât mă așteptam, nu fi leneș la testare aplicații cu atenție, înainte de a le lansa în producție.
Sursa: www.habr.com