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à.
# Linee guida operative di base per Amazon Neptune
Di seguito sono illustrate le linee guida operative di base da seguire quando si usa Neptune.
+ Informazioni sulle istanze database di Neptune per poterle dimensionare in modo appropriato in base ai requisiti di prestazioni e al caso d'uso. Per informazioni, consulta [Cluster e istanze database di Amazon Neptune](feature-overview-db-clusters.md).
+ Monitora l'utilizzo della CPU e della memoria. Ciò ti consente di sapere quando eseguire la migrazione a una classe di istanza database con una maggiore capacità di memoria o di CPU per ottenere le prestazioni di query richieste. Puoi configurare Amazon in modo che CloudWatch ti avvisi quando i modelli di utilizzo cambiano o quando ti avvicini alla capacità della tua implementazione. In questo modo può aiutarti a mantenere le prestazioni del sistema e la disponibilità. Consultare [Monitoraggio delle istanze](feature-overview-db-clusters.md#feature-overview-monitoring-instances) e [Monitoraggio di Neptune](monitoring.md) per i dettagli.
Poiché Neptune dispone del proprio gestore di memoria, è normale osservare un utilizzo della memoria relativamente basso anche quando l'utilizzo della CPU è elevato. Incontrare out-of-memory eccezioni durante l'esecuzione delle query è l'indicatore migliore di cui hai bisogno per aumentare la memoria liberabile.
+ Abilita i backup automatici e imposta la finestra di backup su un orario opportuno.
+ Prova il failover per l'istanza database per capire quanto tempo impiega il processo per il tuo caso d'uso. Inoltre, ciò contribuisce a garantire che l'applicazione che accede all'istanza database è in grado di connettersi automaticamente alla nuova istanza database dopo il failover.
+ Se possibile, eseguire il client e il cluster Neptune nella stessa regione e VPC, poiché le connessioni tra regioni con il peering VPC possono introdurre ritardi nei tempi di risposta delle query. Per le risposte delle query in pochi millisecondi, è necessario mantenere il client e il cluster Neptune nella stessa regione e nello stesso VPC.
+ Quando si crea un'istanza di replica di lettura, questa deve essere grande almeno quanto l'istanza di scrittura master. Ciò consente di mantenere sotto controllo il ritardo di replica ed evitare il riavvio della replica. Per informazioni, consulta [Evitare classi di istanze diverse in un cluster](#best-practices-loader-heterogeneous-instances).
+ Prima di eseguire l'aggiornamento a una nuova versione principale del motore, è necessario assicurarsi di testare l'applicazione su di essa prima di procedere. A tale scopo, è possibile clonare il cluster database affinché il cluster clone esegua la nuova versione del motore e quindi testare l'applicazione sul clone.
+ Per facilitare i failover, tutte le istanze dovrebbero idealmente avere le stesse dimensioni.
**Topics**
+ [Best practice di Amazon Neptune per la sicurezza](best-practices-general-security.md)
+ [Evitare classi di istanze diverse in un cluster](#best-practices-loader-heterogeneous-instances)
+ [Evitare i riavvii ripetuti durante il caricamento in blocco](#best-practices-loader-repeated-restarts)
+ [Abilitazione dell'indice OSGP in presenza di un numero elevato di predicati](#best-practices-general-predicates)
+ [Evitare le transazioni di lunga durata, ove possibile](#best-practices-general-long-running-transactions)
+ [Best practice per l'utilizzo delle metriche di Neptune](best-practices-general-metrics.md)
+ [Best practice per l'ottimizzazione delle query di Neptune](#best-practices-general-tuning)
+ [Bilanciamento del carico tra le repliche di lettura](#best-practices-general-loadbalance)
+ [Caricamento più veloce con un'istanza temporanea di dimensioni più grandi](#best-practices-loader-tempinstance)
+ [Ridimensiona l'istanza di scrittura eseguendo il failover su una replica di lettura](#best-practices-resize-instance)
+ [Nuovo tentativo di caricamento dopo l'errore di attività di prefetch dei dati interrotta](#load-api-reference-status-interrupted)
# Best practice di Amazon Neptune per la sicurezza
Usa gli account AWS Identity and Access Management (IAM) per controllare l'accesso alle azioni dell'API Neptune. Controlla le azioni per creare, modificare o eliminare risorse Neptune, come istanze database, gruppi di sicurezza, gruppi di opzioni o gruppi di parametri, e quelle per eseguire azioni amministrative comuni, come il backup e il ripristino di istanze database.
+ Usa credenziali temporanee anziché credenziali persistenti quando possibile.
+ Assegna un account IAM singolo a ogni utente che gestisce le risorse Amazon Relational Database Service (Amazon RDS). Non utilizzare mai utenti root AWS dell'account per gestire le risorse di Neptune. Crea un utente IAM per tutti, incluso te stesso.
+ Assegna a ciascun utente il set minimo di autorizzazioni richieste per eseguire le proprie mansioni.
+ Utilizza gruppi IAM per gestire in modo efficace le autorizzazioni per più utenti.
+ Ruota periodicamente le credenziali IAM.
Per ulteriori informazioni sull'utilizzo di IAM per l'accesso alle risorse Neptune, consulta [Protezione del database Amazon Neptune](security.md). Per informazioni generali sull'utilizzo di IAM, consulta [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html) e [Best practice di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html) nella *Guida per l'utente di IAM*.
## Evitare classi di istanze diverse in un cluster
Quando il cluster database contiene istanze di classi diverse, nel tempo possono verificarsi problemi. Il problema più comune è che un'istanza di lettura di piccole dimensioni può entrare in un ciclo di riavvii ripetuti a causa del ritardo di replica. Se un nodo di lettura ha una configurazione della classe dell'istanza database più debole rispetto a quella di un'istanza database di scrittura, il volume delle modifiche può essere troppo grande perché il nodo di lettura riesca a stare al passo.
**Importante**
Per evitare riavvii ripetuti causati dal ritardo di replica, configura il cluster database in modo che tutte le istanze abbiano la stessa classe di istanza (dimensioni).
Puoi vedere il ritardo tra l'istanza writer (la principale) e i lettori nel tuo cluster DB utilizzando la `ClusterReplicaLag` metrica in Amazon. CloudWatch La metrica `VolumeWriteIOPs` consente inoltre di rilevare picchi di attività di scrittura nel cluster che possono creare ritardi nella replica.
## Evitare i riavvii ripetuti durante il caricamento in blocco
Se si verifica un ciclo di riavvii ripetuti delle repliche di lettura a causa del ritardo di replica durante un caricamento in blocco, è probabile che le repliche non riescano a stare al passo con l'istanza di scrittura nel cluster database.
Dimensionare le istanze di lettura in modo che siano più grandi dell'istanza di scrittura oppure rimuoverle temporaneamente durante il caricamento in blocco e quindi ricrearle al termine dell'operazione.
## Abilitazione dell'indice OSGP in presenza di un numero elevato di predicati
Se il modello di dati contiene un elevato numero di predicati distinti (nella maggior parte dei casi più di mille), le prestazioni potrebbero risultare ridotte con costi operativi più elevati.
In tal caso, è possibile migliorare le prestazioni abilitando l'[indice OSGP](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp). Per informazioni, consulta [Indice OSGP](features-lab-mode.md#features-lab-mode-features-osgp-index).
## Evitare le transazioni di lunga durata, ove possibile
Le transazioni di lunga durata, di sola lettura o di lettura e scrittura, possono causare problemi imprevisti dei seguenti tipi:
Una transazione di lunga durata su un'istanza di lettura o su un'istanza di scrittura con scritture simultanee può comportare un accumulo significativo di diverse versioni dei dati. Questo può causare latenze più elevate per le query di lettura che filtrano gran parte dei risultati.
In alcuni casi, le versioni accumulate nelle ore possono limitare le nuove scritture.
Una transazione di lettura-scrittura di lunga durata con molte scritture può causare problemi anche in caso di riavvio dell'istanza. Se un'istanza viene riavviata dopo un evento di manutenzione o un arresto anomalo, tutte le scritture di cui non è stato eseguito il commit vengono ripristinate. Tali operazioni di annullamento in genere vengono eseguite in background e non impediscono il ripristino dell'istanza, ma qualsiasi nuova scrittura che sia in conflitto con le operazioni in fase di rollback ha esito negativo.
Se ad esempio la stessa query viene ripetuta dopo l'interruzione della connessione nell'esecuzione precedente, potrebbe avere esito negativo al riavvio dell'istanza.
Il tempo necessario per annullare le operazioni è proporzionale alle dimensioni delle modifiche coinvolte.
# Best practice per l'utilizzo delle metriche di Neptune
Per identificare i problemi di prestazioni causati da risorse insufficienti e altri colli di bottiglia comuni, puoi monitorare le metriche disponibili per il cluster database Neptune.
Monitora regolarmente i parametri relativi alle prestazioni per raccogliere dati riguardo ai valori medi, massimi e minimi per vari intervalli di tempo. Ciò consente di identificare quando le prestazioni subiscono un calo. Utilizzando questi dati, puoi impostare CloudWatch allarmi Amazon per determinate soglie metriche in modo da essere avvisato se vengono raggiunte.
Quando configuri un nuovo cluster di database e lo esegui con un carico di lavoro tipico, prova ad acquisire i valori medi, massimi e minimi di tutti i parametri relativi alle prestazioni a intervalli diversi (ad esempio, un'ora, 24 ore, una settimana, due settimane). Ciò ti permette di avere un quadro dei valori normali. Ciò aiuta anche a effettuare confronti delle attività durante le ore di punta e non di punta. Puoi quindi utilizzare queste informazioni per identificare quando le prestazioni scendono al di sotto dei livelli standard e impostare gli allarmi di conseguenza.
Consulta [Monitoraggio di Neptune tramite Amazon CloudWatch](cloudwatch.md) per informazioni su come visualizzare le metriche di Neptune.
Di seguito sono elencati i parametri più importanti con cui iniziare:
+ **BufferCacheHitRatio**— La percentuale di richieste servite dalla buffer cache. I mancati riscontri della cache aggiungono una latenza significativa all'esecuzione delle query. Se il rapporto di riscontri della cache è inferiore al 99,9% e la latenza è un problema per l'applicazione, valuta la possibilità di aggiornare il tipo di istanza per memorizzare nella cache più dati in memoria.
+ **Utilizzo della CPU**: percentuale di capacità di elaborazione del computer utilizzata. Valori di utilizzo della CPU elevati possono essere appropriati, a seconda degli obiettivi relativi alle prestazioni di query.
+ **Memoria liberabile**: quantità di RAM disponibile nell'istanza database, in megabyte. Neptune dispone di un proprio gestore di memoria, quindi questa metrica potrebbe essere minore del previsto. Un buon segno che indica che dovresti prendere in considerazione l'aggiornamento della tua classe di istanza a una con più RAM è se le query generano spesso eccezioni. out-of-memory
Nella scheda **Monitoring (Monitoraggio)**, la linea rossa indica un livello del 75% per i parametri CPU e memoria. Se il consumo di memoria dell'istanza supera spesso questa linea, controlla il carico di lavoro e valuta la possibilità di aggiornare l'istanza per migliorare le prestazioni di query.
## Best practice per l'ottimizzazione delle query di Neptune
Uno dei modi migliori per migliorare le prestazioni di Neptune consiste nell'ottimizzare le query più comuni e a uso intensivo di risorse per rendere l'esecuzione meno costosa.
Per informazioni su come ottimizzare le query Gremlin, consulta [Hint di query Gremlin](gremlin-query-hints.md) e [Ottimizzazione di query Gremlin](gremlin-traversal-tuning.md). Per informazioni su come ottimizzare le query SPARQL, consulta [Hint di query SPARQL](sparql-query-hints.md).
## Bilanciamento del carico tra le repliche di lettura
L'instradamento round robin dell'endpoint lettore funziona cambiando l'host a cui punta la voce DNS. Il client deve creare una nuova connessione e risolvere il record DNS per ottenere una connessione a una nuova replica di lettura, poiché le WebSocket connessioni vengono spesso mantenute attive per lunghi periodi.
Per ottenere repliche di lettura diverse per richieste successive, assicurarsi che il client risolva la voce DNS ogni volta che si connette. Potrebbe essere necessario chiudere la connessione e riconnettersi all'endpoint del lettore.
É inoltre possibile eseguire il bilanciamento del carico delle richieste tra le repliche di lettura connettendo esplicitamente gli endpoint dell'istanza.
## Caricamento più veloce con un'istanza temporanea di dimensioni più grandi
Le prestazioni di caricamento aumentano con le istanze di dimensioni più grandi. Se non utilizzi un tipo di istanza di grandi dimensioni, ma vuoi aumentare la velocità di caricamento, puoi utilizzare un'istanza più grande per caricare e poi eliminarla.
**Nota**
La procedura seguente è per un nuovo cluster. Se hai già un cluster, puoi aggiungere una nuova istanza più grande e quindi promuoverla a istanza database primaria.
**Per caricare i dati utilizzando un'istanza di dimensioni più grandi**
1. Creare un cluster con una singola istanza `r5.12xlarge`. Questa è l'istanza database primaria.
1. Creare una o più repliche di lettura delle stesse dimensioni (`r5.12xlarge`).
È possibile creare le repliche di lettura in dimensioni inferiori, ma se non sono abbastanza grandi per stare al passo con le scritture effettuate dall'istanza primaria, potrebbe essere necessario riavviarle di frequente. I tempi di inattività che ne derivano riducono drasticamente le prestazioni.
1. Nel comando dello strumento di caricamento in blocco, includi `“parallelism” : “OVERSUBSCRIBE”` per indicare a Neptune di utilizzare tutte le risorse della CPU disponibili per il caricamento (consulta [Parametri della richiesta dello dello strumento di caricamento Neptune](load-api-reference-load.md#load-api-reference-load-parameters)). L'operazione di caricamento procederà quindi alla massima velocità I/O consentita, il che in genere richiede il 60-70% delle risorse della CPU.
1. Caricare i dati utilizzando Neptune Loader. Il processo di caricamento viene eseguito nell'istanza database primaria.
1. Al termine del caricamento dei dati, assicurati di dimensionare tutte le istanze del cluster in base allo stesso tipo di istanza per evitare costi aggiuntivi e problemi di riavvii ripetuti (consulta [Evitare istanze di dimensioni diverse](#best-practices-loader-heterogeneous-instances)).
## Ridimensiona l'istanza di scrittura eseguendo il failover su una replica di lettura
Il modo migliore per ridimensionare un'istanza nel cluster database, inclusa l'istanza di scrittura, consiste nel creare o modificare un'istanza di replica di lettura affinché abbia le dimensioni desiderate e quindi eseguire deliberatamente il failover su tale replica di lettura. Il tempo di inattività rilevato dall'applicazione corrisponde esclusivamente al tempo necessario per modificare l'indirizzo IP dell'istanza di scrittura, in genere compreso tra 3 e 5 secondi.
L'API di gestione di Neptune usata per eseguire deliberatamente il failover dell'istanza di scrittura corrente su un'istanza di replica di lettura è [Failover DBCluster](api-clusters.md#FailoverDBCluster). Se utilizzi il client Java Gremlin, potrebbe essere necessario creare un nuovo oggetto client dopo il failover per rilevare il nuovo indirizzo IP, come indicato [qui](best-practices-gremlin-java-new-connection.md).
Assicurati di modificare tutte le istanze impostandole sulle stesse dimensioni per evitare un ciclo di riavvii ripetuti, come indicato di seguito.
## Nuovo tentativo di caricamento dopo l'errore di attività di prefetch dei dati interrotta
Quando si caricano dati in Neptune mediante lo strumento di caricamento in blocco, occasionalmente può essere restituito uno stato `LOAD_FAILED`, con un messaggio `PARSING_ERROR` e `Data prefetch task interrupted` segnalato in risposta a una richiesta di informazioni dettagliate, come segue:
```
"errorLogs" : [
{
"errorCode" : "PARSING_ERROR",
"errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
"fileName" : "s3://amzn-s3-demo-bucket/some-source-file",
"recordNum" : 0
}
]
```
Se si verifica questo errore, è sufficiente riprovare la richiesta di caricamento in blocco.
L'errore si verifica quando si è verificata un'interruzione temporanea che in genere non è stata causata dalla richiesta o dai dati e solitamente si può risolvere eseguendo nuovamente la richiesta di caricamento in blocco.
Se stai utilizzando impostazioni predefinite, ovvero `"mode":"AUTO"` e `"failOnError":"TRUE"`, il loader salta i file che ha già caricato e riprende il caricamento dei file che non aveva ancora caricato quando si è verificata l'interruzione.