Data, Caches & Performance Back-End

SQL/NoSQL, ORM, Redis, filesystems, optimisation, scalabilité & SLO : comment stocker, accéder et servir les données de manière fiable et performante.

Modèles de données : SQL vs NoSQL & choix de schémas Caches & Redis : patterns, TTL, invalidation Performance, scalabilité, SLO & observabilité

Type	Exemples	Forces	Limites / pièges
SQL relationnel	PostgreSQL, MySQL, SQL Server	ACID, joints, intégrité référentielle, reporting.	Rigidité du schéma, scaling horizontal plus complexe.
Documents	MongoDB, CouchDB	Schéma flexible, modèle proche du JSON.	Transactions limitées (selon moteur), design naïf → duplication.
Clé-valeur	Redis, DynamoDB (simplifié)	Très rapide, simple, idéal pour caches & sessions.	Peu de requêtage avancé, clé de partition à bien choisir.
Colonnes	Cassandra, Bigtable	Très bon pour gros volumes & écritures massives.	Modélisation orientée requêtes, moins flexible.

Règle simple

Si le modèle est bien structuré, rapports nécessaires → SQL.
Si les données sont semi-structurées / évolutives → souvent documents + index.
Si besoin de lecture ultra rapide avec patterns simples → clé-valeur / cache.

Exemple : même info, 2 modèles

-- SQL (orders, order_items)
orders(id, customer_id, total_amount, status)
order_items(id, order_id, sku, qty, price)

// Document (Mongo)
{
  "_id": "ord_123",
  "customer_id": "c1",
  "status": "paid",
  "items": [
    {"sku": "P1", "qty": 2, "price": 10.0}
  ]
}

Types de caches

Cache HTTP (CDN, reverse proxy).
Cache applicatif (in-memory, Redis).
Cache de base (query cache, materialized views).

Pattern cache-aside (le plus courant)

def get_order(order_id):
    key = f"order:{order_id}"
    data = redis.get(key)
    if data:
        return deserialize(data)

    row = db.fetch_one("SELECT ... WHERE id = %s", [order_id])
    if row:
        redis.setex(key, 300, serialize(row))  # TTL 5 min
    return row

Invalidation & TTL

TTL pour les données “soft real-time” (quelques secondes / minutes).
Invalidation ciblée sur update/delete (ex : DEL order:{id}).
Attention au “cache stampede” → utiliser locking / jitter.

Checklist caches

Quelles données peuvent être servies avec un léger retard ? (candidats au cache).
Stratégie claire d’invalidation : par clé, par tag, par incrément de version.
Metrics sur le cache : hit ratio, taille, temps de réponse.

Quand SQL ?

Relations riches, besoin de joints, contraintes d’intégrité fortes.
Rapports / analytics importants (BI, KPI financiers…).
Besoin d’ACID & transactions complexes.

Quand NoSQL ?

Données très volumineuses / schémas variables.
Requêtes simples mais à très haute échelle.
Need spécifique (full-texte, time-series, graph DB…).

Exemple : modéliser un panier

-- SQL
carts(id, user_id, created_at)
cart_items(id, cart_id, sku, qty, price)

// Document
{
  "_id": "cart_123",
  "user_id": "u1",
  "items": [
    {"sku": "P1", "qty": 2, "price": 10.0}
  ]
}

Rôle de l’ORM

Mapper les objets du domaine vers les tables / collections.
Gérer les migrations, transactions, validations.
Éviter d’écrire du SQL répétitif (mais pas de penser SQL).

Exemple simple (ORM Python)

class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    status = Column(String)
    total = Column(Numeric)

N+1 & patterns

N+1 = charger 1 enregistrement, puis N requêtes pour les relations.
Solutions : select_related / join fetch / prefetch.
Pattern Repository / Unit of Work pour isoler la persistence.

Index & cardinalité

Index sur les colonnes filtrées / jointes.
Éviter les index inutiles (faible sélectivité).
Surveiller la taille des index & les mises à jour.

EXPLAIN / plan d’exécution

EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 42;

Vérifier l’utilisation d’index vs full scan.
Regarder le coût estimé / réel, les nœuds dominants.

Requêtes lentes

Activer le “slow query log” ou équivalent.
Optimiser d’abord les requêtes les plus coûteuses (top 10).
Envisager la dénormalisation / vues matérialisées pour certains cas.

Où mettre le cache ?

CDN / reverse proxy : cache HTML, JSON, images.
Cache dans l’app (Redis, memory) : objets & réponses fréquentes.
Cache dans la DB : index, vues matérialisées.

Exemple HTTP

Cache-Control: public, max-age=60
ETag: "v1-article-123"

Utiliser ETag / Last-Modified pour le revalidation.

Anti-patterns

Tout mettre en cache “au hasard” sans metrics.
Pas de stratégie d’invalidation → données incohérentes.

Fichiers vs objets

Fichiers locaux : rapides mais couplés à la machine.
Stockage objet (S3, GCS…) : durable, versionnable, multi-AZ.

Cas d’usage

Uploads utilisateur (documents, images).
Exports / backups / archives.
Large logs / traces longue durée.

Conventions utiles

s3://my-bucket/
  raw/2025/12/...
  exports/{yyyy}/{mm}/...
  logs/{service}/{date}/...

Mesurer avant d’optimiser

APM / profiler : trouver les endpoints / fonctions les plus lentes.
Dashboards simple : RPS, latence, CPU, DB connections.

Tests de charge

# Exemple Locust (pseudo)
class User(HttpUser):
    @task
    def get_profile(self):
        self.client.get("/api/profile")

Tester les scénarios réels, pas des URLs isolées sans contexte.

Scaling

Vertical : plus de CPU/RAM sur la même machine.
Horizontal : plus d’instances derrière un load balancer.
Ne pas oublier la DB, caches & queues dans l’analyse de goulot.

Data, Caches & Performance Back-End

1. Rôle des données & stockage

2. SQL vs NoSQL & modèles

3. ORM, accès data & transactions

4. Index, requêtes & plans d’exécution

5. Caches : Redis & co.

6. Filesystems & stockage objet

7. Performance & scalabilité

8. SLO, observabilité & coûts