Pilastro dell'efficienza delle prestazioni

Il pilastro dell'efficienza delle prestazioni del AWS Well-Architected Framework si concentra su come ottimizzare le prestazioni durante l'acquisizione o l'interrogazione dei dati. L'ottimizzazione delle prestazioni è un processo incrementale e continuo che prevede quanto segue:

• Conferma dei requisiti aziendali

• Misurazione delle prestazioni del carico di lavoro

• Identificazione dei componenti poco performanti

• Ottimizzazione dei componenti per soddisfare le esigenze aziendali

Il pilastro dell'efficienza delle prestazioni fornisce linee guida specifiche per i casi d'uso che possono aiutare a identificare il modello di dati grafici e i linguaggi di query corretti da utilizzare. Include inoltre le best practice da seguire per l'acquisizione e l'utilizzo di dati da Amazon Neptune.

Il pilastro dell'efficienza prestazionale si concentra sulle seguenti aree chiave:

• Modellazione grafica

• Ottimizzazione delle query

• Ridimensionamento corretto del cluster

• Ottimizzazione della scrittura

Comprendi la modellazione dei grafici

Comprendi la differenza tra i modelli Labeled Property Graph (LPG) e Resource Description Framework (RDF). Nella maggior parte dei casi, è una questione di preferenza. Esistono tuttavia diversi casi d'uso in cui un modello è più adatto dell'altro. Se hai bisogno di conoscere il percorso che collega due nodi nel tuo grafico, scegli GPL. Se desideri federare i dati tra cluster Neptune o altri archivi Graph Triple, scegli RDF.

Se stai creando un'applicazione SaaS (Software as a Service) o un'applicazione che richiede la multi-tenancy, valuta la possibilità di incorporare la separazione logica dei tenant nel tuo modello di dati anziché avere un tenant per ogni cluster. Per ottenere questo tipo di progettazione, è possibile utilizzare grafici denominati SPARQL e strategie di etichettatura, ad esempio anteporre gli identificatori del cliente alle etichette o aggiungere coppie chiave-valore di proprietà che rappresentano gli identificatori dei tenant. Assicurati che il tuo livello client inserisca questi valori per mantenere quella separazione logica.

Le prestazioni delle query dipendono dal numero di oggetti grafici (nodi, bordi, proprietà) che devono essere valutati durante l'elaborazione della query. Pertanto, il modello grafico può avere un impatto significativo sulle prestazioni dell'applicazione. Utilizzate etichette granulari quando possibile e memorizzate solo le proprietà necessarie per determinare il percorso o filtrare. Per ottenere prestazioni più elevate, prendi in considerazione la possibilità di precalcolare alcune parti del grafico, ad esempio creando nodi di riepilogo o bordi più diretti che collegano percorsi comuni.

Cerca di evitare di navigare tra nodi con un numero anormalmente elevato di bordi con la stessa etichetta. Tali nodi hanno spesso migliaia di spigoli (mentre la maggior parte dei nodi ha un numero di spigoli pari a decine). Il risultato è una complessità di elaborazione e dati molto più elevata. Questi nodi potrebbero non essere problematici in alcuni modelli di query, ma consigliamo di modellare i dati in modo diverso per evitarli, soprattutto se si naviga attraverso il nodo come passaggio intermedio. È possibile utilizzare i log di interrogazione lenta per identificare le query che navigano tra questi nodi. Probabilmente osserverai metriche di latenza e accesso ai dati molto più elevate rispetto ai modelli di query medi, specialmente se utilizzi la modalità di debug.

Usa il nodo deterministico IDs per nodi e bordi se il tuo caso d'uso lo supporta invece di usare Neptune per assegnare valori GUID casuali per. IDs L'accesso ai nodi tramite ID è il metodo più efficiente.

Ottimizza le interrogazioni

I linguaggi OpenCypher e Gremlin possono essere usati in modo intercambiabile sui modelli GPL. Se le prestazioni sono una delle principali preoccupazioni, valuta la possibilità di utilizzare i due linguaggi in modo intercambiabile, perché uno potrebbe funzionare meglio dell'altro per modelli di query specifici.

Neptune è in fase di conversione al suo motore di interrogazione alternativo (DFE). OpenCypher funziona solo sul DFE, ma sia le query Gremlin che SPARQL possono essere impostate opzionalmente per l'esecuzione sul DFE utilizzando le annotazioni di query. Prendi in considerazione la possibilità di testare le tue query con il DFE attivato e di confrontare le prestazioni del tuo modello di query quando non usi il DFE.

Neptune è ottimizzato per le query di tipo transazionale che partono da un singolo nodo o set di nodi e partono a ventaglio da lì, anziché per le query analitiche che valutano l'intero grafico. Per i tuoi carichi di lavoro di query analitiche, prendi in considerazione l'utilizzo dell'SDK AWS per Pandas o l'utilizzo di neptune-export in combinazione con Amazon EMR. AWS Glue

Per identificare inefficienze e rallentamenti nei modelli e nelle query, utilizza il linguaggio di query e for each explain APIs per ottenere spiegazioni dettagliate del piano di query profile e delle metriche di query. Per ulteriori informazioni, consultate Gremlin profile, OpenCypher explain e SPARQL explain.

Comprendi i tuoi schemi di interrogazione. Se il numero di spigoli distinti in un grafico aumenta, la strategia di accesso predefinita a Neptune può diventare inefficiente. Le seguenti interrogazioni potrebbero diventare piuttosto inefficienti:

• Query che navigano all'indietro tra i bordi quando non vengono fornite etichette sui bordi.

• Clausole che utilizzano lo stesso schema internamente, come .both() in Gremlin, o clausole che eliminano nodi in qualsiasi lingua (il che richiede l'eliminazione dei bordi in entrata senza conoscere le etichette).

• Interrogazioni che accedono ai valori delle proprietà senza specificare le etichette delle proprietà. Queste interrogazioni potrebbero diventare piuttosto inefficienti. Se questo corrisponde al tuo modello di utilizzo, valuta la possibilità di abilitare l'indice OSGP (oggetto, soggetto, grafico, predicato).

Utilizzate la registrazione delle query lente per identificare le query lente. Le query lente possono essere causate da piani di query non ottimizzati o da un numero inutilmente elevato di ricerche negli indici, che possono aumentare i costi di I/O. Gli endpoint di spiegazione e profilazione di Neptune per Gremlin, SPARQL o OpenCypher possono aiutarti a capire perché queste query sono lente. Le cause potrebbero includere le seguenti:

• I nodi con un numero anormalmente elevato di bordi rispetto al nodo medio nel grafico (ad esempio, migliaia rispetto a decine) possono aggiungere complessità computazionale e quindi una maggiore latenza e un maggiore consumo di risorse. Determinate se questi nodi sono modellati correttamente o se i modelli di accesso possono essere migliorati per ridurre il numero di bordi da attraversare.

• Le interrogazioni non ottimizzate conterranno un avviso che indica che passaggi specifici non sono ottimizzati. La riscrittura di queste query per utilizzare passaggi ottimizzati potrebbe migliorare le prestazioni.

• I filtri ridondanti potrebbero causare ricerche nell'indice non necessarie. Allo stesso modo, i modelli ridondanti potrebbero causare ricerche negli indici duplicate che possono essere ottimizzate migliorando la query (vedi nell'output del profilo). Index Operations - Duplication ratio

• Alcuni linguaggi come Gremlin non hanno valori numerici fortemente tipizzati e utilizzano invece la promozione dei tipi. Ad esempio, se il valore è 55, Neptune cerca valori che siano numeri interi, lunghi, float e altri tipi numerici equivalenti a 55. Ciò si traduce in operazioni aggiuntive. Se sai in anticipo che i tuoi tipi corrispondono, puoi evitarlo utilizzando un suggerimento di interrogazione.

• Il tuo modello grafico può influire notevolmente sulle prestazioni. Prendi in considerazione la possibilità di ridurre il numero di oggetti da valutare utilizzando etichette più granulari o precalcolando scorciatoie per percorsi lineari a più hop.

Se l'ottimizzazione delle query da sola non vi consente di raggiungere i vostri requisiti di prestazioni, prendete in considerazione l'utilizzo di una varietà di tecniche di caching con Neptune per soddisfare tali requisiti.

Cluster di dimensioni corrette

Dimensiona il cluster in base ai tuoi requisiti di concorrenza e velocità effettiva. Il numero di query simultanee che possono essere gestite da ciascuna istanza del cluster è pari a due volte il numero di CPUs (vCPUs) virtuali su quell'istanza. Le interrogazioni aggiuntive che arrivano mentre tutti i thread di lavoro sono occupati vengono inserite in una coda sul lato server. Queste domande vengono gestite su base first-in-first-out (FIFO) quando i thread di lavoro diventano disponibili. La CloudWatch metrica MainRequestQueuePendingRequests Amazon mostra la profondità attuale della coda per ogni istanza. Se questo valore è spesso superiore a zero, valuta la possibilità di scegliere un'istanza con più v. CPUs Se la profondità della coda supera 8.192, Neptune restituirà un errore. ThrottlingException

Circa il 65 percento della RAM per ogni istanza è riservato alla cache buffer. La cache buffer contiene il set di dati di lavoro (non l'intero grafico, solo i dati che vengono interrogati). Per determinare la percentuale di dati che viene recuperata dalla cache buffer anziché dallo storage, monitora la metrica. CloudWatch BufferCacheHitRatio Se questa metrica scende spesso al di sotto del 99,9%, prendi in considerazione l'idea di provare un'istanza con più memoria per determinare se ciò riduce la latenza e i costi di I/O.

Le repliche di lettura non devono necessariamente avere le stesse dimensioni dell'istanza di Writer. Tuttavia, carichi di lavoro di scrittura pesanti possono far sì che le repliche più piccole rimangano indietro e si riavviino perché non riescono a tenere il passo con la replica. Pertanto, consigliamo di creare repliche uguali o più grandi dell'istanza di writer.

Quando utilizzi l'auto-scaling per le tue repliche di lettura, ricorda che potrebbero essere necessari fino a 15 minuti per portare online una nuova replica di lettura. Quando il traffico del client aumenta rapidamente ma in modo prevedibile, prendi in considerazione l'utilizzo della scalabilità pianificata per impostare un numero minimo di repliche di lettura più elevato in modo da tenere conto del tempo di inizializzazione.

Le istanze serverless supportano diversi casi d'uso e carichi di lavoro. Prendi in considerazione le istanze serverless anziché le istanze con provisioning per i seguenti scenari:

• Il carico di lavoro varia spesso nel corso della giornata.

• Hai creato una nuova applicazione e non sei sicuro delle dimensioni del carico di lavoro.

• Stai eseguendo attività di sviluppo e test.

È importante notare che le istanze serverless sono più costose delle istanze equivalenti con provisioning in base a un dollaro per GB di RAM. Ogni istanza serverless è composta da 2 GB di RAM con vCPU e rete associate. Esegui un'analisi dei costi tra le opzioni disponibili per evitare fatture a sorpresa. In generale, con serverless è possibile ottenere risparmi sui costi solo quando il carico di lavoro è molto intenso solo per poche ore al giorno e quasi zero il resto della giornata o se il carico di lavoro oscilla notevolmente nel corso della giornata.

Ottimizza le scritture

Per ottimizzare le scritture, considerate quanto segue:

• Il Neptune Bulk Loader è il modo ottimale per caricare inizialmente il database o aggiungerlo ai dati esistenti. Il loader Neptune non è transazionale e non può eliminare dati, quindi non utilizzarlo se questi sono i tuoi requisiti.

• Gli aggiornamenti transazionali possono essere effettuati utilizzando i linguaggi di interrogazione supportati. Per ottimizzare le operazioni di I/O di scrittura, scrivi i dati in batch di 50-100 oggetti per commit. Un oggetto è un nodo, un bordo o una proprietà su un nodo o un bordo in GPL, oppure un triplo archivio o un quadrilatero in RDF.

• Tutte le operazioni di scrittura di Neptune sono a thread singolo per ogni connessione. Quando invii una grande quantità di dati a Neptune, prendi in considerazione la possibilità di avere più connessioni parallele, ognuna delle quali consiste nella scrittura di dati. Quando si sceglie un'istanza con provisioning di Neptune, la dimensione dell'istanza è associata a un numero di v. CPUs Neptune crea due thread di database per ogni vCPU sull'istanza, quindi inizia con il doppio di v quando esegui il test per una parallelizzazione CPUs ottimale.  Le istanze serverless ridimensionano il numero di v CPUs a una velocità di circa uno per 4. NCUs

• Pianifica e gestisci ConcurrentModificationExceptionsin modo efficiente tutti i processi di scrittura, anche se una sola connessione sta scrivendo dati in qualsiasi momento. Progetta i tuoi clienti in modo da renderli affidabili quando ConcurrentModificationExceptions si verificano.

• Se desideri eliminare tutti i tuoi dati, valuta la possibilità di utilizzare l'API di ripristino rapido anziché inviare query di eliminazione simultanee. Quest'ultima richiederà molto più tempo e comporterà costi di I/O sostanziali rispetto alla prima.

• Se desideri eliminare la maggior parte dei tuoi dati, valuta la possibilità di esportare i dati che desideri conservare utilizzando neptune-export per caricare i dati in un nuovo cluster. Quindi elimina il cluster originale.