Interview de Guillaume Lelarge, consultant chez Dalibo, une société d'expertise sur PostgreSQL, et auteur du livre PostgreSQL : Architecture et notions avancées [15/03/2015].

Bonjour Guillaume, tu es aujourd'hui un contributeur majeur de la communauté PostgreSQL, consultant et formateur chez Dalibo. Peux-tu nous raconter comment tu es arrivé à PostgreSQL et comment tu en es venu à t'impliquer autant dans son développement  ?

La première société où j'ai travaillé éditait un logiciel pour les laboratoires d'analyses médicales. C'était un programme très complexe et très puissant, mais aussi très ancien de conception. Il reposait entièrement sur des fichiers à plat. Les clients, généralement les patrons des laboratoires, demandaient fréquemment de pouvoir accéder aux données via une interface standard. L'idée a fait son chemin auprès du PDG qui a choisi d'utiliser PostgreSQL. C'était un choix très difficile, très osé à l'époque. Il s'agissait de la version 6.5. Personne avec un peu de sens commun n'aurait installé ce système, encore très instable (pas de journaux de transactions à l'époque), sur un serveur de production. Mais le PDG a tenu bon, on s'est mis à utiliser et à installer PostgreSQL. J'ai appris à l'utiliser sur le tas, j'ai commencé à lire les listes de discussions, à poser des questions...

Un peu plus tard, déjà très féru de logiciels libres et impliqué dans la communauté libre (principalement pour des traductions avec l'équipe de traduc.org), je me suis lancé dans un projet : traduire la documentation PostgreSQL. C'était un projet démentiel à bien y penser. Il y avait tellement de pages à traduire. Ma plus grosse traduction à l'époque devait être un HOWTO de 40 pages et j'allais me lancer dans une traduction d'une documentation de 1314 pages (2240 maintenant). Ça a été vraiment mon plus gros travail dans le monde libre, aidé bien sûr par différentes personnes selon les versions : toutes les pages de la documentation des versions 7.4 à 9.4.

J'ai continué à m'impliquer de plusieurs façons : en codant (un peu pour tous les outils autour de PostgreSQL mais surtout sur pgAdmin, faisant même partie de l'équipe officielle de développement), en continuant la traduction, en préparant des événements (comme les conférences européennes), en étant dans le bureau de PostgreSQL France dans un premier temps, puis depuis quelques années dans celui de PostgreSQL Europe (en tant que trésorier).

C'est lors d'un voyage en Californie avec Magnus Hagander (président de PostgreSQL Europe, membre de la Core Team), que j'ai appris ma nomination en tant que contributeur majeur au projet. Le seul français avec Dimitri Fontaine de 2ndQuadrant. Ça peut paraître stupide mais j'en suis très fier.

PostgreSQL fait partie du Top5 des SGDB les plus utilisés au monde, et pourtant il reste assez discret, peu médiatisé, au regard des autres systèmes. Comment expliques-tu cela ?

La raison est très simple : autant nous avons des développeurs vraiment exceptionnels, autant nous n'avons aucune équipe marketing pour mettre en avant cet outil. Tous les autres SGBD sont créés par des sociétés qui disposent d'équipes et de budget pour le marketing. PostgreSQL ne dispose pas de budget. PostgreSQL attire peu en dehors de développeurs et d'administrateurs de bases de données, qui n'ont ni affinité ni compétence pour le marketing.

"Autant nous avons des développeurs vraiment exceptionnels,
autant nous n'avons aucune équipe marketing
pour mettre en avant cet outil"

En fait, les seuls à parler de PostgreSQL sont les sociétés de support, notamment les sociétés spécialisées. Elles connaissent les qualités de ce SGBD, elles peuvent avoir un budget marketing et embaucher ou contracter auprès de sociétés de marketing pour faire du bruit autour de PostgreSQL.

Il est clair qu'aujourd'hui la majorité des administrateurs de bases de données qui ont côtoyé un peu PostgreSQL connaissent ses qualités. Il est tout aussi clair que la majorité des DSI n'en ont pas entendu parler. C'est un défi majeur pour une utilisation plus importante de ce SGBD.

Quels sont les points forts de PostgreSQL ?

D'après moi, son extensibilité est certainement son plus gros avantage. PostgreSQL dispose d'un certain nombre de fonctionnalités, qui forme une base complète et cohérente pour la majorité des utilisations. Cependant, il est possible d'étendre ses fonctionnalités. Vous voulez accéder à un autre serveur SQL ou NoSQL ? ajouter un connecter dans PostgreSQL prend cinq minutes. Vous voulez ajouter un scheduler ou un outil d'historisation des statistiques ? pas de soucis, vous l'ajoutez en dix minutes. Vous voulez intégrer un nouveau langage de procédures stockées (Perl par exemple) ? en deux minutes, vous l'avez. Vous avez besoin d'un type de données spécifique, ou d'une couche spatiale complète pour PostgreSQL ? c'est l'affaire de dix minutes.

PostgreSQL ne fait pas tout mais il s'adapte facilement à vos besoins et à votre contexte métier. C'est un avantage majeur.

Un autre gros avantage est sa communauté. Il est assez fréquent d'avoir une réponse à sa question dans l'heure qui suit sur les listes de discussions de PostgreSQL et sur les forums web, quelle que soit l'heure à laquelle vous l'avez posée. De nombreux événements (journées de conférence) sont organisés par la communauté un peu partout dans le monde. Ils permettent d'avoir un accès direct aux utilisateurs, aux contributeurs, aux développeurs. Il y a un sens du partage qui est vraiment épatant (et bien pratique).

Enfin, je dirais que, même si PostgreSQL ne permet pas dans tous les cas de remplacer un autre SGBD, il est quand même capable de le faire dans la majorité des cas. Même si on ne peut utiliser PostgreSQL que dans 90% des cas, ça fait de belles économies en terme de licence.

Et ses points faibles ?

En terme de fonctionnalité, le manque de parallélisation pour l'exécution d'une requête est un frein assez important. Le partitionnement est très basique. La réplication physique atteint ses limites. Heureusement que la réplication logique est en cours d'implémentation.

Quelles sont les situations où tu préconiserais tout particulièrement PostgreSQL ?

Je tournerais plutôt la question autrement. Quelles sont les situations où je ne préconiserais pas PostgreSQL ? L'embarqué. PostgreSQL n'est clairement pas fait pour ça.

Pour tout le reste, PostgreSQL a de très grosses qualités.

En tant que consultant et formateur, tu côtoies de nombreux utilisateurs Oracle qui migrent vers PostgreSQL. Comment se passe généralement le passage de l'un à l'autre ? Est-ce douloureux ?

Un administrateur Oracle va trouver de nombreux points communs avec PostgreSQL. Il trouvera rapidement ses marques avec ce SGBD. Dans la majorité des cas, il n'aura aucun mal à convertir une base Oracle en base PostgreSQL, notamment grâce à un outil de génie (ora2pg, de Gilles Darold).

"Un administrateur Oracle va trouver
de nombreux points communs avec PostgreSQL"

Le problème n'est pas réellement au niveau de la migration de la base de données. Le problème se situe plus au niveau des applications qui utilisent la base de données. Il faudra tester leur compatibilité avec PostgreSQL. La situation est pire quand l'application n'est pas codée en interne. Les éditeurs de progiciels, qui ont généralement codé leurs applications pour de l'Oracle ou du Microsoft SQL Server, ont souvent peu de motivation pour les migrer vers PostgreSQL.

L'explosion des réseaux sociaux et du big data a créé de nouveaux besoins en matière de traitement des données, favorisant l'essor de systèmes de bases de données non relationnels, d'emblée conçus pour être plus flexibles et manipuler des entités de natures très diverses. PostgreSQL n'est cependant pas en reste et propose aussi dans sa dernière version des fonctionnalités pour répondre à ces besoins. On parle même aussi de Postgres NoSQL... Peux-tu nous en dire un peu plus ?

PostgreSQL propose un certain nombre de fonctionnalités que l'on trouve dans les moteurs NoSQL : la possibilité de stocker des données de type clé/valeur avec l'extension hstore, la possibilité de stocker des documents au format JSON (en natif dans PostgreSQL), la possibilité d'écrire des procédures stockées en JavaScript avec PL/V8

L'avantage de PostgreSQL est de proposer tout ça, tout en conservant son côté relationnel et ses performances. Le meilleur des deux mondes en quelque sorte.

Venons-en maintenant à ton livre PostgreSQL - Architecture et notions avancées. Peux-tu le présenter et nous expliquer pourquoi tu as voulu écrire un tel livre ?

La documentation de PostgreSQL est plus une référence qu'un manuel. Personne ne va le lire de A à Z, cela n'aurait aucun intérêt. On va y piocher l'information dont on a besoin à un certain moment. Cela en reste là.

Il existe aussi un excellent livre sur les performances de PostgreSQL. Je pense à PostgreSQL 9.0, High Performance de Greg Smith [1]. Mais en fait, il n'y a aucun livre qui explique comment PostgreSQL fonctionne. Comment il utilise les fichiers, comment il utilise la mémoire, pourquoi il ne peut pas exécuter une requête sur plus d'un CPU, etc. Je me suis rendu compte en donnant des formations que c'était un manque particulièrement important. Les DBA ne savent pas configurer, administrer et superviser ce SGBD parce qu'ils ne comprennent pas comment ils fonctionnent. Pour en revenir à la configuration, tout ce que la documentation de PostgreSQL fait à ce niveau est d'expliquer chaque paramètre dans une immense liste. Ce n'est pas que la documentation est mauvaise en soi. C'est juste une référence. Si par contre on explique que PostgreSQL a besoin de mémoire pour telle et telle opération, et que les paramètres pour configurer ça sont les paramètres X et Y, cela devient plus simple à comprendre et à retenir.

Pour le dire simplement, j'essaie de mettre sur papier ce que je raconte à l'oral pendant mes formations. J'essaie de coucher sur papier tous les dessins et autres graphes que je fais au tableau pendant ces formations. Ce n'est pas simple, je ne me rappelle pas de tout. Mais j'ai plus de temps. Je peux creuser dans le code, je peux faire des petits patchs me permettant de mieux comprendre et du coup de mieux expliquer.

Enfin, je le fais aussi parce que, comme pour les formations, ça me permet d'en apprendre beaucoup plus sur PostgreSQL. Malgré huit ans à ne travailler que sur et avec ce logiciel, j'en apprends encore toujours. Juste passionnant.

À qui le conseillerais-tu en priorité ?

Je le conseillerais à tous ceux qui veulent comprendre. Tous ceux qui ne vont pas chercher à foncer, tête baissée, à installer, configurer, puis oublier.

Mon but est d'expliquer comment fonctionne PostgreSQL, pour ce que j'en sais. J'ai appris énormément en arrivant chez Dalibo, à un point qui m'étonne encore maintenant. Je continue à découvrir, grâce aux questions très pertinentes de mes clients, grâce à une étude plus approfondie du code, grâce à des problèmes auxquels je me heurte et qui me forcent à aller plus profondément dans la compréhension de ce moteur.

Le livre est disponible depuis janvier en version bêta. Cette formule est un peu particulière, puisque les lecteurs peuvent lire les chapitres au fur et à mesure de leur rédaction avant même que l'ensemble soit terminé et te faire part de leurs remarques. Pour un auteur, c'est un sacré défi. Comment le vis-tu et pourquoi avoir expressément choisi cette option ?

Je le vis très bien, et c'est heureux vu que j'ai voulu expressément avoir cette possibilité.

Je ne me vois pas comme un auteur dans sa tour d'ivoire, sachant tout et n'ayant besoin d'aucun retour. J'aime l'idée de construire le livre avec les (premiers) lecteurs et pouvoir prendre en compte leur retour pour améliorer le livre. C'est déjà arrivé deux fois depuis la sortie de la première bêta, et ce fut enrichissant pour le lecteur qui a fait ses retours et pour moi qui a amélioré le livre. Que demander de mieux ?

Je n'ai vraiment pas la prétention de tout savoir. Ce système de bêta et le forum qui permet d'avoir des retours des utilisateurs sont un formidable moyen pour connaître les points problématiques dans le livre : explications peu claires, affirmations erronées... que des lecteurs me disent "oui, mais là, ce que vous dites est étonnant parce que, moi, je constate ceci" ou "non, c'est faux, j'ai vécu cela sur mon serveur en production, en contradiction avec le livre" est déstabilisant mais salutaire. Ça me force à revenir sur ce que je pensais savoir, me force à étudier le problème plus en profondeur et à trouver une réponse. Un peu comme en formation, avec un stagiaire qui ne se laisse pas démonter et va dire au formateur qu'il se trompe : c'est gênant sur le coup mais c'est mieux que de continuer à affirmer une bêtise et ne pas reconnaître son erreur. Le forum permet justement de discuter d'un problème sur le livre, de trouver une meilleure formulation ou d'ajouter des informations manquantes. C'est bon pour le lecteur (celui qui a fait la remontée d'informations car son avis est pris en compte, mais aussi pour les autres qui ont de meilleures informations dans le livre), et aussi pour l'auteur (j'aurais appris une nouvelle chose sur PostgreSQL).

Merci, Guillaume, d'avoir répondu à mes questions. Souhaites-tu ajouter quelque chose ?

Juste un point. J'aimerais que chaque lecteur prenne un peu de temps pour donner son avis sur ce qui fonctionne et ce qui ne fonctionne pas sur ce livre. Histoire que je puisse l'améliorer.