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.

• Surveillez votre utilisation CPU et celle de la mémoire. Cela vous permet de savoir quand migrer vers une classe d'instance de base de données dotée CPU d'une capacité de mémoire supérieure pour atteindre les performances de requête 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 et Surveillance de Neptune pour en savoir plus.

  Neptune disposant de son propre gestionnaire de mémoire, il est normal que l'utilisation de la mémoire soit relativement faible, même lorsque l'CPUutilisation est élevée. 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égionVPC, car les connexions interrégionales associées au VPC peering peuvent retarder les temps de réponse aux requêtes. Pour les réponses aux requêtes à un chiffre en millisecondes, il est nécessaire de maintenir le client et le cluster Neptune dans la même région et. 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.

• 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.

Rubriques

• Bonnes pratiques de sécurité pour Amazon Neptune
• Éviter différentes classes d'instances dans un cluster
• Éviter les redémarrages répétés pendant le chargement en bloc
• Activez l'OSGPindex si vous avez un grand nombre de prédicats
• Éviter les transactions de longue durée dans la mesure du possible
• Bonnes pratiques pour l'utilisation des métriques Neptune
• Bonnes pratiques pour le réglage des requêtes Neptune
• Équilibrage de charge entre les réplicas en lecture
• Chargement plus rapide à l'aide d'une instance temporaire de plus grande taille
• Redimensionnement de l'instance d'enregistreur en basculant vers un réplica en lecture
• Nouvelle tentative de chargement après une erreur d'interruption de tâche de lecture anticipée des données

É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é.

Activez l'OSGPindex si vous avez un grand nombre de prédicats

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.

Dans ce cas, vous pouvez améliorer les performances en activant l'OSGPindex. Consultez L'OSGPindice.

É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 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 et Réglage des requêtes Gremlin. Pour plus d'informations sur le réglage SPARQL des requêtes, consultezSPARQLconseils de requête.

Équilibrage de charge entre les réplicas en lecture

Le routage circulaire des points de terminaison du lecteur fonctionne en modifiant l'hôte vers lequel pointe l'DNSentrée. Le client doit créer une nouvelle connexion et résoudre l'DNSenregistrement 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érentes répliques de lecture pour des demandes successives, assurez-vous que votre client résout l'DNSentrée 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.

2. 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.

3. Dans la commande du chargeur en vrac, incluez “parallelism” : “OVERSUBSCRIBE” pour indiquer à Neptune d'utiliser toutes les CPU ressources disponibles pour le chargement (voirParamètres de demande du chargeur Neptune). L'opération de chargement se déroulera alors aussi rapidement que les E/S le permettent, ce qui nécessite généralement 60 à 70 % des CPU ressources.

4. 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.

5. 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).

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.

La gestion Neptune API que vous utilisez pour basculer délibérément l'instance d'écriture actuelle vers une instance en lecture et réplique est. 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.

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://some-source-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.