Migrez vers CockroachDB - Partie 1
[English version available here]
La migration d'une base de données vers une autre n'est jamais une tâche facile. Quelle que soit votre solution, le passage à un autre outil nécessite une préparation et une adaptation. C'est souvent une tâche que vous allez gérer comme un projet.
Pour aborder ce sujet, j'ai décidé de décomposer le problème en deux parties.
Dans cette première partie, nous allons parler du déplacement du schéma, la partie la plus facile.
Migrer votre schéma
Les données peuvent être stockées dans différents formats, en fonction de la base de données que vous utilisez. Je vais me concentrer ici sur le format le plus connu et parler des documents JSON et des schémas relationnels.
Transformation depuis un format JSON
Imaginons que vous stockez des informations sur les hôtels comme ceci :
Nous pouvons voir une recommandation parfois utilisée pour ajouter le type dans le document. Lors du passage à un schéma SQL, cela n'est généralement pas utile car c'est l'objectif exact du schéma !
Nous pouvons également observer le genre de choses qui pourraient vous faire décider de passer à quelque chose de différent. La description de l'hôtel est assez simple et peut facilement être transformée en un format SQL.
Le problème se pose lorsque nous voulons traiter l'attribut "reviews". Celui-ci n'est pas un simple champ mais une relation entre l'hôtel et les avis. Le problème avec une base de données documentaire NoSQL est de savoir ce que cela signifie d'avoir des milliers d'avis pour un hôtel ? Comment gérer la croissance du document ? Quel sera le coût de sortie lorsque vous déplacerez un gros JSON hors de votre fournisseur de cloud? Que faire si vous ne voulez afficher que les cinq derniers avis ? Vous avez différentes solutions pour gérer cela, mais souvent vous aurez un document d'avis avec un identifiant composé de l'identifiant de l'hôtel et d'une sorte d'unicité ou vous créerez une requête pour récupérer les avis dédiés à cet hôtel particulier.
Lors du passage à une base de données relationnelle, tout sous-document (qui est une relation) est généralement transformé en une table et en une relation de clé étrangère avec la table principale. C'est assez simple !
Ce qui est moins simple, c'est la partie "ratings". Dans ce cas, vous pouvez décider de créer une fois de plus une table d'évaluation avec un lien sur un ID d'évaluation. Comme l'évaluation est directement associée à l'avis, vous pouvez également ajouter des colonnes supplémentaires à la table des avis que vous allez créer. La dernière option consiste à utiliser un type JSONB pour conserver les évaluations au format JSON et faciliter leur évolution. C'est vraiment à vous de décider ce qui est le mieux, en fonction de votre cas d'utilisation, des modèles d'accès aux requêtes, etc.
Pour convertir un document JSON en tableau(x), vous pouvez trouver de nombreux outils qui vous aideront. Mais il est important de garder le contrôle de la transformation et de l'ajuster en fonction de vos besoins.
Une fois la transformation effectuée, vous pouvez vérifier les types de données dans CockroachDB pour vous assurer que la transformation est correcte.
Transformer un schéma relationnel
Si vous utilisez un SGBDR, alors vous avez déjà un schéma. Mais il n'est pas facile de le déplacer car toutes les bases de données du marché ne suivent pas une norme.
Les types de données, les énumérations, etc. peuvent être gérés et définis dans différentes formes qui ne sont pas compatibles. Dans une base de données distribuée comme CockroachDB, l'utilisation d'une séquence pour l'unicité est une mauvaise pratique. Les contraintes sur les colonnes, les clés étrangères, etc. ne sont pas appliquées de la même manière.
Prenons un exemple concret:
Ici, nous créons une table pour les fournisseurs et une autre pour vos contacts d'un fournisseur spécifique. Les identifiants sont gérés automatiquement en auto-incrémentant un INT.
Comme dit précédemment, ce n'est pas une bonne pratique d'utiliser des séquences pour une clé primaire dans CockroachDB. Vous pouvez changer le type de données pour les champs ID, mais que se passe-t-il avec les clés étrangères ? Cela ne fonctionnera pas !
Cette clé étrangère est parfaitement valide lorsque l'ID est un INT, car il s'agit du même type dans les deux tables. Mais si vous changez l'ID en UUID, vous devez également modifier la définition de la table liée.
Votre base de données peut également s'appuyer sur des procédures stockées. Lorsqu'elles ne sont pas prises en charge ou dans une langue différente, vous devrez adapter votre code. Mais c'est un autre sujet !
Pour résumer, quel que soit le système d'où vous venez et la destination, la migration d'une base de données est toujours quelque chose que vous devez préparer soigneusement.
Cockroach peut vous aider
Identifier les modifications à apporter n'est pas une tâche facile. Heureusement, CockroachDB a proposé un outil pour vous aider dans votre migration.
Je l'ai utilisé pour démontrer son fonctionnement avec l'exemple fourni précédemment pour la table des fournisseurs. Je l'ai exécuté deux fois, l'une en mettant à jour les clés en UUID, et l'autre en gardant les clés en séquence.
J'ai passé le script de création de schéma entier, pas seulement les deux tables utilisées.
Voici le résultat avec le maintien des séquences :
Toutes les suggestions portent sur des séquences :
Passage à l'UUID directement pour évaluer la migration :
Le résultat est très différent:
Comme discuté précédemment, l'erreur est due à des types différents. Nous avons demandé de changer le type bosuppliers.id en UUID, mais bosupplierpersons.supplierid est toujours un INT jusqu'à présent.
Ce que vous décidez de faire est important pour la partie suivante, le déplacement des données. L'adaptation du schéma nécessitera des transformations de données.
Une autre option consiste à utiliser une nouvelle colonne et un index. L'idée est d'utiliser une colonne invisible qui stockera un identifiant unique et de conserver l'identifiant original sous forme d'INT. La clé primaire sera modifiée :
Pour utiliser cette option, vous ne pouvez pas compter sur les séquences car l'ID original ne sera plus incrémenté automatiquement. Cette solution peut s'avérer utile lorsque vous importez des données en assurant leur répartition sur le cluster. Vous devez alors travailler sur votre application pour gérer le changement correctement. Il n'est pas nécessaire de définir la PK comme non visible, c'est juste une option que vous avez.
Conclusion
Aussi utile que MOLT puisse être, il n'aide qu'à migrer le schéma par lui-même. Il ne déplace pas les données et n'adapte pas les applications. Il simplifiera le processus de test. Vous pouvez vous attendre à ce que votre schéma soit prêt en quelques minutes et à ce que vous exécutiez une série de tests pour vous assurer que les requêtes des applications sont toujours valides, même sans données. Si vos requêtes renvoient des erreurs, vous devrez alors vérifier ce qui se passe. La partie la plus facile est maintenant faite. Dans la deuxième partie, je parlerai du déplacement de vos données dans ce nouveau schéma.