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.

Clusters de bases de données et instances de base de données Amazon Neptune

Un cluster de bases de données Amazon Neptune gère l'accès à vos données par le biais de requêtes. Un cluster se compose des éléments suivants :

Toutes les instances d'un cluster partagent le même volume de stockage géré sous-jacent, dans le but de garantir fiabilité et haute disponibilité.

Vous vous connectez aux instances de base de données du cluster de bases de données via des points de terminaison Neptune.

Instance de base de données principale dans un cluster de bases de données Neptune

L'instance de base de données principale coordonne toutes les opérations d'écriture sur le volume de stockage sous-jacent du cluster de bases de données. Elle prend également en charge les opérations de lecture.

Il ne peut y avoir qu'une seule instance de base de données principale dans un cluster de bases de données Neptune. Si l'instance principale devient indisponible, Neptune bascule automatiquement vers l'une des instances de réplica en lecture avec une priorité que vous pouvez spécifier.

Instances de base de données de réplica en lecture dans un cluster de bases de données Neptune

Une fois que vous avez créé l'instance principale d'un cluster de bases de données, vous pouvez créer jusqu'à 15 réplicas en lecture dans ce cluster afin de prendre en charge les requêtes en lecture seule.

Les instances de base de données de réplica en lecture Neptune sont adaptées à la mise à l'échelle de la capacité de lecture, car elles sont entièrement dédiées aux opérations de lecture sur le volume du cluster. Toutes les opérations d'écriture sont gérées par l'instance principale. Chaque instance de base de données de réplica en lecture possède son propre point de terminaison.

Étant donné que le volume de stockage du cluster est partagé entre toutes les instances d'un cluster, toutes les instances de réplica en lecture renvoient les mêmes données pour les résultats des requêtes avec un retard de réplication très faible. Ce retard est généralement bien inférieur à 100 ms après que l'instance principale a écrit une mise à jour, bien qu'il puisse être un peu plus long lorsque le volume d'opérations d'écriture est très élevé.

Le fait qu'une ou plusieurs instances de réplica en lecture soient disponibles dans différentes zones de disponibilité contribue à accroître la disponibilité, car les réplicas en lecture servent de cibles de basculement pour l'instance principale. En d'autres termes, si l'instance principale échoue, Neptune promeut une instance de réplica en lecture au statut d'instance principale. Lorsque cela se produit, une brève interruption est observée pendant le redémarrage de l'instance promue, interruption au cours de laquelle les demandes de lecture et d'écriture adressées à l'instance principale échouent avec une exception.

En revanche, si votre cluster de bases de données n'inclut aucune instance de réplica en lecture, le cluster de bases de données reste indisponible en cas de défaillance de l'instance principale tant qu'elle n'a pas été recréée. La recréation de l'instance principale prend beaucoup plus de temps que la promotion d'un réplica en lecture.

Pour garantir une haute disponibilité, nous vous recommandons de créer une ou plusieurs instances de réplica en lecture ayant la même classe d'instances de base de données que l'instance principale et situées dans des zones de disponibilité différentes de celles de l'instance principale. Consultez Tolérance aux pannes pour un cluster de bases de données Neptune.

À l'aide de la console, vous pouvez créer un déploiement multi-AZ en spécifiant simplement l'option Multi-AZ lors de la création d'un cluster DB. Si un cluster de bases de données se trouve dans une seule zone de disponibilité, vous pouvez en faire un cluster de bases de données multi-AZ en ajoutant un réplica Neptune dans une autre zone de disponibilité.

Pour plus d'informations sur la création d'une instance de base de données de réplica en lecture Neptune, consultez Création d'une instance de lecteur Neptune à l'aide de la console.

Dimensionnement des instances de base de données dans un cluster de bases de données Neptune

Dimensionnez les instances du cluster de bases de données Neptune en fonction de vos besoins en termes de CPU et de mémoire. Le nombre de v CPUs sur une instance détermine le nombre de fils de requête qui traitent les requêtes entrantes. La quantité de mémoire d'une instance détermine la taille du cache de tampon. Elle est utilisée pour stocker des copies des pages de données extraites du volume de stockage sous-jacent.

Chaque instance de base de données Neptune possède un nombre de threads de requête égal à 2 x le nombre de v CPUs sur cette instance. Anr5.4xlarge, par exemple, avec 16 vCPUs, possède 32 fils de requêtes et peut donc traiter 32 requêtes simultanément.

Les requêtes supplémentaires qui arrivent alors que tous les threads de requête sont occupés sont placées dans une file d'attente côté serveur et traitées selon le principe du « premier entré, premier sorti » (FIFO) au fur et à mesure que les threads deviennent disponibles. Cette file d'attente côté serveur peut contenir environ 8 000 demandes en attente. Une fois qu'elle est pleine, Neptune répond aux demandes supplémentaires avec une exception ThrottlingException. Vous pouvez surveiller le nombre de demandes en attente à l'aide de la MainRequestQueuePendingRequests CloudWatch métrique ou en utilisant le point de terminaison d'état des requêtes Gremlin avec le includeWaiting paramètre.

Du point de vue du client, le temps d'exécution de la requête inclut le temps passé dans la file d'attente, en plus du temps nécessaire à l'exécution effective de la requête.

Une charge d'écriture simultanée soutenue qui utilise tous les threads de requête de l'instance de base de données principale indique idéalement une utilisation du CPU de 90 % ou plus, ce qui indique que tous les threads de requête du serveur sont activement impliqués dans une tâche utile. Cependant, l'utilisation réelle du CPU est souvent légèrement inférieure, même dans le cas d'une charge d'écriture simultanée prolongée. Cela est généralement dû au fait que les threads de requête attendent l'exécution des opérations d'E/S du volume de stockage sous-jacent. Neptune utilise des écritures de quorum qui effectuent six copies des données dans trois zones de disponibilité. Quatre de ces six nœuds de stockage doivent accuser réception d'une écriture pour que celles-ci soient considérées comme durables. Lorsqu'un thread de requête attend ce quorum provenant du volume de stockage, il est bloqué, ce qui réduit l'utilisation du CPU.

Si vous avez une charge d'écriture en série où vous effectuez une écriture après l'autre et que vous attendez que la première soit terminée avant de commencer la suivante, l'utilisation du CPU devrait être encore plus faible. La quantité exacte sera fonction du nombre de v CPUs et de threads de requête (plus il y a de threads de requêtes, moins le processeur total par requête est élevé), avec une certaine réduction due à l'attente des E/S.

Pour plus d'informations sur la meilleure façon de dimensionner les instances de base de données, consultez Choix des types d'instances pour Amazon Neptune. Pour connaître la tarification de chaque type d'instance, consultez la page de tarification de Neptune.

Surveillance des performances des instances de base de données dans Neptune

Vous pouvez utiliser CloudWatch les métriques de Neptune pour surveiller les performances de vos instances de base de données et suivre la latence des requêtes observée par le client. Consultez Utilisation CloudWatch pour surveiller les performances des instances de base de données dans Neptune.