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'EC2instance 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, les CPU ressources v sont allouées pour prendre en charge deux (2) threads d'exécution de requêtes par CPU v. Ce support est dicté 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 requêtes vCPUs 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
SPARQLles requêtes, openCypher les requêtes et les requêtes de lecture Gremlin qui utilisent le moteur de DFE requêtes 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/statusAPIs, 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.
Le moment d'ajouter de la mémoire de thread est lorsque vous rencontrez un OutOfMemoryException (OOM). OOMdes exceptions se produisent lorsqu'un thread a besoin de plus que la quantité maximale de mémoire qui lui est allouée (ce n'est pas la même chose que l'instance entière manque de mémoire).
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
DEPRECATED— La r4 gamme 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 vCPUs et 32 Go de mémoire) possède deux fois plus de mémoire vCPUs et qu'un r5.large (2 vCPUs et 16 Go de mémoire), et un r5.2xlarge (8 vCPUs et 64 Go de mémoire) possède deux fois la mémoire et d'un. vCPUs 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'r5instances possède une CPU architecture 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 EBS volume 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 RDF et les littéraux 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 ARM processeur 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 graphiques de OLTP type (contraintes). Les requêtes OLAP -ish plus volumineuses peuvent toutefois être légèrement moins performantes avec les processeurs Graviton2 qu'avec les processeurs Intel en raison des performances de pagination mémoire légèrement moins performantes.
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 peu CPU utilisés et présentant un taux d'échec élevé dans le cache du pool de mémoire tampon, essayez plutôt d'utiliser la x2g famille. Ainsi, vous disposerez de la mémoire supplémentaire dont vous avez besoin sans avoir à payer pour de la CPU capacité supplémentaire.
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 vCPUs nécessaire pour 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.
