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](https://aws.amazon.com/neptune/pricing/).
## 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 (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 = (latency x concurrency) / 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](https://aws.amazon.com/neptune/free-trial/) de Neptune, qui permet aux nouveaux clients d'utiliser Neptune gratuitement pendant les 750 premières heures d'instance utilisées dans un AWS compte autonome ou regroupées auprès d'une AWS organisation avec facturation consolidée (compte payeur).
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](engine-releases-1.1.0.0.md) 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](feature-overview-lookup-cache.md) 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'`r5d`instance. 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é [Graviton](https://aws.amazon.com/ec2/graviton/), qui offre de meilleurs résultats price/performance que les équivalents Intel et AMD. La famille `r6g` 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](https://aws.amazon.com/ec2/instance-types/r6i/) sont alimentées par des processeurs Intel Xeon Scalable de 3e génération (nom de code Ice Lake) et conviennent parfaitement aux charges de travail gourmandes en mémoire. En règle générale, elles offrent des performances de calcul jusqu'à 15 % supérieures et une bande passante mémoire par vCPU jusqu'à 20 % supérieure à celle des types d'instances R5 comparables.
## 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'`r6g`instance 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 `x2iezn` de types d'instances
La `x2iezn` gamme fournit des instances optimisées pour la mémoire alimentées par des processeurs Intel Xeon Scalable dotés de performances à haute fréquence. Ces instances offrent un memory-to-vCPU ratio élevé (32 GiB par vCPU), ce qui les rend parfaitement adaptées aux charges de travail graphiques gourmandes en mémoire qui bénéficient de performances élevées en mode monothread.
Les principales caractéristiques incluent une fréquence turbo jusqu'à 4,5 GHz cœurs et la disponibilité dans des tailles allant de 2 x large à 12 x large.
## Famille `x2iedn` de types d'instances
La `x2iedn` gamme fournit des instances optimisées pour la mémoire avec un NVMe stockage SSD local. Ces instances associent une capacité de mémoire élevée (32 GiB par vCPU) à un stockage local rapide, ce qui les rend idéales pour les charges de travail graphiques qui bénéficient à la fois de grands caches en mémoire et d'une mise en cache de disque locale à hautes performances.
Alimentées par des processeurs Intel Xeon Scalable de 3e génération, ces instances sont disponibles dans des tailles allant de xlarge à 32xlarge et sont optimisées pour les bases de données graphiques à grande échelle nécessitant à la fois des performances de mémoire et de stockage.
## 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 utilise une plate-forme à double socket. Les types d'instance vont de `r8g.large` à `r8g.24xlarge` s'exécuter sur un seul socket, ce qui signifie que les performances évoluent de manière linéaire en fonction de la capacité de calcul sur cette plage. Elle `r8g.48xlarge` utilise les deux sockets et constitue le type d'instance le plus important de la famille ; comme les autres familles à double socket, les gains de performances lors du passage de `r8g.24xlarge` à `r8g.48xlarge` peuvent ne pas être parfaitement linéaires en raison de la surcharge de gestion de la mémoire entre sockets.
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'`r7i`instances 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 = (latency x concurrency) / 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](neptune-serverless.md) 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-serverless-capacity-scaling.md) 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.