Skip to main content

​
Indexation

L’indexation est une technique d’optimisation des performances de la base de données qui permet de récupérer rapidement les lignes d’une table. Un index est une structure de données (souvent un arbre B-Tree) qui stocke la valeur d’une ou plusieurs colonnes de la table et, à côté de chaque valeur, l’adresse physique de la ligne correspondante. Mécanisme Sans index, le moteur de base de données doit effectuer une analyse complète de la table (Full Table Scan) pour trouver la ligne correspondant à une condition de requête (ex: WHERE nom = 'Durand'). Avec un index sur la colonne nom, la base de données peut aller directement à l’emplacement physique de la ligne, de manière similaire à un index de livre. Bonnes Pratiques d’Indexation
  • Indexer les colonnes de WHERE et JOIN: Les colonnes utilisées fréquemment dans les clauses de filtre (WHERE), de tri (ORDER BY) ou de jointure (JOIN) sont les meilleures candidates.
  • Clés Primaires/Étrangères : Les SGBD (Systèmes de Gestion de Bases de Données) créent souvent automatiquement un index pour les clés primaires, mais il faut s’assurer que les clés étrangères sont également indexées pour optimiser les jointures.
  • Coût d’Écriture : Chaque index créé doit être mis à jour à chaque insertion, modification ou suppression de ligne. Trop d’index nuit à la performance des écritures. Il est crucial de trouver le bon équilibre entre la vitesse de lecture et la vitesse d’écriture.

​
Mise en Cache (Caching)

La mise en cache est le stockage de données fréquemment consultées (résultats de requêtes, objets entièrement formés) dans une couche de mémoire ultra-rapide et temporaire, plus proche du consommateur que la base de données principale. L’objectif est de réduire l’accès à la base de données, réduisant ainsi la latence et la charge. Outils Clés : Redis Redis (Remote Dictionary Server) est le système de mise en cache le plus populaire. Il est généralement déployé comme un service indépendant (in-memory) et prend en charge des structures de données avancées (Listes, Sets, Hashes, etc.), ce qui le rend utile pour le caching et pour des tâches telles que la gestion de sessions ou le rate limiting. Stratégies de Caching Courantes
  1. Cache-Aside (Caching Lazy) : L’application est responsable de lire et d’écrire dans le cache.
    • Lecture : L’application vérifie d’abord le cache. Si la donnée est là (Cache Hit), elle la renvoie. Si non (Cache Miss), elle va à la DB, stocke la donnée dans le cache, puis la renvoie.
    • Écriture : L’application écrit dans la base de données puis invalide (supprime) l’entrée correspondante dans le cache.
  2. Read-Through / Write-Through : Le cache agit comme le front-end de la base de données. L’application interagit uniquement avec le cache, qui est responsable de lire/écrire les données vers la DB en arrière-plan.
Problématique : Cohérence du Cache Le principal défi du caching est de maintenir la cohérence : s’assurer que les données du cache ne sont pas obsolètes. La technique la plus courante est l’invalidation (suppression de l’entrée) lors de la modification de la donnée dans la source principale (DB).

​
Intégrité des Données

L’intégrité des données garantit que les données sont exactes, cohérentes et fiables sur l’ensemble de leur cycle de vie. Bien que ce concept soit natif au modèle Relationnel (ACID), des stratégies sont nécessaires pour le maintenir dans tous les modèles. Mécanismes pour l’Intégrité
MécanismeModèle TypiqueDescription
Transactions ACIDRelationnel (SQL)Assurent qu’un ensemble d’opérations est exécuté comme une seule unité (tout ou rien). Essentiel pour les opérations financières.
Contraintes de SchémaRelationnel (SQL)Définissent des règles au niveau de la base de données (ex: NOT NULL, UNIQUE, CHECK, Clés Étrangères) pour empêcher l’insertion de données invalides.
Validation au Niveau de l’ApplicationNoSQL (Document)Puisque le schéma est flexible, l’intégrité doit être principalement garantie par la logique métier dans l’API/le Microservice.
Pattern SagaMicroservices DistribuésRemplace les transactions distribuées (non possibles ou trop coûteuses) en utilisant une séquence de transactions locales, chacune compensée en cas d’échec par une transaction inverse.
Versionnement OptimisteTous ModèlesTechnique pour éviter les conflits d’écriture concurrente. Un champ de version ou un timestamp est inclus. Si le numéro de version a changé au moment de la mise à jour, l’écriture est rejetée et l’application cliente doit recharger la donnée et réessayer.
Stratégie Polyglotte et Intégrité Dans une architecture Microservices utilisant plusieurs types de bases de données (Polyglot Persistence), la responsabilité de l’intégrité des données migre du SGBD (Système de Gestion de Base de Données) vers le service propriétaire de ces données. C’est ce service qui doit s’assurer que ses données restent cohérentes et valides avant de les exposer aux autres services.