Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Preparación para migrar de Neo4j a Neptune
La migración de la base de datos de gráficos Neo4j al servicio de base de datos de gráficos de Neptune se puede abordar de dos maneras principales: reconfigurando la plataforma o refactorizándola o rediseñando la arquitectura. El enfoque de replataforma implica modificar el modelo de datos y la arquitectura de aplicaciones existentes para aprovechar mejor las capacidades de Neptuno, mientras que el enfoque de refactorización se centra en encontrar componentes equivalentes en Neptuno para crear una implementación comparable. En la práctica, a menudo se utiliza una combinación de estas estrategias, ya que el proceso de migración implica equilibrar la arquitectura de Neptune objetivo con las restricciones y requisitos de la implementación existente de Neo4j. Independientemente del enfoque, la clave es trabajar de forma retrospectiva a partir de los casos de uso de la aplicación para diseñar el modelo de datos, las consultas y la arquitectura general que mejor se adapten a sus necesidades.
Métodos relacionados con la migración
Al migrar una aplicación de Neo4j a Neptune, recomendamos una de estas dos estrategias: redefinir la plataforma o refactorizar/rediseñar la arquitectura. Para obtener más información sobre las estrategias de migración, consulte Seis estrategias para migrar aplicaciones a la nube
El enfoque de cambio de plataforma, también denominado lift-tinker-and-shift, implica los siguientes pasos:
Identificar los casos de uso para los que la aplicación está diseñada.
Modificar el modelo de datos de gráficos y la arquitectura de la aplicación existentes para abordar mejor estas necesidades de carga de trabajo con las capacidades de Neptune.
Determinar cómo migrar los datos, las consultas y otras partes de la aplicación de origen al modelo y la arquitectura de destino.
Este método de empezar por el final le permite migrar su aplicación al tipo de solución de Neptune que podría diseñar si se tratara de un proyecto completamente nuevo.
El método de refactorización, por el contrario, implica:
Identificar los componentes de la implementación existente, incluidos la infraestructura, los datos, las consultas y las capacidades de las aplicaciones.
Encontrar equivalentes en Neptune que puedan usarse para crear una implementación comparable.
Este método de empezar por el principio busca cambiar una implementación por otra.
En la práctica, es probable que adopte una combinación de estos dos métodos. Puede comenzar con un caso de uso, diseñar la arquitectura de Neptune de destino, pero luego pasar a la implementación existente de Neo4j para identificar las restricciones e invariables que tendrá que mantener. Por ejemplo, puede que tenga que seguir integrándose con otros sistemas externos o seguir ofreciendo aplicaciones gráficas específicas APIs para los usuarios. Con esta información, puede determinar qué datos ya existen para pasarlos al modelo de destino y cuáles deben proceder de otro lugar.
En otros casos, podría empezar por analizar una parte específica de la implementación de Neo4j como el mejor origen de información sobre el trabajo al que está destinada la aplicación. Ese tipo de arqueología en la aplicación existente puede ayudar a definir un caso de uso que luego se pueda diseñar con el fin de sacar partido de las capacidades de Neptune.
Ya sea que esté creando una nueva aplicación con Neptune o migrando una aplicación existente desde Neo4j, le recomendamos empezar por el final a partir de los casos de uso para diseñar un modelo de datos, un conjunto de consultas y una arquitectura de aplicaciones que aborde las necesidades de su empresa.
