Seleccione sus preferencias de cookies

Usamos cookies esenciales y herramientas similares que son necesarias para proporcionar nuestro sitio y nuestros servicios. Usamos cookies de rendimiento para recopilar estadísticas anónimas para que podamos entender cómo los clientes usan nuestro sitio y hacer mejoras. Las cookies esenciales no se pueden desactivar, pero puede hacer clic en “Personalizar” o “Rechazar” para rechazar las cookies de rendimiento.

Si está de acuerdo, AWS y los terceros aprobados también utilizarán cookies para proporcionar características útiles del sitio, recordar sus preferencias y mostrar contenido relevante, incluida publicidad relevante. Para aceptar o rechazar todas las cookies no esenciales, haga clic en “Aceptar” o “Rechazar”. Para elegir opciones más detalladas, haga clic en “Personalizar”.

Migración de datos de Neo4j a Neptune

Modo de enfoque
Migración de datos 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.

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.

Al realizar una migración de Neo4j a Amazon Neptune, la migración de los datos es un paso importante del proceso. Existen varios métodos para migrar datos. El método correcto viene determinado por las necesidades de la aplicación, el tamaño de los datos y el tipo de migración deseado. Sin embargo, muchas de estas migraciones requieren una evaluación de las mismas consideraciones, algunas de las cuales se destacan a continuación.

nota

Consulte la sección Migración de una base de datos gráfica de Neo4j a Neptune con una utilidad totalmente automatizada en el blog de AWS bases de datos para obtener un step-by-step recorrido completo de un ejemplo de cómo realizar una migración de datos fuera de línea.

Evaluación de la migración de datos de Neo4j a Neptune

El primer paso a la hora de evaluar cualquier migración de datos es determinar cómo se van a migrar los datos. Las opciones dependen de la arquitectura de la aplicación que se va a migrar, del tamaño de los datos y de las necesidades de disponibilidad durante la migración. Por lo general, las migraciones suelen clasificarse en una de las siguientes dos categorías: en línea o sin conexión.

Las migraciones sin conexión suelen ser las más sencillas de realizar, ya que la aplicación no acepta tráfico de lectura o escritura durante la migración. Cuando la aplicación deja de aceptar tráfico, los datos se pueden exportar, optimizar e importar, y la aplicación se puede probar antes de volver a habilitarla.

Las migraciones en línea son más complejas, ya que la aplicación aún necesita aceptar el tráfico de lectura y escritura mientras se migran los datos. Las necesidades exactas de cada migración en línea pueden diferir, pero la arquitectura general suele ser similar a la siguiente:

  • Es necesario habilitar en Neo4j la información sobre los cambios continuos realizados en la base de datos. Para ello, configure Neo4j Streams como fuente de un clúster de Kafka.

  • Una vez hecho esto, se puede realizar una exportación del sistema en ejecución siguiendo las instrucciones de Exportación de datos de Neo4j al migrar a Neptune y el tiempo indicado para luego correlacionarlo con el tema de Kafka.

  • A continuación, los datos exportados se importan a Neptune, siguiendo las instrucciones de Importación de datos de Neo4j al migrar a Neptune.

  • Después, los datos modificados de la transmisión de Kafka se pueden copiar al clúster de Neptune mediante una arquitectura similar a la descrita en Escribir en Amazon Neptune desde Amazon Kinesis Data Streams. Tenga en cuenta que la replicación de los cambios se puede ejecutar en paralelo para validar la nueva arquitectura y el rendimiento de la aplicación.

  • Una vez validada la migración de datos, el tráfico de la aplicación se puede redirigir al clúster de Neptune y se puede retirar la instancia de Neo4j.

Optimizaciones de modelos de datos para migrar de Neo4j a Neptune

Tanto Neptune como Neo4j admiten gráficos de propiedades etiquetadas (LPG). Sin embargo, Neptune presenta algunas diferencias en la arquitectura y el modelo de datos que puede sacar partido para optimizar el rendimiento:

Optimización de nodos y perimetrales IDs

Neo4j genera automáticamente una longitud numérica. IDs Con Cypher, puede hacer referencia a los nodos según su ID, pero, en general, se recomienda buscar los nodos mediante una propiedad indexada.

Neptune te permite suministrar tu propia base de cuerdas IDs para vértices y aristas. Si no proporciona las suyas propias IDs, Neptune genera automáticamente representaciones en cadena de UUIDs cuatro nuevas aristas y vértices.

Si migras datos de Neo4j a Neptuno exportándolos desde Neo4j y luego importándolos masivamente a Neptuno, puedes conservar los de Neo4j. IDs Los valores numéricos generados por Neo4j pueden actuar como los proporcionados por el usuario IDs al importarlos a Neptune, donde se representan como cadenas en lugar de valores numéricos.

Sin embargo, hay circunstancias en las que es posible que desee promover una propiedad de vértice para que se convierta en un ID de vértice. Así como buscar un nodo con una propiedad indexada es la forma más rápida de encontrar un nodo en Neo4j, buscar un vértice según el ID es la forma más rápida de encontrar un vértice en Neptune. Por lo tanto, si puede identificar una propiedad de vértice adecuada que incluya valores únicos, debe plantearse reemplazar el valor ~id del vértice por el valor de propiedad designado en los archivos CSV de carga masiva. Si lo hace, también tendrá que volver a escribir los valores de las bordes ~from y ~to correspondientes en los archivos CSV.

Restricciones del esquema al migrar datos de Neo4j a Neptune

En Neptune, la única restricción de esquema disponible es la exclusividad del ID de un nodo o un borde. Se recomienda a las aplicaciones que necesiten sacar partido de una restricción de exclusividad que utilicen este método para lograr una restricción de exclusividad especificando el identificador del nodo o del borde. Si la aplicación utilizó varias columnas como restricción de exclusividad, el ID puede configurarse en una combinación de estos valores. Por ejemplo, id=123, code='SEA' podría representarse como ID='123_SEA' para lograr una restricción de exclusividad compleja.

Optimización de la dirección de los bordes al migrar datos de Neo4j a Neptune

Cuando se añaden nodos, bordes o propiedades a Neptune, se indexan automáticamente de tres formas diferentes, con un cuarto índice opcional. Debido a la forma en que Neptune crea y usa los índices, las consultas que siguen los bordes salientes son más eficaces que las que usan los bordes entrantes. En cuanto al modelo de almacenamiento de datos de gráficos de Neptune, se trata de búsquedas basadas en temas que utilizan el índice SPOG.

Si, al migrar el modelo de datos y las consultas a Neptune, descubre que las consultas más importantes se basan en atravesar los bordes entrantes donde hay un alto grado de distribución, puede plantearse modificar el modelo para que estos recorridos sigan los bordes salientes, especialmente si no puede especificar las etiquetas de borde que desea atravesar. Para ello, invierta la dirección de los bordes relevantes y actualice las etiquetas de los bordes para que reflejen la semántica de este cambio de dirección. Por ejemplo, podría cambiar:

person_A — parent_of — person_B to: person_B — child_of — person_A

Para realizar este cambio en un archivo CSV de borde de carga masiva, basta con cambiar los encabezados de las columnas ~from y ~to y actualizar los valores de la columna ~label.

Como alternativa a la reversión de la dirección de los bordes, puede habilitar un cuarto índice de Neptune, el índice OSGP, que hace que el proceso de atravesar los bordes entrantes o las búsquedas basadas en objetos sean mucho más eficaces. Sin embargo, si se habilita este cuarto índice, se reducirán las tasas de inserción y se necesitará más espacio de almacenamiento.

Optimización del filtrado al migrar datos de Neo4j a Neptune

Neptune está optimizado para funcionar mejor cuando las propiedades se filtran a la propiedad más selectiva disponible. Cuando se utilizan varios filtros, se busca el conjunto de elementos que coincidan entre ellos y, a continuación, se calcula la superposición de todos estos conjuntos. Cuando es posible, la combinación de varias propiedades en una única propiedad minimiza el número de búsquedas en el índice y reduce la latencia de una consulta.

Por ejemplo, esta consulta utiliza dos búsquedas de índices y una combinación:

MATCH (n) WHERE n.first_name='John' AND n.last_name='Doe' RETURN n

Esta consulta recupera la misma información mediante una única búsqueda de índice:

MATCH (n) WHERE n.name='John Doe' RETURN n

Neptune admite tipos de datos diferentes a los de Neo4j.

Mapeos de tipos de datos de Neo4j a tipos de datos compatibles con Neptune
  • LógicaBoolean

    Asigne este valor en Neptune a Bool o Boolean.

  • NuméricaNumber

    Asigne este valor en Neptune al más estrecho de los siguientes tipos de openCypher de Neptune que puedan admitir todos los valores de la propiedad numérica en cuestión:

    Byte Short Integer Long Float Double
  • TextoString

    Asigne este valor en Neptune a String.

  • Momento específico:

    Date Time LocalTime DateTime LocalDateTime

    Asigne estos valores en Neptune a Date como UTC mediante uno de los siguientes formatos ISO-8601 compatibles con Neptune:

    yyyy-MM-dd yyyy-MM-ddTHH:mm yyyy-MM-ddTHH:mm:ss yyyy-MM-ddTHH:mm:ssZ
  • DuraciónDuration

    Asigne este valor en Neptune a un valor numérico para la aritmética de fechas, si es necesario.

  • EspacialPoint

    Asigne este valor en Neptune a los valores numéricos de los componentes, cada uno de los cuales se convierte en una propiedad independiente, o expréselo como un valor de cadena para que lo interprete la aplicación cliente. Tenga en cuenta que la integración de búsqueda de texto completo de Neptune le permite indexar las propiedades de geolocalización OpenSearch .

Migración de propiedades multivalor de Neo4j a Neptune

Neo4j permite almacenar listas homogéneas de tipos sencillas como propiedades tanto de los nodos como de los bordes. Estas listas pueden incluir valores duplicados.

Sin embargo, Neptune solo permite una cardinalidad en conjuntos o única para las propiedades de los vértices y una cardinalidad única para las propiedades de los bordes en los datos de gráficos de propiedades. Como resultado, no existe una migración directa de las propiedades de la lista de nodos de Neo4j que incluyan valores duplicados en las propiedades de los vértices de Neptune, ni de las propiedades de la lista de relaciones de Neo4j en las propiedades de los bordes de Neptune.

Algunas posibles estrategias para migrar propiedades de nodos multivalor de Neo4j con valores duplicados a Neptune son las siguientes:

  • Descarte los valores duplicados y convierta la propiedad del nodo multivalor de Neo4j en una propiedad de vértice de Neptune de cardinalidad en conjuntos. Tenga en cuenta que es posible que el conjunto de Neptune no refleje el orden de los elementos de la propiedad multivalor original de Neo4j.

  • Convierta la propiedad de nodo multivalor de Neo4j en una representación de cadena de una lista con formato JSON en una propiedad de cadena de vértices de Neptune.

  • Extraiga cada uno de los valores de propiedad multivalor en un vértice independiente con una propiedad de valor y conecte esos vértices al vértice principal mediante un borde etiquetado con el nombre de la propiedad.

Asimismo, algunas posibles estrategias para migrar propiedades de relaciones multivalor de Neo4j en Neptune son las siguientes:

  • Convierta la propiedad de relación multivalor de Neo4j en una representación de cadena de una lista con formato JSON en una propiedad de cadena de bordes de Neptune.

  • Refactorice la relación Neo4j en los bordes entrantes y salientes de Neptune asociados a un vértice intermedio. Extraiga cada uno de los valores de propiedad de relación multivalor en un vértice independiente con una propiedad de valor y conecte esos vértices al vértice intermedio mediante un borde etiquetado con el nombre de la propiedad.

Tenga en cuenta que la representación en cadena de una lista con formato JSON es opaca para el lenguaje de consultas de openCypher, aunque openCypher incluye un predicado CONTAINS que permite realizar búsquedas sencillas dentro de los valores de cadena.

Exportación de datos de Neo4j al migrar a Neptune

Al exportar datos de Neo4j, utilice los procedimientos de APOC para exportar a CSV o a GraphML. Aunque es posible exportar a otros formatos, existen herramientas de código abierto para convertir los datos CSV exportados desde Neo4j al formato de carga masiva Neptune, y también herramientas de código abierto para convertir los datos de GraphML exportados de Neo4j al formato de carga masiva de Neptune.

También puede exportar los datos directamente a Amazon S3 mediante los distintos procedimientos de APOC. La exportación a un bucket de Amazon S3 está deshabilitada de forma predeterminada, pero se puede habilitar mediante los procedimientos destacados en Exportación a Amazon S3 en la documentación sobre APOC de Neo4j.

Importación de datos de Neo4j al migrar a Neptune

Puede importar datos a Neptune mediante el programa de carga masiva de Neptune o mediante la lógica de la aplicación en un lenguaje de consulta compatible, como, por ejemplo, openCypher.

El programa de carga masiva de Neptune es el método preferido para importar grandes cantidades de datos, ya que proporciona un rendimiento de importación optimizado si se siguen las prácticas recomendadas. El programa de carga masiva admite dos formatos CSV diferentes, a los que los datos exportados desde Neo4j se pueden convertir con las utilidades de código abierto mencionadas anteriormente en la sección Exportación de datos.

También puede usar openCypher para importar datos con una lógica personalizada con el fin de analizarlos, transformarlos e importarlos. Puede enviar las consultas de openCypher a través del punto de conexión de HTTPS (lo que se recomienda) o mediante el controlador de Bolt.

PrivacidadTérminos del sitioPreferencias de cookies
© 2025, Amazon Web Services, Inc o sus afiliados. Todos los derechos reservados.