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 devez inclure des fichiers JAR supplémentaires qui font partie de l'installation EE. Pour plus d'informations, reportez-vous à Oracle Wallet.
Sans les fichiers JAR, le message d'erreur suivant s'affiche :
Impossible de trouver kvstore-ee.jar et kvstore-ee-<version>.jar dans le répertoire lib. Copiez kvstore-ee.jar et kvstore-ee-<version>.jar dans le répertoire lib
kvstore-ee.jar et kvstore-ee-<version>.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 de logiciel release.major.minor. 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
La durée de vie est un mécanisme qui vous permet de faire expirer automatiquement les lignes de la table. La durée de vie est exprimée sous la forme d'une durée pendant laquelle les données peuvent résider dans le magasin. Les données qui ont atteint leur valeur de délai d'expiration ne peuvent plus être extraites et n'apparaîtront dans aucune statistique de magasin.
Table - Migration des métadonnées de durée de vie
| Types de source | Paramètre de configuration source | Paramètre de configuration du récepteur |
|---|---|---|
| Oracle NoSQL Database | includeTTL |
includeTTL |
| Oracle NoSQL Database Cloud Service | includeTTL |
includeTTL |
| Fichier JSON formaté par DynamoDB | ttlAttributeName |
includeTTL |
| Fichier JSON formaté DynamoDB stocké dans AWS S3 | ttlAttributeName |
includeTTL |
Export de métadonnées de durée de vie dans Oracle NoSQL Database et Oracle NoSQL Database Cloud Service
NoSQL Database Migrator fournit le paramètre de configuration includeTTL pour prendre en charge l'export des métadonnées de durée de vie de la ligne de table.
_metadata n'est pas inclus explicitement dans les données exportées car sa valeur d'expiration est toujours égale à 0. Le migrateur de base de données NoSQL 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 du paramètre de configuration includeTTL dans le modèle de configuration de récepteur.
L'heure de référence par défaut de l'opération d'import est l'heure en cours, en millisecondes, obtenue à partir de System.currentTimeMillis(), de l'ordinateur sur lequel l'outil NoSQL Database Migrator est exécuté. Toutefois, vous pouvez également définir une heure de référence personnalisée à l'aide du paramètre de configuration ttlRelativeDate si vous souhaitez prolonger la durée d'expiration et importer des lignes qui expireraient autrement immédiatement. L'extension est calculée comme suit et ajoutée au délai d'expiration.
Extended time = expiration time - reference timeL'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'emploi ne sont applicables que lorsque le paramètre de configuration includeTTL est défini sur True.
- 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.
Si la ligne à importer ne contient pas d'informations sur la durée de vie, NoSQL Database Migrator définit la durée de vie de la ligne sur 0.
- Cas d'utilisation 2 : la valeur de durée de vie de la ligne de table source a expiré par rapport à l'heure de référence à laquelle la ligne de table est importée.
La ligne de table expirée est ignorée et n'est pas écrite dans le magasin.
- 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 à laquelle la ligne de table est importée.
La ligne du tableau est importée avec une valeur de durée de vie. Cependant, la valeur de durée de vie importée peut ne pas correspondre à la valeur de durée de vie exportée d'origine en raison des contraintes de fenêtre d'heure et de jour entières dans la classe TimeToLive. Exemple :
Prenons une ligne de table exportée :{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC } }L'heure de référence lors de l'importation est 1734480000000, soit le mercredi 18 décembre 2024 à 12 h 00:00.
Ligne de table importée{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1734739200000 //Saturday, December 21, 2024 12:00:00 AM } }
Import de métadonnées de durée de vie dans un fichier JSON au format DynamoDB et un fichier JSON au format DynamoDB stockés dans AWS S3
NoSQL Database Migrator fournit un paramètre de configuration supplémentaire, ttlAttributeName, pour prendre en charge l'import des métadonnées de durée de vie à partir des éléments de fichier JSON au format DynamoDB.
Les fichiers JSON exportés par DynamoDB incluent un attribut spécifique dans chaque élément pour stocker l'horodatage d'expiration de durée de vie. Pour importer éventuellement les valeurs de durée de vie à partir des fichiers JSON exportés par DynamoDB, vous devez fournir le nom de l'attribut spécifique en tant que valeur au paramètre de configuration ttlAttributeName dans le fichier JSON formaté DynamoDB ou le fichier JSON formaté DynamoDB stocké dans les fichiers de configuration source AWS S3. Vous devez également définir le paramètre de configuration includeTTL dans le modèle de configuration de récepteur. Les puits valides sont Oracle NoSQL Database et Oracle NoSQL Database Cloud Service. NoSQL Database Migrator stocke les informations de durée de vie dans l'objet JSON _metadata de l'élément importé.
-
Cas d'utilisation 1 : la valeur du paramètre de configuration ttlAttributeName est définie sur le nom d'attribut de durée de vie indiqué dans le fichier JSON exporté DynamoDB.
NoSQL Database Migrator importe le délai d'expiration de cet élément en millisecondes depuis l'époque UNIX (1er janvier 1970).
Par exemple, prenons un élément dans le fichier JSON exporté DynamoDB :{ "Item": { "DeptId": { "N": "1" }, "DeptName": { "S": "Engineering" }, "ttl": { "N": "1734616800" } } }Ici, l'attributttlindique la valeur de durée de vie de l'élément. Si vous définissez le paramètre de configuration ttlAttributeName surttldans le fichier JSON au format DynamoDB ou dans le fichier JSON au format DynamoDB stocké dans le fichier de configuration source AWS S3, NoSQL Database Migrator importe le délai d'expiration de l'élément comme suit :{ "DeptId": 1, "document": { "DeptName": "Engineering" } "_metadata": { "expiration": 1734616800000 } }Remarques :
Vous pouvez indiquer le paramètre de configuration ttlRelativeDate dans le modèle de configuration de récepteur comme heure de référence pour le calcul de l'heure d'expiration. - Cas d'utilisation 2 : la valeur du paramètre de configuration ttlAttributeName est définie. Cependant, la valeur n'existe pas en tant qu'attribut dans l'élément du fichier JSON exporté DynamoDB.
NoSQL Database Migrator n'importe pas les informations de métadonnées de durée de vie pour l'élément indiqué.
- Cas d'utilisation 3 : la valeur du paramètre de configuration ttlAttributeName ne correspond pas au nom d'attribut dans l'élément du fichier JSON exporté DynamoDB.
NoSQL Database Migrator gère l'import de l'une des manières suivantes en fonction de la configuration du récepteur :
- Copie l'attribut en tant que champ normal s'il est configuré pour l'importation à l'aide du schéma par défaut.
- Ignore l'attribut s'il est configuré pour être importé à l'aide d'un schéma défini par l'utilisateur.
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>
Remarques :
NoSQL Database Migrator consomme des unités de lecture lors de l'export de données de la table Oracle NoSQL Cloud Service vers n'importe quel bascule valide.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 accéder au répertoire d'évier indiqué et afficher le schéma et les données.
-- Exported myTable Data. JSON files are created in the supplied data path
[~/nosqlMigrator]$cat myTable_1_5.json
{
"id" : 10,
"document" : {
"course" : "Computer Science",
"name" : "Neena",
"studentid" : 105
}
}
{
"id" : 3,
"document" : {
"course" : "Computer Science",
"name" : "John",
"studentid" : 107
}
}
{
"id" : 4,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 6,
"document" : {
"course" : "Bio-Technology",
"name" : "Rekha",
"studentid" : 104
}
}
{
"id" : 7,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 5,
"document" : {
"course" : "Journalism",
"name" : "Rani",
"studentid" : 106
}
}
{
"id" : 8,
"document" : {
"course" : "Computer Science",
"name" : "Tom",
"studentid" : 103
}
}
{
"id" : 9,
"document" : {
"course" : "Computer Science",
"name" : "Peter",
"studentid" : 109
}
}
{
"id" : 1,
"document" : {
"course" : "Journalism",
"name" : "Tracy",
"studentid" : 110
}
}
{
"id" : 2,
"document" : {
"course" : "Bio-Technology",
"name" : "Raja",
"studentid" : 108
}
}-- Exported myTable Schema
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))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 qui correspond 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 NoSQL Database.
Cas d'emploi:
Après avoir évalué plusieurs options, une organisation finalise Oracle NoSQL Database sur la 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"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}
Vous 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). Pour cet exemple, vous allez utiliser un fichier de configuration créé manuellement.
Prérequis
- Identifiez la source et le récepteur de la migration.
- Source : DynamoDB JSON File
- Basculement : Oracle NoSQL Database (sur site)
- Pour importer les 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 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
- Préparez le fichier de configuration (au format JSON) avec les détails de source et de récepteur identifiés. Pour plus d'informations, reportez-vous aux sections Source Configuration Templates et Sink Configuration Templates.
Remarques :
Si les éléments de table JSON exportés par DynamoDB contiennent un attribut de durée de vie, pour éventuellement importer les valeurs de durée de vie, indiquez l'attribut dans le paramètre de configuration ttlAttributeName du modèle de configuration source et définissez le paramètre de configuration includeTTL sur True dans le modèle de configuration de récepteur.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, vous définissez le paramètre de configuration defaultSchema sur True. Par conséquent, le migrateur de base de données NoSQL crée le schéma par défaut au niveau de l'évier. Vous devez indiquer
DDBPartitionKeyet le type de colonne NoSQL correspondant. Sinon, une erreur s'affiche.Pour plus de détails sur le schéma par défaut d'une source JSON exportée DynamoDB, reportez-vous à la rubrique Identifier la source et l'évier dans Workflow pour le migreur Oracle NoSQL Database.{ "source" : { "type" : "file", "format" : "dynamodb_json", "ttlAttributeName" : "ttl", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"], "table" : "sampledynDBImp", "includeTTL" : true, "schemaInfo" : { "DDBPartitionKey" : "Id:INTEGER", "defaultSchema" : true }, "overwrite" : true, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.6.5" }Le schéma par défaut suivant est utilisé dans cet exemple :CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) - 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, vous définissez le paramètre de configuration defaultSchema sur False. Par conséquent, vous indiquez le fichier contenant l'instruction DDL de la table de récepteur dans le paramètre schemaPath. Pour plus d'informations, reportez-vous à Mise en correspondance des types DynamoDB avec les types NoSQL Oracle.
Le schéma défini par l'utilisateur suivant est utilisé dans cet exemple :CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))NoSQL Database Migrator utilise le fichier de schéma pour créer la table au niveau 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 s'affiche.
Remarques :
- Si le type de données de la table de base de données Dynamo n'est pas pris en charge dans NoSQL Database, la migration échoue.
- Si les données d'entrée ne contiennent pas de valeur pour une colonne particulière (autre que la clé primaire), la valeur par défaut de la colonne 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. - Si vous modélisez la table DynamoDB en tant que document JSON, veillez à utiliser la transformation
AggregateFieldsafin d'agréger les données de clé non principale en colonne JSON. Pour plus d'informations, reportez-vous à aggregateFields .
{ "source" : { "type" : "file", "format" : "dynamodb_json", "ttlAttributeName" : "ttl", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"], "table" : "sampledynDBImp", "includeTTL" : true, "schemaInfo" : { "schemaPath" : "<full path of the schema file with the DDL statement>" }, "overwrite" : true, "requestTimeoutMs" : 5000 }, "transforms": { "aggregateFields" : { "fieldName" : "document", "skipFields" : ["Id"] } }, "abortOnError" : true, "migratorVersion" : "1.6.5" }
- 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 des fichiers de configuration distincts pour les options 1 et 2. Utilisez l'option--configou-c../runMigrator --config <complete/path/to/the/JSON/config/file> - L'utilitaire procède à la migration des données, comme illustré dans l'exemple suivant :
[INFO] creating source from given configuration: [INFO] source creation completed [INFO] creating sink from given configuration: [INFO] sink creation completed [INFO] creating migrator pipeline [INFO] [nosqldb sink] : start loading DDLs [INFO] [nosqldb sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) [INFO] [nosqldb sink] : completed loading DDLs [INFO] migration started [INFO] Start writing data to OnDB Sink [INFO] executing for source:DynamoSample [INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz [INFO] Writing data to OnDB Sink completed. [INFO] migration completed. Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0. Elapsed time: 0min 0sec 45ms Migration completed.
Validation
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoreSELECT * FROM sampledynDBImpSortie
_metadata pour chaque élément importé.{"Id":102,"document":{"Address":{"City":"Wales","DoorNum":1024,"Street":"32 main","Zip":560014},"Age":48,"FavColors":["Blue"],"FavNumbers":[10],"FirstName":"John","LastName":"White","Phones":[["222-222"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}
{"Id":101,"document":{"Address":{"City":"London","DoorNum":201,"Street":"21 main","Zip":570004},"Age":22,"FavColors":["Red","Green"],"FavNumbers":[10],"FirstName":"Fred","LastName":"Smith","Phones":[["555-222","123-567"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}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. Pour plus d'informations, reportez-vous aux sections Source Configuration Templates et Sink Configuration Templates.
Remarques :
Si les éléments de votre fichier JSON DynamoDB dans AWS S3 contiennent un attribut de durée de vie, pour importer éventuellement les valeurs de durée de vie, indiquez l'attribut dans le paramètre de configuration ttlAttributeName du modèle de configuration source et définissez le paramètre de configuration includeTTL sur True dans le modèle de configuration de récepteur. Pour plus d'informations, reportez-vous à Migration des métadonnées de durée de vie pour les lignes de table.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, defaultSchema est
TRUEet le migreur crée donc le schéma par défaut au niveau de l'évier. Vous devez indiquer le type de colonne 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.6.5" }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 partitionnement 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, defaultSchema est
FALSEet 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 NoSQL Oracle.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. - Si vous modélisez la table DynamoDB en tant que document JSON, veillez à utiliser la transformation
AggregateFieldsafin d'agréger les données de clé non principale en colonne JSON. Pour plus d'informations, reportez-vous à aggregateFields .
{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "transforms": { "aggregateFields" : { "fieldName" : "document", "skipFields" : ["AccountId"] } }, "abortOnError" : true, "migratorVersion" : "1.6.5" } - 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,
- 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]$./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 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 à Ecriture d'objets dans 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 d'OCI Object Storage vers Oracle NoSQL Database Cloud Service à l'aide de l'authentification OKE
Cet exemple montre comment utiliser Oracle NoSQL Database Migrator avec l'authentification d'identité de charge globale OKE pour copier des données d'un fichier JSON dans OCI Object Storage vers la table Oracle NoSQL Database Cloud Service.
Cas d'emploi
En tant que développeur, vous étudiez une option permettant de restaurer des données à partir d'un fichier JSON dans un bucket OCI Object Storage (O/S OCI) vers une table Oracle NoSQL Database Cloud Service (NDCS) à l'aide de NoSQL Database Migrator dans une application en conteneur. Une application en conteneur est un environnement virtualisé qui regroupe l'application et toutes ses dépendances (comme les bibliothèques, les fichiers binaires et les fichiers de configuration) dans un package. Cela permet à l'application de s'exécuter de manière cohérente dans différents environnements, quelle que soit l'infrastructure sous-jacente.
Vous voulez exécuter NoSQL Database Migrator dans un pod Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). Pour accéder en toute sécurité au système d'exploitation OCI et aux services NDCS à partir du pod OKE, vous utiliserez la méthode WIA (Workload Identity Authentication).
Dans cette démonstration, vous allez créer une image Docker pour NoSQL Database Migrator, la copier dans un référentiel dans Container Registry, créer un cluster OKE et déployer l'image Migrator dans le pod de cluster OKE pour exécuter l'utilitaire Migrator. Vous y trouverez un fichier de configuration NoSQL Database Migrator créé manuellement pour exécuter l'utilitaire Migrator en tant qu'application en conteneur.
- Identifiez la source et le récepteur de la migration.
- Source : fichiers JSON et fichier de schéma dans le bucket de système d'exploitation OCI.
Identifiez l'adresse, l'espace de noms, le bucket et le préfixe de région pour le bucket de système d'exploitation OCI dans lequel les fichiers et le schéma JSON source sont disponibles. Pour plus de détails, reportez-vous à Accès à Oracle Cloud Object Storage. Pour obtenir la liste des adresses de service de système d'exploitation OCI, reportez-vous à Adresses Object Storage.
- endpoint :
us-ashburn-1 - bucket :
Migrate_oci - préfixe :
userSession - espace de noms :
idhkv1iewjzjLe nom d'espace de noms d'un bucket est identique à celui de la location. Il est généré automatiquement lors de la création de la location. Vous pouvez obtenir le nom de l'espace de noms comme suit :- Dans la console Oracle NoSQL Database Cloud Service, accédez à Storage > Buckets.
- Sélectionnez le compartiment dans la portée de la liste et sélectionnez le bucket. La page Détails du bucket affiche le nom dans le paramètre Espace de noms.
Si vous ne fournissez pas de nom d'espace de noms de système d'exploitation OCI, l'utilitaire de migration utilise l'espace de noms par défaut de la location.
- endpoint :
- récepteur : table
usersdans Oracle NoSQL Database Cloud Service.Identifiez l'adresse de région, ou l'adresse de service et le nom du compartiment pour le récepteur :
- endpoint :
us-ashburn-1 - compartiment :
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identifiez le schéma de la table de récepteur :
Pour utiliser le nom de table et le schéma stockés dans le bucket de système d'exploitation OCI, définissez le paramètre useSourceSchema sur True. Pour plus d'informations sur les autres options de schéma, reportez-vous à la rubrique Identifier la source et le récepteur dans Workflow pour Oracle NoSQL Database Migrator.
Remarques :
Assurez-vous que vous disposez des privilèges d'écriture sur le compartiment dans lequel vous restaurez les données dans la table NDCS. Pour plus de détails, reportez-vous à Gestion des compartiments. - endpoint :
- Source : fichiers JSON et fichier de schéma dans le bucket de système d'exploitation OCI.
- Préparez une image Docker pour NoSQL Database Migrator et déplacez-la vers Container Registry.
- Obtenez l'espace de noms de location à partir de la console OCI.
Connectez-vous à la console Oracle NoSQL Database Cloud Service. Dans la barre de navigation, sélectionnez le menu Profil, puis Location : <Nom de l'entité>.
Copiez le nom de l'espace de noms Object Storage, qui est l'espace de noms de location, dans le presse-papiers.
- Créez une image Docker pour l'utilitaire de migration.
Accédez au répertoire dans lequel vous avez extrait l'utilitaire NoSQL Database Migrator. Le package de migration inclut un fichier docker nommé Dockerfile. A partir d'une interface de commande, utilisez la commande suivante pour créer une image Docker de l'utilitaire de migration :
#Command: docker build -t nosqlmigrator:<tag> .#Example: docker build -t nosqlmigrator:1.0 .Vous pouvez indiquer un identificateur de version pour l'image Docker dans l'optiontag. Vérifiez l'image Docker à l'aide de la commande suivante :#Command: Docker images#Example output ------------------------------------------------------------------------------------------ REPOSITORY TAG IMAGE ID CREATED SIZE localhost/nosqlmigrator 1.0 e1dcec27a5cc 10 seconds ago 487 MB quay.io/podman/hello latest 83fc7ce1224f 10 months ago 580 kB docker.io/library/openjdk 17-jdk-slim 8a3a2ffec52a 2 years ago 406 MB ------------------------------------------------------------------------------------------ - Générez un token d'authentification.
Vous avez besoin d'un jeton d'authentification pour vous connecter au registre de conteneurs afin de stocker l'image Docker du migrateur. Si vous n'avez pas encore de jeton d'authentification, vous devez en générer un. Pour plus d'informations, reportez-vous à Obtention d'un jeton d'authentification.
- Stockez l'image Docker du migrateur dans Container Registry.
Pour accéder à l'image Docker de migrateur à partir du pod Kubernetes, vous devez stocker l'image dans n'importe quel registre public ou privé. Par exemple, Docker, Artifact Hub, OCI Container Registry, etc. sont quelques registres. Dans cette démonstration, nous utilisons Container Registry. Pour plus d'informations, reportez-vous à Présentation de Container Registry.
- A partir de la console OCI, créez un référentiel dans Container Registry. Pour plus de détails, reportez-vous à Création d'un référentiel.
Pour cette démonstration, vous allez créer un référentiel
okemigrator.Figure - Référentiel dans Container Registry
- Connectez-vous au registre de conteneurs à partir de votre interface de commande à l'aide de la commande suivante :
#Command: docker login <region-key>.ocir.io -u <tenancy-namespace>/<user name>password: <Auth token>#Example: docker login iad.ocir.io -u idhx..xxwjzj/rx..xxxxh@oracle.com password: <Auth token>#Output: Login Succeeded!Dans la commande ci-dessus,
region-key: indique la clé de la région dans laquelle vous utilisez Container Registry. Pour plus de détails, reportez-vous à Disponibilité par région.tenancy-namespace: indique l'espace de noms de location que vous avez copié à partir de la console OCI.user name: indique le nom utilisateur de la console OCI.password: indique le jeton d'authentification. - Balisez et propagez votre image Docker de migrateur vers Container Registry à l'aide des commandes suivantes :
#Command: docker tag <Migrator Docker image> <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag> docker push <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>#Example: docker tag localhost/nosqlmigrator:1.0 iad.ocir.io/idhx..xxwjzj/okemigrator:1.0 docker push iad.ocir.io/idhx..xxwjzj/okemigrator:1.0Dans la commande ci-dessus,
repo: indique le nom du référentiel que vous avez créé dans Container Registry.tag: indique l'identificateur de version de l'image Docker.#Output: Getting image source signatures Copying blob 0994dbbf9a1b done | Copying blob 37849399aca1 done | Copying blob 5f70bf18a086 done | Copying blob 2f263e87cb11 done | Copying blob f941f90e71a8 done | Copying blob c82e5bf37b8a done | Copying blob 2ad58b3543c5 done | Copying blob 409bec9cdb8b done | Copying config e1dcec27a5 done | Writing manifest to image destination
- A partir de la console OCI, créez un référentiel dans Container Registry. Pour plus de détails, reportez-vous à Création d'un référentiel.
- Obtenez l'espace de noms de location à partir de la console OCI.
- Configurez un cluster OKE avec WIA vers NDCS et le système d'exploitation OCI.
- Créez un cluster Kubernetes à l'aide d'OKE.
A partir de la console OCI, définissez et créez un cluster Kubernetes en fonction de la disponibilité des ressources réseau à l'aide d'OKE. Vous avez besoin d'un cluster Kubernetes pour exécuter l'utilitaire de migration en tant qu'application en conteneur. Pour plus d'informations sur la création de cluster, reportez-vous à Création de clusters Kubernetes à l'aide de workflows de console.
Pour cette démonstration, vous pouvez créer un cluster géré à noeud unique à l'aide du workflow de création rapide détaillé dans le lien ci-dessus.
Figure - Cluster Kubernetes pour le conteneur de migration
- Configurez WIA à partir de la console OCI pour accéder aux autres ressources OCI à partir du cluster Kubernetes.
Pour accorder à l'utilitaire de migration l'accès au bucket de système d'exploitation NDCS et OCI lors de l'exécution à partir des pods de cluster Kubernetes, vous devez configurer WIA. Suivez les étapes ci-dessous :
- Configurez le fichier de configuration kubeconfig du cluster.
- Dans la console OCI, ouvrez le cluster Kubernetes que vous avez créé et cliquez sur le bouton Accéder au cluster.
- Dans la boîte de dialogue Accéder au cluster, cliquez sur Accès à Cloud Shell.
- Cliquez sur Lancer Cloud Shell pour afficher la fenêtre Cloud Shell.
- Exécutez la commande de l'interface de ligne de commande Oracle Cloud Infrastructure pour configurer le fichier kubeconfig. Vous pouvez copier la commande à partir de la boîte de dialogue Accéder au cluster. Le résultat suivant est attendu :
#Example: oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aaa...muqzq --file $HOME/.kube/config --region us-ashburn-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT#Output: New config written to the Kubeconfig file /home/<user>/.kube/config
- Copiez l'OCID du cluster à partir de l'option
cluster-iddans la commande ci-dessus et enregistrez-le pour l'utiliser dans d'autres étapes.ocid1.cluster.oc1.iad.aaa...muqzq - Créez un espace de noms pour le compte de service Kubernetes à l'aide de la commande suivante dans la fenêtre de shell cloud :
#Command: kubectl create namespace <namespace-name>#Example: kubectl create namespace migrator#Output: namespace/migrator created - Créez un compte de service Kubernetes pour l'application Migrator dans un espace de noms à l'aide de la commande suivante dans la fenêtre de shell cloud :
#Command: kubectl create serviceaccount <service-account-name> --namespace <namespace-name>#Example: kubectl create serviceaccount migratorsa --namespace migrator#Output: serviceaccount/migratorsa created - Définissez une stratégie IAM à partir de la console OCI pour permettre à la charge globale d'accéder aux ressources OCI à partir du cluster Kubernetes.
A partir de la console OCI, accédez aux menus Identité et sécurité > Identité > Stratégies. Créez les stratégies suivantes pour autoriser l'accès aux ressources
nosql-familyetobject-family. Utilisez l'OCID du cluster, de l'espace de noms et des valeurs de compte de service des étapes précédentes.#Command: Allow <subject> to <verb> <resource-type> in <location> where <conditions>#Example: Allow any-user to manage nosql-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'} Allow any-user to manage object-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}Pour plus de détails sur la création de stratégies, reportez-vous à Utilisation de la console pour créer une stratégie.
- Configurez le fichier de configuration kubeconfig du cluster.
- Créez un cluster Kubernetes à l'aide d'OKE.
Pour effectuer une migration du fichier JSON du bucket de système d'exploitation OCI vers la table NDCS, effectuez les opérations suivantes à partir de la fenêtre Cloud Shell :
Pour vérifier la restauration des données, connectez-vous à la console Oracle NoSQL Database Cloud Service. Dans la barre de navigation, accédez à Bases de données > Base de données NoSQL. Sélectionnez votre compartiment dans la liste déroulante pour visualiser la table users. Pour connaître la procédure d'accès à la console, reportez-vous à Accès au service à partir de la console Infrastructure.
Migrer d'Oracle NoSQL Database vers OCI Object Storage à l'aide de l'authentification par jeton de session
Cet exemple montre comment utiliser Oracle NoSQL Database Migrator avec l'authentification par jeton de session pour copier des données de la table Oracle NoSQL Database vers un fichier JSON dans un bucket OCI Object Storage.
En tant que développeur, vous étudiez une option permettant de sauvegarder les données de table Oracle NoSQL Database vers OCI Object Storage (O/S OCI). Vous voulez utiliser l'authentification par jeton de session.
Dans cette démonstration, vous allez utiliser les commandes de l'interface de ligne de commande OCI pour créer un jeton de session. Vous allez créer manuellement un fichier de configuration Migrator et effectuer la migration des données.
- Identifiez la source et le récepteur de la migration.
- Source : table
usersdans Oracle NoSQL Database. - Sink : fichier JSON dans le bucket de système d'exploitation OCI
Identifiez l'adresse, l'espace de noms, le bucket et le préfixe de région pour le système d'exploitation OCI. Pour plus de détails, reportez-vous à Accès à Oracle Cloud Object Storage. Pour obtenir la liste des adresses de service de système d'exploitation OCI, reportez-vous à Adresses Object Storage.
- endpoint :
us-ashburn-1 - bucket :
Migrate_oci - préfixe :
userSession - espace de noms :
idhkv1iewjzjLe nom d'espace de noms d'un bucket est identique à celui de la location. Il est généré automatiquement lors de la création de la location. Vous pouvez obtenir le nom de l'espace de noms comme suit :- A partir de la console Oracle NoSQL Database Cloud Service, accédez à Storage > Buckets.
- Sélectionnez le compartiment dans la portée de la liste et sélectionnez le bucket. La page Détails du bucket affiche le nom dans le paramètre Espace de noms.
Si vous ne fournissez pas de nom d'espace de noms de système d'exploitation OCI, l'utilitaire de migration utilise l'espace de noms par défaut de la location.
Remarques :
Assurez-vous que vous disposez des privilèges requis pour écrire des objets dans le bucket du système d'exploitation OCI. Pour plus de détails sur la définition des stratégies, reportez-vous à Ecriture dans Object Storage. - endpoint :
- Source : table
- Pour générer un jeton de session, procédez comme suit :
- Installez et configurez l'interface de ligne de commande OCI. Reportez-vous à Démarrage rapide.
- Utilisez l'une des commandes de l'interface de ligne de commande OCI suivantes pour générer un jeton de session. Pour plus d'informations sur les options disponibles, reportez-vous à Authentification basée sur un jeton pour l'interface de ligne de commande.
#Create a session token using OCI CLI from a web browser: oci session authenticate --region <region_name> --profile-name <profile_name>#Example: oci session authenticate --region us-ashburn-1 --profile-name SESSIONPROFILEou
#Create a session token using OCI CLI without a web browser: oci session authenticate --no-browser --region <region_name> --profile-name <profile_name>#Example: oci session authenticate --no-browser --region us-ashburn-1 --profile-name SESSIONPROFILEDans la commande ci-dessus,
region_name: indique l'adresse de région pour le système d'exploitation OCI. Pour obtenir la liste des régions de données prises en charge dans Oracle NoSQL Database Cloud Service, reportez-vous à Régions de données et URL de service associées.profile_name: indique le profil utilisé par la commande de l'interface de ligne de commande OCI pour générer un jeton de session.La commande de l'interface de ligne de commande OCI crée une entrée dans le fichier de configuration OCI au niveau du chemin$HOME/.oci/config, comme indiqué dans l'exemple suivant :[SESSIONPROFILE] fingerprint=f1:e9:b7:e6:25:ff:fe:05:71:be:e8:aa:cc:3d:0d:23 key_file=$HOME/.oci/sessions/SESSIONPROFILE/oci_api_key.pem tenancy=ocid1.tenancy.oc1..aaaaa ... d6zjq region=us-ashburn-1 security_token_file=$HOME/.oci/sessions/SESSIONPROFILE/tokensecurity_token_filepointe vers le chemin du jeton de session généré à l'aide de la commande de l'interface de ligne de commande OCI ci-dessus.Remarques :
- Si le profil existe déjà dans le fichier de configuration OCI, la commande de l'interface de ligne de commande OCI remplace le profil par la configuration liée au jeton de session lors de la génération du jeton de session.
- Spécifiez les éléments suivants dans votre modèle de configuration de récepteur :
- Chemin du fichier de configuration OCI dans le paramètre credentials.
- Profil utilisé lors de la génération du jeton de session dans le paramètre credentialsProfile.
"credentials" : "$HOME/.oci/config" "credentialsProfile" : "SESSIONPROFILE"L'utilitaire Migrator extrait automatiquement les détails du jeton de session généré à l'aide des paramètres ci-dessus. Si vous n'indiquez pas le paramètre credentials, l'utilitaire de migration recherche le fichier d'informations d'identification dans le chemin
$HOME/.oci. Si vous n'indiquez pas le paramètre credentialsProfile, l'utilitaire de migration utilise le nom de profil par défaut (DEFAULT) du fichier de configuration OCI. - Le jeton de session est valide pendant 60 minutes. Pour prolonger la durée de la session, vous pouvez actualiser la session. Pour plus d'informations, reportez-vous à Actualisation d'un jeton.
Pour migrer de la table Oracle NoSQL Database vers un fichier JSON dans le bucket de système d'exploitation OCI, procédez comme suit :
Pour vérifier 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 userSession dans le bucket Migrate_oci. Pour connaître la procédure d'accès à la console, reportez-vous à 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