, L'ultima versione di "a megliu basa di dati relazionale open source di u mondu", esce in un paru di settimane (se tuttu va secondu u pianu). Questu seguita u calendariu abituale di liberazione di una nova versione cù una tonna di funzioni novi una volta à l'annu, è francamente, hè impressiunanti. Hè per quessa chì sò diventatu un membru attivu di a cumunità PostgreSQL.
In u mo parè, à u cuntrariu di e versioni precedenti, PostgreSQL 12 ùn cuntene micca una o duie funzioni rivoluzionarie (cum'è a partizione o u parallelismu di query). Una volta aghju scherzatu chì a funzione principale di PostgreSQL 12 hè una stabilità più grande. Ùn hè micca ciò chì avete bisognu quandu gestisce i dati critichi di a vostra attività?
Ma PostgreSQL 12 ùn si ferma micca quì: cù e funzioni novi è migliurà, l'applicazioni seranu megliu, è tuttu ciò chì duvete fà hè aghjurnà!
(Bè, forse ricustruisce l'indici, ma in questa versione ùn hè micca cusì spaventosa cum'è no simu abituati.)
Serà fantastico per aghjurnà PostgreSQL è gode immediatamente di migliorie significative senza fuss innecessary. Uni pochi anni fà, aghju rivedutu una aghjurnazione da PostgreSQL 9.4 à PostgreSQL 10 è aghju vistu cumu l'applicazione accelerava grazia à u parallelismu di query perfezionatu in PostgreSQL 10. E, più importantemente, quasi nunda ùn era micca necessariu da mè (solu stabilisce un paràmetru di cunfigurazione). max_parallel_workers).
D'accordu, hè cunvenutu quandu l'applicazioni funzionanu megliu immediatamente dopu un aghjurnamentu. E pruvemu assai duru per piace à l'utilizatori, perchè PostgreSQL hà più è più di elli.
Allora cumu si pò fà una semplice aghjurnazione à PostgreSQL 12? Vi dicu avà.
Principali miglioramenti di l'indexazione
Senza indexazione, una basa di dati ùn andarà luntanu. Cumu altrimenti pudete truvà rapidamente informazioni? U sistema di indexazione fundamentale di PostgreSQL hè chjamatu . Stu tipu d'indici hè ottimizatu per i sistemi di almacenamento.
Avemu solu aduprà l'operatore CREATE INDEX ON some_table (some_column), è PostgreSQL faci assai travagliu per mantene l'indici aghjurnatu mentre avemu constantemente inseritu, aghjurnà è sguassate i valori. Tuttu travaglia per sè stessu, cum'è per magia.
Ma l'indici PostgreSQL anu un prublema - elli è occupanu spaziu di discu extra è riduce u rendiment di ricuperazione di dati è aghjurnamentu. Per "bloat" vogliu dì mantene inefficacemente a struttura di l'indici. Questu pò - o ùn pò micca - esse ligatu à i tuppi di basura chì sguassate (ringraziu à Peter Gaghan per l'infurmazioni))). Index bloat hè soprattuttu notevuli in carichi di travagliu induve l'indici hè attivamente cambiante.
PostgreSQL 12 migliurà assai u rendiment di l'indici B-tree, è l'esperimenti cù benchmarks cum'è TPC-C anu dimustratu chì in media 40% menu spaziu hè ora utilizatu. Avà passamu menu tempu micca solu per mantene l'indici B-tree (vale à dì, nantu à l'operazioni di scrittura), ma ancu per ricuperà e dati, perchè l'indici sò assai più chjuchi.
Applicazioni chì aghjurnà attivamente e so tabelle - tipicamente applicazioni OLTP () - aduprà u discu è e dumande di prucessu assai più efficace. U più spaziu di discu, più spaziu a basa di dati hà da cresce senza aghjurnà l'infrastruttura.
Alcune strategie di aghjurnamentu necessitanu di ricustruisce l'indici B-tree per prufittà di sti benefici (p.e. ùn ricustruisce micca l'indici automaticamente). In versioni precedenti di PostgreSQL, a ricustruzzione di grandi indici nantu à e tavule hà risultatu in tempi di inattività significativu perchè i cambiamenti ùn puderanu micca esse fatti intantu. Ma PostgreSQL 12 hà una altra funzione fantastica: avà pudete ricustruisce indici in parallelu cù u cumandamentu per evità completamente i tempi di inattività.
Ci sò altre migliure à l'infrastruttura di indexazione in PostgreSQL 12. Un'altra cosa induve ci era qualchì magia - , alias WAL (registru di scrittura anticipata). U logu di scrittura anticipata registra ogni transazzione in PostgreSQL in casu di fallimentu è replicazione. L'applicazioni l'utilizanu per l'archiviazione è . Di sicuru, u logu di scrittura in anticipu hè scrittu à u discu, chì pò influenzà u rendiment.
PostgreSQL 12 hà riduciutu l'overhead di i registri WAL chì sò creati da l'indici GiST, GIN è SP-GiST durante a custruzzione di l'indici. Questu furnisce parechji benefici tangibili: i registri WAL occupanu menu spaziu di discu, è e dati sò riproduci più rapidamente, cum'è durante a ricuperazione di disastru o a ricuperazione puntuale. Se utilizate tali indici in e vostre applicazioni (per esempiu, l'applicazioni geospaziali basate in PostGIS utilizanu assai l'indici GiST), questa hè una altra funzione chì migliurà significativamente l'esperienza senza alcunu sforzu da a vostra parte.
Partitioning - più grande, megliu, più veloce
PostgreSQL 10 introduttu . In PostgreSQL 11 hè diventatu assai più faciule d'utilizà. In PostgreSQL 12, pudete cambià a scala di e sezioni.
In PostgreSQL 12, u funziunamentu di u sistema di partizione hè diventatu significativamente megliu, soprattuttu s'ellu ci sò millaie di partizioni in a tavula. Per esempiu, se una dumanda affetta solu uni pochi di partizioni in una tavula cù millaie di elli, eseguirà assai più veloce. U rendiment ùn hè micca solu migliuratu per questi tipi di dumande. Avete nutatu ancu quantu l'operazione INSERT sò più veloci nantu à e tavule cù parechje partizioni.
A registrazione di dati utilizendu - per via, questu hè un grande modu è quì hè un esempiu - e tabelle partizionate in PostgreSQL 12 sò ancu diventate più efficaci. Cù COPY tuttu era digià veloce, ma in PostgreSQL 12 vola assolutamente.
Grazie à questi vantaghji, PostgreSQL permette di almacenà insemi di dati ancu più grande è facenu più faciuli di ricuperà. È senza sforzu da a vostra parte. Se l'applicazione hà parechje partizioni, cum'è a registrazione di dati di serie temporale, un aghjurnamentu simplice hà da migliurà significativamente u so rendiment.
Mentre chì questu ùn hè micca esattamente un "aghjurnà è gode", PostgreSQL 12 permette di creà chjavi stranieri chì riferite à e tabelle partizionate, facendu a particionazione un piacè di travaglià.
CU e dumande sò solu assai megliu
Quandu (aka CTE, aka WITH queries), ùn pudia aspittà di scrive un articulu circa . Questa hè una di queste caratteristiche chì accelerà l'applicazione. A menu chì, sicuru, utilizate CTE.
Spessu mi pare chì i principianti di SQL amanu aduprà CTE, se li scrivite in una certa manera, si senti veramente chì scrive un prugramma imperativu. In modu persunale, mi piaceva riscrive queste dumande per andà in giro senza CTE è aumentà a produtividade. Avà tuttu hè diversu.
PostgreSQL 12 permette di inlineà un tipu specificu di CTE senza effetti secundari (SELECT), chì hè utilizatu solu una volta vicinu à a fine di a dumanda. Se aghju seguitu e dumande CTE ch'e aghju scrittu, a maiò parte di elli cascanu in questa categuria. Questu aiuta i sviluppatori à scrive un codice chjaru chì avà corre ancu rapidamente.
Inoltre, PostgreSQL 12 ottimizza l'esekzione SQL stessu, senza avè da fà nunda. E ancu s'ellu ùn aghju micca bisognu di ottimisà tali dumande avà, hè grande chì PostgreSQL cuntinueghja à travaglià nantu à l'ottimisazione di e dumande.
Just-in-Time (JIT) - avà predeterminatu
Nantu à i sistemi PostgreSQL 12 cù supportu A compilazione JIT hè attivata per difettu. Prima di tuttu, avete u sustegnu per certi operazioni internu, è in segundu, dumande cù espressioni (l'esempiu più simplice hè x + y) in listi selezziunati (chì avete dopu à SELECT), aggregati, espressioni cù clause WHERE è altri ponu utilizà JIT per migliurà u rendiment.
Siccomu JIT hè attivatu per difettu in PostgreSQL 12, u rendiment hà da migliurà per sè stessu, ma ricumandemu di pruvà l'applicazione in PostgreSQL 11, chì hà introduttu JIT, per misurà u rendiment di a dumanda è vede s'ellu avete bisognu di sintonizà qualcosa.
Chì ci hè u restu di e funzioni novi in PostgreSQL 12?
PostgreSQL 12 hà una tonna di funzioni novi interessanti, da a capacità di esaminà e dati JSON utilizendu espressioni di rotte standard SQL / JSON à l'autentificazione multifattore cun un paràmetru. clientcert=verify-full, culonni creatu è assai di più. Basta per un postu separatu.
Cum'è PostgreSQL 10, PostgreSQL 12 migliurà u rendiment generale immediatamente dopu l'aghjurnamentu. Di sicuru, pudete avè u vostru propiu percorsu - pruvate l'applicazione in cundizioni simili nantu à u sistema di produzzione prima di attivà i migliori, cum'è aghju fattu cù PostgreSQL 10. Ancu s'è PostgreSQL 12 hè digià più stabile di ciò chì m'aspittava, ùn sia micca pigra in a prova. appiicazioni accuratamente, prima di liberà in a produzzione.
Source: www.habr.com