PgDays Paris 2019

Dans le monde des bases de données relationnelles, les plus connues et plus réputées sont Oracle et Microsoft SQL Server, qui sont extrêmement performantes, configurables, mais très chères. Il y a des bases de données gratuites mais moins performantes, et moins outillées, comme MySQL/MariaDB. Et puis il y a PostgreSQL, base de données gratuite, très performante, très bien outillée, qui est celle qui respecte le mieux le standard SQL, et qui est soutenue par toute une communauté de développeurs et utilisateurs. Algofi s’est rendu à la journée de conférence PgDay Paris du 12 mars 2019. Récit de la journée.

10 :00 Après un café, c’est parti pour les conférences techniques. Et on démarre sur les chapeaux de roues ! Dimitri Fontaine explique par des exemples concrets le fonctionnement de mots-clés SQL ou spécifiques à PostgreSQL plutôt méconnus. A coup de generate_series(), interval, JOIN USING(column_name), LEFT JOIN LATERAL, GROUP BY GROUPING SETS, RANK() OVER, en utilisant comme données d’exemple une liste de Grand Prix de Formule 1, de pilotes de courses, et de leurs résultats, il génère des rapports complexes tels que la liste des gagnants par trimestre, les trois meilleurs pilotes par décennie ou encore le cumul de points, par contructeur et par pilote, par saison. Un festival qui se termine même par la création d’un histogramme, tout cela sans autre outil que PostgreSQL et des requêtes SQL !

10 :55 C’est au tour de Markus Winand de parler de sa spécialité : les index. Un index, c’est une sorte de mini-base de données, qui stocke, pour chaque valeur d’une table, les références des lignes qui contiennent cette valeur, ce qui permet au moteur d’y accéder rapidement, plutôt que de devoir faire une recherche sur l’ensemble de la table. Techniquement, il y a plusieurs façons d’implémenter un index. Le B-Tree est le plus courant. Après avoir expliqué le principe de l’index B-Tree, Markus déroule les détails d’implémentation, et les évolutions au cours des années, dans PostgreSQL. La dernière nouveauté de la version 11, c’est qu’on peut stocker dans l’index des données non-indexées. Cela permet donc un gain de performance dans certains cas précis : une requête avec filtre sur les données indexées, et qui renvoie les données stockées dans l’index (mais sans filtre ni tri sur les données non-indexées). Un autre intérêt d’un tel index, c’est qu’il documente de facto quelles sont les données « clés » et les données « valeur ». Moralité : quand vous le pouvez, utilisez les index B-tree incluant des données non-clés ! Vient après une séance de questions-réponses qui donne quelques informations supplémentaires intéressantes.

  • On ne peut pas mettre de données calculées comme données non-indexées dans l’index B-tree.
  • La taille maximale de données indexées est 2,6 ko.
  • Globalement, dans les bases de données, c’est le nombre d’index qui pose problème, plus que la taille des index.

12 :00 Tout le monde a faim mais la matinée n’est pas terminée. Stephanie Baltus explique ce qu’est une MATERIALIZED VIEW : c’est une sorte de table qui met en cache des résultats – souvent dans un but de performances, notamment parce que les données proviennent de sources externes. Elle explique comment elle (avec son équipe) a décidé d’en utiliser pour son application web JobTeaser, mais est tombée dans tous les pièges de ce merveilleux outil. Un vrai thriller ! Il y a tout d’abord une première tentative d’optimisation de l’application, avec des tables classiques, sans vue matérialisées : les performances étaient déplorables. Ensuite un premier essai avec une vue matérialisée, les performances étaient très bonnes dans l’environnement de test, mais ont été catastrophiques en production. La cause : le rafraîchissement « classique » d’une vue matérialisée, qui nécessite un verrou sur la vue entière, pendant un court instant. Un instant où personne n’utilise l’application, pour un site web ayant des millions d’utilisateurs, cela n’arrive jamais ! Finalement la solution adaptée à un tel cas est de rafraîchir la vue matérialisée avec le mot-clé REFRESH CONCURRENT et non pas REFRESH. En guise de conclusion, un conseil : lisez la doc, elle bien faite, et en cas de doute, lisez le code source, il est très clair !

12h20 Pause-midi bien méritée. De délicieux petits fours nous attendent dans divers petits stands (dommage qu’il n’y ait pas d’indication, on fait la queue et on découvre à la fin ce pour quoi on a fait la queue).

13 :50 C’est reparti ! Christophe Pettus nous emmène dans un voyage vers l’infiniment grand (en termes de taille de base de données). Que se passe-t-il quand la base de données grossit ? Gérer une petite base de données, c’est facile, tous les outils fonctionnent bien, pas besoin de s’intéresser particulièrement au paramétrage. Tant que la base de données tient dans la mémoire de l’ordinateur, tout va bien. Et si elle dépasse un peu, le premier conseil est simple : ajoutez de la mémoire à votre serveur ! La situation devient plus sérieuse lorsque vraiment la base ne tient plus en mémoire (soit quelques Gigaoctets). Dans ce cas il faut essayer d’y mettre au moins les plus gros index. Utiliser PITR pour les sauvegardes, parce que les outils pg_dump/pg_restore ne sont plus adaptés. Et mettre en place le load balancing. Quand la base atteint 1 Téraoctet, il faut sortir l’artillerie lourde : partitionner les tables, utiliser des disques ultra-performants, et mettre en place toute une architecture redondante pour le failover et le load balancing. Les sauvegardes ne peuvent être qu’incrémentales. Si la base de données grossit encore, il faut l’exploser : diviser en bases plus petites (séparation des archives, du datawarehouse et de la partie transactionnelle) …

14 :45 Utiliser PostgreSQL pour se connecter à des sources de données tierces, c’est possible. Et pas seulement à d’autres bases de données relationnelles telles que SQL Server ou Oracle, comme le montre Stefanie Janine Stölting, qui vient présenter la notion de Foreign Data Wrapper (FDW, pour les intimes). C’est qu’il existe des FDW pour plein de sources de données : MongoDB, Hadoop, mais encore IMAP, HTML ou même fichier CSV ou flux RSS. PostgrSQLs peut ainsi lire des données dans des bases externes et, pour certaines d’entre elles, écrire aussi. Stefanie aurait même obtenu de meilleures performances en écrivant dans une base Oracle à l’aide de PostgreSQL+FDW qu’en écrivant dans Oracle directement. Et cerise sur le gâteau, PostgreSQL peut effectuer des jointures sur toutes ces sources de données externes, comme le montre un exemple avec une jointure entre SQLite, deux serveurs PostgreSQL et un fichier CSV. Elle termine par l’intérêt d’utiliser des MATERIALIZED VIEW en association avec les FDW, ce qui nous rappelle furieusement la dernière conférence de la matinée.

15 :50 La temporalité des données, comme l’explique Miroslav Šedivý, c’est le fait de garder trace que certaines données changent au cours du temps. Par exemple, si une entreprise déménage de Boulogne à Paris en mars 2015, puis de Paris à Londres en novembre 2019, on stocke en base l’adresse Boulogne pour la période [2004 -février 2015] et l’adresse Paris pour la période [mars 2015- octobre 2019] et enfin Londres pour la période [novembre 2019-]. Cette manière de procéder est assez habituelle dans le monde des bases de données. Mais l’intérêt de PostgreSQL, c’est qu’il existe un type de données adapté aux intervalles, qu’on nomme RANGE, et des opérateurs comme par exemple && : se chevauchent, @> : contient. Avec tout cela on peut mettre des contraintes pour s’assurer de la cohérence des données, à savoir le non-chevauchement des intervalles. Miroslav Šedivý nous montre une bonne façon de modéliser les données, en joignant deux tables représentant une même entité – l’une contenant les données intangibles, l’autre les données dont on veut garder la trace, sur lesquelles portent diverses contraintes. Et pour complexifier le tout, il présente le cas de la « bitemporalité », parce qu’on peut avoir besoin à la fois de tracer les moments où les données ont changé, et les moments où les changements ont été connus. Comme quoi, avec de bons outils, on peut faire simplement des choses compliquées !

16 :45 Pour terminer, Flavio Henrique Araque Gurgel présente l’infrastructure d’un grand acteur du web : Le Bon Coin. Cette infrastructure est basée sur PostgreSQL, elle a évolué pour atteindre une centaine de serveurs PostgreSQL aujourd’hui, avec des serveurs maîtres, des esclaves, des serveurs dédiés à certains jobs ... Côté hardware, l’entreprise n’a pas lésiné sur les moyens : disques de la meilleure qualité en RAID 10, réseau de grande bande passante, redondance des alimentations, toute la panoplie des bonnes pratiques y est. Les sauvegardes et restaurations de données se font selon une stratégie bien définie - et les sauvegardes sont testées régulièrement, c’est important. Le monitoring c’est un immense écran avec des tas de points verts (un pour chaque serveur physique) ainsi que des courbes qui renseignent en temps réel sur l’activité de l’ensemble. Tous les serveurs ont la même version de PostgreSQL. Une mise à jour de l’ensemble dure 3 heures, cela se fait en mettant à jour les serveurs dans un ordre bien défini, de telle manière à ce que le site soit toujours opérationnel.

18 :00 Ce fut une journée intense ! PostgreSQL est un logiciel qui non seulement a toutes les qualités d’une base de données relationnelle, mais qui aussi met à disposition de nombreux petits outils très pratiques. Il est en perpétuelle évolution, soutenu par une communauté bien active. Ce fut un vrai plaisir de voir tout ce qu’on peut faire avec– et un seul regret, c’est de ne pas utiliser toutes ces fonctionnalités au quotidien !

Le site web de l’événement

Alexis BEURAUD, le 1 avril 2019