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à.
# Best practice operative per ISVs
Molte delle linee guida contenute in questa sezione sono best practice per tutti i clienti, ma hanno un significato aggiunto per. ISVs
## Aggiorna il tuo cluster Neptune con le versioni più recenti
Nelle note di [rilascio di Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/engine-releases.html), puoi vedere che ogni versione apporta una serie di correzioni di bug, miglioramenti delle prestazioni e nuove funzionalità. Mantieni i tuoi cluster Neptune sulla versione più recente il più possibile.
Se trovi un bug precedentemente sconosciuto nel tuo carico di lavoro e il tuo cluster utilizza la versione più recente, i tecnici di Neptune possono creare una patch privata per il tuo cluster (se necessaria e la desideri). La patch può durare fino alla prossima versione, quando la correzione sarà generalmente disponibile. [Per aiutarti ad aggiornare i cluster alla versione più recente, usa la soluzione Neptune Blue/Green.](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-BG-deployments.html)
## Usa i delta invece di eliminare e sostituire per l'ingestione dei dati
È possibile utilizzare diverse tecniche per importare o scrivere dati su Neptune. Molti clienti cercano di semplificare l'inserimento dei dati eliminando e reinserendo il grafico ogni volta che viene ricevuta una modifica nel feed. Potrebbero aggiungere una `last-modified` proprietà a ciascun nodo e scansionare periodicamente i nodi che non sono stati modificati da una data specificata ed eliminarli. Sebbene queste tecniche semplifichino il processo di inserimento dei dati, hanno implicazioni a lungo termine sulla salute e sulla scalabilità per il cluster Neptune.
Innanzitutto, Neptune [utilizza la codifica del dizionario](https://docs.aws.amazon.com/neptune/latest/userguide/feature-overview-data-model.html#feature-overview-storage-dictionary) delle stringhe. A meno che non si specifichi esplicitamente i nodi e gli spigoli, Neptune genera un GUID rappresentato come stringa per l'ID e memorizza tale stringa nel dizionario. IDs Se eliminate e aggiungete costantemente oggetti, quelli generati automaticamente IDs causeranno un aumento del volume nel dizionario.
In secondo luogo, Nettuno si ridimensiona fino a ingerire al massimo circa 120.000 oggetti al secondo. Se si eliminano e si aggiungono continuamente oggetti, si consuma molta di quella larghezza di banda su oggetti che sostanzialmente non cambiano. Ciò limita il numero di tenant che è possibile ospitare in un cluster, richiede istanze di writer più grandi nei cluster e richiede più operazioni. I/O Tutti questi fattori aumentano i costi.
Ti consigliamo vivamente di sviluppare un modo per calcolare il delta reale di ciò che è cambiato invece di utilizzare i metodi delete e add. Tuttavia, alcune fonti di dati non favoriscono questo risultato (ad esempio, chiamate API che restituiscono lo stato corrente o eventi che non tengono traccia esattamente delle modifiche). Se l'origine dei dati grezzi non consente di identificare le modifiche, utilizzate i processi di estrazione, trasformazione e caricamento (ETL) per calcolare il delta. Ad esempio, è possibile conservare le istantanee di ogni precedente acquisizione di dati in formato Parquet, utilizzarle AWS Glue per calcolare le differenze tra tali istantanee e inviare solo le differenze a Neptune.
## Modella in che modo i costi di Neptune si evolveranno con i tuoi inquilini
Sia che utilizzi un silo, un pool o un modello ibrido, i costi del cloud scaleranno in base alle dimensioni dei tuoi tenant. I tenant che richiedono più connessioni simultanee necessitano di istanze più grandi o di più repliche di lettura rispetto a quelli con un minor numero di connessioni simultanee. Lo stesso vale per i tenant che richiedono un'ingestione più rapida dei dati.
I tre componenti del costo del cluster Neptune sono la dimensione (e il numero) dell'istanza, la dimensione dei dati (GB al mese) I/O e le operazioni (per milione). Sebbene questi costi siano generalmente specifici del carico di lavoro, sono scalabili in base alle dimensioni e al volume dei dati e possono essere misurati utilizzando strumenti. AWS Monitora e comprendi le economie di scala rispetto agli indicatori chiave delle dimensioni degli inquilini, incluso il modo in cui le loro dimensioni variano nel tempo. Se l'imprevedibilità degli I/O addebiti influisce sui margini, prendi in considerazione la possibilità di scegliere lo storage [Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/storage-types.html) con ottimizzazione I/O per un costo più prevedibile.
## Scalate i cluster in base alla domanda dei clienti
Non esiste una formula collaudata o vera per dimensionare correttamente la dimensione dell'istanza di Neptune. La documentazione di [Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/instance-types.html) fornisce indicazioni, ma ci sono troppe variabili per consigliare una mappatura diretta. Queste variabili includono, a titolo esemplificativo ma non esaustivo, quanto segue:
+ Modello di dati
+ Forma dei dati
+ Query simultanee
+ Complessità delle interrogazioni.
Pianifica i test per determinare la dimensione ottimale per i carichi di lavoro e i profili degli inquilini. In generale, consigliamo di utilizzare istanze con provisioning per l'efficienza dei costi e la prevedibilità. Se i tuoi obiettivi di customer experience danno priorità alla scalabilità ottimale rispetto ai costi, prendi in considerazione l'utilizzo delle [istanze Neptune Serverless](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-serverless.html) per garantire un'esperienza più coerente indipendentemente dalle fluttuazioni del carico di lavoro.
[Se i carichi di lavoro di lettura dei tenant presentano una notevole variabilità nei picchi e nei minimi, combina le istanze Neptune Serverless con l'auto-scaling di Neptune.](https://docs.aws.amazon.com/neptune/latest/userguide/manage-console-autoscaling.html) In genere occorrono 10-15 minuti prima che una nuova replica di lettura sia online dopo l'inizializzazione. Ciò significa che l'auto-scaling da solo è in grado di gestire variazioni prolungate del traffico, ma non è sufficiente per i picchi di attività in rapida evoluzione. Combinando Neptune Serverless e l'auto-scaling di Neptune, è possibile aumentare o ridurre le istanze e aumentare e ridurre il numero di repliche di lettura in entrata e in uscita.
Se i tuoi tenant hanno profili di carico di lavoro o accordi sul livello di servizio significativamente diversi (SLAs), prendi in considerazione l'utilizzo di [endpoint personalizzati](https://docs.aws.amazon.com/neptune/latest/userguide/feature-custom-endpoint-membership.html) e repliche di lettura dedicate per indirizzare il traffico verso istanze ottimizzate per quel traffico. L'ottimizzazione può includere un diverso dimensionamento dell'istanza, modelli di query specifici o il preriscaldamento della cache del buffer.