L’auteur raconte comment son équipe a migré plus d’un milliard d’enregistrements d’une base de données critique (contenant des données financières) vers une nouvelle, sans aucune interruption de service. Voici les étapes clés et les leçons apprises :
-
Migration par lots des données historiques : Les données ont été divisées en chunks par plages d’ID, chargées en parallèle avec les index et contraintes désactivés pour accélérer le processus, puis vérifiées par des checksums pour garantir l’intégrité.
-
Écritures doubles (dual writes) : Pendant la migration, chaque nouvelle écriture était dupliquée vers l’ancienne et la nouvelle base. Les échecs étaient gérés via une file Kafka de réessai, avec des écritures idempotentes pour éviter les doublons.
-
Lectures fantômes (shadow reads) : Les requêtes étaient exécutées en silence sur la nouvelle base et comparées à l’ancienne pour détecter des incohérences (fuseaux horaires, collations, valeurs NULL), permettant de corriger les problèmes avant de basculer les utilisateurs.
-
Bascule progressive (cutover) : La nouvelle base a été préchauffée (cache et index), et le basculement a eu lieu à 4h30, heure de faible trafic, avec un mécanisme de retour arrière (rollback) prêt. Les métriques business et techniques ont été surveillées en temps réel.
-
Observabilité totale : Des tableaux de bord ont suivi la latence, le lag de réplication, les deadlocks, et les KPI métiers pour détecter instantanément tout problème.
Leçons clés :
- Les migrations à grande échelle se font par lots parallèles, avec des mécanismes de reprise et de vérification.
- Les dual writes et les shadow reads sont essentiels pour capturer les données en temps réel et valider la nouvelle base.
- La bascule doit être préparée comme une opération critique : cache préchauffé, monitoring obsessionnel, et plan de rollback.
- Une migration réussie repose sur la conception distribuée (idempotence, files de réessai) et une observabilité fine (WAL, cache, deadlocks).
En traitant la migration comme un problème de system design plutôt que technique, l’équipe a pu garantir une transition sans temps d’arrêt, malgré la pression et les risques financiers.
Comment fonctionnent les index dans les bases de données
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur fait le point sur les différents systèmes de gestion de données : des SGBD jusqu'au concept de maillage de données (Data Mesh)
Tout est dans le titre
L'astuce concerne surtout l'idée d'une base par environnement (dev, test)
Une introduction aux bases de données orientées graphes
Un excellent et long article sur le chiffrement des bases de données, relationnelles ou pas...
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'idée défendue par l'auteur est de mettre la logique de données (!= logique métier) dans la base de données. L'exemple qu'il prend est celui des tables "facture" et "ligne_facture". Le champ "total" de "facture" est recalculé dès l'insertion / modification / suppression dans "ligne_facture"
Tout est dans le titre, sauf que les ULID permettent de résoudre un pb spécifique aux UUID : la capacité de les trier par ordre croissant / décroissant. L'idée est simple : utiliser un timestamp sur les 48 premiers bits, puis le reste des 80 bits aléatoirement. La probabilité de collision restera très très faible tout en donnant la possibilité de classer les ULID.
Tout est dans le titre