PostgreSQL 11: L'évolution du partitionnement de Postgres 9.6 à Postgres 11

Vendredi saint tout le monde! 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 matériel utile sur le sujet.



Pendant le processus de développement de PostgreSQL 11 , un travail impressionnant a été fait pour améliorer le partitionnement des tables. Le partitionnement de table est une fonction qui existe dans PostgreSQL depuis un certain temps, mais, pour ainsi dire, elle n'existait 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 a obligé à effectuer la plupart du travail manuellement. Par exemple, si vous vouliez insérer des tuples dans des sections pendant les INSERT, vous deviez configurer des déclencheurs pour cela. Le partitionnement utilisant l'héritage était très lent et difficile à développer des fonctions supplémentaires.

Dans PostgreSQL 10, nous avons assisté à la naissance du «partitionnement déclaratif», une fonctionnalité conçue pour résoudre de nombreux problèmes insolubles lors de l'utilisation de l'ancienne méthode avec héritage. Cela a conduit à l'émergence d'un outil beaucoup plus puissant qui nous permet de diviser les données horizontalement!

Comparaison des fonctionnalités

PostgreSQL 11 présente un éventail impressionnant de nouvelles fonctionnalités qui aident à améliorer les performances et à rendre les tables partitionnées plus transparentes pour les applications.




1. Utilisation d'exceptions restrictives
2. Ajoute uniquement des nœuds
3. Uniquement pour une table partitionnée qui fait référence à une table non partitionnée
4. Les index doivent contenir toutes les colonnes clés d'une section
5. La restriction de la section des deux côtés doit correspondre

Performances

Ici, nous avons également de bonnes nouvelles! Une nouvelle méthode pour supprimer des sections a été ajoutée. Ce nouvel algorithme peut déterminer les sections appropriées en examinant la condition de requête WHERE . À son tour, l'algorithme précédent a vérifié chaque section pour déterminer si elle pouvait correspondre à la WHERE . Cela a entraîné une augmentation supplémentaire du temps de planification à mesure que le nombre de sections augmentait.

En 9.6, avec le partitionnement par héritage, le routage des tuples dans une section se faisait généralement en écrivant une fonction de déclenchement qui contenait une série d'instructions IF pour insérer le tuple dans la bonne section. Ces fonctions pourraient être très lentes à exécuter. Avec le partitionnement déclaratif ajouté dans la version 10, cela est devenu beaucoup plus rapide.

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



Les performances d'une requête sur cette table pour rechercher un enregistrement indexé et exécuter DML pour manipuler un enregistrement (en utilisant seulement 1 processeur):



Ici, nous voyons que les performances de chaque opération ont considérablement augmenté après PG 9.6. SELECT requêtes SELECT sont bien meilleures, en particulier celles qui peuvent exclure plusieurs sections lors de la planification des requêtes. Cela signifie que le planificateur peut ignorer la plupart des tâches qu'il aurait dû effectuer auparavant. Par exemple, les chemins pour les sections inutiles ne sont plus créés.

Conclusion

Le partitionnement des tables commence à devenir une fonctionnalité très puissante dans PostgreSQL. Il vous permet de produire rapidement des données en ligne et de les traduire hors ligne, sans attendre la fin des opérations massives lentes de DML . Cela signifie également que les données associées peuvent être stockées ensemble, ce qui signifie que les données requises 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 à tous! PostgreSQL 11 a l'air fantastique!

Voici un article si court, mais plutôt intéressant. Partagez vos commentaires et n'oubliez pas de vous inscrire à une journée portes ouvertes , dans laquelle le programme de cours sera décrit en détail.