Retour sur le pgDay Paris 2019
JoliCode était présent au pgDay Paris 2019 qui se tenait le 12 mars. Le pgDay, c’est des passionnés originaires de toute l’Europe qui se retrouvent à Paris le temps d’une journée pour échanger autour du merveilleux SGBD Open Source qu’est PostgreSQL. Des événements similaires auront bientôt lieu au Danemark, en Allemagne, en Italie…
Cette conférence a lieu intégralement en anglais et comme l’a déjà énoncé mon collègue sur un précédent article, mon avis est aussi mitigé sur ce point.
“La particularité de cette conférence (bien qu’elle soit organisée en France) est de ne proposer que des conférences en langue anglaise. Nous sommes partagés sur l’intérêt. Certes, cela permet d’attirer du monde à l’international mais l’accent de certains speakers est parfois horrible pour nos délicates oreilles. Nous pouvons également regretter que cela ne rende pas accessible certains contenus à des personnes qui ne maîtrisent pas la langue anglaise (dans nos métiers, c’est un prérequis, mais ce n’est malheureusement pas maîtrisé par tous)”
Section intitulée travailler-avec-d-autres-gensTravailler avec… d’autres gens !
par Renee Phillips
Renee attaque la journée en beauté en nous montrant pourquoi être plus inclusif et comment y parvenir. Son talk tient plus de la sociologie que de PostgreSQL, mais c’est une bonne piqûre de rappel pour toutes les entreprises (et pas seulement dans l’informatique). Elle a su mettre en avant les détails auxquels on ne pense pas toujours et les phrases à première vue anodines qui mettent une mauvaise pression aux petits nouveaux.
Section intitulée la-magie-d-une-requete-sqlLa magie d’une requête SQL
par Dimitri Fontaine
Avec une simple ligne de commande, pgloader.io migre votre ancienne base de données vers PostgreSQL, alors plus d’excuse pour ne pas utiliser ce qui suit ! Et qu’est-ce qui va suivre ? Une démo en live coding et plein de conseils.
D’abord, la pratique ! Chaque jour, prenez donc quinze minutes pour répondre en SQL à une question au hasard sur votre base de données.
Personne n’écrit ses requêtes d’une traite. Cela prend un peu de temps et nécessite de jouer avec ses tables en plusieurs itérations.
Un petit rappel, lorsque notre requête contient des dates dans une clause WHERE, on inclut la date de début et on exclut la date de fin :
WHERE some_var >= begin_date
AND some_var < end_date
Nous avons aussi eu quelques exemples intéressants :
- generate_series() pour générer un calendrier mensuel + la dernière semaine du mois précédent couplé avec l’incontournable over partition by et date_trunc() (équivalent Postgres de extract()).
select cast(date as date) as date,
to_char(date, 'Dy') as day,
coalesce(dollars, 0) as dollars,
lag(dollars, 1)
over(
partition by extract('isodow' from date)
order by date
)
as last_week_dollars
from
generate_series(date :'start' - interval '1 week',
date :'start' + interval '1 month' - interval '1 day',
interval '1 day'
)
as calendar(date);
Cet exemple provient directement de la slide présentée.
- lateral qui permet dans une sous-requête de faire référence à la requête principale.
- quelques opérateurs inhabituels :
\>>(contient),<@>et<->qui sont utilisés comme opérateurs de distance dans l’exemple qui suit.
Nous avons vu les possibilités offertes par Geolite, une extension qui permet d’effectuer très simplement des requêtes de géolocalisation, avec l’exemple inspirant d’une application qui trouve en quelques millisecondes le pub le plus proche de votre conférence.
Dimitri nous a enfin montré comment afficher très simplement de charmants histogrammes dans la console psql.
bucket | range | freq | bar
--------+---------+-------+--------------------------------
1 | [10,15) | 52 |
2 | [15,20) | 1363 | ■■
3 | [20,25) | 8832 | ■■■■■■■■■■■■■
4 | [25,30) | 20917 | ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
5 | [30,35) | 20681 | ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
6 | [35,40) | 9166 | ■■■■■■■■■■■■■
7 | [40,45) | 2093 | ■■■
8 | [45,50) | 247 |
9 | [50,54) | 20 |
10 | [54,55) | 1 |
(10 rows)
Section intitulée n-oubliez-pas-les-vues-materialiseesN’oubliez pas les Vues Matérialisées !
par Stéphanie Baltus
Une vue matérialisée (« Mat View » pour les intimes) a pour particularité de stocker son résultat, contrairement à une vue simple. Elle est mise à jour sur demande et se comporte comme une table.
Elles sont très utiles pour mettre en cache des résultats lors de requêtes lentes. Cependant, il faut faire attention à sa stratégie de rafraîchissement : elles lockent les tables dont elles ont besoin.
Conclusion ? On adore, mais soyez attentif à la doc, et n’hésitez pas à jeter un oeil au code source en C qui est très bien commenté et facile à lire.
Section intitulée casser-postgresql-a-grande-echelleCasser PostgreSQL à grande échelle
Qu’est ce qui va casser dans votre base de données, et à quel moment de sa vie ?
Rien et jamais, parce que PostgreSQL c’est trop génial. 🤓
Ok, dans le monde réel, plein de soucis vont se présenter.
Pour bien gérer les changements de Postgres au fil de la croissance de sa base, il y a quelques détails à connaître. Autour de 10GB, tout va vite, ce qui est à la fois une bénédiction et une malédiction, on peut se permettre de ne pas optimiser des requêtes qui deviendront vite assez gourmandes… En terme de backup, un pg_dump fera l’affaire. On conseillera d’activer tous les logs afin de savoir ce qui se passe quand la base grossit. On pensera aussi à bien mettre à jour sa version de Postgres afin de ne pas être à la traîne : plus on a de versions de retard, plus la mise à jour devient complexe !
Après 100GB, on va commencer à penser à la mémoire. Avoir une taille de cache (effective_cache_size) supérieure au plus gros index est une bonne idée. Attention, avoir un maximum de mémoire c’est bien, mais ça ne permet pas d’écrire plus vite ! Concernant les backups, un pg_dump ne fera plus l’affaire, on utilisera des PITR : le nouveau pgBackRest, le bon vieux WAL-E ou encore un programme maison. C’est aussi le moment d’utiliser des outils de monitoring. Au moins pgBadger (analyseur de logs), éventuellement aussi le module pg_stat_statements (traqueur de statistiques d’exécution) et pganalyze (monitoring de performances). Il faudra les regarder régulièrement afin de trouver les requêtes qui peuvent nécessiter de l’attention. Certains index vont briller par leur absence, créez-les ! Mais avec modération, ceux-ci demandent beaucoup de stockage. Il faudra aussi penser à mettre à jour sa base avec pg_upgrade.
Lorsqu’on atteint 1TB, on n’a plus jamais assez de mémoire. Le load balancing va devenir vraiment important. Les opérations de vacuum vont commencer à prendre beaucoup de temps. Augmentez autovacuum_workers uniquement si vous avez plus de 500 tables. Envisagez les index partiels, alternatifs, et le partitionnement (sharding) (amélioré depuis PostgreSQL 10), ainsi que l’exécution de requêtes en parallèle.
Quand on arrive sur une base de 10TB de données, les backups devraient devenir des snapshots du système de fichiers.
Sur une taille encore plus éléphantesque, eh bien… PostgreSQL peut toujours le gérer. Il faudra tout de même penser à sortir de la base tout ce qui est uniquement de l’archivage. Le tout est de ne pas s’encombrer d’outils inutiles trop vite, et de toujours penser plus loin que la dimension actuelle de la base, afin d’être prêt à prendre en main l’étape suivante de sa croissance.
Section intitulée strong-grosses-bases-de-donnees-plein-de-serveurs-sur-place-sur-le-cloud-attrapez-les-tous-strongGrosses bases de données, plein de serveurs, sur place, sur le cloud – attrapez les tous !
par Flavio Gurgel
Flavio, seul DBA de Leboncoin, nous a montré l’impressionnante architecture de leur boîte (Le schéma complet ne tient pas sur la slide), quelques problèmes techniques et physiques qu’ils ont rencontré, et leurs solutions.
Pour la disponibilité, investir dans un bon matériel qui ne lâchera pas, c’est la base. Ils ont mis de bonnes garanties dessus et ne laissent rien au hasard : les serveurs ont deux sources d’alimentations de provenance différente, tout le matériel a des batteries indépendantes, une bonne RAM ECC, des disques en RAID 10 (intransigeant sur ce point), de bons ventilateurs, des alertes du système de monitoring…
Pour la réplication, ils ont une machine de standby minimum par serveur + celle(s) de load balancing. Ils font aussi attention à la localisation des Data Centers dans lesquels leurs données sont répliquées. Par exemple, en Île de France, beaucoup se situent le long de la Seine. Et si celle-ci venait à déborder ? Dites adieu à vos données ainsi qu’à leur réplication !
Des backups sont fait régulièrement. Dans le même esprit que le talk sur Comment casser PostgreSQL, Flavio nous expliquait que plus la base grossit, plus les backups doivent être faits régulièrement : tous les mois si moins de 10GB, toutes les semaines jusqu’à 1TB, et tous les jours au delà.
Ils utilisent quelques outils de Monitoring et d’alertes : Xymon pour tous les types de problèmes possibles, du matériel au logiciel, ainsi que pour les données d’OS. Datadog pour les développeurs. pgwatch2 pour monitorer les bases de données et voir quelles requêtes demandent plus de ressources, le runtime moyen, le nombre d’appels de requêtes, etc et même le nombre d’appels de fonctions ! avec Grafana pour le front.
PostgreSQL est mis à jour très régulièrement. Flavio insiste sur le fait de garder la même version partout.
PostgreSQL est présent sur plus de 70 serveurs chez Leboncoin. Ils utilisent du NoSQL pour le monitoring, et Elasticsearch pour leur recherche, mais en aucun cas pour stocker !
Section intitulée strong-cloture-strongClôture
En bonus, il y a eu un tirage au sort qui a fait gagner plein de goodies aux trois gagnants !
SELECT firstname, lastname FROM attendees ORDER BY random() LIMIT 1;
J’ai trouvé ça super sympa.
L’ambiance était très détendue, les organisateurs et les speakers étaient très accessibles, et ça échangeait beaucoup en anglais. Les talks étaient assez hétérogènes dans leur contenu : d’un aspect socio à des démo débutantes jusqu’à des démos plus poussées, et du système. Très complet !
Toutes les slides sont disponibles sur le site de l’événement.
Cet article porte sur la conférence pgDay Paris 2019.
