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.
Provisionnement de l'infrastructure lors de la migration de Neo4j vers Neptune
Les clusters Amazon Neptune sont conçus pour évoluer en trois dimensions : stockage, capacité d'écriture et capacité de lecture. Les sections ci-dessous présentent les options spécifiques à prendre en compte lors de la migration.
Allocation du stockage
Le stockage de tout cluster Neptune est automatiquement provisionné, sans aucune charge administrative de votre part. Il est redimensionné dynamiquement par tranches de 10 Go à mesure que les besoins de stockage du cluster augmentent. Par conséquent, vous n'avez pas besoin d'estimer le stockage pour faire face à la croissance future des données ni de le provisionner, voire d'en provisionner plus que nécessaire.
Provisionnement de la capacité d'écriture
Neptune fournit une instance d'enregistreur unique qui peut être mise à l'échelle verticalement pour atteindre n'importe quelle taille d'instance disponible sur la page de tarification de Neptune
Le choix d'une taille optimale pour une instance services d'enregistreur nécessite l'exécution de tests de charge permettant de déterminer la taille d'instance optimale pour votre charge de travail. Toute instance dans Neptune peut être redimensionnée à tout moment en modifiant la classe d'instances de base de données. Vous pouvez estimer la taille d'une instance de départ en fonction de la simultanéité et de la latence moyenne des requêtes, comme décrit ci-dessous dans Estimation de la taille d'instance optimale lors du provisionnement du cluster.
Provisionnement de la capacité de lecture
Neptune est conçu pour mettre à l'échelle les instances de réplica en lecture à la fois horizontalement, en en ajoutant jusqu'à 15 au sein d'un cluster (ou plus dans une base de données globale Neptune), et verticalement selon la taille d'instance disponible sur la page de tarification de Neptune
En plus de permettre la mise à l'échelle horizontale des demandes de lecture au sein d'un cluster Neptune, les réplicas en lecture servent également de cibles de basculement pour l'instance d'enregistreur afin de garantir une haute disponibilité. Consultez Directives opérationnelles de base Amazon Neptune pour obtenir des suggestions sur la manière de déterminer le nombre et le placement appropriés des réplicas en lecture dans votre cluster.
Pour les applications où la connectivité et la charge de travail sont imprévisibles, Neptune prend également en charge une fonctionnalité d'autoscaling qui permet d'ajuster automatiquement le nombre de réplicas Neptune en fonction de critères que vous spécifiez.
Pour déterminer une taille et un nombre optimaux d'instances de réplication en lecture, il est nécessaire d'exécuter des tests de charge afin de déterminer les caractéristiques de la charge de travail de lecture qu'elles doivent prendre en charge. Toute instance dans Neptune peut être redimensionnée à tout moment en modifiant la classe d'instances de base de données. Vous pouvez estimer la taille d'une instance de départ en fonction de la simultanéité et de la latence moyenne des requêtes, comme décrit dans la section suivante.
Utilisation de Neptune sans serveur pour mettre automatiquement à l'échelle les instances de lecteur et d'enregistreur selon les besoins
Bien qu'il soit souvent utile d'estimer la capacité de calcul requise par les charges de travail prévues, vous pouvez configurer la fonctionnalité Neptune sans serveur pour augmenter ou diminuer automatiquement la capacité de lecture et d'écriture. Cela peut vous aider à répondre aux besoins en cas de hausse soudaine tout en réduisant automatiquement la capacité lorsque la demande diminue.
Estimation de la taille d'instance optimale lors du provisionnement du cluster
L'estimation de la taille d'instance optimale nécessite de connaître la latence moyenne des requêtes dans Neptune, lorsque votre charge de travail est exécutée, ainsi que le nombre de requêtes traitées simultanément. Une estimation approximative de la taille de l'instance peut être calculée en multipliant la latence moyenne des requêtes par le nombre de requêtes simultanées. Cela vous donne le nombre moyen de threads simultanés nécessaires pour gérer la charge de travail.
Chaque vCPU d'une instance Neptune peut prendre en charge deux threads de requête simultanés. En divisant les threads par deux, on obtient donc le nombre de vCPU requis, qui peut ensuite être corrélé à la taille d'instance appropriée sur la page de tarification de Neptune
Average Query Latency: 30ms (0.03s) Number of concurrent queries: 1000/second Number of threads needed: 0.03 x 1000 = 30 threads Number of vCPUs needed: 30 / 2 = 15 vCPUs
En corrélant cela au nombre de vCPU d'une instance, nous constatons que nous obtenons une estimation approximative recommandant d'essayer r5.4xlarge pour cette charge de travail. Cette estimation est approximative et vise uniquement à fournir des indications initiales sur la sélection de la taille de l'instance. Toute application doit être soumise à un exercice de dimensionnement correct afin de déterminer le nombre et le ou les types d'instances appropriés pour la charge de travail.
Les besoins en mémoire doivent également être pris en compte, ainsi que les exigences de traitement. Neptune est particulièrement performant lorsque les données auxquelles les requêtes accèdent sont disponibles dans le cache du pool de mémoire tampon de la mémoire principale. Le provisionnement d'une mémoire suffisante peut également réduire les coûts d'E/S de manière significative.
Vous trouverez des informations et des conseils supplémentaires sur le dimensionnement des instances dans un cluster Neptune sur la page Dimensionnement des instances de base de données dans un cluster de bases de données Neptune.
