Migración de aplicaciones de Neo4j a Neptune - Amazon Neptune

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.

Migración de aplicaciones de Neo4j a Neptune

Una vez que haya migrado los datos de Neo4j a Neptune, el siguiente paso es migrar la propia aplicación. Al igual que con los datos, existen varios métodos para migrar la aplicación en función de las herramientas que utilice, los requisitos, las diferencias arquitectónicas, etc. A continuación, se describen los aspectos que normalmente es necesario tener en cuenta en este proceso.

Migración de conexiones al migrar de Neo4j a Neptune

Si actualmente no utiliza los controladores Bolt, o si desea utilizar una alternativa, puede conectarse al punto de conexión de HTTPS, que proporciona acceso total a los datos devueltos.

Si tiene una aplicación que usa el protocolo Bolt, puede migrar estas conexiones a Neptune y permitir que las aplicaciones se conecten con los mismos controladores que utilizó en Neo4j. Para conectarse a Neptune, es posible que deba realizar uno o varios de estos cambios en la aplicación:

  • Será necesario actualizar la URL y el puerto para usar los puntos de conexión y el puerto del clúster (el valor predeterminado es 8182).

  • Neptune requiere que todas las conexiones usen SSL, por lo que debe especificar que cada conexión esté cifrada.

  • Neptune administra la autenticación mediante la asignación de roles y políticas de IAM. Los roles y políticas de IAM proporcionan un nivel extremadamente flexible de administración de usuarios dentro de la aplicación, por lo que es importante leer y comprender la Información general de IAM antes de configurar el clúster.

  • Las conexiones de Bolt se comportan de manera diferente en Neptune que en Neo4j de varias maneras, tal y como se explica en Comportamiento de conexión de Bolt en Neptune.

  • Puede encontrar más información y sugerencias en Mejores prácticas de Neptune con openCypher un perno.

Hay ejemplos de código de lenguajes de uso común, como Java, Python, .NET y NodeJS, y para escenarios de conexión, como, por ejemplo, el uso de la autenticación de IAM, en Uso del protocolo Bolt para realizar openCypher consultas a Neptune.

Enrutamiento de consultas a instancias de clúster al pasar de Neo4j a Neptune

Las aplicaciones cliente de Neo4j utilizan un controlador de enrutamiento y especifican un modo de acceso para enrutar las solicitudes de lectura y escritura a un servidor adecuado en un clúster causal.

Al migrar una aplicación cliente a Neptune, utilice los puntos de conexión de Neptune para enrutar las consultas de forma eficaz a una instancia adecuada del clúster:

  • Todas las conexiones a Neptune deben utilizar bolt:// en lugar de bolt+routing:// o neo4j:// en la URL.

  • El punto de conexión del clúster se conecta a la instancia principal actual del clúster. Utilice el punto de conexión del clúster para dirigir las solicitudes de escritura al principal.

  • El punto de conexión del lector distribuye las conexiones entre instancias de lectura de réplica del clúster. Si tiene un clúster de instancia única sin instancias de réplica de lectura, el punto de conexión del lector se conecta a la instancia principal, que admite operaciones de escritura. Si el clúster incluye una o varias instancias de réplica de lectura, el envío de una solicitud de escritura al punto de conexión del lector genera una excepción.

  • Cada instancia del clúster también puede tener su propio punto de conexión de instancia. Utilice un punto de conexión de instancia si la aplicación cliente necesita enviar una solicitud a una instancia específica del clúster.

Para obtener más información, consulte Consideraciones sobre puntos de conexión de Neptune.

Coherencia de datos en Neptune

Cuando se utilizan clústeres causales de Neo4j, las réplicas de lectura acaban siendo coherentes con los servidores principales, pero las aplicaciones cliente pueden garantizar la coherencia causal mediante el encadenamiento causal. El encadenamiento causal implica pasar marcadores entre transacciones, lo que permite a una aplicación cliente escribir en un servidor principal y, a continuación, leer su propia escritura desde una réplica de lectura.

En Neptune, las instancias de lectura de réplica son finalmente coherentes con las del escritor, con un retraso de réplica que suele ser inferior a 100 milisegundos. Sin embargo, hasta que se haya replicado un cambio, las actualizaciones de los bordes y vértices existentes y las adiciones de bordes y vértices nuevos no estarán visibles en una instancia de réplica. Por lo tanto, si la aplicación necesita coherencia inmediata en Neptune al leer cada escritura, utilice el punto de conexión del clúster para la operación de lectura después de escritura. Esta es la única vez que se puede usar el punto de conexión del clúster para operaciones de lectura. En todas las demás circunstancias, utilice el punto de conexión del lector para las lecturas.

Migración de consultas de Neo4j a Neptune

Si bien la compatibilidad con openCypher de Neptune reduce drásticamente la cantidad de trabajo necesaria para migrar las consultas desde Neo4j, aún hay que evaluar algunas diferencias a la hora de migrar:

  • Tal y como se ha mencionado anteriormente en Optimizaciones de modelos de datos, es posible que deba realizar modificaciones en el modelo de datos para crear un modelo de datos de gráficos optimizado para Neptune, lo que a su vez requerirá cambios en sus consultas y pruebas.

  • Neo4j ofrece una variedad de extensiones de lenguaje específicas de Cypher que no se incluyen en la especificación de openCypher implementada por Neptune. Según el caso de uso y la característica utilizada, puede haber soluciones alternativas en el lenguaje de openCypher, en el lenguaje de Gremlin o mediante otros mecanismos, tal y como se describe en Reescritura de consultas de Cypher para ejecutarlas en openCypher en Neptune.

  • Las aplicaciones suelen utilizar otros componentes de middleware para interactuar con la base de datos en lugar de los propios controladores Bolt. Eche un vistazo a Compatibilidad de Neptune con Neo4j para ver si las herramientas o el middleware que está utilizando son compatibles.

  • En el caso de una conmutación por error, es posible que el controlador Bolt siga conectándose a la instancia anterior de escritor o lector, ya que el punto de conexión del clúster proporcionado a la conexión se ha resuelto en una dirección IP. Una gestión adecuada de los errores en la aplicación debería solucionar este problema, tal y como se describe en Cree una nueva conexión después de una conmutación por error.

  • Cuando las transacciones se cancelan debido a conflictos que no se pueden resolver o a tiempos de espera de bloqueo, Neptune responde con un ConcurrentModificationException. Para obtener más información, consulte Códigos de error del motor. Como práctica recomendada, los clientes siempre deben detectar y gestionar estas excepciones.

    En ocasiones, se produce una ConcurrentModificationException cuando varios subprocesos o varias aplicaciones escriben en el sistema de forma simultánea. Dados los niveles de aislamiento de las transacciones, estos conflictos a veces pueden ser inevitables.

  • Neptune permite ejecutar tanto consultas de Gremlin como de openCypher en los mismos datos. Esto significa que, en algunos casos, puede que tenga que plantearse utilizar Gremlin, con sus capacidades de consulta más potentes, para realizar algunas de las funciones de sus consultas.

Tal y como se ha explicado anteriormente en Aprovisionamiento de la infraestructura, cada aplicación debe realizar un ejercicio de dimensionamiento adecuado para garantizar que la cantidad de instancias, los tamaños de las instancias y la topología del clúster estén optimizados para la carga de trabajo específica de la aplicación.

Los aspectos que se tratan aquí para migrar la aplicación son los más comunes, pero esta no es una lista exhaustiva. Cada aplicación es única. Si tiene más preguntas, póngase en contacto con AWS Support o con el equipo de cuentas.

Migración de características y herramientas específicas de Neo4j

Neo4j tiene una variedad de características y complementos personalizados con una funcionalidad en la que la aplicación puede confiar. Al evaluar la necesidad de migrar esta funcionalidad, suele ser útil investigar si existe un método mejor en AWS para lograr el mismo objetivo. Teniendo en cuenta las diferencias arquitectónicas entre Neo4j y Neptune, a menudo se pueden encontrar alternativas eficaces que saquen partido de otros servicios de AWS o integraciones.

Consulte Compatibilidad de Neptune con Neo4j para obtener una lista de las características específicas de Neo4j y las soluciones alternativas sugeridas.