, l'ultima versione del "miglior database relazionale open source al mondo", uscirà tra un paio di settimane (se tutto va secondo i piani). Questo è in linea con il consueto calendario — una nuova versione con una serie di nuove funzionalità esce ogni anno, e, a dire il vero, è impressionante. È per questo che sono diventato un membro attivo della comunità PostgreSQL.
Secondo me, a differenza delle versioni passate, PostgreSQL 12 non contiene una o due funzionalità rivoluzionarie (come la partizionatura o il parallelismo delle query). Una volta scherzai dicendo che la vera novità di PostgreSQL 12 è una maggiore stabilità. E non è proprio ciò di cui hai bisogno quando gestisci dati critici per la tua attività?
Ma PostgreSQL 12 non si ferma qui: con le nuove funzionalità e miglioramenti, le applicazioni funzioneranno meglio, e a te basta semplicemente effettuare l'aggiornamento!
(Beh, forse è necessario ricostruire anche gli indici, ma in questa versione non è così problematico come siamo abituati a pensare.)
Sarebbe fantastico eseguire l'upgrade a PostgreSQL e godere immediatamente di significativi miglioramenti senza troppi sforzi. Alcuni anni fa ho analizzato l'aggiornamento da PostgreSQL 9.4 a PostgreSQL 10 e ho notato come l'applicazione fosse diventata più veloce grazie al migliorato parallelismo delle query in PostgreSQL 10. E, soprattutto, non ho dovuto fare quasi nulla (solo impostare il parametro di configurazione max_parallel_workers).
Concordate che è comodo vedere il miglioramento delle prestazioni delle applicazioni subito dopo l'aggiornamento? Ci impegniamo molto per soddisfare i nostri utenti, dato che gli utilizzatori di PostgreSQL stanno aumentando sempre di più.
E come un semplice upgrade a PostgreSQL 12 vi renderà felici? Ve lo racconto ora.
Miglioramenti significativi nell'indicizzazione
Senza indicizzazione, un database non andrà lontano. Come poter trovare rapidamente le informazioni? Il sistema di indicizzazione fondamentale di PostgreSQL è chiamato . Questo tipo di indice è ottimizzato per i sistemi di archiviazione.
Utilizziamo semplicemente l'operatore CREATE INDEX ON some_table (some_column), e PostgreSQL si occupa del lavoro pesante per mantenere l'indice aggiornato mentre continuiamo ad inserire, aggiornare e rimuovere valori. Tutto funziona da solo, come per magia.
Tuttavia, gli indici di PostgreSQL hanno un problema: sono e occupano spazio inutile su disco, riducendo le prestazioni di estrazione e aggiornamento dei dati. Con 'gonfiamento' intendo il mantenimento inefficace della struttura dell'indice. Questo può essere — e non essere — collegato a tuple di spazzatura che vengono eliminate (grazie all'informazione di Peter Geoghegan ()). Il gonfiamento dell'indice è particolarmente evidente in carichi di lavoro in cui l'indice viene attivamente modificato.
PostgreSQL 12 migliora notevolmente il funzionamento degli indici B-tree, e esperimenti con test di tipo TPC-C hanno dimostrato che ora viene utilizzato, in media, il 40% di spazio in meno. Ora dedichiamo meno tempo non solo alla manutenzione degli indici B-tree (cioè alle operazioni di scrittura), ma anche all'estrazione dei dati, visto che gli indici sono diventati molto più piccoli.
Le applicazioni che aggiornano attivamente le proprie tabelle — solitamente si tratta di applicazioni OLTP () — utilizzeranno molto più efficientemente il disco e gestiranno le query. Più spazio c'è su disco, maggiore sarà lo spazio disponibile per la crescita del database senza dover aggiornare l'infrastruttura.
Alcune strategie di aggiornamento richiedono la ricostruzione degli indici B-tree per sfruttare questi vantaggi (ad esempio, non ricostruirà automaticamente gli indici). Nelle versioni precedenti di PostgreSQL, la ricostruzione di grandi indici nelle tabelle comportava tempi di inattività significativi, poiché durante questo periodo non era possibile apportare modifiche. Ma in PostgreSQL 12 c'è un'altra caratteristica interessante: ora è possibile ricostruire gli indici in parallelo con il comando , per evitare completamente i tempi di inattività.
In PostgreSQL 12 ci sono anche altri miglioramenti nell'infrastruttura degli indici. Un'altra cosa, dove non è mancata la magia, è il , conosciuto anche come WAL (write-ahead log). Il write-ahead log registra ogni transazione in PostgreSQL in caso di guasto e replica. Le applicazioni lo utilizzano per l'archiviazione e . Naturalmente, il write-ahead log viene registrato su disco, il che può influire sulle prestazioni.
In PostgreSQL 12, the overhead of WAL records created by GiST, GIN, and SP-GiST indexes has been reduced. This offers several significant advantages: WAL records take up less disk space and data is restored more quickly, for instance, during recovery after a failure or point-in-time recovery. If you use such indexes in your applications (for example, geospatial applications heavily rely on the GiST index), this is another feature that will greatly enhance performance effortlessly on your part.
Partizionamento — più, meglio, più veloce
In PostgreSQL 10 è stato introdotto . In PostgreSQL 11 è diventato molto più semplice da utilizzare. In PostgreSQL 12 è possibile modificare la scala delle sezioni.
In PostgreSQL 12, the performance of partitioning has significantly improved, especially when dealing with tables that have thousands of sections. For instance, if a query only touches a few sections in a table with thousands, it will execute much faster. The performance enhancement applies not only to such types of queries. You will also notice that INSERT operations in tables with many sections have become faster.
Data recording via — by the way, this is a great method for and here’s an example of — has also become more efficient for partitioned tables in PostgreSQL 12. With COPY, the process was already fast, and in PostgreSQL 12, it's incredibly quick.
Thanks to these advantages, PostgreSQL can now store even larger datasets, and retrieving them has become easier. And there's no extra effort required from your side. If your application has many sections, for example, when it records time series data, a simple upgrade will significantly improve its performance.
Sebbene questo miglioramento non rientri esattamente nella categoria "abbiamo aggiornato e siamo felici", in PostgreSQL 12 è ora possibile creare chiavi esterne che fanno riferimento a tabelle partizionate, rendendo il lavoro con la partizionalità un vero piacere.
Le query WITH sono notevolmente migliorate.
Quando (CTE, note anche come query WITH), non vedevo l'ora di scrivere un articolo su come gli sviluppatori di applicazioni con PostgreSQL . Spesso noto che i principianti in SQL amano usare CTE: se scritti in un certo modo, si ha davvero la sensazione di scrivere un programma imperativo. Personalmente, amavo riscrivere queste query per evitare
utilizzare CTE e migliorare le prestazioni. Ora tutto è cambiato. di CTE e migliorare le prestazioni. Ora è tutto diverso.
PostgreSQL 12 consente di incorporare un certo tipo di CTE senza effetti collaterali (SELECT), utilizzato solo una volta verso la fine della query. Se facessi delle statistiche sulle 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 automaticamente l'esecuzione delle SQL, non dovrai fare nulla. E sebbene ora probabilmente non dovrò più ottimizzare queste query, è fantastico che PostgreSQL continui a lavorare sull'ottimizzazione delle query.
Just-in-Time (JIT) — ora per impostazione predefinita
Nei sistemi PostgreSQL 12 con supporto La compilazione JIT è abilitata di default. Prima di tutto, ottieni il supporto per alcune operazioni interne, e in secondo luogo, le query con espressioni (l'esempio più semplice è x + y) nelle selezioni (che hai dopo SELECT), aggregazioni, espressioni con clausole WHERE e altri possono utilizzare JIT per migliorare le prestazioni.
Con JIT abilitato in PostgreSQL 12 per impostazione predefinita, le prestazioni miglioreranno da sole, ma ti consiglio di testare l'applicazione in PostgreSQL 11, dove JIT è stato introdotto, per misurare le prestazioni delle query e capire se sia necessario effettuare qualche configurazione.
E per quanto riguarda le altre nuove funzionalità di PostgreSQL 12?
In PostgreSQL 12 ci sono tantissime nuove funzionalità interessanti — dalla possibilità di interrogare dati JSON utilizzando le espressioni del percorso SQL/JSON fino all'autenticazione multifattoriale con l'opzione clientcert=verify-full, colonne generate e molto altro. Meriterebbe un post a parte.
Proprio come PostgreSQL 10, PostgreSQL 12 aumenterà le prestazioni generali subito dopo l'upgrade. Certamente puoi seguire il tuo percorso — testa l'applicazione in condizioni simili nel sistema di produzione prima di attivare le migliorie, come ho fatto io con PostgreSQL 10. Anche se PostgreSQL 12 è già più stabile di quanto pensassi, non dimenticare di testare a fondo le applicazioni prima del rilascio in produzione.
Fonte: habr.com
