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