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.
# Bonnes pratiques : optimisation de Neptune
Voici quelques recommandations d'ordre général pour utiliser Amazon Neptune. Utilisez ces informations comme référence pour trouver rapidement des recommandations sur l'utilisation d'Amazon Neptune et l'optimisation des performances.
**Contents**
+ [Directives opérationnelles de base Amazon Neptune](best-practices-general-basic.md)
+ [Bonnes pratiques de sécurité pour Amazon Neptune](best-practices-general-security.md)
+ [Éviter différentes classes d'instances dans un cluster](best-practices-general-basic.md#best-practices-loader-heterogeneous-instances)
+ [Éviter les redémarrages répétés pendant le chargement en bloc](best-practices-general-basic.md#best-practices-loader-repeated-restarts)
+ [Activation de l'index OSGP si le nombre de prédicats est élevé](best-practices-general-basic.md#best-practices-general-predicates)
+ [Éviter les transactions de longue durée dans la mesure du possible](best-practices-general-basic.md#best-practices-general-long-running-transactions)
+ [Bonnes pratiques pour l'utilisation des métriques Neptune](best-practices-general-metrics.md)
+ [Bonnes pratiques pour le réglage des requêtes Neptune](best-practices-general-basic.md#best-practices-general-tuning)
+ [Équilibrage de charge entre les réplicas en lecture](best-practices-general-basic.md#best-practices-general-loadbalance)
+ [Chargement plus rapide à l'aide d'une instance temporaire de plus grande taille](best-practices-general-basic.md#best-practices-loader-tempinstance)
+ [Redimensionnement de l'instance d'enregistreur en basculant vers un réplica en lecture](best-practices-general-basic.md#best-practices-resize-instance)
+ [Nouvelle tentative de chargement après une erreur d'interruption de tâche de lecture anticipée des données](best-practices-general-basic.md#load-api-reference-status-interrupted)
+ [Bonnes pratiques d'ordre général pour l'utilisation de Gremlin avec Neptune](best-practices-gremlin.md)
+ [Configuration Heartbeat pour Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
+ [Structurer les requêtes upsert pour tirer parti du moteur DFE](best-practices-gremlin.md#best-practices-gremlin-upserts)
+ [Testez le code Gremlin dans le contexte dans lequel vous allez le déployer](best-practices-gremlin-console-glv-differences.md)
+ [Création d'écritures Gremlin multithreads efficaces](best-practices-gremlin-multithreaded-writes.md)
+ [Élagage des enregistrements avec la propriété de date/heure de création](best-practices-gremlin-prune.md)
+ [Utilisation de la méthode `datetime( )` pour les données temporelles Groovy](best-practices-gremlin-datetime.md)
+ [Utilisation de la date et de l'heure natives pour les données temporelles GLV](best-practices-gremlin-datetime-glv.md)
+ [Bonnes pratiques pour l'utilisation du client Java Gremlin avec Neptune](best-practices-gremlin-java-client.md)
+ [Réutilisation de l'objet client dans plusieurs threads](best-practices-gremlin-java-reuse.md)
+ [Création d'objets client Java Gremlin distincts pour les points de terminaison en lecture et en écriture](best-practices-gremlin-java-separate.md)
+ [Ajout de plusieurs points de terminaison de réplica en lecture à un groupe de connexions Java Gremlin](best-practices-gremlin-java-multiple.md)
+ [Fermeture du client pour éviter de limiter les connexions](best-practices-gremlin-java-close-connections.md)
+ [Création d'une connexion après un basculement](best-practices-gremlin-java-new-connection.md)
+ [Définition de `maxInProcessPerConnection` et `maxSimultaneousUsagePerConnection` sur la même valeur](best-practices-gremlin-java-maxes.md)
+ [Envoi de requêtes au serveur sous la forme de bytecode et non de chaînes](best-practices-gremlin-java-bytecode.md)
+ [Consommez toujours complètement l'itérateur ResultSet ou l'itérateur renvoyé par une requête](best-practices-gremlin-java-resultset.md)
+ [Ajout en bloc de sommets et d'arêtes dans des lots](best-practices-gremlin-java-batch-add.md)
+ [Désactivation de la mise en cache du DNS dans la machine virtuelle Java](best-practices-gremlin-java-disable-dns-caching.md)
+ [Définition facultative de délais d'expiration au niveau de chaque requête](best-practices-gremlin-java-per-query-timeout.md)
+ [Résolution des problèmes de `java.util.concurrent.TimeoutException`](best-practices-gremlin-java-exceptions-TimeoutException.md)
+ [Bonnes pratiques Neptune avec openCypher et Bolt](best-practices-opencypher.md)
+ [Création d'une connexion après un basculement](best-practices-opencypher.md#best-practices-opencypher-renew-connection)
+ [Gestion des connexions pour les applications de longue durée](best-practices-opencypher.md#best-practices-opencypher-long-connections)
+ [Gestion des connexions pour AWS Lambda](best-practices-opencypher.md#best-practices-opencypher-lambda-connections)
+ [Préférer les arêtes dirigées aux arêtes bidirectionnelles dans les requêtes](best-practices-opencypher-directed-edges.md)
+ [Neptune ne prend pas en charge plusieurs requêtes simultanées dans une transaction](best-practices-opencypher-multiple-queries.md)
+ [Fermer les objets Driver lorsque vous avez terminé](best-practices-opencypher-close-driver.md)
+ [Utilisation des modes de transaction explicites pour la lecture et l'écriture](best-practices-opencypher-use-explicit-txs.md)
+ [Transactions en lecture seule](best-practices-opencypher-use-explicit-txs.md#best-practices-opencypher-read-txs)
+ [Transactions de mutation](best-practices-opencypher-use-explicit-txs.md#best-practices-opencypher-mutation-txs)
+ [Logique des nouvelles tentatives pour les exceptions](best-practices-opencypher-retry-logic.md)
+ [Définissez plusieurs propriétés à la fois à l'aide d'une seule clause SET](best-practices-content-0.md)
+ [Utilisez la clause SET pour supprimer plusieurs propriétés à la fois](best-practices-content-0.md#best-practices-content-1)
+ [Utilisation des requêtes paramétrées](best-practices-content-2.md)
+ [Utilisez des cartes aplaties au lieu de cartes imbriquées dans la clause UNWIND](best-practices-content-3.md)
+ [Placez des nœuds plus restrictifs sur le côté gauche dans les expressions VLP (Variable-Length Path)](best-practices-content-4.md)
+ [Évitez les vérifications redondantes des étiquettes des nœuds en utilisant des noms de relations granulaires](best-practices-content-5.md)
+ [Spécifiez les étiquettes de bord dans la mesure du possible](best-practices-content-6.md)
+ [Évitez d'utiliser la clause WITH dans la mesure du possible](best-practices-content-7.md)
+ [Placez les filtres restrictifs le plus tôt possible dans la requête](best-practices-content-8.md)
+ [Vérifiez explicitement si les propriétés existent](best-practices-content-9.md)
+ [N'utilisez pas de chemin nommé (sauf si cela est obligatoire)](best-practices-content-10.md)
+ [Évitez COLLECT (DISTINCT ())](best-practices-content-11.md)
+ [Préférez la fonction de propriétés à la recherche de propriétés individuelle lors de la récupération de toutes les valeurs de propriété](best-practices-content-12.md)
+ [Effectuer des calculs statiques en dehors de la requête](best-practices-content-13.md)
+ [Entrées par lots utilisant UNWIND au lieu d'instructions individuelles](best-practices-content-14.md)
+ [Préférez utiliser la personnalisation IDs pour le nœud ou la relation](best-practices-content-15.md)
+ [Évitez de faire des calculs \$1id dans la requête](best-practices-content-16.md)
+ [Mise à jour/fusion de plusieurs nœuds](best-practices-merge-multiple-nodes.md)
+ [Bonnes pratiques Neptune avec l'utilisation de SPARQL](best-practices-sparql.md)
+ [Interrogation de tous les graphes par défaut](best-practices-sparql-query.md)
+ [Spécification d'un graphe nommé pour le chargement](best-practices-sparql-graph.md)
+ [Choisir entre FILTER, FILTER...IN et VALUES dans vos requêtes](best-practices-sparql-batch.md)
# Directives opérationnelles de base Amazon Neptune
Vous trouverez ci-dessous les directives opérationnelles de base que vous devez suivre lorsque vous utilisez Neptune.
+ Familiarisez-vous avec les instances de base de données Neptune afin de pouvoir les dimensionner de manière appropriée en fonction de vos exigences en matière de performances et de cas d'utilisation. Consultez [Clusters de bases de données et instances de base de données Amazon Neptune](feature-overview-db-clusters.md).
+ Surveillez votre utilisation de CPU et de la mémoire. Ceci vous permet de savoir quand migrer vers une classe d'instances de base de données avec une plus grande capacité de CPU ou de la mémoire pour atteindre les performances des requêtes dont vous avez besoin. Vous pouvez configurer Amazon CloudWatch pour qu'il vous avertisse lorsque les habitudes d'utilisation changent ou lorsque vous approchez de la capacité de votre déploiement. Ceci peut vous aider à maintenir les performances et la disponibilité du système. Consultez [Surveillance des instances](feature-overview-db-clusters.md#feature-overview-monitoring-instances) et [Surveillance de Neptune](monitoring.md) pour en savoir plus.
Comme Neptune dispose de son propre gestionnaire de mémoire, il est normal d'observer une utilisation de mémoire relativement faible, et ce même en cas de forte utilisation de CPU. Le fait de rencontrer out-of-memory des exceptions lors de l'exécution de requêtes est le meilleur indicateur de la nécessité d'augmenter la mémoire disponible.
+ Activez les sauvegardes automatiques et définissez la fenêtre de sauvegarde pour qu'elles se produisent à un moment opportun.
+ Testez le basculement pour votre instance de base de données afin de connaître la durée du processus pour votre cas d'utilisation. Il permet également de veiller à ce que l'application qui accède à votre instance DB puisse automatiquement se connecter à la nouvelle instance DB suite au basculement.
+ Si possible, exécutez votre client et votre cluster Neptune dans la même région et le même VPC, car les connexions entre régions avec l'appairage de VPC peuvent entraîner des délais dans les temps de réponse des requêtes. Pour obtenir des réponses aux requêtes en moins de 10 millisecondes, il est nécessaire de conserver le client et le cluster Neptune dans la même région et le même VPC.
+ Lorsque vous créez une instance de réplica en lecture, elle doit être au moins aussi volumineuse que l'instance d'enregistreur principale. Cela permet de contrôler le retard de réplication et d'éviter les redémarrages du réplica. Consultez [Éviter différentes classes d'instances dans un cluster](#best-practices-loader-heterogeneous-instances).
+ Avant de procéder à une mise à niveau vers une nouvelle version majeure du moteur, assurez-vous de tester votre application sur cette dernière. Pour ce faire, clonez le cluster de bases de données afin qu'il exécute la nouvelle version du moteur, puis testez votre application sur ce clone.
+ Pour faciliter les basculements, toutes les instances devraient idéalement avoir la même taille.
**Topics**
+ [Bonnes pratiques de sécurité pour Amazon Neptune](best-practices-general-security.md)
+ [Éviter différentes classes d'instances dans un cluster](#best-practices-loader-heterogeneous-instances)
+ [Éviter les redémarrages répétés pendant le chargement en bloc](#best-practices-loader-repeated-restarts)
+ [Activation de l'index OSGP si le nombre de prédicats est élevé](#best-practices-general-predicates)
+ [Éviter les transactions de longue durée dans la mesure du possible](#best-practices-general-long-running-transactions)
+ [Bonnes pratiques pour l'utilisation des métriques Neptune](best-practices-general-metrics.md)
+ [Bonnes pratiques pour le réglage des requêtes Neptune](#best-practices-general-tuning)
+ [Équilibrage de charge entre les réplicas en lecture](#best-practices-general-loadbalance)
+ [Chargement plus rapide à l'aide d'une instance temporaire de plus grande taille](#best-practices-loader-tempinstance)
+ [Redimensionnement de l'instance d'enregistreur en basculant vers un réplica en lecture](#best-practices-resize-instance)
+ [Nouvelle tentative de chargement après une erreur d'interruption de tâche de lecture anticipée des données](#load-api-reference-status-interrupted)
# Bonnes pratiques de sécurité pour Amazon Neptune
Utilisez des comptes Gestion des identités et des accès AWS (IAM) pour contrôler l'accès aux actions de l'API Neptune. Contrôlez les actions qui créent, modifient ou suppriment les ressources Neptune (comme les instances de base de données, les groupes de sécurité, les groupes d'options ou les groupes de paramètres), et celles qui effectuent des tâches administratives courantes (comme la sauvegarde et la restauration d'instances de base de données).
+ Utilisez des informations d'identification temporaires plutôt que persistantes dans la mesure du possible.
+ Attribuez un compte IAM individuel à chaque personne qui gère les ressources Amazon Relational Database Service (Amazon RDS). N'utilisez jamais AWS d'utilisateurs root pour gérer les ressources Neptune. Créez un utilisateur IAM pour chaque personne, y compris vous-même.
+ Accordez à chaque utilisateur un ensemble minimum d'autorisations requises pour exécuter ses tâches.
+ Utilisez des groupes IAM pour gérer efficacement des autorisations pour plusieurs utilisateurs.
+ Effectuer une rotation régulière des informations d’identification IAM.
Pour plus d'informations sur l'utilisation d'IAM afin d'accéder aux ressources Neptune, consultez [Sécurisation de votre base de données Amazon Neptune](security.md). Pour obtenir des informations générales sur l'utilisation d'IAM, consultez [Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html) et [Bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html) dans le *Guide de l'utilisateur IAM*.
## Éviter différentes classes d'instances dans un cluster
Lorsque votre cluster de bases de données contient des instances de différentes classes, des problèmes peuvent survenir au fil du temps. Le problème le plus courant est qu'une petite instance de lecteur peut entrer dans un cycle de redémarrages répétés en raison d'un retard de réplication. Si la configuration de la classe d'instances de base de données d'un nœud de lecture est plus faible que celle d'une instance de base de données d'enregistreur, le volume de modifications peut être trop vaste pour que le lecteur puisse tout gérer.
**Important**
Pour éviter les redémarrages répétés provoqués par un retard de réplication, configurez le cluster de bases de données de manière à ce que toutes les instances aient la même classe (taille) d'instance.
Vous pouvez voir le décalage entre l'instance du rédacteur (l'instance principale) et les lecteurs de votre cluster de bases de données à l'aide de la `ClusterReplicaLag` métrique d'Amazon CloudWatch. La métrique `VolumeWriteIOPs` vous permet également de détecter les pics d'activité d'écriture du cluster susceptibles de provoquer un retard de réplication.
## Éviter les redémarrages répétés pendant le chargement en bloc
Si vous êtes confronté à un cycle de redémarrages répétés des réplicas en lecture en raison d'un retard de réplication lors d'un chargement en bloc, les réplicas ne parviendront probablement pas à suivre le rythme de l'enregistreur du cluster de bases de données.
Vous pouvez soit mettre à l'échelle les lecteurs pour qu'ils soient plus grands que l'enregistreur, soit les supprimer temporairement pendant le chargement en bloc, puis les recréer une fois le chargement terminé.
## Activation de l'index OSGP si le nombre de prédicats est élevé
Si le modèle de données contient un grand nombre de prédicats distincts (plus d'un millier dans la plupart des cas), vous pouvez subir une baisse des performances et une augmentation des coûts d'exploitation.
Si tel est le cas, vous pouvez activer l'[index OSGP](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp) pour améliorer les performances. Consultez [Index OSGP](features-lab-mode.md#features-lab-mode-features-osgp-index).
## Éviter les transactions de longue durée dans la mesure du possible
Les transactions de longue durée, qu'elles soient en lecture seule ou en lecture-écriture, peuvent causer des problèmes inattendus tels que les suivants :
Une transaction de longue durée sur une instance de lecteur ou d'enregistreur avec des écritures simultanées peut entraîner une accumulation importante de versions de données différentes. Les temps de latence peuvent être plus élevés pour les requêtes de lecture qui filtrent une grande partie de leurs résultats.
Dans certains cas, les versions accumulées au fil des heures peuvent entraîner la limitation des nouvelles écritures.
Une transaction de lecture-écriture de longue durée impliquant de nombreuses écritures peut également causer des problèmes si l'instance redémarre. Si une instance redémarre à la suite d'un événement de maintenance ou d'un blocage, toutes les écritures non validées seront annulées. Ces opérations d'annulation s'exécutent généralement en arrière-plan et n'empêchent pas l'instance de se rétablir, mais toute nouvelle écriture entrant en conflit avec les opérations en cours d'annulation échouera.
Par exemple, si la même requête fait l'objet d'une nouvelle tentative après une interruption de la connexion lors de l'exécution précédente, elle pourra échouer au redémarrage de l'instance.
Le temps nécessaire aux opérations d'annulation est proportionnel à l'ampleur des modifications impliquées.
# Bonnes pratiques pour l'utilisation des métriques Neptune
Pour identifier les problèmes de performances causés par des ressources insuffisantes et d'autres goulots d'étranglement courants, vous pouvez surveiller les métriques disponibles pour votre cluster de bases de données Neptune.
Surveillez régulièrement les métriques de performances pour rassembler les données sur les valeurs moyennes, maximales et minimales pour différents intervalles de temps. Cela vous aide à déterminer quand les performances se dégradent. À l'aide de ces données, vous pouvez définir des CloudWatch alarmes Amazon pour des seuils métriques spécifiques afin d'être alerté s'ils sont atteints.
Lorsque vous configurez un nouveau cluster de base de données et l'exécutez avec une charge de travail classique, essayez de capturer les valeurs moyennes, maximales et minimales de toutes les métriques de performances à plusieurs intervalles différents (par exemple, une heure, 24 heures, une semaine, deux semaines). Cela vous permet de vous faire une idée de ce qui est normal. Cela permet de comparer l'activité pendant les heures pleines et les heures creuses. Vous pouvez alors utiliser ces informations pour identifier les périodes où les performances ont chuté en dessous des niveaux standard et définir des alarmes en conséquence.
Consultez [Surveillance de Neptune à l'aide d'Amazon CloudWatch](cloudwatch.md) pour découvrir comment afficher les métriques Neptune.
Voici les métriques les plus importantes pour démarrer :
+ **BufferCacheHitRatio**— Le pourcentage de demandes traitées par le cache tampon. Les échecs d'accès au cache ajoutent une latence importante à l'exécution des requêtes. Si le taux d'accès au cache est inférieur à 99,9 % et que la latence constitue un problème pour votre application, envisagez de mettre à niveau le type d'instance afin de mettre en cache davantage de données en mémoire.
+ **Utilisation de CPU** : pourcentage de la capacité de traitement informatique utilisée. Selon vos objectifs en matière de performance des requêtes, des valeurs de consommation de CPU élevées peuvent être appropriées.
+ **Mémoire libérable** : quantité de RAM disponible sur l'instance de base de données, en octets. Neptune possède son propre gestionnaire de mémoire. Cette métrique peut donc être inférieure à ce à quoi vous vous attendiez. Si les requêtes génèrent souvent des out-of-memory exceptions, vous devriez envisager de mettre à niveau votre classe d'instance vers une classe dotée de plus de RAM.
La ligne rouge sous l'onglet **Surveillance** indique 75 % pour les métriques de CPU et de mémoire. Si la consommation de mémoire de l'instance franchit régulièrement cette ligne, vérifiez votre charge de travail et envisagez de mettre à niveau votre instance pour améliorer les performances des requêtes.
## Bonnes pratiques pour le réglage des requêtes Neptune
L'un des meilleurs moyens d'améliorer les performances de Neptune consiste à ajuster les requêtes les plus communément utilisées et exigeantes en ressources pour les rendre moins onéreuses à exécuter.
Pour en savoir plus sur le réglage des requêtes Gremlin, consultez [Indicateurs de requête Gremlin](gremlin-query-hints.md) et [Réglage des requêtes Gremlin](gremlin-traversal-tuning.md). Pour plus d'informations sur la façon d'ajuster les requêtes SPARQL, consultez [Indicateurs de requête SPARQL](sparql-query-hints.md).
## Équilibrage de charge entre les réplicas en lecture
Le routage en tourniquet du point de terminaison de lecteur modifie l'hôte vers lequel l'entrée DNS pointe. Le client doit créer une nouvelle connexion et résoudre l'enregistrement DNS pour obtenir une connexion à une nouvelle réplique en lecture, car WebSocket les connexions sont souvent maintenues actives pendant de longues périodes.
Pour obtenir différents réplicas en lecture pour les requêtes successives, assurez-vous que votre client résout l'entrée DNS chaque fois qu'il se connecte. Cela peut demander la fermeture de la connexion et la reconnexion au point de terminaison du lecteur.
Vous pouvez également équilibrer la charge des requêtes entre des réplicas en lecture en vous connectant à des points de terminaison d'instance de manière explicite.
## Chargement plus rapide à l'aide d'une instance temporaire de plus grande taille
Vos performances de chargement augmentent avec des tailles d'instance plus grandes. Si vous n'utilisez pas un grand type d'instance, mais que vous souhaitez accélérer le chargement, vous pouvez utiliser une instance plus grande pour le chargement, puis la supprimer.
**Note**
La procédure suivante est pour un nouveau cluster. Si vous disposez déjà d'un cluster existant, vous pouvez ajouter une nouvelle instance plus grande, puis la promouvoir en instance de base de données principale.
**Pour charger des données à l'aide d'une taille d'instance plus grande**
1. Créez un cluster avec une seule instance `r5.12xlarge`. Cette instance est l'instance de base de données principale.
1. Créez un ou plusieurs réplicas en lecture de même taille (`r5.12xlarge`).
Vous pouvez créer des réplicas en lecture de plus petite taille, mais s'ils ne sont pas assez grands pour suivre le rythme des écritures effectuées par l'instance principale, ils nécessiteront peut-être des redémarrages fréquents. Les temps d'arrêt qui en résulteront réduiront considérablement les performances.
1. Dans la commande de chargement en bloc, incluez `“parallelism” : “OVERSUBSCRIBE”` pour indiquer à Neptune d'utiliser toutes les ressources de CPU disponibles pour le chargement (voir [Paramètres de demande du chargeur Neptune](load-api-reference-load.md#load-api-reference-load-parameters)). L'opération de chargement se déroulera alors aussi rapidement que possible, I/O ce qui nécessite généralement 60 à 70 % des ressources du processeur.
1. Chargez vos données à l'aide du chargeur Neptune. La tâche de chargement s'exécute sur l'instance de base de données principale.
1. Une fois le chargement des données terminé, veillez à réduire toutes les instances du cluster au même type d'instance afin d'éviter des frais supplémentaires et des problèmes de redémarrage répétés (voir [Éviter différentes tailles d'instance](#best-practices-loader-heterogeneous-instances)).
## Redimensionnement de l'instance d'enregistreur en basculant vers un réplica en lecture
La meilleure façon de redimensionner une instance de votre cluster de bases de données, y compris l'instance d'enregistreur, consiste à créer ou à modifier une instance de réplica en lecture afin qu'elle ait la taille souhaitée, puis de basculer délibérément vers ce réplica. Le temps d'arrêt observé par votre application correspond uniquement au temps nécessaire pour modifier l'adresse IP de l'enregistreur. Il devrait être d'environ trois à cinq secondes.
L'API de gestion Neptune que vous utilisez pour basculer délibérément de l'instance d'enregistreur actuelle vers une instance de réplica en lecture est [Basculement DBCluster](api-clusters.md#FailoverDBCluster). Si vous utilisez le client Java Gremlin, vous devrez peut-être créer un objet client après le basculement pour relever la nouvelle adresse IP, comme indiqué [ici](best-practices-gremlin-java-new-connection.md).
Assurez-vous d'ajuster vos instances pour qu'elles aient toutes la même taille afin d'éviter un cycle de redémarrages répétés, comme indiqué ci-dessous.
## Nouvelle tentative de chargement après une erreur d'interruption de tâche de lecture anticipée des données
Lorsque vous chargez des données dans Neptune à l'aide du chargeur en bloc, vous pouvez parfois obtenir le statut `LOAD_FAILED` avec une erreur `PARSING_ERROR`, tandis que le message `Data prefetch task interrupted` peut être indiqué en réponse à une demande d'informations détaillées, comme suit :
```
"errorLogs" : [
{
"errorCode" : "PARSING_ERROR",
"errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
"fileName" : "s3://amzn-s3-demo-bucket/some-source-file",
"recordNum" : 0
}
]
```
Si vous rencontrez cette erreur, essayez simplement de relancer la demande de téléchargement par lot.
L'erreur se produit en raison d'une interruption temporaire qui n'est généralement pas provoquée par votre demande ni vos données, et elle peut généralement être résolue en réexécutant la demande de chargement par lot.
Si vous utilisez les paramètres par défaut, à savoir `"mode":"AUTO"` et `"failOnError":"TRUE"`, le chargeur ignore les fichiers qu'il a déjà chargés avec succès et reprend le chargement des fichiers qu'il n'avait pas encore chargés lorsque l'interruption s'est produite.
# Bonnes pratiques d'ordre général pour l'utilisation de Gremlin avec Neptune
Suivez ces recommandations lorsque vous utilisez le langage de parcours de graphe Gremlin avec Neptune. Pour plus d'informations sur l'utilisation de Gremlin avec Neptune, consultez [Accès au graphe Neptune avec Gremlin](access-graph-gremlin.md).
**Important**
Une modification a été apportée à TinkerPop la version 3.4.11 qui améliore l'exactitude du traitement des requêtes, mais qui, pour le moment, peut parfois avoir un impact sérieux sur les performances des requêtes.
Par exemple, une requête de ce type peut être beaucoup plus lente :
```
g.V().hasLabel('airport').
order().
by(out().count(),desc).
limit(10).
out()
```
Les sommets après l'étape de limite sont désormais récupérés de manière non optimale en raison de la TinkerPop modification 3.4.11. Pour éviter cela, vous pouvez modifier la requête en ajoutant l'étape barrier() à tout moment après `order().by()`. Par exemple :
```
g.V().hasLabel('airport').
order().
by(out().count(),desc).
limit(10).
barrier().
out()
```
TinkerPop [La version 3.4.11 a été activée dans la version 1.0.5.0 du moteur Neptune.](engine-releases-1.0.5.0.md)
**Topics**
+ [Configuration Heartbeat pour Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
+ [Structurer les requêtes upsert pour tirer parti du moteur DFE](#best-practices-gremlin-upserts)
+ [Testez le code Gremlin dans le contexte dans lequel vous allez le déployer](best-practices-gremlin-console-glv-differences.md)
+ [Création d'écritures Gremlin multithreads efficaces](best-practices-gremlin-multithreaded-writes.md)
+ [Élagage des enregistrements avec la propriété de date/heure de création](best-practices-gremlin-prune.md)
+ [Utilisation de la méthode `datetime( )` pour les données temporelles Groovy](best-practices-gremlin-datetime.md)
+ [Utilisation de la date et de l'heure natives pour les données temporelles GLV](best-practices-gremlin-datetime-glv.md)
# Configuration Heartbeat pour Neptune Serverless
Lorsque vous utilisez des WebSocket clients G705 avec Neptune Serverless, vous devez configurer l'intervalle de ping du client de manière appropriée afin de maintenir des connexions stables pendant les événements de dimensionnement. Le client G705 utilise des WebSocket connexions et envoie des pings périodiques pour vérifier que la connexion est active. Le client attend une réponse du serveur dans le délai imparti pour le ping. Si le serveur ne répond pas, le client ferme automatiquement la connexion.
**Pour les instances **provisionnées par** Neptune, nous recommandons de définir l'intervalle ping sur 5 secondes.** Pour les **clusters Neptune Serverless**, nous recommandons de définir l'intervalle ping sur au moins **20 secondes** afin de tenir compte des retards potentiels lors des opérations de dimensionnement. Ce paramètre contrôle la durée pendant laquelle le client attend entre deux écritures sur le serveur avant d'envoyer un ping pour vérifier que la connexion est toujours active.
La configuration de ce paramètre varie en fonction de l'implémentation du client :
**Configuration du client Java**
Pour le client Java TinkerPop G705, configurez le `keepAliveInterval` paramètre :
```
Cluster.Builder builder = Cluster.build()
.addContactPoint(endpoint)
.keepAliveInterval(20000); // Configure ping interval in milliseconds
```
Pour plus de détails sur la configuration du pilote Java, consultez la [ TinkerPop documentation Java](https://tinkerpop.apache.org/docs/current/reference/#gremlin-java-configuration).
**Configuration du client Go**
Pour le client G705 Go, configurez le `KeepAliveInterval` paramètre :
```
rc, err := driver.NewDriverRemoteConnection(endpoint,
func(settings *driver.DriverRemoteConnectionSettings) {
settings.TraversalSource = "g"
settings.AuthInfo = auth
settings.KeepAliveInterval = 20 * time.Second // Configure ping interval
...
})
```
Pour plus de détails sur la configuration du pilote Go, consultez la [ TinkerPop documentation Go](https://tinkerpop.apache.org/docs/current/reference/#gremlin-go-configuration).
**JavaScriptConfiguration du client /Node.js**
Pour le client JavaScript /Node.js G705, configurez le `pingInterval` paramètre :
```
const gremlin = require('gremlin');
const DriverRemoteConnection = gremlin.driver.DriverRemoteConnection;
const connection = new DriverRemoteConnection(endpoint, {
traversalSource: 'g',
pingInterval: 20000 // Configure ping interval in milliseconds
});
```
Pour plus de détails sur la configuration du JavaScript pilote, reportez-vous à la [JavaScript TinkerPop documentation](https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript-configuration).
**Configuration du client Python**
Pour le client Python Gremlin, l'intervalle ping est généralement géré au niveau de la couche de transport. Consultez la documentation spécifique de mise en œuvre du transport pour connaître les options de configuration :
```
from gremlin_python.driver.driver_remote_connection import DriverRemoteConnection
g = traversal().with_remote(
DriverRemoteConnection('wss://your-neptune-endpoint:your-neptune-port/gremlin','g',
transport_factory=lambda: AiohttpTransport(read_timeout=60,
write_timeout=20,
heartbeat=20, // Configure heartbeat
call_from_event_loop=True,
max_content_length=100*1024*1024,
ssl_options=ssl.create_default_context(Purpose.CLIENT_AUTH))))
```
Pour plus de détails sur la configuration du pilote Python, consultez la [ TinkerPop documentation Python](https://tinkerpop.apache.org/docs/current/reference/#gremlin-python-configuration).
Cette configuration garantit à votre client la stabilité de la connexion lors des événements de dimensionnement Neptune Serverless, en évitant les fermetures de connexion inutiles et en améliorant la fiabilité des applications.
## Structurer les requêtes upsert pour tirer parti du moteur DFE
[Réalisation d'upserts efficaces avec les étapes Gremlin `mergeV()` et `mergeE()`](gremlin-efficient-upserts.md) explique comment structurer les requêtes upsert pour utiliser le moteur DFE le plus efficacement possible.
# Testez le code Gremlin dans le contexte dans lequel vous allez le déployer
Dans G705, les clients peuvent envoyer des requêtes au serveur de plusieurs manières : en utilisant ou en utilisant le Bytecode GLV WebSocket, ou via la console G705 à l'aide de scripts basés sur des chaînes.
Il est important de savoir que l'exécution d'une requête Gremlin peut varier en fonction de la manière dont vous la soumettez. Une requête qui renvoie un résultat vide peut être considérée comme ayant abouti si elle est soumise en mode Bytecode, mais comme ayant échoué si elle est soumise en mode script. Par exemple, si vous incluez une requête `next()` en mode script, elle `next()` est envoyée au serveur, mais l'utilisation du client ByteCode la `next()` traite généralement elle-même. Dans le premier cas, la requête échoue si aucun résultat n'est trouvé, mais dans le second, elle aboutit, que le jeu de résultats soit vide ou non.
Si vous développez et testez le code dans un seul contexte (par exemple, la console Gremlin qui envoie généralement des requêtes sous forme de texte), mais que vous déployez ensuite le code dans un autre contexte (par exemple via le pilote Java utilisant Bytecode), vous pouvez rencontrer des problèmes liés au fait que le code se comporte différemment en production que dans l'environnement de développement.
**Important**
Assurez-vous de tester le code Gremlin dans le contexte GLV dans lequel il sera déployé, afin d'éviter des résultats inattendus.
# Création d'écritures Gremlin multithreads efficaces
Quelques recommandations sont à observer pour le chargement multithread de données dans Neptune avec Gremlin.
Dans la mesure du possible, attribuez à chaque thread un ensemble de sommets ou d'arcs à insérer ou modifier qui ne se chevauchent pas. Par exemple, le thread 1 concerne la plage d'ID allant de 1 à 50 000, le thread 2 concerne la plage d'ID allant de 50 001 à 100 000, et ainsi de suite. Cela réduit le risque de générer une exception `ConcurrentModificationException`. Par mesure de sécurité, placez un bloc `try/catch` autour de toutes les écritures. En cas d'échec, vous pouvez effectuer une nouvelle tentative après un court délai.
Le traitement par lots de 50 à 100 écritures (sommets ou arcs) donne généralement de bons résultats. Si, pour chaque sommet, un grand nombre de propriétés sont ajoutées, il est préférable de tendre vers 50 plutôt que 100. Il est utile de réaliser des expérimentations. Ainsi, pour les écritures traitées par lots, vous pouvez utiliser un code similaire à ce qui suit :
```
g.addV(‘test’).property(id,’1’).as(‘a’).
addV(‘test’).property(id,’2’).
addE(‘friend’).to(‘a’).
```
Il est ensuite repris dans chaque opération de traitement par lots.
Il est nettement plus efficace d'utiliser des lots que d'ajouter un sommet ou un arc au serveur pour chaque boucle Gremlin.
Si vous utilisez un client GLV (Gremlin Language Variant), vous pouvez créer un lot par programmation en commençant par la création d'un parcours. Ensuite, effectuez des ajouts et, enfin, des itérations, par exemple :
```
t.addV(‘test’).property(id,’1’).as(‘a’)
t.addV(‘test’).property(id,’2’)
t.addE(‘friend’).to(‘a’)
t.iterate()
```
Il est préférable d'utiliser le client GLV (Gremlin Language Variant) si possible. Mais vous pouvez faire quelque chose de similaire avec un client qui soumet des requêtes sous forme de chaînes de texte qui sont concaténées pour former un lot.
Si vous utilisez l'une des bibliothèques de client Gremlin plutôt que le protocole HTTP de base pour les requêtes, les threads doivent tous partager le même client, cluster ou groupe de connexion. Vous pouvez être amené à ajuster les paramètres pour bénéficier d'un débit optimal, des paramètres tels que la taille du groupe de connexion et le nombre de threads de travail qu'utilise le client Gremlin.
# Élagage des enregistrements avec la propriété de date/heure de création
Vous pouvez élaguer les enregistrements obsolètes en stockant la date/heure de création en tant que propriété sur les sommets et en les supprimant périodiquement.
Si vous devez stocker des données pour une durée de vie spécifique, puis les supprimer du graphe (durée de vie du sommet), vous pouvez stocker une propriété d'horodatage lors de la création du sommet. Vous pouvez ensuite exécuter périodiquement une requête `drop()` pour tous les sommets qui ont été créés avant une certaine date/heure, par exemple :
```
g.V().has(“timestamp”, lt(datetime('2018-10-11')))
```
# Utilisation de la méthode `datetime( )` pour les données temporelles Groovy
Neptune fournit la méthode `datetime` afin de spécifier des dates et heures pour les requêtes envoyées dans la variante Gremlin **Groovy**. Cela inclut la console Gremlin, les chaînes de texte utilisant l'API REST HTTP, et toute autre sérialisation qui utilise Groovy.
**Important**
Ceci s'applique *uniquement* aux méthodes dans lesquelles vous envoyez la requête Gremlin en tant que *chaîne de texte*. Si vous utilisez une variante du langage Gremlin (Gremlin Language Variant), vous devez utiliser les classes et fonctions de dates natives pour le langage. Pour plus d’informations, consultez la section suivante, [Utilisation de la date et de l'heure natives pour les données temporelles GLV](best-practices-gremlin-datetime-glv.md).
Commencer par TinkerPop `3.5.2` (introduit dans la [version 1.1.1.0 du moteur Neptune](engine-releases-1.1.1.0.md)) fait partie intégrante de. `datetime` TinkerPop
Vous pouvez utiliser la méthode `datetime` pour stocker et comparer des dates :
```
g.V('3').property('date',datetime('2001-02-08'))
```
```
g.V().has('date',gt(datetime('2000-01-01')))
```
# Utilisation de la date et de l'heure natives pour les données temporelles GLV
Si vous utilisez une variante du langage Gremlin (GLV), vous devez utiliser les classes et fonctions de date et d'heure natives fournies par le langage de programmation pour les données temporelles Gremlin.
Les TinkerPop bibliothèques officielles sont toutes des bibliothèques de variantes de langage G705.
+ [Go](https://tinkerpop.apache.org/docs/current/reference/#gremlin-go)
+ [Java](https://tinkerpop.apache.org/docs/current/reference/#gremlin-java)
+ [JavaScript](https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript)
+ [.NET](https://tinkerpop.apache.org/docs/current/reference/#gremlin-dotnet)
+ [Python](https://tinkerpop.apache.org/docs/current/reference/#gremlin-python)
**Important**
Cette page s'applique uniquement aux bibliothèques GLV (G705 Language Variant). Si vous utilisez une méthode dans laquelle vous envoyez la requête Gremlin sous forme de chaîne de texte, vous devez utiliser la fonction datetime () de G705. Cela inclut la console G705, les chaînes de texte utilisant l'API HTTP REST ou la soumission directe de chaînes G705 via les pilotes.
**Go**
Voici un exemple partiel dans Go qui crée une propriété unique nommée « date » pour le sommet avec un ID de « 3 ». Il définit la valeur comme étant une date générée à l'aide de la fonction Go Time.now ().
```
import ( "time" )
g.V('3').property('date', time.Now()).next();
```
Pour un exemple complet de connexion à Neptune à l'aide de Go, voir [Utilisation d'un client Go pour se connecter à une instance de base de données Neptune](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-gremlin-go.html).
**Java**
Voici un exemple partiel en Java qui crée une propriété unique nommée « `date` » pour le sommet avec l'ID « `3` ». Cet exemple définit la valeur sur une date générée à l'aide du constructeur `Date()` Java.
```
import java.util.date
g.V('3').property('date', new Date()).next();
```
Pour un exemple complet de connexion à Neptune à l'aide de Java, consultez. [Utilisation du client Java pour se connecter à une instance de base de données Neptune](access-graph-gremlin-java.md)
**Node.js (JavaScript)**
Voici un exemple partiel de création JavaScript d'une propriété unique nommée « `date` » pour le sommet avec un ID de « `3` ». Cet exemple définit la valeur sur une date générée à l'aide du constructeur `Date()` Node.js.
```
g.V('3').property('date', new Date()).next()
```
Pour un exemple complet de connexion à Neptune à l'aide de Node.js, consultez. [Utilisation de Node.js pour se connecter à une instance de base de données Neptune](access-graph-gremlin-node-js.md)
**.NET (C\$1)**
Voici un exemple partiel en C\$1 qui crée une propriété unique nommée « `date` » pour le sommet avec l'ID « `3` ». Cet exemple définit la valeur sur une date générée à l'aide de la propriété .NET `DateTime.UtcNow`.
```
Using System;
g.V('3').property('date', DateTime.UtcNow).next()
```
Pour un exemple complet de connexion à Neptune à l'aide de C\$1, consultez. [Utilisation de .NET pour se connecter à une instance de base de données Neptune](access-graph-gremlin-dotnet.md)
**Python**
Voici un exemple partiel en Python qui crée une propriété unique nommée « `date` » pour le sommet avec l'ID « `3` ». Cet exemple définit la valeur sur une date générée à l'aide de la méthode `datetime.now()` Python.
```
import datetime
g.V('3').property('date',datetime.datetime.now()).next()
```
Pour un exemple complet de connexion à Neptune à l'aide de Python, consultez. [Utilisation de Python pour se connecter à une instance de base de données Neptune](access-graph-gremlin-python.md)
# Bonnes pratiques pour l'utilisation du client Java Gremlin avec Neptune
Suivez ces recommandations lors de l'utilisation du client Java Gremlin avec Neptune. Ces bonnes pratiques vous aident à optimiser les performances, à gérer efficacement les connexions et à éviter les pièges courants lorsque vous utilisez le pilote Java.
Pour plus d'informations sur la configuration des intervalles de pulsation pour Neptune Serverless, consultez. [Configuration Heartbeat pour Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
**Topics**
+ [Réutilisation de l'objet client dans plusieurs threads](best-practices-gremlin-java-reuse.md)
+ [Création d'objets client Java Gremlin distincts pour les points de terminaison en lecture et en écriture](best-practices-gremlin-java-separate.md)
+ [Ajout de plusieurs points de terminaison de réplica en lecture à un groupe de connexions Java Gremlin](best-practices-gremlin-java-multiple.md)
+ [Fermeture du client pour éviter de limiter les connexions](best-practices-gremlin-java-close-connections.md)
+ [Création d'une connexion après un basculement](best-practices-gremlin-java-new-connection.md)
+ [Définition de `maxInProcessPerConnection` et `maxSimultaneousUsagePerConnection` sur la même valeur](best-practices-gremlin-java-maxes.md)
+ [Envoi de requêtes au serveur sous la forme de bytecode et non de chaînes](best-practices-gremlin-java-bytecode.md)
+ [Consommez toujours complètement l'itérateur ResultSet ou l'itérateur renvoyé par une requête](best-practices-gremlin-java-resultset.md)
+ [Ajout en bloc de sommets et d'arêtes dans des lots](best-practices-gremlin-java-batch-add.md)
+ [Désactivation de la mise en cache du DNS dans la machine virtuelle Java](best-practices-gremlin-java-disable-dns-caching.md)
+ [Définition facultative de délais d'expiration au niveau de chaque requête](best-practices-gremlin-java-per-query-timeout.md)
+ [Résolution des problèmes de `java.util.concurrent.TimeoutException`](best-practices-gremlin-java-exceptions-TimeoutException.md)
# Réutilisation de l'objet client dans plusieurs threads
Réutilisez le même objet client (ou `GraphTraversalSource`) dans plusieurs threads. Autrement dit, créez une instance partagée d'une `org.apache.tinkerpop.gremlin.driver.Client` classe dans votre application plutôt que de le faire dans chaque thread. L'objet `Client` est thread-safe, et la surcharge entraînée par l'initialisation est considérable.
Cela s'applique également à `GraphTraversalSource`, qui crée un objet `Client` en interne. Par exemple, le code suivant entraîne l'instanciation d'un nouvel objet `Client` :
```
import static org.apache.tinkerpop.gremlin.process.traversal.AnonymousTraversalSource.traversal;
/////
GraphTraversalSource traversal = traversal()
.withRemote(DriverRemoteConnection.using(cluster));
```
# Création d'objets client Java Gremlin distincts pour les points de terminaison en lecture et en écriture
Vous pouvez augmenter les performances en effectuant uniquement les écritures sur le point de terminaison enregistreur et la lecture à partir d'un ou plusieurs points de terminaison en lecture seule.
```
Client readerClient = Cluster.build("https://reader-endpoint")
...
.connect()
Client writerClient = Cluster.build("https://writer-endpoint")
...
.connect()
```
# Ajout de plusieurs points de terminaison de réplica en lecture à un groupe de connexions Java Gremlin
Lorsque vous créez un objet `Cluster` Java Gremlin, vous pouvez utiliser la méthode `.addContactPoint()` pour ajouter plusieurs instances de réplicas en lecture aux points de contact du groupe de connexions.
```
Cluster.Builder readerBuilder = Cluster.build()
.port(8182)
.minConnectionPoolSize(…)
.maxConnectionPoolSize(…)
………
.addContactPoint("reader-endpoint-1")
.addContactPoint("reader-endpoint-2")
```
# Fermeture du client pour éviter de limiter les connexions
Il est important de fermer le client lorsque vous en avez terminé avec celui-ci pour vous assurer que les WebSocket connexions sont fermées par le serveur et que toutes les ressources associées aux connexions sont libérées. Cela se produit automatiquement si vous fermez le cluster à l'aide de `Cluster.close( )`, car `client.close( )` est ensuite appelé en interne.
Si le client n'est pas fermé correctement, Neptune met fin à toutes les WebSocket connexions inactives au bout de 20 à 25 minutes. Toutefois, si vous ne fermez pas explicitement les WebSocket connexions lorsque vous en avez terminé et que le nombre de connexions en direct atteint la [limite de connexions WebSocket simultanées](limits.md#limits-websockets), les connexions supplémentaires sont alors refusées avec un code `429` d'erreur HTTP. À ce stade, vous devez redémarrer l'instance Neptune pour fermer les connexions.
Le conseil avisant d'appeler `cluster.close()` ne s'applique pas aux fonctions AWS Lambda Java. Consultez [Gestion des WebSocket connexions G705 dans les fonctions AWS Lambda](lambda-functions-websocket-connections.md) pour plus de détails.
# Création d'une connexion après un basculement
En cas de basculement, le pilote Gremlin peut continuer à se connecter à l'ancien enregistreur, car le nom DNS du cluster a été résolu en une adresse IP. Si cela se produit, vous pouvez créer un nouvel objet `Client` après le basculement.
# Définition de `maxInProcessPerConnection` et `maxSimultaneousUsagePerConnection` sur la même valeur
Les paramètres `maxInProcessPerConnection` et les `maxSimultaneousUsagePerConnection` paramètres sont liés au nombre maximum de requêtes simultanées que vous pouvez soumettre sur une seule WebSocket connexion. En interne, ces paramètres sont liés entre eux et la modification de l'un sans modifier l'autre peut entraîner la réception d'un délai d'expiration lors d'une tentative d'extraction d'une connexion à partir du groupe de connexions du client.
Nous vous recommandons de conserver la valeur minimale par défaut en cours et la valeur d'utilisation simultanée, et de définir `maxInProcessPerConnection` et `maxSimultaneousUsagePerConnection` sur la même valeur.
La valeur sur laquelle définir ces paramètres dépend de la complexité de la requête et du modèle de données. Un cas d'utilisation dans lequel la requête renvoie un grand nombre de données nécessite plus de bande passante de connexion par requête. Par conséquent, les paramètres doivent être définis sur des valeurs plus faibles et `maxConnectionPoolSize` sur une valeur plus élevée.
En revanche, dans le cas où la requête renvoie une plus petite quantité de données, `maxInProcessPerConnection` et `maxSimultaneousUsagePerConnection` doivent être définis sur une valeur plus élevée que `maxConnectionPoolSize`.
# Envoi de requêtes au serveur sous la forme de bytecode et non de chaînes
L'utilisation de bytecode plutôt que d'une chaîne lors de la soumission de requêtes présente plusieurs avantages :
+ **Interception plus rapide d'une syntaxe de requête non valide : ** L'utilisation de la variante bytecode permet de détecter une syntaxe de requête non valide lors de l'étape de compilation. Si vous utilisez la variante basée sur une chaîne, vous ne pouvez pas identifier la syntaxe non valide tant que la requête n'est pas soumise au serveur et qu'une erreur n'est pas renvoyée.
+ **Évitez de réduire les performances basées sur des chaînes :** [toute soumission de requête basée sur des chaînes, que vous utilisiez HTTP WebSockets ou HTTP, entraîne le détachement d'un sommet, ce qui implique que l'objet Vertex comprend l'ID, l'étiquette et toutes les propriétés associées au sommet (voir Propriétés des éléments).](http://tinkerpop.apache.org/docs/current/reference/#_properties_of_elements)
Dans les cas où les propriétés ne sont pas obligatoires, cela peut entraîner des calculs inutiles sur le serveur. Par exemple, si le client souhaite obtenir le vertex portant l'ID « hakuna\$11 » à l'aide de la requête `g.V("hakuna#1")`. Si la requête est envoyée sous la forme d'une soumission basée sur une chaîne, le serveur consacre du temps à la récupération de l'ID, de l'étiquette et de toutes les propriétés de ce vertex. Si la requête est envoyée sous la forme d'une soumission de bytecode, le serveur consacre du temps à la récupération de l'ID et de l'étiquette du vertex uniquement.
En d'autres termes, au lieu de soumettre une requête comme suit :
```
final Cluster cluster = Cluster.build("localhost")
.port(8182)
.maxInProcessPerConnection(32)
.maxSimultaneousUsagePerConnection(32)
.serializer(Serializers.GRAPHBINARY_V1D0)
.create();
try {
final Client client = cluster.connect();
List results = client.submit("g.V().has('name','pumba').out('friendOf').id()").all().get();
System.out.println(verticesWithNamePumba);
} finally {
cluster.close();
}
```
Soumettez la requête en bytecode comme suit :
```
final Cluster cluster = Cluster.build("localhost")
.port(8182)
.maxInProcessPerConnection(32)
.maxSimultaneousUsagePerConnection(32)
.serializer(Serializers.GRAPHBINARY_V1D0)
.create();
try {
final GraphTraversalSource g = traversal().withRemote(DriverRemoteConnection.using(cluster));
List