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.
# Le cache de recherche Neptune peut accélérer les requêtes de lecture
Amazon Neptune implémente un cache de recherche qui utilise le SSD NVMe basé sur l'`R5d`instance afin d'améliorer les performances de lecture pour les requêtes impliquant des recherches fréquentes et répétitives de valeurs de propriétés ou de littéraux RDF. Le cache de recherche stocke temporairement ces valeurs dans le volume NVMe SSD où elles sont rapidement accessibles.
Les requêtes de lecture qui renvoient les propriétés d'un grand nombre de sommets et d'arêtes, ou de nombreux triplets RDF, peuvent avoir une latence élevée si les valeurs des propriétés ou les littéraux doivent être extraits des volumes de stockage du cluster plutôt que de la mémoire. Comme exemple, citons les requêtes de lecture de longue durée qui renvoient un grand nombre de noms complets à partir d'un graphe d'identité ou un grand nombre d'adresses IP à partir d'un graphe de détection de fraude. Plus le nombre de valeurs de propriétés ou de littéraux RDF renvoyés par la requête augmente, plus la mémoire disponible diminue, et l'exécution de la requête peut se dégrader de manière significative.
# Cas d'utilisation du cache de recherche Neptune
Le cache de recherche n'est utile que lorsque les requêtes de lecture renvoient les propriétés d'un très grand nombre de sommets et d'arêtes, ou de triplets RDF.
Pour optimiser les performances des requêtes, Amazon Neptune utilise le type d'instance `R5d` afin de créer un cache volumineux pour ces valeurs de propriété ou ces littéraux. Leur extraction depuis le cache est alors beaucoup plus rapide que leur extraction depuis des volumes de stockage en cluster.
En règle générale, il ne vaut la peine d'activer le cache de recherche que si les trois conditions suivantes sont remplies :
+ Vous avez observé une latence accrue des requêtes de lecture.
+ Vous observez également une baisse de la `BufferCacheHitRatio` [CloudWatch métrique](cw-metrics.md#cw-metrics-available) lors de l'exécution de requêtes de lecture (voir[Surveillance de Neptune à l'aide d'Amazon CloudWatch](cloudwatch.md)).
+ Vos requêtes de lecture passent beaucoup de temps à matérialiser les valeurs renvoyées avant d'afficher les résultats (voir l'exemple Gremlin Profile ci-dessous pour découvrir comment déterminer le nombre de valeurs de propriétés matérialisées pour une requête).
**Note**
Cette fonctionnalité *n'est utile que* dans le scénario spécifique décrit ci-dessus. Par exemple, le cache de recherche ne facilite pas du tout les requêtes d'agrégation. À moins que vous n'exécutiez des requêtes qui bénéficieraient du cache de recherche, il n'y a aucune raison d'utiliser un type d'instance `R5d` au lieu d'un type d'instance `R5` équivalent et moins coûteux.
Si vous utilisez Gremlin, vous pouvez évaluer les coûts de matérialisation d'une requête à l'aide de l'API [API Gremlin `profile`](gremlin-profile-api.md). La section « Opérations d'index » indique le nombre de termes matérialisés lors de l'exécution :
```
Index Operations
Query execution:
# of statement index ops: 3
# of unique statement index ops: 3
Duplication ratio: 1.0
# of terms materialized: 5273
Serialization:
# of statement index ops: 200
# of unique statement index ops: 140
Duplication ratio: 1.43
# of terms materialized: 32693
```
Le nombre de termes non numériques matérialisés est directement proportionnel au nombre de recherches de termes que Neptune doit effectuer.
# Utilisation du cache de recherche
Le cache de recherche n'est disponible que sur un type d'instance `R5d`, où il est automatiquement activé par défaut. Les `R5d` instances Neptune ont les mêmes spécifications que `R5` les instances, plus jusqu'à 1,8 To de stockage SSD NVMe local. Les caches de recherche sont spécifiques aux instances, et les charges de travail qui en bénéficient peuvent être dirigées spécifiquement vers les instances `R5d` d'un cluster Neptune, tandis que les autres charges de travail peuvent être dirigées vers des types d'instances `R5` ou autres.
Pour utiliser le cache de recherche sur une instance Neptune, il suffit de mettre à niveau cette dernière vers le type d'instance `R5d`. Lorsque vous le faites, Neptune définit automatiquement le paramètre du [neptune\$1lookup\$1cache](parameters.md#parameters-db-cluster-parameters-neptune_lookup_cache) cluster de base de données sur `1` (activé) et crée le cache de recherche sur cette instance particulière. Vous pouvez ensuite utiliser l'API [Statut d’une instance](access-graph-status.md)pour confirmer que le cache a été activé.
De même, pour désactiver le cache de recherche sur une instance donnée, mettez à l'échelle l'instance en la faisant passer d'un type d'instance `R5d` à un type d'instance `R5` équivalent.
Lorsqu'une instance `R5d` est lancée, le cache de recherche est activé et en mode démarrage à froid, ce qui signifie qu'il est vide. Neptune vérifie d'abord la présence dans le cache de recherche de valeurs de propriétés ou de littéraux RDF lors du traitement des requêtes, puis les ajoute s'ils ne s'y trouvent pas encore. Cela prépare progressivement le cache.
Lorsque vous dirigez les requêtes de lecture qui nécessitent des recherches de valeurs de propriété ou de littéraux RDF vers une instance de *lecteur* R5d, les performances de lecture se dégradent légèrement pendant la préparation de son cache. Cependant, lorsque le cache est réchauffé, les performances de lecture s'accélèrent de manière significative et vous pouvez également constater une baisse des I/O coûts liés aux recherches effectuées dans le cache plutôt qu'au stockage en cluster. L'utilisation de la mémoire s'améliore également.
Si votre instance d'*enregistreur* est une instance `R5d`, elle prépare automatiquement son cache de recherche à chaque opération d'écriture. Cette approche augmente légèrement la latence pour les requêtes d'écriture, mais prépare le cache de recherche de manière plus efficace. Ensuite, si vous dirigez les requêtes de lecture qui nécessitent des recherches de valeurs de propriété ou de littéraux RDF vers l'instance d'enregistreur, vous obtiendrez immédiatement des performances de lecture améliorées, car les valeurs y ont déjà été mises en cache.
En outre, si vous exécutez le chargeur en bloc sur une instance d'enregistreur `R5d`, vous remarquerez peut-être que ses performances sont légèrement dégradées à cause du cache.
Le cache de recherche étant spécifique à chaque nœud, le remplacement de l'hôte réinitialise le cache à froid.
Vous pouvez désactiver temporairement le cache de recherche sur toutes les instances de votre cluster de base de données en définissant le paramètre de [neptune\$1lookup\$1cache](parameters.md#parameters-db-cluster-parameters-neptune_lookup_cache) cluster de base de données sur `0` (désactivé). En général, il est toutefois plus judicieux de désactiver le cache sur des instances spécifiques en les faisant passer des types d'instance `R5d` à des types d'instance `R5` inférieurs.