PostgreSQL 10 : un véritable support pour le partitionnement de table sera implémenté
PostgreSQL 10 : un véritable support pour le partitionnement de table sera implémenté
dans le système de gestion de base de données libre
Les développeurs du système de gestion de base de données relationnelle et objet (SGBDRO) libre PostgreSQL pourraient bientôt livrer un véritable support du partitionnement de tables. De manière simpliste, on peut dire que le partitionnement fait référence à la division d'une table volumineuse en plusieurs tables plus petites, appelées partitions.
Il comporte de nombreux avantages comme l’amélioration significative des performances des requêtes en particulier lorsque la plupart des lignes fortement accédées d'une table se trouvent sur une seule partition ou sur un petit nombre de partitions. Si votre table principale est correctement partitionnée, supprimer de nombreux enregistrements sera également plus facile, car cela pourra se traduire par la suppression de tables. Il pourrait en effet être beaucoup plus difficile de supprimer de nombreux enregistrements d'une grande table et ensuite lancer un VACUUM pour récupérer l'espace de stockage occupé par des lignes supprimées. Le partitionnement sur une plage de dates signifie par exemple que pour supprimer les données les plus anciennes, vous aurez simplement besoin de supprimer une ou quelques tables. Ce qui est bien plus facile. Il en est de même pour les chargements massifs de données, ils peuvent être simplement obtenus par l’ajout de partitions, sous réserve que ce besoin ait été pris en compte lors de l’implémentation du partitionnement.
PostgreSQL offre déjà un support du partitionnement de tables, mais il s’agit d'un support basique à travers l'héritage de tables. Chaque partition doit être créée comme une table enfant d'une unique table parent. La table parent est habituellement vide et elle n'existe que pour représenter l'ensemble complet des données. Lors de la conception de votre base de données PostgreSQL, l’implémentation du partitionnement consiste à :
- créer la table « maître » ;
- créer plusieurs tables enfants (les partitions) qui héritent chacune de la table maître ;
- ajouter les contraintes de tables aux tables de partitions pour définir les valeurs des clés autorisées dans chacune ;
- pour chaque partition, créer un index sur les colonnes clés, ainsi que tout autre index nécessaire ;
- de manière optionnelle, définir un déclencheur ou une règle pour rediriger les données insérées dans la table maître vers la partition appropriée ;
- s'assurer que le paramètre de configuration constraint_exclusion n'est pas désactivé dans postgresql.conf. S’il est désactivé, les requêtes ne seront pas optimisées.
Mais ce support du partitionnement à travers l’héritage n’est juste qu’une méthode de contournement qui se base sur le rapprochement entre le partitionnement et l’héritage. La solution offerte par PostgreSQL consiste en effet à créer une table parent qui sera vide, des tables enfants qui héritent de la table parent, des déclencheurs pour acheminer les données insérées vers les tables de partitions appropriées, activer le paramètre constraint_exclusion pour optimiser les requêtes, etc. ; alors que le partitionnement natif ne vous montrera que la table parent, et tout le reste sera en arrière-plan. C’est-à-dire que vous n’aurez qu’à déclarer comment une table doit être partitionnée, sans devoir implémenter les détails vous-mêmes. Avec Oracle par exemple, la table partitionnée est vue par le développeur comme une unique table, mais comme plusieurs par le moteur Oracle. Ainsi, selon le critère de partitionnement, Oracle n'interrogera que les partitions concernées.
Ce que les développeurs de PostgreSQL seraient en train de faire maintenant à partir de la version 10 du SGBD, c’est d’implémenter un tel support du partitionnement de tables. Dans un mail dans la liste de diffusion de PostgreSQL, ils expliquent par exemple que « les tuples insérés dans le parent sont automatiquement acheminés vers la partition concernée, de sorte que les déclencheurs d'insertion de tuple ON INSERT ne sont pas nécessaires. » Mais, il faut noter que pour le moment, certaines fonctionnalités ne sont pas supportées. Ils avertissent par exemple que « la redirection de tuple n'est pas encore prise en charge pour les partitions qui sont des tables étrangères et ne gère pas les mises à jour qui franchissent les limites de la partition. »
S’il est similaire à l’héritage de table et réutilise une grande partie de l'infrastructure PostgreSQL existante, le partitionnement de table présente toutefois des différences importantes. Il est moins général que l'héritage de table, ce qui, selon les développeurs de PostgreSQL, rendra « plus facile de raisonner sur les propriétés des partitions et servira de base pour une variété d'optimisations possibles, y compris les optimisations du planificateur de requêtes. »
Sources : PostgreSQL Git, Partitionnement sous PostgreSQL
Et vous ?
:fleche: Utilisez-vous PostgreSQL ?
:fleche: Que pensez-vous du support de partitionnement de tables ?
Voir aussi :
:fleche: La version finale de PostgreSQL 9.6 est disponible avec le parallélisme des requêtes et de nouvelles options pour la réplication synchrone
:fleche: Les systèmes de JIT améliorent la performance des requêtes SQL complexes, une extension de PostgreSQL intègre LLVM et diminue les temps de traitement
