PostgreSQL 11 : Evolution du partitionnement de Postgres 9.6 vers Postgres 11

Bon vendredi à tous ! Il reste de moins en moins de temps avant le lancement du cours "SGBD relationnel", nous partageons donc aujourd'hui la traduction d'un autre document utile sur le sujet.

En développement PostgreSQL 11 Un travail impressionnant a été réalisé pour améliorer le partitionnement des tables. Tables de partitionnement - c'est une fonction qui existait dans PostgreSQL depuis assez longtemps, mais elle, pour ainsi dire, n'existait essentiellement pas avant la version 10, dans laquelle elle est devenue une fonction très utile. Nous avons précédemment déclaré que l'héritage de table est notre implémentation du partitionnement, et c'est vrai. Seule cette méthode vous obligeait à effectuer la plupart du travail manuellement. Par exemple, si vous souhaitez que des tuples soient insérés dans des sections lors des INSERT, vous devrez configurer des déclencheurs pour le faire à votre place. Le partitionnement par héritage était très lent et difficile à développer des fonctionnalités supplémentaires.

Dans PostgreSQL 10, nous avons vu naître le « partitionnement déclaratif », une fonctionnalité conçue pour résoudre de nombreux problèmes insolubles avec l'ancienne méthode d'héritage. Cela a conduit à un outil beaucoup plus puissant qui nous a permis de diviser les données horizontalement !

Comparaison des fonctionnalités

PostgreSQL 11 introduit un ensemble impressionnant de nouvelles fonctionnalités qui contribuent à améliorer les performances et à rendre les tables partitionnées plus transparentes pour les applications.

PostgreSQL 11 : Evolution du partitionnement de Postgres 9.6 vers Postgres 11
PostgreSQL 11 : Evolution du partitionnement de Postgres 9.6 vers Postgres 11
PostgreSQL 11 : Evolution du partitionnement de Postgres 9.6 vers Postgres 11
1. Utilisation d'exceptions limitatives
2. Ajoute uniquement des nœuds
3. Uniquement pour une table partitionnée faisant référence à une table non partitionnée
4. Les index doivent contenir toutes les colonnes clés de la partition
5. Les restrictions de section des deux côtés doivent correspondre

Performance

Nous avons aussi de bonnes nouvelles ici ! Nouvelle méthode ajoutée suppression de sections. Ce nouvel algorithme peut déterminer les sections appropriées en examinant la condition de la requête WHERE. L’algorithme précédent, à son tour, vérifiait chaque section pour déterminer si elle pouvait remplir la condition WHERE. Cela a entraîné une augmentation supplémentaire du temps de planification à mesure que le nombre de sections augmentait.

Dans la version 9.6, avec le partitionnement via l'héritage, le routage des tuples dans les partitions était généralement effectué en écrivant une fonction de déclenchement contenant une série d'instructions IF pour insérer le tuple dans la partition correcte. Ces fonctions pourraient être très lentes à exécuter. Avec le partitionnement déclaratif ajouté dans la version 10, cela fonctionne beaucoup plus rapidement.

En utilisant une table partitionnée avec 100 partitions, nous pouvons évaluer les performances de chargement de 10 millions de lignes dans une table avec 1 colonne BIGINT et 5 colonnes INT.

PostgreSQL 11 : Evolution du partitionnement de Postgres 9.6 vers Postgres 11

Performance de l'interrogation de cette table pour trouver un enregistrement indexé et exécuter DML pour manipuler un enregistrement (en utilisant un seul processeur) :

PostgreSQL 11 : Evolution du partitionnement de Postgres 9.6 vers Postgres 11

Ici, nous pouvons voir que les performances de chaque opération ont considérablement augmenté depuis PG 9.6. Demandes SELECT sont bien meilleurs, en particulier ceux qui sont capables d'exclure plusieurs partitions lors de la planification des requêtes. Cela signifie que le planificateur peut ignorer une grande partie du travail qu'il aurait dû effectuer auparavant. Par exemple, les chemins ne sont plus construits pour les sections inutiles.

Conclusion

Le partitionnement de tables commence à devenir une fonctionnalité très puissante dans PostgreSQL. Il vous permet d'afficher rapidement des données en ligne et de les mettre hors ligne sans attendre la fin d'opérations DML lentes et massives.. Cela signifie également que les données associées peuvent être stockées ensemble, ce qui signifie que les données dont vous avez besoin sont accessibles beaucoup plus efficacement. Les améliorations apportées à cette version n'auraient pas été possibles sans les développeurs, les réviseurs et les committers qui ont travaillé sans relâche sur toutes ces fonctionnalités.
Merci à eux tous ! PostgreSQL 11 a l'air fantastique !

Voici un article si court mais assez intéressant. Partagez vos commentaires et n'oubliez pas de vous inscrire Journée portes ouvertes, dans lequel le programme du cours sera détaillé.

Source: habr.com

Ajouter un commentaire