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

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 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 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 fornisce indicazioni, ma ci sono troppe variabili per consigliare una mappatura diretta. Queste variabili includono, a titolo esemplificativo ma non esaustivo, quanto segue:

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