Utilisation d'Amazon Neptune en tant que cible pour AWS Database Migration Service

Amazon Neptune est un service de base de données orientée graphe entièrement géré et fiable, qui facilite la création et l'exécution d'applications fonctionnant avec des jeux de données hautement connectés. Le cœur de Neptune est un moteur de base de données orientée graphe spécialisé et hautes performances. Ce moteur est optimisé pour le stockage de milliards de relations et l'interrogation du graphe avec une latence de l'ordre de quelques millisecondes. Neptune prend en charge les langages de requête de graphe populaires Apache TinkerPop Gremlin et SPARQL de W3C. Pour plus d'informations sur Amazon Neptune, consultez Qu'est-ce qu'Amazon Neptune ? dans le Guide de l'utilisateur Amazon Neptune.

Sans une base de données orientée graphe telle que Neptune, vous modélisez probablement des données hautement connectées dans une base de données relationnelle. Étant donné que les données ont des connexions potentiellement dynamiques, les applications qui utilisent de telles sources de données doivent modéliser les requêtes de données connectées dans SQL. Cette approche nécessite que vous écriviez une couche supplémentaire pour convertir les requêtes de graphe en SQL. En outre, les bases de données relationnelles sont dotées d'une rigidité de schéma. Toute modification du schéma pour modéliser les connexions changeantes nécessite des temps d'arrêt et une maintenance supplémentaire de la conversion de requête pour prendre en charge le nouveau schéma. Les performances des requêtes sont également une autre contrainte importante à prendre en compte lors de la conception de vos applications.

Les bases de données graphiques peuvent grandement simplifier de telles situations. Libre d'un schéma, une couche de requête graphique enrichie (Gremlin ou SPARQL) et des index optimisés pour les requêtes graphiques augmentent la flexibilité et les performances. La base de données orientée graphe Amazon Neptune comporte également des fonctionnalités d'entreprise telles que le chiffrement au repos, une couche d'autorisation sécurisée, les sauvegardes par défaut, la prise en charge de Multi-AZ, la prise en charge de réplicas en lecture, etc.

À l'aide d'AWS DMS, vous pouvez migrer des données relationnelles qui modélisent un graphe hautement connecté vers un point de terminaison cible Neptune à partir d'un point de terminaison source DMS pour toute base de données SQL prise en charge.

Pour plus de détails, consultez les sections suivantes.

Vue d'ensemble de la migration vers Amazon Neptune en tant que cible

Avant de commencer une migration vers une cible Neptune, créez les ressources suivantes dans votre compte AWS :

• Un cluster Neptune pour le point de terminaison cible.

• Une base de données relationnelle SQL prise en charge par AWS DMS pour le point de terminaison source.

• Un compartiment Amazon S3 pour le point de terminaison cible. Créez ce compartiment S3 dans la même région AWS que votre cluster Neptune. AWS DMS utilise ce compartiment S3 comme stockage de fichiers intermédiaires pour les données cibles qu'il charge en bloc dans la base de données Neptune. Pour plus d'informations sur la création d'un compartiment S3, consultez Créer un compartiment dans le Guide de l'utilisateur Amazon Simple Storage Service.

• Un point de terminaison de cloud privé virtuel (VPC) pour S3 dans le même VPC que le cluster Neptune.

• Rôle AWS Identity and Access Management (IAM) qui inclut une stratégie IAM. Cette stratégie doit spécifier les autorisations GetObject, PutObject, DeleteObject et ListObject pour le compartiment S3 pour votre point de terminaison cible. Ce rôle est assumé par AWS DMS et Neptune avec un accès IAM à la fois au compartiment S3 cible et à la base de données Neptune. Pour de plus amples informations, veuillez consulter Création d'une fonction de service IAM pour l'accès à Amazon Neptune en tant que cible.

Une fois ces ressources disponibles, la configuration et le démarrage d'une migration vers une cible Neptune sont similaires à toute migration de chargement complet à l'aide de la console ou de l'API DMS. Toutefois, une migration vers une cible Neptune nécessite des étapes uniques.

Pour migrer une base de données relationnelle AWS DMS vers Neptune

1. Créez une instance de réplication comme décrit dans Création d'une instance de réplication.

2. Créez et testez une base de données relationnelle SQL prise en charge par AWS DMS pour le point de terminaison source.

3. Créez et testez le point de terminaison cible pour la base de données Neptune.

   Pour connecter le point de terminaison cible à la base de données Neptune, spécifiez le nom du serveur pour le point de terminaison du cluster Neptune ou le point de terminaison de l'instance d'écriture Neptune. Spécifiez également le dossier du compartiment S3 pour AWS DMS afin de stocker ses fichiers intermédiaires en vue d'un chargement en bloc dans la base de données Neptune.

   Pendant la migration, AWS DMS stocke toutes les données cibles migrées dans ce dossier compartiment S3 jusqu'à la taille maximale de fichier que vous spécifiez. Lorsque ce stockage de fichiers atteint cette taille maximale, AWS DMS charge en bloc les données S3 stockées dans la base de données cible. Il efface le dossier pour permettre le stockage de toutes les données cibles supplémentaires pour le chargement ultérieur dans la base de données cible. Pour de plus amples informations sur la spécification de ces paramètres, veuillez consulter Spécification des paramètres de point de terminaison pour Amazon Neptune en tant que cible.

4. Créez une tâche de réplication à chargement complet avec les ressources créées aux étapes 1 à 3 et procédez comme suit :

   1. Utilisez le mappage de tables de tâches comme d'habitude pour identifier des schémas, tables et vues sources spécifiques à migrer depuis votre base de données relationnelle à l'aide de règles de sélection et de transformation appropriées. Pour de plus amples informations, veuillez consulter Utilisation du mappage de table pour spécifier des paramètres de tâche.

   2. Spécifiez les mappages de cible en choisissant l'une des options suivantes pour spécifier les règles de mappage à partir de tables et de vues sources vers votre graphe de base de données cible Neptune :

      • Gremlin JSON : pour en savoir plus sur l'utilisation de Gremlin JSON pour charger une base de données Neptune, consultez Format des données de chargement Gremlin dans le Guide de l'utilisateur Amazon Neptune.

      • SPARQL RDB to Resource Description Framework Mapping Language (R2RML) : pour en savoir plus sur l'utilisation de SPARQL R2RML, consultez la spécification W3C R2RML : langage de mappage RDB à RDF (langue française non garantie).

   3. Effectuez l'une des actions suivantes :

      • À l'aide de la console AWS DMS, spécifiez les options de mappage de graphique en utilisant les règles de mappage de graphique sur la page Créer une tâche de migration de base de données.

      • À l'aide de l'API AWS DMS, spécifiez ces options à l'aide du paramètre de demande TaskData de l'appel d'API CreateReplicationTask.

      Pour de plus amples informations et consulter des exemples utilisant Gremlin JSON et SPARQL R2RML afin de spécifier des règles de mappage graphique, veuillez consulter Spécification de règles de mappage de graphe à l'aide de Gremlin et de R2RML pour Amazon Neptune en tant que cible.

5. Démarrez la réplication de votre tâche de migration.

Spécification des paramètres de point de terminaison pour Amazon Neptune en tant que cible

Pour créer ou modifier un point de terminaison cible, vous pouvez utiliser la console, CreateEndpoint ou les opérations d'API ModifyEndpoint.

Pour une cible Neptune dans la console AWS DMS, spécifiez les Paramètres spécifiques au point de terminaison sur la page Créer un point de terminaison ou Modifier un point de terminaison de la console. Pour CreateEndpoint et ModifyEndpoint, spécifiez les paramètres de demande pour l'option NeptuneSettings. L'exemple suivant montre comment procéder à l'aide de l'interface de ligne de commande.

dms create-endpoint --endpoint-identifier my-neptune-target-endpoint
--endpoint-type target --engine-name neptune 
--server-name my-neptune-db.cluster-cspckvklbvgf.us-east-1.neptune.amazonaws.com 
--port 8192
--neptune-settings 
     '{"ServiceAccessRoleArn":"arn:aws:iam::123456789012:role/myNeptuneRole",
       "S3BucketName":"my-bucket",
       "S3BucketFolder":"my-bucket-folder",
       "ErrorRetryDuration":57,
       "MaxFileSize":100, 
       "MaxRetryCount": 10, 
       "IAMAuthEnabled":false}‘

Ici, l'option --server-name de l'interface CLI spécifie le nom du serveur pour le point de terminaison d'écriture de cluster Neptune. Vous pouvez également spécifier le nom du serveur pour un point de terminaison d'instance d'écriture Neptune.

Les paramètres de demande d'option --neptune-settings sont les suivants :

• ServiceAccessRoleArn : (Obligatoire) Amazon Resource Name (ARN) de la fonction de service que vous avez créée pour le point de terminaison cible Neptune. Pour de plus amples informations, veuillez consulter Création d'une fonction de service IAM pour l'accès à Amazon Neptune en tant que cible.

• S3BucketName : (Obligatoire) nom du compartiment S3 dans lequel DMS peut stocker temporairement des données de graphe migrées dans des fichiers .csv avant de les charger en bloc dans la base de données cible Neptune. DMS mappe les données source SQL aux données de graphique avant de les stocker dans ces fichiers .csv.

• S3BucketFolder : (Obligatoire) chemin d'accès au dossier dans lequel vous souhaitez que DMS stocke les données de graphe migrées dans le compartiment S3 spécifié par S3BucketName.

• ErrorRetryDuration : (Facultatif) nombre de millisecondes pendant lesquelles DMS doit attendre pour réessayer une charge groupée de données de graphe migrées vers la base de données cible Neptune avant de déclencher une erreur. La valeur par défaut est 250.

• MaxFileSize : (Facultatif) taille maximale en Ko de données de graphe migrées stockées dans un fichier .csv avant que DMS charge en bloc les données dans la base de données cible Neptune. La valeur par défaut est de 1 048 576 Ko (1 Go). En cas de succès, DMS efface le compartiment, prêt à stocker le prochain lot de données de graphique migrées.

• MaxRetryCount : (Facultatif) nombre de fois où DMS peut réessayer une charge en bloc de données de graphe migrées vers la base de données cible Neptune avant de déclencher une erreur. La valeur par défaut est 5.

• IAMAuthEnabled : (Facultatif) si vous souhaitez que l'autorisation IAM soit activée pour ce point de terminaison, définissez ce paramètre sur true et attachez le document de politique IAM approprié à votre fonction de service spécifié par ServiceAccessRoleArn. La valeur par défaut est false.

Création d'une fonction de service IAM pour l'accès à Amazon Neptune en tant que cible

Pour accéder à Neptune en tant que cible, créez un rôle de service à l'aide d'IAM. Selon la configuration du point de terminaison Neptune, attachez à ce rôle une partie ou la totalité des documents de politique IAM et d'approbation suivants. Lorsque vous créez le point de terminaison Neptune, vous fournissez l'ARN de cette fonction de service. Cela permet à AWS DMS et Amazon Neptune d'assumer les autorisations d'accès à Neptune et à son compartiment Amazon S3 associé.

Si vous définissez le paramètre IAMAuthEnabled dans NeptuneSettings sur true dans votre configuration de point de terminaison Neptune, attachez une politique IAM telle que la suivante à votre fonction de service. Si vous définissez IAMAuthEnabled sur false, vous pouvez ignorer cette stratégie.

// Policy to access Neptune

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "VisualEditor0",
                "Effect": "Allow",
                "Action": "neptune-db:*",
                "Resource": "arn:aws:neptune-db:us-east-1:123456789012:cluster-CLG7H7FHK54AZGHEH6MNS55JKM/*"
            }
        ]
    }

La politique IAM précédente permet un accès complet au cluster cible Neptune spécifié par Resource.

Joignez une stratégie IAM telle que la suivante à votre rôle de service. Cette stratégie permet à DMS de stocker temporairement des données de graphe migrées dans le compartiment S3 que vous avez créé pour le chargement en bloc dans la base de données cible Neptune.

//Policy to access S3 bucket

{
	"Version": "2012-10-17",
	"Statement": [{
			"Sid": "ListObjectsInBucket0",
			"Effect": "Allow",
			"Action": "s3:ListBucket",
			"Resource": [
				"arn:aws:s3:::my-bucket"
			]
		},
		{
			"Sid": "AllObjectActions",
			"Effect": "Allow",
			"Action": ["s3:GetObject",
				"s3:PutObject",
				"s3:DeleteObject"
			],

			"Resource": [
				"arn:aws:s3:::my-bucket/"
			]
		},
		{
			"Sid": "ListObjectsInBucket1",
			"Effect": "Allow",
			"Action": "s3:ListBucket",
			"Resource": [
				"arn:aws:s3:::my-bucket",
				"arn:aws:s3:::my-bucket/"
			]
		}
	]
}

La politique IAM précédente permet à votre compte d'interroger le contenu du compartiment S3 (arn:aws:s3:::my-bucket) créé pour votre cible Neptune. Elle permet également à votre compte de fonctionner pleinement sur le contenu de tous les fichiers et dossiers de compartiment (arn:aws:s3:::my-bucket/).

Modifiez la relation d'approbation et attachez le rôle IAM suivant à votre fonction de service pour permettre à AWS DMS et au service de base de données Amazon Neptune d'assumer le rôle.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "dms.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "neptune",
      "Effect": "Allow",
      "Principal": {
        "Service": "rds.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Pour en savoir plus sur la spécification de cette fonction de service pour votre point de terminaison cible Neptune, consultez Spécification des paramètres de point de terminaison pour Amazon Neptune en tant que cible.

Spécification de règles de mappage de graphe à l'aide de Gremlin et de R2RML pour Amazon Neptune en tant que cible

Les règles de mappage de graphe que vous créez spécifient comment les données extraites d'une source de base de données relationnelle SQL sont chargées dans une cible de cluster de base de données Neptune. Le format de ces règles de mappage diffère selon que les règles servent à charger des données de graphique de propriétés à l'aide d'Apache TinkerPop Gremlin ou de données RDF (Resource Description Framework) à l'aide de R2RML. Vous trouverez ci-dessous des informations sur ces formats et sur les autres ressources disponibles.

Vous pouvez spécifier ces règles de mappage lorsque vous créez la tâche de migration à l'aide de la console ou de l'API DMS.

À l'aide de la console, spécifiez ces règles de mappage à l'aide des règles de mappage de graphique sur la page Créer une tâche de migration de base de données. Dans Règles de mappage de graphique, vous pouvez entrer et modifier les règles de mappage directement à l'aide de l'éditeur fourni. Vous pouvez également rechercher un fichier contenant les règles de mappage dans le format de mappage de graphique approprié.

À l'aide de l'API, spécifiez ces options à l'aide du paramètre de demande TaskData de l'appel d'API CreateReplicationTask. Définissez TaskData sur le chemin d'accès d'un fichier contenant les règles de mappage dans le format de mappage de graphique approprié.

Règles de mappage de graphique pour générer des données de graphique de propriétés à l'aide de Gremlin

À l'aide de Gremlin pour générer les données du graphique de propriétés, spécifiez un objet JSON avec une règle de mappage pour chaque entité de graphique à générer à partir des données source. Le format de ce code JSON est défini spécifiquement pour charger Amazon Neptune en bloc. Le modèle suivant montre à quoi ressemble chaque règle de cet objet.

{
    "rules": [
        {
            "rule_id": "(an identifier for this rule)",
            "rule_name": "(a name for this rule)",
            "table_name": "(the name of the table or view being loaded)",
            "vertex_definitions": [
                {
                    "vertex_id_template": "{col1}",
                    "vertex_label": "(the vertex to create)",
                    "vertex_definition_id": "(an identifier for this vertex)",
                    "vertex_properties": [
                        {
                            "property_name": "(name of the property)",
                            "property_value_template": "{col2} or text",
                            "property_value_type": "(data type of the property)"
                        }
                    ]
                }
            ]
        },
        {
            "rule_id": "(an identifier for this rule)",
            "rule_name": "(a name for this rule)",
            "table_name": "(the name of the table or view being loaded)",
            "edge_definitions": [
                {
                    "from_vertex": {
                        "vertex_id_template": "{col1}",
                        "vertex_definition_id": "(an identifier for the vertex referenced above)"
                    },
                    "to_vertex": {
                        "vertex_id_template": "{col3}",
                        "vertex_definition_id": "(an identifier for the vertex referenced above)"
                    },
                    "edge_id_template": {
                        "label": "(the edge label to add)",
                        "template": "{col1}_{col3}"
                    },
                    "edge_properties":[
                        {
                            "property_name": "(the property to add)",
                            "property_value_template": "{col4} or text",
                            "property_value_type": "(data type like String, int, double)"
                        }
                    ]
                }
            ]
        }
    ]
}
 

La présence d'une étiquette de sommet implique que le sommet est créé ici. Son absence implique que le sommet est créé par une source différente, et cette définition n'ajoute que des propriétés de sommet. Spécifiez autant de définitions de sommets et de tronçons que nécessaire pour spécifier les mappages pour l'ensemble de la source de base de données relationnelle.

Voici un exemple de règle pour une table employee.

{
    "rules": [
        {
            "rule_id": "1",
            "rule_name": "vertex_mapping_rule_from_nodes",
            "table_name": "nodes",
            "vertex_definitions": [
                {
                    "vertex_id_template": "{emp_id}",
                    "vertex_label": "employee",
                    "vertex_definition_id": "1",
                    "vertex_properties": [
                        {
                            "property_name": "name",
                            "property_value_template": "{emp_name}",
                            "property_value_type": "String"
                        }
                    ]
                }
            ]
        },
        {
            "rule_id": "2",
            "rule_name": "edge_mapping_rule_from_emp",
            "table_name": "nodes",
            "edge_definitions": [
                {
                    "from_vertex": {
                        "vertex_id_template": "{emp_id}",
                        "vertex_definition_id": "1"
                    },
                    "to_vertex": {
                        "vertex_id_template": "{mgr_id}",
                        "vertex_definition_id": "1"
                    },
                    "edge_id_template": {
                        "label": "reportsTo",
                        "template": "{emp_id}_{mgr_id}"
                    },
                    "edge_properties":[
                        {
                            "property_name": "team",
                            "property_value_template": "{team}",
                            "property_value_type": "String"
                        }
                    ]
                }
            ]
        }
    ]
}
 

Ici, les définitions de sommets et de tronçons mappent une relation de reporting à partir d'un nœud employee avec l'ID d'employé (EmpID) et d'un nœud employee avec un ID de responsable (managerId).

Pour plus d'informations sur la création de règles de mappage de graphe à l'aide de Gremlin JSON, consultez Format des données de chargement Gremlin dans le Guide de l'utilisateur Amazon Neptune.

Règles de mappage de graphique pour la génération de données RDF/SPARQL

Si vous chargez des données RDF à interroger à l'aide de SPARQL, écrivez les règles de mappage de graphique dans R2RML. R2RML est un langage W3C standard pour mapper des données relationnelles vers RDF. Dans un fichier R2RML, un mappage de triples (par exemple, <#TriplesMap1> suivant) spécifie une règle pour convertir chaque ligne d'une table logique en zéro ou plusieurs triples RDF. Un mappage de sujet (par exemple, tout élément rr:subjectMap suivant) spécifie une règle pour générer les sujets des triples RDF générés par un mappage de triples. Un mappage prédicat-objet (par exemple, tout élément rr:predicateObjectMap suivant) est une fonction qui crée une ou plusieurs paires prédicat-objet pour chaque ligne de table logique d'une table logique.

Voici un exemple simple de table nodes.

@prefix rr: <http://www.w3.org/ns/r2rml#>.
@prefix ex: <http://example.com/ns#>.

<#TriplesMap1>
    rr:logicalTable [ rr:tableName "nodes" ];
    rr:subjectMap [
        rr:template "http://data.example.com/employee/{id}";
        rr:class ex:Employee;
    ];
    rr:predicateObjectMap [
        rr:predicate ex:name;
        rr:objectMap [ rr:column "label" ];
    ]

Dans l'exemple précédent, le mappage définit des nœuds de graphique mappés à partir d'une table d'employés.

Voici un autre exemple simple de table Student.

@prefix rr: <http://www.w3.org/ns/r2rml#>.
@prefix ex: <http://example.com/#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

<#TriplesMap2>
    rr:logicalTable [ rr:tableName "Student" ];
    rr:subjectMap   [ rr:template "http://example.com/{ID}{Name}";
                      rr:class foaf:Person ];
    rr:predicateObjectMap [
        rr:predicate ex:id ;
        rr:objectMap  [ rr:column "ID";
                        rr:datatype xsd:integer ]
    ];
    rr:predicateObjectMap [
        rr:predicate foaf:name ;
        rr:objectMap  [ rr:column "Name" ]
    ].

Dans l'exemple précédent, le mappage définit des nœuds de graphique qui mappent des relations de type ami d'un ami entre des personnes d'une table Student.

Pour de plus amples informations sur la création de règles de mappage de graphique à l'aide de SPARQL R2RML, veuillez consulter la spécification W3C R2RML : RDB to RDF Mapping Language.

Types de données pour la migration Gremlin et R2RML vers Amazon Neptune en tant que cible

AWS DMS effectue le mappage de type de données du point de terminaison source SQL vers votre cible Neptune de l'une des deux manières suivantes. La solution choisie dépend du format de mappage de graphe que vous utilisez pour charger la base de données Neptune :

• Apache TinkerPop Gremlin, en utilisant une représentation JSON des données de migration.

• SPARQL du W3C, en utilisant une représentation R2RML des données de migration.

Pour de plus amples informations sur ces deux formats de mappage de graphique, veuillez consulter Spécification de règles de mappage de graphe à l'aide de Gremlin et de R2RML pour Amazon Neptune en tant que cible.

Vous trouverez ci-dessous des descriptions des mappages de types de données pour chaque format.

Mappages de type de données cible source SQL vers Gremlin

Le tableau suivant présente les mappages de type de données d'une source SQL vers une cible formatée Gremlin.

AWS DMS mappe tout type de données source SQL non répertorié à un Gremlin String.

Types de données sources SQL	Types de données cibles Gremlin
NUMERIC (et variantes)	Double
DECIMAL
TINYINT	Byte
SMALLINT	Short
INT, INTEGER	Int
BIGINT	Long
FLOAT	Float
DOUBLE PRECISION
REAL	Double
BIT	Boolean
BOOLEAN
DATE	Date
TIME
TIMESTAMP
CHARACTER (et variantes)	String

Pour plus d'informations sur les types de données Gremlin pour le chargement de Neptune, consultez Types de données Gremlin dans le Guide de l'utilisateur Neptune.

Mappages de type de données cible Source SQL vers R2RML (RDF)

Le tableau suivant présente les mappages de types de données d'une source SQL vers une cible formatée R2RML.

Tous les types de données RDF répertoriés sont sensibles à la casse, à l'exception du littéral RDF. AWS DMS mappe tout type de données source SQL non répertorié à un littéral RDF.

Un littéral RDF est l'une des diverses formes lexicales littérales et l'un des différents types de données. Pour de plus amples informations, veuillez consulter Littéraux RDF dans la spécification W3C Resource Description Framework (RDF) : Concepts and Abstract Syntax.

Types de données sources SQL	Types de données cibles R2RML (RDF)
BINARY (et variantes)	xsd:hexBinary
NUMERIC (et variantes)	xsd:decimal
DECIMAL
TINYINT	xsd:integer
SMALLINT
INT, INTEGER
BIGINT
FLOAT	xsd:double
DOUBLE PRECISION
REAL
BIT	xsd:boolean
BOOLEAN
DATE	xsd:date
TIME	xsd:time
TIMESTAMP	xsd:dateTime
CHARACTER (et variantes)	Littéral RDF

Pour plus d'informations sur les types de données RDF pour charger Neptune et leurs mappages aux types de données sources SQL, consultez Conversions de type de données dans la spécification W3C R2RML : langage de mappage RDB à RDF (langue française non garantie).

Limitations de l'utilisation d'Amazon Neptune en tant que cible

Les limitations suivantes s'appliquent lorsque vous utilisez Neptune en tant que cible :

• AWS DMS prend actuellement en charge les tâches de chargement complet uniquement pour la migration vers une cible Neptune. La migration CDC (capture des données de modification) vers une cible Neptune n'est pas prise en charge.

• Assurez-vous d'effacer manuellement toutes les données de la base de données Neptune cible avant de commencer la tâche de migration, comme dans les exemples suivants.

  Pour supprimer toutes les données (sommets et arêtes) dans le graphe, exécutez la commande Gremlin suivante.

  gremlin> g.V().drop().iterate()

  Pour supprimer les sommets portant l'étiquette 'customer', exécutez la commande Gremlin suivante.

  gremlin> g.V().hasLabel('customer').drop()

  Note

  La suppression d'un jeu de données volumineux peut prendre un certain temps. Vous pouvez vouloir itérer drop() avec une limite, par exemple limit(1000).

  Pour supprimer les arêtes portant l'étiquette 'rated', exécutez la commande Gremlin suivante.

  gremlin> g.E().hasLabel('rated').drop()

  Note

  La suppression d'un jeu de données volumineux peut prendre un certain temps. Vous pouvez vouloir itérer drop() avec une limite, par exemple limit(1000).

• L'opération d'API DMS DescribeTableStatistics peut renvoyer des résultats inexacts sur une table donnée en raison de la nature des structures de données de graphe Neptune.

  Pendant la migration, AWS DMS analyse chaque table source et utilise le mappage de graphe pour convertir les données source en graphe Neptune. Les données converties sont d'abord stockées dans le dossier de compartiment S3 spécifié pour le point de terminaison cible. Si la source est analysée et que ces données S3 intermédiaires sont générées avec succès, DescribeTableStatistics suppose que les données ont été chargées avec succès dans la base de données cible Neptune. Mais ce n'est pas toujours vrai. Pour vérifier que les données ont été chargées correctement pour une table donnée, comparez les valeurs count() renvoyées aux deux extrémités de la migration pour cette table.

  Dans l'exemple suivant, AWS DMS a chargé une table customer à partir de la base de données source, à laquelle est affectée l'étiquette 'customer' dans le graphe de base de données Neptune cible. Vous pouvez vous assurer que cette étiquette est écrite dans la base de données cible. Pour ce faire, comparez le nombre de lignes customer disponibles à partir de la base de données source avec le nombre de lignes étiquetées 'customer' chargées dans la base de données cible Neptune une fois la tâche terminée.

  Pour obtenir le nombre de lignes client disponibles à partir de la base de données source à l'aide de SQL, exécutez la procédure suivante.

  select count(*) from customer;

  Pour obtenir le nombre de lignes étiquetées 'customer' chargées dans le graphique de base de données cible à l'aide de Gremlin, exécutez la procédure suivante.

  gremlin> g.V().hasLabel('customer').count()

• Actuellement, si une seule table n'est pas chargée, c'est toute la tâche qui échoue. Contrairement à une cible de base de données relationnelle, les données dans Neptune sont hautement connectées, ce qui rend impossible dans de nombreux cas la reprise d'une tâche. Si une tâche ne peut pas être reprise correctement en raison de ce type d'échec de chargement des données, créez une nouvelle tâche pour charger la table qui n'a pas pu être chargée. Avant d'exécuter cette nouvelle tâche, effacez manuellement la table partiellement chargée de la cible Neptune.

  Note

  Vous pouvez reprendre une tâche dont la migration vers une cible Neptune a échoué si l'échec est récupérable (par exemple, une erreur de transit réseau).

• AWS DMS prend en charge la plupart des normes pour R2RML. Cependant, AWS DMS ne prend pas en charge certaines normes R2RML, y compris les expressions inverses, les jointures et les vues. Une solution de contournement pour une vue R2RML consiste à créer une vue SQL personnalisée correspondante dans la base de données source. Dans la tâche de migration, utilisez le mappage de table pour choisir la vue en tant qu'entrée. Mappez ensuite la vue à une table qui est ensuite consommée par R2RML pour générer des données de graphique.

• Lorsque vous migrez des données sources avec des types de données SQL non pris en charge, les données cibles résultantes peuvent avoir une perte de précision. Pour de plus amples informations, veuillez consulter Types de données pour la migration Gremlin et R2RML vers Amazon Neptune en tant que cible.

• AWS DMS ne prend pas en charge la migration des données LOB dans une cible Neptune.