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à.
# Preparazione per la migrazione da Neo4j a Neptune
La migrazione dal database grafico Neo4j al servizio di database di grafici Neptune può essere affrontata in due modi principali: re-platforming o refactoring/re-architecting. L'approccio di ripiattaforma prevede la modifica del modello di dati e dell'architettura applicativa esistenti per sfruttare al meglio le funzionalità di Neptune, mentre l'approccio di refactoring si concentra sulla ricerca di componenti equivalenti in Neptune per creare un'implementazione comparabile. In pratica, viene spesso utilizzata una combinazione di queste strategie, poiché il processo di migrazione prevede il bilanciamento dell'architettura Neptune di destinazione con i vincoli e i requisiti dell'implementazione Neo4j esistente. Indipendentemente dall'approccio, la chiave è partire dai casi d'uso dell'applicazione per progettare il modello di dati, le interrogazioni e l'architettura complessiva che meglio rispondono alle vostre esigenze.
## Approcci alla migrazione
Quando si esegue la migrazione di un'applicazione Neo4j su Neptune, consigliamo di seguire una di due strategie: quella di re-platforming o quella di refactoring/re-architecting. Per ulteriori informazioni sulle strategie di migrazione, consulta [6 Strategies for Migrating Applications to the Cloud](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/), un post del blog di Stephen Orban.
L'*approccio di re-platforming*, a volte chiamato *lift-tinker-and-shift*, prevede i seguenti passaggi:
+ Identificazione dei casi d'uso che l'applicazione deve soddisfare.
+ Modifica del modello di dati a grafo e dell'architettura applicativa esistenti per soddisfare al meglio le esigenze di carico di lavoro utilizzando le funzionalità di Neptune.
+ Definizione della migrazione di dati, query e altre parti dell'applicazione di origine nel modello e nell'architettura di destinazione.
Questo approccio "a ritroso" consente di eseguire la migrazione dell'applicazione nel tipo di soluzione Neptune che potresti progettare se si trattasse di un progetto completamente nuovo.
L'*approccio del refactoring*, al contrario, prevede questi passaggi:
+ Identificazione dei componenti dell'implementazione esistente, tra cui infrastruttura, dati, query e funzionalità dell'applicazione.
+ Individuazione di soluzioni Neptune equivalenti che possano essere usate per creare un'implementazione comparabile.
Questo approccio "progressivo" punta a sostituire un'implementazione con un'altra.
Nella pratica, è probabile che adotterai un mix di questi due approcci. Potresti iniziare con un caso d'uso, ad esempio progettare l'architettura Neptune di destinazione, per poi passare all'implementazione Neo4j esistente per identificare i vincoli e gli elementi fondamentali che dovrai rispettare. Ad esempio, potresti dover continuare a integrarti con altri sistemi esterni o continuare a offrire offerte specifiche APIs per gli utenti della tua applicazione grafica. Con queste informazioni, è possibile determinare se esistono già dei dati da trasferire nel modello di destinazione e quali devono provenire da altre origini.
In altre fasi, potresti iniziare analizzando una parte specifica dell'implementazione Neo4j come fonte migliore di informazioni su ciò che deve fare l'applicazione. Questo tipo di analisi storica dell'applicazione esistente è utile per definire un caso d'uso mirato a utilizzare le funzionalità di Neptune.
Sia che tu stia creando una nuova applicazione utilizzando Neptune o eseguendo la migrazione di un'applicazione esistente da Neo4j, ti consigliamo di lavorare a ritroso partendo dai casi d'uso per progettare un modello di dati, una serie di query e un'architettura applicativa che soddisfino le esigenze aziendali.
# Differenze architettoniche tra Neptune e Neo4j
Quando i clienti prendono in considerazione per la prima volta la migrazione di un'applicazione da Neo4j a Neptune, sono spesso tentati di eseguire un confronto basato sulla dimensione dell'istanza. like-to-like Tuttavia, le architetture di Neo4j e Neptune hanno differenze fondamentali. Neo4j si basa su un all-in-one approccio in cui il caricamento dei dati, l'ETL dei dati, le query delle applicazioni, l'archiviazione dei dati e le operazioni di gestione avvengono tutti nello stesso set di risorse di elaborazione, come le istanze EC2.
Neptune, al contrario, è un database a grafo incentrato su OLTP in cui l'architettura separa le responsabilità e le risorse sono separate in modo che possano scalare in modo dinamico e indipendente.
Durante la migrazione da Neo4j a Neptune, devi determinare i requisiti di durabilità, disponibilità e scalabilità dei dati dell'applicazione. L'architettura di cluster di Neptune semplifica la progettazione di applicazioni che richiedono durabilità, disponibilità e scalabilità elevate. Se comprendi bene l'architettura di cluster di Neptune, potrai progettare una topologia di cluster Neptune per soddisfare questi requisiti.
## Architettura di cluster di Neo4j
Molte applicazioni di produzione utilizzano il [clustering causale](https://neo4j.com/docs/operations-manual/current/clustering/introduction/) di Neo4j per garantire durabilità dei dati, alta disponibilità e scalabilità. L'architettura di clustering di Neo4j utilizza istanze di server principali e di replica di lettura:
+ I server principali garantiscono la durabilità dei dati e la tolleranza agli errori mediante la replica dei dati con il protocollo Raft.
+ Le repliche di lettura utilizzano l'invio dei log delle transazioni per replicare in modo asincrono i dati per carichi di lavoro con throughput di lettura elevato.
Ogni istanza di un cluster, che si tratti di un server principale o di una replica di lettura, contiene una copia completa dei dati a grafo.
## Architettura di cluster di Neptune
[Un cluster di Neptune](feature-overview-db-clusters.md) è composto da un'istanza di scrittura principale e da un massimo di 15 istanze di replica di lettura. Tutte le istanze del cluster condividono lo stesso servizio di archiviazione distribuito sottostante, separato rispetto alle istanze.
+ L'istanza di scrittura principale coordina tutte le operazioni di scrittura sul database ed è scalabile verticalmente per fornire un supporto flessibile per diversi carichi di lavoro di scrittura. Supporta anche le operazioni di lettura.
+ Le istanze di replica di lettura supportano le operazioni di lettura dal volume di archiviazione sottostante e consentono la scalabilità orizzontale per supportare carichi di lavoro di lettura elevati. Garantiscono, inoltre, un'elevata disponibilità poiché fungono da destinazioni di failover per l'istanza principale.
**Nota**
Nel caso di carichi di lavoro con attività intensive di scrittura, è consigliabile ridimensionare le istanze di replica di lettura in modo che abbiano le stesse dimensioni dell'istanza di scrittura, così da garantire che i reader possano rimanere in linea con le modifiche dei dati.
+ Il volume di archiviazione sottostante ridimensiona automaticamente la capacità di archiviazione con l'aumento dei dati del database (fino a 128 TiB di archiviazione).
Le dimensioni delle istanze sono dinamiche e indipendenti. Ogni istanza può essere ridimensionata mentre il cluster è in esecuzione e le repliche di lettura possono essere aggiunte o rimosse durante l'esecuzione del cluster.
La funzionalità [Neptune Serverless](neptune-serverless.md) può aumentare e ridurre automaticamente la capacità di elaborazione in base all'aumento e alla diminuzione della domanda. In questo modo, è possibile non solo ridurre il sovraccarico amministrativo, ma anche configurare il database per gestire picchi di domanda elevati senza ridurre le prestazioni o richiedere un provisioning eccessivo.
È possibile arrestare un cluster di Neptune per un massimo di sette giorni.
Neptune supporta anche il [dimensionamento automatico](manage-console-autoscaling.md) per adattare automaticamente le dimensioni delle istanze reader in base al carico di lavoro.
Utilizzando la [funzionalità di database globale](neptune-global-database.md) Neptune, puoi eseguire il mirroring di un cluster in un massimo di altre 5 regioni.
Neptune offre anche la [tolleranza agli errori per impostazione predefinita](backup-restore-overview-fault-tolerance.md):
+ Il volume del cluster che fornisce l'archiviazione dei dati a tutte le istanze del cluster si estende su più zone di disponibilità () in un'unica. AZs Regione AWS Ogni AZ contiene una copia completa dei dati del cluster.
+ Se l'istanza principale non è più disponibile, Neptune esegue automaticamente il failover su una replica di lettura esistente senza alcuna perdita di dati, in genere in meno di 30 secondi. Se nel cluster non esistono repliche di lettura, Neptune effettua automaticamente il provisioning di una nuova istanza primaria, sempre senza perdere dati.
Ciò significa che, durante la migrazione da un cluster causale Neo4j a Neptune, non è necessario progettare la topologia del cluster in modo esplicito in modo che abbia durabilità dei dati e disponibilità elevate. Puoi così stabilire le dimensioni del cluster in base ai carichi di lavoro di lettura e scrittura previsti, nonché a eventuali requisiti di maggiore disponibilità. Ecco come puoi fare:
+ Per scalare le operazioni di lettura, [aggiungi istanze di replica di lettura](feature-overview-db-clusters.md#feature-overview-read-replicas) o abilita la funzionalità [Neptune Serverless](neptune-serverless.md).
+ Per migliorare la disponibilità, distribuisci l'istanza principale e leggi le repliche nel cluster su più zone di disponibilità (). AZs
+ Per ridurre i tempi di failover, fornisci almeno un'istanza di replica di lettura che possa fungere da destinazione di failover per l'istanza primaria. Per determinare l'ordine di promozione a istanza primaria delle repliche di lettura dopo un errore, [assegna una priorità a ciascuna di esse](manage-console-add-replicas.md). È consigliabile assicurarsi che una destinazione di failover disponga di una classe di istanza in grado di gestire il carico di lavoro di scrittura dell'applicazione, se promossa a istanza primaria.
# Differenze di archiviazione di dati tra Neptune e Neo4j
Neptune utilizza un [modello di dati a grafo](feature-overview-data-model.md) basato su un modello quad nativo. Durante la migrazione dei dati a Neptune, devi conoscere le molte differenze nell'architettura del modello di dati e nel livello di archiviazione per utilizzare in modo ottimale l'archiviazione condivisa distribuita e scalabile fornita da Neptune:
+ Neptune non utilizza schemi o vincoli definiti in modo esplicito. Consente di aggiungere nodi, archi e proprietà in modo dinamico senza dover definire preventivamente lo schema. Neptune non limita i valori e i tipi di dati archiviati, ad eccezione di quanto indicato nei [limiti di Neptune](limits.md#limits-properties). Come parte dell'architettura di archiviazione di Neptune, i dati vengono inoltre [indicizzati automaticamente](feature-overview-storage-indexing.md) in modo da gestire molti dei pattern di accesso più comuni. Questa architettura di archiviazione elimina il sovraccarico operativo legato alla creazione e alla gestione dello schema del database e all'ottimizzazione degli indici.
+ Neptune offre un'architettura di archiviazione distribuita e condivisa univoca che si ridimensiona automaticamente in blocchi da 10 GB man mano che le esigenze di archiviazione del database crescono, fino a 128 tebibyte (TiB). Questo livello di archiviazione è affidabile, duraturo e tollerante agli errori, con dati copiati 6 volte, due volte in ciascuna delle 3 zone di disponibilità. Per impostazione predefinita, tutti i cluster di Neptune hanno un livello di archiviazione di dati ad alta disponibilità e tollerante agli errori. L'architettura di archiviazione di Neptune riduce i costi ed elimina la necessità di eseguire il provisioning o l'over-provisioning dell'archiviazione per gestire la crescita futura dei dati.
Prima di eseguire la migrazione dei dati su Neptune, è bene acquisire familiarità con il [modello di dati a grafo delle proprietà](feature-overview-storage-indexing.md#feature-overview-storage-indexing-gremlin) e la [semantica delle transazioni](transactions.md) di Neptune.
# Differenze operative tra Neptune e Neo4j
Neptune è un servizio completamente gestito che automatizza molte delle normali attività operative da svolgere quando utilizzi database locali o autogestiti come Neo4j Enterprise o Community Edition:
+ **[Backup automatici](backup-restore.md#backup-restore-overview-backups)**: Neptune esegue automaticamente il backup del volume del cluster e conserva il backup per un periodo specificato da te (da 1 a 35 giorni). Questi backup sono continui e incrementali, in modo da poter eseguire rapidamente un ripristino in qualsiasi punto nel periodo di conservazione. Durante la scrittura dei dati di backup, non si verifica alcun impatto sulle prestazioni o interruzione del funzionamento del servizio del database.
+ **[Snapshot manuali](backup-restore.md)**: Neptune consente di creare uno snapshot del volume di archiviazione del cluster database per eseguire il backup dell'intero cluster database. Questo tipo di snapshot può quindi essere utilizzato per ripristinare il database, crearne una copia e condividerlo tra più account.
+ **[Clonazione](manage-console-cloning.md)**: Neptune supporta una funzionalità di clonazione per creare rapidamente cloni di un database a costi contenuti. I cloni utilizzano un copy-on-write protocollo che richiede solo uno spazio aggiuntivo minimo dopo la creazione. La clonazione del database è un modo efficace per provare nuove funzionalità o aggiornamenti di Neptune senza interrompere il cluster di origine.
+ **[Monitoraggio](monitoring.md)**: Neptune offre vari metodi per monitorare le prestazioni e l'utilizzo del cluster, tra cui:
+ Stato dell'istanza
+ Integrazione con Amazon CloudWatch e AWS CloudTrail
+ Funzionalità di log di audit
+ Notifiche degli eventi
+ Assegnazione di tag
+ **[Sicurezza](security.md)**: per impostazione predefinita, Neptune fornisce un ambiente sicuro. Un cluster risiede all'interno di un VPC privato che garantisce l'isolamento della rete da altre risorse. Tutto il traffico è crittografato tramite SSL e tutti i dati inattivi vengono crittografati utilizzando AWS KMS.
[Inoltre, Neptune si integra AWS Identity and Access Management con (IAM) per fornire l'autenticazione.](iam-auth.md) Se specifichi [chiavi delle condizioni IAM](iam-condition-keys.md), puoi utilizzare le policy IAM per offrire un controllo granulare degli accessi per le [azioni sui dati](iam-data-access-policies.md).
## Differenze di strumenti e integrazioni tra Neptune e Neo4j
Neptune ha un'architettura diversa per le integrazioni e gli strumenti rispetto a Neo4j, il che può influire sull'architettura dell'applicazione. Neptune utilizza le risorse di calcolo del cluster per elaborare le query, ma sfrutta best-in-class AWS altri servizi per funzionalità come la ricerca full-text (utilizzo OpenSearch), ETL (utilizzo di Glue) e così via. Per un elenco completo di queste integrazioni, vedi [Integrazioni di Neptune](integrations.md).