LOXODATA

Retour de PGConf.EU 2022 à Berlin

2022-11-04   2795 mots, 14 minutes de lecture   Philippe

De retour de PGConf.EU 2022

La conférence européenne PostgreSQL 2022 s’est tenue du 25 au 28 octobre 2022 à Berlin au Mariott Hotel. Initialement prévue en 2020, la pandémie de COVID 19 a obligé les organisateurs à reporter l'évènement en 2022. Fort de cette absence, cet évènement a rassemblé cette année 604 participants.

C’est avec plaisir que l’on a pu rencontrer à nouveau les contributeurs au projet PostgreSQL, sous des températures inhabituellement clémentes pour cette saison.

Loxodata était Partenaire Bronze de la conférence PGConf.EU 2022, « Bronze Partner of PGConf.EU 2022 », et à ce titre, nous avions notre logo sur la page du site de l'évènement.

Comme toujours, la conférence commençait par une journée de formation dispensée par différents partenaires de l'évènement. Ont suivi les trois jours de conférence à proprement parler. Comme à son habitude, la conférence proposait trois sessions en parallèle, plus une pour les partenaires.

Le programme de la conférence sur le site : PGConf.EU 2022

Voici une sélection des sujets auxquels nous avons assisté, devant faire un choix parmi toutes les sessions proposées.

Jour 1

Le premier jour, l'équipe organisatrice nous attendait avec notre badge et des goodies fournies par les différents partenaires de l'évènement. Magnus Hagander et Vik Fearing ont ensuite ouvert la conférence par une petite présentation, pour donner la main au premier intervenant, Peter Boncz.

Peter Boncz nous a présenté en session d’ouverture les travaux de recherche sur le langage GQL (Graph Query Language) et SQL/PGQ (Property Graph Query) et sa possible intégration au prochain standard SQL. C'était une présentation très dense et technique pour une ouverture de conférence, histoire de se mettre dans le bain assez rapidement.

Présentation par Yugo Nagata de la mécanique interne des triggers (déclencheurs) sous PostgreSQL, les cas d’usage, comment ils fonctionnent, comment ils sont déclenchés, et leur imbrication dans le catalogue système.

Henrietta Dombrovskaya nous éclaira sur ses travaux autour du modèle bitemporal en lieu et place d’un changelog. Elle a expliqué comment reconstruire un changelog depuis ce modèle, lorsque l’on souhaite faire du timetravel sur les données. Elle nous présenta les fonctions bitemporales, et la différence entre effective time (date d’application) et asserted time (visibilité) pour arriver aux time regions.

Tomas Vondra nous présenta les index BRIN, les avantages et inconvénients à les utiliser. Il s’est notamment étendu sur la conservation d’une bonne corrélation des données pour éviter un effondrement des performances. De nouveaux opérateurs de classe font leur apparition en version 14 de PostgreSQL : minmax-multi pour mieux gérer les données mal corrélées, bloom pour les données aléatoires (UUID). Tomas proposa ensuite des idées d’améliorations futures pour les index BRIN : citons par exemple le rejeu d’insertion, le routage d’insertion, d’autres types de résumé, l’utilisation de ce type d’index pour le tri ou pourquoi pas pour accélérer count(*). C’est un bon terrain de jeu pour ceux qui veulent entrer dans le code, car il est isolé. Terrain de jeu qui gagnerait à être mieux connu.

Présentation d’un cas d’usage de PostgreSQL en production chez GitLab et comment ils ont réussi à décomposer leur architecture pour la rendre plus efficace et évolutive.

Hans-Jürgen Schönig nous donna quelques conseils sur l’utilisation de PostgreSQL. Par exemple, contourner la boucle locale lors de test pour s’affranchir d’une latence réseau supplémentaire, ou ordonner les colonnes d’une table correctement selon ses types pour gagner en espace disque, l’utilisation de l’extension pgstattuple et bien d’autres.

Dave Pitts et Derk van Veen nous livrèrent leur expérience au sein de Adyen sur le phénomène de Write Amplification de PostgreSQL (lors de la mise à jour d’une ligne, tous les index affectés doivent être mis à jour également). Ils ont expliqué comment les mises à jour Heap Only Tuple (HOT updates) permettent de pallier ce phénomène et comment le réglage fin du paramètre fillfactor permet de gagner encore en efficacité : plus de HOT updates, moins d'écriture de WAL, moins de bloat de table et index; le monitoring de ces paramètres (notamment pg_stat_user_tables) avec des outils comme Prometheus et Grafana est également présenté.

Divya Sharma, de chez AWS, nous présenta l’utilisation des CTEs matérialisées, leur usage et impact et quand les utiliser. Avant la version 12 de PostgreSQL, les CTEs étaient toujours matérialisées, depuis c’est une option qui peut être spécifiée, à ajuster pour permettre au planificateur de requêtes de travailler le plus efficacement possible.

Renee Philipps nous présenta les types de données utilisables sous PostgreSQL d’un point de vue qualité en rappelant les piliers d’une bonne donnée : complétude, validité, précision et cohérence, et les travers de l’utilisation de certains types, comme le type numérique et sa taille de stockage, le type monétaire ou les booléens en lieu et place de labels divers et variés sujets à erreur d’interprétation.

Hannu Krosing nous présenta ses travaux concernant la fonction COPY et son ouverture à d’autres formats et protocoles de transports utilisables dans des environnements cloud, l’idée étant de se baser sur le système d’extension de PostgreSQL, comme utilisé avec les FDW et les méthodes d’accès d’index de tables.

Sarah Hoffman nous livra les secrets de l’architecture de OpenStreetMap et l’utilisation de PostgreSQL depuis 2006 en version 9.5, avec un serveur primaire, cinq secondaires, un volume de 14TB. Sarah nous a fait part d’une possible migration prévue vers la dernière version 14 ou 15 de PostgreSQL.

Social event

Le premier soir se tenait la soirée de la communauté au Alte Münze où il était possible de discuter avec tous les participants autour de boissons et amuse-bouche, si vous étiez là tôt.

Qu'à cela ne tienne, nous nous mîmes à la recherche d’un endroit pour dîner à Berlin après 21 heures : et bien ce ne fut pas facile étant donné la rigueur sur les horaires allemands de restauration.

Jour 2

Gregory Stark nous a fait part de sa vision sur le futur de l’observabilité au sein de PostgreSQL, et les changements à apporter au coeur de PostgreSQL, comme la prise en charge en natif du format OpenMetrics déjà utilisé au sein de nombreux outils de monitoring, la mise en place d’un background serveur HTTP livrant les métriques, l'évolution apportée par la version 15 de PostgreSQL avec le chargement des statistiques serveur en mémoire. Cependant, il reste de nombreuses questions auxquelles répondre comme la cohérence des métriques et la compatibilité entre les versions majeures de PostgreSQL.

Laurenz Albe nous a partagé son expérience sur la mise en place d’une instance PostgreSQL et sa configuration, notamment le choix d’un pool de connexion, le calcul de son dimensionnement, sa topologie. Cela afin d’obtenir une capacité de traitement élevé, en s’affranchissant de certains préjugés qui pourraient nuire au final aux performances des applications.

Devrim Gündüz et Christoph Berg, respectivement responsables des dépôts PostgreSQL des distributions RedHat et Debian, nous ont livré leur travail quotidien au maintien de ces dépôts et l’assurance qualité des paquets hébergés, les différences entre les dépôts officiels des distributions et ceux du PGDG et comment contribuer sur les différents projets.

Heikki Linnakangas nous présenta les travaux en cours autour de Neon, un nouveau système de stockage open source pour PostgreSQL pour le cloud, séparant le calcul (instance PostgreSQL) du stockage (système de stockage Neon). Lors de la phase d'écriture, les WALs sont envoyés aux Safekeepers pour assurer la durabilité des données puis transmis aux Pageservers pour être réordonnés et envoyés au stockage cloud. Pour la lecture, les WALs sont rejoués pour reconstruire à la demande les pages demandées. Neon offre également la possibilité de créer des branches de la base de données à l’image de Git comme pour un PITR mais dont la granularité se situe au niveau d’une page de données.

Bruce Momjian nous présenta l’un des sujets récurrents autour de PostgreSQL : MVCC l’acronyme pour Multi Version Concurrency Control, ou la mécanique interne de PostgreSQL pour assurer la cohérence des données en utilisant un modèle de version multiples des données.

Stephen Frost, CTO chez CrunchyData, nous a livré l'état de l’art autour du TDE (Transparent Data Encryption) sur PostgreSQL, qui consiste à chiffrer les données par le moteur de la base de données. Stephen nous a exposé les différents vecteurs d’attaques et leur criticité pour les données au repos, en transit et en utilisation. La première étape vers le TDE est la création d’un système de gestion de clés de sécurité, puis le chiffrement des pages (tables et index), WALs, fichiers temporaires et l’authentification des utilisateurs. Stephen encourage la communauté à se pencher sur les patchs proposés afin de faire avancer le sujet du chiffrement natif au sein de PostgreSQL.

Taras Kloba nous a proposé un benchmark de différentes solutions d’instances PostgreSQL managées sur le cloud portant sur les traitements hybrides transactionnel et analytique. Les trois solutions testées sont : Google AlloyDB, Amazon Aurora et Azure CosmosDB. C’est HammerDB qui a été utilisé pour les tests, avec les spécifications open source TPROC-C dérivées des spécifications TPC-C définies par l’organisation TPC. Seules deux métriques sont retenues : TPM (transaction per minute) et NOPM (new order per minute). Au final, AlloyDB semble gagner le challenge en TPROC-C, malgré l’absence de distinction entre les écritures et les lectures.

Robert Haas, de chez EDB, nous partagea les freins à l’automatisation de la gestion de PostgreSQL par des outils utilisés actuellement pour d’autres produits logiciels. Une partie de la solution selon lui serait que PostgreSQL puisse proposer des interfaces propres à fournir les informations nécessaires aux produits tiers, une meilleure introspection pour fournir l'état de PostgreSQL avec les paramètres actuels de configuration d’une instance.

Jour 3

Tobias Bussmann nous a fait le plaisir de nous parler des collations au sein de PostgreSQL. Il a fait un rappel de ce qu’est une collation, une locale, comment elles sont supportées dans PostgreSQL, les inconvénients dans l’utilisation de l’une ou l’autre et les dangers de corruption de données lors de changement de collations, les avantages à utiliser les versions de collation. Il propose d’utiliser dorénavant la collation ICU.

Robert Haas nous parla cette fois-ci des améliorations apportées à l’outil pg_basebackup() dans la version 15 de PostgreSQL, ses nouveaux algorithmes de compression, la compression côté serveur, le choix de la cible des sauvegardes (locale ou sur le cloud), le rapport d’avancement de la sauvegarde intégré dans le protocole, et enfin la possibilité de passer des options supplémentaires aux outils. Robert nous partagea son opinion sur les sauvegardes parallèles et incrémentales, et sa vision du futur, à savoir ce que devrait proposer PostgreSQL en sauvegarde native.

Ilya Kosmodemiansky nous proposa une présentation sur les transactions, avec une brève introduction aux concepts derrière les transactions ACID et les algorithmes s’y rapportant, faisant écho à la présentation de Bruce Momjian sur MVCC, puis une approche un peu plus pratique des transactions au sein de PostgreSQL et leur utilisation dans nos applications.

Ronan Dunklau, de chez Aiven, nous présenta un nouvel outil open source pgtracer permettant d’instrumenter PostgreSQL en se basant sur la fonctionnalité du kernel Linux eBPF (Extended Berkeley Packet Filter) afin de surveiller toutes les requêtes SQL d’un backend PostgreSQL, en activant au besoin l’instrumentation de ces dernières comme le ferait un EXPLAIN ANALYZE et à terme de récupérer les statistiques système et de les relier à chaque noeud.

Frits Hoogland, de chez Yugabyte, nous invita à plonger dans l’utilisation mémoire de Linux et les performances d’entrée/sortie qui sont intrinsèquement liées entre elles. PostgreSQL utilise des entrées/sorties mises en mémoire tampon (buffered IO). Grâce à l’utilisation de fio, Frits nous a démontré ce qui se passe réellement lors des écritures et lectures, l’important étant de connaître la mémoire disponible avec MemAvailable et non la mémoire totale MemFree. Les lectures, comme les écritures font pression sur la mémoire. De fait, les écritures peuvent être ralenties si la mémoire venait à manquer et des seuils sont définis par Linux comme vm.dirty_background_ratio ou vm.dirty_ratio, ratios donnés toujours par rapport à la mémoire disponible et non totale, au-delà desquels le système va montrer des signes de ralentissement. Frits nous a rappelé combien il est indispensable de tester par soi-même plutôt que de s’appuyer sur des tests de performance fournis par des vendeurs tiers.

Harald Armin Massa nous a proposé une présentation axée sur de la haute-disponibilité pour PostgreSQL en s’appuyant sur les notions de RTO et de RPO, et quelles seraient les implications financières des stratégies adoptées. Harald a rappelé l’importance de tester les sauvegardes et les temps de reprise d’activité et incite à utiliser pg_receivewal en synchrone.

Boriss Mejias, de chez EDB, nous proposa un tour de PostgreSQL sur le partitionnement de tables déclaratif et comme indiqué dans le titre, il n’y a pas de magie, dans le sens où il faut bien choisir sa clé de partitionnement. Il nous démontre avec EXPLAIN et ANALYZE comment l'écriture d’une requête SQL utilisant la clé de partitionnement dans ses clauses peut améliorer significativement les temps de réponse, en élaguant les tables qui ne sont pas nécessaires pour éviter le parcours de toutes les partitions. Il nous présenta également les différents types de partitionnement (range, list, hash). Puis la maintenance simplifiée des partitions pour détacher ou supprimer une partition de table, la création d’un index sur la table parente qui ne crée pas un index global mais bien un index par partition, l’importance de la partition par défaut et des contraintes à créer, et enfin l’import d’une nouvelle partition sur laquelle il faut également veiller à créer les contraintes avant d’attacher la partition pour éviter de devoir scanner cette dernière.

Jonathan S. Katz, de chez AWS, nous présenta comment il serait possible de dimensionner dynamiquement des instances PgBouncer pour des déploiements de PostgreSQL sur Kubernetes. L’idée est de passer par un service Kubernetes et d’utiliser l’outil open source Karpenter afin d’allouer une taille adaptée d’instance de calcul et maîtriser les coûts pour régler PgBouncer finement pour sa charge de travail.

Mehboob Alam, de chez OrioleDATA, nous présenta la solution OrioleDB : un nouveau moteur de stockage pour PostgreSQL se présentant sous la forme d’une extension. Mehboob a expliqué le caractère extensible de PostgreSQL et comment OrioleDB a été initié. Mehboob présenta de nombreux benchmarks donnant l’avantage à OrioleDB par rapport à PostgreSQL mais le détail de ces tests n’a pas été donné.

Lightning Talks

Incontournables des conférences PostgreSQL, les lightning Talks sont des présentations durant moins de cinq minutes sur des sujets au choix de l’intervenant.

Sujets parfois sérieux, parfois moins, mais cela reste un excellent moment.

Conclusion

La PGConf Europe est un des évènements majeurs dans l'écosystème de PostgreSQL. Les chiffres parlent d’eux-même, avec un engouement confirmé à chaque édition et le record de participation de cette année 2022 avec rappelons-le : 604 inscrits.

C'était le premier évènement PostgreSQL pour ma part, et je n’ai pas été déçu par cette édition riche en présentations de tout niveau, et touchant à des sujets divers et variés. La communauté PostgreSQL est aussi bienveillante et a à coeur d’intégrer de nouveaux contributeurs et utilisateurs, et tout est fait pour faciliter l’arrivée des nouveaux, alors il ne faut pas se priver !

On peut remercier l'équipe PostgreSQL en charge de l’organisation de l'évènement, et également les équipes du Mariott Hotel de Berlin qui ont assuré la restauration.