Migration des bases de données dans le cloud : mode d’emploi

Itamar Ben Hemo, CEO de Rivery partage son expertise sur la migration des bases de données dans le Cloud.

Cette migration peut être réalisée pour différentes raisons, comme l’optimisation des performances, la réduction des coûts ou l’accès à des fonctionnalités avancées. L’idée ici est de voir quelles sont les différentes méthodes qui peuvent être appliquées et d’identifier celle qui semble la plus efficace. Aujourd’hui, il faut au maximum éviter les migrations dites Big Bang, à savoir réalisées d’un seul coup sans possibilité de retour en arrière, ou « au compte-goutte » qui introduisent une couche supplémentaire de complexité. Il faut ainsi aujourd’hui privilégier la migration parallèle directe.

L’objectif de cette stratégie de migration est de faire vivre l’ancienne et la nouvelle base de données en parallèle avec les données de production. C’est la stratégie à privilégier. Dans une migration, il va forcément arriver un moment où soit quelque chose ne va pas, soit il manque des données, soit les données du nouveau système ne correspondent pas à celles de l’ancien. Quelle que soit la façon dont cette migration sera envisagée, il faudra deux choses que seule une migration parallèle en direct peut fournir :

• une validation permanente de la concordance entre les données de l’ancien et du nouveau système
• un moyen facile de tester le nouveau système avec des données et des rapports en temps réel, et de pouvoir revenir en arrière de manière fiable si nécessaire.

Voici donc les étapes à suivre pour réaliser cette migration : 

Migration des données de l’ancien système vers le nouveau

Avant de migrer les données, il faut déterminer comment gérer les différences entre les deux systèmes. Si la plupart des bases de données et des entrepôts de données prennent en charge les mêmes commandes SQL de base, chaque solution basée sur SQL possède sa propre « sauce » et des caractéristiques qui vont au-delà des normes ANSI SQL.

Par exemple, comment les bases de données traitent les données JSON, ou les tableaux de données dans une seule cellule. Ce qu’elles prennent en charge en termes de types de données, d’index, de procédures stockées, de vues, de déclencheurs, de clés étrangères et de fonctions ne sont que quelques-unes des différences communes entre les bases de données.

Si la nouvelle base de données reproduit autant que possible la structure de l’ancienne, il sera plus facile de faire des comparaisons entre les deux bases, mais il faudra peser le pour et le contre des améliorations possibles des performances.

Maintenir la synchronisation des deux systèmes

Attention, il ne faut surtout pas essayer de construire sa propre solution : l’intérêt de passer au cloud computing est de ne pas avoir à gérer l’infrastructure soi-même. Il existe une multitude d’excellents outils et de plates-formes SaaS qui traitent de ce problème. Il ne faut surtout pas réinventer la roue.

Le choix de l’outil le mieux adapté dépasse le cadre de cet article, mais la décision la plus importante à prendre est de savoir s’il faut une synchronisation en continu (en temps réel) ou par lots. La synchronisation par lots signifie que les dernières mises à jour sont copiées par lots, par exemple toutes les 5 minutes, toutes les heures ou peut-être une fois par jour. La synchronisation en continu signifie que chaque mise à jour est diffusée en « temps réel » de la source vers la cible.

Si les mises à jour en continu semblent intéressantes, les mises à jour par lots sont beaucoup plus simples à mettre en œuvre et plus faciles à récupérer en cas de défaillance. Si un délai de 5 minutes est acceptable, mieux vaut opter pour les lots, ce choix sera très bénéfique plus tard.

Un type spécifique de solution à examiner afin de maintenir la synchronisation entre la base de données source et la base de données cible est appelé Change Data Capture, ou CDC en abrégé. La capture des données de changement est une méthodologie de capture des changements de données dans une base de données source afin de transmettre ces mises à jour à une base de données cible ou à un entrepôt de données. Les exemples de changements qui sont suivis sont les insertions, les mises à jour, les suppressions ou les changements de schéma.