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.

Pilier d’optimisation des coûts

Le pilier d'optimisation des coûts du AWS Well-Architected Framework vise à éviter les coûts inutiles. Les recommandations suivantes peuvent vous aider à respecter les principes de conception d'optimisation des coûts et les meilleures pratiques architecturales pour Amazon Neptune.

Le pilier de l'optimisation des coûts se concentre sur les domaines clés suivants :

Comprendre les modèles d'utilisation et les services nécessaires

Neptune convient parfaitement à votre charge de travail si votre modèle de données possède une structure graphique perceptible et que vos requêtes doivent explorer les relations et effectuer plusieurs sauts. Une base de données de graphes ne convient pas aux modèles suivants :

Déterminez si l'utilisation conjointe de plusieurs bases de données spécialement conçues pour des modèles d'accès spécifiques peut répondre à tous vos besoins. Par exemple :

Comprenez les coûts associés aux services qui interagissent avec Neptune et le complètent, notamment les suivants :

Sélectionnez les ressources en tenant compte des coûts

La tarification de Neptune est basée sur le coût horaire de l'instance (ou les unités de calcul Neptune consommées en mode sans serveur), les E/S de données et l'utilisation du stockage. Les instances représentent, en moyenne, 85 % du coût total, de sorte que le bon dimensionnement peut avoir des implications financières importantes. Le meilleur moyen de dimensionner correctement les instances consiste à tester les performances des applications sur diverses instances et à comparer les facteurs suivants :

Les coûts des instances évoluent de manière linéaire en fonction de la taille au sein d'une même famille d'instances. Le coût horaire de l'db.r6i.2xlargeinstance est le double de celui de l'db.r6i.xlargeinstance et les ressources allouées sont également deux fois plus élevées. Le coût horaire de l'db.r6i.24xlargeinstance est 24 fois supérieur à celui de l'db.r6i.xlargeinstance.

Estimez le nombre de requêtes simultanées que vous devez prendre en charge. Vous pouvez avoir entre zéro et quinze répliques en lecture pour traiter les requêtes en lecture seule. Si vos besoins varient en fonction de l'heure de la journée, de la semaine ou du mois, vous pouvez utiliser plusieurs instances plus petites pour effectuer une mise à l'échelle selon un calendrier. Chaque vCPU d'une instance fournit deux threads pour gérer les requêtes simultanées. Trois répliques de db.r6i.xlarge lecture, avec 4 vCPU chacune, peuvent gérer 24 requêtes simultanées.

Si votre volume de trafic est plutôt mesuré en requêtes par seconde (QPS), vous devez expérimenter pour déterminer la latence moyenne de vos requêtes. Le nombre de requêtes par seconde qu'un cluster Neptune peut prendre en charge est égal à. vCPU × 2 × (1 second/average query latency) Par exemple, si vous avez 4 vCPU et une latence de requête de 100 millisecondes (0,1 seconde),. QPS = 4 × 2 × (1s/0.1s) = 80 queries per second

Les instances provisionnées sont moins chères que les instances sans serveur pour des charges de travail continues, stables et prévisibles. Le mode Serverless permet d'optimiser les coûts lorsque votre charge de travail nécessite une utilisation très élevée quelques heures par jour (par exempledb.r6i.4xlarge), puis pratiquement aucun trafic le reste de la journée (par exemple, une unité de calcul Neptune). Une instance sans serveur qui évolue pendant quelques heures puis redémarre sera moins coûteuse que d'utiliser une db.r6i.4xlarge instance provisionnée toute la journée.

Envisagez de passer à Neptune 1.4.5.0 ou version ultérieure et d'utiliser des r8g instances pour obtenir un meilleur débit de lecture et d'écriture à moindre coût que les instances d'ancienne génération, telles que ou. r7g r6g Pour plus d'informations, découvrez un rapport prix/performances de requête en écriture 4,7 fois supérieur avec les instances AWS Graviton4 R8g utilisant Amazon Neptune v1.4.5 (article de blog).AWS

Les clusters Neptune sont créés par défaut avec un stockage standard (si vous créez à l'aide de la console, le stockage est sélectionné par défaut, I/O-optimized storage). With I/O-optimized storage, you pay a slightly higher cost for storage and instances, but there are no I/O costs. This leads to more predictable recurring costs, but if your I/O usage is generally low, it may be more cost efficient to utilize standard storage. If you intend to load a lot of data initially, you can optimize cost by choosing I/O le chargement initial des données est effectué, puis il passe au stockage standard). Le type de stockage affecte uniquement le modèle de facturation et ne présente aucune différence technique dans la configuration du cluster ou de l'instance de base de données Neptune. Vous pouvez modifier le type de stockage une fois tous les 30 jours. Au bout de 30 jours, vérifiez le détail de vos coûts Neptune et utilisez la page de tarification de Neptune pour déterminer si vos coûts auraient été plus élevés avec -optimized. I/O-optimized storage. If they would have been, continue to use standard storage, otherwise switch back to I/O

Choisissez la configuration d'instance Neptune la mieux adaptée à votre charge de travail

Si vous avez créé le vôtre Compte AWS avant le 15 juillet 2025, vous pouvez utiliser le niveau AWS gratuit pour des expériences d'entrée de gamme avec Neptune. Les 750 heures gratuites db.t3.medium et d'utilisation de l'db.t4g.mediuminstance sont suffisantes pour vous faire une bonne idée de Neptune à petite échelle. Votre cluster sera conservé après la fin de la période d'essai gratuite, mais son utilisation vous sera facturée à partir de cette date.

Les db.t4g.medium instances db.t3.medium et conviennent aux environnements de développement à faible coût dans lesquels vous n'utilisez pas OpenCypher, Graph Explorer ou diverses intégrations génératives d'IA. Ces instances ont un RAM-to-vCPU ratio inférieur (2:1) à celui des instances R familiales (8:1) ou des instances X familiales (16:1). Ce ratio réduit empêche l'utilisation des statistiques du moteur DFE qui permettent les performances d'OpenCypher, les intégrations GenAI (pour informer le LLM du schéma du graphe) et Graph Explorer. Les profils de performance peuvent être très différents lors de l'utilisation d'instances T familiales, en particulier pour les charges de travail mentionnées précédemment. Ces instances peuvent également augmenter le nombre de OutOfMemoryExceptions requêtes qui parcourent une partie significative du graphique. Pour déterminer si cette dernière condition est susceptible d'être affectée, vérifiez la BufferCacheHitRatio CloudWatch métrique.

Nous vous déconseillons vivement d'effectuer des tests de performance ou de charge avec des instances de T la famille, car vous pourriez obtenir des résultats incohérents qui ne sont pas révélateurs d'un environnement de production.

Les instances provisionnées vous offrent la meilleure combinaison de coûts et de performances lorsque votre charge de travail est relativement stable et prévisible. Choisissez la taille de l'instance en fonction de la simultanéité des demandes requise et de la complexité de la requête. Une simultanéité plus élevée nécessite plus de v. CPUs Une complexité de requête plus élevée nécessite davantage de RAM. Utilisez la MainRequestQueuePendingRequests CloudWatch métrique pour déterminer l'impact de la première option (une valeur supérieure à zéro représente un nombre de demandes simultanées supérieur à ce qui peut être traité). Utilisez la BufferCacheHitRatio CloudWatch métrique pour déterminer l'impact de cette dernière. Un ratio souvent inférieur à 99,9 % indique qu'il n'y a pas assez de RAM pour contenir la partie active du graphique en cours d'évaluation, ce qui entraîne des échanges de cache plus fréquents. Si la famille d'instances R fournit une simultanéité suffisante mais pas assez de RAM, envisagez d'essayer la X famille d'instances.

Les cas d'utilisation idéaux pour les instances sans serveur sont décrits dans la documentation Neptune. Si vous ne savez pas si la solution provisionnée ou sans serveur est la meilleure solution pour vous et que le coût est votre principale préoccupation, testez votre charge de travail en mode sans serveur pour déterminer le nombre de machines NCUs utilisées et comparez le coût de provisioned (N hours × hourly provisioned cost) à celui de sans serveur (). sum of NCUs × hourly cost per NCU Si vous n'êtes pas sûr d'une instance de provisionnement de taille équivalente, une NCU équivaut à environ 2 Go de RAM, ainsi qu'au vCPU et au réseau associés. Si votre instance provisionnée appartient à la r6i famille, le ratio est de 1 vCPU pour 8 Go de RAM, ou NCUs 4, avec le réseau associé. Le calculateur de prix Amazon Neptune fournit également une comparaison pour vous aider à déterminer votre configuration de coûts optimale.

Lorsque vous utilisez le mode sans serveur pour les instances principales et de réplication, n'oubliez pas que les répliques en lecture des niveaux de promotion 0 et 1 seront redimensionnées NCUs en fonction de l'instance d'écriture afin qu'elles soient correctement dimensionnées en cas de basculement. Définissez vos limites de NCU pour ces instances en fonction des instances (enregistreurs ou lecteurs) qui reçoivent le plus de trafic.

Dans les environnements où le cluster n'est pas nécessaire 24 heures sur 24, 7 jours sur 7, envisagez d'écrire des scripts qui désactiveront les instances Neptune lorsqu'elles ne sont pas utilisées et les redémarreront avant leur utilisation. Les instances Neptune redémarrent automatiquement tous les 7 jours pour garantir l'application des mises à jour de maintenance requises. Si vous avez l'intention de laisser les instances désactivées pendant de longues durées, utilisez un script hebdomadaire pour les arrêter à nouveau.

Stockage et transfert de données à la bonne taille

Les requêtes plus efficaces (par exemple, les requêtes qui doivent toucher un nombre réduit de nœuds, d'arêtes et de propriétés dans le graphe) nécessitent moins de I/O transferts et peuvent éventuellement utiliser des instances plus petites car la quantité de cache tampon requise est moindre. Utilisez le profil ou expliquez les points de terminaison de votre langage de requête afin d'optimiser votre requête, et envisagez d'optimiser votre modèle de graphe en fonction des performances de vos requêtes.

Neptune utilise le codage par dictionnaire sur de grandes chaînes, et ce dictionnaire est optimisé pour les performances, et non pour l'efficacité. Si vous avez de grandes BLOBs chaînes JSON ou si vous changez fréquemment de chaîne pour les propriétés, envisagez de les stocker en dehors de Neptune dans Amazon S3, Amazon DynamoDB ou Amazon DocumentDB, et de stocker uniquement une référence dans le nœud Neptune.

Dans certains cas, le choix d'une taille d'instance plus grande peut s'avérer moins coûteux. Si vos I/O coûts sont très élevés en raison d'un faible niveauBufferCacheHitRatio, il est possible qu'un cache tampon plus important réduise considérablement ces coûts. En effet, toutes les données rentreraient dans le cache au lieu d'être fréquemment échangées depuis le stockage et d'augmenter le I/O taux de transfert.

Neptune utilise copy-on-write le clonage. Lorsque vous clonez pour diviser un graphe en plusieurs fragments, il peut être plus efficace de ne pas supprimer les données indésirables du cluster cloné, car cela impliquera la création de nouvelles pages de données, ce qui entraînera une augmentation des coûts de stockage. Les données inchangées par rapport à avant l'événement de clonage existeront sur une seule page de données partagée entre les deux clusters et ne seront facturées que pour cette copie unique.

N'activez pas l'index OSGP et n'utilisez pas d'instances R5d à moins d'avoir effectué des tests pour confirmer qu'elles font une différence substantielle dans votre charge de travail. Les deux sont conçus pour des scénarios rares, et ils peuvent augmenter vos coûts pour des gains minimes ou nuls.