Étapes de pré-migration pour les migrations de données de MongoDB vers Azure Cosmos DB for MongoDB

Article
08/15/2024

S’APPLIQUE À : MongoDB

Important

Veuillez lire ce guide dans son intégralité avant de suivre les étapes de prémigration.

Ce guide de prémigration de MongoDB fait partie d'une série consacrée à la migration de MongoDB. Les principales étapes de migration de MongoDB sont la prémigration, la migration proprement dite et la postmigration, comme indiqué dans ce guide.

Diagramme des étapes de migration de la pré à la post-migration.

Présentation de la prémigration

Il est essentiel de procéder à une planification à l’avance et de prendre certaines décisions avant d'entamer la migration réelle des données. Ce processus décisionnel initial est appelé « prémigration ».

Vos objectifs dans la prémigration sont les suivants :

Veillez à configurer Azure Cosmos DB pour répondre aux exigences de votre application.
Planifiez la façon dont vous effectuerez la migration.

Suivez les étapes ci-dessous pour effectuer une prémigration complète :

Découvrir vos ressources MongoDB existantes et évaluer la préparation de vos ressources MongoDB existantes pour la migration des données
Mappez vos ressources MongoDB existantes avec les nouvelles ressources Azure Cosmos DB
Planifiez la logistique du processus de migration de bout en bout avant de lancer la migration des données à grande échelle

Exécutez ensuite votre migration conformément à votre plan de prémigration.

Enfin, suivez les étapes critiques de postmigration que sont le basculement et l'optimisation.

Toutes les étapes ci-dessus sont essentielles à la réussite de la migration.

Lorsque vous planifiez une migration, nous vous recommandons, dans la mesure du possible, de procéder à une planification au niveau de chaque ressource.

Évaluation de la prémigration

La première étape de pré-migration consiste à découvrir vos ressources MongoDB existantes et à évaluer la préparation de vos ressources à la migration.

La découverte implique de créer une liste complète des ressources existantes (bases de données ou collections) dans votre patrimoine de données MongoDB.

L’évaluation implique de déterminer si vous utilisez les fonctionnalités et la syntaxe prises en charge. Elle inclut également une liste permettant de vérifier si vous respectez les limites et quotas. L’objectif de cette étape est de créer une liste d’incompatibilités et d’avertissements, le cas échéant. Une fois que vous avez les résultats de l’évaluation, vous pouvez essayer de traiter les résultats pendant le reste de la planification de la migration.

Il existe 3 façons d’effectuer l’évaluation de la pré-migration. Nous vous recommandons d’utiliser l’extension Migration de Azure Cosmos DB pour MongoDB.

Extension Migration Azure Cosmos DB for MongoDB

L’extension Migration Azure Cosmos DB for MongoDB dans Azure Data Studio vous permet d’évaluer une charge de travail MongoDB en vue de sa migration vers Azure Cosmos DB for MongoDB. Vous pouvez utiliser cette extension pour exécuter une évaluation de bout en bout sur votre charge de travail, et découvrir les actions que vous devrez peut-être effectuer pour migrer vos charges de travail sans problème sur Azure Cosmos DB. Pendant l’évaluation d’un point de terminaison MongoDB, l’extension signale toutes les ressources découvertes.

Notes

Nous vous recommandons également de passer en revue les fonctionnalités et la syntaxe prises en charge, les limites et quotas Azure Cosmos DB en détail, ainsi que d’effectuer une preuve de concept avant la migration réelle.

Découverte manuelle (héritée)

Vous pouvez également créer une feuille de calcul de migration de patrimoine de données. L’objectif de cette feuille de calcul est d’améliorer votre productivité et de vous aider à planifier la migration de bout en bout et à l’utiliser comme document de suivi tout au long du processus de migration.

Cette feuille contient une liste complète des ressources existantes (bases de données ou collections) dans votre patrimoine de données MongoDB.
La feuille de calcul doit être structurée pour répertorier les ressources de votre patrimoine de données.
Chaque ligne de la liste correspond à une ressource (base de données ou collection).
Chaque colonne correspond à une propriété de la ressource. Commencez donc par utiliser au moins le nom et la taille des données (en Go) en tant que colonnes.
Au fil de votre progression dans ce guide, vous allez transformer cette feuille de calcul en document de suivi pour la planification de votre migration de bout en bout, en y ajoutant des colonnes en fonction des besoins.

Voici quelques outils que vous pouvez utiliser pour découvrir les ressources :

Parcourez la feuille de calcul et vérifiez chaque collection par rapport aux fonctionnalités et à la syntaxe prises en charge, ainsi qu’aux limites et quotas Azure Cosmos DB en détail.

Utilitaire de l’Assistant Migration de base de données (hérité)

Notes

L’Assistant Migration de base de données est un utilitaire hérité destiné à vous aider lors des étapes de préalables à la migration. Nous vous recommandons d’utiliser l’extension Migration Azure Cosmos DB pour MongoDB pour toutes les étapes antérieures à la migration.

Vous pouvez utiliser l’utilitaire DMA (Database Migration Assistant ) pour vous aider à effectuer les étapes de pré-migration.

Mappage de prémigration

Une fois les étapes de découverte et d'évaluation terminées, vous en aurez fini avec la partie MongoDB de l'équation. Il est maintenant temps de planifier la partie Azure Cosmos DB. Comment comptez-vous installer et configurer vos ressources Azure Cosmos DB de production ? Effectuez votre planification au niveau de chaque ressource. Pour ce faire, vous devez ajouter les colonnes suivantes à votre feuille de calcul de planification :

Mappage d'Azure Cosmos DB
Clé de partition
Modèle de données
Débit dédié et débit partagé

De plus amples détails sont fournis dans les sections qui suivent.

planification de la capacité

Vous tentez d’effectuer une planification de la capacité pour une migration vers Azure Cosmos DB ?

Si vous ne connaissez que le nombre de vCore et de serveurs présents dans votre cluster de bases de données existant, lisez Estimation des unités de requête à l’aide de vCore ou de processeurs virtuels.
Si vous connaissez les taux de requêtes typiques de votre charge de travail de base de données actuelle, lisez la section concernant l’estimation des unités de requête à l’aide du planificateur de capacité Azure Cosmos DB

Considérations relatives à l’utilisation de l’API Azure Cosmos DB pour MongoDB

Avant de planifier votre patrimoine de données Azure Cosmos DB, assurez-vous de bien comprendre les concepts Azure Cosmos DB suivants :

Modèle de capacité : La capacité de base de données dans Azure Cosmos DB est basée sur un modèle basé sur le débit. Ce modèle est basé sur les unités de requête par seconde et constitue une unité qui représente le nombre d’opérations de base de données pouvant être exécutées par seconde sur une collection. Cette capacité peut être allouée au niveau d’une collection ou d’une base de données, et elle peut être approvisionnée sur un modèle d’allocation ou à l’aide du débit approvisionné en mode de mise à l’échelle automatique.
Unités de requête : Chaque opération de base de données a un coût d’unités de requête (RU) associé dans Azure Cosmos DB. Une fois l’opération exécutée, les unités de requête sont soustraites du niveau d’unités de requête disponible à une seconde donnée. Si une demande nécessite plus d’unités de requête que le nombre d’unités de requête actuellement allouées par seconde, deux options s’offrent à vous pour résoudre le problème : augmenter le nombre d’unités de requête ou attendre que la seconde suivante démarre, puis recommencer l’opération.
Capacité élastique : La capacité d’une collection ou d’une base de données donnée peut changer à tout moment. Cette flexibilité permet à la base de données de s’adapter de manière élastique aux exigences de débit de votre charge de travail.
Partitionnement automatique : Azure Cosmos DB fournit un système de partitionnement automatique qui requiert un seul partitionnement (ou une clé de partition). Le mécanisme de partitionnement automatique est partagé entre toutes les API Azure Cosmos DB et permet une mise à l’échelle transparente des données et du débit via une distribution horizontale.

Planifier le patrimoine de données Azure Cosmos DB

Déterminez les ressources Azure Cosmos DB que vous allez créer. Ce processus nécessite de passer en revue la feuille de calcul de migration de votre patrimoine de données et de mapper chaque ressource MongoDB existante avec une nouvelle ressource Azure Cosmos DB.

Prévoyez que chaque base de données MongoDB devienne une base de données Azure Cosmos DB.
Prévoyez que chaque collection MongoDB devienne une collection Azure Cosmos DB.
Choisissez une convention d'affectation de noms pour vos ressources Azure Cosmos DB. Conserver les mêmes noms de ressource est généralement le bon choix, sauf si des modifications sont apportées dans la structure des bases de données et des collections.
Déterminez si vous utilisez des collections partitionnées ou non partitionnées dans Azure Cosmos DB. La limite de collections non partitionnées est de 20 Go. Le partitionnement, en revanche, permet d’obtenir une mise à l’échelle horizontale qui est essentielle aux performances de nombreuses charges de travail.
Si vous utilisez des collections partitionnées, ne partez pas du principe que votre clé de partition de collection MongoDB devient votre clé de partition de conteneur Azure Cosmos DB. Ne partez pas du principe que votre structure de document de modèle de données MongoDB existante doit être la même que celle que vous utilisez sur Azure Cosmos DB.
- La clé de partition est le paramètre le plus important pour optimiser la scalabilité et les performances d'Azure Cosmos DB, devant le paramètre de modélisation des données. Ces deux paramètres sont immuables et ne peuvent pas être modifiés une fois qu'ils sont définis ; par conséquent, il est très important de les optimiser au cours de la phase de planification. Pour plus d'informations, suivez les instructions de la section Décisions immuables.
Azure Cosmos DB ne reconnaît pas certains types de collections MongoDB, comme les collections limitées. Pour ces ressources, contentez-vous de créer des collections Azure Cosmos DB normales.
Azure Cosmos DB dispose de deux types de collections qui lui sont propres : le débit partagé et le débit dédié. Débit partagé ou débit dédié ? Il s'agit là d'une autre décision importante et immuable qu'il est essentiel de prendre lors de la phase de planification. Pour plus d'informations, suivez les instructions de la section Décisions immuables.

Décisions immuables

Les choix suivants en matière de configuration d'Azure Cosmos DB ne peuvent pas être modifiés ou annulés une fois que vous avez créé une ressource Azure Cosmos DB. Il est donc important de bien définir ces choix de configuration lors de la planification de la prémigration, avant de lancer toute migration :

Reportez-vous à la page sur le partitionnement et la mise à l’échelle horizontale dans Azure Cosmos DB pour choisir la meilleure clé de partition. Le partitionnement est un point clé à prendre en compte avant de migrer des données. Azure Cosmos DB utilise un partitionnement complètement managé pour augmenter la capacité d’une base de données à répondre aux exigences de stockage et de débit. Cette fonctionnalité n’a pas besoin de l’hébergement ni de la configuration des serveurs de routage.
- D’une façon similaire, la fonctionnalité de partitionnement ajoute automatiquement de la capacité et rééquilibre les données en conséquence. Pour plus d’informations sur le choix de la clé de partition appropriée pour vos données, consultez Choisir une clé de partition.
Suivez le guide de modélisation des données dans Azure Cosmos DB pour choisir un modèle de données.
Suivez les informations de la page Optimiser le coût du débit provisionné dans Azure Cosmos DB pour choisir entre le débit dédié et partagé pour chaque ressource que vous migrez
Comment modéliser et partitionner des données sur Azure Cosmos DB à l’aide d’un exemple réel est un exemple concret de partitionnement et de modélisation des données pour vous aider dans votre processus décisionnel

Coût total de possession

Estimez le coût total de possession de vos nouvelles ressources Azure Cosmos DB à l'aide de la calculatrice de capacité Azure Cosmos DB.

Estimer le débit

Dans Azure Cosmos DB, le débit est provisionné à l’avance et mesuré en unités de requête par seconde. Contrairement aux machines virtuelles ou aux serveurs locaux, il est facile d’effectuer un scale-up ou scale-down des unités de requête à tout moment. Vous pouvez instantanément modifier le nombre d’unités de requête provisionnées. Pour en savoir plus, voir Unités de requête dans Azure Cosmos DB.
Vous pouvez utiliser la calculatrice de capacité Azure Cosmos DB pour déterminer le nombre d’unités de requête que vous devez utiliser. Ce nombre est basé sur votre configuration de compte de base de données, sur la quantité de données, la taille de document et les opérations de lecture et d’écriture requises par seconde.
Les principaux facteurs qui affectent le nombre d’unités de requête nécessaires sont les suivants :
- Taille de document : plus la taille d’un élément/document augmente, plus le nombre d’unités de requête consommées pour le lire ou l’écrire augmente.
- Nombre de propriétés de document : le nombre d’unités de requête consommées pour créer ou mettre à jour un document est lié au nombre, à la complexité et à la longueur de ses propriétés. Vous pouvez réduire la consommation d’unités de requête pour les opérations d’écriture en limitant le nombre de propriétés indexées.
- Modèles de requête : la complexité d’une requête a une incidence sur le nombre d’unités de requête qu’elle consomme.
La meilleure façon de comprendre le coût des requêtes consiste à utiliser des exemples de données dans Azure Cosmos DB et à exécuter des exemples de requête dans l’interpréteur de commandes MongoDB à l’aide de la commande getLastRequestStastistics pour obtenir les frais de requêtes, ce qui fournira le nombre d’unités de requête consommées :
```
db.runCommand({getLastRequestStatistics: 1})
```
*Cette commande génère un document JSON semblable à l’exemple suivant :
```
{
  "_t": "GetRequestStatisticsResponse",
  "ok": 1,
  "CommandName": "find",
  "RequestCharge": 10.1,
  "RequestDurationInMilliSeconds": 7.2
}
```
Vous pouvez également utiliser les paramètres de diagnostic pour comprendre la fréquence et les modèles des requêtes exécutées sur Azure Cosmos DB. Les résultats des journaux de diagnostic peuvent être envoyés à un compte de stockage, à une instance Event Hubs ou à Azure Log Analytics.

Planification de la logistique de prémigration

Enfin, maintenant que vous disposez d'une vision globale de votre patrimoine de données existant et d'une conception pour votre nouveau patrimoine de données Azure Cosmos DB, vous êtes prêt à planifier l'exécution de votre processus de migration de bout en bout. Encore une fois, effectuez votre planification au niveau de chaque ressource, en ajoutant des colonnes à votre feuille de calcul pour capturer les dimensions logistiques inclues dans cette section.

Logistique d'exécution

Attribuez la responsabilité de la migration de chaque ressource existante de MongoDB vers Azure Cosmos DB. À vous de voir comment vous allez appliquer vos ressources d’équipe pour mener à bien votre migration. Pour les petites migrations, vous pouvez confier à une seule équipe le lancement de l'ensemble de la migration et le suivi de sa progression. Pour les migrations plus volumineuses, vous pouvez confier à certains membres de l'équipe la responsabilité de la migration et de la surveillance de telle ou telle ressource.

Une fois que vous avez attribué la responsabilité de la migration de vos ressources, vous devez choisir le ou les outils de migration appropriés. Pour les petites migrations, vous pouvez utiliser un outil de migration tel qu'un outil natif MongoDB ou Azure DMS afin de migrer toutes vos ressources en une seule fois. Pour les migrations plus importantes ou avec des exigences particulières, vous pouvez choisir des outils de migration qui offre une granularité « par ressource ».

Avant de planifier les outils de migration à utiliser, nous vous recommandons de vous familiariser avec les options disponibles. Le service Azure Database Migration Service pour l’API Azure Cosmos DB pour MongoDB simplifie la migration des données en fournissant une plateforme d’hébergement complètement managée, des options de surveillance de la migration et une gestion automatique de la limitation. Voici une liste complète des options :

Type de migration	Solution	Considérations
En ligne	Azure Database Migration Service	• Utilise la bibliothèque d’exécuteur en bloc pour Azure Cosmos DB • Adapté aux jeux de données volumineux et chargé de la réplication des modifications dynamiques. • Fonctionne uniquement avec d’autres sources MongoDB.
Hors connexion	Azure Database Migration Service	• Utilise la bibliothèque d’exécuteur en bloc pour Azure Cosmos DB • Adapté aux jeux de données volumineux et chargé de la réplication des modifications dynamiques. • Fonctionne uniquement avec d’autres sources MongoDB.
Hors connexion	Azure Data Factory	• Utilise la bibliothèque d’exécuteur en bloc pour Azure Cosmos DB • Adapté aux jeux de données volumineux • Facile à configurer et prend en charge plusieurs sources • L’absence de points de contrôle signifie que tout problème lors de la migration impose le redémarrage de l’ensemble du processus de migration • L’absence de file d’attente de lettres mortes signifie que quelques fichiers erronés peuvent arrêter l’ensemble du processus de migration • Nécessite du code personnalisé pour augmenter le débit de lecture pour certaines sources de données
Hors connexion	Outils Mongo existants (mongodump, mongorestore, Studio3T)	• Facile à configurer et à intégrer • Nécessite une gestion personnalisée des limitations
Hors connexion/en ligne	Azure Databricks et Spark	• Contrôle total de la vitesse de migration et de la transformation des données • Requiert du code personnalisé

Si votre ressource peut tolérer une migration hors connexion, utilisez ce diagriamme pour choisir l'outil de migration approprié :
Si votre ressource requiert une migration en ligne, utilisez ce diagramme pour choisir l'outil de migration approprié :
Regardez cette vidéo proposant une vue d’ensemble et une démonstration des solutions de migration.

Une fois que vous avez choisi les outils de migration pour chaque ressource, l'étape suivante consiste à hiérarchiser les ressources que vous allez migrer. Une bonne hiérarchisation peut vous aider à respecter votre calendrier de migration. Nous vous recommandons de donner la priorité à la migration des ressources dont le déplacement prend le plus de temps. Effectuer la migration de ces ressources en premier sera plus efficace. En outre, étant donné que ces migrations chronophages impliquent généralement plus de données, elles sont plus gourmandes en ressources pour l'outil de migration et sont donc plus susceptibles d'exposer rapidement d’éventuels problèmes inhérents à votre pipeline de migration. Cette pratique réduit les risques de retard de calendrier dus à des problèmes de pipeline de migration.
Planifiez votre façon de surveiller la progression de la migration une fois qu'elle aura commencé. Si vous coordonnez votre migration des données au sein d'une équipe, prévoyez un rythme régulier de synchronisations d'équipe afin d'avoir une vue d'ensemble de l'avancement des migrations prioritaires.

Scénarios de migration pris en charge

Le meilleur choix d'outil de migration MongoDB dépend de votre scénario de migration.

Types de migrations

Voici une liste d’outils compatibles pour chaque scénario de migration :

Source	Destination	Recommandation en matière de processus
• Cluster MongoDB local • Cluster MongoDB sur machine virtuelle IaaS • Cluster MongoDB Atlas – Hors connexion	API Mongo d’Azure Cosmos DB	• <données de 10 Go : outils natifs MongoDB • < 1-To de données : Azure DMS • > Données de 1 To : Spark
• Cluster MongoDB local • Cluster MongoDB sur machine virtuelle IaaS • Cluster MongoDB Atlas – En ligne	API Mongo d’Azure Cosmos DB	• < 1-To de données : Azure DMS • >Données de 1 To : Spark + Mongo ChangeStream
• Besoin de modifier le schéma pendant la migration Besoin de plus de flexibilité que les outils mentionnés ci-dessus	API Mongo d’Azure Cosmos DB	• ADF est plus flexible que DMS, il prend en charge les modifications de schéma lors de la migration ainsi que la plupart des combinaisons source/destination • DMS est meilleur en termes de mise à l’échelle (migration plus rapide, par exemple)
• Fichier JSON	API Mongo d’Azure Cosmos DB	• Outils natifs MongoDB spécifiquement mongoimport
• Fichier CSV	API Mongo d’Azure Cosmos DB	• Outils natifs MongoDB spécifiquement mongoimport
• Fichier BSON	API Mongo d’Azure Cosmos DB	• Outils natifs MongoDB spécifiquement mongorestore

Prise en charge des outils pour les versions de MongoDB

Dans la mesure où vous effectuez une migration à partir d’une version particulière de MongoDB, les outils pris en charge pour chaque version sont inclus ici :

Version source de MongoDB	Version de destination Azure Cosmos DB for MongoDB	Outils pris en charge	Outils non pris en charge
<2.x, >4.0	3.2, 3.6, 4.0	Outils natifs MongoDB, Spark	DMS, ADF
3.2, 3.6, 4.0	3.2, 3.6, 4.0	Outils natifs MongoDB, DMS, ADF, Spark	Aucun

Postmigration

Lors de la phase de prémigration, prenez le temps de planifier les étapes à suivre pour la migration et l'optimisation des applications après la migration.

Lors de la phase de postmigration, vous procédez au basculement de votre application pour utiliser Azure Cosmos DB à la place de votre patrimoine de données MongoDB existant.
Planifiez au mieux l’indexation, la distribution globale, la cohérence, et autres propriétés mutables Azure Cosmos DB au niveau de chaque ressource. Sachez toutefois que ces paramètres de configuration Azure Cosmos DB peuvent être modifiés ultérieurement, attendez-vous à apporter quelques ajustements à ces paramètres plus tard. Vous appliquez ces configurations mutables après la migration.
Pour consulter un guide de post-migration, consultez Étapes d’optimisation post-migration lors de l’utilisation de l’API Azure Cosmos DB pour MongoDB.

Étapes suivantes

Migrer vers Azure Cosmos DB for MongoDB

Partage via