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.
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, les donnéesETL, 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 EC2 les instances.
Neptune, en revanche, est une base de données graphique OLTP ciblée dont l'architecture sépare les responsabilités et où les ressources sont découplées afin de pouvoir évoluer 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
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 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 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 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 de Neptune, vous pouvez mettre en miroir un cluster dans jusqu'à cinq autres régions.
Neptune est également tolérant aux pannes par conception :
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 ou activez la fonctionnalité Neptune sans serveur.
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é. 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.
