Dimitri Fontaine (2ndQuadrant) : «Le modèle de développement de PostgreSQL est sérieux au point de ne jamais griller d’étapes»

Retour détaillé sur les nouveautés de PostgreSQL 9.3 avec Dimitri Fontaine, contributeur du projet.

Silicon.fr – Bonjour Dimitri. Pouvez-vous résumer la teneur de votre participation dans le développement de cette nouvelle mouture de PostgreSQL ?

Dimitri Fontaine – Bonjour David. J’ai le plaisir d’être listé parmi les « Contributeurs Majeurs » du projet PostgreSQL pour avoir travaillé sur des outils, des extensions, la documentation, la conception, puis finalement des fonctionnalités intégrées dans PostgreSQL.

Cette activité de développement fait partie de mon travail chez 2ndQuadrant et complète idéalement notre activité de conseil et d’expertise sur la solution Open Source de référence des bases de données relationnelles.

Après avoir mis au point les Extensions pour la version 9.1, pour la version 9.3 ma participation principale a été la possibilité de déclencher des traitements lors de l’exécution de commandes (telles CREATE TABLE) avec les “Event Triggers”.

La commande VIEW semble avoir fortement progressé. Dans quels domaines et en quoi cela pourra-t-il faciliter le travail des développeurs ?

Le standard SQL définit les « vues » comme une requête enregistrée sous un nom, et ajoute tout un ensemble de fonctionnalités avancées. La version 9.3 de PostgreSQL s’intéresse à cela avec les premières étapes vers les vues matérialisées et le support des mises à jour des vues.

Lorsqu’une équipe de développement utilise les vues afin de simplifier l’accès aux données, le support des mises à jour permet de bénéficier des vues non seulement en lecture, mais aussi en écriture, et ce de manière automatique – dans les cas simples. Si votre vue est trop complexe pour que PostgreSQL 9.3 sache exécuter un ordre de mise à jour des données directement sur les relations sous-jacentes, vous pourrez définir des “triggers” sur cette vue comme depuis la version 9.1.

Les vues matérialisées quant à elles permettent aux développeurs de maintenir en base de données des “snapshots” précalculés du résultat d’une requête. Plutôt que de devoir calculer les résultats avec les données les plus récentes à chaque fois qu’une vue est référencée, il est maintenant possible de se contenter de la dernière valeur calculée. Un tel compromis ouvre donc l’utilisation de PostgreSQL comme solution de « mise en cache » des données.

Le support de JSON est en progrès. Pouvez-vous nous en dire plus à ce sujet et sur ses implications sur le marché PostgreSQL ?

PostgreSQL est un système relationnel né de la recherche sur la modélisation objets en base de données lancée dans les années 80. Comme tout projet Open Source, il évolue en fonction des usages qui en sont faits.

Aujourd’hui, les utilisateurs souhaitent mettre en place une approche dite “schema less” où les développeurs peuvent progresser sur leurs applications avant de savoir quelles données ils vont manipuler dans le détail, et avec la capacité de changer d’avis à ce propos très facilement.

Plutôt que d’essayer de raisonner ce besoin, PostgreSQL a su le reconnaître et intégrer la solution qui a su se démarquer aujourd’hui : la version 9.2 apportait déjà la capacité d’intégrer des données selon le format JSON, la version 9.3 ajoute un ensemble puissant et évolué de fonctions et d’opérateurs permettant de réaliser des traitements JSON au sein même de la base de données. Cela inclut une très grande souplesse d’indexation des champs JSON.

Pouvez-vous relever le défi d’expliquer simplement comment fonctionne LATERAL JOIN et ce que cela va changer pour les développeurs ?

Et quel défi ! Avant de m’y essayer, plaçons cette fonctionnalité dans son contexte : PostgreSQL excelle à résoudre des problèmes SQL complexes mettant en œuvre de nombreuses jointures. Quand avec d’autres produits il est souvent nécessaire de revoir ses ambitions à la baisse, avec PostgreSQL il est possible d’exprimer votre besoin d’analyse de données dans les moindres détails.

En effet, le planificateur de requêtes de PostgreSQL est un véritable compilateur et dispose non seulement d’algorithmes avancés et de statistiques détaillées sur le contenu de vos relations, mais aussi d’un optimiseur de requêtes extrêmement futé. Profitons-en !

Pour comprendre LATERAL le mieux est de commencer par le terme technique de l’implémentation sous-jacente : parcours de données paramétré. Il est donc maintenant possible lors d’une jointure de référencer des données de la relation pivot.

Cela permet de résoudre des jointures complexes avec une plus grande souplesse puisque l’on dispose d’un outil supplémentaire, et aussi d’écrire certaines requêtes pour lesquelles il était auparavant nécessaire de déployer des procédures stockées.

De nouvelles techniques permettent de mieux résoudre ou éviter les problèmes. Comment fonctionnent-elles et quelles sont leurs limites ?

Le modèle de développement de PostgreSQL est sérieux au point de ne jamais griller d’étapes. Avec la version 9.1 de PostgreSQL, nous avons bénéficié d’une solution de réplication intégrée robuste et performante, permettant de mettre en place des architectures à haute disponibilité des données et des services.

Les versions suivantes apportent maintenant de la souplesse et de la facilité d’utilisation, ainsi que des améliorations de performances. Le cas du “failover” a été étudié et il a été prouvé qu’une étape de sécurité des données était redondante : ne plus l’effectuer permet de réaliser une bascule en quelques secondes ou moins et d’atteindre par là même les cinq neuf de disponibilité : 99,999% de disponibilité de service ! Évidemment, tout en garantissant la durabilité et la disponibilité des données.

PostgreSQL 9.3 permet également de se passer d’une configuration d’archivage des journaux de transaction même dans les scénarios de réplication en cascade et de changement de nœud primaire. L’archivage devient alors un outillage de sauvegarde et restauration des données plutôt qu’un élément de la configuration de la réplication.

Puisqu’on parle de sauvegardes, souvenez-vous que sans procédures automatiques de restauration des données ni test systématique de vos sauvegardes, ces dernières sont inutiles. Nulles et non avenues.

Enfin, le matériel et les nombreux logiciels de stockages n’étant pas infaillible, il peut arriver que les données soumises aux soins de PostgreSQL soient corrompues. La version 9.3 apporte les outils permettant de déterminer si le problème est matériel avec l’arrivée des sommes de contrôles des données (“data checksums”).

Voir la seconde partie de notre entretien : amélioration des performances et avantages concurrentiels de PostgreSQL.

Crédit photo : © Oleg Bartunov

Voir aussi
Quiz Silicon.fr – Connaissez-vous les logiciels open source ?