, l'ultima versione del "miglior database relazionale open source al mondo" uscirà tra un paio di settimane (se tutto va secondo i piani). Questo segue il consueto programma di rilascio di una nuova versione con tantissime nuove funzionalità una volta all'anno e, francamente, è impressionante. Ecco perché sono diventato un membro attivo della comunità PostgreSQL.
A mio parere, a differenza delle versioni precedenti, PostgreSQL 12 non contiene una o due funzionalità rivoluzionarie (come il partizionamento o il parallelismo delle query). Una volta ho scherzato dicendo che la caratteristica principale di PostgreSQL 12 è una maggiore stabilità. Non è quello che ti serve quando gestisci i dati critici della tua azienda?
Ma PostgreSQL 12 non si ferma qui: con nuove funzionalità e miglioramenti, le applicazioni funzioneranno meglio, e tutto ciò che devi fare è aggiornare!
(Beh, forse ricostruire gli indici, ma in questa versione non è così spaventoso come siamo abituati.)
Sarà fantastico aggiornare PostgreSQL e godere immediatamente di miglioramenti significativi senza inutili complicazioni. Qualche anno fa, ho esaminato un aggiornamento da PostgreSQL 9.4 a PostgreSQL 10 e ho visto come l'applicazione è stata velocizzata grazie al miglioramento del parallelismo delle query in PostgreSQL 10. E, cosa più importante, non mi è stato richiesto quasi nulla (basta impostare un parametro di configurazione max_parallel_workers).
D'accordo, è conveniente quando le applicazioni funzionano meglio subito dopo un aggiornamento. E facciamo del nostro meglio per accontentare gli utenti, perché PostgreSQL ne ha sempre di più.
Quindi, come può un semplice aggiornamento a PostgreSQL 12 renderti felice? Te lo dirò adesso.
Importanti miglioramenti dell'indicizzazione
Senza indicizzazione, un database non andrà lontano. In quale altro modo puoi trovare rapidamente informazioni? Il sistema di indicizzazione fondamentale di PostgreSQL si chiama . Questo tipo di indice è ottimizzato per i sistemi di archiviazione.
Usiamo semplicemente l'operatore CREATE INDEX ON some_table (some_column)e PostgreSQL fa molto lavoro per mantenere aggiornato l'indice mentre inseriamo, aggiorniamo ed eliminiamo costantemente valori. Tutto funziona da solo, come per magia.
Ma gli indici PostgreSQL hanno un problema: loro e occupano spazio aggiuntivo su disco e riducono le prestazioni di recupero e aggiornamento dei dati. Per "gonfiamento" intendo il mantenimento inefficace della struttura dell'indice. Ciò potrebbe, o meno, essere correlato alle tuple spazzatura che rimuove (grazie a Peter Gaghan per l'informazione))). Il rigonfiamento dell'indice è particolarmente evidente nei carichi di lavoro in cui l'indice cambia attivamente.
PostgreSQL 12 migliora notevolmente le prestazioni degli indici B-tree e esperimenti con benchmark come TPC-C hanno dimostrato che in media viene ora utilizzato il 40% di spazio in meno. Ora dedichiamo meno tempo non solo al mantenimento degli indici dell'albero B (ovvero alle operazioni di scrittura), ma anche al recupero dei dati, perché gli indici sono molto più piccoli.
Applicazioni che aggiornano attivamente le proprie tabelle, in genere applicazioni OLTP () - utilizzerà il disco ed elaborerà le richieste in modo molto più efficiente. Maggiore è lo spazio su disco, maggiore sarà lo spazio a disposizione del database per crescere senza aggiornare l'infrastruttura.
Alcune strategie di aggiornamento richiedono la ricostruzione degli indici B-tree per sfruttare questi vantaggi (ad es. non ricostruirà automaticamente gli indici). Nelle versioni precedenti di PostgreSQL, la ricostruzione di indici di grandi dimensioni sulle tabelle comportava tempi di inattività significativi perché nel frattempo non era possibile apportare modifiche. Ma PostgreSQL 12 ha un'altra caratteristica interessante: ora puoi ricostruire gli indici in parallelo con il comando per evitare completamente i tempi di inattività.
Sono stati apportati altri miglioramenti all'infrastruttura di indicizzazione in PostgreSQL 12. Un'altra cosa in cui c'era un po' di magia... , noto anche come WAL (log write-ahead). Un registro write-ahead registra ogni transazione in PostgreSQL in caso di errore e replica. Le applicazioni lo utilizzano per l'archiviazione e . Naturalmente, il registro write-ahead viene scritto su disco, il che può influire sulle prestazioni.
PostgreSQL 12 ha ridotto il sovraccarico dei record WAL creati dagli indici GiST, GIN e SP-GiST durante la costruzione dell'indice. Ciò offre numerosi vantaggi tangibili: i record WAL occupano meno spazio su disco e i dati vengono riprodotti più velocemente, ad esempio durante il ripristino di emergenza o il ripristino point-in-time. Se utilizzi tali indici nelle tue applicazioni (ad esempio, le applicazioni geospaziali basate su PostGIS utilizzano molto l'indice GiST), questa è un'altra funzionalità che migliorerà significativamente l'esperienza senza alcuno sforzo da parte tua.
Partizionamento: più grande, migliore, più veloce
Introduzione di PostgreSQL 10 . In PostgreSQL 11 è diventato molto più semplice da usare. In PostgreSQL 12 puoi modificare la scala delle sezioni.
In PostgreSQL 12, le prestazioni del sistema di partizionamento sono migliorate notevolmente, soprattutto se nella tabella sono presenti migliaia di partizioni. Ad esempio, se una query interessa solo poche partizioni in una tabella che ne contiene migliaia, verrà eseguita molto più velocemente. Le prestazioni non sono solo migliorate per questi tipi di query. Noterai anche quanto siano più veloci le operazioni INSERT su tabelle con più partizioni.
Registrazione dei dati utilizzando - a proposito, questo è un ottimo modo ed ecco un esempio — Anche le tabelle partizionate in PostgreSQL 12 sono diventate più efficienti. Con COPY era già tutto veloce, ma in PostgreSQL 12 vola assolutamente.
Grazie a questi vantaggi, PostgreSQL consente di archiviare set di dati ancora più grandi e di facilitarne il recupero. E nessuno sforzo da parte tua. Se l'applicazione ha molte partizioni, ad esempio la registrazione di dati di serie temporali, un semplice aggiornamento migliorerà significativamente le sue prestazioni.
Sebbene questo non sia esattamente un miglioramento "aggiorna e divertiti", PostgreSQL 12 ti consente di creare chiavi esterne che fanno riferimento a tabelle partizionate, rendendo il partizionamento un piacere con cui lavorare.
Le query WITH sono migliorate molto
Quando (aka CTE, aka WITH query), non vedevo l'ora di scrivere un articolo su . Questa è una di quelle funzionalità che velocizzeranno l'applicazione. A meno che, ovviamente, non utilizzi CTE.
Trovo spesso che i neofiti di SQL adorino usare i CTE; se li scrivi in un certo modo, sembra davvero che tu stia scrivendo un programma imperativo. Personalmente, mi è piaciuto riscrivere queste domande per aggirare il problema без CTE e aumentare la produttività. Ora tutto è diverso.
PostgreSQL 12 consente di incorporare un tipo specifico di CTE senza effetti collaterali (SELECT), che viene utilizzato solo una volta verso la fine della richiesta. Se tenessi traccia delle query CTE che ho riscritto, la maggior parte di esse rientrerebbe in questa categoria. Ciò aiuta gli sviluppatori a scrivere codice chiaro che ora viene eseguito anche rapidamente.
Inoltre, PostgreSQL 12 ottimizza l'esecuzione SQL stessa, senza che tu debba fare nulla. E anche se probabilmente non avrò bisogno di ottimizzare tali query ora, è fantastico che PostgreSQL continui a lavorare sull'ottimizzazione delle query.
Just-in-Time (JIT): ora predefinito
Sui sistemi PostgreSQL 12 con supporto La compilazione JIT è abilitata per impostazione predefinita. Prima di tutto, ottieni supporto per alcune operazioni interne e, in secondo luogo, query con espressioni (l'esempio più semplice è x + y) negli elenchi di selezione (che hai dopo SELECT), aggregati, espressioni con clausole WHERE e altri possono utilizzare JIT per migliorare le prestazioni.
Poiché JIT è abilitato per impostazione predefinita in PostgreSQL 12, le prestazioni miglioreranno da sole, ma consiglio di testare l'applicazione in PostgreSQL 11, che ha introdotto JIT, per misurare le prestazioni delle query e vedere se è necessario ottimizzare qualcosa.
Che dire delle altre nuove funzionalità di PostgreSQL 12?
PostgreSQL 12 ha tantissime nuove interessanti funzionalità, dalla possibilità di esaminare i dati JSON utilizzando espressioni di route SQL/JSON standard all'autenticazione a più fattori con un parametro clientcert=verify-full, colonne create e molto altro ancora. Abbastanza per un post separato.
Come PostgreSQL 10, PostgreSQL 12 migliorerà le prestazioni complessive immediatamente dopo l'aggiornamento. Ovviamente puoi avere il tuo percorso: testare l'applicazione in condizioni simili sul sistema di produzione prima di abilitare miglioramenti, come ho fatto con PostgreSQL 10. Anche se PostgreSQL 12 è già più stabile di quanto mi aspettassi, non essere pigro nel testare applicazioni accuratamente, prima di rilasciarle in produzione.
Fonte: habr.com