Migrez vers CockroachDB - Partie 2

[English version available here]

Dans la première partie, nous avons vu comment transformer et adapter vos schémas ou vos documents JSON pour les utiliser dans CockroachDB.
Selon que vous veniez d'une base de données NoSQL comme Cassandra, MongoDB, Couchbase, etc., ou d'une base de données relationnelle comme Oracle, Postgres, MySQL, etc. vous avez apporté quelques modifications à votre schéma. Il est maintenant temps d'adapter l'application pour assurer une migration en douceur pour vos clients ou utilisateurs.

Sur cette page, vous trouverez de nombreuses informations sur la migration des données depuis Oracle, SQL Server, Postgres et MySQL.
Cela vous aidera à importer vos données depuis votre base de données existante vers CockroachDB. Mais cela ne vous aidera pas pour une migration live. Que pouvez-vous faire pour éviter les temps d'arrêt de votre application ?
Ici, je vais vous présenter un moyen de gérer cela en implémentant un modèle de concurrence dans votre référentiel.

Commençons par le début

Il est important de clarifier un peu ce que nous allons faire ici.

Cette implémentation fonctionne mieux lorsque vous utilisez le pattern CQRS, car vous avez une séparation claire entre la création et la lecture des données. Ce n'est pas obligatoire, et je présenterai un exemple sans CQRS.

L'idée est de mettre en œuvre un référentiel avec deux bases de données différentes. Vous pouvez imaginer un référentiel unique accédant à deux bases de données ou deux référentiels gérés par une couche d'abstraction. C'est à vous de définir quelle est la meilleure solution à mettre en œuvre dans votre cas. Ici, nous utiliserons un seul référentiel.

Ainsi, lorsque votre application appellera les données, vous demanderez aux deux bases de données, attendrez le résultat et vérifierez que tout est correct. Nous ne ferons cela que pour les requêtes (d'où l'intérêt du modèle CQRS), car toutes les commandes doivent être dirigées vers le cluster Cockroach. Encore une fois, vous devrez faire un choix. Est-ce que je fais confiance à Cockroach par défaut ou non ? Si vous faites confiance à CockroachDB, l'implémentation sera plus facile. Sinon, vous devrez gérer une résolution de conflit pour les données reçues des deux côtés et repousser la résolution vers CockroachDB.

Un exemple de TODO!

Je vais prendre le chemin le plus facile avec un exemple d'application TODO. Imaginons que nous ayons cette table dans un  Postgres :

Je peux décider de le modifier de cette manière pour CockroachDB

J'ai simplement changé la colonne id en UUID. Il faudra donc adapter le DTO pour s'assurer que nous avons la bonne définition des objets.

L'application ressemble à ceci :

La partie intéressante est le DAO où tous les appels à la base de données sont effectués.

Dans ce cas, nous avons des requêtes simples dirigées vers notre base de données Postgres. Au début, la table est vide dans CockroachDB et contient 400 lignes dans Postgres.
La sauvegarde est une opération de commande et doit être dirigée vers CockroachDB. Mais chaque méthode utilisant un SELECT doit être adaptée pour demander les deux bases de données.

Un cas simple

Intéressons-nous à cette méthode :

Pour adapter la méthode, nous devons interroger CockroachDB ET Postgres, comparer les résultats, et décider lequel nous voulons utiliser.
Dans mon repo, j'ai simplement ajouté des éléments pour CockroachDB, avec une configuration d'URL et un client prêt à accepter des requêtes.

La nouvelle version ressemble à ceci

Nous utilisons un waitGroup pour que les deux requêtes s'exécutent en parallèle et nous enregistrons les résultats pour la gestion de la migration. Voici un exemple de sortie

Un cas un peu plus complexe

Comme je n'ai pas encore importé de données, on peut voir beaucoup de différences dans les comptages. Maintenant, il est temps de gérer cela correctement !

Pour ce faire, je vais utiliser la méthode Get

Dans cette méthode, nous récupérons tous les todos de la table. L'idée est de mettre en œuvre la même stratégie et d'ajouter un outil de migration pour pousser les données inexistantes vers CockroachDB.

D'abord j'ajoute une méthode pour gérer la migration à la volée

Je reçois les Todos de Postgres et utilise ensuite la méthode Save pour assurer une insertion correcte dans CockroachDB.

Nous devons adapter la méthode Get pour gérer deux appels simultanés et décider si nous devons migrer les données ou non. Je réutilise exactement la même implémentation pour gérer les deux appels

Dans cet exemple, je ne fais pas une inspection approfondie des objets pour éviter les doublons, je compte simplement les éléments de chaque tableau.

Nous ajoutons simplement une ligne de journal indiquant que nous n'avons plus besoin d'accéder à Postgres.

Voici un exemple de sortie

Conclusion

Comme vous pouvez le constater, ce processus de migration peut être vraiment efficace pour éviter les temps d'arrêt des applications. Évidemment, il nécessitera une double exécution, mais selon votre cas d'usage, il peut être assez facile à gérer, surtout à l'ère des micro-services.

De plus, cet exemple est évidemment très simple, sans beaucoup de données. Mais c'est un point de départ pour réfléchir à la façon de gérer une migration en live.