, l'ultima versione "del migliore sistema di database relazionale open source al mondo", uscirà tra un paio di settimane (se tutto va secondo i piani). Questo è in linea con il consueto programma — una nuova versione con un sacco di nuove funzionalità viene rilasciata una volta all'anno e, a dire il vero, è impressionante. Per questo sono diventato un membro attivo della comunità PostgreSQL.
A mio parere, a differenza delle versioni precedenti, PostgreSQL 12 non introduce una o due funzionalità rivoluzionarie (come ad esempio il partizionamento o il parallelismo delle query). Ho scherzato dicendo che la vera novità di PostgreSQL 12 è una maggiore stabilità. E non è forse ciò che serve quando gestisci dati critici per il tuo business?
Ma PostgreSQL 12 non si ferma qui: con nuove funzionalità e miglioramenti, le applicazioni funzioneranno meglio, e a te basterà fare un aggiornamento!
(Beh, forse anche ripristinare gli indici, ma in questa versione non è così problematico come ci aspettavamo.)
Sarà fantastico aggiornare PostgreSQL e godere immediatamente di miglioramenti significativi senza troppe complicazioni. Qualche anno fa ho analizzato l'aggiornamento da PostgreSQL 9.4 a PostgreSQL 10 e ho visto come l’applicazione sia stata accelerata grazie al migliorato parallelismo delle query in PostgreSQL 10. E, cosa più importante, non ho dovuto fare quasi nulla (solo impostare un parametro di configurazione max_parallel_workers).
Concordi che è comodo quando, subito dopo l'aggiornamento, le applicazioni funzionano meglio. E ci impegniamo molto per rendere felici gli utenti, perché PostgreSQL continua ad avere sempre più fan.
E come un semplice aggiornamento a PostgreSQL 12 ti renderà felice? Adesso te lo racconto.
Importanti miglioramenti nell'indicizzazione
Senza indicizzazione, un database non andrà lontano. Come altrimenti possiamo trovare rapidamente le informazioni? Il sistema di indicizzazione fondamentale di PostgreSQL si chiama . Questo tipo di indice è ottimizzato per i sistemi di archiviazione.
Basta utilizzare l'operatore CREATE INDEX ON some_table (some_column), e PostgreSQL si occupa del resto, mantenendo l'indice aggiornato mentre noi continuiamo ad inserire, aggiornare ed eliminare valori. Funziona tutto da solo, come per magia.
Ma gli indici di PostgreSQL hanno un problema — essi e occupano spazio inutile su disco, mentre le prestazioni di estrazione e aggiornamento dei dati diminuiscono. Con "gonfiamento" intendo il mantenimento inefficace della struttura dell'indice. Questo può essere — e può anche non essere — correlato a tuple spazzatura, che vengono eliminate (grazie per l'informazione a Peter Geoghegan ()). Il gonfiamento dell'indice è particolarmente evidente nei carichi di lavoro in cui l'indice viene modificato attivamente.
PostgreSQL 12 migliora significativamente la gestione degli indici B-tree, e gli esperimenti con test di tipo TPC-C hanno mostrato che ora si utilizza, in media, il 40% in meno di spazio. Ora dedichiamo meno tempo non solo alla manutenzione degli indici B-tree (cioè alle operazioni di scrittura), ma anche all'estrazione dei dati, poiché gli indici sono diventati molto più piccoli.
Le applicazioni che aggiornano attivamente le proprie tabelle — di solito sono applicazioni OLTP () — utilizzeranno il disco in modo molto più efficiente e gestiranno le richieste. Più spazio c'è su disco, maggiore è lo spazio a disposizione del database per crescere senza eseguire un aggiornamento dell'infrastruttura.
Alcune strategie di aggiornamento richiedono di ricostruire gli indici B-tree per sfruttare questi vantaggi (ad esempio, non ricostruisce automaticamente gli indici). Nelle versioni precedenti di PostgreSQL, la ricostruzione di grandi indici nelle tabelle portava a un notevole fermo, poiché non era possibile apportare modifiche nel frattempo. Ma in PostgreSQL 12 c'è un'altra funzionalità interessante: ora è possibile ricostruire gli indici in parallelo con il comando , per evitare del tutto il fermo.
In PostgreSQL 12 ci sono anche ulteriori miglioramenti all'infrastruttura di indicizzazione. Un'altra cosa che non è stata priva di magia è , noto anche come WAL (write-ahead log). Il log delle scritture anticipate registra ogni transazione in PostgreSQL per situazioni di fallimento e replicazione. Le applicazioni lo utilizzano per l'archiviazione e . Certo, il log delle scritture anticipate viene registrato su disco, e questo può influire sulle prestazioni.
In PostgreSQL 12, i costi delle registrazioni WAL, creati dagli indici GiST, GIN e SP-GiST durante la creazione degli indici, sono diminuiti. Questo offre diversi vantaggi tangibili: le registrazioni WAL occupano meno spazio su disco e i dati vengono riprodotti più velocemente, ad esempio durante il ripristino dopo un guasto o il recupero a un determinato momento. Se utilizzi questi indici nelle tue applicazioni (ad esempio, le applicazioni geospaziali basate su PostGIS utilizzano molto l'indice GiST), questa è un'altra funzionalità che migliorerà notevolmente le prestazioni senza alcuno sforzo da parte tua.
Partizionamento — più grande, migliore, più veloce
In PostgreSQL 10 è stato introdotto . In PostgreSQL 11 è diventato molto più facile da utilizzare. In PostgreSQL 12 è possibile modificare la scala delle partizioni.
In PostgreSQL 12, le prestazioni del sistema di partizionamento sono migliorate notevolmente, specialmente se nella tabella ci sono migliaia di partizioni. Ad esempio, se una query colpisce solo alcune partizioni in una tabella con migliaia di esse, verrà eseguita molto più velocemente. Le prestazioni sono migliorate non solo per questo tipo di query. Noterai anche come siano state accelerate le operazioni INSERT nelle tabelle con molte partizioni.
Scrivere dati usando — a proposito, è un ottimo modo ecco un esempio — anche nelle tabelle partizionate in PostgreSQL 12 è diventato più efficiente. Con COPY era già tutto veloce, ma in PostgreSQL 12 è davvero fulmineo.
Grazie a questi vantaggi, in PostgreSQL è possibile memorizzare set di dati di dimensioni ancora maggiori, e l'estrazione è diventata più semplice. E senza alcuno sforzo da parte tua. Se l'applicazione ha molte partizioni, ad esempio, se registra dati di serie temporali, un semplice aggiornamento migliorerà notevolmente le sue prestazioni.
E anche se questo miglioramento non rientra esattamente nella categoria 'abbiamo aggiornato e siamo felici', in PostgreSQL 12 è possibile creare chiavi esterne che fanno riferimento a tabelle partizionate, in modo che lavorare con il partizionamento sia un vero piacere.
Le query WITH sono migliorate notevolmente
Quando (che sono anche CTE, ovvero le query WITH), non vedevo l'ora di scrivere un articolo su come si sono rallegrati gli sviluppatori di applicazioni con PostgreSQL .
Spesso noto che i principianti in SQL amano usare CTE: se li scrivi in un certo modo, senti davvero che stai scrivendo un programma imperativo. Personalmente, mi piaceva riscrivere queste query per evitarle senza CTE e migliorare le prestazioni. Ora tutto è diverso.
PostgreSQL 12 consente di incorporare un certo tipo di CTE senza effetti collaterali (SELECT), che viene utilizzato solo una volta verso la fine della query. Se avessi tenuto statistiche delle query con CTE che ho riscritto, la maggior parte di esse rientrerebbe in questa categoria. Questo aiuta gli sviluppatori a scrivere codice comprensibile, che ora funziona anche rapidamente.
Inoltre, PostgreSQL 12 ottimizza l'esecuzione SQL automaticamente, non dovrai fare nulla. E sebbene ora, probabilmente, non avrò bisogno di ottimizzare queste query, è fantastico che PostgreSQL continui a lavorare sull'ottimizzazione delle query.
Just-in-Time (JIT) — ora di default
Nei sistemi PostgreSQL 12 che supportano la compilazione JIT è attivata di default. Prima di tutto, ottieni supporto per alcune operazioni interne, e in secondo luogo, le query con espressioni (l'esempio più semplice è x + y) nelle liste di selezione (che hai dopo SELECT), aggregati, espressioni con clausole WHERE e altro possono utilizzare JIT per migliorare le prestazioni.
Poiché JIT è abilitato di default in PostgreSQL 12, le prestazioni miglioreranno da sole, ma ti consiglio di testare l'applicazione in PostgreSQL 11, dove JIT è apparso per la prima volta, per misurare le prestazioni delle query e capire se c'è bisogno di qualche configurazione.
E le altre nuove funzionalità di PostgreSQL 12?
In PostgreSQL 12 ci sono molte nuove funzionalità interessanti — dalla possibilità di esplorare i dati JSON utilizzando le espressioni standard SQL/JSON fino all'autenticazione a più fattori con il parametro clientcert=verify-full, colonne generate e molto altro. Abbastanza per un post a parte.
Come per PostgreSQL 10, PostgreSQL 12 migliorerà le prestazioni generali subito dopo l'upgrade. Certo, potresti avere il tuo percorso — testa l'applicazione in condizioni simili in un ambiente di produzione, prima di attivare i miglioramenti, come ho fatto io con PostgreSQL 10. Anche se PostgreSQL 12 è già ora più stabile di quanto avessi previsto, non scordarti di testare accuratamente le applicazioni prima di metterle in produzione.
Fonte: habr.com
