Stockage, fiabilité et disponibilité d'Amazon Neptune

Amazon Neptune utilise une architecture de stockage distribuée et partagée qui se met automatiquement à l'échelle en fonction de vos besoins en stockage de base de données.

Les données Neptune sont stockées dans un volume de cluster, qui est un volume virtuel unique qui utilise des disques basés sur Non-Volatile Memory Express (NVMe)SSD. Le volume du cluster se compose d'un ensemble de blocs logiques, appelés segments. Chacun de ces segments se voit attribuer 10 gigaoctets (Go) de stockage. Les données de chaque segment sont répliquées en six copies, qui sont ensuite réparties entre trois zones de disponibilité (AZs) dans le AWS Région dans laquelle réside le cluster de base de données.

Lorsqu'un cluster de bases de données Neptune est créé, un seul segment de 10 Go lui est alloué. Lorsque le volume de données augmente et dépasse le stockage actuellement alloué, Neptune augmente automatiquement le volume du cluster en ajoutant de nouveaux segments. Un volume de cluster Neptune peut atteindre une taille maximale de 128 tebioctets (TiB) dans toutes les régions prises en charge, à l'exception de la Chine GovCloud, où il est limité à 64 TiB. Toutefois, pour les versions du moteur antérieures à Sortie : 1.0.2.2 (09/03/2020), la taille des volumes de cluster est limitée à 64 Tio dans toutes les régions.

Le volume de cluster de bases de données contient toutes les données utilisateur, les index et les dictionnaires (décrits dans la section Modèle de données de graphe de Neptune), ainsi que les métadonnées internes, telles que les journaux de transactions internes. Toutes ces données de graphe, y compris les indicateurs et les journaux internes, ne peuvent pas dépasser la taille maximale du volume de cluster.

Option Stockage optimisé pour les E/S

Neptune propose deux modèles de tarification pour le stockage :

• Stockage standard : le stockage standard fournit un stockage de base de données rentable pour les applications dont l’utilisation des E/S est modérée à faible.

• Stockage optimisé pour les E/S : avec le stockage optimisé pour les E/S, vous ne payez que pour le stockage que vous utilisez, à un coût supérieur à celui du stockage standard, et vous ne payez rien pour les E/S que vous utilisez.

  Le stockage optimisé pour les E/S est conçu pour satisfaire les besoins des charges de travail de base gourmandes en E/S à un coût prévisible, avec une faible latence des E/S et un débit d’E/S homogène.

  Pour plus d’informations sur les options de stockage, consultez Stockage optimisé pour les E/S.

Allocation du stockage Neptune

Même si un volume de cluster Neptune peut atteindre une taille de 128 Tio (ou 6 Tio dans quelques régions), vous n'êtes facturé que pour l'espace réellement alloué. L'espace total alloué est déterminé par la limite supérieure, qui est la quantité maximale allouée au volume du cluster à tout moment au cours de son existence.

En d'autres termes, même si les données utilisateur sont supprimées d'un volume de cluster, par exemple par le biais d'une requête de suppression comme g.V().drop(), l'espace total alloué reste le même. Neptune optimise automatiquement l'espace alloué inutilisé pour pouvoir le réutiliser ultérieurement.

Outre les données utilisateur, deux autres types de contenu consomment de l'espace de stockage interne, à savoir les données du dictionnaire et les journaux de transactions internes. Bien que les données du dictionnaire soient stockées avec des données de graphe, elles persistent indéfiniment, même lorsque les données de graphe prises en charge ont été supprimées, ce qui signifie que les entrées peuvent être réutilisées si les données sont réintroduites. Les données des journaux internes sont stockées dans un espace de stockage interne distinct doté de sa propre limite supérieure. Lorsqu'un journal interne expire, l'espace de stockage qu'il occupait peut être réutilisé pour d'autres journaux, mais pas pour les données de graphe. La quantité d'espace interne allouée aux journaux est incluse dans l'espace total indiqué par la VolumeBytesUsed CloudWatch métrique.

Consultez Bonnes pratiques de stockage pour déterminer comment réduire au minimum l'espace de stockage alloué et réutiliser l'espace.

Facturation du stockage Neptune

Les frais de stockage sont facturés sur la base de la limite supérieure, comme décrit ci-dessus. Bien que vos données soient répliquées en six copies, une seule copie des données vous est facturée.

Vous pouvez déterminer le seuil de stockage actuel de votre cluster de base de données en surveillant la VolumeBytesUsed CloudWatch métrique (voirSurveillance de Neptune à l'aide d'Amazon CloudWatch).

Parmi les autres facteurs susceptibles d'affecter les coûts de stockage Neptune, citons les instantanés de base de données et les sauvegardes. Ceux-ci sont facturés séparément en tant que stockage de sauvegarde et sont basés sur les coûts de stockage Neptune (voir Métriques CloudWatch utiles pour gérer le stockage des sauvegardes Neptune).

Toutefois, si vous créez un clone de votre base de données, celui-ci pointe vers le même volume de cluster que celui utilisé par votre cluster de bases de données lui-même. Vous n'encourez donc pas de frais de stockage supplémentaires pour les données d'origine. Les modifications ultérieures apportées au clone utilisent le copy-on-write protocole et entraînent des coûts de stockage supplémentaires.

Pour plus d'informations sur la tarification de Neptune, consultez Tarification Amazon Neptune.

Bonnes pratiques de stockage Neptune

Étant donné que certains types de données nécessitent un stockage permanent dans Neptune, appliquez les bonnes pratiques suivantes pour éviter des pics importants de croissance du stockage :

• Lorsque vous concevez votre modèle de données de graphe, évitez autant que possible d'utiliser des clés de propriété et des valeurs destinées à l'utilisateur qui sont de nature temporaire.

• Si vous prévoyez d'apporter des modifications à votre modèle de données, ne chargez pas de données sur un cluster de base de données existant à l'aide du nouveau modèle tant que vous n'avez pas effacé les données de ce cluster de base de données à l'aide de la réinitialisation rapide API. Il est souvent préférable de charger les données utilisant un nouveau modèle sur un nouveau cluster de bases de données.

• Les transactions qui gèrent de grandes quantités de données génèrent des journaux internes d'une taille correspondante, ce qui contribue à augmenter de façon permanente la limite supérieure d'espace des journaux internes. Par exemple, une seule transaction qui supprime toutes les données de votre cluster de bases de données peut générer un énorme journal interne qui nécessiterait l'allocation d'une grande quantité de stockage interne et réduirait ainsi de façon permanente l'espace disponible pour les données de graphe.

  Pour éviter cela, divisez les transactions volumineuses en transactions de plus petite taille et laissez du temps s'écouler entre elles afin que les journaux internes associés aient une chance d'expirer et de libérer leur espace de stockage interne afin qu'il puisse être réutilisé par les journaux suivants.

• Pour surveiller la croissance du volume de votre cluster Neptune, vous pouvez définir une CloudWatch alarme sur la VolumeBytesUsed CloudWatch métrique. Cela peut s'avérer particulièrement utile si vos données atteignent la taille maximale du volume de cluster. Pour plus d'informations, consultez la section Utilisation des CloudWatch alarmes Amazon.

La seule façon de réduire l'espace de stockage utilisé par votre cluster de bases de données lorsque vous disposez d'une grande quantité d'espace non utilisé consiste à exporter toutes les données de votre graphe, puis à les recharger dans un nouveau cluster de bases de données. Consultez le service et utilitaire d'exportation de données de Neptune pour exporter facilement des données depuis un cluster de bases de données, et le chargeur en bloc Neptune pour réimporter facilement des données dans Neptune.

Note

La création et la restauration d'un instantané ne réduisent pas la quantité de stockage allouée au cluster de bases de données, car un instantané conserve l'image d'origine du stockage sous-jacent du cluster. Si une quantité substantielle du stockage alloué n'est pas utilisée, la seule façon de la réduire la quantité de stockage alloué est d'exporter toutes les données de votre graphe, puis de les recharger dans un nouveau cluster de bases de données.

Fiabilité et haute disponibilité du stockage Neptune

Amazon Neptune est conçu pour être fiable, durable et tolérant aux pannes.

Le fait que six copies de vos données Neptune soient conservées dans trois zones de disponibilité (AZs) garantit que le stockage des données est extrêmement durable, avec un très faible risque de perte de données. Les données sont répliquées automatiquement dans toutes les zones de disponibilité, qu'elles contiennent ou non des instances de base de données, et le volume de la réplication est indépendant du nombre d'instances de base de données du cluster.

Vous pouvez donc ajouter rapidement un réplica en lecture, car Neptune ne fait pas de nouvelle copie des données du graphe. Au lieu de cela, le réplica en lecture se connecte au volume partagé qui contient déjà toutes les données. De même, la suppression d'un réplica en lecture ne supprime aucune des données sous-jacentes.

Vous ne pouvez supprimer le volume du cluster et ses données qu'après avoir supprimé toutes ses instances de base de données.

De plus, Neptune détecte automatiquement les défaillances au niveau des segments qui composent le volume du cluster. Lorsqu'une copie des données d'un segment est corrompue, Neptune répare immédiatement ce segment en utilisant d'autres copies des données au sein du même segment pour s'assurer que les données réparées sont à jour. Neptune évite ainsi les pertes de données et réduit le besoin d'effectuer une point-in-time restauration pour récupérer après une panne de disque.