mercredi 22 avril 2026

J’explique l’Architecture de PostgreSQL simplement

 

J’explique l’Architecture de PostgreSQL simplement

 Donatien Mbadi, Architecte Bases de Données

PostgreSQL est probablement le système de bases de données open source le plus avancé. Depuis 1989, il a bénéficié de nombreuses améliorations.

PostgreSQL est un serveur de bases de données ayant une architecture orientée sur un modèle multiprocessus, plutôt que multithreads. Ainsi il utilise un processus distinct pour chaque connexion client.

Dans cet article, nous allons discuter des différents composants de l’architecture de PostgreSQL et de comment ils interagissent entre eux.

L’architecture de PostgreSQL se divise en trois :

-     Une architecture de mémoire

-     Une architecture de processus

-     Une architecture de fichiers



                                                                                                                    Schéma de l’architecture de PostgreSQL

 

Dans PostgreSQL, une instance peut contenir une ou plusieurs bases de données. C’est pour cette raison nous désignons une instance de bases de données par un Cluster de bases de données.

Lorsque vous démarrez votre instance PostgreSQL, le premier processus qui démarre s’appelle le processus Postmaster. Il joue le rôle de superviseur et de module d’écoute et est responsable de l’authentification et l’autorisation de toute demande client. Poastmaster assigne un nouveau processus Postgres pour chaque nouvelle connexion et le contrôle durant toute la durée de la connexion.

 

Architecture de mémoire

Lorsqu’une instance PostgreSQL est démarrée, la mémoire partagée (Shared Memory) est allouée. Cette mémoire est réservée aux transactions et aux tâches de maintenance. Elle contient plusieurs segments pour différentes opérations. Nous décrivons dans la suite, les plus importants.

Le tampon partagé (Shared Buffers)

Le tampon partagé est la quantité de mémoire dédiée utilisée pour maintenir les données en cache avant qu’elles ne soient écrites sur disque par le processus Background Writer. Il permet de minimiser les entrées/sorties sur le disque. Il opère comme un cache primaire permettant un accès concurrent aux processus pour accéder aux données. Le paramètre Shared_buffers détermine la taille de cette zone mémoire. La valeur par défaut est 128M.



Le tampon de journalisation anticipé (Wal Buffers)

Les Wal Buffers sont une zone de mémoire partagée dédiée au stockage temporaire des enregistrements du journal de transactions, avant qu’ils ne soient écrits les Wal Segments sur le disque par le processus Wal Writer, lorsque les transactions sont validées et ceci, de manière cyclique. Ils sont essentiels pour assurer la durabilité des transactions et la récupération après une panne. Le paramètre Wal_buffers détermine la taille de cette zone.



Les autres zones de mémoire

La zone de mémoire Work Memory est utilisée pour les opérations de tri, de jointure. Elle est contrôlée par le paramètre work_mem.



La zone Mantenance work est utilisée pour les opérations de maintenance tels que la création des index etc. elle est contrôlée par le paramètre maintenance_work_mem.



Le tampon Temp est une zone utilisée lors de l’accès aux tables temporaires durant les opérations de tri. Il est spécifique à une session.

Architecture de processus

Les processus en arrière-plan sont utilisés pour maintenir la consistance entre la mémoire et les disques. Chaque processus a un rôle bien particulier.

Les processus les plus courants sont les suivants :

Le processus background writer

 Le processus background writer est un processus de serveur dédié dont la fonction est d’écrire les pages (Nouvelles données ou données modifiées) du cache partagé vers le disque



Les processus Wal writer et Archiver

Le processus Wal writer est un processus en arrière-plan responsable de la durabilité des données et la fiabilité des transactions. Il écrit toutes les transactions de journal (WAL) vers le disque.



Lorsque que la base de données est en mode Archive Log, le processus Archiver copie automatiquement les journaux de transactions (WAL) vers un emplacement sécurisé dès qu’ils sont pleins. Il est activé via le paramètre archive_mode=on dans le fichier postgresql.conf.



Les autres processus

Le processus logger est utilisé pour écrire les messages dans le fichier de log. La destination de ce fichier est définie dans le fichier des paramètres postgresql.conf.

Le processus Autovacuum maintient la santé de la base de données en libérant l’espace disque occupé par les lignes supprimées or obsolètes et en mettant les statistiques à jour.

Le processus Checkpointer permet de gérer et séparer les points de synchronisation, permettant ainsi de raccourcir le temps de récupération après un arrêt brutal.

Le processus Logger est chargé de capturer les message d’erreurs, d’avertissement et d’information envoyés par les processus serveurs et de les enregistrer dans les fichiers journaux

Le processus Logical Replication est utilisé pour les gérer les réplications logiques dans PostgreSQL

Le processus IO Workers récemment introduit dans PostgreSQL est conçu pour améliorer les performances en déléguant les opérations de lecture/écriture bloquantes sur disque à des processus d’arrière-plan dédiés, permettant ainsi au processus principal de continuer à traiter des données sans attendre que le disque réponde, simulant ainsi un comportement asynchrone.

Architecture de fichiers

Les fichiers physiques sont utilisés pour stocker des données dans les fichiers de données (Data files), des changements de données dans les fichiers de journalisation (Wal files), des changements archivés dans les fichiers de journalisation archivés (Archive logs) et des messages d’erreurs et d’avertissement dans les fichiers journaux (log files).

Les fichiers de données

Les fichiers de données servent à stocker les données brutes. Ils contiennent uniquement les données, sans aucune instruction ni information de code. Lorsqu'un utilisateur demande des données, PostgreSQL les recherche dans le tampon partagé. Si les données ne s'y trouvent pas, il les charge depuis les fichiers de données présents dans le tampon partagé, puis les traite.

Les fichiers de journalisation

Les fichiers de journalisation servent à enregistrer toutes les modifications apportées au tampon WAL avant la validation. Ils sont principalement utilisés pour garantir la durabilité et la cohérence des données lors d'une opération d'écriture sur le stockage de la base de données.

Les fichiers de journalisation archivés

Les fichiers de journalisation archivés servent à stocker le segment WAL sur le disque. Ces journaux sont utilisés en cas de panne inattendue entraînant une perte de données ; ils permettent alors de réparer ou de récupérer la base de données.

Les fichiers journaux

Les fichiers journaux stockent tous les journaux relatifs au serveur : stderr, csvlog, Syslog, messages d’erreur, d’avertissement, d’information, etc. Ils permettent à l’administrateur de la base de données de déboguer facilement tout problème.

Mécanismes de Commit et Checkpoint dans PostgreSQL

Lorsque vous exécutez des transactions dans PostgreSQL, avant que la transaction ne soit validée (Commit), tous les changements sont maintenus en mémoire dans le tampon partagé et le tampon de journalisation. Lorsque vous effectuez la validation, les changements sont écrits dans le fichier de journalisation par le processus Wal Writer, pour assurer la durabilité et les changements sont marqués comme validé dans le tampon partagé et visibles pour toutes les sessions. Le tampon partagé continue d’être synchronisé par des opérations de validations, jusqu’au moment du point de synchronisation (Checkpoint); moment auquel toutes les transactions marquées validées sont écrites dans les fichiers de données par le processus Background Writer.

Mutiples instances sur PostgreSQL

Vous pouvez créer plusieurs instances de bases de données sur PostgreSQL. Chaque instance va utiliser son propre répertoire de données …/data, son propre fichier de configuration …pg_hba.conf son propre port d’écoute …5444, 5434 ainsi que ses propres processus et mémoires.

 

Exécution d’une requête dans PostgreSQL

L’exécution d’une requête PostgreSQL suit un processus rigoureux.

Analyse : PostgreSQL vérifie la syntaxe SQL et s’assurent de l’existence des objets. Cette phase permet aussi d’appliquer les règles définies, notamment sur les vues et transforme la requête si nécessaire.

Optimisation : Le planification analyse différentes stratégies d’accès aux données (analyses séquentielles, index, jointures) et génère le plan le moins couteux.

Exécution : Le moteur exécute le plan, parcourt les tables, applique les filtres et renvoie les résultats.

J’explique l’Architecture de PostgreSQL simplement

  J’explique l’Architecture de PostgreSQL simplement  Donatien Mbadi, Architecte Bases de Données PostgreSQL est probablement le système...