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](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/) de Stephen Orban. 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. # Différences architecturales entre Neptune et Neo4j Lorsque les clients envisagent pour la première fois de migrer une application de Neo4j vers Neptune, il est souvent tentant d'effectuer une like-to-like comparaison basée sur la taille de l'instance. Cependant, les architectures de Neo4j et Neptune présentent des différences fondamentales. Neo4j est basé sur une all-in-one approche dans laquelle le chargement des données, l'ETL des données, les requêtes d'application, le stockage des données et les opérations de gestion se déroulent tous dans le même ensemble de ressources de calcul, telles que les instances EC2. En revanche, Neptune est une base de données orientée graphe axée sur l'OLTP. Son architecture sépare les responsabilités, et ses ressources sont découplées afin qu'elles puissent se mettre à l'échelle de manière dynamique et indépendante. Lors de la migration de Neo4j vers Neptune, déterminez les exigences de durabilité, de disponibilité et d'évolutivité des données de votre application. L'architecture de cluster de Neptune simplifie la conception d'applications nécessitant une durabilité, une disponibilité et une capacité de mise à l’échelle élevées. En comprenant l'architecture de cluster de Neptune, vous pourrez concevoir une topologie de cluster Neptune qui répond à ces exigences. ## Architecture de cluster de Neo4j De nombreuses applications de production utilisent le [clustering causal](https://neo4j.com/docs/operations-manual/current/clustering/introduction/) de Neo4j pour garantir la durabilité, la haute disponibilité et la capacité de mise à l’échelle des données. L'architecture de clustering de Neo4j utilise des instances de serveur principal et de réplica en lecture : + Les serveurs principaux assurent la durabilité des données et la tolérance aux pannes en répliquant les données à l'aide du protocole Raft. + Les réplicas en lecture utilisent l'expédition des journaux de transactions pour répliquer les données de manière asynchrone pour les charges de travail à haut débit de lecture. Chaque instance d'un cluster, qu'il s'agisse du serveur principal ou d'un réplica en lecture, contient une copie complète des données du graphe. ## Architecture de cluster de Neptune Un [cluster Neptune](feature-overview-db-clusters.md) est composé d'une instance d'enregistreur principale et d'un maximum de 15 instances de réplica en lecture. Toutes les instances du cluster partagent le même service de stockage distribué sous-jacent, distinct des instances. + L'instance d'enregistreur principale coordonne toutes les opérations d'écriture dans la base de données et est évolutive verticalement pour assurer une prise en charge flexible des différentes charges de travail d'écriture. Elle prend également en charge les opérations de lecture. + Les instances de réplica en lecture prennent en charge les opérations de lecture à partir du volume de stockage sous-jacent et vous permettent d'effectuer une mise à l'échelle horizontale pour répondre aux besoins des charges de travail à haut débit de lecture. Elles assurent également une haute disponibilité en servant de cibles de basculement pour l'instance principale. **Note** Pour les charges de travail impliquant un grand nombre d'écritures, il est préférable de mettre à l'échelle les instances de réplica en lecture pour qu'elles soient de la même taille que l'instance d'enregistreur, afin de garantir la cohérence des lecteurs face aux modifications des données. + Le volume de stockage sous-jacent met automatiquement à l'échelle la capacité de stockage à mesure que les données de votre base de données augmentent, jusqu'à 128 tébioctets (Tio) de stockage. Les tailles d'instance sont dynamiques et indépendantes. Chaque instance peut être redimensionnée pendant l'exécution du cluster, et des réplicas en lecture peuvent être ajoutés ou supprimés pendant l'exécution du cluster. La fonctionnalité [Neptune sans serveur](neptune-serverless.md) permet d'augmenter ou de diminuer automatiquement la capacité de calcul en fonction de la hausse ou de la baisse de la demande. Cela permet non seulement de réduire votre charge administrative, mais également de configurer la base de données pour qu'elle puisse gérer les pics de demande importants sans dégrader les performances ni vous obliger à provisionner plus de ressources que nécessaire. Vous pouvez arrêter un cluster Neptune pendant une durée pouvant atteindre sept jours. Neptune prend également en charge l'[autoscaling](manage-console-autoscaling.md) afin d'ajuster automatiquement la taille des instances de lecteur en fonction de la charge de travail. Grâce à la [fonctionnalité de base de données globale](neptune-global-database.md) de Neptune, vous pouvez mettre en miroir un cluster dans jusqu'à cinq autres régions. Neptune est également [tolérant aux pannes par conception](backup-restore-overview-fault-tolerance.md) : + Le volume de cluster qui fournit le stockage de données à toutes les instances du cluster couvre plusieurs zones de disponibilité (AZs) en une seule Région AWS. Chaque zone de disponibilité contient une copie intégrale des données du cluster. + Si l'instance principale devient indisponible, Neptune bascule automatiquement vers un réplica en lecture existant sans aucune perte de données, généralement en moins de 30 secondes. S'il n'existe aucune réplica en lecture dans le cluster, Neptune provisionne automatiquement une nouvelle instance principale, là aussi sans aucune perte de données. Autrement dit, lors de la migration d'un cluster causal Neo4j vers Neptune, vous n'avez pas à concevoir explicitement la topologie du cluster pour une haute durabilité des données et une disponibilité élevée. Cela vous permet de dimensionner votre cluster en fonction des charges de travail de lecture et d'écriture attendues et de toute exigence de disponibilité accrue que vous pourriez avoir, en seulement quelques étapes : + Pour mettre à l'échelle les opérations de lecture, [ajoutez des instances de réplica en lecture](feature-overview-db-clusters.md#feature-overview-read-replicas) ou activez la fonctionnalité [Neptune sans serveur](neptune-serverless.md). + Pour améliorer la disponibilité, distribuez l'instance principale et lisez les répliques dans votre cluster sur plusieurs zones de disponibilité (AZs). + Pour réduire le temps de basculement, provisionnez au moins une instance de réplica en lecture qui servira de cible de basculement pour l'instance principale. Vous pouvez déterminer l'ordre dans lequel les réplicas en lecture sont promus en instance principale après un échec [en affectant à chaque réplica une priorité](manage-console-add-replicas.md). Il est recommandé de s'assurer qu'une cible de basculement possède une classe d'instances capable de gérer la charge de travail d'écriture de votre application si elle est promue en instance principale. # Différences de stockage des données entre Neptune et Neo4j Neptune utilise un [modèle de données de graphe](feature-overview-data-model.md) basé sur un modèle de quadruplet natif. Lorsque vous migrez vos données vers Neptune, il existe plusieurs différences dont vous devez tenir compte dans l'architecture du modèle de données et de la couche de stockage afin d'utiliser de manière optimale le stockage partagé distribué et évolutif fourni par Neptune : + Neptune n'utilise aucun schéma ni aucune contrainte définis de manière explicite. Il vous permet d'ajouter des nœuds, des arêtes et des propriétés de manière dynamique sans avoir à définir le schéma à l'avance. Neptune ne limite pas les valeurs et les types de données stockées, sauf indication contraire spécifiée dans les [limites Neptune](limits.md#limits-properties). Dans le cadre de l'architecture de stockage de Neptune, les données sont également [automatiquement indexées](feature-overview-storage-indexing.md) de manière à gérer la plupart des modèles d'accès les plus courants. Cette architecture de stockage élimine les coûts opérationnels liés à la création et à la gestion du schéma de base de données et à l'optimisation des index. + Neptune fournit une architecture de stockage distribuée et partagée unique qui s'adapte automatiquement par tranches de 10 Go à mesure que les besoins de stockage de votre base de données augmentent, jusqu'à 128 tébioctets (Tio). Cette couche de stockage est fiable, durable et tolérante aux pannes. Les données sont copiées six fois : deux fois dans chacune des trois zones de disponibilité. Elle fournit par défaut à tous les clusters Neptune une couche de stockage de données hautement disponible et tolérante aux pannes. L'architecture de stockage de Neptune réduit les coûts et évite d'avoir à provisionner du stockage ou plus de stockage que nécessaire pour faire face à la croissance future des données. Avant de migrer vos données vers Neptune, il est conseillé de vous familiariser avec le [modèle de données du graphe de propriétés](feature-overview-storage-indexing.md#feature-overview-storage-indexing-gremlin) et la [sémantique des transactions](transactions.md) de Neptune. # Différences opérationnelles entre Neptune et Neo4j Neptune est un service entièrement géré qui automatise la plupart des tâches opérationnelles normales que vous devez effectuer lorsque vous utilisez des bases de données sur site ou autogérées telles que Neo4j Enterprise ou Community Edition : + **[Sauvegardes automatisées](backup-restore.md#backup-restore-overview-backups)** : Neptune sauvegarde automatiquement le volume de votre cluster et conserve la sauvegarde pendant une période de rétention que vous spécifiez (comprise entre 1 et 35 jours). Ces sauvegardes étant continues et incrémentielles, vous pouvez rapidement opérer une restauration à un point quelconque de la période de rétention. Aucun impact sur les performances ou interruption du service de base de données ne se produit lors de l’écriture des données de sauvegarde. + **[Instantanés manuels](backup-restore.md)** : Neptune vous permet de créer un instantané du volume de stockage de votre cluster de bases de données pour sauvegarder l'intégralité du cluster. Ce type d'instantané pourra être utilisé pour restaurer la base de données, en faire une copie et la partager entre les comptes. + **[Clonage](manage-console-cloning.md)** : Neptune prend en charge une fonctionnalité de clonage qui vous permet de créer rapidement des clones économiques d'une base de données. Les clones utilisent un copy-on-write protocole qui ne nécessite qu'un minimum d'espace supplémentaire après leur création. Le clonage de base de données est un moyen efficace de tester les nouvelles fonctionnalités ou mises à niveau de Neptune sans affecter le cluster d'origine. + **[Surveillance](monitoring.md)** : Neptune propose différentes méthodes pour surveiller les performances et l'utilisation de votre cluster, notamment : + Statut de l'instance + Intégration avec Amazon CloudWatch et AWS CloudTrail + Fonctionnalités du journal d'audit + Notifications d’événements + Identification + **[Sécurité](security.md)** : Neptune fournit un environnement sécurisé par défaut. Un cluster réside dans un VPC privé qui permet d'isoler le réseau des autres ressources. Tout le trafic est crypté via SSL, et toutes les données sont cryptées au repos à l'aide de AWS KMS. [En outre, Neptune s'intègre à Gestion des identités et des accès AWS (IAM) pour fournir une authentification.](iam-auth.md) En spécifiant des [clés de condition IAM](iam-condition-keys.md), vous pouvez utiliser des politiques IAM pour fournir un contrôle d'accès précis au niveau des [actions sur les données](iam-data-access-policies.md). ## Différences d'outils et d'intégration entre Neptune et Neo4j Neptune possède une architecture d'intégrations et d'outils différente de celle de Neo4j, ce qui peut avoir un impact sur l'architecture de votre application. Neptune utilise les ressources de calcul du cluster pour traiter les requêtes, mais utilise d'autres best-in-class AWS services pour des fonctionnalités telles que la recherche en texte intégral (utilisation OpenSearch), ETL (utilisation de Glue), etc. Pour obtenir la liste complète de ces intégrations, consultez [Intégrations Neptune](integrations.md).