Qu’est-ce qu’un moteur de base de données ?
La plupart des développeurs interagissent avec une base de données à travers une interface familière : tables, requêtes SQL, ORM. Mais derrière cette abstraction se trouve un composant sophistiqué, déterminant la manière dont les données sont stockées, protégées et retrouvées : le moteur de base de données.
Comprendre ce qu’est un moteur et ce qu’il n’est pas est essentiel pour analyser la performance, raisonner sur la durabilité, ou comparer différentes architectures.
Cette note propose une exploration structurée du fonctionnement interne d’un moteur : le rôle du storage engine, du query engine et du transaction manager ; les fondements ACID ; et la raison pour laquelle un moteur n’est pas un simple « Postgres embarqué ». L’objectif n’est pas l’exhaustivité, mais la construction d’un modèle mental clair.
Le cœur du système : une division de responsabilités
Un moteur n’est pas un bloc monolithique. C’est un ensemble coordonné de sous-systèmes.
+------------------------+
| Query Engine |
+------------------------+
| Transaction Manager |
+------------------------+
| Storage Engine |
+------------------------+
Le Storage Engine
Il gère la manière dont les données sont physiquement stockées, en contrôlant :
- les chemins d’écriture,
- le WAL,
- les formats sur disque,
- les index,
- la récupération après crash.
Le Query Engine
Il transforme une requête en un plan d’exécution optimal. Il gère : parsing SQL, optimisation, choix des stratégies de jointure, exécution des opérateurs.
Le Transaction Manager
Il s’assure que les transactions respectent les propriétés fondamentales :
- atomicité,
- isolation,
- cohérence,
- durabilité.
ACID : le contrat qui donne confiance
ACID n’est pas une simple définition académique. C’est un contrat opérationnel entre l’ingénieur et le moteur.
Chaque composante impose des mécanismes internes : multiversioning, verrous, journaux d’écriture, stratégies de récupération. Sans ACID, aucune application ne peut raisonner correctement sur l’état du système.
Une architecture coordonnée
À l’exécution, le moteur fonctionne comme un pipeline :
Chaque étape applique des décisions critiques pour préserver cohérence et performance.
Pourquoi un moteur n’est pas un “Postgres embarqué”
Un moteur est une architecture complète, pas un composant réutilisable comme une bibliothèque.
Plusieurs raisons :
- les moteurs sont spécialisés (B-Tree, LSM, MVCC, etc.)
- ils dépendent du matériel et du contexte opérationnel
- ils définissent la performance et la cohérence
- les couches query/storage ne sont pas interchangeables
Imaginer qu’un moteur est « Postgres dans une boîte » masque toute la complexité réelle.
Conclusion
Un moteur de base de données est la machinerie fondamentale qui décide de la manière dont les données sont écrites, stockées, indexées et récupérées. Il assemble un storage engine, un query engine et un transaction manager pour assurer les garanties ACID et garantir un comportement prédictible.
C’est une architecture, pas un module.
Comprendre ce mécanisme est la première étape pour analyser les performances, diagnostiquer les problèmes ou imaginer de nouvelles architectures de stockage.
Références recommandées
- J. Gray & A. Reuter — Transaction Processing: Concepts and Techniques
- P. O’Neil et al. — “The Log-Structured Merge-Tree (LSM-Tree)”
- M. Stonebraker — “What Goes Around Comes Around”
- H. Garcia-Molina et al. — Database Systems: The Complete Book
- Google — Bigtable: A Distributed Storage System for Structured Data
- PostgreSQL Documentation — WAL, Concurrency Control
- RocksDB Engineering Notes