Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Pilastro dell'ottimizzazione dei costi

Il pilastro dell'ottimizzazione dei costi del AWS Well-Architected Framework si concentra sull'evitare costi inutili. I seguenti consigli possono aiutarti a soddisfare i principi di progettazione per l'ottimizzazione dei costi e le best practice architettoniche per Amazon Neptune.

Il pilastro dell'ottimizzazione dei costi si concentra sulle seguenti aree chiave:

Comprendi i modelli di utilizzo e i servizi necessari

Neptune è la soluzione ideale per il tuo carico di lavoro se il tuo modello di dati ha una struttura a grafi riconoscibile e le tue query devono esplorare le relazioni e attraversare più hop. Un database grafico non è adatto ai seguenti modelli:

Valuta se l'utilizzo congiunto di più database creati appositamente per modelli di accesso specifici possa soddisfare tutte le tue esigenze. Esempio:

Comprendi i costi associati ai servizi che interagiscono e completano Neptune, inclusi i seguenti:

Seleziona le risorse prestando attenzione ai costi

I prezzi di Neptune si basano sul costo orario dell'istanza (o sulle unità di calcolo Neptune utilizzate per la versione serverless), sull'I/O dei dati e sull'utilizzo dello storage. Le istanze rappresentano, in media, l'85% del costo complessivo, quindi un corretto dimensionamento può avere implicazioni significative in termini di costi. Il modo migliore per dimensionare correttamente le istanze è testare le prestazioni delle applicazioni su una varietà di istanze e confrontare i seguenti fattori:

I costi delle istanze variano in modo lineare in base alle dimensioni all'interno della stessa famiglia di istanze. Il costo orario dell'db.r6i.2xlargeistanza è il doppio di quello dell'db.r6i.xlargeistanza e ha anche il doppio dell'allocazione delle risorse. L'db.r6i.24xlargeistanza è 24 volte il costo orario dell'istanza. db.r6i.xlarge

Stima il numero di query simultanee che devi supportare. È possibile disporre di un numero compreso tra zero e quindici repliche di lettura per l'elaborazione di interrogazioni di sola lettura. Se i requisiti variano in base all'ora del giorno, della settimana o del mese, puoi utilizzare più istanze più piccole per scalare in base a una pianificazione. Ogni vCPU su un'istanza fornisce due thread per la gestione delle query simultanee. Tre repliche di db.r6i.xlarge lettura, con 4 vCPU ciascuna, possono gestire 24 query simultanee.

Se il volume di traffico viene invece misurato in query al secondo (QPS), è necessario sperimentare per determinare la latenza media delle query. Il numero di query al secondo che un cluster Neptune può supportare è pari a. vCPU × 2 × (1 second/average query latency) Ad esempio, se si dispone di 4 vCPU e una latenza di query di 100 millisecondi (0,1 secondi),. QPS = 4 × 2 × (1s/0.1s) = 80 queries per second

Le istanze con provisioning sono più economiche di quelle senza server per carichi di lavoro continui, stabili e prevedibili. Il serverless offre opportunità di ottimizzazione dei costi quando si dispone di un carico di lavoro che richiede un utilizzo molto elevato per poche ore al giorno (ad esempiodb.r6i.4xlarge) e quindi quasi nessun traffico per il resto della giornata (ad esempio, 1 Neptune Compute Unit). Un'istanza serverless con scalabilità verso l'alto per alcune ore e poi ridotta sarà meno costosa rispetto all'utilizzo di un'istanza con provisioning per tutto il giorno. db.r6i.4xlarge

Prendi in considerazione l'aggiornamento a Neptune 1.4.5.0 o versione successiva e l'utilizzo di r8g istanze per ottenere una migliore velocità di lettura e scrittura a un costo inferiore rispetto alle istanze di vecchia generazione, come o. r7g r6g Per ulteriori informazioni, consulta il rapporto prezzo/prestazioni di scrittura delle query 4,7 volte migliore con le istanze AWS Graviton4 R8g che utilizzano Amazon Neptune v1.4.5 (post sul blog).AWS

I cluster Neptune vengono creati per impostazione predefinita con lo storage standard (se crei utilizzando la console, per impostazione predefinita 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 selezionerà l'archiviazione ottimizzata, eseguirà il caricamento iniziale dei dati e quindi passerà allo storage standard. Il tipo di archiviazione influisce solo sul modello di fatturazione e non presenta differenze tecniche nella configurazione del cluster o dell'istanza di Neptune DB. È possibile modificare il tipo di archiviazione una volta ogni 30 giorni. Dopo 30 giorni, controlla i costi dettagliati di Neptune e utilizza la pagina dei prezzi di Neptune per calcolare se i costi sarebbero stati più elevati utilizzando -optimized. I/O-optimized storage. If they would have been, continue to use standard storage, otherwise switch back to I/O

Scegli la configurazione dell'istanza Neptune migliore per il tuo carico di lavoro

Se l'hai creato Account AWS prima del 15 luglio 2025, puoi utilizzare il piano AWS gratuito per sperimentare Neptune come principiante. Le 750 ore gratuite di db.t3.medium utilizzo dell'db.t4g.mediumistanza sono sufficienti per acquisire una buona comprensione di Neptune su bassa scala. Il tuo cluster rimarrà attivo dopo la fine del periodo di prova gratuito, anche se da quel momento in poi ti verranno addebitati i costi per l'utilizzo.

Le db.t4g.medium istanze db.t3.medium e sono ideali per ambienti di sviluppo a basso costo in cui non si utilizzano OpenCypher, Graph Explorer o varie integrazioni di intelligenza artificiale generativa. Queste istanze hanno un RAM-to-vCPU rapporto inferiore (2:1) rispetto alle istanze familiari (8:1) o alle istanze R familiari (16:1). X Questa riduzione del rapporto impedisce l'uso delle statistiche del motore DFE che abilitano le prestazioni di OpenCypher, le integrazioni GenAI (per informare l'LLM dello schema del grafico) e Graph Explorer. I profili prestazionali potrebbero differire in modo significativo quando si utilizzano istanze T familiari, in particolare per i carichi di lavoro menzionati in precedenza. Queste istanze possono anche aumentare il numero di casi in OutOfMemoryExceptions cui le query navigano su una parte significativa del grafico. Per determinare se quest'ultima condizione potrebbe essere influenzata, controlla la BufferCacheHitRatio CloudWatch metrica.

Sconsigliamo vivamente di eseguire test delle prestazioni o del carico con le istanze T familiari perché potrebbero verificarsi risultati incoerenti che non sono indicativi di un ambiente di produzione.

Le istanze con provisioning offrono la migliore combinazione di costi e prestazioni quando il carico di lavoro è abbastanza stabile e prevedibile. Scegliete la dimensione dell'istanza in base alla contemporaneità della richiesta e alla complessità della query. Una maggiore concorrenza richiede più v. CPUs Una maggiore complessità delle query richiede più RAM. Utilizza la MainRequestQueuePendingRequests CloudWatch metrica per determinare l'impatto della prima (un valore maggiore di zero indica un numero di richieste simultanee superiore a quello che è possibile gestire). Utilizza la BufferCacheHitRatio CloudWatch metrica per determinare l'impatto della seconda. Un rapporto che scende spesso al di sotto del 99,9 percento indica che non c'è abbastanza RAM per contenere la parte operativa del grafico da valutare, il che si traduce in uno scambio di cache più frequente. Se la famiglia di istanze R fornisce una concorrenza sufficiente ma non abbastanza RAM, prova a provare la X famiglia di istanze.

I casi d'uso ideali per le istanze serverless sono descritti nella documentazione di Neptune. Se non siete sicuri se il provisioning o il serverless siano la soluzione migliore per voi e il costo è la vostra preoccupazione principale, testate il vostro carico di lavoro in modalità serverless per determinare il numero di applicazioni NCUs utilizzate e confrontate il costo di provisioned () con serverless (). N hours × hourly provisioned cost sum of NCUs × hourly cost per NCU Se non si è certi dell'istanza di provisioning di dimensioni equivalenti, una NCU equivale a circa 2 GB di RAM e vCPU e rete associate. Se l'istanza fornita appartiene alla r6i famiglia, il rapporto è 1 vCPU per 8 GB di RAM, o NCUs 4, oltre alla rete associata. Il calcolatore dei prezzi di Amazon Neptune fornisce anche un confronto per aiutarti a decidere la configurazione dei costi ottimale.

Quando utilizzi la modalità serverless per le istanze primarie e di replica, ricorda che le repliche di lettura nei livelli di promozione 0 e 1 le ridimensioneranno in base all'istanza di writer, NCUs in modo che vengano ridimensionate correttamente in caso di evento di failover. Imposta i limiti NCU per queste istanze in base a quale delle tue istanze, writer o reader, riceve la maggior parte del traffico.

In ambienti in cui il cluster non è necessario 24 ore al giorno, 7 giorni alla settimana, prendete in considerazione la possibilità di scrivere script che disattivino le istanze di Neptune quando non sono in uso e le riavviino prima di essere utilizzate. Le istanze Neptune verranno riavviate automaticamente ogni 7 giorni per garantire l'applicazione degli aggiornamenti di manutenzione richiesti. Se intendi lasciare le istanze disattivate per lunghi periodi, usa uno script settimanale per chiuderle nuovamente.

Archiviazione e trasferimento dei dati delle dimensioni corrette

Le query più efficienti (ad esempio, le query che devono toccare un minor numero di nodi, bordi e proprietà nel grafico) richiedono meno I/O trasferimenti e possono potenzialmente utilizzare istanze più piccole perché è necessaria una minore cache di buffer. Utilizzate gli endpoint Profile or Explore del vostro linguaggio di query per ottimizzare la query e valutate la possibilità di ottimizzare il modello grafico per le prestazioni delle query.

Neptune utilizza la codifica del dizionario su stringhe di grandi dimensioni e tale dizionario è ottimizzato per le prestazioni, non per l'efficienza. Se disponi di stringhe JSON di grandi dimensioni BLOBs o che cambiano frequentemente per le proprietà, valuta la possibilità di archiviarle all'esterno di Neptune in Amazon S3, Amazon DynamoDB o Amazon DocumentDB e memorizza solo un riferimento all'interno del nodo Neptune.

In alcuni casi, la scelta di un'istanza di dimensioni maggiori può essere più economica. Se i I/O costi sono molto elevati perché bassiBufferCacheHitRatio, è possibile che una cache buffer più grande riduca in modo significativo tale costo. Questo perché tutti i dati entrerebbero nella cache anziché essere spesso scambiati dallo storage e incorrere in una velocità di trasferimento elevata. I/O

copy-on-writeNeptune usa la clonazione. Quando si esegue la clonazione per dividere un grafico in più frammenti, potrebbe essere più efficiente non eliminare i dati indesiderati dal cluster clonato, poiché ciò comporterebbe la creazione di nuove pagine di dati, con conseguente aumento dei costi di archiviazione. I dati che non sono stati modificati prima dell'evento di clonazione saranno presenti in un'unica pagina di dati condivisa tra i due cluster e verranno addebitati solo per quella singola copia.

Non attivate l'indice OSGP o utilizzate le istanze R5d a meno che non abbiate effettuato dei test per confermare che fanno una differenza sostanziale nel carico di lavoro. Entrambi sono progettati per scenari che si verificano raramente e potrebbero aumentare i costi con guadagni minimi o nulli.