Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Préparation à la migration de Neo4j vers Neptune
La migration de la base de données de graphes Neo4j vers le service de base de données de graphes Neptune peut être abordée de deux manières principales : replateforme ou refactorisation/réarchitecture. L'approche de replateforme implique de modifier le modèle de données et l'architecture d'application existants afin de tirer le meilleur parti des capacités de Neptune, tandis que l'approche de refactorisation vise à trouver des composants équivalents dans Neptune afin de créer une implémentation comparable. Dans la pratique, une combinaison de ces stratégies est souvent utilisée, car le processus de migration consiste à équilibrer l'architecture Neptune cible avec les contraintes et les exigences de l'implémentation existante de Neo4j. Quelle que soit l'approche, l'essentiel est de repartir des cas d'utilisation de l'application pour concevoir le modèle de données, les requêtes et l'architecture globale qui répondent le mieux à vos besoins.
Approches en matière de migration
Lors de la migration d'une application Neo4j vers Neptune, nous recommandons l'une des deux stratégies suivantes : le changement de plateforme ou la refactorisation/restructuration de l'architecture. Pour plus d'informations sur les stratégies de migration, consultez le billet de blog 6 Strategies for Migrating Applications to the Cloud
L'approche de replateforme, parfois appelée approche lift-tinker-and-shift, implique les étapes suivantes :
Identifiez les cas d'utilisation auxquels votre application est censée répondre.
Modifiez le modèle de données de graphe et l'architecture d'application existants pour répondre au mieux à ces besoins de charge de travail en utilisant les fonctionnalités de Neptune.
Déterminez comment migrer les données, les requêtes et les autres parties de l'application source vers le modèle et l'architecture cibles.
Cette approche rétroactive vous permet de migrer votre application vers le type de solution Neptune que vous pourriez concevoir s'il s'agissait d'un tout nouveau projet.
L'approche de refactorisation, en revanche, implique les étapes suivantes :
Identifiez les composants de la mise en œuvre existante, notamment l'infrastructure, les données, les requêtes et les fonctionnalités de l'application.
Trouvez des équivalents dans Neptune qui pourront être utilisés pour créer une implémentation comparable.
Cette approche avant-gardiste vise à remplacer une implémentation par une autre.
Dans la pratique, il est probable que vous adoptiez une combinaison de ces deux approches. Vous pouvez commencer par un cas d'utilisation, concevoir l'architecture Neptune cible, puis vous tourner vers l'implémentation Neo4j existante pour identifier les contraintes et les invariants à respecter. Par exemple, vous devrez peut-être poursuivre l'intégration avec d'autres systèmes externes ou continuer à proposer des offres spécifiques APIs aux utilisateurs de votre application graphique. Grâce à ces informations, vous pourrez déterminer quelles données existantes transférer vers votre modèle cible, et celles qui doivent aller ailleurs.
À d'autres moments, vous commencerez peut-être par analyser un élément spécifique de votre implémentation Neo4j comme étant la meilleure source d'informations sur la tâche que votre application est censée accomplir. Ce type d'archéologie dans l'application existante peut aider à définir un cas d'utilisation que vous pourrez ensuite concevoir en utilisant les fonctionnalités de Neptune.
Que vous développiez une nouvelle application à l'aide de Neptune ou que vous migriez une application existante à partir de Neo4j, nous vous recommandons de travailler de manière rétroactive en partant des cas d'utilisation pour concevoir un modèle de données, un ensemble de requêtes et une architecture d'application répondant aux besoins de votre entreprise.
