Utilisation d'Oracle NoSQL Database Migrator

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

Migrateur Oracle NoSQL Database est un outil qui vous permet de migrer des tables Oracle NoSQL d'une source de données vers une autre. Cet outil peut fonctionner sur des tables dans 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 physiques différents. Les formats de données pris en charge sont JSON, Parquet, JSON au format MongoDB, JSON au format DynamoDB et 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 informations suivantes :

Rubriques connexes

Aperçu

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

Plusieurs situations peuvent nécessiter la migration des tables NoSQL de ou à Oracle NoSQL Database. Par exemple, une équipe de développeurs améliorant une application NoSQL Database peut vouloir tester le code mis à jour dans l'instance Oracle NoSQL Database Cloud Service (NDCS) locale à l'aide de cloudim. Pour vérifier tous les scénarios de test possibles, ils doivent définir les données de test similaires aux 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 sur place vers le nuage et vice-versa, pour le développement ou les tests.

Dans tous ces cas, et bien d'autres encore, vous pouvez utiliser Oracle NoSQL Database Migrator pour déplacer vos tables NoSQL d'une source de données à une autre, par exemple 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 le montre 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). En substance, cet utilitaire exporte les données de la source sélectionnée et les importe dans l'évier. 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 s'exécute 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.

Le service Migrateur Oracle NoSQL Database est conçu pour prendre en charge des sources et des éviers supplémentaires à l'avenir. Pour obtenir la liste des sources et des récepteurs pris en charge par Oracle NoSQL Database Migrator à partir de la version courante, voir Sources et récepteurs pris en charge.

Description de l'illustration migrator_overview.eps

Terminologie utilisée avec Oracle NoSQL Database Migrator

Découvrez en détail les différents termes utilisés dans le diagramme ci-dessus.

Source : Entité à partir de laquelle les tables NoSQL sont exportées pour la migration. Voici quelques exemples de sources : Oracle NoSQL Database sur place ou en nuage, fichier JSON, fichier JSON au format MongoDB, fichier JSON au format DynamoDB et fichiers CSV.
Dirigeant : Entité qui importe les tables NoSQL à partir de NoSQL Database Migrator. Voici quelques exemples de puits : Oracle NoSQL Database sur place ou en nuage et fichier JSON.

L'outil NoSQL Database Migrator prend en charge différents types de sources et d'éviers (médias physiques ou référentiels de données) et de formats de données (c'est-à-dire la façon dont les données sont représentées dans la source ou l'évier). Les formats de données pris en charge sont JSON, Parquet, JSON au format MongoDB, JSON au format DynamoDB et fichiers CSV. Les types source et d'évier 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.

Tuyau de migration : Les données d'une source seront transférées vers l'évier par NoSQL Database Migrator. Cela peut être visualisé en tant que tuyau de migration.
Transformations : Vous pouvez ajouter des règles pour modifier les données de la table NoSQL dans le canal de migration. Ces règles sont appelées transformations. Le service Migrateur Oracle NoSQL Database autorise les transformations de données dans les champs ou colonnes de niveau supérieur uniquement. Il ne vous permet pas de transformer les données dans les champs imbriqués. Voici quelques exemples de transformations autorisées :
- Déposer ou ignorer une ou plusieurs colonnes,
- Renommer une ou plusieurs colonnes, ou
- Agréger plusieurs colonnes en un seul champ, généralement un champ JSON.

Fichier de configuration : Vous définissez tous les paramètres requis pour l'activité de migration dans un format JSON. Plus tard, vous transmettez ce fichier de configuration en tant que paramètre unique à la commande runMigrator à partir de l'interface de ligne de commande. Un format de fichier de configuration type ressemble à celui indiqué ci-dessous.

{
 "source": {
   "type" : <source type>,
   //source-configuration for type. See Source Configuration Templates  .
 },
 "sink": {
   "type" : <sink type>,
   //sink-configuration for type. See Sink Configuration Templates  .
 },
 "transforms" : {
   //transforms configuration. See Transformation Configuration Templates  .
 },
 "migratorVersion" : "<migrator version>",
 "abortOnError" : <true|false>
}

Groupe	Paramètres	Obligatoire (O/N)	Objet	Valeurs prises en charge
`source`	`type`	Y	Représente la source à partir de laquelle migrer les données. La source fournit des données et des métadonnées (le cas échéant) pour la migration.	Pour connaître la valeur `type` pour chaque source, voir Sources et puits pris en charge.
`source`	configuration de la source pour le type	Y	Définit la configuration de la source. Ces paramètres de configuration sont spécifiques au type de source sélectionné ci-dessus.	Voir Modèles de configuration de la source pour obtenir la liste complète des paramètres de configuration pour chaque type de source.
`sink`	`type`	Y	Représente le puits vers lequel migrer les données. L'évier est la cible ou la destination de la migration.	Pour connaître la valeur `type` pour chaque source, voir Sources et puits pris en charge.
`sink`	configuration de l'évier pour le type	Y	Définit la configuration de l'évier. Ces paramètres de configuration sont spécifiques au type d'évier sélectionné ci-dessus.	Voir Modèles de configuration de récepteur pour obtenir la liste complète des paramètres de configuration pour chaque type de récepteur.
`transforms`	configuration des transformations	N	Définit les transformations à appliquer aux données du canal de migration.	Voir Modèles de configuration de transformation pour obtenir la liste complète des transformations prises en charge par l'outil de migration de données NoSQL.
-	`migratorVersion`	N	Version de l'outil de migration de données NoSQL	-
-	`abortOnError`	N	Indique si l'activité de migration doit être arrêtée en cas d'erreur ou non. La valeur par défaut est Vrai, ce qui indique que la migration s'arrête chaque fois qu'elle rencontre une erreur de migration. Si vous réglez cette valeur à Faux, la migration se poursuit même en cas d'échec d'enregistrements ou d'autres erreurs de migration. Les enregistrements en échec et les erreurs de migration seront enregistrés en tant qu'AVERTISSEMENTS sur le terminal de l'interface de ligne de commande.	vrai, faux

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 l'outil de migration d'Oracle NoSQL Database.

Vous pouvez utiliser n'importe quelle combinaison d'une source et d'un puits valides de cette table pour l'activité de migration. Toutefois, vous devez vous assurer qu'au moins l'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 la table NoSQL d'un fichier à un autre.

Type (valeur)	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
	MongoDB JSON (`mongodb_json`)	Y	N
	DynamoDB JSON (`dynamodb_json`)	Y	N
	Parquet(`parquet`)	N	Y
	CSV (`csv`)	Y	N
OCI Object Storage (`object_storage_oci`)	JSON (`json`)	Y	Y
	MongoDB JSON (`mongodb_json`)	Y	N
	Parquet(`parquet`)	N	Y
	CSV (`csv`)	Y	N
AWS S3	DynamoDB JSON (`dynamodb_json`)	Y	N

Note :

De nombreux paramètres de configuration sont communs dans la configuration source et de l'évier. Pour faciliter la référence, la description de ces paramètres est répétée pour chaque source et puits dans les sections de documentation, qui expliquent les formats de fichiers de configuration pour différents types de sources et puits. Dans tous les cas, la syntaxe et la sémantique des paramètres du même nom sont identiques.

Sécurité des sources et des récepteurs

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

Toutes les sources et tous les éviers 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 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 basée sur un portefeuille

Si une installation d'Oracle NoSQL Database utilise l'authentification basée sur Oracle Wallet, vous avez besoin d'un fichier JAR supplémentaire qui fait partie de l'installation EE. Pour plus d'informations, voir Oracle Wallet.

Sans ce fichier JAR, vous obtiendrez le message d'erreur suivant :

Impossible de trouver kvstore-ee.jar dans le répertoire lib. Copiez kvstore-ee.jar dans le répertoire lib.

Pour empêcher l'exception affichée ci-dessus, vous devez copier le fichier kvstore-ee.jar de votre ensemble de serveurs EE vers le répertoire <MIGRATOR_HOME>/lib. <MIGRATOR_HOME> est le répertoire nosql-migrator-M.N.O/ créé en extrayant l'ensemble Oracle NoSQL Database Migrator et M.N.O représente les numéros release.major.minor du logiciel. Par exemple, nosql-migrator-1.1.0/lib.

Note :

L'authentification basée sur un portefeuille n'est prise en charge que dans Enterprise Edition (EE) d'Oracle NoSQL Database.

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 des principaux) autorisés à effectuer des actions sur les ressources de service. Chaque instance de calcul possède sa propre identité et s'authentifie à l'aide des certificats ajoutés.

L'outil de migration d'Oracle NoSQL Database permet de se connecter à des sources et des éviers de stockage d'objets en nuage et OCI NoSQL à l'aide de l'authentification du 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 source en nuage et d'évier NoSQL. Pour plus d'informations sur les paramètres de configuration pour différents types de sources et de puits, voir Modèles de configuration de source et Modèles de configuration de récepteur.

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

Flux de travail pour Oracle NoSQL Database Migrator

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

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

Description de l'illustration migrator_flow.eps

Télécharger l'utilitaire de migration de données NoSQL

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

Note :

L'utilitaire de migration 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 de données et l'évier. 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'émetteur sera un fichier JSON. Assurez-vous que la source et le puits identifiés sont pris en charge par l'outil de migration d'Oracle NoSQL Database en faisant référence aux sources et puits 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 puits, et les créer.

Identifier le schéma de table de l'émetteur : Si l'émetteur est Oracle NoSQL Database sur place ou en nuage, vous devez identifier le schéma de la table de l'émetteur et vous assurer que les données sources correspondent au schéma cible. S'il y a lieu, utilisez des transformations pour mapper les données sources à la table source.
- Schéma par défaut : NoSQL Database Migrator fournit une option pour créer une table avec le schéma par défaut sans avoir à prédéfinir le schéma pour la table. Cette fonction est utile principalement lors du chargement de fichiers sources JSON dans Oracle NoSQL Database.
  Si la source est un fichier JSON au format MongoDB, le schéma par défaut de la table est le suivant :
```
CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))
```
  Où :
  
  - tablename = valeur fournie pour l'attribut de table dans la configuration.
  
  - ID = valeur _id de chaque document du fichier source JSON exporté mongoDB.
  
  - DOCUMENT = Pour chaque document dans le fichier exporté mongoDB, le contenu, à l'exclusion du champ _id, est agrégé dans la colonne DOCUMENT.
  Si la source est un fichier JSON au format DynamoDB, le schéma par défaut de la table est 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 la table d'évier 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 de base de données Dynamo agrégés dans une colonne JSON NoSQL
  
  Si le format source est un fichier CSV, un schéma par défaut n'est pas pris en charge pour la table cible. Vous pouvez créer un fichier de schéma avec une définition de table contenant le même nombre de colonnes et de types de données que le fichier CSV source. Pour plus de détails sur la création du fichier de schéma, voir Fourniture du schéma de table.
  Pour toutes les autres sources, le schéma par défaut est le suivant :
```
CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))
```
  Où :
  
  - tablename = valeur fournie pour l'attribut de table dans la configuration.
  
  - ID = Valeur LONG générée automatiquement.
  
  - DOCUMENT = L'enregistrement JSON fourni par la source est agrégé dans la colonne DOCUMENT.
  
  Note :
  Si la valeur _id n'est pas fournie en tant que chaîne dans le fichier JSON au format MongoDB, NoSQL Database Migrator la convertit en chaîne avant de l'insérer dans le schéma par défaut.
Fournir un schéma de table : NoSQL Database Migrator permet à la source de fournir des définitions de schéma pour les données de table à l'aide de l'attribut schemaInfo. L'attribut schemaInfo est disponible dans toutes les sources de données qui n'ont pas de schéma implicite déjà défini. Les magasins de données de puits peuvent choisir l'une des options suivantes.
- Utilisez le schéma par défaut défini par NoSQL Database Migrator.
- Utilisez le schéma fourni par la source.
- Remplacez le schéma fourni par la source en définissant son propre schéma. Par exemple, si vous voulez transformer les données du schéma source vers un autre schéma, vous devez remplacer le schéma fourni par la source et utiliser la capacité de transformation de l'outil NoSQL Database Migrator.
Description de l'illustration source_sink_schema_example.png

Le fichier de schéma de table, par exemple mytable_schema.DDL, peut inclure des énoncés LDD de table. L'outil NoSQL Database Migrator exécute ce fichier de schéma de table avant de lancer la migration. L'outil de migration ne prend pas en charge plus d'une instruction LDD par ligne dans le fichier de schéma. Par exemple,
```
CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))
```
Note :
La migration échouera si la table est présente à l'évier et que le LDD dans schemaPath est différent de la table.
Créer une table de dérivation : Une fois que vous avez identifié le schéma de la table de dérivation, créez-la au moyen de l'interface de ligne de commande d'administration ou à l'aide de l'attribut schemaInfo du fichier de configuration de dérivation. Voir Modèles de configuration de récepteur.

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.

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

Vous pouvez choisir d'inclure les métadonnées de durée de vie pour les rangées de table avec les données réelles lors de la migration des tables NoSQL. L'outil de migration de bases de données NoSQL fournit un paramètre 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. En outre, l'outil permet de sélectionner le délai d'expiration relatif des enregistrements de table pendant l'opération d'importation. Vous pouvez éventuellement exporter ou importer des métadonnées de durée de vie à l'aide du paramètre includeTTL.

Note :

La prise en charge de la migration des métadonnées de durée de vie pour les rangées de table est uniquement disponible pour Oracle NoSQL Database et Oracle NoSQL Database Cloud Service.

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

Lorsqu'une table est exportée, les données de durée de vie sont exportées pour les rangées de table ayant un délai d'expiration valide. Si une ligne n'expire pas, elle n'est pas incluse explicitement dans les données exportées car sa valeur d'expiration est toujours 0. Les informations de durée de vie sont contenues dans l'objet JSON _metadata pour chaque rangée exportée. NoSQL Database Migrator exporte le délai d'expiration de chaque rangée en tant que nombre de millisecondes depuis l'heure 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 d'un paramètre de configuration, includeTTL. L'opération d'importation traite les cas d'utilisation suivants lors de la migration de rangées de table contenant des métadonnées de durée de vie. Ces cas d'utilisation s'appliquent uniquement lorsque le paramètre de configuration includeTTL est spécifié.

Dans les cas d'utilisation 2 et 3, 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 en cours d'exécution. Mais 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 l'heure d'expiration et importer des rangées qui, autrement, expireront immédiatement.

Cas d'utilisation 1 : Aucune information sur les métadonnées de durée de vie n'est présente dans la rangée de la table d'importation.
Lorsque vous importez un fichier source JSON produit à partir d'une source externe ou exporté à l'aide de versions antérieures de l'outil de migration, la rangée d'importation ne contient pas d'informations de durée de vie. Mais comme le paramètre de configuration includeTTL est égal à true, l'outil de migration a défini la durée de vie = 0 pour la rangée de table, ce qui signifie que la rangée de table d'importation n'expire jamais.
Cas d'utilisation 2 : La valeur de durée de vie de la rangée de la table source a expiré par rapport à l'heure de référence lors de l'importation de la rangée de la table.
Lorsque vous exportez une ligne de table dans un fichier et que vous essayez de l'importer après l'heure d'expiration de la ligne de table, celle-ci est ignorée et n'est pas écrite dans le magasin.
Cas d'utilisation 3 : La valeur de durée de vie de la rangée de la table source n'est pas expirée par rapport à l'heure de référence lors de l'importation de la rangée de la table.
Lorsque vous exportez une ligne de table dans un fichier et que vous essayez de l'importer avant l'heure d'expiration de la ligne de table, celle-ci est importée avec une valeur de durée de vie. Mais la nouvelle valeur de durée de vie pour la rangée de table peut ne pas être égale à la valeur de durée de vie exportée en raison des contraintes de fenêtre de nombre entier d'heures et de jours dans la classe TimeToLive. Par exemple,
Rangée de tableau exportée
```
{
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
    "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC
  }
}
```
L'heure de référence lors de l'importation est 1629707962582, qui est le lundi 23 août 2021 8:39 :22.582 AM.
Rangée de tableau importée
```
{
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
    "ttl" :  1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC
  }
}
```

Importer des données dans un évier avec une colonne IDENTITY

Vous pouvez importer les données d'une source valide dans une table source (services sur place ou en nuage) avec une colonne IDENTITY. Vous créez la colonne IDENTITY en tant que 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 le guide de référence SQL.

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

Table source avec la colonne IDENTITY comme GENERATED ALWAY AS IDENTITY

Considérez une table source avec la colonne IDENTITY créée en tant que GENERATED ALWAYS AS IDENTITY. L'importation des données dépend du fait que la source fournisse 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 fichier JSON vers la table Oracle NoSQL Database en tant qu'émetteur. Le schéma de la table source 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 de l'utilisateur Résultat de la migration

Condition source	Action de l'utilisateur	Résultat de la migration
Cas 1 : Les données sources ne fournissent pas de valeur pour le champ IDENTITY de la table source. 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.	La migration des données a réussi. Les valeurs de colonne IDENTITY sont générées automatiquement. Données migrées dans la table de l'évier 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 source. 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 d'ID dans le modèle de configuration de l'évier. `"transforms" : { "ignoreFields" : ["ID"] }`	La migration des données a réussi. 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 l'évier 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".`

Cas 1 : Les données sources ne fournissent pas de valeur pour le champ IDENTITY de la table source.

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.

La migration des données a réussi. Les valeurs de colonne IDENTITY sont générées automatiquement. Données migrées dans la table de l'évier 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 source.

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 d'ID dans le modèle de configuration de l'évier.

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

La migration des données a réussi. 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 l'évier 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 transformation, voir la rubrique Modèles de configuration de transformation.

Table source avec colonne IDENTITY comme GENERATED BY DEFAULT AS IDENTITY

Considérez une table source avec la colonne IDENTITY créée en tant que GENERATED BY DEFAULT AS IDENTITY. L'importation des données dépend du fait que la source fournisse 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 fichier JSON vers la table Oracle NoSQL Database en tant qu'émetteur. Le schéma de la table source 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 de l'utilisateur Résultat de la migration

Condition source	Action de l'utilisateur	Résultat de la migration
Cas 1 : Les données sources ne fournissent pas de valeur pour le champ IDENTITY de la table source. 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.	La migration des données a réussi. Les valeurs de colonne IDENTITY sont générées automatiquement. Données migrées dans la table de l'évier 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 source 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 d'ID dans le modèle de configuration de l'évier (recommandé). `"transforms" : { "ignoreFields" : ["ID"] }`	La migration des données a réussi. 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 l'évier 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.	La migration des données a réussi. Les valeurs `ID` fournies à partir de la source sont copiées dans la colonne `ID` de la table source. Lorsque vous essayez d'insérer un enregistrement supplémentaire dans la table sans fournir de valeur de code, le générateur de séquences tente de générer automatiquement la valeur de 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 source. 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équence pour des informations supplémentaires. 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 source. Pour utiliser l'attribut START WITH pour effectuer cette modification, reportez-vous à l'exemple ci-dessous : Exemple : Données migrées dans la table d'évier 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 à insérer par le générateur de séquences dans la colonne ID, extrayez la valeur maximale du champ `ID` à l'aide de l'interrogation suivante : `SELECT max(ID) FROM migrateID` Sortie : `{"Column_1":3}` La valeur maximale de la colonne `ID` dans la table d'évitement 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 démarre à 4. Maintenant, lorsque vous insérez des enregistrements dans la table source sans fournir les valeurs d'ID, le générateur de séquences génère automatiquement les valeurs d'ID à partir de 4, évitant ainsi la duplication des ID.

Cas 1 : Les données sources ne fournissent pas de valeur pour le champ IDENTITY de la table source.

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.

La migration des données a réussi. Les valeurs de colonne IDENTITY sont générées automatiquement. Données migrées dans la table de l'évier 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 source 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 d'ID dans le modèle de configuration de l'évier (recommandé).

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

La migration des données a réussi. 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 l'évier 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.

La migration des données a réussi. Les valeurs ID fournies à partir de la source sont copiées dans la colonne ID de la table source.

Lorsque vous essayez d'insérer un enregistrement supplémentaire dans la table sans fournir de valeur de code, le générateur de séquences tente de générer automatiquement la valeur de 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 source. 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équence pour des informations supplémentaires.

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 source. Pour utiliser l'attribut START WITH pour effectuer cette modification, reportez-vous à l'exemple ci-dessous :

Exemple : Données migrées dans la table d'évier 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 à insérer par le générateur de séquences dans la colonne ID, extrayez la valeur maximale du champ ID à l'aide de l'interrogation suivante :

SELECT max(ID) FROM migrateID

Sortie :

{"Column_1":3}

La valeur maximale de la colonne ID dans la table d'évitement 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 démarre à 4.

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

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

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 :

En créant le fichier de configuration à l'aide des options d'exécution de la commande runMigrator, comme indiqué 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 le fichier de configuration créé par l'utilitaire, vous pouvez soit poursuivre l'activité de migration au cours de la même exécution, soit 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 modification ou personnalisation afin de répondre à vos besoins futurs. Vous pouvez utiliser le fichier de configuration personnalisé pour la migration ultérieurement.
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 puits, voir Informations de référence sur Oracle NoSQL Database Migrator.
```
[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
```

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 vers 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.

Niveaux de journalisation

Pour contrôler le comportement de journalisation au moyen de l'outil NoSQL Database Migrator, transmettez le paramètre d'exécution --log-level ou -l à la commande runMigrator. Vous pouvez spécifier la quantité d'informations de journal à écrire en transmettant la valeur de niveau de journal appropriée.

$./runMigrator --log-level <loglevel>

Exemple :

$./runMigrator --log-level debug

Table - Niveaux de journal pris en charge pour NoSQL Database Migrator

Niveau de journalisation	Description
avertissement	Sert à imprimer les erreurs et les avertissements.
info (par défaut)	Affiche le statut de progression de la migration des données, par exemple la validation de la source, la validation de l'évier, la création de tables et le nombre d'enregistrements de données migrés.
debug	Imprime des informations de débogage supplémentaires.
all	Imprime tout. Ce niveau active tous les niveaux de journalisation.

Fichier journal :
Vous pouvez spécifier le nom du fichier journal à l'aide du paramètre --log-file ou -f. Si --log-file est transmis en tant que paramètre d'exécution à la commande runMigrator, NoSQL Database Migrator écrit tous les messages de journal dans le fichier sinon dans la sortie standard.
```
$./runMigrator --log-file <log file name>
```
Exemple :
```
$./runMigrator --log-file nosql_migrator.log
```

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 de l'outil de migration d'Oracle NoSQL Database pour des cas d'utilisation spécifiques. Vous trouverez 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 informations suivantes :

Migrer d'Oracle NoSQL Database Cloud Service vers un fichier JSON

Cet exemple montre comment utiliser l'outil de migration d'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) vers un fichier JSON.

Cas d'utilisation

Une organisation décide d'entraîner un modèle à l'aide des données Oracle NoSQL Database Cloud Service (NDCS) afin de prédire les comportements à venir et de 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, voyons comment migrer les données et la définition de schéma d'une table NoSQL nommée myTable de NDCS vers un fichier JSON.

Conditions requises

Identifiez la source et le puits de la migration.
- Source : Oracle NoSQL Database Cloud Service
- Évier : fichier JSON
Identifiez vos données d'identification pour le nuage OCI et saisissez-les dans le fichier de configuration OCI. Enregistrez le fichier de configuration dans /home/.oci/config. Voir Obtention de données d'identification.
```
[DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
```
Identifiez le point d'extrémité de la région et le nom du compartiment pour Oracle NoSQL Database Cloud Service.
- point d'extrémité : us-phoenix-1
- compartiment : developers

Procédure

Pour migrer les données et la définition de schéma de myTable d'Oracle NoSQL Database Cloud Service vers un fichier JSON :

Ouvrez l'invite de commande et naviguez jusqu'au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.
Pour générer le fichier de configuration à l'aide de NoSQL Database Migrator, exécutez la commande runMigrator sans paramètres d'exécution.
```
[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator
```
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.
```

Selon les invites de l'utilitaire, choisissez 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
#? 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]:

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 file to store JSON data: /home/apothula/nosqlMigrator/myTableJSON
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/apothula/nosqlMigrator/myTableSchema

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]:
```
Entrez votre choix pour déterminer s'il faut poursuivre la migration 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]:
```

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

generated configuration is:
{
  "source": {
    "type": "nosqldb_cloud",
    "endpoint": "us-phoenix-1",
    "table": "myTable",
    "compartment": "developers",
    "credentials": "/home/apothula/.oci/config",
    "credentialsProfile": "DEFAULT",
    "readUnitsPercent": 90,
    "requestTimeoutMs": 5000
  },
  "sink": {
    "type": "file",
    "format": "json",
    "schemaPath": "/home/apothula/nosqlMigrator/myTableSchema",
    "pretty": true,
    "dataPath": "/home/apothula/nosqlMigrator/myTableJSON"
  },
  "abortOnError": true,
  "migratorVersion": "1.0.0"
}

Enfin, l'utilitaire vous invite à 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/apothula/nosqlMigrator/NDCS2JSON
(y/n) [y]:
```

L'outil de migration de bases de données NoSQL 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.
Elapsed time: 0min 1sec 277ms
Migration completed.

Validation

Pour valider la migration, vous pouvez ouvrir les fichiers JSON Sink et voir le schéma et les données.

-- Exported myTable Data
 
[~/nosqlMigrator]$cat myTableJSON
{
  "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)))

Migrer d'Oracle NoSQL Database sur place vers Oracle NoSQL Database Cloud Service

Cet exemple montre comment utiliser Oracle NoSQL Database Migrator 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 étudiez les 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. À titre de 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, voyons comment migrer les données et la définition de schéma d'une table NoSQL nommée myTable de la base de données NoSQL KVStore 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

Identifiez la source et le puits de la migration.
- Source : Oracle NoSQL Database
- Évier : Oracle NoSQL Database Cloud Service
Identifiez vos données d'identification pour le nuage OCI et saisissez-les dans le fichier de configuration OCI. Enregistrez le fichier de configuration dans /home/.oci/config. Voir Obtention de données d'identification dans Utilisation d'Oracle NoSQL Database Cloud Service.
```
[DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
```
Identifiez le point d'extrémité de la région et le nom du compartiment pour Oracle NoSQL Database Cloud Service.
- point d'extrémité : us-phoenix-1
- compartiment : developers
Identifiez les détails suivants pour KVStore sur place :
- storeName: kvstore
- helperHosts: <hostname>:5000
- table : myTable

Procédure

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

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

{
  "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.0.0"
}

Ouvrez l'invite de commande et naviguez jusqu'au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.
Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.
```
[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
```

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 fichiers JSON vers Oracle NoSQL Database Cloud Service

Cet exemple montre l'utilisation d'Oracle NoSQL Database Migrator pour copier des données à partir d'une source de fichier 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 de base de données NoSQL. Comme son contenu source est au format de fichier JSON, ils cherchent un moyen de les 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

Identifiez la source et le puits de la migration.

Source : fichier source JSON.

SampleData.json est le fichier source. Il contient plusieurs documents JSON avec un document par ligne, délimité par un nouveau caractère de ligne.

{"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-03-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-02T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-02T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-02T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":7,"val_json":{"array":["a","b","c"],"date":"2023-02-20T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-01-20T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-01-22T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":4,"val_json":{"array":["j","k","l"],"date":"2023-02-03T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-03T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-02-03T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}

Évier : Oracle NoSQL Database Cloud Service.

Identifiez vos données d'identification pour le nuage OCI et saisissez-les dans le fichier de configuration. Enregistrez le fichier de configuration dans /home/user/.oci/config. Pour plus de détails, voir Obtention de données d'identification dans Utilisation du service Oracle NoSQL Database Cloud Service.
```
[DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
```
Identifiez le point d'extrémité de la région et le nom du compartiment pour Oracle NoSQL Database Cloud Service.
- point d'extrémité : us-ashburn-1
- compartiment : Training-NoSQL
Identifiez les détails suivants pour le fichier source JSON :
- schemaPath: <absolute path to the schema definition file containing DDL statements for the NoSQL table at the sink>.
  Dans cet exemple, le fichier LDD est schema_json.DDL.
```
create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY
    KEY(id));
```
  L'outil de migration d'Oracle NoSQL Database fournit une option pour créer une table avec le schéma par défaut si schemaPath n'est pas fourni. Pour plus de détails, voir Identifier la source et le puits dans le flux de travail pour Oracle NoSQL Database Migrator.
- Chemin de données : <absolute path to a file or directory containing the JSON data for migration>.

Procédure

Pour migrer le fichier source JSON de SampleData.json vers Oracle NoSQL Database Cloud Service, procédez comme suit :

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

{
  "source" : {
    "type" : "file",
    "format" : "json",
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.5.0]/schema_json.ddl"
    },
    "dataPath" : "[~/nosql-migrator-1.5.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.5.0"
}

Ouvrez l'invite de commande et naviguez jusqu'au répertoire dans lequel vous avez extrait l'utilitaire Oracle NoSQL Database Migrator.
Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.
```
[~/nosql-migrator-1.5.0]$./runMigrator --config <complete/path/to/the/config/file>
```

L'utilitaire procède à la migration des données, comme indiqué ci-dessous. La table Migrate_JSON est créée au niveau de l'évier 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 permettant d'accéder à 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 "Figure - Tables de la console Oracle NoSQL Database Cloud Service"

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

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

Migrer du fichier JSON MongoDB vers Oracle NoSQL Database Cloud Service

Cet exemple montre comment utiliser Oracle NoSQL Database Migrator pour copier des données formatées Mongo-DB dans 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 de base de données NoSQL. Comme ses tables et ses données NoSQL se trouvent dans MongoDB, elles recherchent un moyen de migrer ces tables et ces données vers Oracle NDCS.

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

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"}]}

MongoDB prend en charge deux types d'extension au format JSON des fichiers, le mode canonique et le mode relaxé. Vous pouvez fournir le fichier JSON au format MongoDB généré à l'aide de l'outil mongoexport en mode canonique ou relaxé. Les deux modes sont pris en charge par NoSQL Database Migrator pour la migration.

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, voyons comment migrer un fichier JSON au format MongoDB vers NDCS. Nous utiliserons un fichier de configuration créé manuellement pour cet exemple.

Conditions requises

Identifiez la source et le puits de la migration.
- Source : Fichier JSON formaté par MongoDB
- Évier : Oracle NoSQL Database Cloud Service
Extrayez les données de Mongo DB à l'aide de l'utilitaire mongoexport. Voir mongoexport pour plus d'informations.
Créez une table NoSQL dans l'évier avec un schéma de table qui correspond aux données du fichier JSON au format Mongo-DB. Vous pouvez également indiquer à NoSQL Database Migrator de créer une table avec la structure de schéma par défaut en réglant l'attribut defaultSchema à Vrai.
Note :
Pour une source JSON formatée MongoDB, le schéma par défaut de la table est le suivant :
```
CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))
```
Où :
- tablename = valeur de la configuration de table.
- ID = valeur _id du fichier source JSON exporté mongoDB.
- DOCUMENT = Tout le contenu du fichier source JSON exporté mongoDB est agrégé dans la colonne DOCUMENT, à l'exclusion du champ _id.
Identifiez vos données d'identification pour le nuage OCI et saisissez-les dans le fichier de configuration OCI. Enregistrer le fichier de configuration dans /home/.oci/config. Voir Obtention de données d'identification dans Utilisation d'Oracle NoSQL Database Cloud Service.
```
[DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
```
Identifiez le point d'extrémité de la région et le nom du compartiment pour Oracle NoSQL Database Cloud Service.
- point d'extrémité : us-phoenix-1
- compartiment : developers

Procédure

Pour migrer les données JSON au format MongoDB vers Oracle NoSQL Database Cloud Service :

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

{
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "mongoImport",
    "compartment" : "developers",
    "schemaInfo" : {
      "defaultSchema" : true,
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.0.0"
}

Ouvrez l'invite de commande et naviguez jusqu'au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.
Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.
```
[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
```

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

Records provided by source=29,353, Records written to sink=29,353, Records failed=0.
Elapsed time: 9min 9sec 630ms
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 du fichier JSON DynamoDB vers Oracle NoSQL Database

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

Cas d'utilisation :

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

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"}}}
{"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 copiez les données de la table DynamoDB exportées à partir du stockage AWS S3 vers un système de fichiers monté local.

Exemple :

Pour cette démonstration, vous apprendrez à migrer un fichier JSON DynamoDB vers Oracle NoSQL Database (sur place). Vous allez utiliser un fichier de configuration créé manuellement pour cet exemple.

Conditions requises

Identifiez la source et le puits de la migration.
- Source : DynamoDB Fichier JSON
- Dissipateur : Oracle NoSQL Database (sur place)
Pour importer les données de la table DynamoDB dans Oracle NoSQL Database, vous devez d'abord exporter la table DynamoDB vers S3. Reportez-vous aux étapes fournies dans Exportation des données de table DynamoDB vers Amazon S3 pour exporter votre table. Lors de l'exportation, vous sélectionnez le format DynamoDB JSON. Les données exportées contiennent des données de table DynamoDB dans plusieurs fichiers gzip, comme indiqué ci-dessous.
```
/ 01639372501551-bb4dd8c3 
|-- 01639372501551-bb4dd8c3 ==> exported data prefix
|----data
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data
|----manifest-files.json
|----manifest-files.md5
|----manifest-summary.json
|----manifest-summary.md5
|----_started
```

Vous devez télécharger les fichiers à partir d'AWS s3. La structure des fichiers après le téléchargement sera comme indiqué ci-dessous.

download-dir/01639372501551-bb4dd8c3     
|----data    
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data   
|----manifest-files.json   
|----manifest-files.md5   
|----manifest-summary.json   
|----manifest-summary.md5   
|----_started

Procédure

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

Préparez le fichier de configuration (au format JSON) avec la source identifiée et le récepteur details.See Modèles de configuration de source et Modèles de configuration de récepteur.
Vous pouvez choisir l'une des deux options suivantes.
- Option 1 : Importation d'une table DynamoDB en tant que document JSON à l'aide de la configuration de schéma par défaut.
  Ici, defaultSchema est TRUE et l'outil de migration crée donc le schéma par défaut dans l'évier. Vous devez spécifier DDBPartitionKey et le type de colonne NoSQL correspondant. Sinon, une erreur est générée.
```
{
 "source" : {
   "type" : "file",
   "format" : "dynamodb_json",
   "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>"
 },
 "sink" : {
    "type" : "nosqldb",
    "table" : "<table_name>",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"]
    "schemaInfo" : {
       "defaultSchema" : true,    
       "DDBPartitionKey" : "<PrimaryKey:Datatype>",
     },  
  },
  "abortOnError" : true,
  "migratorVersion" : "1.0.0"
}
```
  Pour une source JSON DynamoDB, le schéma par défaut pour la table est 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 la table de l'évier dans la configuration
  
  DDBPartitionKey_name = valeur fournie pour la clé de partiiton 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 de base de données Dynamo agrégés dans une colonne JSON NoSQL
- Option 2 : Importation de la table DynamoDB en tant que colonnes fixes à l'aide d'un fichier de schéma fourni par l'utilisateur.
  Ici, defaultSchema est FALSE et vous spécifiez schemaPath en tant que fichier contenant votre énoncé LDD. Pour plus de détails, voir Mappage des types DynamoDB aux types Oracle NoSQL .
  
  Note :
  Si le type de données de la table de base de données Dynamo 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 de l'évier 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 est 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.
```
{
  "source" : {
    "type" : "file",
    "format" : "dynamodb_json",
    "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb",
    "table" : "<table_name>",
    "schemaInfo" : {
      "defaultSchema" : false,
      "readUnits" : 100,
      "writeUnits" : 60,
      "schemaPath" : "<full path of the schema file with the DDL statement>",
      "storageSize" : 1
    },
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"]
  },
  "abortOnError" : true,
  "migratorVersion" : "1.0.0"
}
```
Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire Database Migrator NoSQL.
Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.
```
[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator 
--config <complete/path/to/the/JSON/config/file>
```

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.

Validation

Démarrez l'invite SQL dans KVStore.

 java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore

Vérifiez que la nouvelle table est créée avec les données sources :

desc <table_name>
SELECT * from <table_name>

Migrer du fichier JSON DynamoDB 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 dans 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 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 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 la table DynamoDB vers Amazon S3.

Exemple :

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

Conditions requises

Identifiez la source et le puits de la migration.
- Source : DynamoDB Fichier JSON dans AWS S3
- Évier : Oracle NoSQL Database Cloud Service
Identifiez la table dans AWS DynamoDB qui doit être migrée vers NDCS. Connectez-vous à votre console AWS à l'aide de vos données d'identification. Allez à DynamoDB. Sous Tables, sélectionnez la table à migrer.
Créez un seau d'objet et exportez la table vers S3. Depuis la console AWS, allez à S3. Sous Seaux, créez un nouveau seau d'objet. Retournez à DynamoDB et cliquez sur Exportations vers S3. Indiquez la table source et le seau S3 de destination, puis cliquez sur Exporter.
Reportez-vous aux étapes fournies dans Exportation des données de table DynamoDB vers Amazon S3 pour exporter votre table. Lors de l'exportation, vous sélectionnez le format DynamoDB JSON. Les données exportées contiennent des données de table DynamoDB dans plusieurs fichiers gzip, comme indiqué ci-dessous.
```
/ 01639372501551-bb4dd8c3 
|-- 01639372501551-bb4dd8c3 ==> exported data prefix
|----data
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data
|----manifest-files.json
|----manifest-files.md5
|----manifest-summary.json
|----manifest-summary.md5
|----_started
```
Vous avez besoin de données d'identification aws (y compris l'ID clé d'accès et la clé d'accès secrète) et de fichiers de configuration (données d'identification et éventuellement de configuration) pour accéder à AWS S3 à partir de l'outil de migration. Voir Définir et voir les paramètres de configuration pour plus de détails sur les fichiers de configuration. Pour plus de détails sur la création de clés d'accès, voir Création d'une paire de clés.
Identifiez vos données d'identification pour le nuage OCI et saisissez-les dans le fichier de configuration OCI. Enregistrez le fichier de configuration dans un répertoire .oci sous votre répertoire de base (~/.oci/config). Voir Obtention de données d'identification pour plus de détails.
```
[DEFAULT]              
tenancy=ocid1.tenancy.oc1....         
user=ocid1.user.oc1....         
fingerprint= 43:d1:....         
key_file=</fully/qualified/path/to/the/private/key/>              
pass_phrase=<passphrase>
```
Identifiez le point d'extrémité de la région et le nom du compartiment pour Oracle NoSQL Database. Par exemple,
- endpoint : us-phoenix-1
- compartiment : développeurs

Procédure

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

Préparez le fichier de configuration (au format JSON) avec les détails de la source et du puits identifiés. Voir Modèles de configuration de source et Modèles de configuration de récepteur.
Vous pouvez choisir l'une des deux options suivantes.
- Option 1 : Importation d'une table DynamoDB en tant que document JSON à l'aide de la configuration de schéma par défaut.
  Ici, defaultSchema est TRUE et l'outil de migration crée donc le schéma par défaut dans l'évier. 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.0.0"
}
```
  Pour une source JSON DynamoDB, le schéma par défaut pour la table est 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 la table de l'évier dans la configuration
  
  DDBPartitionKey_name = valeur fournie pour la clé de partiiton 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 de base de données Dynamo agrégés dans une colonne JSON NoSQL
- Option 2 : Importation de la table DynamoDB en tant que colonnes fixes à l'aide d'un fichier de schéma fourni par l'utilisateur.
  Ici, defaultSchema est FALSE et vous spécifiez schemaPath en tant que fichier contenant votre énoncé LDD. Pour plus de détails, voir Mappage des types DynamoDB aux types Oracle NoSQL .
  
  Note :
  Si le type de données de la table de base de données Dynamo 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 de l'évier 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 est 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.
```
{
 "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
 },
 "abortOnError" : true,
 "migratorVersion" : "1.0.0"
}
```
Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire Database Migrator NoSQL.
Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.
```
[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator 
--config <complete/path/to/the/JSON/config/file>
```

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.

Validation

Vous pouvez vous connecter à la console NDCS 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 présente l'utilisation d'Oracle NoSQL Database Migrator pour effectuer une migration inter-région.

Cas d'utilisation

Une organisation utilise Oracle NoSQL Database Cloud Service pour stocker et gérer ses données. Elle 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 de lancer la nouvelle région pour l'environnement de production.

Dans ce cas d'utilisation, vous apprendrez à utiliser NoSQL Database Migrator pour copier les 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

Téléchargez Oracle NoSQL Database Migrator à partir de la page Téléchargements Oracle NoSQL et extrayez le contenu sur votre ordinateur. Pour plus de détails, voir Flux de travail pour Oracle NoSQL Database Migrator.

Identifiez la source et le puits de la migration.

Source : Table user_data dans la région Ashburn.

La table user_data contient les données suivantes :

{"id":40,"firstName":"Joanna","lastName":"Smith","otherNames":[{"first":"Joanna","last":"Smart"}],"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},"connections":[70,30,40],"email":"joanna.smith123@reachmail.com","communityService":"**"}

{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"Good"},{"first":"Johny2","last":"Brave"},{"first":"Johny3","last":"Kind"},{"first":"Johny4","last":"Humble"}],"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},"connections":[30,55,43],"email":"john.smith@reachmail.com","communityService":"****"}

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"BeGood"}],"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},"connections":[40,75,63],"email":"jane.smith201@reachmail.com","communityService":"*****"}

{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"BeGood"}],"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},"connections":[60,45,73],"email":"adam.smith201reachmail.com","communityService":"***"}

Identifiez le point d'extrémité de la région ou le point d'extrémité du service et le nom du compartiment pour votre source.

point d'extrémité : us-ashburn-1
compartiment : ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya

Sink : Table user_data dans la région Phoenix.
Identifiez le point d'extrémité de la région ou le point d'extrémité du service et le nom du compartiment pour votre évier.
- point d'extrémité : us-phoenix-1
- compartiment : ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identifiez le schéma de la table source.

Vous pouvez utiliser le même nom de table et le même schéma que la table source. Pour plus d'informations sur les autres options de schéma, voir la rubrique Identifier la source et le noeud dans Flux de travail pour Oracle NoSQL Database Migrator

Identifiez vos données d'identification pour le nuage OCI pour les deux régions et saisissez-les dans le fichier de configuration. Enregistrez le fichier de configuration sur votre ordinateur à l'emplacement /home/<user>/.oci/config. Pour plus de détails, voir Acquisition de données d'identification.

Note :

Si les régions se trouvent sous des locations différentes, vous devez fournir des profils différents dans le fichier /home/<user>/.oci/config avec les données d'identification du nuage OCI appropriées pour chacune d'entre elles.
Si les régions se trouvent sous la même location, vous pouvez avoir un seul profil dans le fichier /home/<user>/.oci/config.

Dans cet exemple, les régions se trouvent 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 d'origine), 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é 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, effectuez les opérations suivantes :

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

{
  "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.5.0"
}

Sur votre ordinateur, naviguez jusqu'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.
Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c.
```
[~/nosql-migrator-1.5.0]$./runMigrator --config <complete/path/to/the/config/file>
```

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

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à dans l'évier 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é le paramètre overwrite comme étant vrai dans le modèle de configuration.
Si la table existe déjà dans l'évier avec un schéma différent 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 de la région Ashburn sont copiées dans la table user_data de cette région. Pour la procédure permettant d'accéder à 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 OCI

Cet exemple présente l'utilisation d'Oracle NoSQL Database Migrator à partir d'un Cloud Shell.

Cas d'utilisation

Une entreprise en démarrage prévoit d'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 à partir d'une table dans Oracle NoSQL Database Cloud Service vers le service de stockage d'objets OCI pour 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 abonnée 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 stockage d'objets OCI.

Conditions requises

Téléchargez Migrateur Oracle NoSQL Database à partir de la page Téléchargements Oracle NoSQL sur votre machine locale.
Lancez Cloud Shell à partir du menu Outils de développement de la console en nuage. Le navigateur Web ouvre votre répertoire de base. Cliquez sur le menu Cloud Shell dans le coin supérieur droit de la fenêtre Cloud Shell et sélectionnez l'option Charger dans la liste déroulante. Dans la fenêtre contextuelle, effectuez un glisser-déposer de l'ensemble Migrateur Oracle NoSQL Database à partir de votre ordinateur local, ou cliquez sur l'option Sélectionner à partir de votre ordinateur, sélectionnez l'ensemble à partir de votre ordinateur local, puis cliquez sur le bouton Charger. Vous pouvez également glisser-déposer l'ensemble Migrateur Oracle NoSQL Database directement de votre machine locale vers votre répertoire de base dans Cloud Shell. Extraire le contenu du package.
Identifiez la source et l'évier de la sauvegarde.
- Source : Table NDCSupload dans la région Ashburn du service Oracle NoSQL Database Cloud Service.
  Pour la démonstration, considérez les données suivantes dans la table NDCSupload :
```
{"id":1,"name":"Jane Smith","email":"iamjane@somemail.co.us","age":30,"income":30000.0}
{"id":2,"name":"Adam Smith","email":"adam.smith@mymail.com","age":25,"income":25000.0}
{"id":3,"name":"Jennifer Smith","email":"jenny1_smith@mymail.com","age":35,"income":35000.0}
{"id":4,"name":"Noelle Smith","email":"noel21@somemail.co.us","age":40,"income":40000.0} 
```
  Identifiez le point d'extrémité et l'ID compartiment pour votre source. Pour le point d'extrémité, vous pouvez fournir l'identificateur de région ou le point d'extrémité du service. Pour obtenir la liste des régions de données prises en charge dans Oracle NoSQL Database Cloud Service, voir Régions de données et URL de service associé.
  - point d'extrémité : us-ashburn-1
  - ID compartiment : ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- Sink : Fichier JSON dans le seau de stockage d'objets pour OCI.
  
  Identifiez le point d'extrémité, l'espace de noms, le seau et le préfixe de la région pour le stockage d'objets OCI. Pour plus de détails, consultez Accès au service de stockage d'objets Oracle Cloud. Pour obtenir la liste des points d'extrémité du service de stockage d'objets pour OCI, voir Points d'extrémité du service de stockage d'objets.
  - point d'extrémité : us-ashburn-1
  - seau : Migrate_oci
  - préfixe : Delegation
  - espace de noms : <> Si vous ne fournissez pas d'espace de noms, l'utilitaire utilise l'espace de noms par défaut de la location.
  Note :
  Si le seau de stockage d'objets se trouve dans un autre compartiment, assurez-vous de disposer des privilèges nécessaires pour écrire des objets dans le seau. Pour plus de détails sur la définition des politiques, voir Autoriser les utilisateurs à écrire des objets dans les compartiments de stockage d'objets.

Procédure

Pour sauvegarder la table NDCSupload d'Oracle NoSQL Database Cloud Service dans un fichier JSON dans le seau de stockage d'objets OCI à l'aide de Cloud Shell, procédez comme suit :

Préparez le fichier de configuration (au format JSON) avec les détails de la source et du puits identifiés. Voir Modèles de configuration de source et Modèles de configuration de récepteur. Assurez-vous de régler le paramètre useDelegationToken à Vrai dans les modèles de configuration source et d'origine.

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.6.0"
}

Dans Cloud Shell, naviguez jusqu'au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.
Exécutez la commande runMigrator en transmettant le fichier de configuration à l'aide de l'option --config ou -c
```
[~/nosql-migrator-1.6.0]$./runMigrator --config <complete/path/to/the/config/file>
```
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. L'outil de migration de bases de données NoSQL copie vos données de la table NDCSupload vers un fichier JSON dans le seau de stockage d'objets Migrate_oci. Vérifiez les journaux pour voir si la sauvegarde des données a réussi.
```
[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 du 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 permettant d'accéder à la console, voir l'article Accès au service à partir de la console d'infrastructure.

Migrer d'un fichier CSV vers Oracle NoSQL Database

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

Exemple

Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database en tant que plate-forme de base de données NoSQL. Comme son contenu source est au format de fichier CSV, ils cherchent un moyen de les migrer vers Oracle NoSQL Database.

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

Vous pouvez également préparer le fichier de configuration avec les détails de source et d'évier identifiés. Voir Référence de l'outil de migration d'Oracle NoSQL Database.

Conditions requises

Identifiez la source et le puits de la migration.

Source : fichier CSV

Dans cet exemple, le fichier source est course.csv


cat [~/nosql-migrator-1.5.0]/course.csv
1,"Computer Science", "San Francisco", "2500"
2,"Bio-Technology", "Los Angeles", "1200"
3,"Journalism", "Las Vegas", "1500"
4,"Telecommunication", "San Francisco", "2500"

Évier : Oracle NoSQL Database

Le fichier CSV doit respecter le format RFC4180.
Créez un fichier contenant les commandes LDD pour le schéma de la table cible, course. La définition de la table doit correspondre au fichier de données CSV concernant le nombre de colonnes et leurs types.
Dans cet exemple, le fichier LDD est mytable_schema.DDL
```
cat [~/nosql-migrator-1.5.0]/mytable_schema.ddl
create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
```

Procédure

Pour migrer les données de fichier CSV de course.csv vers le service Oracle NoSQL Database, procédez comme suit :

Ouvrez l'invite de commande et naviguez jusqu'au répertoire dans lequel vous avez extrait l'utilitaire Oracle NoSQL Database Migrator.
Pour générer le fichier de configuration à l'aide d'Oracle NoSQL Database Migrator, exécutez la commande runMigrator sans paramètres d'exécution.
```
[~/nosql-migrator-1.5.0]$./runMigrator
```
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
```

Selon les invites de l'utilitaire, choisissez 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

Fournissez le chemin d'accès au fichier CSV source. De plus, en fonction des invites de l'utilitaire, vous pouvez choisir de réorganiser les noms de colonne, de sélectionner la méthode d'encodage et de couper les espaces de fin de la table cible.


Enter path to a file or directory containing csv data: [~/nosql-migrator-1.5.0]/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

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


Select the sink:
1) nosqldb
2) nosqldb_cloud
#? 1
Configuration for sink type=nosqldb
Enter store name of the Oracle NoSQL Database: mystore
Enter comma separated list of host:port of Oracle NoSQL Database: <hostname>:5000

En fonction des invites de l'utilitaire, indiquez le nom de la table cible.
```
Enter fully qualified table name: course
```

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]: n

Selon les invites de l'utilitaire, spécifiez si la table cible doit être créée ou non au moyen de l'outil Oracle NoSQL Database Migrator. Si la table est déjà créée, il est recommandé 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-1.5.0]/mytable_schema.ddl
Is the store secured? (y/n) [y]: n
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

Entrez votre choix pour déterminer s'il faut poursuivre la migration en cas d'échec de la migration d'un enregistrement.
```
Would you like to continue migration if any data fails to be migrated? 
(y/n) [n]: n
```

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


Generated configuration is:
{
  "source" : {
    "type" : "file",
    "format" : "csv",
    "dataPath" : "[~/nosql-migrator-1.5.0]/course.csv",
    "hasHeader" : false,
    "csvOptions" : {
      "encoding" : "UTF-8",
      "trim" : false
    }
  },
  "sink" : {
    "type" : "nosqldb",
    "storeName" : "mystore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "migrated_table",
    "query" : "",
    "includeTTL" : false,
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.5.0]/mytable_schema.ddl"
    },
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.5.0"
}

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.
Note : Si vous sélectionnez n, vous pouvez utiliser le fichier de configuration généré pour effectuer la migration. Spécifiez ./runMigrator -c ou l'option ./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 ./migrator-config.json
(y/n) [y]: y
```

L'outil de migration de bases de données NoSQL copie vos données du fichier CSV vers Oracle NoSQL Database.


creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[nosqldb sink] : start loading DDLs
[nosqldb sink] : executing DDL: create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id))
[nosqldb sink] : completed loading DDLs
[nosqldb sink] : start loading records
[csv file source] : start parsing CSV records from file: course.csv
migration completed. Records provided by source=4, Records written to sink=4, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 559ms
Migration completed.

Validation

Démarrez l'invite SQL dans KVStore.

 java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore

Vérifiez que la nouvelle table est créée avec les données sources :


sql-> select * from course;
{"id":4,"name":"Telecommunication","location":"San Francisco","fees":2500}
{"id":1,"name":"Computer Science","location":"San Francisco","fees":2500}
{"id":2,"name":"Bio-Technology","location":"Los Angeles","fees":1200}
{"id":3,"name":"Journalism","location":"Las Vegas","fees":1500}
 
4 rows returned

Titre et droits d'auteur

Utilisation d'Oracle NoSQL Database Migrator

Oracle et/ou ses sociétés affiliées.