Migration des données de Neo4j vers Neptune - Amazon Neptune
Évaluation de la migration des donnéesOptimisations des modèles de donnéesExportation de donnéesImportation de données

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migration des données de Neo4j vers Neptune

Lorsque vous effectuez une migration de Neo4j vers Amazon Neptune, la migration des données constitue une étape majeure du processus. Plusieurs approches permettent de migrer des données. L'approche appropriée est déterminée par les besoins de l'application, la taille des données et le type de migration souhaité. Cependant, bon nombre de ces migrations nécessitent l'évaluation des mêmes considérations, dont plusieurs sont soulignées ci-dessous.

Note

Consultez la section sur la migration d'une base de données orientée graphe de Neo4j vers Neptune à l'aide d'un utilitaire entièrement automatisé dans le blog sur les bases de données AWS pour voir une présentation détaillée d'un exemple de migration de données hors connexion.

Évaluation de la migration des données de Neo4j vers Neptune

Lors de l'évaluation d'une migration de données, la première étape consiste à déterminer la manière dont vous allez migrer les données. Les options dépendent de l'architecture de l'application à migrer, de la taille des données et des besoins de disponibilité pendant la migration. En général, les migrations se répartissent dans l'une des deux catégories suivantes : en ligne ou hors ligne.

Les migrations hors ligne sont généralement les plus simples à réaliser, car l'application n'accepte pas le trafic de lecture ou d'écriture pendant la migration. Une fois que l'application cesse d'accepter le trafic, les données peuvent être exportées, optimisées et importées, et l'application peut être testée avant sa réactivation.

Les migrations en ligne sont plus complexes, car l'application doit continuer à accepter le trafic de lecture et d'écriture pendant la migration des données. Les besoins exacts de chaque migration en ligne peuvent différer, mais l'architecture générale est souvent similaire à la suivante :

Optimisations des modèles de données pour la migration de Neo4j vers Neptune

Neptune et Neo4j prennent tous deux en charge les graphes de propriétés étiquetés (LPG). Neptune présente toutefois certaines différences d'architecture et de modèle de données dont vous pouvez tirer parti pour optimiser les performances :

Optimisation des ID de nœud et d'arête

Neo4j génère automatiquement de longs ID numériques. Avec Cypher, vous pouvez faire référence aux nœuds par ID, mais cela est généralement déconseillé au profit d'une recherche des nœuds en fonction d'une propriété indexée.

Neptune vous permet de fournir vos propres ID basés sur des chaînes pour les sommets et les arêtes. Si vous ne fournissez pas vos propres ID, Neptune génère automatiquement des représentations sous forme de chaînes d'UUID pour les nouvelles arêtes et les nouveaux sommets.

Si vous migrez des données de Neo4j vers Neptune en les exportant depuis Neo4j, puis en les important en bloc dans Neptune, vous pouvez conserver les ID de Neo4j. Les valeurs numériques générées par Neo4j peuvent servir d'ID fournis par l'utilisateur lors de l'importation dans Neptune, où elles sont représentées sous forme de chaînes plutôt que de valeurs numériques.

Toutefois, dans certaines circonstances, il peut être utile de convertir une propriété de sommet en ID de sommet. Tout comme la recherche d'un nœud à l'aide d'une propriété indexée est le moyen le plus rapide de trouver un nœud dans Neo4j, la recherche d'un sommet par ID est le moyen le plus rapide de trouver un sommet dans Neptune. Par conséquent, si vous pouvez identifier une propriété de sommet appropriée contenant des valeurs uniques, envisagez de remplacer la valeur ~id du sommet par la valeur de propriété désignée dans les fichiers CSV de chargement en bloc. Dans ce cas, vous devrez également réécrire les valeurs d'arête ~from et ~to correspondantes dans les fichiers CSV.

Contraintes de schéma lors de la migration de données de Neo4j vers Neptune

Dans Neptune, la seule contrainte de schéma disponible est l'unicité de l'ID d'un nœud ou d'une arête. Les applications qui doivent utiliser une contrainte d'unicité sont invitées à envisager cette approche pour obtenir une contrainte d'unicité en spécifiant l'ID du nœud ou de l'arête. Si l'application utilisait plusieurs colonnes comme contrainte d'unicité, l'ID peut être défini sur une combinaison de ces valeurs. Par exemple, id=123, code='SEA' peut être représenté parID='123_SEA') pour obtenir une contrainte d'unicité complexe.

Optimisation de la direction des arêtes lors de la migration de données de Neo4j vers Neptune

Lorsque des nœuds, des arêtes ou des propriétés sont ajoutés à Neptune, ils sont automatiquement indexés de trois manières différentes, avec un quatrième index facultatif. En raison de la façon dont Neptune crée et utilise les index, les requêtes qui suivent les arêtes sortantes sont plus efficaces que celles qui utilisent des arêtes entrantes. En ce qui concerne le modèle de stockage de données de graphe de Neptune, il s'agit de recherches thématiques qui utilisent l'index SPOG.

Si, lors de la migration de votre modèle de données et de vos requêtes vers Neptune, vous constatez que vos requêtes les plus importantes reposent sur la traversée des arêtes entrantes où il existe un fort degré de distribution ramifiée, vous pouvez envisager de modifier votre modèle afin que ces traversées suivent plutôt les arêtes sortantes, en particulier lorsque vous ne pouvez pas spécifier les étiquettes d'arête à traverser. Pour ce faire, inversez la direction des arêtes concernées et mettez à jour les étiquettes des arêtes afin de refléter la sémantique de ce changement de direction. Par exemple, vous pouvez effectuer la modification suivante :

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

Pour effectuer cette modification dans un fichier CSV d'arêtes à chargement en bloc, il suffit d'échanger les en-têtes de colonne ~from et ~to, et de mettre à jour les valeurs de la colonne ~label.

Au lieu d'inverser la direction des arêtes, vous pouvez activer un quatrième index Neptune, l'index OSGP, qui rend la traversée des arêtes entrantes (ou les recherches basées sur des objets) beaucoup plus efficace. Cependant, l'activation de ce quatrième index réduit les taux d'insertion et nécessite davantage de stockage.

Optimisation du filtrage lors de la migration de données de Neo4j vers Neptune

Neptune est optimisé pour fonctionner au mieux lorsque les propriétés sont filtrées en fonction de la propriété la plus sélective disponible. Lorsque plusieurs filtres sont utilisés, l'ensemble de résultats correspondants est trouvé pour chacun de ces filtres, puis le chevauchement de tous les ensembles correspondants est calculé. Lorsque cela est possible, la combinaison de plusieurs propriétés en une seule permet de minimiser le nombre de recherches d'index et de réduire la latence d'une requête.

Par exemple, cette requête utilise deux recherches d'index et une jointure :

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

Cette requête récupère les mêmes informations en utilisant une seule recherche d'index :

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

Neptune prend en charge différents types de données que Neo4j.

Mappages des types de données Neo4j dans les types de données pris en charge par Neptune

  • Logique :   Boolean

    Mappez cette valeur dans Neptune avec Bool ou Boolean.

  • Numérique :   Number

    Mappez cette valeur dans Neptune avec le type Neptune openCypher suivant le plus proche pouvant prendre en charge toutes les valeurs de la propriété numérique en question :

      Byte
  Short
  Integer
  Long
  Float
  Double

  • Text :   String

    Mappez cette valeur dans Neptune avec String.

  • Point dans le temps :

      Date
  Time
  LocalTime
  DateTime
  LocalDateTime

    Mappez ces éléments dans Neptune avec Date au format UTC en utilisant l'un des formats ISO-8601 suivants pris en charge par Neptune :

      yyyy-MM-dd
  yyyy-MM-ddTHH:mm
  yyyy-MM-ddTHH:mm:ss
  yyyy-MM-ddTHH:mm:ssZ

  • Durée : Duration

    Mappez cette valeur dans Neptune avec une valeur numérique pour l'arithmétique des dates, si nécessaire.

  • Spatial :   Point

    Mappez cette valeur dans Neptune avec les valeurs numériques des composants, chacune d'elles devenant alors une propriété distincte, ou exprimez-la sous forme de valeur de chaîne à interpréter par l'application cliente. Notez que l'intégration Neptune de la recherche en texte intégral à l'aide d'OpenSearch vous permet d'indexer les propriétés de géolocalisation.

Migration des propriétés à valeurs multiples de Neo4j vers Neptune

Neo4j permet de stocker des listes homogènes de types simples en tant que propriétés des nœuds et des arêtes. Ces listes peuvent contenir des valeurs en double.

Neptune n'autorise toutefois qu'une cardinalité définie ou unique pour les propriétés des sommets, et une cardinalité unique pour les propriétés des arêtes dans les données des graphes de propriétés. Par conséquent, il n'y a pas de migration directe des propriétés de liste de nœuds Neo4j contenant des valeurs dupliquées vers des propriétés de sommet Neptune ni de migration directe des propriétés de liste de relations Neo4j vers des propriétés d'arête Neptune.

Voici quelques stratégies possibles pour migrer les propriétés des nœuds à valeurs multiples Neo4j avec des valeurs en double dans Neptune :

  • Supprimez les valeurs en double et convertissez la propriété du nœud Neo4j à valeurs multiples en propriété de sommet Neptune à cardinalité définie. Notez que l'ensemble Neptune peut ne pas refléter l'ordre des éléments dans la propriété Neo4j à valeurs multiples d'origine.

  • Convertissez la propriété du nœud Neo4j à valeurs multiples en une représentation sous forme de chaîne d'une liste au format JSON dans une propriété de chaîne de sommet Neptune.

  • Extrayez chacune des valeurs de propriété à valeurs multiples dans un sommet distinct doté d'une propriété de valeur, et connectez ces sommets au sommet parent à l'aide d'une arête portant le nom de la propriété.

De même, les stratégies possibles pour migrer les propriétés des relations Neo4j à valeurs multiples vers Neptune sont les suivantes :

  • Convertissez la propriété de relation Neo4j à valeurs multiples en une représentation sous forme de chaîne d'une liste au format JSON et stockez-la en tant que propriété de chaîne d'arête Neptune.

  • Refactorisez la relation Neo4j en arêtes Neptune entrantes et sortantes attachées à un sommet intermédiaire. Extrayez chacune des valeurs de propriété de relation à valeurs multiples dans un sommet distinct doté d'une propriété de valeur et connectez ces sommets au sommet intermédiaire à l'aide d'une arête portant le nom de la propriété.

Notez qu'une représentation sous forme de chaîne d'une liste au format JSON est opaque pour le langage de requête openCypher, bien qu'openCypher comprenne un prédicat CONTAINS qui permet des recherches simples dans des valeurs de chaîne.

Exportation de données à partir de Neo4j lors de la migration vers Neptune

Lorsque vous exportez des données à partir de Neo4j, utilisez les procédures APOC pour les exporter au format CSV ou GraphML. Bien qu'il soit possible d'exporter les données dans d'autres formats, il existe des outils open source pour convertir les données CSV exportées de Neo4j dans le format de chargement en bloc Neptune, ainsi que des outils open source pour convertir les données GraphML exportées de Neo4j dans le format de chargement en bloc Neptune.

Vous pouvez également exporter des données directement dans Amazon S3 à l'aide des différentes procédures APOC. L'exportation vers un compartiment Amazon S3 est désactivée par défaut, mais elle peut être activée à l'aide des procédures décrites dans la section Exportation dans Amazon S3 dans la documentation APOC de Neo4j.

Importation de données à partir de Neo4j lors de la migration vers Neptune

Vous pouvez importer des données dans Neptune en utilisant soit le chargeur en bloc Neptune, soit la logique de l'application dans un langage de requête compatible tel qu'openCypher.

Le chargeur en bloc Neptune est l'approche préférée pour importer de grandes quantités de données, car il fournit des performances d'importation optimisées si vous suivez les bonnes pratiques. Le chargeur en bloc prend en charge deux formats CSV différents, dans lesquels les données exportées à partir de Neo4j peuvent être converties à l'aide des utilitaires open source mentionnés ci-dessus dans la section Exportation de données.

Vous pouvez également utiliser openCypher pour importer des données avec une logique personnalisée pour l'analyse, la transformation et l'importation. Vous pouvez envoyer les requêtes openCypher soit via le point de terminaison HTTPS (ce qui est recommandé), soit en utilisant le pilote Bolt.