URL: https://linuxfr.org/news/interview-de-dimitri-fontaine-contributeur-majeur-a-postgresql
Title: Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL
Authors: CamilleM
ZeroHeure, Davy Defaud, Benoît Sibaud, Nils Ratusznik et palm123
Date: 2018-02-25T01:44:03+01:00
License: CC By-SA
Tags: postgres, postgresql, base_de_données, sgbd, sgbdr, interview et entretien
Score: 56
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](https://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_base_de_donn%C3%A9es "système de gestion de base de données") libre de référence » : [_Mastering PostgreSQL in Application Development_](https://masteringpostgresql.com/). 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.
----
[Le blog de Dimitri Fontaine](https://tapoueh.org)
[Planet PostgreSQL](https://planet.postgresql.org/)
[Le Groupe de Travail Inter‐Entreprises de PostgreSQL-FR](https://www.postgresql.fr/entreprises/accueil)
[Le site du livre Mastering PostgreSQL in Application Development](https://masteringpostgresql.com/)
----
***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 vingt 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 à Postgres, 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 bogue 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 sauvegarde 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 » [N. D. M. : référence à [_La Cathédrale et le Bazar_ ](https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar), d’Eric Raymond], 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 notes de publication 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 liste de diffusion, 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 publication indépendants. PostgreSQL, de son côté, maintient cinq versions stables en parallèle : l’idée derrière _apt.postgresql.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.
***À côté du cœur de PostgreSQL, tu as écrit l’outil PGloader : pourquoi ?***
Cela a commencé en 2005, à l’occasion de migrations d’Informix vers PostgreSQL. À 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 Postgres qui contient les données de production ;
4. une fois que tous les tests sont OK sur l’intégration continue, on pense à basculer l’application en production.
PGLoader permet de réaliser l’étape deux. Pour ceux que cela intéresse, la méthodologie est détaillée dans un [livre blanc, disponible sur le site de PGLoader](https://pgloader.io/white-paper/).
***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 sont 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 ou .
***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 pgBackRest.
[Patroni](https://github.com/zalando/patroni), développé par Zalando, permet de créer des systèmes PostgreSQL haute disponibilité sur mesure, qui fonctionnent bien en combinaison avec Kubernetes.
[pgBackRest](http://pgbackrest.org/) 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 à [Barman](http://www.pgbarman.org/) 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 de sens que 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](https://fr.wikipedia.org/wiki/Administrateur_de_base_de_donn%C3%A9es "DataBase Administrator — administrateur de base de données") 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](https://fr.wikipedia.org/wiki/Directeur_des_syst%C3%A8mes_d%27information "Directeur des systèmes d’information") vis‐à‐vis de l’Open Source. Par ailleurs, il est extrêmement rare de voir une _start‐up_ employer des SGBD propriétaires.
***Avez-vous 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 revue de code 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 trois 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.
***Merci Dimitri !***