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.
Choix des types d'instances pour Amazon Neptune
Amazon Neptune propose différentes tailles et familles d'instances, qui offrent des fonctionnalités distinctes adaptées aux différentes charges de travail de graphe. Cette section a pour but de vous aider à choisir le type d'instance le plus adapté à vos besoins.
Pour connaître la tarification de chaque type d'instance dans ces familles, consultez la page de tarification de Neptune
Présentation de l'allocation des ressources d'instance
Chaque type et taille d' EC2 instance Amazon utilisés dans Neptune offrent une quantité définie de calcul (vCPUs) et de mémoire système. Le stockage principal de Neptune est externe aux instances de base de données d'un cluster, ce qui permet aux capacités de calcul et de stockage d'évoluer indépendamment l'une de l'autre.
Cette section se concentre sur la manière dont les ressources de calcul peuvent être mises à l'échelle et sur les différences entre les différentes familles d'instances.
Dans toutes les familles d'instances, des ressources vCPU sont allouées pour prendre en charge deux (2) threads d'exécution de requêtes par vCPU. Cette prise en charge est dictée par la taille de l'instance. Lorsque vous déterminez la taille appropriée d'une instance de base de données Neptune spécifique, vous devez tenir compte de la simultanéité possible de votre application et de la latence moyenne des requêtes. Vous pouvez estimer le nombre de v CPUs nécessaires comme suit, où la latence est mesurée comme la latence moyenne des requêtes en secondes et la simultanéité comme le nombre cible de requêtes par seconde :
vCPUs=(latencyxconcurrency)/2
Note
Les requêtes SPARQL, les requêtes openCypher et les requêtes de lecture Gremlin qui utilisent le moteur de requêtes DFE peuvent, dans certaines circonstances, utiliser plus d'un thread d'exécution par requête. Lors du dimensionnement initial du cluster de bases de données, partez du principe que chaque requête consomme un seul thread d'exécution par exécution, puis augmentez la taille si vous observez une pression de retour dans la file d'attente des requêtes. Cela peut être observé en utilisant le /gremlin/status/oc/status, ou /sparql/status APIs, ou il peut également être observé en utilisant la MainRequestsPendingRequestsQueue CloudWatch métrique.
La mémoire système de chaque instance est divisée en deux allocations principales : le cache du pool de tampons et la mémoire des threads d'exécution des requêtes.
Environ les deux tiers de la mémoire disponible dans une instance sont alloués au cache du pool de tampons. Le cache du pool de tampons sert à mettre en cache les derniers composants du graphe utilisés afin d'accélérer l'accès aux requêtes qui accèdent à plusieurs reprises à ces composants. Les instances dotées d'une plus grande quantité de mémoire système possèdent de plus vastes caches de pool de tampons qui peuvent stocker une plus grande partie du graphe localement. Un utilisateur peut régler la quantité appropriée de cache du pool de mémoire tampon en surveillant les mesures de réussite et d'échec du cache tampon disponibles dans. CloudWatch
Il peut être utile d'augmenter la taille de l'instance si le taux d'accès au cache tombe en dessous de 99,9 % pendant une période constante. Cela suggère que le pool de tampons n'est pas assez grand et que le moteur doit récupérer les données du volume de stockage sous-jacent plus souvent que nécessaire.
Le tiers restant de la mémoire système est réparti uniformément entre les threads d'exécution des requêtes, alors qu'une partie de la mémoire reste allouée au système d'exploitation et à un petit pool dynamique pour les threads à utiliser selon les besoins. La mémoire disponible pour chaque thread augmente légèrement d'une taille d'instance à l'autre jusqu'à un type d'instance 8xl, taille à laquelle la mémoire allouée par thread atteint un maximum.
Il convient d'ajouter de la mémoire de thread lorsque vous rencontrez une exception OutOfMemoryException (OOM). Les exceptions OOM se produisent lorsqu'un thread a besoin de plus de mémoire que la quantité maximale qui lui est allouée (ce qui diffère de la saturation de mémoire de l'instance entière).
Types d'instance t3 et t4g
La famille d'instances t3 et t4g offre une option économique pour commencer à utiliser une base de données orientée graphe, ainsi que pour le développement et les tests initiaux. Ces instances sont éligibles à l'offre gratuite
Les instances t3 et t4g ne sont proposées que dans les configurations de taille moyenne (t3.medium et t4g.medium).
Elles ne sont pas destinées à être utilisées dans un environnement de production.
Les ressources de ces instances étant très limitées, elles ne sont pas recommandées pour tester le temps d'exécution des requêtes ni les performances globales de la base de données. Pour évaluer les performances des requêtes, passez à une famille d'instances supérieure.
Famille r4 de types d'instances
OBSOLÈTE : la famille r4 a été proposée lors du lancement de Neptune en 2018, mais les nouveaux types d'instances offrent désormais un meilleur rapport prix/performances. Depuis la version 1.1.0.0 du moteur, Neptune ne prend plus en charge les types d'instances r4.
Famille r5 de types d'instances
La famille r5 contient des types d'instances à mémoire optimisée qui sont adaptées à la plupart des cas d'utilisation de graphes. La famille r5 contient les types d'instances allant de r5.large jusqu'à r5.24xlarge. Les performances de calcul évoluent de manière linéaire à mesure que vous augmentez la taille. Par exemple, un r5.xlarge (4 V CPUs et 32 Go de mémoire) possède deux fois plus de v CPUs et de mémoire qu'un r5.large (2 V CPUs et 16 Go de mémoire), et un r5.2xlarge (8 V et 64 Go de mémoire) possède deux fois plus de v CPUs et de mémoire qu'un. CPUs r5.xlarge Les performances des requêtes devraient évoluer directement en fonction de la capacité de calcul du type d'instance r5.12xlarge.
La famille d'instances r5 présente une architecture de processeur Intel à 2 sockets. Les instances r5.12xlarge et les types d'instances plus petits utilisent un seul socket et la mémoire système de ce processeur monosocket. Les types d'instances r5.16xlarge et r5.24xlarge utilisent à la fois les sockets et la mémoire disponible. Étant donné qu'une certaine surcharge de gestion de la mémoire est requise entre deux processeurs physiques dans une architecture à deux sockets, les gains de performances obtenus lors du passage d'une instance r5.12xlarge à un type d'instance r5.16xlarge ou r5.24xlarge plus grand ne sont pas aussi linéaires que ceux obtenus avec des tailles plus petites.
Famille r5d de types d'instances
Neptune possède une fonctionnalité de cache de recherche qui contribue à améliorer les performances des requêtes qui doivent récupérer et renvoyer un grand nombre de valeurs de propriétés et de littéraux. Cette fonctionnalité est principalement utilisée par les clients dont les requêtes doivent renvoyer de nombreux attributs. Le cache de recherche améliore les performances de ces requêtes en récupérant ces valeurs d'attribut localement plutôt que de les rechercher à plusieurs reprises dans le stockage indexé Neptune.
Le cache de recherche est implémenté à l'aide d'un volume EBS NVMe attaché à un type d'r5dinstance. Il est activé à l'aide du groupe de paramètres d'un cluster. Lorsque les données sont extraites du stockage indexé Neptune, les valeurs des propriétés et les littéraux RDF sont mis en cache dans ce volume. NVMe
Si vous n'avez pas besoin de la fonctionnalité de cache de recherche, utilisez un type d'instance r5 standard plutôt qu'une instance r5d, pour éviter le coût plus élevé de r5d.
La famille r5d possède des types d'instances de la même taille que la famille r5, allant de r5d.large à r5d.24xlarge.
Famille r6g de types d'instances
AWS a développé son propre processeur ARM appelé Gravitonr6g utilise le processeur Graviton2. Lors de nos tests, le processeur Graviton2 offre des performances supérieures de 10 à 20 % pour les requêtes orientées graphe (contraintes) de type OLTP. Les requêtes de type OLAP plus volumineuses peuvent toutefois être légèrement moins performantes avec les processeurs Graviton2 qu'avec les processeurs Intel en raison d'une pagination mémoire un peu moins performante.
Il est également important de noter que la famille r6g possède une architecture à socket unique. Dès lors, les performances évoluent de manière linéaire en fonction de la capacité de calcul en passant d'un type d'instance r6g.large à r6g.16xlarge (qui est le type d'instance le plus vaste dans cette famille).
Famille r6i de types d'instances
Les instances Amazon R6i
Famille x2g de types d'instances
Certains cas d'utilisation de graphes impliquent de meilleures performances lorsque les instances disposent de caches de pool de tampons plus grands. La famille x2g a été créée pour mieux prendre en charge ces cas d'utilisation. La x2g famille a un memory-to-vCPU ratio plus élevé que la r6g famille r5 ou la famille. Les instances x2g utilisent également le processeur Graviton2 et ont de nombreuses caractéristiques de performance identiques à celles des types d'instances r6g, ainsi qu'un cache de pool de tampons plus grand.
Si vous utilisez des types r5 d'r6ginstance présentant une faible utilisation du processeur et un taux d'échec élevé du cache du pool de mémoire tampon, essayez plutôt d'utiliser la x2g famille. Ainsi, vous obtiendrez la mémoire supplémentaire dont vous avez besoin sans avoir à payer pour augmenter la capacité du processeur.
Famille r8g de types d'instances
La r8g famille comprend des types d'instances optimisés pour la mémoire alimentés par des processeurs AWS Graviton4. Ces instances offrent des améliorations de performances significatives par rapport aux générations précédentes, ce qui les rend parfaitement adaptées aux charges de travail graphiques gourmandes en mémoire. Les instances r8g offrent des performances supérieures d'environ 15 à 20 % pour les requêtes graphiques par rapport aux instances r7g.
La r8g famille possède une architecture à socket unique, ce qui signifie que les performances évoluent de manière linéaire en fonction de la capacité de calcul comprise entre un r8g.large et un r8g.16xlarge (le type le plus important de la famille).
Les principales caractéristiques de la r8g famille sont les suivantes :
Alimenté par des processeurs basés AWS sur Graviton4 ARM
Bande passante mémoire supérieure par vCPU par rapport aux générations précédentes
Excellent price/performance ratio à la fois pour les requêtes graphiques de type OLTP (contraintes) et pour les charges de travail analytiques de type OLAP
Fonctionnalités de gestion de la mémoire améliorées qui favorisent les traversées de graphes complexes
La r8g gamme est idéale pour les charges de travail de production qui nécessitent une capacité de mémoire élevée et des performances constantes. Ils sont particulièrement efficaces pour les applications soumises à des exigences élevées en matière de simultanéité des requêtes.
Famille r7g de types d'instances
La r7g famille utilise le processeur AWS Graviton3, qui offre de meilleurs résultats price/performance que les instances précédentes basées sur Graviton2. Lors des tests, le processeur Graviton3 offre des performances supérieures de 25 à 30 % pour les requêtes graphiques de type OLTP par rapport aux instances r6g.
À l'instar de la r6g famille, la r7g famille possède une architecture à socket unique, ce qui signifie que les performances évoluent de manière linéaire en fonction de la capacité de calcul comprise entre un r7g.large et un r7g.16xlarge (le type le plus important de la famille).
Les principales caractéristiques de la r7g famille sont les suivantes :
Alimenté par des processeurs basés AWS sur Graviton3 ARM
Performances de pagination mémoire améliorées par rapport au r6g, ce qui profite à la fois aux charges de travail OLTP et OLAP
Efficacité améliorée du cache du pool de mémoire tampon
Latence réduite pour les opérations gourmandes en mémoire
La r7g gamme convient parfaitement aux environnements de production présentant des modèles de requêtes variés et est particulièrement efficace pour les charges de travail qui bénéficient d'une bande passante mémoire améliorée.
Famille r7i de types d'instances
La r7i famille est alimentée par des processeurs Intel Xeon Scalable de 4e génération (nom de code Sapphire Rapids) et offre des améliorations significatives par rapport aux instances r6i. Ces instances fournissent un calcul supérieur d'environ 15 % price/performance et une bande passante mémoire jusqu'à 20 % supérieure par vCPU par rapport aux types d'instances r6i comparables.
La famille d'r7iinstances possède une architecture de processeur Intel à 2 sockets, similaire à la r5 famille. Les instances r7i.12xlarge et les types d'instances plus petits utilisent un seul socket et la mémoire système de ce processeur monosocket. Les types d'instances r7i.16xlarge et r7i.24xlarge utilisent à la fois les sockets et la mémoire disponible. Étant donné qu'une certaine surcharge de gestion de la mémoire est requise entre deux processeurs physiques dans une architecture à deux sockets, les gains de performances obtenus lors du passage d'une instance r7i.12xlarge à un type d'instance r7i.16xlarge ou r7i.24xlarge plus grand ne sont pas aussi linéaires que ceux obtenus avec des tailles plus petites.
Les principales caractéristiques de la r7i famille sont les suivantes :
Alimenté par des processeurs Intel Xeon Scalable de 4e génération
Les performances évoluent de manière linéaire avec une capacité de calcul allant jusqu'à r7i.12xlarge
Gestion améliorée de la mémoire entre les processeurs physiques dans l'architecture à 2 sockets
Performances améliorées pour les opérations graphiques gourmandes en mémoire
Pour toutes ces familles d'instances, vous pouvez estimer le nombre de v CPUs nécessaires en utilisant la même formule que celle mentionnée précédemment :
vCPUs=(latencyxconcurrency)/2
Où la latence est mesurée comme la latence moyenne des requêtes en secondes et la simultanéité comme le nombre cible de requêtes par seconde.
Type d'instance serverless
La fonctionnalité Neptune sans serveur permet de mettre à l'échelle la taille de l'instance de manière dynamique en fonction des besoins en ressources d'une charge de travail. Au lieu de calculer le nombre de v CPUs nécessaires à votre application, Neptune Serverless vous permet de définir des limites inférieures et supérieures de capacité de calcul (mesurée en unités de capacité Neptune) pour les instances de votre cluster de bases de données. Les charges de travail dont l'utilisation varie peuvent être optimisées en termes de coûts en utilisant des instances sans serveur plutôt que des instances provisionnées.
Vous pouvez configurer à la fois des instances provisionnées et des instances sans serveur dans le même cluster de bases de données pour obtenir une configuration coût/performance optimale.
