Entretien avec Dimitri Fontaine, contributeur PostgreSQL

Contributeur de longue date au projet PostgreSQL, Dimitri Fontaine a publié il y a quelques mois un ouvrage consacré au développement d’applications et au « SGBD Open Source de référence » : Mastering PostgreSQL in Application Development ; on s’est dit que cela pourrait être une bonne occasion pour avoir sa vision sur l’évolution de PostgreSQL et des rapports entre développeurs et bases de données.

Pour ceux qui ne te connaissent pas, et ceux qui te connaissent mais n’ont jamais eu l’occasion de te poser la question : Comment as-tu été en contact avec PostgreSQL ?

Cela a commencé il y a 20 ans, quand à l’école, il nous fallait un SGBD sur HP-UX : PostgreSQL était le seul disponible et fonctionnait très bien. Ce n’est que bien plus tard que j’ai appris que Tom Lane (de la core team de PostgreSQL), était un ancien ingénieur kernel de HP-UX et qu’il veillait à la qualité de PostgreSQL sur cette plate-forme.

Un élément clef qui m’a incité à continuer à m’intéresser à PostgreSQL, c’est la conformité entre la documentation et le produit : tout marche comme indiqué dans la documentation, et si ce n’est pas le cas, c’est considéré comme un bug et rapidement corrigé.

Comment as-tu été amené à y contribuer ?

Ma première contribution a été déclenchée par la frustration que j’ai ressentie face à la complexité des procédures de backup et restauration lorsque des modules externes étaient employés. À l’époque, il n’y avait pas de système d’extension alors j’ai décidé d’en implémenter un. Cela m’a pris plus de deux ans, et cela m’a permis d’être reconnu comme major contributor au projet.

En tant que projet Open Source, PostgreSQL a plus un fonctionnement Cathédrale que Bazar, avec un nombre de commiteurs réduit (une dizaine actifs actuellement). Une grande importance est attachée à la reconnaissance individuelle : le nom de chaque auteur apparaît dans les release notes de chaque version, même si, pour des raisons techniques, il n’apparaît pas dans le champ author de git mais dans les commentaires.

Ma contribution suivante a porté sur les Event triggers. Sur la mailing list, Jan Wieck avait indiqué que ça devait être assez facile à mettre au point : à la lecture de son message, je me suis dit qu’il devait avoir raison et j’ai commencé le développement. Ça m’a pris 18 mois.

Tu as aussi été mainteneur Debian de PostgreSQL ?

Non : j’ai aidé à créer la solution apt.postgresql.org. 

Debian ne maintient dans Debian stable qu’une seule version de PostgreSQL, pour ne pas se trouver dans la situation où ils auraient à maintenir une version de PostgreSQL que nous aurions cessé de maintenir : les deux projets ont des gouvernances libres et ont des cycles de release indépendants.

PostgreSQL, de son côté, maintient 5 versions stables en parallèle : l’idée derrière apt.postgresl.org est de fournir des paquets Debian pour ces différentes versions.

Aujourd’hui, c’est principalement Christoph Berg (credativ) qui s’en occupe et il fait vraiment un excellent travail.

A côté du core de PostgreSQL, tu as écrit l’outil PGloader : pourquoi ?

Cela a commencé en 2005, à l’occasion de migrations d’Informix vers PostgreSQL. A force de refaire à peu près les mêmes opérations à la main, je me suis rendu compte que la partie de migration des données était complètement automatisable et c’est ce que permet un outil comme PGLoader.

Parallèlement, j’ai affiné une méthodologie de migration continue, adaptée aux migrations de projets complexes.

Elle comporte quatre étapes majeures :

1. On met en place une architecture de production PostgreSQL
2. On migre automatiquement les données de production toutes les nuits
3. On branche une intégration Continue sur l’environnement PostgreSQL qui contient les données de production
4. Une fois que tous les tests sont OK sur la CI, on pense à basculer l’application en production.

PGLoader permet de réaliser l’étape 2. Pour ceux que cela intéresse, la méthodologie est détaillée dans un Livre Blanc, disponible sur le site de PGLoader.

La version 10 de PostgreSQL est sortie en fin d’année dernière, quelles en ont été les nouveautés les plus marquantes ?

Il y en a trois principales, qui assez bien couvertes dans la presse, donc ce sera sans surprise :

• La réplication logique: elle permet de nouvelles architectures PostgreSQL. Ce ne sont pas des choses entièrement nouvelles, mais elles sont désormais beaucoup plus simples et on peut les mettre en œuvre avec bien plus de souplesse. Alors qu’on avait pour la réplication une granularité au niveau de l’installation PostgreSQL (un cluster), on a désormais une granularité au niveau de la table.
• Le partitionnement : on pouvait également le faire auparavant, mais c’est désormais plus simple et surtout mieux intégré avec les autres fonctionnalités de PostgreSQL, comme les requêtes parallèles. Sur cet aspect, PostgreSQL   a été un peu en retard par rapport à d’autres solutions, mais l’implémentation est vraiment robuste. C’est un peu le même phénomène que l’on a constaté pour UPSERT : la fonctionnalité est arrivée très tardivement dans PostgreSQL, et s’intègre bien avec l’ensemble du SGBD. De plus, INSERT … ON CONFLICT … résout le vrai problème qui motive la commande, en permettant de spécifier la contrainte d’unicité à prendre en compte.
• L’intégration de la haute disponibilité côté client : côté client, on fournit une liste de serveurs auxquels se connecter. C’est simple techniquement, et simplifie beaucoup les déploiements. Cela a d’abord été implémenté côté serveur, et une fois que cela a atteint un niveau de maturité satisfaisant, on l’a implémenté côté client.

Les prochains changements que l’on peut attendre ?

Les nouvelles fonctionnalités de PostgreSQL sont systématiquement construites sur ce qu’on a déjà : on va donc avoir un prolongement des dernières évolutions, comme une granularité au niveau des colonnes pour la réplication logique, par exemple.

Pour avoir une idée de ce qui va arriver dans PostgreSQL avec un an d’avance, le mieux est de suivre des sources comme https://planet.postgresql.org/ ou https://postgresweekly.com.

Et les sujets que tu aimerais personnellement voir progresser ?

Le partitionnement, c’est un sujet compliqué et j’aimerais bien qu’on le termine. Ensuite, les vues matérialisées en ligne : actuellement, il est encore nécessaire de mettre à jour le cache manuellement ; l’idée serait de mettre à jour le cache automatiquement quand les données changent.

Au niveau des outils externes à PostgreSQL, y a-t-il des nouveautés intéressantes parues récemment ?

Il y a toujours une actualité fournie sur les outils autours de PostgreSQL. Deux outils me viennent à l’esprit en particulier : Patroni et PG back rest.

• Patroni, développé par Zalando, permet de créer des systèmes PostgreSQL haute-disponibilité sur mesure, qui fonctionnent bien en combinaison avec Kubernetes.
• PG Back Rest est une solution d’automatisation de sauvegarde et de restauration de données. On a tendance à se focaliser sur la partie sauvegarde, alors que c’est la restauration de données qui compte. C’est une alternative sérieuse à PG Barman de 2nd Quadrant.

Y a-t-il des manques importants en termes d’outils externes par rapport à d’autres SGBD, comme Oracle ?

Il y a certains outils pour Oracle ou DB2, qui n’ont pas de sens que de dans leur contexte spécifique et pas avec PostgreSQL, qui inclut beaucoup de choses par défaut (Hot Standby, etc.). Après, il y a des outils qui apportent un vrai confort d’utilisation, dont certains peuvent encore manquer à PostgreSQL.

Il ne faut toutefois pas tomber dans le piège de la reproduction à l’identique. Prenons le cas des hints dans Oracle, par exemple. Cela permet à un DBA de modifier les plans d’exécution des requêtes écrites par les développeurs, sans toucher à l’application. Cela permet de corriger certains défauts de l’application, sans parler avec les développeurs, ce qui, au final n’est pas forcément une bonne chose, car c’est une occasion perdue d’échanger avec eux, de les faire monter en compétence sur les sujets liés à l’utilisation de la base de données. Et puis surtout, d’une version à l’autre de votre SGBD les hints peuvent changer de manière assez drastique, obligeant à revoir l’ensemble des requêtes arrangées.

Vu de l’extérieur, PostgreSQL semble connaître une adoption en croissance forte : c’est aussi l’impression que vous avez au sein du projet ?

C’est ce que l’on constate. On distingue notamment deux causes fortes favorisant son adoption : d’une part, les pratiques commerciales d’Oracle (aussi bien les audits que le mode de tarification) et d’autre part la montée en maturité des DSI vis-à-vis de l’Open Source.

Par ailleurs, il est extrêmement rare de voir une start-up employer des SGBD propriétaires.

Vous avez des indicateurs chiffrés spécifiques ?

On n’a pas de suivi du nombre de téléchargements ou autre et c’est de toute façon assez difficile à suivre, car le projet est vraiment libre. Il y a aussi plusieurs forks dans le cloud comme Amazon RDS, ou des extensions comme Citus, où je travaille actuellement… l’écosystème est vaste et complexe à cerner.

Le Groupe de Travail Inter-Entreprises (PGGTIE) de PostgreSQL-FR réunit des entreprises utilisatrices pour pousser l’adoption de PostgreSQL par les éditeurs et mutualiser des financements pour le développement de PostgreSQL. Tu en penses quoi ?

C’est une excellente initiative : il y a plusieurs années, certains de nos clients avaient déjà cette démarche individuellement vis-à-vis des petits éditeurs. La fédération autour de cette question devrait permettre de toucher des éditeurs plus importants.

Pourquoi écrire un livre sur PostgreSQL ?

Il y a des années que j’avais ce livre en tête : je me suis rendu compte que les développeurs gagneraient vraiment à mieux appréhender certaines des idées fondamentales sur les bases de données et en particulier celle-ci : le rôle principal de la base de données, c’est de gérer la concurrence d’accès aux données. Le stockage et la durabilité, c’est un problème beaucoup plus facile à résoudre, pas besoin de SGBD relationnel pour cela.

L’application se concentre typiquement sur le workflow de l’utilisateur, et la base de données maintient une vue globale et cohérente du système d’information. On peut gérer la concurrence d’accès au niveau applicatif, au risque alors de réécrire un SGBD.

À qui s’adresse ton livre ?

Aux développeurs d’applications, comme le titre l’indique (Mastering PostgreSQL in Application Development). L’idée est de les accompagner dans l’écriture de SQL de qualité, dans son intégration avec le reste du code, dans l’écriture des tests et dans les processus de code review sur du SQL.

L’objectif final est de permettre aux développeurs d’applications d’utiliser le langage SQL avec le même niveau de professionnalisme dont ils ont aujourd’hui l’habitude avec leurs autres langages de développement.

L’écriture a pris longtemps ?

C’est le fruit d’années de réflexions et de contacts avec les développeurs. L’écriture en elle-même a été assez rapide : environ 3 mois ; il y avait déjà des éléments sur mon blog.

Tu l’as écrit avec quels outils ?

Je rédige sous Emacs en Markdown, que je transforme avec Pandoc et des templates Latex ; le tout géré dans un dépôt git.