Labels

Le rêve de tout enfant - devenir DBA ?

J'ai eu le plaisir de présenter une keynote à PyCon France 2025. C’était mon premier PyCon FR et je l’ai beaucoup apprécié. J'espère avoir l'occasion de revenir.

Je partage ici la version annotée de mes slides, et je publierai le lien vers l'enregistrement dès que ce sera disponible.

J'ajouterai également les alt-text pour les slides, mais sachez que les infos pertinentes qui se trouvent dans les slides sont déjà repliquées dans le text.


J'étais ravie d'etre invité faire cette keynote, et surtout de pouvoir parler de mon sujet préféré : les bases de données.

Parce que, gérer les bases de données, c'est le rêve de tous les enfants, n'est-ce pas ?!

Je suis Karen Jex, Senior Solutions Architect à Crunchy Data (qui fait maintenant partie de Snowflake).



Mon père m'a appris à compter en binaire avant que je sache vraiment compter en décimal.



Je passait des heures à jouer à Chuckie Egg vers l'âge de 8 ans.



Peu apres, j'ai appris à coder en BBC BASIC sur l'ordi que mon père m'avait fabriqué à partir d'un kit.



Plus tard, j'ai fait un license en maths et un master en informatique.



Et pourtant petite, j'ai rêvé de devenir prof, avocate, réalisatrice, et même (à une époque) dinosaur (?!)

Tout sauf informaticienne, et surtout pas DBA !



Quand on demande à un enfant « Que veux-tu faire quand tu seras grand ? » je doute que la réponse soit « DBA ».

J'ai demandé « Qui, dans cette salle, a dit vouloir devenir DBA quand il ou elle serait grand ? »

Et personne ne s'est levée la main.



Je travaille uniquement avec les bases de données pendant plus de 25 ans.

Comme vous voyez sur l'image, j'ai tenu des rôles aussi « variés » que « DBA junior », « DBA sénior », « Experte Base de Données » (ce qui veut dire simplement que je ne sais faire que ça) et « Consultante Base de Données Sénior ».

Mon rôle actuel (Senior Solutions Architect) est le seul qui ne contient pas le mot « bases de données » ou « database », mais je ne travail toujours qu'avec les bases de données.



Et parce que ça, ce n'est pas assez de bases de données:

Et même moi, je n'ai jamais rêvée de devenir DBA !



Je me sens obligé de vous assurer que j'ai quand même une vie en dehors des bases de données (si, si) donc me voici toute contente, couverte de boue en sortie VTT.

Je vis dans un petit village à la montagne en Haute Savoie et quand je ne suis pas en train de jouer avec ou de parler des bases de données, j'adore faire du vélo (route, gravel ou VTT, selon le jour et selon mon humeur).



En préparant cette conférence, je me suis dit que peut-être j'ai eu tort, et qu'en fait il arrive que les enfants rêvent de devenir DBA.

J'ai donc décidé de faire quelques recherches pour valider mon hypothèse. Après tout - je suis une DBA dans l'âme, les données c'est la vie…

Heureusement, il y a des gens sérieux qui ont déjà fait tout le travail.

Ils ont posé la question de ce qu'ils veulent devenir à des enfants,

et ils ont posé la questions de ce qu'ils voulaient devenir à des adultes.

J'ai été étonnée d'apprendre que DBA n'apparaît dans aucune des listes !



Il y avait beaucoup de vétérinaire ou médecin.e,



pas mal de footballeur / footballeuse,



astronaute, évidemment,



et même ingénieure.



Mais pas DBA.

J'ai du improviser, parce qu'on ne trouve même pas d'image de DBA !

Donc je dois avouer que peut-être, finalement, ce n'est pas tout le monde qui aime autant que moi les bases de données.



La plupart des devs que je rencontre veulent simplement que la base de données fonctionne discrètement en arrière plan, afin qu'ils / elles puissent se concentrer sur le développement de leur application.

Et même moi - amoureuse de bases de données que je suis - je trouve que c'est une demande plutôt raisonnable.



Mais, le monde des bases de données change. Le rôle traditionnel du DBA est de moins en moins courant, et les devs doivent souvent gérer leurs propres bases de données.

Même si vous n'avez pas à vous en occuper vous-même, votre base de données represente souvent le cœur de votre application. Il est donc utile de savoir comment interagir avec elle.

Je souhaite donc vous parler de comment coexister avec les bases de données en tant que dev, et de ce que vous devez réellement savoir sur le sujet.



Evidemment, parce que moi, j'aime tant les bases de données, surtout Postgres, j'ai du mal à comprendre pourquoi tout le monde ne cherche pas à apprendre tout ce qu'il y a à savoir sur ça.

Si vous ne voulez pas parler constamment de la forme normale de Boyce-Codd, pourquoi pas ?

Si votre talent n'est pas de réciter les propriétés ACID des transactions, ou d'expliquer les différentes modes d'isolation des transactions (non seulement ce qui est indiqué par la norme SQL mais également l'implémentation dans chaque SGBD)...
alors que faites vous de votre vie ?

Venez me voir après si vous avez besoin d'autres idées pour lancer des conversations passionnantes lors de votre prochain dîner !



J'ai eu la chance d'assister à la conférence The Attentive Programmer (Le programmeur attentif) de Daniele Procida à PyCon Italia l'année dernière.

Daniele a parlé de l'idée d'écrire un programme d'amour, et j'adore l'ode à son appareil photo préféré qu'il a écrite en Python !

Cela m'a fait réfléchir à la manière dont j'exprimerais mon amour pour les bases de données.



Le langage de l'amour que j'ai choisi est, bien sûr, le modèle entité-relation.

Quelle belle façon de représenter n'importe quel objet du monde réel en termes d'attributs et de relations entre eux.

J'aime le fait qu'il y ait des règles, une syntaxe et des conventions.

J'aime la simplicité de la notation - le fait que quelques petites lignes suffisent pour transmettre autant d'informations.

À partir de ce petit extrait, par exemple, nous savons qu'un département peut avoir un ou plusieurs employés, et qu'un employé appartient à un seul et unique département.

J'aime la façon dont on peut utiliser la couleur et l'organisation des éléments dans le modèle Pour permettre même à un lecteur non-tech de comprendre les objets qui y sont représentés.

Je peux facilement me perdre pendant des heures dans la réorganisation d'un modèle entité-relation pour qu'il soit équilibré, joli, clair et ordonné.



Et quoi de mieux que d'utiliser mon langage d'amour pour décrire l'une de mes choses préférées : un cluster Postgres !

Je commence par mon cluster Postgres lui même, qui peut contenir une ou plusieurs bases de données.

Mon cluster peut également avoir un ou plusieurs rôles ou utilisateurs et un ou plusieurs tablespaces.

Chacune des bases de données peut contenir un ou plusieurs schémas, et chacune des tables appartiendra à l'un de ces schémas ainsi qu'à l'un des tablespaces.

On peut créer un index sur un ou plusieurs colonnes d'une table, et une colonne peut appartenir à un ou plusieurs index.

Je peux modéliser les permissions, d'autres objets (vues, des fonctions, des procédures stockées, des extensions)...

Je dois réfléchir à la manière dont les changements au fil du temps seront modélisés : est-ce que je veux garder l'historique ?

Mais j'ai dû m'arrêter là, car le but de cette conférence n'est pas de créer un modèle réaliste de mon cluster de bases de données.

Je voulais simplement montrer comment je pourrais « dessiner » mes bases de données avec amour !



Revenons donc au sujet de la conférence !

En fait, ça fait quoi, une DBA ?

(attention - si on n'a rien de gentil à dire, il vaut mieux se taire.)

Selon différentes définitions (je me suis renseigné auprès des services d'orientation, de fournisseurs de SGBD et de sites d'emploi) une DBA est une personne qui :

Utilise des logiciels spécialisés pour gérer et sécuriser les systèmes informatiques qui stockent les données d'une entreprise.

Trés bien. C'est clair.



Sauf que ça ne nous apprend strictement rien sur ce que fait une DBA de sa journée.

Alors, que fait réellement une DBA ?

J'ai créé une liste à partir des offres d'emploi et descriptions du rôle de DBA, et c'est assez longue !

Une DBA fait tout ou partie de ces tâches :



Mettre en place et maintenir des procédures de sauvegarde et de restauration.



Mettre en place des procédures de sécurité et et gérer l'accès aux bases de données.



Monitorer les bases de données.



Modélisation logiques et physiques des données.



Assurer une assistance et un dépannage, Souvent 24 heures sur 24, 7 jours sur 7.



S'occuper de l'installation et de la montée de version des logiciels de base de données.



Fournir une expertise, des conseils et une assistance base de données aux autres équipes.



Résoudre les problèmes de performances, et améliorer de manière générale les performances des bases de données.



Préparer les besoins futurs en termes de ressources des bases de données.



Créer des bases de données.



Surveiller les procédures de maintenance des bases de données.



S'assurer du respect des règles concernant la protection des données.



Que ça ?



Non, parce que puis, il y a les compétences demandées pour le rôle de DBA.

J'ai créé ce slide à partir des données fourni par IT Jobs Watch en 2023.

Il classe les compétences et aptitudes requises pour les postes de DBA en fonction de leur fréquence d'apparition dans les offres d'emploi au Royaume Uni.



En gros, ils demandent:

  • Compétences SQL et langages procéduraux
  • Intégration de données
  • ORM


Connaissance d'un ou plusieurs SGBD.



Connaissance de divers systèmes d'exploitation et environnements cloud.



  • Optimisation des performances
  • Migration de bases de données
  • Disaster recovery


Compétences sociales !

Je ne sais pas ce qu'ils veulent dire par là à propos des DBAs, mais lorsque j'ai vérifié récemment pour m'assurer que la liste était toujours à jour, les compétences sociales avaient une place encore plus haut dans le classement !



Ça continue avec

  • La Haute disponibilité
  • La Réplication
  • et plus encore


Cela fait beaucoup à savoir et à faire.



Et pour rendre les choses encore moins claires, il existe différentes « variantes » de DBA :

On distingue souvent le DBA de production et le DBA de développement.

Le DBA de développement travaille en lien avec les devs et crée et maintient l'environnement de base de données utilisée pour le développement.

Il transmet ensuite le relais au DBA de production, qui se concentrent sur les bases de données de l'environnement de production, surtout en ce qui concerne la disponibilité, les performances et la sécurité.



Dans certaines organisations, la distinction se fait entre le DBA application (qui s'occupe des aspects logiques de la base de donnees liés aux applications) et le DBA système (qui est responsable plus de ce qui concerne l'infrastructure physique).



En plus des DBAs de production et de développement, des DBAs d'application et de système, il y a également les DBAs Datawarehouse, DBAs cloud, architectes base de données, même des DBAs qui s'occupent d'un aspect en particulier de la gestion des base de données, par exemple la réplication ou les sauvegardes.

Les différents types de DBA diffèrent d'une entreprise à une autre et même entre équipes. La séparation des responsibilities n'est pas forcément très clair, et les rôles parfois s'entre-mêlent.



Mais - pas de panique - pas besoin d'être experte de tout ça.



J'ai beaucoup apprécié le discours de Katie McLaughlin lors de la DjangoCon Europe 2022 à Porto: « What should you have to worry about » (De quoi devriez-vous vous préoccuper ?)

Katie a souligné que même s'il est tout à fait possible d'utiliser Django en créant un serveur, en installant Django, Postgres et nginx et en le rendant accessible au monde, il y a alors toutes sortes de choses dont il faut se soucier, notamment :

  • La disponibilité du serveur et du réseau.
  • Les mises à jour du système d'exploitation, de Django, de nginx et de Postgres.
  • Les migrations de bases de données
  • La gestion des bases de données
  • Les sauvegardes...


Et si c'est vous qui vous faites du souci pour ces choses-là, Katie se demandait :

Etes-vous développeur Django ? Ou êtes-vous à la fois développeur Django, DBA, admin système, admin réseau, ingénieur full stack et très, très sous-payé ?



Vous n'avez absolument pas besoin de tout savoir sur les bases de données – je ne sais certainement pas tout sur le développement d'applications et même cette affirmation donne l'impression que j'en sais beaucoup plus que ce n'est le cas !

J'en sais juste assez pour pouvoir aider les développeurs à répondre à leurs questions concernant les bases de données.

De même, vous devez en savoir juste assez sur les bases de données pour vous permettre de faire vos taches de dev.



Voici l'ordre du jour d'une conférence que j'ai donnée il y a deux ans (2023) à PyCon UK, intitulée How to Keep your Database Happy ou « Comment garder votre base de données en bonne santé ».

J'ai présenté mes top 5 conseils pour mettre en place, sans trop d'efforts, un environnement de base de données robuste et performante.



  1. Vérifiez que certains paramètres de configuration clés sont correctement définis pour votre environnement et votre charge de travail.
  2. Assurez-vous de sauvegarder régulièrement votre base de données (et testez sa restauration).
  3. Avoir une architecture à haute disponibilité.
  4. S'assurer que les bons utilisateurs/applications peuvent se connecter à votre base de données et interagir avec elle.
  5. Mettez en place le monitoring necessaire afin de savoir ce qui se passe et de pouvoir réagir rapidement en cas de problème.


J'ai eu le temps de partager un aperçu d'à peu près 3 minutes pour chaque conseil !

Bizarrement, ce n'était pas assez de temps pour transmettre tous les détails de tout ce dont vous avez besoin de savoir pour vous occuper de votre base de données (soit tout ce que j'ai passé 25 ans à apprendre !)

Et cela ne concernait que le côté environment base de données. Nous n'avons même pas abordé les aspects liés aux applications : la conception de la base de données et des requêtes, la performance, les procédures stockées etc.



Si vous n'avez pas le temps, les compétences, l'envie ou l'infrastructure nécessaires pour vous occuper d'une base de données, il existe différentes options, notamment des services gérés, qui s'en chargeront pour vous.

Les grands fournisseurs de services cloud proposent des services de bases de données gérées, la société pour laquelle je travaille (Crunchy Data) dispose d'un service PostgreSQL géré appelé Crunchy Bridge, et il en existe beaucoup d'autres.

Et même si vous avez les compétences et l'envie, il peut être plus raisonnable d'externaliser certaines de ces tâches pour mieux utiliser votre temps et votre expertise.



Les titres d'autres présentations que j'ai donnée aux événements Python, Django et même Ruby servent à vous donner une idée des autres informations qui, selon moi, pourraient vous être utiles :

  • Tuning PostgreSQL to work even better
    (Optimiser PostgreSQL pour un fonctionnement encore plus performant)
  • Optimising your database for analytics
    (Optimiser votre base de données pour l'analyse)
  • Everything you wanted to know about databases but were too afraid to ask your DBA
    (Tout ce que vous avez toujours voulu savoir sur les bases de données sans jamais oser le demander à votre administrateur de base de données)
  • Database Troubleshooting for developers
    (Dépannage de bases de données pour les développeurs)
  • Anatomy of a database operation
    (Anatomie d'une opération de base de données)
  • Postgres Partitioning Best Practices
    (Meilleures pratiques pour le partitionnement en Postgres)

Regardons rapidement ce que j'ai voulu à ce qu'on retient de ces présentations.



Dans Tuning PostgreSQL to work even better, je parle du fait que Postgres est une base de données très appréciée par les développeurs et que l'une des choses que les développeurs disent apprécier particulièrement chez Postgres, c'est que « it just works » (ca fait son boulot).

Ce qui est une excellente nouvelle, car cela vous permet de vous concentrer sur ce que vous faites le mieux et de ce vous avez envie de faire.

Les valeurs par défaut des paramètres de configuration de Postgres permettent à un cluster Postgres d'occuper peu d'espace et d'utiliser peu de ressources, mais ils ne sont pas forcément adaptées à la taille et / ou à l'activité de votre base de données.

Mais il y a plus de 350 paramètres Postgres. comment savoir lesquels modifier et quel valeur mettre ?

Heureusement vous n'avez pas besoin de modifier ni même de connaître l'existence de la plupart d'entre eux. Une connaissance pratique d'une poignée de paramètres peut suffire.



Nous avons regardé comment voir et modifier les paramètres, puis j'ai listé les paramètres Postgres les plus importants ainsi que quelques règles pour les configurer en fonction de votre cas d'utilisation.

Le but était de partager ce que font ces paramètres, pourquoi ils sont importants, et comment les configurer pour que votre base de données fonctionne de manière optimale.



Votre base de données et votre code sont probablement optimisés pour vos activités quotidiennes (OLTP), mais le business veut souvent que la base soit utilisée également pour une activité d'analyse ou reporting (OLAP).

Cela veut dire des requêtes complexes sur plusieurs tables qui travaillent beaucoup de données.

Dans Optimising your database for Analytics (Optimisation de votre base de données pour l'analyse) j'ai parlé des implications du fait d'avoir une charge de travail mixte sur votre base de données et j'ai donné des conseils pour minimiser son impact sur les performances.



On a regardé :

  • La création d'une base de données à part (une base répliquée) pour l'analyse
  • Les paramètres de configuration
  • La création d'index adaptés
  • Pre-calculation / pre-aggregation des donnees (par ex. avec des vues matérialisées)
  • Le fait qu'on peut combiner les techniques


J'ai créé la presentation Everything you wanted to know about databases but were too afraid to ask your DBA (Tout ce que vous avez toujours voulu savoir sur les bases de données sans jamais oser le demander à votre administrateur de bases de données) initialement en tant que mini-formation pour mes collègues dev.

Je l'ai donnée ensuite en plusieurs formats différents ; d'une conférence courte de 25 minutes (c'etait quand meme juste) à un workshop de 2 heures.



On a fait un peu le tour en commencant par l'architecture d'une base de données, en passant par les rôles et utilisateurs, les différents objets d'une base de données (tables, vues, index...), les connexions et transactions, et le WAL ou write ahead log.

La doc Postgres faisait évidemment partie du tour !



Une présentation que j'ai donné en français - Dépannage de bases de données pour les devs.



Quasiment toute cette présentation est une partie “au secours” - comment réagir / qu’est-ce que je fais si l'une de ces choses arrive.

A la fin, il y a quelques conseils pour mettre en pratique ce que vous avez appris pour le renforcer et faire gagner en confiance.



Anatomy of a database operation (Anatomie d'une opération de base de données).



Ici, nous avons suivi le trajet d'une opération base de données a partir d'un click sur une appli web Django, vers une requête en base de données et l'envoie des résultats à l'utilisateur.

Les exemples et les détails dans toutes mes présentations sont spécifiques à Postgres, car (comme vous l'aurez déjà remarqué) c'est le système de base de données que je connais le mieux et que j'apprécie le plus.

Mais les notions et les méthodes utilisés sont souvent utiles pour d'autres bases de données.



Et pour finir, on a Postgres Partitioning Best Practices qui est née a partir de questions que les devs me posent souvent sur le partitionnement des tables dans Postgres.



J'ai regroupé les questions afin de parler de

  • Ce que c'est le partitionnement de tables, comment ça fonctionne, et les avantages.
  • Comment choisir une clé de partition et le type de partitionnement.
  • Les outils tels que pg_partman pour la gestion des partitions.
  • Comment partitionner des tables existantes avec un temps d'arrêt minimal.


Revenons donc à la liste des responsabilités d'un.e DBA.

J'ai souligné ce que je trouve le plus important a savoir pour un.e dev.



  • Des connaissances sur la sauvegarde et la restauration des bases de données.
    Que ce soit pour faire vos propres sauvegardes de vos environnements de dev, ou pour vous assurer que les sauvegardes soient en place et que les restaures fonctionnent si vous utilisez un service de base de données géré.
  • Je n'ai pas souligné sécurité, mais il est quand même pratique d'en avoir quelques notions -
    quel rôle doit posséder et manipuler les objets de la base de données,
    quels utilisateurs doivent se connecter et comment, etc.
  • Pareil pour le monitoring - ce n'est pas forcément à vous de le mettre en place, mais avoir une idée de ce qui signifie certains des indicateurs affichés sur le tableau de bord de votre base de données peut être utile.
  • La modélisation logique et physique ou au moins savoir lire un modele.
    Avoir une vision claire de la structure des données de votre système et de la manière dont elles s'articulent entre elles est très utile pour déterminer la meilleure façon d'écrire le code qui accède à ces données.
  • Normalement, vous n'aurez pas à assurer une assistance 24 / 24, 7 sur 7, mais être capable d'effectuer quelques opérations de dépannage de base sur la base de données pourrait vous faire gagner beaucoup de temps.
  • Optimisation des performances : si une une requête ou une partie de votre application fonctionne mal, vous allez vouloir trouver pourquoi et être capable d'améliorer les performances.
    Mieux encore, savoir écrire du code qui fonctionne bien avec la base de données dès le départ.
  • Que l'on soit DBA ou dev, on ne peut pas echapper aux RGPD.
    Oui, ça peut être pénible, mais il est de la responsabilité de chacun.e d'entre nous de veiller au respect des règles de protection des données.


Pour revenir à la liste dont on a parlé toute à l'heure des compétences et capacités requises pour les DBAs; sont elles toutes réellement nécessaires ?



  • SQL, oui. Je sais, je sais, tout le monde utilise des ORM. Mais si vous voulez comprendre ce que fait l'ORM, et éventuellement l'améliorer, il n'y a pas de meilleur moyen que de comprendre et d'être capable d'écrire vos propres requêtes SQL.
  • Un SGBD. Pas besoin de connaître toutes les technologies de bases de données, juste celle que vous utilisez réellement.
    Évidemment, je vais proposer Postgres dans pratiquement tous les cas, mais vous avez peut-être vos raisons d'utiliser autre chose.
  • J'ai déjà abordé la performance.
  • Ayant passé du temps avec la communauté Python, je dirais que ça va sur le plan social - vous pouvez apprendre ça à nous, les DBAs !


Si vous avez pris de l'inspiration, et vous avez envie de creuser des sujets, il y a (entre autres) :



Je vais le redire : Vous n'avez pas besoin de tout savoir sur les bases de donnees.

Il est utile d'avoir quelque notions, et de savoir que certains techniques ou methodes existent, et il faut savoir où chercher et/ou à qui s'adresser pour avoir plus d'info si et quand vous en avez besoin.

J'inclue toujours des liens vers la documentation pertinente ou vers d'autres ressources utiles lorsque je fais une conférence base de donnees, car je sais que je ne peux pas tout dire en 30 minutes et que, même si je le faisais, les gens ne se souviendraient pas de la plupart de ce que j'ai dit.

Si, lorsque vous devez mettre quelque chose en œuvre ou lorsque vous rencontrez un problème, vous vous dites « oh, je me souviens vaguement que Karen a dit quelque chose à ce sujet » et que vous pouvez aller vous renseigner, alors j'ai le sentiment d'avoir fait quelque chose d'utile.




Et même si vous n'avez jamais rêvé de devenir DBA, avec un peu de chance, vous allez bientôt raconter fièrement

« Comment j'ai appris à ne plus m'en faire et à aimer la base de données. »

ou « How I learned to stop worrying and love the database. »

(Pour ceux / celles qui n'ont pas la référence - Inspiré par Dr Strangelove or: How I Learned to Stop Worrying and Love the Bomb.)



Merci de votre attention !

Contactez-moi ou me suivre pour plus de discussions base de données :

LinkedIn: https://www.linkedin.com/in/karenhjex/

Mastodon: @karenhjex@mastodon.online

Bluesky: @karenhjex.bsky.social



[1] https://www.fatherly.com/love-money/work-money/the-2017-imagination-report-what-kids-want-to-be- when-they-grow-up/

[2] https://www.statista.com/chart/28802/childhood-aspirations-in-china-us-uk/

[3] https://www.moneypenny.com/us/resources/blog/what-did-you-want-to-be/

[4] https://www.reed.co.uk/career-advice/revealed-what-your-kids-really-want-to-be-when-they-grow-up/

[5] https://www.itjobswatch.co.uk/jobs/uk/dba.do

https://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form



Labels: