Utilisation d'Oracle NoSQL Database Migrator
Découvrez Oracle NoSQL Database Migrator et comment l'utiliser pour la migration des données.
Oracle NoSQL Database Migrator 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 site et AWS S3. L'outil Migrator prend en charge plusieurs formats de données et types de média physique différents. Les formats de données pris en charge sont les fichiers JSON, Parquet, JSON au format MongoDB, JSON au format DynamoDB et CSV. Les types de média physique pris en charge sont les fichiers, OCI Object Storage, Oracle NoSQL Database sur site, Oracle NoSQL Database Cloud Service et AWS S3.
Cet article comprend les rubriques suivantes :
Rubriques connexes
Présentation
Oracle NoSQL Database Migrator vous permet de déplacer des tables Oracle NoSQL d'une source de données vers une autre, telle qu'Oracle NoSQL Database sur site ou dans le cloud ou même un fichier JSON simple.
De nombreuses situations peuvent vous obliger à migrer des tables NoSQL de ou vers une instance Oracle NoSQL Database. Par exemple, une équipe de développeurs améliorant une application NoSQL Database peut vouloir tester son code mis à jour dans l'instance Oracle NoSQL Database Cloud Service (NDCS) locale à l'aide de CloudSim. Pour vérifier tous les cas de test possibles, ils doivent configurer des 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 d'un environnement sur site vers le cloud et inversement, à des fins de développement ou de test.
Dans tous ces cas, et bien plus encore, vous pouvez utiliser Oracle NoSQL Database Migrator pour déplacer vos tables NoSQL d'une source de données vers une autre, comme Oracle NoSQL Database sur site ou dans le cloud, ou même un simple fichier JSON. 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 site ou dans le cloud.
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é récepteur). En substance, cet utilitaire exporte les données de la source sélectionnée et les importe dans le récepteur. Cet outil est orienté table, c'est-à-dire que vous ne pouvez déplacer les données qu'au niveau table. Une tâche de migration unique fonctionne sur une seule table et prend en charge la migration des données de table de la source vers le récepteur dans différents formats de données.
Terminologie utilisée avec Oracle NoSQL Database Migrator
En savoir plus sur les différents termes utilisés dans le diagramme ci-dessus.
- Source : entité à partir de laquelle les tables NoSQL sont exportées pour migration. Voici quelques exemples de sources : Oracle NoSQL Database sur site ou dans le cloud, fichier JSON, fichier JSON au format MongoDB, fichier JSON au format DynamoDB et fichiers CSV.
- Récepteur : entité qui importe les tables NoSQL à partir de NoSQL Database Migrator. Oracle NoSQL Database sur site ou dans le cloud et le fichier JSON sont des exemples de récepteur.
L'outil NoSQL Database Migrator prend en charge différents types de source et de récepteur (médias physiques ou référentiels de données) et formats de données (c'est-à-dire la façon dont les données sont représentées dans la source ou le récepteur). Les formats de données pris en charge sont les fichiers JSON, Parquet, JSON au format MongoDB, JSON au format DynamoDB et CSV. Les types de source et de récepteur pris en charge sont les fichiers, OCI Object Storage, Oracle NoSQL Database sur site et Oracle NoSQL Database Cloud Service.
- Pipe de migration : les données d'une source seront transférées vers le récepteur par NoSQL Database Migrator. Il peut s'agir d'un tuyau de migration.
- Transformations : vous pouvez ajouter des règles pour modifier les données de table NoSQL dans le pipeline de migration. Ces règles sont appelées transformations. Oracle NoSQL Database Migrator autorise uniquement les transformations de données au niveau des champs ou des colonnes de niveau supérieur. Il ne vous permet pas de transformer les données dans les champs imbriqués. Voici quelques exemples de transformations autorisées :
- Supprimer ou ignorer une ou plusieurs colonnes,
- Renommer une ou plusieurs colonnes, ou
- Agrégez plusieurs colonnes dans un seul champ, généralement un champ JSON.
- Fichier de configuration : un fichier de configuration permet de définir tous les paramètres requis pour l'activité de migration au format JSON. Par la suite, 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 standard se présente comme 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> }Grouper Paramètres Obligatoire (O/N) Description Valeurs prises en charge sourcetypeO 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 typede chaque source, reportez-vous à Sources et liens pris en charge.sourceconfiguration source pour le type O Définit la configuration de la source. Ces paramètres de configuration sont spécifiques au type de source sélectionné ci-dessus. Pour obtenir la liste complète des paramètres de configuration pour chaque type de source, reportez-vous à Modèles de configuration source. sinktypeO Représente le récepteur vers lequel migrer les données. Le récepteur est la cible ou la destination de la migration. Pour connaître la valeur typede chaque source, reportez-vous à Sources et liens pris en charge.sinkconfiguration de récepteur pour le type O Définit la configuration de l'évier. Ces paramètres de configuration sont spécifiques au type d'évier sélectionné ci-dessus. Reportez-vous à la section Sink Configuration Templates pour obtenir la liste complète des paramètres de configuration pour chaque type de récepteur. transformsconfiguration des transformations N Définit les transformations à appliquer aux données du pipeline de migration. Reportez-vous à 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. - migratorVersionN Version de l'outil de migration de données NoSQL - - abortOnErrorN Indique si l'activité de migration doit être arrêtée en cas d'erreur ou non.
La valeur par défaut est true, ce qui indique que la migration s'arrête chaque fois qu'elle rencontre une erreur de migration.
Si vous définissez cette valeur sur false, 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 consignés en tant qu'AVERTISSEMENTS sur le terminal CLI.
true, false Remarques :
Le fichier JSON étant sensible à la casse, tous les paramètres définis dans le fichier de configuration sont sensibles à la casse, sauf indication contraire.
Sources et récepteurs pris en charge
Cette rubrique fournit la liste des sources et des puits pris en charge par Oracle NoSQL Database Migrator.
Vous pouvez utiliser n'importe quelle combinaison d'une source valide et d'un récepteur de cette table pour l'activité de migration. Toutefois, vous devez vous assurer qu'au moins l'une des extrémités (source ou récepteur) 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 vers un autre.
|
Type |
Format |
Source valide | Evier valide |
|---|---|---|---|
|
Oracle NoSQL Database |
S/O | O | O |
|
Oracle NoSQL Database Cloud Service |
S/O | O | O |
|
Système de fichiers |
JSON |
O | O |
|
MongoDB JSON |
O | N | |
|
DynamoDB JSON |
O | N | |
|
Parquet( |
N | O | |
|
CSV |
O | N | |
|
OCI Object Storage |
JSON |
O | O |
|
MongoDB JSON |
O | N | |
|
Parquet( |
N | O | |
|
CSV |
O | N | |
| AWS S3 |
DynamoDB JSON |
O | N |
Remarques :
De nombreux paramètres de configuration sont communs à l'ensemble de 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 chaque évier dans les sections de documentation, qui expliquent les formats de fichier de configuration pour différents types de sources et d'éviers. Dans tous les cas, la syntaxe et la sémantique des paramètres portant le même nom sont identiques.Sécurité des sources et des récepteurs
Certains types de source et de récepteur ont des informations de sécurité facultatives ou obligatoires à des fins d'authentification.
Toutes les sources et tous les puits qui utilisent des services dans Oracle Cloud Infrastructure (OCI) peuvent utiliser certains paramètres pour fournir des informations de sécurité facultatives. Ces informations peuvent être fournies à l'aide d'un fichier de configuration OCI ou d'un principal d'instance.
Les sources et les puits 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 Oracle NoSQL Database utilise l'authentification basée sur Oracle Wallet, vous avez besoin d'un fichier JAR supplémentaire faisant partie de l'installation EE. Pour plus d'informations, reportez-vous à Oracle Wallet.
Sans ce fichier JAR, le message d'erreur suivant s'affiche :
kvstore-ee.jar est introuvable dans le répertoire lib. Copiez kvstore-ee.jar dans le répertoire lib.
kvstore-ee.jar de votre package de serveur EE vers le répertoire <MIGRATOR_HOME>/lib. <MIGRATOR_HOME> est le répertoire nosql-migrator-M.N.O/ créé en extrayant le package 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.
Remarques :
L'authentification basée sur un portefeuille est prise en charge UNIQUEMENT dans Enterprise Edition (EE) d'Oracle NoSQL Database.Authentification à l'aide de principaux d'instance
Les principaux d'instance sont une fonctionnalité de service IAM qui permet aux instances d'être des acteurs autorisés (ou principaux) pouvant effectuer des actions sur les ressources de service. Chaque instance de calcul dispose de sa propre identité et est authentifiée à l'aide des certificats ajoutés.
Oracle NoSQL Database Migrator fournit une option permettant de se connecter à un cloud NoSQL et à des sources et puits OCI Object Storage à l'aide de l'authentification par principal d'instance. Elle est uniquement prise en charge lorsque l'outil NoSQL Database Migrator est utilisé dans une instance de calcul OCI, par exemple, l'outil NoSQL Database Migrator exécuté dans une machine virtuelle hébergée sur OCI. Pour activer cette fonctionnalité, utilisez l'attribut useInstancePrincipal de la source cloud NoSQL et du fichier de configuration de récepteur. Pour plus d'informations sur les paramètres de configuration des différents types de source et de récepteur, reportez-vous aux sections Source Configuration Templates et Sink Configuration Templates.
Pour plus d'informations sur les principaux d'instance, reportez-vous à Appel de services à partir d'une instance.
Workflow pour Oracle NoSQL Database Migrator
Découvrez les différentes étapes de migration des données NoSQL à l'aide de l'utilitaire Oracle NoSQL Database Migrator.
Le flux général des tâches impliquées dans l'utilisation de NoSQL Database Migrator est représenté dans la figure ci-dessous.
Télécharger l'utilitaire Data Migrator NoSQL
runMigrator à partir de l'interface de ligne de commande.
Remarques :
L'utilitaire Oracle NoSQL Database Migrator requiert l'exécution de Java 11 ou versions ultérieures.Identifier la source et l'évier
- Identifier le schéma de table de récepteur : si le récepteur est Oracle NoSQL Database sur site ou dans le cloud, vous devez identifier le schéma de la table de récepteur et vous assurer que les données source correspondent au schéma cible. Si nécessaire, utilisez des transformations pour mapper les données source avec la table récepteur.
- Schéma par défaut : NoSQL Database Migrator fournit une option permettant de créer une table avec le schéma par défaut sans avoir à prédéfinir le schéma pour la table. Cela est principalement utile lors du chargement de fichiers source 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 table dans la configuration.
- ID = valeur _id de chaque document du fichier source JSON exporté mongoDB.
- DOCUMENT = Pour chaque document du fichier exporté mongoDB, le contenu excluant le 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 de récepteur 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 partitionnement dans la configuration
- DDBSortKey_name = valeur fournie pour la clé de tri dans la configuration, le cas échéant
- DDBSortKey_type = valeur fournie pour le type de données de la clé de tri dans la configuration, le cas échéant
- DOCUMENT = Tous les attributs sauf la partition et la clé de tri d'un élément de table Dynamo DB agrégé dans une colonne JSON NoSQL
Si le format source est un fichier CSV, aucun schéma par défaut n'est 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 d'informations sur la création du fichier de schéma, reportez-vous à Fourniture d'un 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 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.Remarques :
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.
- Schéma par défaut : NoSQL Database Migrator fournit une option permettant de créer une table avec le schéma par défaut sans avoir à prédéfinir le schéma pour la table. Cela est principalement utile lors du chargement de fichiers source JSON dans Oracle NoSQL Database.
- Fourniture d'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 pour lesquelles aucun schéma implicite n'est déjà défini. Les banques de données d'évier 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 souhaitez transformer les données du schéma source en un autre schéma, vous devez remplacer le schéma fourni par la source et utiliser la fonctionnalité de transformation de l'outil NoSQL Database Migrator.
Le fichier de schéma de table, par exemple,mytable_schema.ddlpeut inclure des instructions DDL de table. L'outil NoSQL Database Migrator exécute ce fichier de schéma de table avant de démarrer la migration. L'outil de migration ne prend en charge qu'une instruction DDL par ligne dans le fichier de schéma. Exemple :CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))Remarques :
La migration échouera si la table est présente dans le récepteur et que le DDL dansschemaPathest différent de la table. - Créer une table de récepteur : une fois que vous avez identifié le schéma de table de récepteur, créez la table de récepteur via l'interface de ligne de commande d'administration ou à l'aide de l'attribut
schemaInfodu fichier de configuration de récepteur. Reportez-vous à la section Sink Configuration Templates .Remarques :
Si la source est un fichier CSV, créez un fichier avec les commandes DDL pour le schéma de la table cible. Indiquez le chemin du fichier dans le paramètre schemaInfo.schemaPath du fichier de configuration du récepteur.
Migration des métadonnées de durée de vie pour les lignes de table
Remarques :
La prise en charge de la migration des métadonnées de durée de vie pour les lignes de table est uniquement disponible pour Oracle NoSQL Database et Oracle NoSQL Database Cloud Service.Export des métadonnées de durée de vie
_metadata pour chaque ligne exportée. NoSQL Database Migrator exporte le délai d'expiration de chaque ligne en millisecondes depuis l'époque UNIX (1er janvier 1970). 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
}Import 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'import gère les cas d'emploi suivants lors de la migration de lignes de table contenant des métadonnées de durée de vie. Ces cas d'utilisation sont applicables uniquement lorsque le paramètre de configuration includeTTL est spécifié.
- Cas d'utilisation 1 : aucune information sur les métadonnées de durée de vie n'est présente dans la ligne de la table d'import.
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 ligne d'import ne contient pas d'informations de durée de vie. Toutefois, étant donné que le paramètre de configuration includeTTL est égal à
true, le migrateur définit la durée de vie = 0 pour la ligne de table, ce qui signifie que la ligne de table d'import n'expire jamais. - Cas d'utilisation 2 : la valeur de durée de vie de la ligne de table source est expirée par rapport à l'heure de référence lorsque la ligne de table est importée.
Lorsque vous exportez une ligne de table vers un fichier et que vous essayez de l'importer après l'expiration de la ligne de table, la ligne de table est ignorée et n'est pas écrite dans l'emplacement de stockage.
- Cas d'utilisation 3 : la valeur de durée de vie de la ligne de table source n'a pas expiré par rapport à l'heure de référence lors de l'importation de la ligne de 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, la ligne de table est importée avec une valeur de durée de vie. Toutefois, la nouvelle valeur de durée de vie de la ligne de table peut ne pas être égale à la valeur de durée de vie exportée en raison des contraintes de fenêtre d'heures et de jours entiers dans la classe TimeToLive. Exemple :
Ligne de table 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 lundi 23 août 2021 8:39 :22.582 AM.
Ligne de table importée{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC } }
Importer des données dans un récepteur avec une colonne IDENTITY
Vous pouvez importer les données d'une source valide vers une table de récepteur (Services sur site/Cloud) avec une colonne IDENTITY. Vous créez la colonne IDENTITY en sélectionnant GENERATED ALWAYS AS IDENTITY ou GENERATED BY DEFAULT AS IDENTITY. Pour plus d'informations sur la création de table avec une colonne IDENTITY, reportez-vous à 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 du récepteur est vide si elle existe. S'il existe des données préexistantes dans la table de récepteur, la migration peut entraîner des problèmes tels que le remplacement des données existantes dans la table de récepteur ou le saut des données source pendant l'import.
Table de récepteur avec colonne IDENTITY comme GENERATED ALWAYS AS IDENTITY
Prenons une table récepteur avec la colonne IDENTITY créée en tant que GENERATED ALWAYS AS IDENTITY. L'import de 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 que récepteur. Le schéma de la table d'évier est le suivant :
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Condition source | Action utilisateur | Résultat de la migration |
|---|---|---|
|
CAS 1 : Les données source ne fournissent pas de valeur pour le champ IDENTITY de la table récepteur. Exemple : fichier source JSON |
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 récepteur Oracle NoSQL Database |
|
CAS 2 : Les données source fournissent des valeurs pour le champ IDENTITY de la table récepteur. Exemple : fichier source JSON |
Créez/générez le fichier de configuration. Vous fournissez une transformation ignoreFields pour la colonne ID dans le modèle de configuration de récepteur.
|
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 récepteur Oracle NoSQL Database
migrateID : |
|
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 d'informations sur les paramètres de configuration de transformation, reportez-vous à la rubrique Modèles de configuration de transformation.
Table récepteur avec colonne IDENTITY comme GENERATED BY DEFAULT AS IDENTITY
Prenons une table récepteur avec la colonne IDENTITY créée en tant que GENERATED BY DEFAULT AS IDENTITY. L'import de 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 que récepteur. Le schéma de la table d'évier est le suivant :
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Condition source | Action utilisateur | Résultat de la migration |
|---|---|---|
|
CAS 1 : Les données source ne fournissent pas de valeur pour le champ IDENTITY de la table récepteur. Exemple : fichier source JSON |
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 récepteur Oracle NoSQL Database
migrateID : |
|
CAS 2 : Les données source fournissent des valeurs pour le champ IDENTITY de la table récepteur et il s'agit d'un champ de clé primaire. Exemple : fichier source JSON |
Créez/générez le fichier de configuration. Vous fournissez une transformation ignoreFields pour la colonne ID dans le modèle de configuration de récepteur (Recommandé).
|
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 récepteur Oracle NoSQL Database
migrateID : |
|
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 Lorsque vous essayez d'insérer une ligne supplémentaire dans la table sans fournir de valeur d'ID, le générateur de séquences tente de générer automatiquement la valeur d'ID. 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 récepteur. 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. Pour plus d'informations, reportez-vous à Générateur de séquences. Pour éviter toute 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 récepteur. Pour utiliser l'attribut START WITH pour effectuer cette modification, reportez-vous à l'exemple ci-dessous : Exemple : données migrées dans la table de récepteur Oracle NoSQL Database
migrateID :Pour rechercher la valeur appropriée que le générateur de séquences doit insérer dans la colonne ID, extrayez la valeur maximale du champ
ID à l'aide de la requête suivante :Sortie :
La valeur maximale de la colonne
ID dans la table de récepteur 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 les doublons. Pour mettre à jour l'attribut START WITH du générateur de séquences sur 4, utilisez l'instruction suivante :La séquence commencera à 4. Maintenant, lorsque vous insérez des lignes dans la table récepteur 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 d'informations sur les paramètres de configuration de transformation, reportez-vous à 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 11 ou une version supérieure et bash sur votre système pour exécuter la commande runMigrator.
runMigrator de deux manières :
- 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 que l'utilitaire a créé le fichier de configuration, vous pouvez poursuivre l'activité de migration dans la même exécution ou enregistrer le fichier de configuration pour une migration ultérieure.
- 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.
- Lorsque vous appelez l'utilitaire
- En transmettant un fichier de configuration créé manuellement (au format JSON) en tant que paramètre d'exécution à l'aide de l'option
-cou--config. Vous devez créer le fichier de configuration manuellement avant d'exécuter la commanderunMigratoravec l'option-cou--config. Pour obtenir de l'aide sur les paramètres de configuration source et récepteur, reportez-vous à Référence Oracle NoSQL Database Migrator.[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
Journalisation de la progression du migrateur
L'outil NoSQL Database Migrator fournit des options qui permettent d'imprimer les messages de trace, de débogage et de progression dans une sortie standard ou dans un fichier. Cette option peut être utile pour suivre la progression de l'opération de migration, en particulier pour les tables ou jeux de données très volumineux.
- Niveaux de journalisation
Pour contrôler le comportement de journalisation via l'outil NoSQL Database Migrator, transmettez le paramètre d'exécution --log-level ou -l à la commande
runMigrator. Vous pouvez indiquer la quantité d'informations de journal à écrire en transmettant la valeur de niveau de journal appropriée.$./runMigrator --log-level <loglevel>Par exemple :$./runMigrator --log-level debugTableau - Niveaux de journal pris en charge pour NoSQL Database Migrator
Niveau de journalisation Description avertissement Imprime les erreurs et les avertissements. Informations (par défaut) Imprime le statut d'avancement de la migration de données, par exemple la validation de la source, la validation du récepteur, 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 indiquer 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, puis dans la sortie standard.$./runMigrator --log-file <log file name>Par exemple :$./runMigrator --log-file nosql_migrator.log
démonstrations de cas d'emploi pour Oracle NoSQL Database Migrator
Découvrez comment effectuer une migration de données à l'aide de l'outil de migration Oracle NoSQL Database pour des cas d'emploi 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 comprend les rubriques suivantes :
Migration à partir d'Oracle NoSQL Database Cloud Service vers un fichier JSON
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 Cloud Service (NDCS) vers un fichier JSON.
Cas d'emploi
Une organisation décide d'entraîner un modèle à l'aide des données Oracle NoSQL Database Cloud Service (NDCS) afin de prévoir les comportements futurs et de fournir des recommandations personnalisées. Ils peuvent effectuer une copie périodique des données des tables NDCS dans un fichier JSON et les appliquer au moteur d'analyse pour analyser et entraîner le modèle. Cela les aide à séparer les requêtes analytiques des chemins critiques à faible latence.
Exemple
Pour la démonstration, examinons comment migrer les données et la définition de schéma d'une table NoSQL nomméemyTable de NDCS vers un fichier JSON.- Identifiez la source et le récepteur de la migration.
- Source : Oracle NoSQL Database Cloud Service
- Récepteur : fichier JSON
- Identifiez vos informations d'identification cloud OCI et capturez-les dans le fichier de configuration OCI. Enregistrez le fichier de configuration dans
/home/.oci/config. Reportez-vous à Obtention d'informations 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 l'adresse de région et le nom de compartiment pour Oracle NoSQL Database Cloud Service.
- endpoint :
us-phoenix-1 - compartiment :
developers
- endpoint :
myTable à partir d'Oracle NoSQL Database Cloud Service vers un fichier JSON, procédez comme suit :
Pour valider la migration, vous pouvez ouvrir les fichiers de récepteur JSON et visualiser 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)))Migration d'une instance Oracle NoSQL Database sur site 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'emploi
En tant que développeur, vous étudiez les options permettant d'éviter la surcharge liée à la gestion des ressources, des clusters et du nettoyage de la mémoire pour vos charges globales NoSQL Database KVStore existantes. En tant que solution, vous décidez de migrer vos charges globales KVStore on-premise existantes vers Oracle NoSQL Database Cloud Service car NDCS les gère automatiquement.
Exemple
Pour la démonstration, examinons comment migrer les données et la définition de schéma d'une table NoSQL appeléemyTable de la base de données NoSQL KVStore vers NDCS. Nous allons également utiliser ce cas d'emploi pour montrer comment exécuter l'utilitaire runMigrator en transmettant un fichier de configuration prédéfini.- Identifiez la source et le récepteur de la migration.
- Source : Oracle NoSQL Database
- Récepteur : Oracle NoSQL Database Cloud Service
- Identifiez vos informations d'identification cloud OCI et capturez-les dans le fichier de configuration OCI. Enregistrez le fichier de configuration dans
/home/.oci/config. Reportez-vous à Acquiring Credentials dans Using 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 l'adresse de région et le nom de compartiment pour Oracle NoSQL Database Cloud Service.
- endpoint :
us-phoenix-1 - compartiment :
developers
- endpoint :
- Identifiez les détails suivants pour le fichier KVStore sur site :
- storeName:
kvstore - helperHosts:
<hostname>:5000 - table :
myTable
- storeName:
myTable de la base de données NoSQL KVStore vers NDCS, procédez comme suit :
Pour valider la migration, vous pouvez vous connecter à la console NDCS et vérifier que myTable est créé avec les données source.
Migration à partir d'une source de fichier JSON vers Oracle NoSQL Database Cloud Service
Cet exemple montre comment utiliser Oracle NoSQL Database Migrator pour copier des données 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. Le contenu source étant au format de fichier JSON, ils recherchent un moyen de les migrer vers Oracle NoSQL Database Cloud Service.
Dans cet exemple, vous allez apprendre à migrer les données à partir d'un fichier JSON appelé SampleData.json. 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 via une procédure interactive.
- Identifiez la source et le récepteur de la migration.
- Source : fichier source JSON.
SampleData.jsonest 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"}} - Récepteur : Oracle NoSQL Database Cloud Service.
- Source : fichier source JSON.
- Identifiez vos informations d'identification cloud OCI et capturez-les dans le fichier de configuration. Enregistrez le fichier de configuration dans
/home/user/.oci/config. Pour plus de détails, reportez-vous à Acquiring Credentials dans Using 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 l'adresse de région et le nom de compartiment pour Oracle NoSQL Database Cloud Service.
- endpoint :
us-ashburn-1 - compartiment :
Training-NoSQL
- endpoint :
- 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 DDL estschema_json.ddl.create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id));L'outil de migration Oracle NoSQL Database fournit une option permettant de créer une table avec le schéma par défaut si
schemaPathn'est pas fourni. Pour plus de détails, reportez-vous à Identification de la source et du récepteur dans la rubrique Workflow pour Oracle NoSQL Database Migrator. - Chemin de données :
<absolute path to a file or directory containing the JSON data for migration>.
-
SampleData.json vers Oracle NoSQL Database Cloud Service, procédez comme suit :
Migrate_JSON est créée avec les données source. Pour connaître la procédure d'accès à la console, reportez-vous à 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
Figure - Données de table de la console Oracle NoSQL Database Cloud Service
Migration à partir d'un fichier JSON MongoDB vers une instance Oracle NoSQL Database Cloud Service
Cet exemple montre comment utiliser Oracle NoSQL Database Migrator pour copier des données au format Mongo-DB vers Oracle NoSQL Database Cloud Service (NDCS).
Cas d'emploi
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 données NoSQL se trouvent dans MongoDB, ils recherchent un moyen de migrer ces tables et 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 indiquant le fichier ou le répertoire dans le modèle de configuration source.
{"_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, Mode canonique et Mode décontracté. Vous pouvez fournir le fichier JSON au format MongoDB généré à l'aide de l'outil mongoexport en mode Canonical ou Relaxed. Les deux modes sont pris en charge par NoSQL Database Migrator pour la migration.
Pour plus d'informations sur le fichier JSON étendu MongoDB (v2), reportez-vous à mongoexport_formats.
Pour plus d'informations sur la génération du fichier JSON au format MongoDB, reportez-vous à mongoexport.
Exemple
Pour la démonstration, examinons comment migrer un fichier JSON au format MongoDB vers NDCS. Nous allons utiliser un fichier de configuration créé manuellement pour cet exemple.- Identifiez la source et le récepteur de la migration.
- Source : fichier JSON au format MongoDB
- Récepteur : Oracle NoSQL Database Cloud Service
- Extrayez les données de Mongo DB à l'aide de l'utilitaire mongoexport. Pour plus d'informations, reportez-vous à mongoexport.
- Créez une table NoSQL dans le récepteur avec un schéma de table correspondant aux données du fichier JSON au format Mongo-DB. Vous pouvez également demander à NoSQL Database Migrator de créer une table avec la structure de schéma par défaut en définissant l'attribut
defaultSchemasur True.Remarques :
Pour une source 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 de la configuration de table.ID= valeur_iddu fichier source JSON exporté mongoDB.DOCUMENT= L'intégralité du contenu du fichier source JSON exporté mongoDB est agrégée dans la colonneDOCUMENT, à l'exception du champ_id.
- Identifiez vos informations d'identification cloud OCI et capturez-les dans le fichier de configuration OCI. Enregistrez le fichier de configuration dans
/home/.oci/config. Reportez-vous à Acquiring Credentials dans Using 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 l'adresse de région et le nom de compartiment pour Oracle NoSQL Database Cloud Service.
- endpoint :
us-phoenix-1 - compartiment :
developers
- endpoint :
Pour migrer les données JSON au format MongoDB vers Oracle NoSQL Database Cloud Service, procédez comme suit :
Pour valider la migration, vous pouvez vous connecter à la console NDCS et vérifier que myTable est créé avec les données source.
Migration à partir d'un fichier JSON DynamoDB vers Oracle NoSQL Database
Cet exemple montre comment utiliser Oracle NoSQL Database Migrator pour copier le fichier JSON DynamoDB vers Oracle NoSQL Database.
Cas d'emploi:
Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database sur une base de données DynamoDB. L'organisation souhaite migrer ses tables et données de DynamoDB vers Oracle NoSQL Database (sur site).
Pour plus d'informations, reportez-vous à Mise en correspondance de la table DynamoDB avec la table Oracle NoSQL.
Vous pouvez migrer un fichier ou un répertoire contenant les données JSON exportées par DynamoDB à partir d'un système de fichiers en indiquant le chemin dans le modèle de configuration source.
{"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 table DynamoDB exportées du stockage AWS S3 vers un système de fichiers monté local.
Par exemple :
Pour cette démonstration, vous allez apprendre à migrer un fichier JSON DynamoDB vers Oracle NoSQL Database (sur site). Vous allez utiliser un fichier de configuration créé manuellement pour cet exemple.
Prérequis
- Identifiez la source et le récepteur de la migration.
- Source : DynamoDB JSON File
- Récepteur : Oracle NoSQL Database (sur site)
- Pour importer des données de table DynamoDB vers Oracle NoSQL Database, vous devez d'abord exporter la table DynamoDB vers S3. Reportez-vous aux étapes fournies dans Export de données de table DynamoDB vers Amazon S3 pour exporter votre table. Lors de l'export, vous sélectionnez le format JSON DynamoDB. 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
- Préparez le fichier de configuration (au format JSON) avec la source et le récepteur identifiés details.See Source Configuration Templates et Sink Configuration Templates .
Vous pouvez choisir l'une des deux options suivantes.
- Option 1 : import de la table DynamoDB en tant que document JSON à l'aide de la configuration de schéma par défaut.
Ici,
defaultSchemaestTRUE, de sorte que le migrateur crée le schéma par défaut au niveau du récepteur. Vous devez indiquerDDBPartitionKeyet 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 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]))WHERE
TABLE_NAME = valeur fournie pour le récepteur 'table' 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 partitionnement dans la configuration
DDBSortKey_name = valeur fournie pour la clé de tri dans la configuration, le cas échéant
DDBSortKey_type = valeur fournie pour le type de données de la clé de tri dans la configuration, le cas échéant
DOCUMENT = Tous les attributs sauf la partition et la clé de tri d'un élément de table Dynamo DB agrégé dans une colonne JSON NoSQL
- Option 2 : import de la table DynamoDB en tant que colonnes fixes à l'aide d'un fichier de schéma fourni par l'utilisateur.
Ici,
defaultSchemaestFALSEet vous indiquez schemaPath en tant que fichier contenant votre instruction DDL. Pour plus d'informations, reportez-vous à Mise en correspondance des types DynamoDB avec les types Oracle NoSQL.Remarques :
Si le type de données de la table Dynamo DB n'est pas pris en charge dans NoSQL, la migration échoue.Voici un exemple de fichier de schéma.CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, PRIMARY KEY(SHARD(AccountId)));Le fichier de schéma est utilisé pour créer la table au niveau du récepteur 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 il génère une erreur.Remarques :
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" }
- Option 1 : import de la table DynamoDB en tant que document JSON à l'aide de la configuration de schéma par défaut.
- Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.
- Exécutez la commande
runMigratoren transmettant le fichier de configuration à l'aide de l'option--configou-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
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoredesc <table_name>
SELECT * from <table_name>Migration à partir d'un fichier JSON DynamoDB dans AWS S3 vers une instance Oracle NoSQL Database Cloud Service
Cet exemple montre comment utiliser Oracle NoSQL Database Migrator pour copier le fichier JSON DynamoDB stocké dans une banque AWS S3 vers Oracle NoSQL Database Cloud Service (NDCS).
Cas d'emploi:
Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database Cloud Service sur une base de données DynamoDB. L'organisation souhaite migrer ses tables et données de DynamoDB vers Oracle NoSQL Database Cloud Service.
Pour plus d'informations, reportez-vous à Mise en correspondance de la table DynamoDB avec la table Oracle NoSQL.
Vous pouvez migrer un fichier contenant les données JSON exportées par DynamoDB à partir du stockage AWS S3 en indiquant le chemin dans le modèle de configuration source.
{"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 Export de données de table DynamoDB vers Amazon S3.
Par exemple :
Pour cette démonstration, vous allez apprendre à migrer un fichier JSON DynamoDB dans une source AWS S3 vers NDCS. Vous allez utiliser un fichier de configuration créé manuellement pour cet exemple.
Prérequis
- Identifiez la source et le récepteur de la migration.
- Source : DynamoDB JSON File dans AWS S3
- Récepteur : Oracle NoSQL Database Cloud Service
- Identifiez la table dans AWS DynamoDB qui doit être migrée vers NDCS. Connectez-vous à la console AWS à l'aide de vos informations d'identification. Accédez à DynamoDB. Sous Tables, choisissez la table à migrer.
- Créez un bucket d'objet et exportez la table vers S3. A partir de la console AWS, accédez à S3. Sous Buckets, créez un bucket d'objet. Revenez à DynamoDB et cliquez sur Exports vers S3. Indiquez la table source et le bucket de destination S3, puis cliquez sur Exporter.
Reportez-vous aux étapes fournies dans Export de données de table DynamoDB vers Amazon S3 pour exporter votre table. Lors de l'export, vous sélectionnez le format JSON DynamoDB. 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 d'informations d'identification aws (y compris l'ID de clé d'accès et la clé d'accès secrète) et de fichiers de configuration (informations d'identification et éventuellement de configuration) pour accéder à AWS S3 à partir de la migration. Pour plus d'informations sur les fichiers de configuration, reportez-vous à Définir et afficher les paramètres de configuration. Pour plus d'informations sur la création de clés d'accès, reportez-vous à Création d'une paire de clés.
- Identifiez vos informations d'identification cloud OCI et capturez-les dans le fichier de configuration OCI. Enregistrez le fichier de configuration dans un répertoire
.ocisous votre répertoire de base (~/.oci/config). Pour plus d'informations, reportez-vous à Obtention d'informations 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 l'adresse de région et le nom de compartiment pour Oracle NoSQL Database. Exemple :
- endpoint : us-phoenix-1
- compartiment : développeurs
Procédure
- Préparez le fichier de configuration (au format JSON) avec les détails de source et de récepteur identifiés. Reportez-vous aux sections Source Configuration Templates et Sink Configuration Templates.
Vous pouvez choisir l'une des deux options suivantes.
- Option 1 : import de la table DynamoDB en tant que document JSON à l'aide de la configuration de schéma par défaut.
Ici,
defaultSchemaestTRUE, de sorte que le migrateur crée le schéma par défaut au niveau du récepteur. Vous devez indiquerDDBPartitionKeyet 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 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]))WHERE
TABLE_NAME = valeur fournie pour le récepteur 'table' 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 partitionnement dans la configuration
DDBSortKey_name = valeur fournie pour la clé de tri dans la configuration, le cas échéant
DDBSortKey_type = valeur fournie pour le type de données de la clé de tri dans la configuration, le cas échéant
DOCUMENT = Tous les attributs sauf la partition et la clé de tri d'un élément de table Dynamo DB agrégé dans une colonne JSON NoSQL
- Option 2 : import de la table DynamoDB en tant que colonnes fixes à l'aide d'un fichier de schéma fourni par l'utilisateur.
Ici,
defaultSchemaestFALSEet vous indiquez schemaPath en tant que fichier contenant votre instruction DDL. Pour plus d'informations, reportez-vous à Mise en correspondance des types DynamoDB avec les types Oracle NoSQL.Remarques :
Si le type de données de la table Dynamo DB n'est pas pris en charge dans NoSQL, la migration échoue.Voici un exemple de fichier de schéma.CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, PRIMARY KEY(SHARD(AccountId)));Le fichier de schéma est utilisé pour créer la table au niveau du récepteur 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 il génère une erreur.Remarques :
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" }
- Option 1 : import de la table DynamoDB en tant que document JSON à l'aide de la configuration de schéma par défaut.
- Ouvrez l'invite de commande et accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator.
- Exécutez la commande
runMigratoren transmettant le fichier de configuration à l'aide de l'option--configou-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 source.
Migration entre les régions Oracle NoSQL Database Cloud Service
Cet exemple illustre l'utilisation d'Oracle NoSQL Database Migrator pour effectuer une migration inter-région.
Cas d'emploi
Une organisation utilise Oracle NoSQL Database Cloud Service pour stocker et gérer ses données. Il décide de répliquer les données d'une région existante vers une région plus récente à des fins de test avant que la nouvelle région puisse être lancée pour l'environnement de production.
Dans ce cas d'emploi, vous allez apprendre à utiliser NoSQL Database Migrator pour copier les données de la table user_data dans la région Ashburn vers la région Phoenix.
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 via une procédure interactive.
- 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, reportez-vous à Workflow pour Oracle NoSQL Database Migrator.
- Identifiez la source et le récepteur de la migration.
- Source : table
user_datadans la région Ashburn.La tableuser_datainclut 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 l'adresse de région ou l'adresse de service et le nom de compartiment pour la source.- endpoint :
us-ashburn-1 - compartiment :
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- endpoint :
- Récepteur : table
user_datadans la région Phoenix.Identifiez l'adresse de région ou l'adresse de service et le nom de compartiment de votre récepteur.- endpoint :
us-phoenix-1 - compartiment :
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identifiez le schéma de la table récepteur.
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, reportez-vous à la rubrique Identification de la source et du récepteur dans Workflow pour Oracle NoSQL Database Migrator.
- endpoint :
- Source : table
- Identifiez vos informations d'identification cloud OCI pour les deux régions et capturez-les dans le fichier de configuration. Enregistrez le fichier de configuration sur l'ordinateur à l'emplacement
/home/<user>/.oci/config. Pour plus de détails, reportez-vous à Acquiring Credentials.
Remarques :
- Si les régions appartiennent à des locations différentes, vous devez fournir des profils différents dans le fichier
/home/<user>/.oci/configavec les informations d'identification cloud OCI appropriées pour chacune d'entre elles. - Si les régions se trouvent sous la même location, vous pouvez disposer d'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 informations d'identification OCI pour la région Ashburn et DEFAULT2 inclut les informations d'identification OCI pour la région Phoenix.
endpoint du fichier de configuration du migrateur (modèles de configuration source et récepteur), vous pouvez indiquer l'URL d'adresse de service ou l'ID de 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 d'adresse de service, reportez-vous à Régions de données et URL de service associées dans le document Oracle NoSQL Database Cloud Service.[DEFAULT]
user=ocid1.user.oc1....
fingerprint=fd:96:....
tenancy=ocid1.tenancy.oc1....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=abcd
[DEFAULT2]
user=ocid1.user.oc1....
fingerprint=1b:68:....
tenancy=ocid1.tenancy.oc1....
region=us-phoenix-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=23456user_data de la région Ashburn vers la région Phoenix, procédez comme suit :
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 source de la table user_data dans la région Ashburn sont copiées dans la table user_data de cette région. Pour connaître la procédure d'accès à la console, reportez-vous à l'article Accès au service à partir de la console Infrastructure.
Migration d'Oracle NoSQL Database Cloud Service vers OCI Object Storage
Cet exemple présente l'utilisation d'Oracle NoSQL Database Migrator à partir d'un shell Cloud Shell.
Cas d'emploi
Une entreprise en démarrage prévoit d'utiliser Oracle NoSQL Database Cloud Service comme solution de stockage de données. L'entreprise souhaite utiliser Oracle NoSQL Database Migrator pour copier les données d'une table dans Oracle NoSQL Database Cloud Service vers OCI Object Storage afin d'effectuer des sauvegardes périodiques de ses données. Comme mesure rentable, ils souhaitent exécuter l'utilitaire NoSQL Database Migrator à partir de Cloud Shell, accessible à tous les utilisateurs OCI.
Dans ce cas d'emploi, vous allez apprendre à copier l'utilitaire NoSQL Database Migrator vers Cloud Shell dans la région abonnée et à effectuer une migration de données. Vous migrez les données source de la table Oracle NoSQL Database Cloud Service vers un fichier JSON dans OCI Object Storage.
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 via une procédure interactive.
- Téléchargez Oracle NoSQL Database Migrator sur votre ordinateur local à partir de la page Téléchargements Oracle NoSQL.
- Lancez Cloud Shell à partir du menu Outils de développement de la console cloud. Le navigateur Web ouvre votre répertoire personnel. Cliquez sur le menu Cloud Shell dans l'angle supérieur droit de la fenêtre Cloud Shell et sélectionnez l'option charger dans la liste déroulante. Dans la fenêtre instantanée, glissez-déplacez le package Oracle NoSQL Database Migrator à partir de votre ordinateur local ou cliquez sur l'option Sélectionner à partir de votre ordinateur, sélectionnez le package à partir de votre ordinateur local et cliquez sur le bouton Télécharger. Vous pouvez également glisser-déplacer le package Oracle NoSQL Database Migrator directement de l'ordinateur local vers le répertoire de base dans Cloud Shell. Extrayez le contenu du package.
- Identifiez la source et le récepteur de la sauvegarde.
-
Source : table
NDCSuploaddans la région Oracle NoSQL Database Cloud Service Ashburn.Pour la démonstration, considérez les données suivantes dans le tableauNDCSupload:{"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 l'adresse et l'ID de compartiment pour la source. Pour l'adresse, vous pouvez indiquer l'identificateur de région ou l'adresse de service. Pour obtenir la liste des régions de données prises en charge dans Oracle NoSQL Database Cloud Service, reportez-vous à Les régions de données et les URL de service associées.
- endpoint :
us-ashburn-1 - ID de compartiment :
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- endpoint :
-
Récepteur : fichier JSON dans le bucket OCI Object Storage.
Identifiez l'adresse de région, l'espace de noms, le bucket et le préfixe pour OCI Object Storage. Pour plus de détails, reportez-vous à Accès à Oracle Cloud Object Storage. Pour obtenir la liste des adresses de service OCI Object Storage, reportez-vous à Adresses Object Storage.
- endpoint :
us-ashburn-1 - bucket :
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.
Remarques :
Si le bucket Object Storage se trouve dans un autre compartiment, assurez-vous que vous disposez des privilèges nécessaires pour écrire des objets dans le bucket. Pour plus de détails sur la définition des stratégies, reportez-vous à Laisser les utilisateurs écrire des objets dans des buckets Object Storage. - endpoint :
-
NDCSupload d'Oracle NoSQL Database Cloud Service vers un fichier JSON dans le bucket OCI Object Storage à l'aide de Cloud Shell, procédez comme suit :
Pour valider votre sauvegarde de données, connectez-vous à la console Oracle NoSQL Database Cloud Service. Parcourez les menus, Storage > Object Storage & Archive Storage > Buckets. Accédez aux fichiers à partir du répertoire NDCSupload/Delegation dans le bucket Migrate_oci. Pour connaître la procédure d'accès à la console, reportez-vous à l'article Accès au service à partir de la console Infrastructure.
Migration à partir d'un fichier CSV vers Oracle NoSQL Database
Cet exemple illustre l'utilisation d'Oracle NoSQL Database Migrator pour copier des données 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 CSV, ils recherchent 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 proposés 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. Reportez-vous à Référence Oracle NoSQL Database Migrator.
- Identifiez la source et le récepteur de la migration.
- Source : fichier CSV
Dans cet exemple, le fichier source est
course.csvcat [~/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" - Récepteur : Oracle NoSQL Database
- Source : fichier CSV
- Le fichier CSV doit être conforme au format
RFC4180. - Créez un fichier contenant les commandes DDL pour le schéma de la table cible,
course. La définition de table doit correspondre au fichier de données CSV concernant le nombre de colonnes et leur type.Dans cet exemple, le fichier DDL est
mytable_schema.ddlcat [~/nosql-migrator-1.5.0]/mytable_schema.ddl create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
course.csv vers le service Oracle NoSQL Database, procédez comme suit :
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
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