Module 1 — Les 7 types de bases de données à connaître
Bonne lecture et bon apprentissage ! Junior TSAFACK – 13/09/2026 Temps de lecture estimé : 8 minutes
Pourquoi « type de base de données » et pas juste « SQL vs NoSQL »
Section titled “Pourquoi « type de base de données » et pas juste « SQL vs NoSQL »”La distinction SQL/NoSQL, souvent présentée comme le seul choix qui compte, cache en réalité sept familles distinctes, chacune conçue pour un problème précis. Confondre « NoSQL » avec « une seule technologie » est l’erreur la plus fréquente — MongoDB (document) et Redis (clé-valeur) sont tous les deux « NoSQL », mais ne résolvent absolument pas le même problème.
1. Relationnel (SQL)
Section titled “1. Relationnel (SQL)”Les données sont organisées en tables, avec des lignes et des colonnes, reliées entre elles par des clés étrangères. Le point fort : des garanties ACID (Atomicité, Cohérence, Isolation, Durabilité) qui empêchent qu’une transaction ne soit appliquée qu’à moitié — un virement bancaire ne doit jamais débiter un compte sans créditer l’autre.
- Exemples : PostgreSQL, MySQL, MariaDB, Oracle, SQL Server
- Cas d’usage : systèmes financiers, e-commerce, tout ce qui exige une cohérence stricte des données
- Déjà couvert en détail dans le cours SQL et le cours PostgreSQL de ce site
2. Colonne (Columnar)
Section titled “2. Colonne (Columnar)”Contrairement au relationnel qui stocke les données ligne par ligne, une base colonne stocke chaque colonne séparément. Pour une requête qui n’a besoin que de 3 colonnes sur 50, cette organisation évite de lire les 47 colonnes inutiles — un gain énorme sur de gros volumes analytiques.
- Exemples : Cassandra, HBase, Google BigQuery, Amazon Redshift
- Cas d’usage : entrepôts de données (data warehouses), analytique, agrégations fréquentes sur de larges volumes
3. Document
Section titled “3. Document”Chaque enregistrement est un document (typiquement JSON), et deux documents de la même collection peuvent avoir des champs différents — pas de schéma rigide imposé à l’avance.
- Exemples : MongoDB, CouchDB, Amazon DocumentDB
- Cas d’usage : catalogues produits aux attributs variables, profils utilisateurs, contenus hétérogènes
- Démontré réellement dans le module SQL vs NoSQL du cours DevOps de ce site (le même catalogue, stocké dans PostgreSQL et dans MongoDB)
4. Clé-valeur (Key-Value)
Section titled “4. Clé-valeur (Key-Value)”Le modèle le plus simple : une clé, une valeur, un point c’est tout. Généralement conservé en mémoire vive pour une vitesse extrême. Rarement utilisé comme stockage principal — plutôt comme couche de cache devant une autre base.
- Exemples : Redis, Memcached
- Cas d’usage : cache applicatif, sessions utilisateur, files d’attente, compteurs à haute fréquence
5. Séries temporelles (Time Series / TSDB)
Section titled “5. Séries temporelles (Time Series / TSDB)”Optimisée pour des valeurs horodatées qui évoluent dans le temps, avec des écritures en append (on ajoute, on ne modifie presque jamais) et des techniques de compression poussées adaptées à ce type d’accès.
- Exemples : Prometheus, InfluxDB, Graphite
- Cas d’usage : supervision (déjà vu avec Prometheus dans le cours DevOps), capteurs IoT, historiques de cours boursiers
6. Graphe (Graph)
Section titled “6. Graphe (Graph)”Les données sont stockées comme des nœuds (entités) et des relations (connexions) — optimisée pour naviguer efficacement dans des réseaux d’interconnexions complexes, là où une jointure SQL profonde deviendrait rapidement coûteuse.
- Exemples : Neo4j, Amazon Neptune, ArangoDB
- Cas d’usage : réseaux sociaux, détection de fraude (repérer des schémas de transactions liées), moteurs de recommandation
7. Vecteur (Vector)
Section titled “7. Vecteur (Vector)”La famille la plus récente à devenir grand public : les données sont stockées sous forme de vecteurs numériques (embeddings) qui capturent une notion de proximité sémantique — deux contenus « proches en sens » ont des vecteurs proches dans l’espace, même sans mot en commun.
- Exemples : Pinecone, Qdrant, et — on le voit au Module 3 — PostgreSQL via l’extension
pgvector - Cas d’usage : recherche sémantique, systèmes de RAG (Retrieval-Augmented Generation) pour les modèles de langage — déjà abordé conceptuellement dans le cours NLP, LLM & RAG de ce site
Tableau récapitulatif
Section titled “Tableau récapitulatif”| Type | Ce qu’il optimise | Exemple réel |
|---|---|---|
| Relationnel | Cohérence stricte, transactions | PostgreSQL |
| Colonne | Lecture analytique sur gros volumes | BigQuery |
| Document | Schéma flexible | MongoDB |
| Clé-valeur | Vitesse d’accès extrême | Redis |
| Séries temporelles | Écritures horodatées, compression | Prometheus |
| Graphe | Navigation dans des relations complexes | Neo4j |
| Vecteur | Recherche par similarité sémantique | Pinecone |
Le piège à éviter
Section titled “Le piège à éviter”Aucune de ces sept familles n’est « meilleure » dans l’absolu — chacune a été conçue en sacrifiant délibérément certaines garanties pour en gagner d’autres (c’est le compromis bien connu du théorème CAP pour les systèmes distribués : cohérence, disponibilité, tolérance au partitionnement — on ne peut pas maximiser les trois à la fois). Le bon réflexe n’est pas « quelle est la meilleure base de données », mais « quel type de problème ai-je, et quelle famille a été conçue pour ce problème précis ».