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 du bon type d'instance de base de données 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'instance Amazon EC2 utilisés dans Neptune offrent une quantité définie de calcul (vCPU) 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 vCPU nécessaires comme suit, où la latence est mesurée comme étant la latence moyenne des requêtes en secondes et la simultanéité comme correspondant au nombre cible de requêtes par seconde :
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é à l'aide des /sparql/status API /gremlin/status/oc/status, ou peut également être observé à l'aide de 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, une instance r5.xlarge (4 vCPU et 32 Go de mémoire) possède deux fois plus de vCPU et de mémoire qu'une instance r5.large (2 vCPU et 16 Go de mémoire), et une instance r5.2xlarge (8 vCPU et 64 Go de mémoire) possède deux fois plus de vCPU et de mémoire qu'une instance 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 attaché à NVMe sur un type d'instance r5d. 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. Le ratio memory-to-v CPU de la x2g famille est supérieur à celui de la r6g famille r5 OR. 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 votre type d'instance r5 ou r6g utilise peu de CPU et que le taux d'échec du cache du pool de tampon est élevé, essayez plutôt d'utiliser la famille x2g. Vous bénéficierez ainsi de la mémoire supplémentaire dont vous avez besoin sans avoir à payer pour augmenter la capacité du CPU.
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 vCPU nécessaires à votre application, Neptune sans serveur vous permet de définir des limites inférieures et supérieures de capacité de calcul (mesurées 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.
