Utilisation d'Oracle NoSQL Database Migrator

Découvrez Oracle NoSQL Database Migrator et comment l'utiliser pour la migration de données.

Oracle NoSQL Database Migrator est un outil qui vous permet de migrer des tables Oracle NoSQL d'une source de données à une autre. Cet outil peut fonctionner sur des tables avec Oracle NoSQL Database Cloud Service, Oracle NoSQL Database sur place et AWS S3. L'outil Migrator prend en charge plusieurs formats de données et types de média physique différents. Les formats de données pris en charge sont JSON, Parquet, JSON au format MongoDB, JSON au format DynamoDB et des fichiers CSV. Les types de média physique pris en charge sont les fichiers, le service de stockage d'objets pour OCI, Oracle NoSQL Database sur place, Oracle NoSQL Database Cloud Service et AWS S3.

Cet article contient les rubriques suivantes :

Aperçu

Oracle NoSQL Database Migrator vous permet de déplacer les tables Oracle NoSQL d'une source de données à une autre, telle qu'Oracle NoSQL Database sur place ou en nuage ou même un fichier JSON simple.

De nombreuses situations peuvent vous obliger à migrer des tables NoSQL depuis ou vers une base de données Oracle NoSQL Database. Par exemple, une équipe de développeurs qui améliorent une application NoSQL Database pourrait vouloir tester leur code mis à jour dans l'instance locale d'Oracle NoSQL Database Cloud Service (NDCS) à l'aide de cloudsim. Pour vérifier tous les scénarios de test possibles, ils doivent définir les données de test de la même manière que les données réelles. Pour ce faire, ils doivent copier les tables NoSQL de l'environnement de production vers leur instance NDCS locale, l'environnement cloudim. Dans une autre situation, les développeurs NoSQL peuvent avoir besoin de déplacer leurs données d'application de leur environnement sur place vers le nuage, et vice versa, pour le développement ou les tests.

Dans tous ces cas, et bien d'autres, vous pouvez utiliser Oracle NoSQL Database Migrator pour déplacer les tables NoSQL d'une source de données à une autre, telle qu'Oracle NoSQL Database sur place ou en nuage ou même un fichier JSON simple. Vous pouvez également copier des tables NoSQL à partir d'un fichier d'entrée JSON au format MongoDB, d'un fichier d'entrée JSON au format DynamoDB (stocké dans la source AWS S3 ou à partir de fichiers), ou d'un fichier CSV dans votre base de données NoSQL sur place ou en nuage.

Comme illustré dans la figure suivante, l'utilitaire NoSQL Database Migrator agit comme un connecteur ou un tuyau entre la source de données et la cible (appelé évier). Essentiellement, cet utilitaire exporte les données de la source sélectionnée et les importe dans le puits. Cet outil est orienté table, c'est-à-dire que vous ne pouvez déplacer les données qu'au niveau table. Une seule tâche de migration fonctionne sur une seule table et prend en charge la migration des données de table de la source vers le puits dans différents formats de données.

Oracle NoSQL Database Migrator est conçu de manière à pouvoir prendre en charge des sources et des puits supplémentaires à l'avenir. Pour obtenir la liste des sources et des puits pris en charge par Oracle NoSQL Database Migrator à partir de la version courante, voir Sources et puits pris en charge. Description de l'image ci-dessous

Description de l'illustration migrator_overview.png

Terminologie utilisée avec Oracle NoSQL Database Migrator

En savoir plus sur les différents termes utilisés dans le diagramme ci-dessus.

L'outil NoSQL Database Migrator prend en charge différents types de sources et de puits (médias physiques ou référentiels de données) et formats de données (c'est-à-dire comment les données sont représentées dans la source ou le puits). Les formats de données pris en charge sont JSON, Parquet, JSON au format MongoDB, JSON au format DynamoDB et des fichiers CSV. Les types de source et de récepteur pris en charge sont les fichiers, le service de stockage d'objets pour OCI, Oracle NoSQL Database sur place et Oracle NoSQL Database Cloud Service.

Note : Comme le fichier JSON est sensible à la casse, tous les paramètres définis dans le fichier de configuration sont sensibles à la casse, sauf indication contraire.

Sources et récepteurs pris en charge

Cette rubrique fournit la liste des sources et des puits pris en charge par Oracle NoSQL Database Migrator.

Vous pouvez utiliser n'importe quelle combinaison d'une source et d'un récepteur valides de cette table pour l'activité de migration. Toutefois, vous devez vous assurer qu'au moins une des extrémités, c'est-à-dire la source ou l'évier, doit être un produit Oracle NoSQL. Vous ne pouvez pas utiliser NoSQL Database Migrator pour déplacer les données de table NoSQL d'un fichier à un autre.

Type (value) Format (valeur) Source valide Lavabo valide
Oracle NoSQL Database (nosqldb) S.O. Y Y
Oracle NoSQL Database Cloud Service (nosqldb_cloud) S.O. Y Y
Système de fichiers (file) JSON (json) Y Y
Système de fichiers (file) MongoDB JSON (mongodb_json) Y N
Système de fichiers (file) DynamoDB JSON (dynamodb_json) Y N
Système de fichiers (file) Parquet (parquet) N Y
Système de fichiers (file) CSV (csv) Y N
Service de stockage d'objets pour OCI (object_storage_oci) JSON (json) Y Y
Service de stockage d'objets pour OCI (object_storage_oci) MongoDB JSON (mongodb_json) Y N
Service de stockage d'objets pour OCI (object_storage_oci) Parquet (parquet) N Y
Service de stockage d'objets pour OCI (object_storage_oci) CSV (csv) Y N
AWS S3 DynamoDB JSON (dynamodb_json) Y N

Note : De nombreux paramètres de configuration sont communs à la configuration de la source et du récepteur. Pour plus de facilité de référence, la description de ces paramètres est répétée pour chaque source et évier dans les sections de documentation, qui expliquent les formats de fichier de configuration pour différents types de sources et éviers. Dans tous les cas, la syntaxe et la sémantique des paramètres portant le même nom sont identiques.

Sécurité des sources et des récepteurs

Certains types de source et d'évier contiennent des informations de sécurité facultatives ou obligatoires à des fins d'authentification.

Toutes les sources et tous les puits qui utilisent des services dans Oracle Cloud Infrastructure (OCI) peuvent utiliser certains paramètres pour fournir des informations de sécurité facultatives. Ces informations peuvent être fournies à l'aide d'un fichier de configuration OCI ou d'un principal d'instance.

Les sources et les puits d'Oracle NoSQL Database nécessitent des informations de sécurité obligatoires si l'installation est sécurisée et utilise une authentification basée sur Oracle Wallet. Ces informations peuvent être fournies en ajoutant un fichier JAR au répertoire <MIGRATOR_HOME>/lib.

Authentification avec les principaux d'instance

Les principaux d'instance sont une fonction de service IAM qui permet aux instances d'être des acteurs (ou principaux) autorisés pouvant effectuer des actions sur les ressources de service. Chaque instance de calcul possède sa propre identité et s'authentification à l'aide des certificats qui y sont ajoutés.

Oracle NoSQL Database Migrator offre une option pour se connecter à des sources et des puits de stockage d'objets NoSQL en nuage et OCI à l'aide de l'authentification par principal d'instance. Il n'est pris en charge que lorsque l'outil NoSQL Database Migrator est utilisé dans une instance de calcul OCI, par exemple, l'outil NoSQL Database Migrator s'exécutant dans une machine virtuelle hébergée sur OCI. Pour activer cette fonction, utilisez l'attribut useInstancePrincipal du fichier de configuration de la source et du récepteur NoSQL en nuage. Pour plus d'informations sur les paramètres de configuration pour différents types de sources et de puits, voir Modèles de configuration des sources et Modèles de configuration des puits.

Pour plus d'informations sur les principaux d'instance, voir Appel de services à partir d'une instance.

Autorisation dans les sources et les collecteurs d'Oracle NoSQL Database Cloud Service

L'accès aux ressources d'Oracle NoSQL Database Cloud Service, telles que les tables, les espaces-tables et les API, est géré au moyen des politiques du service de gestion des identités et des accès (IAM). Ainsi, seuls les utilisateurs ou les applications disposant des autorisations d'inspection, de lecture, d'utilisation ou de gestion de table appropriées dans un compartiment spécifique peuvent interagir avec ces ressources. Pour plus d'informations, voir Gestion de l'accès aux tables NDCS.

Lorsque vous utilisez l'utilitaire Migrator pour importer ou exporter des données à partir de tables Oracle NoSQL Database Cloud Service, vos autorisations IAM effectives déterminent les ressources dans lesquelles vous pouvez lire ou écrire. Si un utilisateur d'un groupe défini tente une action au-delà de ses privilèges autorisés, l'utilitaire Migrator retourne l'erreur d'autorisation correspondante telle que fournie par OCI IAM.

Par exemple, le service IAM pour OCI refuse toute tentative d'importation de données dans une table Oracle NoSQL Database Cloud Service si votre groupe d'utilisateurs n'a que l'autorisation "lecture" sur la table. Un message d'erreur similaire à celui qui suit s'affiche dans les journaux :

[INSUFFICIENT_PERMISSION] Authorization failed or requested resource not found

Flux de travail pour Oracle NoSQL Database Migrator

Découvrez les différentes étapes impliquées dans l'utilisation de l'utilitaire de migration d'Oracle NoSQL Database pour migrer vos données NoSQL.

Le flux de haut niveau des tâches impliquées dans l'utilisation de NoSQL Database Migrator est illustré dans la figure ci-dessous.

Description de l'image ci-dessous

Description de l'illustration migrator_flow.png

Télécharger l'utilitaire NoSQL Data Migrator

L'utilitaire Migrator d'Oracle NoSQL Database est disponible pour téléchargement à partir de la page Téléchargements Oracle NoSQL. Une fois que vous l'avez téléchargé et décompressé sur votre machine, vous pouvez accéder à la commande runMigrator à partir de l'interface de ligne de commande.

Note : L'utilitaire Migrator d'Oracle NoSQL Database nécessite l'exécution de Java version 11 ou supérieure.

Identifier la source et le puits

Avant d'utiliser l'outil de migration, vous devez identifier la source et le puits de données. Par exemple, si vous voulez migrer une table NoSQL d'Oracle NoSQL Database sur place vers un fichier au format JSON, votre source sera Oracle NoSQL Database et l'évier sera un fichier JSON. Assurez-vous que la source et l'évier identifiés sont pris en charge par Oracle NoSQL Database Migrator en se référant aux sources et aux éviers pris en charge. Il s'agit également d'une phase appropriée pour décider du schéma de votre table NoSQL dans la cible ou le récepteur et les créer.

Note : La migration échouera si la table est présente au niveau du récepteur et que le LDD dans schemaPath est différent de la table.

Note : Si la source est un fichier CSV, créez un fichier avec les commandes LDD pour le schéma de la table cible. Indiquez le chemin d'accès au fichier dans le paramètre schemaInfo.schemaPath du fichier de configuration de l'évier.

Exécutez la commande runMigrator

Le fichier exécutable runMigrator est disponible dans les fichiers NoSQL Database Migrator extraits. Vous devez installer Java version 11 ou supérieure et bash sur votre système pour exécuter avec succès la commande runMigrator.

Vous pouvez exécuter la commande runMigrator de deux façons :

  1. En créant le fichier de configuration à l'aide des options d'exécution de la commande runMigrator, comme illustré ci-dessous.

    [~]$ ./runMigrator
configuration file is not provided. Do you want to generate configuration? (y/n)

[n]: y
...
...

    • Lorsque vous appelez l'utilitaire runMigrator, il fournit une série d'options d'exécution et crée le fichier de configuration en fonction de vos choix pour chaque option.

    • Une fois que l'utilitaire a créé le fichier de configuration, vous avez le choix de poursuivre l'activité de migration dans la même exécution ou d'enregistrer le fichier de configuration pour une migration future.

    • Quelle que soit votre décision de poursuivre ou de différer l'activité de migration avec le fichier de configuration généré, le fichier sera disponible pour les modifications ou la personnalisation afin de répondre à vos besoins futurs. Vous pouvez utiliser le fichier de configuration personnalisé pour la migration plus tard.

  2. En transmettant un fichier de configuration créé manuellement (au format JSON) en tant que paramètre d'exécution à l'aide de l'option -c ou --config. Vous devez créer le fichier de configuration manuellement avant d'exécuter la commande runMigrator avec l'option -c ou --config. Pour obtenir de l'aide sur les paramètres de configuration de la source et du récepteur, voir Informations de référence sur l'outil de migration pour Oracle NoSQL Database.

    [~]$ ./runMigrator -c </path/to/the/configuration/json/file>

Note : NoSQL Database Migrator consomme des unités de lecture lors de l'exportation de données à partir d'une table Oracle NoSQL Cloud Service vers un évier valide.

Progression de l'outil de migration de journalisation

L'outil NoSQL Database Migrator fournit des options qui permettent d'imprimer les messages de trace, de débogage et de progression vers une sortie standard ou un fichier. Cette option peut être utile pour suivre la progression de l'opération de migration, en particulier pour les tables ou les jeux de données très volumineux.

Limitation

Oracle NoSQL Database Migrator ne verrouille pas la base de données pendant la sauvegarde et ne bloque pas les autres utilisateurs. Par conséquent, il est fortement recommandé de ne pas effectuer les activités suivantes lorsqu'une tâche de migration est en cours d'exécution :

Migration des métadonnées de durée de vie pour les rangées de table

Voyez comment migrer les données de durée de vie de la source vers le puits.

La durée de vie (TTL) est un mécanisme qui permet d'annuler automatiquement les lignes d'une table. La durée de vie est exprimée en tant que période de vie. Les données sont autorisées à vivre dans le magasin. Les données qui ont atteint leur valeur de temporisation d'expiration ne peuvent plus être extraites et n'apparaîtront dans aucune statistique de magasin.

Vous pouvez choisir d'inclure les métadonnées de durée de vie des rangées de table ainsi que les données réelles lors de la migration des tables Oracle NoSQL Database. NoSQL Database Migrator fournit des paramètres de configuration pour prendre en charge l'exportation et l'importation des métadonnées de durée de vie des rangées de table pour les types de source suivants :

Table - Migration des métadonnées de durée de vie

Types de sources Paramètre de configuration source Paramètre de configuration de l'évier
Oracle NoSQL Database includeTTL includeTTL
Service Oracle NoSQL Database Cloud includeTTL includeTTL
Fichier JSON au format DynamoDB ttlAttributeName includeTTL
Fichier JSON au format DynamoDB stocké dans AWS S3 ttlAttributeName includeTTL

Exportation des métadonnées de durée de vie dans Oracle NoSQL Database et Oracle NoSQL Database Cloud Service

NoSQL Database Migrator fournit le paramètre de configuration includeTTL pour prendre en charge l'exportation des métadonnées de durée de vie de la rangée de table.

Lorsqu'une table est exportée, les données de durée de vie sont exportées pour les rangées de table dont le délai d'expiration est valide. Si une rangée n'expire pas, l'objet JSON _metadata n'est pas inclus explicitement dans les données exportées car sa valeur d'expiration est toujours

  1. NoSQL Database Migrator exporte le délai d'expiration de chaque ligne en tant que nombre de millisecondes depuis l'époque UNIX (1er janvier 1970). Par exemple,
//Row 1
{
    "id" : 1,
    "name" : "xyz",
    "age" : 45,
    "_metadata" : {
        "expiration" : 1629709200000   //Row Expiration time in milliseconds
    }
}

//Row 2
{
    "id" : 2,
    "name" : "abc",
    "age" : 52,
    "_metadata" : {
        "expiration" : 1629709400000   //Row Expiration time in milliseconds
    }
}

//Row 3 No Metadata for below row as it will not expire
{
    "id" : 3,
    "name" : "def",
    "age" : 15
}

Importation des métadonnées de durée de vie

Vous pouvez éventuellement importer des métadonnées de durée de vie à l'aide du paramètre de configuration includeTTL dans le modèle de configuration de l'évier.

L'heure de référence par défaut de l'opération d'importation est l'heure courante, en millisecondes, obtenue à partir de System.currentTimeMillis(), de l'ordinateur sur lequel l'outil NoSQL Database Migrator est exécuté. Toutefois, vous pouvez également définir une heure de référence personnalisée à l'aide du paramètre de configuration ttlRelativeDate si vous souhaitez prolonger la durée d'expiration et importer des rangées qui expireraient immédiatement. L'extension est calculée comme suit et ajoutée au délai d'expiration.

Extended time = expiration time - reference time

L'opération d'importation gère les cas d'utilisation suivants lors de la migration des rangées de table contenant des métadonnées de durée de vie. Ces cas d'utilisation ne sont applicables que lorsque le paramètre de configuration includeTTL est réglé à Vrai.

Importation des métadonnées de durée de vie dans le fichier JSON au format DynamoDB et le fichier JSON au format DynamoDB stockés dans AWS S3

NoSQL Database Migrator fournit un paramètre de configuration supplémentaire, ttlAttributeName, pour prendre en charge l'importation des métadonnées de durée de vie à partir des éléments de fichier JSON au format DynamoDB.

Les fichiers JSON exportés DynamoDB incluent un attribut spécifique dans chaque élément pour stocker l'horodatage d'expiration de la durée de vie. Pour importer facultativement les valeurs de durée de vie à partir des fichiers JSON exportés DynamoDB, vous devez fournir le nom de l'attribut spécifique en tant que valeur au paramètre de configuration ttlAttributeName dans le fichier JSON formaté DynamoDB ou le fichier JSON formaté DynamoDB stocké dans les fichiers de configuration source AWS S3. Vous devez également définir le paramètre de configuration includeTTL dans le modèle de configuration de l'évier. Les puits valides sont Oracle NoSQL Database et Oracle NoSQL Database Cloud Service. NoSQL Database Migrator stocke les informations de durée de vie dans l'objet JSON _metadata pour l'élément importé.

L'opération d'importation gère les cas d'utilisation suivants lors de la migration des éléments de table des fichiers JSON exportés DynamoDB :

Note : Vous pouvez fournir le paramètre de configuration ttlRelativeDate dans le modèle de configuration de l'évier comme heure de référence pour le calcul du délai d'expiration.

Importation de données dans un évier avec une colonne IDENTITY

Voyez comment importer des données dans un évier qui inclut une colonne IDENTITY.

Vous pouvez importer les données d'une source valide dans une table de puits (Services sur place/infonuagiques) avec une colonne IDENTITY. Vous créez la colonne IDENTITY sous la forme GENERATED ALWAYS AS IDENTITY ou GENERATED BY DEFAULT AS IDENTITY. Pour plus d'informations sur la création d'une table avec une colonne IDENTITY, voir Création de tables avec une colonne IDENTITY dans SQL Reference Guide.

Avant d'importer les données, assurez-vous que la table Oracle NoSQL Database au niveau du récepteur est vide si elle existe. S'il existe des données préexistantes dans la table de puits, la migration peut entraîner des problèmes tels que le remplacement des données existantes dans la table de puits ou l'omission des données sources pendant l'importation.

Table d'évier dont la colonne IDENTITY est GENERATED ALWAYS AS IDENTITY

Prenons l'exemple d'une table d'évier dont la colonne IDENTITY a été créée avec la valeur GENERATED ALWAYS AS IDENTITY. L'importation de données dépend du fait que la source fournit ou non les valeurs à la colonne IDENTITY et au paramètre de transformation ignoreFields dans le fichier de configuration.

Par exemple, vous voulez importer des données d'une source de fichiers JSON dans la table Oracle NoSQL Database en tant que puits. Le schéma de la table de puits est le suivant :

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))

L'utilitaire Migrator gère la migration des données comme décrit dans les cas suivants :

Condition source Action d'utilisateur Résultat de la migration

CAS 1 : Les données sources ne fournissent pas de valeur pour le champ IDENTITY de la table d'évier.

Exemple : Fichier source JSON sample_noID.json

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

Créez/générez le fichier de configuration.

Migration des données réussie. Les valeurs de colonne IDENTITY sont générées automatiquement. Données migrées dans la table de récepteur Oracle NoSQL Database migrateID :

{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"John","course":"Computer Science"}
{"ID":1002,"name":"Tony","course":"Electronics"}

CAS 2 : Les données sources fournissent des valeurs pour le champ IDENTITY de la table d'évier.

Exemple : Fichier source JSON sampleID.json

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

Créez/générez le fichier de configuration. Vous fournissez une transformation ignoreFields pour la colonne ID dans le modèle de configuration de l'évier.

"transforms" : { "ignoreFields" : ["ID"] }

Migration des données réussie. Les valeurs d'ID fournies sont ignorées et les valeurs de colonne IDENTITY sont générées automatiquement.

Données migrées dans la table de récepteur Oracle NoSQL Database migrateID :

{"ID":2003,"name":"John","course":"Computer Science"}
{"ID":2002,"name":"Tony","course":"Electronics"}
{"ID":2001,"name":"Jane","course":"BioTechnology"}

Vous créez/générez le fichier de configuration sans la transformation ignoreFields pour la colonne IDENTITY.

La migration des données échoue avec le message d'erreur suivant :

"Cannot set value for a generated always identity column".

Pour plus de détails sur les paramètres de configuration de la transformation, voir la rubrique Modèles de configuration de la transformation.

Table d'évier avec la colonne IDENTITY GENERATED BY DEFAULT AS IDENTITY

Considérons une table de puits avec la colonne IDENTITY créée comme GENERATED BY DEFAULT AS IDENTITY. L'importation de données dépend du fait que la source fournit ou non les valeurs à la colonne IDENTITY et au paramètre de transformation ignoreFields.

Par exemple, vous voulez importer des données d'une source de fichiers JSON dans la table Oracle NoSQL Database en tant que puits. Le schéma de la table de puits est le suivant :

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))

L'utilitaire Migrator gère la migration des données comme décrit dans les cas suivants :

Condition source Action d'utilisateur Résultat de la migration

CAS 1 : Les données sources ne fournissent pas de valeur pour le champ IDENTITY de la table d'évier.

Exemple : Fichier source JSON sample_noID.json

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

Créez/générez le fichier de configuration.

Migration des données réussie. Les valeurs de colonne IDENTITY sont générées automatiquement. Données migrées dans la table de récepteur Oracle NoSQL Database migrateID :

{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}

CAS 2 : Les données sources fournissent des valeurs pour le champ IDENTITY de la table d'évier et il s'agit d'un champ de clé primaire.

Exemple : Fichier source JSON sampleID.json

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

Créez/générez le fichier de configuration. Vous fournissez une transformation ignoreFields pour la colonne ID dans le modèle de configuration de l'évier (recommandé).

"transforms" : { "ignoreFields" : ["ID"] }

Migration des données réussie. Les valeurs d'ID fournies sont ignorées et les valeurs de colonne IDENTITY sont générées automatiquement.

Données migrées dans la table de récepteur Oracle NoSQL Database migrateID :

{"ID":1002,"name":"John","course":"Computer Science"}
{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"Tony","course":"Electronics"}

Vous créez/générez le fichier de configuration sans la transformation ignoreFields pour la colonne IDENTITY.

Migration des données réussie. Les valeurs ID fournies à partir de la source sont copiées dans la colonne ID de la table de récepteur.

Lorsque vous tentez d'insérer un enregistrement supplémentaire dans la table sans fournir de code, le générateur de séquences tente de générer automatiquement le code. La valeur de départ du générateur de séquences est 1. Par conséquent, la valeur d'ID générée peut potentiellement dupliquer l'une des valeurs d'ID existantes dans la table de l'évier. Comme il s'agit d'une violation de la contrainte de clé primaire, une erreur est renvoyée et la ligne n'est pas insérée.

Voir Générateur de séquences pour plus d'informations.

Pour éviter la violation de contrainte de clé primaire, le générateur de séquences doit démarrer la séquence avec une valeur qui n'est pas en conflit avec les valeurs d'ID existantes dans la table du récepteur. Pour utiliser l'attribut START WITH pour effectuer cette modification, voir l'exemple ci-dessous :

Exemple : Données migrées dans la table de récepteur Oracle NoSQL Database migrateID :

{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}

Pour trouver la valeur appropriée que le générateur de séquences doit insérer dans la colonne ID, extrayez la valeur maximale du champ ID à l'aide de l'interrogation suivante :

SELECT ID FROM migrateID ORDER BY ID DESC LIMIT 1

Sortie :

{"ID":3}

La valeur maximale de la colonne ID dans la table de puits est 3. Vous voulez que le générateur de séquences commence à générer les valeurs d'ID au-delà de 3 pour éviter la duplication. Vous mettez à jour l'attribut START WITH du générateur de séquences à 4 à l'aide de l'instruction suivante :

ALTER Table migrateID (MODIFY ID GENERATED BY DEFAULT AS IDENTITY (START WITH 4))

La séquence commence à 4.

Maintenant, lorsque vous insérez des enregistrements dans la table de puits sans fournir les valeurs d'ID, le générateur de séquences génère automatiquement les valeurs d'ID à partir de 4 afin d'éviter la duplication des ID.

Pour plus de détails sur les paramètres de configuration de la transformation, voir la rubrique Modèles de configuration de la transformation.

Filtrage de données à l'aide de prédicats d'interrogation

Voyez comment spécifier des prédicats d'interrogation pour exporter uniquement les rangées de table qui correspondent aux critères de filtre.

Prédicat d'interrogation

NoSQL Database Migrator permet de filtrer les données lors de l'exportation en spécifiant un prédicat d'interrogation. Le prédicat d'interrogation spécifie les conditions qui doivent être remplies pour qu'une rangée soit exportée. L'utilitaire Migrator convertit le prédicat d'interrogation en clause SQL WHERE et l'applique à la table indiquée afin de fournir une condition de filtre pour exporter uniquement les rangées correspondant à la condition spécifiée. Vous pouvez utiliser des fonctions intégrées (modification_time(), expiration_time(), creation_time()) dans le prédicat d'interrogation pour créer des options de filtre avancées.

Vous ne pouvez utiliser des prédicats d'interrogation que sur les sources Oracle NoSQL Database et Oracle NoSQL Database Cloud Service pour tous les puits pris en charge. Pour plus de détails, voir Oracle NoSQL Database et Oracle NoSQL Database Cloud Service.

Pour une démonstration de cas d'utilisation, voir Migrer d'Oracle NoSQL Database Cloud Service vers un fichier JSON.

Filtre de vidage

L'utilitaire Migrator fournit une option pour faire écho à l'interrogation SQL exécutée sur le serveur dorsal. Cette fonction vous aide à vérifier l'interrogation générée et, si nécessaire, à préciser votre filtre avant d'exécuter la tâche de migration.

Vous pouvez exécuter l'utilitaire Migrator avec l'option de filtre de vidage comme suit :

[~/nosqlMigrator]$./runMigrator --dump-filter|df [optional-config-file]

Démonstrations de cas d'utilisation pour l'outil de migration d'Oracle NoSQL Database

Voyez comment effectuer une migration de données à l'aide d'Oracle NoSQL Database Migrator pour des cas d'utilisation particuliers. Vous pouvez trouver des instructions systématiques détaillées avec des exemples de code pour effectuer la migration dans chacun des cas d'utilisation.

Cet article contient les rubriques suivantes :

Migrer depuis le service Oracle NoSQL Database Cloud vers un fichier JSON

Cet exemple montre comment utiliser le migrateur Oracle NoSQL Database pour copier des données et la définition de schéma d'une table NoSQL d'Oracle NoSQL Database Cloud Service (NDCS) dans un fichier JSON.

Cas d'utilisation

Une organisation décide d'entraîner un modèle à l'aide des données d'Oracle NoSQL Database Cloud Service (NDCS) pour prédire les comportements à venir et fournir des recommandations personnalisées. Ils peuvent prendre une copie périodique des données des tables NDCS dans un fichier JSON et l'appliquer au moteur d'analyse pour analyser et entraîner le modèle. Cela les aide à séparer les interrogations analytiques des chemins critiques à faible latence.

Exemple

Pour la démonstration, examinons comment migrer la définition de données et de schéma d'une table NoSQL nommée myTable depuis NDCS vers un fichier JSON.

Conditions requises

Procédure

Pour migrer les données et la définition de schéma de votre table d'Oracle NoSQL Database Cloud Service vers un fichier JSON, vous pouvez utiliser l'une des options suivantes :

  1. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  2. Pour générer le fichier de configuration à l'aide de NoSQL Database Migrator, exécutez la commande runMigrator sans paramètre d'exécution.

    [~/nosqlMigrator]$./runMigrator

  3. Comme vous n'avez pas fourni le fichier de configuration en tant que paramètre d'exécution, l'utilitaire vous invite à générer la configuration maintenant. Entrez **y**.

    Configuration file is not provided. Do you want to generate
configuration? (y/n) [n]: y

Generating a configuration file interactively.

  4. En fonction des invites de l'utilitaire, sélectionnez vos options pour la configuration Source.

    Enter a location for your config [./migrator-config.json]: /home/<user>/nosqlMigrator/NDCS2JSON
Select the source:
1) nosqldb

2) nosqldb_cloud

3) file

4) object_storage_oci

5) aws_s3

#? 2

Configuration for source type=nosqldb_cloud
Enter endpoint URL or region ID of the Oracle NoSQL Database Cloud: us-phoenix-1
Select the authentication type:
1) credentials_file

2) instance_principal

3) delegation_token

4) session_token

5) oke_workload_identity

#? 1
Enter path to the file containing OCI credentials [/home/<user>/.oci/config]:
Enter the profile name in OCI credentials file [DEFAULT]:
Enter the compartment name or id of the table []: developers
Enter table name: myTable
Include TTL data? If you select 'yes' TTL of rows will also
be included in the exported data.(y/n) [n]:
Enter percentage of table read units to be used for migration operation. (1-100) [90]:

Enter store operation timeout in milliseconds. (1-30000) [5000]:

  5. En fonction des invites de l'utilitaire, choisissez vos options pour la configuration de l'évier.

    Select the sink:
1) nosqldb

2) nosqldb_cloud

3) file

#? 3
Configuration for sink type=file
Enter path to a directory to store JSON data: /home/<user>/nosqlMigrator
would you like to export data to multiple files for each source?(y/n) [y]: n
Would you like to store JSON in pretty format? (y/n) [n]: y
Would you like to migrate the table schema also? (y/n) [y]: y
Enter path to a file to store table schema: /home/<user>/nosqlMigrator/myTableSchema

  6. En fonction des invites de l'utilitaire, sélectionnez vos options pour les transformations de données sources. La valeur par défaut est n.

    Would you like to add transformations to source data? (y/n) [n]:

  7. Entrez votre choix pour déterminer si la migration doit se poursuivre en cas d'échec de la migration d'un enregistrement.

    Would you like to continue migration in case of any record/row is failed to migrate?: (y/n) [n]:

  8. L'utilitaire affiche la configuration générée à l'écran.

    generated configuration is:
{
  "source": {
    "type": "nosqldb_cloud",
    "endpoint": "us-ashburn-1",
    "table": "myTable",
    "compartment": "ocid1.compartment.oc1..aa..rhsmq",
    "credentials": "/home/<user>/.oci/config",
    "credentialsProfile": "DEFAULT",
    "readUnitsPercent": 90,
    "requestTimeoutMs": 5000
  },
  "sink": {
    "type": "file",
    "format": "json",
    "useMultiFiles" : false,
    "schemaPath": "/home/<user>/nosqlMigrator/myTableSchema",
    "pretty": true,
    "dataPath": "/home/<user>/nosqlMigrator"
  },
  "abortOnError": true,
  "migratorVersion": "1.8.0"
}

  9. L'utilitaire vous demande de choisir de poursuivre ou non la migration avec le fichier de configuration généré. L'option par défaut est y.

    Note : Si vous sélectionnez n, vous pouvez utiliser le fichier de configuration généré pour exécuter la migration à l'aide de l'option ./runMigrator -c ou ./runMigrator --config.

    Would you like to run the migration with above configuration?
If you select no, you can use the generated configuration file to
run the migration using:
./runMigrator --config /home/<user>/nosqlMigrator/NDCS2JSON
(y/n) [y]:

  10. NoSQL Database Migrator migre vos données et votre schéma de NDCS vers le fichier JSON.

    Records provided by source=10,Records written to sink=10,Records failed=0,Records skipped=0.
Elapsed time: 0min 1sec 277ms
Migration completed.

    Validation

Pour valider la migration, vous pouvez naviguer jusqu'au répertoire de puits spécifié et voir le schéma et les données.

-- Exported myTable Data. JSON files are created in the supplied data path

[~/nosqlMigrator]$cat myTable_1_5.json
{
  "id" : 10,
  "document" : {
    "course" : "Computer Science",
    "name" : "Neena",
    "studentid" : 105
  }
}
{
  "id" : 3,
  "document" : {
  "course" : "Computer Science",
    "name" : "John",
    "studentid" : 107
  }
}
{
  "id" : 4,
  "document" : {
    "course" : "Computer Science",
    "name" : "Ruby",
    "studentid" : 100
  }
}
{
  "id" : 6,
  "document" : {
    "course" : "Bio-Technology",
    "name" : "Rekha",
    "studentid" : 104
  }
}
{
  "id" : 7,
  "document" : {
    "course" : "Computer Science",
    "name" : "Ruby",
    "studentid" : 100
  }
}
{
  "id" : 5,
  "document" : {
    "course" : "Journalism",
    "name" : "Rani",
    "studentid" : 106
  }
}
{
  "id" : 8,
  "document" : {
    "course" : "Computer Science",
    "name" : "Tom",
    "studentid" : 103
  }
}
{
  "id" : 9,
  "document" : {
    "course" : "Computer Science",
    "name" : "Peter",
    "studentid" : 109
  }
}
{
  "id" : 1,
  "document" : {
    "course" : "Journalism",
    "name" : "Tracy",
    "studentid" : 110
  }
}
{
  "id" : 2,
  "document" : {
    "course" : "Bio-Technology",
    "name" : "Raja",
    "studentid" : 108
  }
}
-- Exported myTable Schema

[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))

  1. Préparez le fichier de configuration (au format JSON) avec les détails de source et de récepteur JSON d'Oracle NoSQL Database Cloud Service (NDCS). Voir Modèles de configuration source et Modèles de configuration de puits.

    Une table users est utilisée avec les données suivantes dans cet exemple :

    {"id":10,"firstName":"John","lastName":"Smith","age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008}}
{"id":20,"firstName":"Jane","lastName":"Smith","age":22,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005}}
{"id":30,"firstName":"Adam","lastName":"Smith","age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075}}
{"id":40,"firstName":"Joanna","lastName":"Smith","age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085}}

    Assurez-vous d'inclure le paramètre queryFilter avec le prédicat d'interrogation approprié dans le modèle de configuration source pour exporter uniquement les rangées requises de votre table. Pour plus de détails sur la création de prédicats d'interrogation, voir la table Exemples de prédicats d'interrogation dans la rubrique Source du service NoSQL Database Cloud.

    Dans cet exemple, le prédicat d'interrogation exporte les rangées avec le champ city dans la colonne JSON address = 'Houston' de la table users.

    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "queryFilter" : "$row.address.city='Houston'",
    "compartment" : "ocid1.compartment.oc1..aa..rhsmq",
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "readUnitsPercent" : 90,
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "file",
    "format" : "json",
    "useMultiFiles" : true,
    "chunkSize" : 32,
    "schemaPath" : "/scratch/<user>/nosqlMigrator/tableschema.ddl",
    "pretty" : false,
    "dataPath" : "/scratch/<user>/nosqlMigrator"
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration. Utilisez l'option --config ou -c.

    [~/nosqlMigrator]$./runMigrator --config <complete/path/to/the/JSON/config/file>

    Note :

    Vous pouvez également exécuter la commande avec

    option pour voir et vérifier l'interrogation générée avant d'exécuter la tâche de migration comme suit. Pour plus de détails, voir

    .

    [~/nosqlMigrator]$./runMigrator --dump-filter <complete/path/to/the/JSON/config/file>

    L'utilitaire procède à la migration des données comme suit :

    [INFO] creating source from given configuration:
[INFO] [cloud source] : query = 'SELECT $row,expiration_time_millis($row) AS expiration FROM users $row where $row.address.city='Houston''
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [json file sink] : writing table schema to /scratch/raumesh/nosqlMigrator/tableschema.ddl
[INFO] migration started
[INFO] Migration success for source users. read=2,written=2,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 182ms
Migration completed.

Vérification

Pour vérifier la migration, vous pouvez naviguer jusqu'au répertoire de puits spécifié et afficher le schéma et les données. Seules les rangées de la colonne JSON address avec la valeur de champ city 'Houston' sont exportées.

-- Exported users data. Schema and JSON files are created in the supplied data paths.

[~/nosqlMigrator]: cat tableschema.ddl

CREATE TABLE IF NOT EXISTS users (id INTEGER, firstName STRING, lastName STRING, age INTEGER, income INTEGER, address JSON, PRIMARY KEY(SHARD(id)))
[~/nosqlMigrator]: cat users_6_10.json

{"id":30,"firstName":"Adam","lastName":"Smith","age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075}}
{"id":40,"firstName":"Joanna","lastName":"Smith","age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085}}
bash-4.4$

Migrer depuis le service Oracle NoSQL Database On-Premise vers le service Oracle NoSQL Database Cloud

Cet exemple montre comment utiliser le migrateur Oracle NoSQL Database pour copier des données et la définition de schéma d'une table NoSQL d'Oracle NoSQL Database vers Oracle NoSQL Database Cloud Service (NDCS).

Cas d'utilisation

En tant que développeur, vous envisagez d'explorer des options pour éviter les frais généraux liés à la gestion des ressources, des grappes et du nettoyage de la mémoire pour vos charges de travail NoSQL Database KVStore existantes. Comme solution, vous décidez de migrer vos charges de travail KVStore existantes sur place vers Oracle NoSQL Database Cloud Service, car NDCS les gère automatiquement.

Exemple

Pour la démonstration, examinons comment migrer la définition de données et de schéma d'une table NoSQL nommée myTable du magasin KVStore de NoSQL Database vers NDCS. Nous utiliserons également ce cas d'utilisation pour montrer comment exécuter l'utilitaire runMigrator en transmettant un fichier de configuration prédéfini.

Conditions requises

Procédure

Pour migrer la définition de données et de schéma de myTable de NoSQL Database KVStore vers NDCS :

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Voir Modèles de configuration source et Modèles de configuration de puits.

    {
  "source" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "myTable",
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "myTable",
    "compartment" : "developers",
    "schemaInfo" : {
      "schemaPath" : "<complete/path/to/the/JSON/file/with/DDL/commands/for/the/schema/definition>",
      "readUnits" : 100,
      "writeUnits" : 100,
      "storageSize" : 1
    },
    "credentials" : "<complete/path/to/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.

    [~/nosqlMigrator/nosql-migrator-1.8.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>

  4. L'utilitaire procède à la migration des données, comme indiqué ci-dessous.

    Records provided by source=10, Records written to sink=10, Records failed=0.
Elapsed time: 0min 10sec 426ms
Migration completed.

Validation

Pour valider la migration, vous pouvez vous connecter à la console NDCS et vérifier que myTable est créé avec les données sources.

Migrer de la source de fichier JSON vers Oracle NoSQL Database Cloud Service

Cet exemple montre l'utilisation d'Oracle NoSQL Database Migrator pour copier des données d'une source de fichiers JSON vers Oracle NoSQL Database Cloud Service.

Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database Cloud Service en tant que plate-forme NoSQL Database. Comme son contenu source est au format de fichier JSON, il cherche un moyen de le migrer vers Oracle NoSQL Database Cloud Service.

Dans cet exemple, vous apprendrez à migrer les données à partir d'un fichier JSON nommé SampleData.json. Vous exécutez l'utilitaire runMigrator en transmettant un fichier de configuration précréé. Si le fichier de configuration n'est pas fourni en tant que paramètre d'exécution, l'utilitaire runMigrator vous invite à générer la configuration au moyen d'une procédure interactive.

Conditions requises

Procédure

Pour migrer le fichier source JSON de SampleData.json vers Oracle NoSQL Database Cloud Service, procédez de la façon suivante :

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Voir Modèles de configuration source et Modèles de configuration de puits.

    {
  "source" : {
    "type" : "file",
    "format" : "json",
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.8.0]/schema_json.ddl"
    },
    "dataPath" : "[~/nosql-migrator-1.8.0]/SampleData.json"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "Migrate_JSON",
    "compartment" : "Training-NoSQL",
    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire Oracle NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.

    [~/nosql-migrator-1.8.0]$./runMigrator --config <complete/path/to/the/config/file>

  4. L'utilitaire procède à la migration des données, comme indiqué ci-dessous. La table Migrate_JSON est créée au niveau du récepteur avec le schéma fourni dans schemaPath.

    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id)),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
[cloud sink] : start loading records
[json file source] : start parsing JSON records from file: SampleData.json
[INFO] migration completed.
Records provided by source=4, Records written to sink=4, Records failed=0, Records skipped=0.
Elapsed time: 0min 5sec 778ms
Migration completed.

Validation

Pour valider la migration, vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et vérifier que la table Migrate_JSON est créée avec les données sources. Pour la procédure d'accès à la console, voir l'article Accès au service à partir de la console d'infrastructure dans le document Oracle NoSQL Database Cloud Service.

Figure - Tables de la console Oracle NoSQL Database Cloud Service

Description de l'image ci-dessous

Description de l'illustration migrate_json1.png

Figure - Données de table de la console Oracle NoSQL Database Cloud Service

Description de l'image ci-dessous

Description de l'illustration migrate_json2.png

Migrer du fichier JSON MongoDB vers Oracle NoSQL Database Cloud Service

Cet exemple montre comment utiliser l'outil de migration d'Oracle NoSQL Database pour copier des données au format MongoDB vers Oracle NoSQL Database Cloud Service (NDCS).

Cas d'utilisation

Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database Cloud Service en tant que plate-forme NoSQL Database. Les tables et les données sont dans MongoDB et l'organisation souhaite migrer les deux vers Oracle NDCS.

Vous pouvez copier un fichier ou un répertoire contenant les données JSON exportées par MongoDB pour la migration en spécifiant le fichier ou le répertoire dans le modèle de configuration source.

Considérons les deux exemples de fichiers JSON suivants exportés depuis MongoDB pour démontrer notre cas d'utilisation.

Un exemple de fichier JSON au format MongoDB est le suivant :

{"_id":0,"name":"Aimee Zank","scores":[{"score":1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}

Un exemple de fichier JSON au format MongoDB exporté à partir d'une application Spring est le suivant :

{"_id":{"$oid":"63d3a87cf564fc21dac3838d"},"firstName":"John","lastName":"Smith","address":{"Country":"France"},"_class":"com.example.demo.Customer"}
{"_id":{"$oid":"63d3a87cf564fc21dac3838e"},"firstName":"Sam","lastName":"David","address":{"Country":"USA"},"_class":"com.example.demo.Customer"}
{"_id":"3","firstName":"Dona","lastName":"William","address":{"Country":"England"},"_class":"com.example.demo.Customer"}

MongoDB prend en charge deux types d'extension des fichiers JSON formatés, le mode canonique et le mode assoupli. Vous pouvez fournir le fichier JSON au format MongoDB qui est généré à l'aide de l'outil mongoexport en mode Canonical ou Relaxed. NoSQL Database Migrator prend en charge les deux modes.

Pour plus d'informations sur le fichier MongoDB Extended JSON (v2), voir mongoexport_formats.

Pour plus d'informations sur la génération du fichier JSON au format MongoDB, voir mongoexport.

Exemple

Pour la démonstration, examinons comment migrer un fichier JSON au format MongoDB vers NDCS. Nous utiliserons un fichier de configuration créé manuellement pour cet exemple.

Conditions requises

Procédure

Pour migrer les données JSON au format MongoDB vers Oracle NoSQL Database Cloud Service, vous pouvez choisir l'une des options suivantes :

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Voir Modèles de configuration source et Modèles de configuration de puits.

    Ici, vous réglez le paramètre de configuration defaultSchema à Vrai. Par conséquent, NoSQL Database Migrator crée une table avec le schéma par défaut au niveau du récepteur.

    {
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "mongoImport",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",

    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "defaultSchema" : true
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

    Le schéma par défaut pour la source de fichier JSON au format MongoDB est le suivant :

    CREATE TABLE IF NOT EXISTS <tablename>(id STRING, document JSON,PRIMARY KEY(SHARD(id));

    Où :

    • tablename = valeur fournie pour l'attribut table dans la configuration.

    • id = Valeur _id de chaque document du fichier source JSON exporté par MongoDB.

    • document = Pour chaque document du fichier exporté MongoDB, le contenu excluant le champ _id est agrégé dans la colonne document.

    Note : Si la table <tablename> existe déjà dans Oracle NoSQL Database Cloud Service et que vous voulez migrer des données vers la table à l'aide de la configuration defaultSchema, vous devez vous assurer que la table existante contient la colonne ID en minuscules (id) et qu'elle est de type STRING.

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration. Utilisez l'option --config ou -c.

    $./runMigrator --config <complete/path/to/the/JSON/config/file>

  4. L'utilitaire procède à la migration des données, comme indiqué ci-dessous.

    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS mongoImport (id STRING, document JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] [mongo file source] : start parsing MongoDB JSON records from file: mongoDBSample.json
[INFO] Migration success for source mongoDBSample. read=5,written=5,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 448ms
Migration completed.

Vérification

Pour vérifier la migration, vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et vérifier que la table mongoImport est créée avec les données sources. Pour la procédure d'accès à la console, voir l'article Accès au service à partir de la console d'infrastructure.

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Voir Modèles de configuration source et Modèles de configuration de puits.

    Ici, vous spécifiez le fichier contenant l'énoncé LDD de la table de puits dans le paramètre schemaPath du modèle de configuration source. En conséquence, réglez le paramètre de configuration useSourceSchema à Vrai dans le modèle de configuration de l'évier.

    Vous pouvez générer un schéma personnalisé comme suit :

    • Notez les noms et les types de données pour chaque colonne à partir des données JSON au format MongoDB. Utilisez ces informations pour créer un fichier LDD de schéma pour la table Oracle NoSQL Database Cloud Service.

    • Dans le fichier de schéma, nommez la première colonne (clé primaire) id de type STRING. Incluez le même nom et le même type pour les colonnes restantes enregistrées dans le fichier JSON au format MongoDB.

    • Enregistrez le fichier de schéma et notez son chemin complet.

    Le schéma défini par l'utilisateur suivant est utilisé dans cet exemple :

    CREATE TABLE IF NOT EXISTS sampleMongoDBImp (id STRING, name STRING, scores JSON, PRIMARY KEY(SHARD(id)));

    Vous devez inclure une transformation renameFields demandant à NoSQL Database Migrator de convertir la colonne _id en id lors de la création de la table. Pour plus de détails sur les paramètres, voir Modèles de configuration de transformation. NoSQL Database Migrator crée une table avec le schéma personnalisé au niveau du récepteur.

    {
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "schemaInfo" : {
      "schemaPath" : "<complete/path/to/the/schema/file>"
    },
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "sampleMongoDBImp",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : false,
    "requestTimeoutMs" : 5000
  },
  "transforms": {
    "renameFields" : {
      "_id":"id"
    }
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration. Utilisez l'option --config ou -c.

    $./runMigrator --config <complete/path/to/the/JSON/config/file>

  4. L'utilitaire procède à la migration des données, comme indiqué ci-dessous.

    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampleMongoDBImp (id INTEGER, name STRING, scores JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] [mongo file source] : start parsing MongoDB JSON records from file: mongoDBSample.json
[INFO] Migration success for source mongoDBSample. read=5,written=5,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 438ms
Migration completed.

Vérification

Pour vérifier la migration, vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et vérifier que la table sampleMongoDBImp est créée avec les données sources. Pour la procédure d'accès à la console, voir l'article Accès au service à partir de la console d'infrastructure.

  1. Pour ce cas d'utilisation, nous utiliserons l'exemple de fichier JSON au format MongoDB exporté à partir d'une application Spring comme source. Pour plus de détails sur ce format, voir Données sources.

  2. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Voir Modèles de configuration source et Modèles de configuration de puits.

    Ici, vous spécifiez le fichier contenant l'énoncé LDD de la table de puits dans le paramètre schemaPath du modèle de configuration source. En conséquence, réglez le paramètre de configuration useSourceSchema à Vrai dans le modèle de configuration de l'évier.

    Vous pouvez générer un schéma personnalisé comme suit :

    • Notez les noms et les types de données pour chaque colonne à partir des données JSON au format MongoDB.

    • Dans le fichier de schéma, nommez la première colonne (clé primaire) id de type STRING. Agréger les champs restants dans un champ nommé kv_json_ de type JSON, en respectant le format de données Spring. Pour plus de détails, voir Modèle de persistance du cadre de données de printemps.

    • Enregistrez le fichier de schéma et notez son chemin complet.

    Le schéma défini par l'utilisateur suivant est utilisé dans cet exemple :

    CREATE TABLE IF NOT EXISTS sampleMongoDBSpringImp(id STRING, kv_json_ JSON, PRIMARY KEY(SHARD(id)))

    Pour l'exemple de données Spring donné ci-dessus, vous devez inclure les transformations suivantes :

    • Transformation renameFields pour convertir la colonne _id en id

    • Transformation ignoreFields pour ignorer la colonne _class et ne pas l'inclure dans la table de récepteur

    • Transformation aggregateFields pour agréger les champs restants (autres que id) à un champ de type JSON

    Pour plus de détails sur les paramètres, voir Modèles de configuration de transformation. NoSQL Database Migrator crée une table avec le schéma personnalisé au niveau du récepteur.

    {
  "source": {
    "type": "file",
    "format": "mongodb_json",
    "schemaInfo": {
      "schemaPath": "<complete/path/to/the/schema/file>"
    },
    "dataPath": "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink": {
    "type": "nosqldb_cloud",
    "endpoint": "us-ashburn-1",
    "table": "sampleMongoDBSpringImp",
    "compartment": "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",
    "includeTTL": true,
    "schemaInfo": {
      "readUnits": 100,
      "writeUnits": 60,
      "storageSize": 1,
      "useSourceSchema": true
    },
    "credentials": "<complete/path/to/the/oci/config/file>",
    "credentialsProfile": "DEFAULT",
    "writeUnitsPercent": 90,
    "overwrite": false,
    "requestTimeoutMs": 5000
  },
  "transforms": {
    "renameFields": {
      "_id": "id"
    },
    "ignoreFields": ["_class"],
    "aggregateFields": {
      "fieldName": "kv_json_",
      "skipFields": ["id"]
    }
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  3. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  4. Exécutez la commande runMigrator en transmettant le fichier de configuration. Utilisez l'option --config ou -c.

    $./runMigrator --config <complete/path/to/the/JSON/config/file>

  5. L'utilitaire procède à la migration des données, comme indiqué ci-dessous.

    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampleMongoDBSpringImp (id STRING, kv_json_ JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
migration started
[mongo file source] : start parsing MongoDB JSON records from file: mongodbspring.json
Migration success for source mongodbspring. read=3,written=3,failed=0
Migration is successful for all the sources.
migration completed.
Records provided by source=3, Records written to sink=3, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 393ms
Migration completed.

Vérification

Pour vérifier la migration, vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et vérifier que la table sampleMongoDBImp est créée avec les données sources. Pour la procédure d'accès à la console, voir l'article Accès au service à partir de la console d'infrastructure.

Migrer du fichier JSON DynamoDB vers Oracle NoSQL Database Cloud Service

Cet exemple montre comment utiliser Oracle NoSQL Database Migrator pour copier le fichier JSON DynamoDB dans le service NoSQL Database Cloud.

Cas d'utilisation

Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database Cloud Service sur la base de données DynamoDB. L'organisation veut migrer ses tables et ses données de DynamoDB vers Oracle NoSQL Database Cloud Service.

Pour plus de détails, voir Mappage de la table DynamoDB à la table Oracle NoSQL.

Vous pouvez migrer un fichier ou un répertoire contenant les données JSON exportées DynamoDB à partir d'un système de fichiers en spécifiant le chemin dans le modèle de configuration source.

Un exemple de fichier JSON au format DynamoDB est le suivant :

{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}

Vous exportez la table DynamoDB vers le stockage AWS S3, comme indiqué dans Exportation des données de table DynamoDB vers Amazon S3.

Exemple

Pour cette démonstration, vous apprendrez à migrer un fichier JSON DynamoDB vers Oracle NoSQL Database Cloud Service. Vous utiliserez un fichier de configuration créé manuellement pour cet exemple.

Conditions requises

Procédure

Pour migrer les données JSON DynamoDB vers Oracle NoSQL Database :

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Pour plus de détails, voir Modèles de configuration de source et Modèles de configuration de récepteur.

    Note : Si les éléments de table JSON exportés par DynamoDB contiennent un attribut de durée de vie, pour importer facultativement les valeurs de durée de vie, spécifiez l'attribut dans le paramètre de configuration ttlAttributeName du modèle de configuration source et réglez le paramètre de configuration includeTTL à Vrai dans le modèle de configuration de l'évier. Pour plus de détails, voir Migration des métadonnées de durée de vie pour les rangées de table.

    Ici, vous réglez le paramètre de configuration defaultSchema à Vrai. Par conséquent, NoSQL Database Migrator crée le schéma par défaut au niveau du récepteur. Vous devez spécifier DDBPartitionKey et le type de colonne NoSQL correspondant. Sinon, une erreur s'affiche.

    Pour plus de détails sur le schéma par défaut d'une source JSON exportée par DynamoDB, voir la rubrique Identifier la source et le récepteur dans Flux de travail pour Oracle NoSQL Data Migrator.

        {
     "source" : {
      "type" : "file",
      "format" : "dynamodb_json",
      "ttlAttributeName" : "ttl",
      "dataPath" : "complete/path/to/the/DynamoDB/Formatted/JSON/file"
     },
     "sink" : {
      "type" : "nosqldb_cloud",
      "endpoint" : "us-sanjose-1",
      "table" : "sampledynDBImp",
      "compartment" : "ocid
1.compartment.oc1..aaaaaaaa......smq",
      "includeTTL" : true,
      "schemaInfo" : {
       "readUnits" : 10,
       "writeUnits" : 10,
       "storageSize" : 1,
       "schemaPath" : "complete/path/to/the/DDl/file"
      },
      "credentials" : "/home/<username>/.oci/config",
      "credentialsProfile" : "DEFAULT",
      "writeUnitsPercent" : 90,
      "overwrite" : true,
      "requestTimeoutMs" : 5000
     },
     "abortOnError" : true,
     "migratorVersion" : "1.8.0"
    }

    Le schéma par défaut suivant est utilisé dans cet exemple :

    CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant des fichiers de configuration distincts. Utilisez l'option --config ou -c.

    ./runMigrator --config <complete/path/to/the/JSON/config/file>

  4. L'utilitaire procède à la migration des données comme illustré dans l'exemple suivant :

    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] Start writing data to OnDB Sink
[INFO] executing for source:DynamoSample
[INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz
[INFO] Writing data to OnDB Sink completed.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 45ms
Migration completed.

Vérification

Pour valider la migration, vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et vérifier que la table sampledynDBImp est créée avec les données sources.

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Pour plus de détails, voir Modèles de configuration de source et Modèles de configuration de récepteur.

    Note : Si les éléments de table JSON exportés par DynamoDB contiennent un attribut de durée de vie, pour importer facultativement les valeurs de durée de vie, spécifiez l'attribut dans le paramètre de configuration ttlAttributeName du modèle de configuration source et réglez le paramètre de configuration includeTTL à Vrai dans le modèle de configuration de l'évier.

    Ici, vous réglez le paramètre de configuration defaultSchema à Faux. Par conséquent, vous spécifiez le fichier contenant l'énoncé LDD de la table de puits dans le paramètre schemaPath. Pour plus de détails, voir Mappage des types DynamoDB aux types Oracle NoSQL.

    Le schéma défini par l'utilisateur suivant est utilisé dans cet exemple :

    CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))

    NoSQL Database Migrator utilise le fichier de schéma pour créer la table au niveau du puits dans le cadre de la migration. Tant que les données de clé primaire sont fournies, l'enregistrement JSON d'entrée est inséré. Sinon, une erreur s'affiche.

    Note :

    • Si la table Dynamo DB a un type de données qui n'est pas pris en charge dans NoSQL Database, la migration échoue.

    • Si les données d'entrée ne contiennent pas de valeur pour une colonne particulière (autre que la clé primaire), la valeur par défaut de la colonne sera utilisée. La valeur par défaut doit faire partie de la définition de colonne lors de la création de la table. Par exemple id INTEGER not null default 0. Si la colonne n'a pas de définition par défaut, SQL NULL est inséré si aucune valeur n'est fournie pour la colonne.

    • Si vous modélisez une table DynamoDB en tant que document JSON, assurez-vous d'utiliser la transformation AggregateFields pour agréger les données de clé non principale dans une colonne JSON. Pour plus de détails, consultez aggregateFields

        Generated configuration is
    {
     "source" : {
      "type" : "file",
      "format" : "dynamodb_json",
      "ttlAttributeName" : "ttl",
      "dataPath" : "complete/path/to/the/DynamoDB/Formatted/JSON/file"
     },
     "sink" : {
      "type" : "nosqldb_cloud",
      "endpoint" : "us-sanjose-1",
      "table" : "sampledynDBImp",
      "compartment" : "ocid
1.compartment.oc1..aaaaaaaa......smq",
      "includeTTL" : true,
      "schemaInfo" : {
       "readUnits" : 10,
       "writeUnits" : 10,
       "storageSize" : 1,
       "schemaPath" : "complete/path/to/the/DDl/file"
      },
      "credentials" : "/home/<username>/.oci/config",
      "credentialsProfile" : "DEFAULT",
      "writeUnitsPercent" : 90,
      "overwrite" : true,
      "requestTimeoutMs" : 5000
     },
     "abortOnError" : true,
     "migratorVersion" : "1.8.0"
    }

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant des fichiers de configuration distincts. Utilisez l'option --config ou -c.

    ./runMigrator --config <complete/path/to/the/JSON/config/file>

  4. L'utilitaire procède à la migration des données comme illustré dans l'exemple suivant :

    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] Start writing data to OnDB Sink
[INFO] executing for source:DynamoSample
[INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz
[INFO] Writing data to OnDB Sink completed.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 45ms
Migration completed.

Vérification

Pour valider la migration, vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et vérifier que la table sampledynDBImp est créée avec les données sources.

Migrer du fichier DynamoDB JSON dans AWS S3 vers Oracle NoSQL Database Cloud Service

Cet exemple montre comment utiliser Oracle NoSQL Database Migrator pour copier le fichier JSON DynamoDB stocké dans un magasin AWS S3 vers Oracle NoSQL Database Cloud Service (NDCS).

Cas d'utilisation :

Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database Cloud Service sur la base de données DynamoDB. L'organisation veut migrer ses tables et ses données de DynamoDB vers Oracle NoSQL Database Cloud Service.

Pour plus de détails, voir Mappage de la table DynamoDB à la table Oracle NoSQL.

Vous pouvez migrer un fichier contenant les données JSON exportées par DynamoDB à partir du stockage AWS S3 en spécifiant le chemin dans le modèle de configuration source.

Un exemple de fichier JSON au format DynamoDB est le suivant :

{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"}}}

Vous exportez la table DynamoDB vers le stockage AWS S3, comme indiqué dans Exportation des données de table DynamoDB vers Amazon S3.

Exemple :

Pour cette démonstration, vous apprendrez à migrer un fichier DynamoDB JSON dans une source AWS S3 vers NDCS. Vous utiliserez un fichier de configuration créé manuellement pour cet exemple.

Conditions requises

Procédure

Pour migrer les données JSON DynamoDB vers Oracle NoSQL Database Cloud Service, utilisez l'une des options suivantes :

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Pour plus de détails, voir Modèles de configuration de source et Modèles de configuration de récepteur.

    Note : Si les éléments de votre fichier JSON DynamoDB dans AWS S3 contiennent un attribut de durée de vie, pour importer facultativement les valeurs de durée de vie, spécifiez l'attribut dans le paramètre de configuration ttlAttributeName du modèle de configuration source et réglez le paramètre de configuration includeTTL à Vrai dans le modèle de configuration de l'évier. Pour plus de détails, voir Migration des métadonnées de durée de vie pour les rangées de table.

    Réglez defaultSchema à TRUE pour que l'utilitaire Migrator crée le schéma par défaut au niveau du récepteur. Vous devez spécifier DDBPartitionKey et le type de colonne NoSQL correspondant. Sinon, une erreur est générée.

        {
     "source" : {
       "type" : "aws_s3",
       "format" : "dynamodb_json",
       "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>",
       "credentials" : "</path/to/aws/credentials/file>",
       "credentialsProfile" : <"profile name in aws credentials file">
     },
     "sink" : {
       "type" : "nosqldb_cloud",
       "endpoint" : "<region_name>",
       "table" : "<table_name>",
       "compartment" : "<compartment_name>",
       "schemaInfo" : {
          "defaultSchema" : true,
          "readUnits" : 100,
          "writeUnits" : 60,
          "DDBPartitionKey" : "<PrimaryKey:Datatype>",
          "storageSize" : 1
       },
       "credentials" : "<complete/path/to/the/oci/config/file>",
       "credentialsProfile" : "DEFAULT",
       "writeUnitsPercent" : 90,
       "requestTimeoutMs" : 5000
     },
     "abortOnError" : true,
     "migratorVersion" : "1.8.0"
    }

    Pour une source JSON DynamoDB, le schéma par défaut de la table sera le suivant :

    CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type,
[DDBSortKey_name DDBSortKey_type], DOCUMENT JSON,
PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))

    Où :

    TABLE_NAME = valeur fournie pour l'évier 'table' dans la configuration

    DDBPartitionKey_name = valeur fournie pour la clé de partition dans la configuration

    DDBPartitionKey_type = valeur fournie pour le type de données de la clé de partition dans la configuration

    DDBSortKey_name = valeur fournie pour la clé de tri dans la configuration, le cas échéant

    DDBSortKey_type = valeur fournie pour le type de données de la clé de tri dans la configuration, le cas échéant

    DOCUMENT = Tous les attributs sauf la partition et la clé de tri d'un élément de table Dynamo DB regroupés dans une colonne NoSQL JSON

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration. Utilisez l'option --config ou -c.

    [~/nosqlMigrator]$./runMigrator

--config <complete/path/to/the/JSON/config/file>

  4. L'utilitaire procède à la migration des données, comme indiqué ci-dessous.

    Records provided by source=7..,
Records written to sink=7,
Records failed=0,
Records skipped=0.
Elapsed time: 0 min 2sec 50ms
Migration completed.

Vérification

Vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et vérifier que la nouvelle table est créée avec les données sources.

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Pour plus de détails, voir Modèles de configuration de source et Modèles de configuration de récepteur.

    Note : Si les éléments de votre fichier JSON DynamoDB dans AWS S3 contiennent un attribut de durée de vie, pour importer facultativement les valeurs de durée de vie, spécifiez l'attribut dans le paramètre de configuration ttlAttributeName du modèle de configuration source et réglez le paramètre de configuration includeTTL à Vrai dans le modèle de configuration de l'évier. Pour plus de détails, voir Migration des métadonnées de durée de vie pour les rangées de table.

    Pour spécifier un fichier de schéma défini par l'utilisateur dans le modèle de configuration de puits, réglez defaultSchema à FALSE et spécifiez schemaPath en tant que fichier contenant votre énoncé LDD. Pour plus de détails, voir Mappage de types DynamoDB à des types Oracle NoSQL.

    Note : Si la table Dynamo DB a un type de données qui n'est pas pris en charge dans NoSQL, la migration échoue.

    Un exemple de fichier de schéma est présenté ci-dessous.

    CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON,
PRIMARY KEY(SHARD(AccountId)));

    Le fichier de schéma est utilisé pour créer la table au niveau du puits dans le cadre de la migration. Tant que les données de clé primaire sont fournies, l'enregistrement JSON d'entrée est inséré, sinon une erreur est générée.

    Note :

    • Si les données d'entrée ne contiennent pas de valeur pour une colonne particulière (autre que la clé primaire), la valeur par défaut de la colonne sera utilisée. La valeur par défaut doit faire partie de la définition de colonne lors de la création de la table. Par exemple id INTEGER not null default 0. Si la colonne n'a pas de définition par défaut, SQL NULL est inséré si aucune valeur n'est fournie pour la colonne.
    • Si vous modélisez une table DynamoDB en tant que document JSON, assurez-vous d'utiliser la transformation AggregateFields pour agréger les données de clé non principale dans une colonne JSON. Pour plus de détails, voir aggregateFields.
        {
     "source" : {
       "type" : "aws_s3",
       "format" : "dynamodb_json",
       "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>",
       "credentials" : "</path/to/aws/credentials/file>",
       "credentialsProfile" : <"profile name in aws credentials file">
     },
     "sink" : {
       "type" : "nosqldb_cloud",
       "endpoint" : "<region_name>",
       "table" : "<table_name>",
       "compartment" : "<compartment_name>",
       "schemaInfo" : {
          "defaultSchema" : false,
          "readUnits" : 100,
          "writeUnits" : 60,
          "schemaPath" : "<full path of the schema file with the DDL statement>",
          "storageSize" : 1
       },
       "credentials" : "<complete/path/to/the/oci/config/file>",
       "credentialsProfile" : "DEFAULT",
       "writeUnitsPercent" : 90,
       "requestTimeoutMs" : 5000
     },
      "transforms": {
        "aggregateFields" : {
          "fieldName" : "document",
          "skipFields" : ["AccountId"]
        }
      },
     "abortOnError" : true,
     "migratorVersion" : "1.8.0"
    }

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration. Utilisez l'option --config ou -c.

    [~/nosqlMigrator]$./runMigrator

--config <complete/path/to/the/JSON/config/file>

  4. L'utilitaire procède à la migration des données, comme indiqué ci-dessous.

    Records provided by source=7..,
Records written to sink=7,
Records failed=0,
Records skipped=0.
Elapsed time: 0 min 2sec 50ms
Migration completed.

Vérification

Vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et vérifier que la nouvelle table est créée avec les données sources.

Migrer entre les régions Oracle NoSQL Database Cloud Service

Cet exemple montre l'utilisation d'Oracle NoSQL Database Migrator pour effectuer une migration inter-régions.

Cas d'utilisation

Une organisation utilise Oracle NoSQL Database Cloud Service pour stocker et gérer ses données. Il décide de répliquer les données d'une région existante vers une région plus récente à des fins de test avant que la nouvelle région ne puisse être lancée pour l'environnement de production.

Dans ce cas d'utilisation, vous apprendrez à utiliser l'outil de migration de base de données NoSQL pour copier des données de la table user_data dans la région Ashburn vers la région Phoenix.

Vous exécutez l'utilitaire runMigrator en transmettant un fichier de configuration précréé. Si vous ne fournissez pas le fichier de configuration en tant que paramètre d'exécution, l'utilitaire runMigrator vous invite à générer la configuration au moyen d'une procédure interactive.

Conditions requises

Dans cet exemple, les régions sont sous des locations différentes. Le profil DEFAULT inclut les données d'identification OCI pour la région Ashburn et DEFAULT2 inclut les données d'identification OCI pour la région Phoenix.

Dans le paramètre endpoint du fichier de configuration de l'outil de migration (modèles de configuration source et de récepteur), vous pouvez fournir l'URL du point d'extrémité du service ou l'ID région des régions. Pour obtenir la liste des régions de données prises en charge pour Oracle NoSQL Database Cloud Service et leurs URL de point d'extrémité de service, voir Régions de données et URL de service associées dans le document Oracle NoSQL Database Cloud Service.

[DEFAULT]
user=ocid1.user.oc1....
fingerprint=fd:96:....
tenancy=ocid1.tenancy.oc1....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=abcd


[DEFAULT2]
user=ocid1.user.oc1....
fingerprint=1b:68:....
tenancy=ocid1.tenancy.oc1....
region=us-phoenix-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=23456

Procédure

Pour migrer la table user_data de la région Ashburn vers la région Phoenix, procédez de la façon suivante :

  1. Préparez le fichier de configuration (au format JSON) avec les détails de la source et du récepteur identifiés. Voir Modèles de configuration source et Modèles de configuration de puits.

    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "user_data",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "readUnitsPercent" : 100,
    "includeTTL" : false,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "user_data",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma",
    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT2",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  2. Sur votre ordinateur, accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator. Vous pouvez accéder à la commande runMigrator à partir de l'interface de ligne de commande.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option –config ou -c.

    [~/nosql-migrator]$./runMigrator --config <complete/path/to/the/config/file>

  4. L'utilitaire procède à la migration des données comme indiqué ci-dessous. La table user_data est créée au niveau du récepteur avec le même schéma que la table source que vous avez configuré le paramètre useSourceSchema avec la valeur Vrai dans le modèle de configuration du récepteur.

    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS user_data (id INTEGER, firstName STRING, lastName STRING, otherNames ARRAY(RECORD(first STRING, last STRING)), age INTEGER, income INTEGER, address JSON, connections ARRAY(INTEGER), email STRING, communityService STRING, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
[cloud sink] : start loading records
migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
Elapsed time: 0min 5sec 603ms
Migration completed.

    Note :

    • Si la table existe déjà au niveau du récepteur avec le même schéma que la table source, les rangées avec les mêmes clés primaires sont remplacées car vous avez indiqué que le paramètre de remplacement est Vrai dans le modèle de configuration.

    • Si la table existe déjà au niveau du récepteur avec un schéma différent de celui de la table source, la migration échouera.

Validation

Pour valider la migration, vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service dans la région Phoenix. Vérifiez que les données sources de la table user_data dans la région Ashburn sont copiées dans la table user_data de cette région. Pour la procédure d'accès à la console, voir l'article Accès au service à partir de la console d'infrastructure.

Migrer d'Oracle NoSQL Database Cloud Service vers le service de stockage d'objets pour OCI

Cet exemple montre l'utilisation d'Oracle NoSQL Database Migrator à partir d'un interpréteur de commandes Cloud Shell.

Cas d'utilisation

Une entreprise en démarrage prévoit utiliser Oracle NoSQL Database Cloud Service comme solution de stockage de données. La société veut utiliser Oracle NoSQL Database Migrator pour copier des données d'un tableau dans Oracle NoSQL Database Cloud Service vers le service de stockage d'objets OCI afin d'effectuer des sauvegardes périodiques de leurs données. À titre de mesure rentable, ils veulent exécuter l'utilitaire NoSQL Database Migrator à partir de Cloud Shell, qui est accessible à tous les utilisateurs OCI.

Dans ce cas d'utilisation, vous apprendrez à copier l'utilitaire NoSQL Database Migrator dans Cloud Shell dans la région à laquelle vous êtes abonné et à effectuer une migration de données. Vous migrez les données sources de la table Oracle NoSQL Database Cloud Service vers un fichier JSON dans le service de stockage d'objets pour OCI.

Vous exécutez l'utilitaire runMigrator en transmettant un fichier de configuration précréé. Si vous ne fournissez pas le fichier de configuration en tant que paramètre d'exécution, l'utilitaire runMigrator vous invite à générer la configuration au moyen d'une procédure interactive.

Conditions requises

Procédure

Pour migrer d'Oracle NoSQL Database Cloud Service vers le service de stockage d'objets pour OCI, effectuez les opérations suivantes à partir de la fenêtre Cloud Shell :

  1. Préparez un fichier de configuration Migrator, migrator-config.json, avec la source Oracle NoSQL Database Cloud Service et le dissipateur de stockage d'objets OCI. Pour les modèles, voir Modèles de configuration source et Modèles de configuration de puits. Assurez-vous de régler le paramètre useDelegationToken à true dans les modèles de configuration de source et de récepteur.

    Le modèle de configuration suivant est utilisé dans ce cas d'utilisation :

    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "NDCSupload",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
    "useDelegationToken" : true,
    "readUnitsPercent" : 90,
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "",
    "bucket" : "Migrate_oci",
    "prefix" : "Delegation",
    "chunkSize" : 32,
    "compression" : "",
    "useDelegationToken" : true
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  2. À partir de Cloud Shell, naviguez jusqu'au répertoire où vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.

    [~/nosql-migrator]$./runMigrator --config <complete/path/to/the/config/file>

  4. L'utilitaire NoSQL Database Migrator procède à la migration des données. Comme vous avez réglé le paramètre useDelegationToken à Vrai, Cloud Shell s'authentifie automatiquement à l'aide du jeton de délégation lors de l'exécution de l'utilitaire NoSQL Database Migrator. NoSQL Database Migrator copie vos données de la table NDCSupload dans un fichier JSON du seau de stockage d'objets Migrate_oci. Consultez les journaux pour connaître la réussite de la sauvegarde des données.

    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] migration started
[INFO] [OCI OS sink] : writing table schema to Delegation/Schema/schema.ddl
[INFO] [OCI OS sink] : start writing records with prefix Delegation
[INFO] migration completed.
Records provided by source=4,Records written to sink=4,Records failed=0.
Elapsed time: 0min 0sec 486ms
Migration completed.

    Note :

    Les données sont copiées dans le fichier : Migrate_oci/NDCSupload/Delegation/Data/000000.json

    Selon le paramètre chunkSize dans le modèle de configuration de l'évier, les données sources peuvent être fractionnées en plusieurs fichiers JSON dans le même répertoire.

    Le schéma est copié dans le fichier : Migrate_oci/NDCStable1/Delegation/Schema/schema.ddl

Validation

Pour valider votre sauvegarde de données, connectez-vous à la console Oracle NoSQL Database Cloud Service. Naviguez dans les menus, Storage > Object Storage & Archive Storage > Buckets. Accédez aux fichiers à partir du répertoire NDCSupload/Delegation dans le seau Migrate_oci. Pour la procédure d'accès à la console, voir l'article Accès au service à partir de la console d'infrastructure.

Migrer du service de stockage d'objets OCI vers Oracle NoSQL Database Cloud Service à l'aide de l'authentification OKE

Cet exemple montre comment utiliser l'outil de migration d'Oracle NoSQL Database avec l'authentification d'identité de charge de travail OKE pour copier des données à partir d'un fichier JSON dans le stockage d'objets OCI vers la table Oracle NoSQL Database Cloud Service.

Cas d'utilisation

En tant que développeur, vous envisagez d'explorer une option pour restaurer des données à partir d'un fichier JSON dans un seau de stockage d'objets OCI (OS OCI) vers une table Oracle NoSQL Database Cloud Service (NDCS) à l'aide de NoSQL Database Migrator dans une application conteneurisée. Une application conteneurisée est un environnement virtualisé qui regroupe l'application et toutes ses dépendances (telles que les bibliothèques, les fichiers binaires et les fichiers de configuration) dans un ensemble. Cela permet à l'application de s'exécuter de manière cohérente dans différents environnements, quelle que soit l'infrastructure sous-jacente.

Vous voulez exécuter NoSQL Database Migrator dans un module de réseautage Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). Pour accéder en toute sécurité aux services du système d'exploitation OCI et NDCS à partir du pod OKE, vous utiliserez la méthode d'authentification d'identité de charge de travail (WIA).

Dans cette démonstration, vous allez créer une image docker pour NoSQL Database Migrator, copier l'image dans un référentiel du registre de conteneurs, créer une grappe OKE et déployer l'image Migrator dans le pod de la grappe OKE pour exécuter l'utilitaire Migrator. Ici, vous fournirez un fichier de configuration NoSQL Database Migrator créé manuellement pour exécuter l'utilitaire Migrator en tant qu'application conteneurisée.

Conditions requises

Procédure

Pour migrer du fichier JSON du seau de système d'exploitation OCI vers la table NDCS, effectuez les opérations suivantes à partir de la fenêtre Cloud Shell :

  1. Préparez un fichier de configuration Migrator, migrator-config.json, avec la source du système d'exploitation OCI et le récepteur NDCS. Pour les modèles, voir Modèles de configuration source et Modèles de configuration de puits.

    Pour utiliser OKE WIA pour accéder au seau de système d'exploitation OCI et à NDCS, réglez le paramètre useOKEWorkloadIdentity à Vrai dans les modèles de configuration de source et de récepteur. Ici, vous utiliserez le schéma source du fichier LDD de schéma dans le seau de système d'exploitation OCI. Par conséquent, réglez le paramètre useSourceSchema à Vrai dans le modèle de configuration de l'évier.

    Note : Lors de l'utilisation d'OKE WIA, vous ne pouvez pas générer le fichier de configuration de Migrator de manière interactive. Vous devez préparer le fichier de configuration manuellement en vous référant aux modèles de configuration source et récepteur.

        {
      "source" : {
        "type" : "object_storage_oci",
        "format" : "json",
        "endpoint" : "us-ashburn-1",
        "namespace" : "",
        "bucket" : "Migrate_oci",
        "prefix" : "userSession",
        "useOKEWorkloadIdentity" : true
      },
      "sink" : {
        "type" : "nosqldb_cloud",
        "endpoint" : "us-ashburn-1",
        "table" : "users",
        "compartment" : "Training-NoSQL",
        "includeTTL" : true,
        "schemaInfo" : {
          "readUnits" : 100,
          "writeUnits" : 60,
          "storageSize" : 1,
          "useSourceSchema" : true
        },
        "useOKEWorkloadIdentity" : true,
        "writeUnitsPercent" : 90,
        "overwrite" : true,
        "requestTimeoutMs" : 5000
      },
      "abortOnError" : true,
      "migratorVersion" : "1.8.0"
    }

  2. Créez une ressource de configuration de mappage (configmap) pour transmettre le fichier d'entrée de configuration migrator-config.json au conteneur Migrator lors de l'exécution dans le pod Kubernetes. Le fichier de configuration configmap monte le fichier de configuration de Migrator dans le système de fichiers du conteneur en tant que volume de montage.

    #Command:
kubectl create configmap oci-migrator-config --from-file=<Migrator configuration file> -n <namespace-name>
    #Example:
kubectl create configmap oci-migrator-config --from-file=migrator-config.json -n migrator
    #Output:
configmap/oci-migrator-config created

  3. Créez une clé secrète de registre Docker qui inclut les données d'identification OCI à utiliser lors de l'extraction de l'image Docker de l'outil de migration à partir du registre de conteneurs dans le pod Kubernetes.

    #Command:
kubectl create secret docker-registry ocirsecret --docker-server=<region-key>.ocir.io --docker-username='tenancy-namespace/username' --docker-password='auth token' --docker-email='<user Email>' -n <namespace-name>
    #Example:
kubectl create secret docker-registry ocirsecret --docker-server=iad.ocir.io --docker-username='idhx..xxwjzj/rx..xxxxh@oracle.com' --docker-password='<Auth token>' --docker-email='rx..xxxxh@oracle.com' -n migrator
    #Output:
secret/ocirsecret created

  4. Créez un fichier manifeste, que vous utiliserez pour spécifier l'image Docker de Migrator. Assurez-vous de fournir les valeurs des étapes précédentes pour l'espace de noms, le nom du compte de service Kubernetes, le nom de l'image Docker, la clé secrète du registre Docker et le mappage de configuration. Vous pouvez consulter l'exemple de fichier manifeste suivant :

    #migrator-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nosql-migrator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nosql-migrator
  template:
    metadata:
      labels:
        app: nosql-migrator
    spec:
      serviceAccountName: migratorsa
      automountServiceAccountToken: true
      containers:

        - name: nosqlmigrator
          image: iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
          imagePullPolicy: Always
          args: ["--config", "/config/migrator-config.json", "--log-level", "DEBUG"]
          volumeMounts:

            - name: config-volume
              mountPath: /config  # Mount the file here
      imagePullSecrets:

        - name: ocirsecret
      volumes:

        - name: config-volume
          configMap:
            name: oci-migrator-config

  5. Déployez l'image Docker de Migrator dans le pod Kubernetes à l'aide de la commande suivante. OKE exécute l'utilitaire Migrator dans un conteneur sur l'un des noeuds de la grappe Kubernetes.

    #Command:
kubectl create -f <manifest file> -n <namespace-name>
    #Example:
kubectl create -f migrator-deployment.yaml -n migrator
    #Output:
deployment.apps/nosql-migrator created

  6. Vous pouvez vérifier les journaux à l'aide des commandes suivantes :

    1. Extrayez le nom du pod sur lequel l'utilitaire Migrator est exécuté.

      #Command:
kubectl get pods -n <namespace-name>
      #Example:
kubectl get pods -n migrator
      #Output:
NAME                            READY   STATUS    RESTARTS   AGE
nosql-migrator-ccdbf549-6sjjg   1/1     Running   0          56s

    2. Utilisez le nom du pod pour extraire les journaux de l'outil de migration.

      #Command:
kubectl logs -f <kubernetes cluster pod name> -n <namespace-name>
      #Example:
kubectl logs -f nosql-migrator-ccdbf549-6sjjg -n migrator
      #Output:
SLF4J(I): Connected with provider of type [org.apache.logging.slf4j.SLF4JServiceProvider]
[INFO] Configuration for migration:
{
  "source" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "idhkv1iewjzj",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "useOKEWorkloadIdentity" : true
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "compartment" : "Training-NoSQL",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "useOKEWorkloadIdentity" : true,
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}
[INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] migration started
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : completed loading DDLs
[INFO] [cloud sink] : start loading records
[INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_1_5_0.json
[INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_6_10_0.json
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
Elapsed time: 0min 1sec 15ms
Migration completed.

    Note :

    Vous pouvez exécuter itérativement la migration de données comme suit :

    1. Supprimez le conteneur nosql-migrator à l'aide de la commande suivante :

      #Command:

kubectl delete -f <manifest file> -n <namespace-name>
      #Example:

kubectl delete -f migrator-deployment.yaml -n migrator
      #Output:

deployment.apps "nosql-migrator" deleted

    2. Mettez à jour le fichier d'entrée de configuration migrator-config.json.

    3. Supprimez et recréez le fichier configmap à l'aide des commandes de l'étape 2.

      Il n'est pas nécessaire de créer la clé secrète du registre Docker et le fichier manifeste de nouveau.

    4. Déployez l'image Docker de Migrator dans le pod Kubernetes à l'aide du fichier manifeste (étape 5).

Vérification

Pour vérifier la restauration de vos données, connectez-vous à la console Oracle NoSQL Database Cloud Service. Dans la barre de navigation, allez à Bases de données > Base de données NoSQL. Sélectionnez votre compartiment dans la liste déroulante pour voir la table users. Pour la procédure d'accès à la console, voir Accès au service à partir de la console d'infrastructure.

Migrer d'Oracle NoSQL Database vers le service de stockage d'objets pour OCI à l'aide de l'authentification par jeton de session

Cet exemple montre comment utiliser Oracle NoSQL Database Migrator avec l'authentification par jeton de session pour copier des données de la table Oracle NoSQL Database vers un fichier JSON dans un seau de stockage d'objets OCI.

Cas d'utilisation

En tant que développeur, vous envisagez d'explorer une option pour sauvegarder les données de table Oracle NoSQL Database dans le service de stockage d'objets pour OCI (OCI OS). Vous voulez utiliser l'authentification basée sur un jeton de session.

Dans cette démonstration, vous allez utiliser les commandes de l'interface de ligne de commande OCI pour créer un jeton de session. Vous allez créer manuellement un fichier de configuration Migrator et effectuer la migration des données.

Conditions requises

Note : Assurez-vous de disposer des privilèges nécessaires pour écrire des objets dans le seau de système d'exploitation OCI. Pour plus de détails sur la définition des politiques, voir Écrire dans le stockage d'objets.

Procédure

Pour migrer de la table Oracle NoSQL Database vers un fichier JSON dans le seau de système d'exploitation OCI :

  1. Préparez le fichier de configuration (au format JSON) avec la source Oracle NoSQL Database et le fichier JSON dans le dissipateur de seau de système d'exploitation OCI. Pour les modèles, voir Modèles de configuration source et Modèles de configuration de puits.

    Pour utiliser l'authentification par jeton de session pour accéder au seau de système d'exploitation OCI, réglez le paramètre useSessionToken à Vrai dans le modèle de configuration du récepteur. En conséquence, spécifiez le chemin de configuration dans le paramètre d'identification et de connexion et le nom du profil dans le paramètre d'identification et de connexion.

    {
   "source" : {
     "type" : "nosqldb",
     "storeName" : "kvstore",
     "helperHosts" : ["<hostname>:<port>"],
     "table" : "users",
     "includeTTL" : true,
     "requestTimeoutMs" : 5000
   },
   "sink" : {
     "type" : "object_storage_oci",
     "format" : "json",
     "endpoint" : "us-ashburn-1",
     "namespace" : "idhkv1iewjzj",
     "bucket" : "Migrate_oci",
     "prefix" : "userSession",
     "chunkSize" : 32,
     "compression" : "",
     "useSessionToken" : true,
     "credentials" : "$/home/.oci/config",
     "credentialsProfile" : "SESSIONPROFILE"
   },
   "abortOnError" : true,
   "migratorVersion" : "1.8.0"
}

  2. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.

  3. Exécutez la commande runMigrator en transmettant l'option de fichier de configuration. Utilisez l'option --config ou -c pour transmettre le fichier de configuration comme suit :

    ./runMigrator --config ./migrator-config.json

  4. L'utilitaire Migrator procède à la migration des données. Un exemple de sortie est présenté ci-dessous.

    Lorsque le paramètre useSessionToken est réglé à Vrai, l'utilitaire Migrator s'authentifie automatiquement à l'aide du jeton de session. L'utilitaire Migrator copie vos données de la table users dans un fichier JSON du seau de système d'exploitation OCI nommé Migrate_oci. Consultez les journaux pour connaître la réussite de la sauvegarde des données.

    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [OCI OS sink] : writing table schema to userSession/Schema/schema.ddl
[INFO] migration started
[INFO] Migration success for source users_6_10. read=2,written=2,failed=0

[INFO] Migration success for source users_1_5. read=3,written=3,failed=0

[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 982ms
Migration completed.

    Note :

    Selon le paramètre chunkSize dans le modèle de configuration de l'évier, l'utilitaire Migrator fractionne les données sources en plusieurs fichiers JSON dans le même répertoire. Dans cet exemple, l'utilitaire Migrator copie les données dans les fichiers users_1_5_0.json et users_6_10_0.json du répertoire Migrate_oci/userSession/Data.

    Le schéma de la table source est copié dans le fichier schema.ddl du répertoire Migrate_oci/userSession/Schema.

Vérification

Pour vérifier votre sauvegarde de données, connectez-vous à la console Oracle NoSQL Database Cloud Service. Naviguez dans les menus, Storage > Object Storage & Archive Storage > Buckets. Accédez aux fichiers à partir du répertoire userSession dans le seau Migrate_oci. Pour la procédure d'accès à la console, voir Accès au service à partir de la console d'infrastructure

Migrer à partir d'un fichier CSV vers Oracle NoSQL Database Cloud Service

Cet exemple montre l'utilisation d'Oracle NoSQL Database Migrator pour copier des données d'un fichier CSV vers Oracle NoSQL Database Cloud Service.

Exemple

Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database Cloud Service en tant que plate-forme NoSQL Database. Comme son contenu source est au format de fichier CSV, il cherche un moyen de le migrer vers Oracle NoSQL Database Cloud Service.

Dans cet exemple, vous apprendrez à migrer les données à partir d'un fichier CSV appelé course.csv, qui contient des informations sur les différents cours offerts par une université. Vous générez le fichier de configuration de manière interactive à partir de l'utilitaire runMigrator.

Vous pouvez également préparer le fichier de configuration avec les détails de la source et de l'évier identifiés. Voir Informations de référence sur le type Oracle NoSQL Database Migrator.

Conditions requises

Procédure

Pour migrer des données du fichier course.csv vers Oracle NoSQL Database Cloud Service, procédez comme suit :

  1. Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire Oracle NoSQL Database Migrator.

  2. Pour générer le fichier de configuration à l'aide d'Oracle NoSQL Database Migrator, exécutez la commande runMigrator sans aucun paramètre d'exécution.

    [~/nosql-migrator-1.8.0]$./runMigrator

  3. Comme vous n'avez pas fourni le fichier de configuration en tant que paramètre d'exécution, l'utilitaire vous invite à générer la configuration maintenant. Entrez y.

    Vous pouvez choisir un emplacement pour le fichier de configuration ou conserver l'emplacement par défaut en appuyant sur Enter key.

    Configuration file is not provided. Do you want to generate
configuration? (y/n) [n]: y
Generating a configuration file interactively.

Enter a location for your config [./migrator-config.json]:
./migrator-config.json already exist. Do you want to overwrite?(y/n) [n]: y

  4. En fonction des invites de l'utilitaire, sélectionnez vos options pour la configuration Source.

    Select the source:
1) nosqldb

2) nosqldb_cloud

3) file

4) object_storage_oci

5) aws_s3

#? 3

Configuration for source type=file
Select the source file format:
1) json

2) mongodb_json

3) dynamodb_json

4) csv

#? 4

  5. Indiquez le chemin d'accès au fichier CSV source. En outre, en fonction des invites de l'utilitaire, vous pouvez choisir de réordonner les noms de colonne, de sélectionner la méthode d'encodage et de couper les espaces de queue de la table cible.

    Enter path to a file or directory containing csv data: [~/nosql-migrator]/course.csv
Does the CSV file contain a headerLine? (y/n) [n]: n
Do you want to reorder the column names of NoSQL table with respect to
CSV file columns? (y/n) [n]: n
Provide the CSV file encoding. The supported encodings are:
UTF-8,UTF-16,US-ASCII,ISO-8859-1. [UTF-8]:

Do you want to trim the tailing spaces? (y/n) [n]: n

  6. En fonction des invites de l'utilitaire, sélectionnez l'option nosqldb_cloud pour la configuration de l'évier.

    Select the sink:
1) nosqldb

2) nosqldb_cloud

#? 2

  7. Indiquez l'URL du point d'extrémité ou l'ID région de votre location et sélectionnez le type d'authentification pour que l'utilitaire Migrator puisse accéder à Oracle NoSQL Database Cloud Service.

    Configuration for sink type=nosqldb_cloud
Enter endpoint URL or region ID of the Oracle NoSQL Database Cloud: us-ashburn-1
Select the authentication type:
1) credentials_file

2) instance_principal

3) delegation_token

4) session_token

5) oke_workload_identity

#? 1

  8. En fonction des invites de l'utilitaire, indiquez le nom du fichier de données d'identification à utiliser pour l'authentification, le profil de données d'identification, l'ID compartiment et le nom de la table dans laquelle vous voulez copier les données au niveau du puits.

    Enter path to the file containing OCI credentials [/home/<user>/.oci/config]:
Enter the profile name in OCI credentials file [DEFAULT]:
Enter the compartment name or id of the table []: ua_nosql
Enter table name: course

  9. Entrez votre choix pour définir la valeur de durée de vie. La valeur par défaut est n.

    Include TTL data? If you select 'yes' TTL value provided by the
source will be set on imported rows. (y/n) [n]: y
Would you like to provide TTL reference time?(y/n) [n]: n

  10. Sur la base des invites de l'utilitaire, indiquez si la table cible doit être créée au moyen de l'outil Oracle NoSQL Database Migrator. Si la table est déjà créée, il est suggéré de fournir n. Si la table n'est pas créée, l'utilitaire demande le chemin du fichier contenant les commandes LDD pour le schéma de la table cible.

    Would you like to create table as part of migration process?
Use this option if you want to create table through the migration tool.
If you select yes, you will be asked to provide a file that contains
table DDL or to use schema provided by the source or default schema.
(y/n) [n]: y
Enter path to a file containing table DDL: [~/nosql-migrator]/mytable_schema.ddl

  11. Entrez les valeurs de débit et d'affectation de stockage pour la table de puits.

    Would you like to use on demand read and write units? (y/n) [n]: n
Enter read throughput in KB of new table: 100
Enter write throughput in KB of new table: 60
Enter storage size in GB of new table: 1
Enter percentage of table write units to be used for migration operation.
(1-100) [90]: 90

  12. Entrez vos choix pour déterminer si les enregistrements doivent être remplacés ou non si la table est déjà disponible au niveau de l'évier. Vous pouvez également ajouter des transformations à vos données sources.

    would you like to overwrite records which are already present?
If you select 'no' records with same primary key will be skipped [y/n] [y]: y
Enter store operation timeout in milliseconds. [5000]:
Would you like to add transformations to source data? (y/n) [n]: n
Would you like to continue migration if any data fails to be migrated?
 (y/n) [n]: n

  13. L'utilitaire affiche la configuration générée à l'écran.

    {
  "source" : {
    "type" : "file",
    "format" : "csv",
    "dataPath" : "[~/nosql-migrator]/course.csv",
    "hasHeader" : false,
    "csvOptions" : {
      "encoding" : "UTF-8",
      "trim" : false
    }
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "course",
    "compartment" : "ua_nosql",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "schemaPath" : "[~/nosql-migrator]/mytable_schema.ddl"
    },
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  14. Enfin, l'utilitaire vous invite à spécifier si la migration doit être effectuée à l'aide du fichier de configuration généré. L'option par défaut est y.

    Remarque :

    Si vous sélectionnez n, la migration des données n'est pas lancée. Le fichier de configuration généré est enregistré dans le répertoire Migrator. Utilisez l'une des commandes suivantes pour exécuter l'utilitaire de migration avec l'option de fichier de configuration.

    ./runMigrator -c ./migrator-config.json

    ./runMigrator --config ./migrator-config.json

    Would you like to run the migration with above configuration?
If you select no, you can use the generated configuration file to
run the migration using:
./runMigrator --config ./migrator-config.json
(y/n) [y]: y

  15. NoSQL Database Migrator copie vos données du fichier CSV vers Oracle NoSQL Database Cloud Service.

    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: create table if not exists course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id)),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
migration started
[csv file source] : start parsing CSV records from file: course.csv
Migration success for source course. read=4,written=4,failed=0
Migration is successful for all the sources.
migration completed.
Records provided by source=4, Records written to sink=4, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 395ms
Migration completed.

Vérification

Pour vérifier la migration, vous pouvez vous connecter à la console Oracle NoSQL Database Cloud Service et accéder à la table course. La table contient les données sources. Pour la procédure d'accès à la console, voir l'article Accès au service à partir de la console d'infrastructure dans le document Oracle NoSQL Database Cloud Service.

Rubriques connexes