Types de bases de données : relationnelles, NoSQL et au-delà
Leçon 1.2 · Temps de lecture : ~20 min · Exercices pratiques ↓
Il existe de nombreux types de bases de données, chacun optimisé pour un type de données, un modèle de requête ou des exigences de scalabilité spécifiques. Dans cette leçon, vous découvrirez les principaux modèles de bases de données - relationnelles, clé-valeur, documentaires, à colonnes larges, graphes, séries temporelles et colonnaires - avec leurs différences clés, leurs cas d'usage typiques et des exemples de systèmes réels. Pour chaque type, vous verrez aussi à quoi ressemblent les mêmes données d'une boutique en ligne.
Dans la leçon précédente, nous avons introduit l'idée générale d'une base de données et d'un SGBD. En pratique, toutes les bases de données ne sont pas construites de la même manière. Différents types sont optimisés pour différents types de données, modèles de requêtes, exigences de scalabilité et besoins de cohérence.
Nous porterons également une attention particulière aux bases de données relationnelles, car elles resteront le principal focus de ce cours.
Pourquoi Existe-t-il Différents Types de Bases de Données ?
Aucun modèle de base de données n'est parfait pour toutes les applications.
Par exemple :
- Un système bancaire a besoin d'une forte cohérence et de transactions fiables.
- Un système de cache a besoin de recherches par clé extrêmement rapides.
- Un réseau social peut avoir besoin d'un stockage documentaire flexible et d'une analyse des relations de type graphe.
- Une plateforme analytique peut avoir besoin d'analyser efficacement des milliards de valeurs pour le reporting.
Parce que différents systèmes résolvent différents problèmes, plusieurs modèles de bases de données ont émergé au fil du temps.
Principaux Types de Bases de Données : Tableau Comparatif
Voici une comparaison rapide avant d'examiner chaque type plus en détail :
| Type | Modèle de données | Forces | Cas d'usage courants | Exemples |
|---|---|---|---|---|
| Relationnelle | Tables avec lignes et colonnes | Cohérence forte, SQL, jointures, données structurées | Banque, ERP, CRM, e-commerce, reporting | PostgreSQL, MySQL, MariaDB, SQLite, Oracle |
| Clé-valeur | Clé associée à une valeur | Recherches très rapides, scalabilité simple | Cache, sessions, feature flags, paniers d'achat | Redis, Amazon DynamoDB, Riak |
| Documentaire | Documents de type JSON | Schéma flexible, données imbriquées | Gestion de contenu, profils utilisateurs, catalogues | MongoDB, Couchbase, Firestore |
| À colonnes larges | Lignes avec colonnes flexibles en familles | Haut débit d'écriture, scalabilité horizontale | Journalisation, IoT, charges distribuées à grande échelle | Apache Cassandra, HBase, ScyllaDB |
| Graphe | Nœuds et arêtes | Requêtes centrées sur les relations | Réseaux sociaux, détection de fraude, recommandations | Neo4j, Amazon Neptune, ArangoDB |
| Séries temporelles | Enregistrements horodatés | Ingestion et agrégation efficaces dans le temps | Supervision, métriques, capteurs, données financières | InfluxDB, TimescaleDB, OpenTSDB |
| Colonnaire analytique | Données stockées par colonne | Analyses et agrégations rapides | BI, tableaux de bord, data warehousing, OLAP | ClickHouse, DuckDB, Amazon Redshift, BigQuery |
| En mémoire | Données principalement en RAM | Latence extrêmement faible | Cache, classements, compteurs en temps réel | Redis, Memcached, SAP HANA |
Bases de Données Relationnelles
Les bases de données relationnelles stockent les données dans des tables composées de lignes et de colonnes. Les tables peuvent être liées entre elles par des relations, généralement à l'aide de clés primaires et de clés étrangères.
Ce modèle est particulièrement adapté lorsque les données sont bien structurées et que l'exactitude, la cohérence et les requêtes complexes sont importantes.
Exemple de données :
Tous les exemples de cette leçon utilisent les mêmes données d'une boutique en ligne : Ann (identifiant client 42) et ses commandes. Dans une base relationnelle, clients et commandes sont stockés dans deux tables reliées par la colonne customer_id :
customers
| id | name | city |
|---|---|---|
| 42 | Ann | Lisbon |
| 43 | Bob | Madrid |
orders
| id | customer_id | order_date | total |
|---|---|---|---|
| 1 | 42 | 2026-03-14 | 99.50 |
| 2 | 42 | 2026-04-02 | 15.00 |
| 3 | 43 | 2026-04-02 | 12.00 |
La valeur 42 de orders.customer_id désigne la ligne d'Ann dans customers : les données du client sont stockées une seule fois, et chaque commande y fait référence.
Propriétés Fondamentales des Bases Relationnelles
1. Schéma structuré - exige un schéma clairement défini avec tables, colonnes, types de données, contraintes et relations. La structure est prévisible et facile à valider.
2. Relations entre les tables - capacité à modéliser explicitement les relations entre entités (ex. customers → orders → order_items). Idéal pour les systèmes métiers.
3. Prise en charge de SQL - standard pour filtrer, joindre, agréger, trier et modifier des données structurées.
4. Transactions ACID :
- Atomicité : une transaction réussit entièrement ou échoue entièrement.
- Cohérence : les données restent valides selon les règles définies.
- Isolation : les transactions concurrentes ne s'interfèrent pas incorrectement.
- Durabilité : les données validées sont conservées même après une panne.
5. Contraintes d'intégrité - clés primaires, clés étrangères, unicité, NOT NULL, CHECK pour prévenir les données invalides.
6. Jointures puissantes - idéales pour combiner des données de plusieurs tables en reporting et analytique.
7. Normalisation - réduction de la duplication via des tables liées.
Cas d'Usage Courants
Les bases relationnelles sont le meilleur choix quand les données sont structurées, les relations importantes, les transactions fiables requises et les requêtes complexes nécessaires.
Exemples
- PostgreSQL, MySQL, MariaDB, SQLite, Oracle Database, Microsoft SQL Server
Bases de Données Clé-Valeur
Stockent les données comme une paire clé + valeur. Accès direct par clé - modèle très simple et très rapide.
Exemple de données :
Chaque valeur est retrouvée par sa clé. La base ne regarde pas à l'intérieur de la valeur : pour elle, le JSON ci-dessous n'est qu'une chaîne.
| Clé | Valeur |
|---|---|
session:8f3a2c | { "customer_id": 42, "expires": "2026-03-14T12:00:00Z" } |
cart:42 | [101, 205] |
views:product:101 | 1532 |
feature:new_checkout | on |
Les clés comme session:8f3a2c reçoivent généralement une durée de vie, par exemple une heure, après laquelle elles sont supprimées automatiquement. En revanche, la base ne peut pas répondre à « toutes les sessions du client 42 » : elle ne trouve une valeur que si l'on connaît déjà la clé.
Cas d'usage : cache, sessions, paniers, feature flags, classements.
Exemples : Redis, Amazon DynamoDB, Riak
Bases de Données Documentaires
Stockent les données sous forme de documents JSON. Chaque document peut avoir une structure différente.
Exemple de données :
La commande 1 est stockée en un seul document : le client et les lignes de commande y sont imbriqués, une seule lecture renvoie donc tout, sans jointure.
{
"_id": 1,
"order_date": "2026-03-14",
"customer": { "id": 42, "name": "Ann", "city": "Lisbon" },
"items": [
{ "product": "Keyboard", "qty": 1, "price": 79.50 },
{ "product": "Mouse pad", "qty": 2, "price": 10.00 }
],
"total": 99.50
}
Un autre document de la même collection peut avoir d'autres champs, par exemple une commande cadeau avec gift_message :
{
"_id": 2,
"order_date": "2026-04-02",
"customer": { "id": 42, "name": "Ann" },
"items": [ { "product": "Gift card", "qty": 1, "price": 15.00 } ],
"gift_message": "Happy birthday!",
"total": 15.00
}
Contrepartie : le nom d'Ann est copié dans chaque commande ; s'il change, il faut mettre à jour tous les documents.
Cas d'usage : gestion de contenu, catalogues produits, profils utilisateurs, applications web et mobiles.
Exemples : MongoDB, Couchbase, Google Firestore
Bases de Données à Colonnes Larges
Stockent les données en lignes avec un ensemble flexible de colonnes. Conçues pour la distribution sur de nombreux serveurs et un haut débit d'écriture.
Exemple de données :
Les lignes sont retrouvées par une clé de ligne (row key), et chaque ligne ne stocke que les colonnes qu'elle possède réellement. Les colonnes sont regroupées en familles (ici info et orders, notées family:column), et de nouvelles colonnes peuvent être ajoutées à une seule ligne sans modifier de schéma :
customer:42
info:name = Ann
info:city = Lisbon
orders:1 = 99.50
orders:2 = 15.00
customer:43
info:name = Bob
orders:3 = 12.00
La ligne de Bob n'a aucune colonne city : ce n'est pas NULL, elle n'existe tout simplement pas. La ligne d'Ann gagne une colonne à chaque commande. La clé de ligne détermine le serveur qui stocke la ligne, les données sont donc recherchées par cette clé ; pour trouver des commandes par total, il faudrait une autre table organisée selon cette valeur.
Cas d'usage : journalisation d'événements, IoT, messagerie, systèmes distribués géographiquement.
Exemples : Apache Cassandra, Apache HBase, ScyllaDB
Bases de Données Colonnaires Analytiques
Stockent les valeurs d'une même colonne ensemble sur disque - différent des bases à colonnes larges. Efficaces pour les requêtes analytiques lisant peu de colonnes sur de très grands volumes.
Exemple de données :
Reprenons la table orders de l'exemple relationnel. Une base orientée lignes écrit chaque ligne d'un bloc ; une base colonnaire écrit chaque colonne d'un bloc :
Stockage par lignes :
[1, 42, 2026-03-14, 99.50] [2, 42, 2026-04-02, 15.00] [3, 43, 2026-04-02, 12.00]
Stockage par colonnes :
id: 1, 2, 3
customer_id: 42, 42, 43
order_date: 2026-03-14, 2026-04-02, 2026-04-02
total: 99.50, 15.00, 12.00
Un rapport du chiffre d'affaires par date n'a besoin que de order_date et total : une base colonnaire ne lit que ces deux colonnes et ignore les autres. Avec des centaines de colonnes et des milliards de lignes, le gain est énorme. Les valeurs répétées d'une colonne (comme 2026-04-02) se compressent en outre très bien.
Cas d'usage : business intelligence, data warehousing, dashboards, analyses de logs.
Exemples : ClickHouse, DuckDB, Amazon Redshift, Google BigQuery
Bases de Données Graphe
Conçues pour les données où les relations sont la partie la plus importante. Stockent des nœuds (entités) et des arêtes (relations). Parcours des relations rapide et naturel.
Exemple de données :
Clients, commandes et produits deviennent des nœuds ; « a passé », « contient » et « suit » deviennent des arêtes. Chaque arête a une direction et un type, et nœuds comme arêtes peuvent porter des propriétés :
(Ann:Customer)-[:PLACED]->(Order 1 { total: 99.50 })-[:CONTAINS]->(Mouse pad:Product)
(Ann:Customer)-[:PLACED]->(Order 1 { total: 99.50 })-[:CONTAINS]->(Keyboard:Product)
(Bob:Customer)-[:PLACED]->(Order 3 { total: 12.00 })-[:CONTAINS]->(Mouse pad:Product)
(Bob:Customer)-[:FOLLOWS]->(Ann:Customer)
Pour savoir qui a acheté les mêmes produits qu'Ann, la base suit simplement les arêtes : Ann → Order 1 → Mouse pad → Order 3 → Bob. Dans une base relationnelle, la même question exige de combiner plusieurs tables.
Cas d'usage : réseaux sociaux, détection de fraude, recommandations, graphes de connaissances.
Exemples : Neo4j, Amazon Neptune, ArangoDB
Bases de Données de Séries Temporelles
Spécialisées pour les données associées au temps, optimisées pour l'ingestion, la rétention et l'agrégation temporelle.
Exemple de données :
Les commandes s'y prêtent mal : les données typiques sont un flux de mesures. Par exemple, les serveurs de la boutique envoient des métriques chaque minute :
| time | host | cpu_percent | requests_per_sec |
|---|---|---|---|
| 2026-03-14 10:00:00 | web-01 | 37.5 | 120 |
| 2026-03-14 10:00:00 | web-02 | 41.2 | 134 |
| 2026-03-14 10:01:00 | web-01 | 39.0 | 126 |
| 2026-03-14 10:01:00 | web-02 | 44.8 | 141 |
Les lignes sont seulement ajoutées et presque jamais modifiées. Les questions typiques portent sur des fenêtres de temps, par exemple la charge CPU moyenne de chaque serveur par intervalles de 5 minutes sur la dernière heure. La base peut aussi supprimer ou compresser automatiquement les anciennes données : par exemple garder les points bruts 30 jours, puis seulement les moyennes horaires.
Cas d'usage : supervision de serveurs, métriques, données de capteurs, données boursières.
Exemples : InfluxDB, TimescaleDB, OpenTSDB
Bases de Données en Mémoire
Stockent la plupart des données en RAM plutôt que sur disque - extrêmement rapides, mais mémoire plus coûteuse.
Exemple de données :
Redis garde en RAM des structures de données comme l'ensemble trié (sorted set). Ici, il contient un classement des clients par montant dépensé : chaque nouvelle commande augmente le score du client, et l'ensemble reste toujours trié :
top_customers
customer:42 114.5
customer:43 12
Lire le top 10 prend moins d'une milliseconde. Une base relationnelle devrait additionner toute la table des commandes pour obtenir ce classement ; ici, il est toujours prêt.
Cas d'usage : cache, sessions, compteurs en temps réel, classements de jeux.
Exemples : Redis, Memcached, SAP HANA
Comment Choisir le Bon Type de Base de Données ?
Questions à se poser :
- Les données sont-elles très structurées ou flexibles ?
- Ai-je besoin de transactions ACID fortes ?
- Vais-je exécuter des jointures complexes ?
- La recherche rapide par clé est-elle la priorité absolue ?
- La charge est-elle transactionnelle ou analytique ?
- Le système devra-t-il évoluer sur de nombreux serveurs ?
- Les relations entre entités sont-elles centrales ?
Dans de nombreux systèmes réels, on utilise plusieurs types de bases de données - c'est la persistance polyglotte : relationnelle pour les données métier, Redis pour le cache, documentaire pour le contenu flexible, colonnaire pour l'analytique.
Résumé : Différences Clés Entre Types de Bases de Données
- Modèle de données - tables, documents, clé-valeur, graphes, enregistrements horodatés
- Flexibilité du schéma - fixe ou flexible
- Style de requête - SQL, clé, documents, graphes, fenêtres temporelles
- Modèle de cohérence - ACID fort ou compromis pour la scalabilité
- Profil de performance - transactions, analytique, relations ou accès ultra-rapide
Points clés :
- Différents types de bases de données existent car différentes applications ont des besoins différents.
- Les bases relationnelles excellent pour les schémas structurés, SQL, relations, intégrité et ACID.
- Les bases clé-valeur sont idéales pour le cache et les recherches rapides.
- Les bases documentaires sont utiles pour les données flexibles ou changeantes.
- Les bases à colonnes larges sont conçues pour les charges distribuées et massives.
- Les bases colonnaires analytiques s'optimisent pour le reporting et l'analytique.
- Les bases graphe sont parfaites pour les données riches en relations.
- Les bases de séries temporelles spécialisent les métriques et événements liés au temps.
- La persistance polyglotte combine plusieurs types selon les besoins.
Questions Fréquentes
Quelle est la différence entre bases relationnelles et NoSQL ?
Les bases relationnelles utilisent un schéma fixe, des transactions ACID et SQL. NoSQL est un terme générique pour les modèles clé-valeur, documentaires, à colonnes larges et graphes - ils échangent certaines garanties de cohérence contre flexibilité ou scalabilité. Le bon choix dépend de vos données et de votre charge.
Quand utiliser une base documentaire plutôt que relationnelle ?
Utilisez une base documentaire quand les données ont une structure imbriquée variable et que les jointures entre collections sont rares. Utilisez une base relationnelle quand les données sont structurées, les entités interreliées, et que vous avez besoin de transactions fiables et de requêtes multi-tables complexes.
Une application peut-elle utiliser plusieurs types de bases de données ?
Oui - c'est la persistance polyglotte. C'est courant en production : PostgreSQL pour les données transactionnelles, Redis pour le cache, ClickHouse pour l'analytique. Chaque type est utilisé là où il excelle.
Questions d'entretien
Quel type de base de données choisiriez-vous pour un cas d'usage donné, et pourquoi ?
Partez de la charge et des contraintes : structure des données, besoins de cohérence, type de requêtes, objectifs de latence et échelle. Par exemple, choisissez une base relationnelle pour des transactions ACID, une base documentaire pour des enregistrements JSON flexibles, et une base de séries temporelles pour des métriques horodatées.
Quels sont les avantages et les inconvénients d'un type de base de données par rapport à un autre ?
Chaque modèle implique des compromis. Les bases relationnelles offrent une forte cohérence, les jointures et un écosystème SQL mature, mais les changements de schéma peuvent être plus contraignants à grande échelle. Les modèles NoSQL apportent souvent plus de flexibilité ou de scalabilité horizontale, mais peuvent limiter les jointures ou demander une conception plus fine de la cohérence.
Peut-on utiliser plusieurs types de bases de données dans une même application ?
Oui. C'est la persistance polyglotte : utiliser plusieurs bases, chacune pour la charge qu'elle gère le mieux. Un schéma fréquent est PostgreSQL pour les transactions, Redis pour le cache et ClickHouse (ou un autre système colonnaire) pour l'analytique.