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à. # Ottimizzazione di un caricamento in blocco di Amazon Neptune Utilizzare le seguenti strategie per ridurre al minimo il tempo di caricamento per un caricamento in blocco di Neptune: + **Pulire i dati:** + Assicurarsi di convertire i dati in un [formato di dati supportato](bulk-load-tutorial-format.md) prima di caricarli. + Rimuovere eventuali duplicati o errori noti. + Ridurre il più possibile il numero di predicati univoci (come le proprietà di archi e vertici). + **Ottimizzare i file:** + Se si caricano file di grandi dimensioni come i file CSV da un bucket Amazon S3, lo strumento di caricamento gestisce la concorrenza per l'utente analizzandoli in blocchi che possono essere caricati in parallelo. L'utilizzo di un numero molto elevato di file di piccole dimensioni può rallentare questo processo. + Se carichi più file da un prefisso Amazon S3, il loader carica automaticamente prima i file vertex, poi i file edge. Tuttavia, se sai che caricherai solo file edge, `edgeOnlyLoad` puoi impostare in modo da `TRUE` ignorare il primo passaggio in cui tutti i file vengono scansionati per determinarne il contenuto (vertici o bordi) in modo che tutti i file con i vertici trovati vengano caricati prima di qualsiasi file edge. Questo può velocizzare notevolmente il tempo di caricamento, specialmente quando sono coinvolti molti file edge. Nel caso in cui alcuni file vertex siano presenti anche nello stesso prefisso Amazon S3 `source` (parametro), verranno caricati ma senza alcuna garanzia di ordine rispetto ad altri file. Inoltre, se alcuni `from` `to` vertici non sono presenti nel database, l'inserimento degli edge potrebbe riportare errori nel messaggio. `FROM_OR_TO_VERTEX_ARE_MISSING` Come best practice, inserisci nodi e edge in un prefisso Amazon S3 separato. + **Controllare le impostazioni dello dello strumento di caricamento:** + Se non è necessario eseguire altre operazioni durante il caricamento, utilizzare il parametro [`OVERSUBSCRIBE`  `parallelism`](load-api-reference-load.md#load-api-reference-load-syntax). Questa impostazione dei parametri fa sì che lo strumento di caricamento in blocco utilizzi tutte le risorse della CPU disponibili durante l'esecuzione. In genere è necessario il 60%-70% della capacità della CPU per mantenere l'operazione in esecuzione alla velocità consentita dai vincoli. I/O **Nota** Quando `parallelism` è impostato su `OVERSUBSCRIBE` o `HIGH` (l'impostazione predefinita), durante il caricamento dei dati openCypher c'è il rischio che i thread incontrino una race condition e un deadlock, causando un errore `LOAD_DATA_DEADLOCK`. In questo caso, impostare `parallelism` su un'impostazione inferiore e riprovare a eseguire il caricamento. + Se il processo di caricamento include più richieste di caricamento, utilizzare il parametro `queueRequest`. L'impostazione di `queueRequest` su `TRUE` consente a Neptune di mettere in coda le richieste in modo da non dover aspettare che una finisca prima di inviarne un'altra. + Se le richieste di caricamento vengono messe in coda, è possibile impostare i livelli di dipendenza utilizzando il parametro `dependencies`, in modo che l'esito negativo di un processo causi l'esito negativo dei processi dipendenti. In questo modo è possibile evitare incongruenze nei dati caricati. + Se un processo di caricamento prevede l'aggiornamento di valori caricati in precedenza, assicurarsi di impostare il parametro `updateSingleCardinalityProperties` su `TRUE`. In caso contrario, lo strumento di caricamento considererà un errore il tentativo di aggiornare un valore di cardinalità singola esistente. Per i dati Gremlin, la cardinalità è specificata anche nelle intestazioni di colonna di proprietà (vedi [Intestazioni di colonna delle proprietà](bulk-load-tutorial-format-gremlin.md#bulk-load-tutorial-format-gremlin-propheaders)). **Nota** Il parametro `updateSingleCardinalityProperties` non è disponibile per i dati RDF (Resource Description Framework). + È possibile utilizzare il parametro `failOnError` per determinare se le operazioni di caricamento in blocco devono avere esito negativo o continuare quando si verifica un errore. Inoltre, è possibile utilizzare il parametro `mode` per assicurarsi che un processo di caricamento riprenda il caricamento dal punto in cui un processo precedente ha avuto esito negativo anziché ricaricare i dati che erano già stati caricati. + **Aumentare la capacità:** impostare l'istanza di scrittura del cluster database sulla dimensione massima prima del caricamento in blocco. Tenere presente che se si esegue questa operazione, è necessario aumentare la capacità anche di tutte le istanze di replica di lettura nel cluster database o rimuoverle fino al termine del caricamento dei dati. Una volta completato il caricamento in blocco, assicurarsi di dimensionare nuovamente l'istanza di scrittura. **Importante** 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. Vedi [Parametri della richiesta](load-api-reference-load.md#load-api-reference-load-parameters) per maggiori dettagli sull'impostazione dei parametri di richiesta dello strumento di caricamento.