🗄️ Bases de Données — concepts, modèles, SQL/NoSQL, transactions, index, perf, réplication & ops

ACID (et pourquoi c’est important)

CAP (version utile)

Si partition réseau :
- C (consistency) ou A (availability) : tu choisis comportement
En pratique :
- CP : préfère cohérence (peut refuser)
- AP : préfère disponibilité (cohérence éventuelle)
        

OLTP vs OLAP : ne pas mélanger sans précautions

OLTP : petits writes/reads, beaucoup de connexions, index + contention
OLAP : scans, aggregations, partitions, columnar, compression

Mix :
- réplicas dédiés
- ETL vers warehouse
- workload management
        

Relationnel : pourquoi ça reste dominant

- schéma explicite
- contraintes (PK/FK/unique/check)
- transactions + isolation
- optimizer mature
- reporting + SQL universel
        

Document : flexibilité

- documents JSON (collections)
- index sur champs
- atomicité souvent par document
- bon pour structures imbriquées
Risques :
- schéma “caché” => dette
- duplication => incohérences
        

Spécialisées : “le bon outil au bon endroit”

Key-Value : Redis-like (cache)
Search : Elastic-like (full text)
Time-series : Influx/Timescale-like (metrics)
Graph : Neo4j-like (relations)
Wide-column : Cassandra-like (scale)
        

Normalisation (résumé)

• 1NF : valeurs atomiques.
• 2NF : pas de dépendance partielle (clé composite).
• 3NF : pas de dépendance transitive.

Contraintes : “payer un peu” pour éviter le chaos

ORM : productivité vs transparence

Avantages :
- productivité CRUD
- migrations + modèle unique
Risques :
- N+1 queries
- joins implicites
- mauvais plans invisibles
Pratiques :
- profiler SQL
- expliciter préfetch/join
- indexer selon requêtes
        

Locks : pourquoi ça bloque

Sources de contention :
- transactions longues
- scans + updates
- hotspots (même row)
- index manquants sur FK
Solutions :
- réduire durée transactions
- indexer correctement
- partitioning, batching
        

MVCC : multi-version concurrency control

Idée :
- lecteurs ne bloquent pas écrivains (souvent)
- versions (tuples) -> nettoyage (vacuum)
Impacts :
- bloat si vacuum mal réglé
- visibilité via snapshots
        

Deadlocks : cercle d’attente

Pattern :
T1 lock(A) -> veut B
T2 lock(B) -> veut A
=> deadlock, un est tué
Prévention :
- ordre d'accès stable
- transactions courtes
- index + éviter scans lockants
        

Cardinalité / sélectivité

Index utile si :
- filtre réduit fortement le résultat
- ou couvre ORDER BY / JOIN

Index peu utile si :
- colonne faible cardinalité (ex: bool)
=> sauf bitmap/partiel selon moteur
        

Covering index (include)

Idée :
- l'index contient toutes les colonnes nécessaires
=> éviter lookup table (heap fetch)
Gain :
- lectures I/O réduites
Coût :
- index plus gros, writes plus lents
        

Chaque index a un coût

Statistics : le fuel de l’optimizer

Si stats fausses :
- mauvais join order
- mauvais choix index
Solutions :
- analyze/vacuum
- histogram/extended stats (selon moteur)
        

Joins : règles simples

Anti-patterns requêtes

• SELECT * sur tables larges.
• Fonctions sur colonnes indexées (empêche usage index) : WHERE lower(email)=...
• OR multiples sans index adaptés.
• JOIN sans condition (cartésien involontaire).
• N+1 queries (côté ORM).

RPO/RTO

RPO : combien de données je peux perdre ?
RTO : combien de temps je peux être down ?
Choix architecture = arbitrage business.
        

Split brain & quorum

Split brain : 2 primaires en même temps
=> corruption logique
Prévention :
- leader election (quorum)
- fencing (STONITH)
- consensus store (etcd/raft)
        

Sharding (scale horizontal)

Sharding = partitionner données sur plusieurs nodes
Défis :
- transactions cross-shard
- joins compliqués
- rebalancing
Souvent :
- commencer par read replicas + caching
- shard seulement si nécessité
        

Chiffrement : at rest & in transit

• TLS entre app ↔ DB.
• Chiffrement disque / tablespaces.
• Gestion secrets (vault), rotation.

Audit & traçabilité

- journaliser accès admin
- tracer opérations sensibles
- alerter sur anomalies
- conserver logs selon policy
        

Multi-tenant : pièges

• Isolation logique (schemas) vs physique (instances).
• Quotas (CPU/IO) pour éviter noisy neighbor.
• Row-level security si disponible.

Perf : 10 leviers

1. Index adaptés aux requêtes (et pas trop).
2. Plans corrects (stats à jour).
3. Connection pooling (éviter 10k connexions).
4. Cache (buffer) dimensionné.
5. Batching writes, éviter transactions longues.
6. Partitioning si gros volumes.
7. Réduire I/O (covering index, compression).
8. Eviter N+1 côté ORM.
9. Workload séparation (read replica/warehouse).
10. Hardware/stockage adapté (NVMe/IOPS).

Maintenance : éviter la “surprise”

- vacuum/compaction (selon moteur)
- bloat tracking
- reindex / analyze
- upgrades planifiés (test)
- capacity planning (croissance)
        

Incident playbook (résumé)

1) Identifier symptôme : latency, errors, locks, disk full
2) Protéger : limiter traffic, read-only, circuit breaker
3) Diagnostiquer : top queries, locks, IO, replication lag
4) Mitiger : kill query, add index, scale read, failover
5) Postmortem : cause -> action (monitoring, code, ops)