Je t'explique
l’Architecture de PostgreSQL simplement
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.
