Buona venerdì a tutti! Il tempo sta per scadere prima del lancio del corso , perciò oggi condividiamo la traduzione di un altro materiale utile sull'argomento.
Durante lo sviluppo è stato compiuto un lavoro impressionante per migliorare il partizionamento delle tabelle. Partizionamento delle tabelle è una funzione che esiste in PostgreSQL da molto tempo, ma che, per così dire, non era realmente operativa fino alla versione 10, in cui è diventata una funzionalità molto utile. In precedenza, affermavamo che l'ereditarietà delle tabelle era la nostra implementazione del partizionamento, e questo è vero. Tuttavia, questo metodo richiedeva di fare gran parte del lavoro manualmente. Ad esempio, se volevi che le tuple fossero inserite nelle sezioni durante gli INSERT, dovevi impostare i trigger per farlo per te. Il partizionamento tramite ereditarietà era molto lento e complesso da implementare ulteriori funzionalità sopra di esso.
In PostgreSQL 10, we witnessed the birth of "declarative partitioning" — a feature designed to solve many problems that were unsolvable using the old inheritance method. This led to the emergence of a much more powerful tool that allows us to partition data horizontally!
Feature comparison
PostgreSQL 11 introduced an impressive array of new features that improve performance and make partitioned tables clearer for applications.
1. Using exclusion constraints
2. Adds only nodes
3. Only for partitioned tables referring to non-partitioned ones
4. Indexes must contain all key columns of the partition
5. Constraints on both sides of the partition must match
Prestazioni
Here we also have good news! A new method . This new algorithm can identify suitable partitions by examining the query condition DOVE. The previous algorithm, on the other hand, checked each partition to determine if it could meet the condition DOVE. Questo ha portato a un aumento del tempo di pianificazione man mano che cresceva il numero di sezioni.
Con la versione 9.6, utilizzando la partizione tramite ereditarietà, l'instradamento delle tuple nelle sezioni avveniva di solito scrivendo una funzione trigger che conteneva una serie di operatori IF per inserire la tupla nella sezione corretta. Queste funzioni potevano essere molto lente nell'esecuzione. Con la partizione dichiarativa introdotta nella versione 10, questo è diventato molto più veloce.
Utilizzando una tabella partizionata con 100 sezioni, possiamo valutare le prestazioni di caricamento di 10 milioni di righe in una tabella con 1 colonna BIGINT e 5 colonne INT.
Le prestazioni della query su questa tabella per cercare un singolo record indicizzato ed eseguire DML per manipolare un record (utilizzando solo 1 processore):
Qui vediamo che le prestazioni di ogni operazione sono aumentate notevolmente dopo PG 9.6. Le query SELECT sono decisamente migliori, specialmente quelle capaci di escludere molte sezioni durante la pianificazione delle query. Questo significa che il pianificatore può evitare gran parte del lavoro che doveva fare in precedenza. Ad esempio, non si costruiscono più percorsi per sezioni non necessarie.
Conclusione
La partizionamento delle tabelle sta diventando una funzionalità molto potente in PostgreSQL. Permette di restituire rapidamente i dati online e di convertirli in offline, senza dover aspettare il completamento di operazioni DML lente e massicce.. Questo significa anche che i dati correlati possono essere memorizzati insieme, il che consente un accesso molto più efficiente ai dati richiesti. I miglioramenti apportati in questa versione non sarebbero stati possibili senza gli sviluppatori, i revisori e i membri del team che hanno lavorato instancabilmente su tutte queste funzionalità.
Grazie a tutti loro! PostgreSQL 11 ha un aspetto semplicemente fantastico!
Ecco un articolo breve ma piuttosto interessante. Condividete i commenti e non dimenticate di registrarvi per il , durante il quale verrà illustrato in dettaglio il programma del corso.
Fonte: habr.com
