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 :

• Une seule instance de base de données principale.

• Jusqu'à 15 instances de base de données de réplica en lecture.

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

Note

Vous ne pouvez pas créer d'instance de réplica en lecture chiffrée pour un cluster de bases de données Neptune non chiffré ni d'instance de réplica en lecture non chiffrée pour un cluster de bases de données Neptune chiffré.

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 de votre cluster de base de données Neptune en fonction de vos besoins CPU et de vos besoins en mémoire. Le nombre de vCPUs 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 fils vCPUs sur cette instance. Unr5.4xlarge, par exemple, avec 16vCPUs, 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 fils de requête sont occupés sont placées dans une file d'attente côté serveur et traitées au fur et à mesure que les fils de requête deviennent disponibles. FIFO 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 fils de requête de l'instance de base de données principale indique idéalement une CPU utilisation de 90 % ou plus, ce qui indique que tous les fils de requête du serveur sont activement engagés dans un travail utile. Cependant, CPU l'utilisation réelle 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 CPU le taux d'utilisation.

Si vous avez un chargement 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, vous pouvez vous attendre à ce que le CPU taux d'utilisation soit encore plus faible. Le montant exact sera fonction du nombre de fils de requête (plus il y a de vCPUs fils de requêtes, moins il y en a CPU par requête), 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 du bon type d'instance de base de données 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.