Référence Oracle NoSQL Database Migrator

Découvrez les paramètres de modèle de configuration source, récepteur et de transformation disponibles pour Oracle NoSQL Database Migrator.

Cet article comprend les rubriques suivantes :

Rubriques connexes

Paramètres

Le NoSQL Database Migrator requiert un fichier de configuration dans lequel vous définissez tous les paramètres pour effectuer l'activité de migration. Quelques paramètres sont communs à plusieurs sources et puits. Cette rubrique fournit la liste de ces paramètres communs. Pour obtenir la liste des autres paramètres propres à chaque source ou récepteur, reportez-vous aux sections du modèle de configuration correspondant.

Paramètres de configuration communs

Voici les paramètres de configuration courants. Reportez-vous aux sections de chaque modèle de configuration pour obtenir des exemples.

bucket

Objectif : indique le nom du bucket OCI Object Storage, qui contient les objets source/récepteur.

Assurez-vous que le bucket requis existe déjà dans l'instance OCI Object Storage et dispose de droits d'accès en lecture/écriture.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

chunkSize

Objectif : indique la taille maximale d'un chunk de données de table à stocker dans le récepteur. La valeur est en Mo. Pendant la migration, une table est divisée en blocs chunkSize et chaque bloc est écrit en tant que fichier distinct dans le récepteur. Un nouveau fichier est créé lorsque les données source en cours de migration dépassent la valeur chunkSize.

Si elle n'est pas indiquée, la valeur par défaut est 32 Mo. La valeur valide est un entier compris entre 1 et 1024.
Type de données : entier
Obligatoire (O/N) : N

credentials

Objectif : indique le chemin absolu d'un fichier contenant des informations d'identification OCI. NoSQL Database Migrator utilise ce fichier pour se connecter au service OCI, tel qu'Oracle NoSQL Database Cloud Service, OCI Object Storage, etc.

La valeur par défaut est $HOME/.oci/config.

Reportez-vous à la section Example Configuration pour obtenir un exemple de fichier d'informations d'identification.

Remarques :
Les paramètres d'authentification credentials, useInstancePrincipal et useDelegationToken s'excluent mutuellement. Indiquez un seul de ces paramètres dans le modèle de configuration.
Type de données : chaîne
Obligatoire (O/N) : N

credentialsProfile

Objectif : indique le nom du profil de configuration à utiliser pour la connexion au service OCI, tel qu'Oracle NoSQL Database Cloud Service, OCI Object Storage, etc. Les informations d'identification de compte utilisateur sont appelées profil.

Si vous n'indiquez pas cette valeur, NoSQL Database Migrator utilise le profil DEFAULT.

Remarques :
Ce paramètre est valide uniquement si le paramètre credentials est spécifié.
Type de données : chaîne
Obligatoire (O/N) : N

endpoint

Objectif : Indique l'une des valeurs suivantes :
- URL d'adresse de service ou ID de région pour le service OCI Object Storage.
  Pour obtenir la liste des adresses de service OCI Object Storage, reportez-vous à Adresses Object Storage.
- URL d'adresse de service ou ID de région pour Oracle NoSQL Database Cloud Service.
  Vous pouvez indiquer l'URL complète ou l'ID de région uniquement. Pour obtenir la liste des régions de données prises en charge pour Oracle NoSQL Database Cloud Service, reportez-vous à Les régions de données et les URL de service associées dans le document Oracle NoSQL Database Cloud Service.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

format

Objectif : Indique le format source/récepteur.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

namespace

Objectif : indique l'espace de noms du service OCI Object Storage. Ce paramètre est facultatif. Si vous n'indiquez pas ce paramètre, l'espace de noms par défaut de la location est utilisé.
Type de données : chaîne
Obligatoire (O/N) : N

préfixe

Objectif : le préfixe sert de conteneur logique ou de répertoire pour le stockage des données dans le bucket OCI Object Storage.
- Modèle de configuration source : si le paramètre prefix est indiqué, tous les objets du répertoire nommé dans le paramètre prefix sont migrés. Sinon, tous les objets présents dans le bucket sont migrés.
- Modèle de configuration de récepteur : si le paramètre prefix est indiqué, un répertoire avec le préfixe donné est créé dans le bucket et les objets sont migrés dans ce répertoire. Sinon, le nom de table de la source est utilisé comme préfixe. Si un objet portant le même nom existe déjà dans le bucket, il est écrasé.
Pour plus d'informations sur les préfixes, reportez-vous à Résolution de noms d'objet à l'aide de préfixe et de hiérarchie.
Type de données : chaîne
Obligatoire (O/N) : N

requestTimeoutMs

Objectif : indique le temps d'attente de la fin de chaque opération de lecture/écriture depuis/vers le magasin. Ceci est fourni en millisecondes. La valeur par défaut est 5 000. Il doit s'agir d'un entier positif.
Type de données : entier
Obligatoire (O/N) : N

sécurité

Objectif : indique le chemin absolu du fichier de connexion de sécurité qui contient les informations d'identification de l'emplacement de stockage si l'emplacement de stockage est sécurisé. Pour plus d'informations sur le fichier de connexion de sécurité, reportez-vous à la section Configuring Security with Remote Access dans le Guide de l'administrateur.

Vous pouvez utiliser l'authentification basée sur un fichier de mots de passe ou sur un portefeuille. Toutefois, l'authentification basée sur un portefeuille est prise en charge uniquement dans Enterprise Edition (EE) d'Oracle NoSQL Database. Pour plus d'informations sur l'authentification basée sur un portefeuille, reportez-vous à Sécurité de source et de récepteur.

L'édition Community Edition (CE) prend uniquement en charge l'authentification basée sur un fichier de mots de passe.
Type de données : chaîne
Obligatoire (O/N) : O, pour un magasin sécurisé

type

Objectif : Identifie le type d'origine/d'évier.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

useDelegationToken

Objectif : indique si l'outil NoSQL Database Migrator utilise ou non une authentification par jeton de délégation pour se connecter aux services OCI. Vous devez utiliser l'authentification par jeton de délégation pour exécuter l'utilitaire de migration à partir de Cloud Shell. Le jeton de délégation est créé automatiquement pour l'utilisateur lorsque Cloud Shell est appelé.

La valeur par défaut est false.
Type de données : booléen

Obligatoire (O/N) : N

Remarques :

L'authentification avec jeton de délégation est prise en charge uniquement lorsque l'outil NoSQL Database Migrator est exécuté à partir d'un shell Cloud Shell.
Les paramètres d'authentification credentials, useInstancePrincipal et useDelegationToken s'excluent mutuellement. Indiquez un seul de ces paramètres dans le modèle de configuration.

Cloud Shell prend uniquement en charge la migration entre les sources et les puits suivants :

Type	Source valide	Evier valide
Oracle NoSQL Database Cloud Service (`nosqldb_cloud`)	O	O
Fichier (fichier JSON dans le répertoire de base)	O	O
OCI Object Storage (fichier JSON) (`object_storage_oci`)	O	O
OCI Object Storage (fichier Parquet) (`object_storage_oci`)	N	O

useInstancePrincipal

Objectif : indique si l'outil NoSQL Database Migrator utilise ou non l'authentification par principal d'instance pour se connecter au service OCI, tel qu'Oracle NoSQL Database Cloud Service, OCI Object Storage, etc. Pour plus d'informations sur la méthode d'authentification du principal d'instance, reportez-vous à Sécurité de la source et du récepteur.

La valeur par défaut est false.
Remarques :
- L'authentification avec les ID instance est prise en charge uniquement lorsque l'outil NoSQL Database Migrator est exécuté dans une instance de calcul OCI, par exemple, l'outil NoSQL Database Migrator exécuté dans une machine virtuelle hébergée sur OCI.
- Les paramètres d'authentification credentials, useInstancePrincipal et useDelegationToken s'excluent mutuellement. Indiquez un seul de ces paramètres dans le modèle de configuration.
Type de données : booléen
Obligatoire (O/N) : N

Modèles de configuration source

Découvrez les formats de fichier de configuration source pour chaque source valide et l'objectif de chaque paramètre de configuration.

Pour le modèle de fichier de configuration, reportez-vous à Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Pour plus d'informations sur les formats de récepteur valides pour chaque source, reportez-vous à la section Sink Configuration Templates.

Rubriques

Les rubriques suivantes décrivent les modèles de configuration source référencés par Oracle NoSQL Database Migrator pour copier les données de la source donnée vers un récepteur valide.

Source du fichier JSON
Fichier ou répertoire spécifié contenant les données JSON.
Fichier JSON dans le bucket OCI Object Storage
Fichier JSON indiqué dans le bucket OCI Object Storage.
Fichier JSON au format MongoDB
Fichier ou répertoire indiqué contenant les données JSON formatées MongoDB.
Fichier JSON au format MongoDB dans le bucket OCI Object Storage
Fichier JSON exporté MongoDB indiqué stocké dans le bucket OCI Object Storage.
Fichier JSON au format DynamoDB stocké dans AWS S3
Le fichier JSON exporté DynamoDB indiqué est stocké dans le stockage AWS S3.
Fichier JSON au format DynamoDB
Le fichier JSON exporté DynamoDB indiqué à partir d'un système de fichiers.
Oracle NoSQL Database
Table indiquée dans Oracle NoSQL Database.
Oracle NoSQL Database Cloud Service
Table indiquée dans Oracle NoSQL Database Cloud Service.
Source du fichier CSV
Fichier ou répertoire spécifié contenant les données CSV.
Fichier CSV dans le bucket OCI Object Storage
Fichier CSV indiqué dans le bucket OCI Object Storage.

Source de fichier JSON

Le format de fichier de configuration du fichier JSON en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer un fichier source JSON en indiquant le chemin du fichier ou un répertoire dans le modèle de configuration source.

Voici un exemple de fichier source JSON :

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

Modèle de configuration source

"source": {
  "type": "file",
  "format": "json",
  "dataPath": "<path/to/JSON/[file|dir]>",
  "schemaInfo": {
    "schemaPath": "<path/to/schema/file>"
  }
},

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "file"
format
Utiliser "format" : "json"

Paramètres de configuration uniques

dataPath
schemaInfo
schemaInfo.schemaPath

dataPath

Objectif : indique le chemin absolu d'un fichier ou d'un répertoire contenant les données JSON à migrer.

Vous devez vous assurer que ces données correspondent au schéma de table NoSQL défini au niveau du récepteur. Si vous spécifiez un répertoire, NoSQL Database Migrator identifie tous les fichiers portant l'extension .json dans ce répertoire pour la migration. Les sous- répertoires ne sont pas pris en charge.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple :
- Spécification d'un fichier JSON
  
  "dataPath" : "/home/user/sample.json"
- Indiquer un répertoire
  
  "dataPath" : "/home/user"

schemaInfo

Objectif : indique le schéma des données source en cours de migration. Ce schéma est transmis au récepteur NoSQL.
Type de données : objet
Obligatoire (O/N) : N

schemaInfo.schemaPath

Objectif : indique le chemin absolu du fichier de définition de schéma contenant les instructions DDL pour la table NoSQL en cours de migration.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

Exemple :

"schemaInfo": {
  "schemaPath": "<path to the schema file>"
}

Fichier JSON dans le bucket OCI Object Storage

Le format de fichier de configuration du fichier JSON dans le bucket OCI Object Storage en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer un fichier JSON dans le bucket OCI Object Storage en indiquant le nom du bucket dans le modèle de configuration source.

Voici un exemple de fichier source JSON dans le bucket OCI Object Storage :

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

Remarques :

Les types de récepteur valides pour le type de source OCI Object Storage sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "object_storage_oci",
  "format" : "json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "schemaInfo" : {
     "schemaObject" : "<object name>"
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>
}

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "object_storage_oci"
format
Utiliser "format" : "json"
endpoint
Par exemple :
- ID de région : "endpoint" : "us-ashburn-1"
- Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"
espace de noms
Exemple : "namespace" : "my-namespace"
bucket
Exemple : "bucket" : "my-bucket"
préfixe
Par exemple :
1. "prefix" : "my_table/Data/000000.json" (migre uniquement 000000.json)
2. "prefix" : "my_table/Data" (migre tous les objets avec le préfixe my_table/Data)
informations d'identification
Par exemple :
1. "credentials" : "/home/user/.oci/config"
2. "credentials" : "/home/user/security/config"
credentialsProfile
Par exemple :
1. "credentialsProfile" : "DEFAULT"
2. "credentialsProfile" : "ADMIN_USER"
useInstancePrincipal
Exemple : "useInstancePrincipal" : true
useDelegationToken
Exemple : "useDelegationToken" : true

Remarques :
L'authentification avec jeton de délégation est prise en charge uniquement lorsque NoSQL Database Migrator est exécuté à partir d'un shell Cloud Shell.

Paramètres de configuration uniques

schemaInfo
schemaInfo.schemaObject

schemaInfo

Objectif : indique le schéma des données source en cours de migration. Ce schéma est transmis au récepteur NoSQL.
Type de données : objet
Obligatoire (O/N) : N

schemaInfo.schemaObject

Objectif : indique le nom de l'objet dans le bucket où sont stockées les définitions de schéma de table NoSQL pour les données en cours de migration.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

Exemple :

"schemaInfo": {
  "schemaObject": "mytable/Schema/schema.ddl"
},

Fichier JSON au format MongoDB

Le format du fichier de configuration pour le fichier JSON au format MongoDB en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer des données JSON exportées MongoDB en indiquant le fichier ou le répertoire dans le modèle de configuration source.

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 pour plus d'informations.

Voici un exemple de fichier JSON Mode décontracté au format MongoDB :

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

Modèle de configuration source

"source": {
  "type": "file",
  "format": "mongodb_json",
  "dataPath": "</path/to/json/[file|dir]>",
  "schemaInfo": {
    "schemaPath": "</path/to/schema/file>"
  }
}

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "file"
format
Utilisez "format" : "mongodb_json"

Paramètres de configuration uniques

dataPath
schemaInfo
schemaInfo.schemaPath

dataPath

Objectif : indique le chemin absolu d'un fichier ou d'un répertoire contenant les données JSON exportées MongoDB pour la migration.

Vous pouvez fournir le fichier JSON au format MongoDB généré à l'aide de l'outil mongoexport.

Si vous spécifiez un répertoire, NoSQL Database Migrator identifie tous les fichiers portant l'extension .json dans ce répertoire pour la migration. Les sous- répertoires ne sont pas pris en charge. Vous devez vous assurer que ces données correspondent au schéma de table NoSQL défini au niveau du récepteur.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple :
- Spécification d'un fichier JSON au format MongoDB
  
  "dataPath" : "/home/user/sample.json"
- Indiquer un répertoire
  
  "dataPath" : "/home/user"

schemaInfo

Objectif : indique le schéma des données source en cours de migration. Ce schéma est transmis au récepteur NoSQL.
Type de données : objet
Obligatoire (O/N) : N

schemaInfo.schemaPath

Objectif : indique le chemin absolu du fichier de définition de schéma contenant les instructions DDL pour la table NoSQL en cours de migration.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

Exemple :

"schemaInfo" : {
  "schemaPath" : "/home/user/mytable/Schema/schema.ddl"
}

Fichier JSON au format MongoDB dans le bucket OCI Object Storage

Le format de fichier de configuration du fichier JSON au format MongoDB dans le bucket OCI Object Storage en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer les données JSON exportées MongoDB dans le bucket OCI Object Storage en indiquant le nom du bucket dans le modèle de configuration source.

Extrayez les données de MongoDB à l'aide de l'utilitaire mongoexport et téléchargez-les vers le bucket OCI Object Storage. Pour plus d'informations, reportez-vous à mongoexport. MongoDB prend en charge deux types d'extension au format JSON des fichiers, Mode canonique et Mode décontracté. Les deux formats sont pris en charge dans le bucket OCI Object Storage.

Voici un exemple de fichier JSON en mode Relaxé au format MongoDB :

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

Remarques :

Les types de récepteur valides pour le type de source OCI Object Storage sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "object_storage_oci",
  "format" : "mongodb_json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "schemaInfo" : {
     "schemaObject" : "<object name>"
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>
}

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "object_storage_oci"
format
Utilisez "format" : "mongodb_json"
endpoint
Par exemple :
- ID de région : "endpoint" : "us-ashburn-1"
- Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"
espace de noms
Exemple : "namespace" : "my-namespace"
bucket
Exemple : "bucket" : "my-bucket"
préfixe
Par exemple :
1. "prefix" : "mongo_export/Data/table.json" (migre uniquement table.json)
2. "prefix" : "mongo_export/Data" (migre tous les objets avec le préfixe mongo_export/Data)
Remarques :
Si vous n'indiquez aucune valeur, tous les objets présents dans le bucket sont migrés.
informations d'identification
Par exemple :
1. "credentials" : "/home/user/.oci/config"
2. "credentials" : "/home/user/security/config"
credentialsProfile
Par exemple :
1. "credentialsProfile" : "DEFAULT"
2. "credentialsProfile" : "ADMIN_USER"
useInstancePrincipal
Exemple : "useInstancePrincipal" : true

Paramètres de configuration uniques

schemaInfo
schemaInfo.schemaObject

schemaInfo

Objectif : indique le schéma des données source en cours de migration. Ce schéma est transmis au récepteur NoSQL.
Type de données : objet
Obligatoire (O/N) : N

schemaInfo.schemaObject

Objectif : indique le nom de l'objet dans le bucket où sont stockées les définitions de schéma de table NoSQL pour les données en cours de migration.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

Exemple :

"schemaInfo": {
  "schemaObject": "mytable/Schema/schema.ddl"
}

Fichier JSON au format DynamoDB stocké dans AWS S3

Le format du fichier de configuration pour le fichier JSON au format DynamoDB dans AWS S3 en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

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.

Voici un exemple de fichier JSON au format DynamoDB :

{"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 devez exporter la table DynamoDB vers le stockage AWS S3 comme indiqué dans Export de données de table DynamoDB vers Amazon S3.

Les types de récepteur valides pour le format DynamoDB JSON stocké dans AWS S3 sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "aws_s3",
  "format" : "dynamodb_json",
  "s3URL" : "<S3 object url>",
  "credentials" : "</path/to/aws/credentials/file>",
  "credentialsProfile" : <"profile name in aws credentials file">
}

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "aws_s3"
format
Utilisez "format" : "dynamodb_json"

Remarques :
Si la valeur du paramètre type est aws_s3, le format doit être dynamodb_json.

Paramètres de configuration uniques

s3URL
informations d'identification
credentialsProfile

s3URL

Objectif : indique l'URL d'une table DynamoDB exportée stockée dans AWS S3. Vous pouvez obtenir cette URL à partir de la console AWS S3. Le format d'URL valide est https://<bucket-name>.<s3_endpoint>/<prefix>. L'NoSQL Database Migrator recherche les fichiers json.gz dans le préfixe lors de l'import.

Remarques :
Vous devez exporter la table DynamoDB comme indiqué dans Export de données de table DynamoDB vers Amazon S3.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple : https://my-bucket.s3.ap-south-1.amazonaws.com/AWSDynamoDB/01649660790057-14f642be

credentials

Objectif : indique le chemin absolu d'un fichier contenant les informations d'identification AWS. S'il n'est pas spécifié, la valeur par défaut est $HOME/.aws/credentials. Pour plus d'informations sur le fichier d'informations d'identification, reportez-vous à Paramètres de fichier de configuration et d'informations d'identification.
Type de données : chaîne
Obligatoire (O/N) : N
Par exemple :
```
"credentials" : "/home/user/.aws/credentials"
"credentials" : "/home/user/security/credentials
```
Remarques :
NoSQL Database Migrator ne consigne aucune information d'identification. Vous devez protéger correctement le fichier d'informations d'identification contre tout accès non autorisé.

credentialsProfile

Objectif : nom du profil dans le fichier d'informations d'identification AWS à utiliser pour la connexion à AWS S3. Les informations d'identification de compte utilisateur sont appelées profil. Si vous n'indiquez pas cette valeur, NoSQL Database Migrator utilise le profil default. Pour plus d'informations sur le fichier d'informations d'identification, reportez-vous à Paramètres de fichier de configuration et d'informations d'identification.
Type de données : chaîne
Obligatoire (O/N) : N

Par exemple :

"credentialsProfile" : "default"
"credentialsProfile" : "test"

Fichier JSON au format DynamoDB

Le format du fichier de configuration pour le fichier JSON au format DynamoDB en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

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.

Voici un exemple de fichier JSON au format DynamoDB :

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

Les types de récepteur valides pour le fichier JSON DynamoDB sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "file",
  "format" : "dynamodb_json",
  "dataPath" : "<path/to/[file|dir]/containing/exported/DDB/tabledata>"   
}

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "file"
format
Utilisez "format" : "dynamodb_json"

Paramètre de configuration unique

dataPath

Objectif : indique le chemin absolu d'un fichier ou d'un répertoire contenant les données de la table DynamoDB exportée. Vous devez copier les données de table DynamoDB exportées d'AWS S3 vers un système de fichiers monté local. Vous devez vous assurer que ces données correspondent au schéma de table NoSQL défini au niveau du récepteur. Si vous spécifiez un répertoire, le NoSQL Database Migrator identifie tous les fichiers avec l'extension .json.gz dans ce répertoire et le sous-répertoire data.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

Par exemple :

Indiquer un fichier

"dataPath" : "/home/user/AWSDynamoDB/01639372501551-bb4dd8c3/data/zclclwucjy6v5mkefvckxzhfvq.json.gz"

Indiquer un répertoire

"dataPath" : "/home/user/AWSDynamoDB/01639372501551-bb4dd8c3"

Oracle NoSQL Database

Le format du fichier de configuration pour Oracle NoSQL Database en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer une table à partir d'Oracle NoSQL Database en indiquant son nom dans le modèle de configuration source.

Voici un exemple de table Oracle NoSQL Database :

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"teacher"}],"age":25,"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],"expenses":null}
{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"chef"}],"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],"expenses":null}
{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"handyman"}],"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],"expenses":null}

Modèle de configuration source

"source" : {
  "type": "nosqldb",
  "storeName" : "<store name>",
  "helperHosts" : ["hostname1:port1","hostname2:port2,..."],
  "table" : "<fully qualified table name>", 
  "includeTTL": <true|false>,    
  "security" : "</path/to/store/security/file>",
  "requestTimeoutMs" : 5000
}

Paramètres de source

Paramètre de configuration commune

type
Utiliser "type" : "nosqldb"

sécurité

Par exemple :

"security" : "/home/user/client.credentials"

Exemple de contenu de fichier de sécurité pour l'authentification basée sur un fichier de mots de passe :

oracle.kv.password.noPrompt=true
oracle.kv.auth.username=admin
oracle.kv.auth.pwdfile.file=/home/nosql/login.passwd
oracle.kv.transport=ssl
oracle.kv.ssl.trustStore=/home/nosql/client.trust
oracle.kv.ssl.protocols=TLSv1.2
oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL)

Exemple de contenu de fichier de sécurité pour l'authentification basée sur un portefeuille :

oracle.kv.password.noPrompt=true
oracle.kv.auth.username=admin
oracle.kv.auth.wallet.dir=/home/nosql/login.wallet
oracle.kv.transport=ssl
oracle.kv.ssl.trustStore=/home/nosql/client.trust
oracle.kv.ssl.protocols=TLSv1.2
oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL)

requestTimeoutMs
Exemple : "requestTimeoutMs" : 5000

Paramètres de configuration uniques

storeName
helperHosts
table
includeTTL

storeName

Objectif : nom de la banque Oracle NoSQL Database.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple : "storeName" : "kvstore"

helperHosts

Objectif : liste des paires d'hôtes et de ports de registre au format hostname:port. Délimitez chaque élément de la liste à l'aide d'une virgule. Vous devez indiquer au moins un hôte helper.
Type de données : tableau de chaînes
Obligatoire (O/N) : Y (Oui)
Exemple : "helperHosts" : ["localhost:5000","localhost:6000"]

table

Objectif : nom de table entièrement qualifié à partir duquel migrer les données.

Format : [namespace_name:]<table_name>

Si la table se trouve dans l'espace de noms DEFAULT, vous pouvez omettre namespace_name. La table doit exister dans le magasin.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple :
- Avec l'espace de noms DEFAULT "table" :"mytable"
- Avec un espace de noms autre que celui par défaut "table" : "mynamespace:mytable"
- Pour indiquer une table enfant "table" : "mytable.child"

includeTTL

Objectif : indique si les métadonnées de durée de vie des lignes de table doivent être incluses lors de l'export des tables Oracle NoSQL Database. Si la valeur est définie sur Vrai, les données de durée de vie des lignes sont également incluses dans les données fournies par la source. La durée de vie est présente dans l'objet JSON _metadata associé à chaque ligne. Le délai d'expiration de chaque ligne est exporté en millisecondes depuis l'époque UNIX (1er janvier 1970).

Si vous ne spécifiez pas ce paramètre, la valeur par défaut est false.
Seules les lignes ayant une valeur d'expiration positive pour la durée de vie sont incluses dans les lignes exportées. Si une ligne n'expire pas, ce qui signifie TTL=0, ses métadonnées TTL ne sont pas explicitement incluses. Par exemple, si ROW1 expire à 2021-10-19 00:00:00 et que ROW2 n'expire pas, les données exportées se présentent comme suit :
```
//ROW1
{
  "id" : 1,
  "name" : "abc",
  "_metadata" : {
    "expiration" : 1634601600000
  }
}

//ROW2
{
  "id" : 2,
  "name" : "xyz"
}
```
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "includeTTL" : true

Oracle NoSQL Database Cloud Service

Le format du fichier de configuration pour Oracle NoSQL Database Cloud Service en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer une table à partir d'Oracle NoSQL Database Cloud Service en indiquant le nom ou l'OCID du compartiment dans lequel la table réside dans le modèle de configuration source.

Voici un exemple de table Oracle NoSQL Database Cloud Service :

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"teacher"}],"age":25,"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],"expenses":null}
{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"chef"}],"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],"expenses":null}
{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"handyman"}],"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],"expenses":null}

Modèle de configuration source

"source" : {
  "type" : "nosqldb_cloud",
  "endpoint" : "<Oracle NoSQL Cloud Service endpoint URL or region ID>",
  "table" : "<table name>",
  "compartment" : "<OCI compartment name or id>",
  "credentials" : "<path/to/oci/credential/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "readUnitsPercent" : <table readunits percent>,
  "includeTTL": <true|false>,
  "requestTimeoutMs" : <timeout in milli seconds>
}

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "nosqldb_cloud"
endpoint
Par exemple :
- ID de région : "endpoint" : "us-ashburn-1"
- Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"
informations d'identification
Par exemple :
1. "credentials" : "/home/user/.oci/config"
2. "credentials" : "/home/user/security/config"
credentialsProfile
Par exemple :
1. "credentialsProfile" : "DEFAULT"
2. "credentialsProfile" : "ADMIN_USER"
useInstancePrincipal
Exemple : "useInstancePrincipal" : true
useDelegationToken
Exemple : "useDelegationToken" : true

Remarques :
L'authentification avec jeton de délégation est prise en charge uniquement lorsque NoSQL Database Migrator est exécuté à partir d'un shell Cloud Shell.
requestTimeoutMs
Exemple : "requestTimeoutMs" : 5000

Paramètres de configuration uniques

table
compartiment
readUnitsPercent
includeTTL

table

Objectif : nom de la table à partir de laquelle migrer les données.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple :
- Pour indiquer une table, procédez comme suit : "table" : "myTable"
- Pour indiquer une table enfant "table" : "mytable.child"

compartiment

Objectif : indique le nom ou l'OCID du compartiment dans lequel réside la table.

Si vous n'indiquez aucune valeur, le compartiment root est utilisé par défaut.

Vous pouvez trouver l'OCID de votre compartiment dans la fenêtre Explorateur de compartiment sous Gouvernance dans la console OCI Cloud.
Type de données : chaîne
Obligatoire (O/N) : O, si la table ne se trouve pas dans le compartiment racine de la location OU lorsque le paramètre useInstancePrincipal est défini sur True.

Remarques :
Si le paramètre useInstancePrincipal est défini sur True, le compartiment doit indiquer l'OCID du compartiment et non le nom.
Exemple :
- Nom de compartiment
  
  "compartment" : "mycompartment"
- Nom du compartiment qualifié avec son compartiment parent
  
  "compartment" : "parent.childcompartment"
- Aucune valeur fournie. La valeur par défaut est le compartiment racine.
  
  "compartment": ""
- OCID du compartiment.
  
  "compartment" : "ocid1.tenancy.oc1...4ksd"

readUnitsPercent

Objectif : pourcentage d'unités de lecture de table à utiliser lors de la migration de la table NoSQL.

La valeur par défaut est 90. La plage valide est tout entier compris entre 1 et 100. La durée nécessaire à la migration des données est directement proportionnelle à cet attribut. Il est préférable d'augmenter le débit de lecture de la table pour l'activité de migration. Vous pouvez réduire le débit de lecture une fois le processus de migration terminé.

Pour en savoir plus sur les limites quotidiennes de débit, reportez-vous à Limites cloud dans le document Oracle NoSQL Database Cloud Service.

Pour savoir comment utiliser cet attribut afin d'améliorer la vitesse de migration des données, reportez-vous à Dépannage d'Oracle NoSQL Database Migrator.
Type de données : entier
Obligatoire (O/N) : N
Exemple : "readUnitsPercent" : 90

includeTTL

Objectif : indique si les métadonnées de durée de vie des lignes de table doivent être incluses lors de l'export des tables Oracle NoSQL Database Cloud Service. Si la valeur est définie sur Vrai, les données de durée de vie des lignes sont également incluses dans les données fournies par la source. La durée de vie est présente dans l'objet JSON _metadata associé à chaque ligne. Le délai d'expiration de chaque ligne est exporté en millisecondes depuis l'époque UNIX (1er janvier 1970).

Si vous ne spécifiez pas ce paramètre, la valeur par défaut est false.
Seules les lignes ayant une valeur d'expiration positive pour la durée de vie sont incluses dans les lignes exportées. Si une ligne n'expire pas, ce qui signifie TTL=0, ses métadonnées TTL ne sont pas explicitement incluses. Par exemple, si ROW1 expire à 2021-10-19 00:00:00 et que ROW2 n'expire pas, les données exportées se présentent comme suit :
```
//ROW1
{
  "id" : 1,
  "name" : "abc",
  "_metadata" : {
    "expiration" : 1634601600000
  }
}

//ROW2
{
  "id" : 2,
  "name" : "xyz"
}
```
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "includeTTL" : true

Source du fichier CSV

Le format du fichier de configuration du fichier CSV en tant que source de NoSQL Database Migrator est indiqué ci-dessous. Le fichier CSV doit être conforme au format RFC4180.

Vous pouvez migrer un fichier CSV ou un répertoire contenant les données CSV en indiquant le nom ou le répertoire du fichier dans le modèle de configuration source.

Voici un exemple de fichier CSV :

1,"Computer Science","San Francisco","2500"
2,"Bio-Technology","Los Angeles","1200"
3,"Journalism","Las Vegas","1500"
4,"Telecommunication","San Francisco","2500"

Modèle de configuration source

"source" : {
  "type" : "file",
  "format" : "csv",
  "dataPath": "</path/to/a/csv/[file|dir]>",
  "hasHeader" : <true | false>,
  "columns" : ["column1", "column2", ....],
  "csvOptions": {
    "encoding": "<character set encoding>",
    "trim": "<true | false>"
 }
}

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "file"
format
Utiliser "format" : "csv"

Paramètres de configuration uniques

dataPath
hasHeader
colonnes
csvOptions
csvOptions.encoding
csvOptions.trim

chemin de données

Objectif : indique le chemin absolu d'un fichier ou d'un répertoire contenant les données CSV à migrer. Si vous indiquez un répertoire, NoSQL Database Migrator importe tous les fichiers portant l'extension .csv ou .CSV dans ce répertoire. Tous les fichiers CSV sont copiés dans une seule table, mais pas dans un ordre particulier.

Les fichiers CSV doivent être conformes à la norme RFC4180. Vous devez vous assurer que les données de chaque fichier CSV correspondent au schéma de table NoSQL Database défini dans la table de récepteur. Les sous- répertoires ne sont pas pris en charge.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple :
- Spécification d'un fichier CSV
  
  "dataPath" : "/home/user/sample.csv"
- Indiquer un répertoire
  
  "dataPath" : "/home/user"

Remarques :

Les fichiers CSV ne doivent contenir que des valeurs scalaires. L'importation de fichiers CSV contenant des types complexes tels que MAP, RECORD, ARRAY et JSON n'est pas prise en charge. L'outil NoSQL Database Migrator ne vérifie pas l'exactitude des données du fichier CSV d'entrée. L'outil NoSQL Database Migrator prend en charge l'importation de données CSV conformes au format RFC4180. Les fichiers CSV contenant des données non conformes à la norme RFC4180 risquent de ne pas être copiés correctement ou d'entraîner une erreur. Si les données d'entrée sont endommagées, l'outil NoSQL Database Migrator n'analyse pas les enregistrements CSV. Si des erreurs sont détectées lors de la migration, l'outil NoSQL Database Migrator consigne les informations relatives aux enregistrements d'entrée en échec à des fins de débogage et d'information. Pour plus de détails, reportez-vous à Progression de la journalisation de l'outil de migration dans Utilisation d'Oracle NoSQL Data Migrator.

hasHeader

Objectif : Indique si le fichier CSV a un en-tête ou non. Si elle est définie sur true, la première ligne est ignorée. Si elle est définie sur false, la première ligne est considérée comme un enregistrement CSV. Valeur par défaut : false.
Type de données : Booléen
Obligatoire (O/N) : N
Exemple : "hasHeader" : "false"

colonnes

Objectif : indique la liste des noms de colonne de table NoSQL Database. L'ordre des noms de colonne indique la mise en correspondance des champs de fichier CSV avec les colonnes de table NoSQL Database correspondantes. Si l'ordre des colonnes du fichier CSV d'entrée ne correspond pas aux colonnes de la table NoSQL Database existantes ou nouvellement créées, vous pouvez mapper l'ordre à l'aide de ce paramètre. En outre, lors de l'import dans une table comportant une colonne d'identité, vous pouvez ignorer le nom de la colonne d'identité dans le paramètre columns.
Remarques :
- Si la table NoSQL Database contient des colonnes supplémentaires qui ne sont pas disponibles dans le fichier CSV, les valeurs des colonnes manquantes sont mises à jour avec la valeur par défaut définie dans la table NoSQL Database. Si aucune valeur par défaut n'est fournie, une valeur NULL est insérée lors de la migration. Pour plus d'informations sur les valeurs par défaut, reportez-vous à la section Définitions de type de données du Guide de référence SQL.
- Si le fichier CSV contient des colonnes supplémentaires qui ne sont pas définies dans la table NoSQL Database, les informations de colonne supplémentaires sont ignorées.
- Si une valeur de l'enregistrement CSV est vide, elle est définie sur la valeur par défaut des colonnes correspondantes dans la table NoSQL Database. Si aucune valeur par défaut n'est fournie, une valeur NULL est insérée lors de la migration.
Type de données : Tableau de chaînes
Obligatoire (O/N) : N
Exemple : "columns" : ["table_column_1", "table_column_2"]

csvOptions

Objectif : Indique les options de formatage d'un fichier CSV. Indiquez le format d'encodage du jeu de caractères du fichier CSV et choisissez de supprimer ou non les espaces.
Type de données : objet
Obligatoire (O/N) : N

csvOptions.encoding

Objectif : Indique le jeu de caractères pour décoder le fichier CSV. La valeur par défaut est UTF-8. Les jeux de caractères pris en charge sont US-ASCII, ISO-8859-1, UTF-8, et UTF-16.
Type de données : chaîne
Obligatoire (O/N) : N
Exemple : "encoding" : "UTF-8"

csvOptions.trim

Objectif : Indique si les espaces de début et de fin d'une valeur de champ CSV doivent être tronqués. La valeur par défaut est false.
Type de données : Booléen
Obligatoire (O/N) : N
Exemple : "trim" : "true"

Fichier CSV dans le bucket OCI Object Storage

Le format du fichier de configuration du fichier CSV dans le bucket OCI Object Storage en tant que source de NoSQL Database Migrator est indiqué ci-dessous. Le fichier CSV doit être conforme au format RFC4180.

Vous pouvez migrer un fichier CSV dans le bucket OCI Object Storage en indiquant le nom du bucket dans le modèle de configuration source.

Voici un exemple de fichier CSV dans le bucket OCI Object Storage :

1,"Computer Science","San Francisco","2500"
2,"Bio-Technology","Los Angeles","1200"
3,"Journalism","Las Vegas","1500"
4,"Telecommunication","San Francisco","2500"

Remarques :

Les types de récepteur valides pour le type de source OCI Object Storage sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "object_storage_oci",
  "format" : "csv",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
   "hasHeader" : <true | false>,
   "columns" : ["column1", "column2", ....],
   "csvOptions" : {         
     "encoding" : "<character set encoding>",
     "trim" : <true | false>
   }
 }

Paramètres de source

Paramètres de configuration communs

type
Utiliser "type" : "object_storage_oci"
format
Utiliser "format" : "csv"
endpoint
Par exemple :
- ID de région : "endpoint" : "us-ashburn-1"
- Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"
espace de noms
Exemple : "namespace" : "my-namespace"
bucket
Exemple : "bucket" : "my-bucket"
Remarques :
- NoSQL Database Migrator importe tous les fichiers avec l'extension .csv ou .CSV au niveau objet et les copie dans une table unique dans le même ordre.
- Les fichiers CSV ne doivent contenir que des valeurs scalaires. L'importation de fichiers CSV contenant des types complexes tels que MAP, RECORD, ARRAY et JSON n'est pas prise en charge. L'outil NoSQL Database Migrator ne vérifie pas l'exactitude des données du fichier CSV d'entrée. L'outil NoSQL Database Migrator prend en charge l'importation de données CSV conformes au format RFC4180. Les fichiers CSV contenant des données non conformes à la norme RFC4180 risquent de ne pas être copiés correctement ou d'entraîner une erreur. Si les données d'entrée sont endommagées, l'outil NoSQL Database Migrator n'analyse pas les enregistrements CSV. Si des erreurs sont détectées lors de la migration, l'outil NoSQL Database Migrator consigne les informations relatives aux enregistrements d'entrée en échec à des fins de débogage et d'information. Pour plus de détails, reportez-vous à Progression de la journalisation de l'outil de migration dans Utilisation d'Oracle NoSQL Data Migrator.
préfixe
Par exemple :
1. "prefix" : "my_table/Data/000000.csv" (migre uniquement 000000.csv)
2. "prefix" : "my_table/Data" (migre tous les objets avec le préfixe my_table/Data)
informations d'identification
Par exemple :
1. "credentials" : "/home/user/.oci/config"
2. "credentials" : "/home/user/security/config"
credentialsProfile
Par exemple :
1. "credentialsProfile" : "DEFAULT"
2. "credentialsProfile" : "ADMIN_USER"
useInstancePrincipal
Exemple : "useInstancePrincipal" : true

Paramètres de configuration uniques

hasHeader
colonnes
csvOptions
csvOptions.encoding
csvOptions.trim

hasHeader

Objectif : Indique si le fichier CSV a un en-tête ou non. Si elle est définie sur true, la première ligne est ignorée. Si elle est définie sur false, la première ligne est considérée comme un enregistrement CSV. Valeur par défaut : false.
Type de données : Booléen
Obligatoire (O/N) : N
Exemple : "hasHeader" : "false"

colonnes

Objectif : indique la liste des noms de colonne de table NoSQL Database. L'ordre des noms de colonne indique la mise en correspondance des champs de fichier CSV avec les colonnes de table NoSQL Database correspondantes. Si l'ordre des colonnes du fichier CSV d'entrée ne correspond pas aux colonnes de la table NoSQL Database existantes ou nouvellement créées, vous pouvez mapper l'ordre à l'aide de ce paramètre. En outre, lors de l'import dans une table comportant une colonne d'identité, vous pouvez ignorer le nom de la colonne d'identité dans le paramètre columns.
Remarques :
- Si la table NoSQL Database contient des colonnes supplémentaires qui ne sont pas disponibles dans le fichier CSV, les valeurs des colonnes manquantes sont mises à jour avec la valeur par défaut définie dans la table NoSQL Database. Si aucune valeur par défaut n'est fournie, une valeur NULL est insérée lors de la migration. Pour plus d'informations sur les valeurs par défaut, reportez-vous à la section Définitions de type de données du Guide de référence SQL.
- Si le fichier CSV contient des colonnes supplémentaires qui ne sont pas définies dans la table NoSQL Database, les informations de colonne supplémentaires sont ignorées.
- Si une valeur de l'enregistrement CSV est vide, elle est définie sur la valeur par défaut des colonnes correspondantes dans la table NoSQL Database. Si aucune valeur par défaut n'est fournie, une valeur NULL est insérée lors de la migration.
Type de données : Tableau de chaînes
Obligatoire (O/N) : N
Exemple : "columns" : ["table_column_1", "table_column_2"]

csvOptions

Objectif : Indique les options de formatage d'un fichier CSV. Indiquez le format d'encodage du jeu de caractères du fichier CSV et choisissez de supprimer ou non les espaces.
Type de données : objet
Obligatoire (O/N) : N

csvOptions.encoding

Objectif : Indique le jeu de caractères pour décoder le fichier CSV. La valeur par défaut est UTF-8. Les jeux de caractères pris en charge sont US-ASCII, ISO-8859-1, UTF-8, et UTF-16.
Type de données : chaîne
Obligatoire (O/N) : N
Exemple : "encoding" : "UTF-8"

csvOptions.trim

Objectif : Indique si les espaces de début et de fin d'une valeur de champ CSV doivent être tronqués. La valeur par défaut est false.
Type de données : Booléen
Obligatoire (O/N) : N
Exemple : "trim" : "true"

Modèles de configuration de récepteur

Découvrez les formats de fichier de configuration de récepteur pour chaque récepteur valide et l'objectif de chaque paramètre de configuration.

Pour le modèle de fichier de configuration, reportez-vous à Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Pour plus d'informations sur les formats source valides pour chaque récepteur, reportez-vous à la section Source Configuration Templates.

Rubriques

Les rubriques suivantes décrivent les modèles de configuration de récepteur référencés par Oracle NoSQL Database Migrator pour copier les données d'une source valide vers le récepteur donné.

Récepteur de fichier JSON
Fichier JSON spécifié.
Fichier Parquet
Fichier Parquet dans le répertoire indiqué.
Fichier JSON dans le bucket OCI Object Storage
Fichier JSON dans le bucket OCI Object Storage indiqué.
Fichier Parquet dans le bucket OCI Object Storage
Fichier Parquet dans le bucket OCI Object Storage indiqué.
Oracle NoSQL Database
Table indiquée dans Oracle NoSQL Database.
Oracle NoSQL Database Cloud Service
Table indiquée dans Oracle NoSQL Database Cloud Service.

Récepteur de fichier JSON

Le format du fichier de configuration du fichier JSON en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration de récepteur

"sink" : {
  "type" : "file",
  "format" : "json",
  "dataPath": "</path/to/a/file>",
  "schemaPath" : "<path/to/a/file>",
  "pretty" : <true|false>,
  "useMultiFiles" : <true|false>,
  "chunkSize" : <size in MB>
}

Paramètres d'évier

Paramètres de configuration communs

type
Utiliser "type" : "file"
format
Utiliser "format" : "json"
chunkSize
Exemple : "chunkSize" : 40

Remarques :
Ce paramètre s'applique UNIQUEMENT lorsque le paramètre useMultiFiles est défini sur True.

Paramètres de configuration uniques

dataPath
schemaPath
jolie
useMultiFiles

dataPath

Objectif : indique le chemin absolu d'un fichier dans lequel les données source seront copiées au format JSON.

Si le fichier n'existe pas dans le chemin de données indiqué, NoSQL Database Migrator le crée. S'il existe, NoSQL Database Migrator écrase son contenu avec les données source.

Vous devez vous assurer que le répertoire parent dans le chemin d'accès aux données est valide pour le fichier spécifié.

Remarques :
Si le paramètre useMultiFiles est défini sur True, indiquez le chemin d'accès à un répertoire, sinon indiquez le chemin d'accès au fichier.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Par exemple :
- Avec le paramètre useMultiFiles défini sur True
  "dataPath" :"/home/user/data"
- Avec le paramètre useMultiFiles non spécifié ou défini sur False
  "dataPath" :"/home/user/sample.json"

schemaPath

Objectif : indique le chemin absolu d'un fichier permettant d'écrire les informations de schéma de table fournies par la source.

Si cette valeur n'est pas définie, les informations du schéma source ne seront pas migrées vers le récepteur. Si cette valeur est indiquée, l'utilitaire de migration écrit le schéma de la table source dans le fichier indiqué ici.

Les informations de schéma sont écrites sous la forme d'une commande LDD par ligne dans ce fichier. Si le fichier n'existe pas dans le chemin de données indiqué, NoSQL Database Migrator le crée. S'il existe déjà, NoSQL Database Migrator écrase son contenu avec les données source. Vous devez vous assurer que le répertoire parent dans le chemin d'accès aux données est valide pour le fichier spécifié.
Type de données : chaîne
Obligatoire (O/N) : N
Exemple : "schemaPath" : "/home/user/schema_file"

jolie

Objectif : indique si la sortie JSON doit être embellie pour améliorer la lisibilité.

S'il n'est pas spécifié, la valeur par défaut est False.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "pretty" : true

useMultiFiles

Objectif : indique si les données de la table NoSQL doivent être fractionnées en plusieurs fichiers lors de la migration des données source vers un fichier.

S'il n'est pas spécifié, la valeur par défaut est False.

Si la valeur est définie sur Vrai, lors de la migration des données source vers un fichier, les données de la table NoSQL sont divisées en plusieurs petits fichiers. Par exemple, <chunk>.json, où chunk=000000, 000001, 000002, etc.
```
dataPath
         |--000000.json
         |--000001.json
```
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "useMultiFiles" : true

Fichier Parquet

Le format du fichier de configuration du fichier Parquet en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration de récepteur

"sink" : {
  "type" : "file",
  "format" : "parquet",
  "dataPath": "</path/to/a/dir>",
  "chunkSize" : <size in MB>,
  "compression": "<SNAPPY|GZIP|NONE>",
  "parquetOptions": {
    "useLogicalJson": <true|false>,
    "useLogicalEnum": <true|false>,
    "useLogicalUUID": <true|false>,     
    "truncateDoubleSpecials": <true|false>
  }
}

Paramètres d'évier

Paramètres de configuration communs

type
Utiliser "type" : "file"
format
Utiliser "format" : "parquet"
chunkSize
Exemple : "chunkSize" : 40

Paramètres de configuration uniques

dataPath
compression
parquetOptions
parquetOptions.useLogicalJson
parquetOptions.useLogicalEnum
parquetOptions.useLogicalUUID
parquetOptions.truncateDoubleSpecials

dataPath

Objectif : indique le chemin d'accès à un répertoire pour le stockage des données de table NoSQL migrées. Assurez-vous que le répertoire existe déjà et dispose de droits d'accès en lecture et en écriture.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple : "dataPath" : "/home/user/migrator/my_table"

compression

Objectif : indique le type de compression à utiliser pour compresser les données Parquet. Les valeurs valides sont SNAPPY, GZIP et NONE.

Si elle n'est pas indiquée, la valeur par défaut est SNAPPY.
Type de données : chaîne
Obligatoire (O/N) : N
Exemple : "compression" : "GZIP"

parquetOptions

Objectif : indique les options permettant de sélectionner des types logiques Parquet pour les colonnes NoSQL ENUM, JSON et UUID.

Si vous n'indiquez pas ce paramètre, l'outil de migration de base de données NoSQL écrit les données des colonnes ENUM, JSON et UUID en tant que chaîne.
Type de données : objet
Obligatoire (O/N) : N

parquetOptions.useLogicalJson

Objectif : indique si les données de colonne JSON NoSQL doivent être écrites en tant que type JSON logique Parquet. Pour plus d'informations, reportez-vous à la section Parquet Logical Type Definitions.

Si elle n'est pas indiquée ou définie sur False, NoSQL Database Migrator écrit les données de colonne JSON NoSQL sous forme de chaîne.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "useLogicalJson" : true

parquetOptions.useLogicalEnum

Objectif : indique si les données de colonne ENUM NoSQL doivent être écrites en tant que type ENUM logique Parquet. Pour plus d'informations, reportez-vous à la section Parquet Logical Type Definitions.

Si elle n'est pas spécifiée ou définie sur False, NoSQL Database Migrator écrit les données de colonne ENUM NoSQL sous forme de chaîne.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "useLogicalEnum" : true

parquetOptions.useLogicalUUID

Objectif : indique si les données de colonne d'UUID NoSQL doivent être écrites en tant que type d'UUID logique Parquet. Pour plus d'informations, reportez-vous à la section Parquet Logical Type Definitions.

Si elle n'est pas spécifiée ou définie sur False, NoSQL Database Migrator écrit les données de colonne d'UUID NoSQL sous forme de chaîne.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "useLogicalUUID" : true

parquetOptions.truncateDoubleSpecials

Objectif : indique si les valeurs doubles +Infinity, -Infinity et NaN doivent être tronquées.
La valeur par défaut est false. Si la valeur est true,
- Positive_Infinity est tronqué en Double.MAX_VALUE.
- NEGATIVE_INFINITY est tronqué en -Double.MAX_VALUE.
- NaN est tronqué en 9.9999999999999990E307.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "truncateDoubleSpecials" : true

Fichier JSON dans le bucket OCI Object Storage

Le format de fichier de configuration du fichier JSON dans le bucket OCI Object Storage en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Remarques :

Les types de source valides pour OCI Object Storage en tant que récepteur sont nosqldb et nosqldb_cloud.

Modèle de configuration de récepteur

"sink" : {
  "type" : "object_storage_oci",
  "format" : "json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "chunkSize" : <size in MB>,
  "pretty" : <true|false>,
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,  
  "useDelegationToken" : <true|false>
}

Paramètres d'évier

Paramètres de configuration communs

type
Utiliser "type" : "object_storage_oci"
format
Utiliser "format" : "json"
endpoint
Par exemple :
- ID de région : "endpoint" : "us-ashburn-1"
- Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"
espace de noms
Exemple : "namespace" : "my-namespace"
bucket
Exemple : "bucket" : "my-bucket"
préfixe
Le schéma est migré vers le fichier <prefix>/Schema/schema.ddl et les données source sont migrées vers les fichiers <prefix>/Data/<chunk>.json, où chunk=000000.json, 000001.json, etc.
Par exemple :
1. "prefix" : "my_export"
2. "prefix" : "my_export/2021-04-05/"
chunkSize
Exemple : "chunkSize" : 40
informations d'identification
Par exemple :
1. "credentials" : "/home/user/.oci/config"
2. "credentials" : "/home/user/security/config"
credentialsProfile
Par exemple :
1. "credentialsProfile" : "DEFAULT"
2. "credentialsProfile" : "ADMIN_USER"
useInstancePrincipal
Exemple : "useInstancePrincipal" : true
useDelegationToken
Exemple : "useDelegationToken" : true

Remarques :
L'authentification avec jeton de délégation est prise en charge uniquement lorsque NoSQL Database Migrator est exécuté à partir d'un shell Cloud Shell.

Paramètre de configuration unique

jolie

Objectif : indique si la sortie JSON doit être embellie pour améliorer la lisibilité.

S'il n'est pas spécifié, la valeur par défaut est False.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "pretty" : true

Fichier Parquet dans le bucket OCI Object Storage

Le format de fichier de configuration du fichier Parquet dans le bucket OCI Object Storage en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Remarques :

Les types de source valides pour le type de source OCI Object Storage sont nosqldb et nosqldb_cloud.

Modèle de configuration de récepteur

"sink" : {
  "type" : "object_storage_oci",
  "format" : "parquet",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "chunkSize" : <size in MB>,
  "compression": "<SNAPPY|GZIP|NONE>",
  "parquetOptions": {
    "useLogicalJson": <true|false>,
    "useLogicalEnum": <true|false>,
    "useLogicalUUID": <true|false>,
    "truncateDoubleSpecials": <true|false>
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>
}

Paramètres d'évier

Paramètres de configuration communs

type
Utiliser "type" : "object_storage_oci"
format
Utiliser "format" : "parquet"
endpoint
Par exemple :
- ID de région : "endpoint" : "us-ashburn-1"
- Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"
espace de noms
Exemple : "namespace" : "my-namespace"
bucket
Exemple : "bucket" : "my-bucket"
préfixe
Les données source sont migrées vers les fichiers <prefix>/Data/<chunk>.parquet, où chunk=000000.parquet, 000001.parquet, etc.
Par exemple :
1. "prefix" : "my_export"
2. "prefix" : "my_export/2021-04-05/"
chunkSize
Exemple : "chunkSize" : 40
informations d'identification
Par exemple :
1. "credentials" : "/home/user/.oci/config"
2. "credentials" : "/home/user/security/config"
credentialsProfile
Par exemple :
1. "credentialsProfile" : "DEFAULT"
2. "credentialsProfile" : "ADMIN_USER"
useInstancePrincipal
Exemple : "useInstancePrincipal" : true
useDelegationToken
Exemple : "useDelegationToken" : true

Remarques :
L'authentification avec jeton de délégation est prise en charge uniquement lorsque NoSQL Database Migrator est exécuté à partir d'un shell Cloud Shell.

Paramètre de configuration unique

compression
parquetOptions
parquetOptions.useLogicalJson
parquetOptions.useLogicalEnum
parquetOptions.useLogicalUUID
parquetOptions.truncateDoubleSpecials

compression

Objectif : indique le type de compression à utiliser pour compresser les données Parquet. Les valeurs valides sont SNAPPY, GZIP et NONE.

Si elle n'est pas indiquée, la valeur par défaut est SNAPPY.
Type de données : chaîne
Obligatoire (O/N) : N
Exemple : "compression" : "GZIP"

parquetOptions

Objectif : indique les options permettant de sélectionner des types logiques Parquet pour les colonnes NoSQL ENUM, JSON et UUID.

Si vous n'indiquez pas ce paramètre, l'outil de migration de base de données NoSQL écrit les données des colonnes ENUM, JSON et UUID en tant que chaîne.
Type de données : objet
Obligatoire (O/N) : N

parquetOptions.useLogicalJson

Objectif : indique si les données de colonne JSON NoSQL doivent être écrites en tant que type JSON logique Parquet. Pour plus d'informations, reportez-vous à la section Parquet Logical Type Definitions.

Si elle n'est pas indiquée ou définie sur False, NoSQL Database Migrator écrit les données de colonne JSON NoSQL sous forme de chaîne.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "useLogicalJson" : true

parquetOptions.useLogicalEnum

Objectif : indique si les données de colonne ENUM NoSQL doivent être écrites en tant que type ENUM logique Parquet. Pour plus d'informations, reportez-vous à la section Parquet Logical Type Definitions.

Si elle n'est pas spécifiée ou définie sur False, NoSQL Database Migrator écrit les données de colonne ENUM NoSQL sous forme de chaîne.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "useLogicalEnum" : true

parquetOptions.useLogicalUUID

Objectif : indique si les données de colonne d'UUID NoSQL doivent être écrites en tant que type d'UUID logique Parquet. Pour plus d'informations, reportez-vous à la section Parquet Logical Type Definitions.

Si elle n'est pas spécifiée ou définie sur False, NoSQL Database Migrator écrit les données de colonne d'UUID NoSQL sous forme de chaîne.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "useLogicalUUID" : true

parquetOptions.truncateDoubleSpecials

Objectif : indique si les valeurs doubles +Infinity, -Infinity et NaN doivent être tronquées.
La valeur par défaut est false. Si la valeur est true,
- Positive_Infinity est tronqué en Double.MAX_VALUE.
- NEGATIVE_INFINITY est tronqué en -Double.MAX_VALUE.
- NaN est tronqué en 9.9999999999999990E307.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "truncateDoubleSpecials" : true

Oracle NoSQL Database

Le format du fichier de configuration pour Oracle NoSQL Database en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration de récepteur

"sink" : {
  "type": "nosqldb",
  "storeName" : "<store name>",
  "helperHosts" : ["hostname1:port1","hostname2:port2,..."],
  "security" : "</path/to/store/credentials/file>",
  "table" : "<fully qualified table name>",
  "includeTTL": <true|false>,
  "ttlRelativeDate": "<date-to-use in UTC>",
  "schemaInfo" : {
    "schemaPath" : "</path/to/a/schema/file>",
    "defaultSchema" : <true|false>,
    "useSourceSchema" : <true|false>,
    "DDBPartitionKey" : <"name:type">,
    "DDBSortKey" : "<name:type>"
  },
  "overwrite" : <true|false>,
  "requestTimeoutMs" : <timeout in milli seconds>
}

Paramètres d'évier

Paramètre de configuration commune

type
Utiliser "type" : "nosqldb"

sécurité

Par exemple :

"security" : "/home/user/client.credentials"

Exemple de contenu de fichier de sécurité pour l'authentification basée sur un fichier de mots de passe :

oracle.kv.password.noPrompt=true
oracle.kv.auth.username=admin
oracle.kv.auth.pwdfile.file=/home/nosql/login.passwd
oracle.kv.transport=ssl
oracle.kv.ssl.trustStore=/home/nosql/client.trust
oracle.kv.ssl.protocols=TLSv1.2
oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL)

Exemple de contenu de fichier de sécurité pour l'authentification basée sur un portefeuille :

oracle.kv.password.noPrompt=true
oracle.kv.auth.username=admin
oracle.kv.auth.wallet.dir=/home/nosql/login.wallet
oracle.kv.transport=ssl
oracle.kv.ssl.trustStore=/home/nosql/client.trust
oracle.kv.ssl.protocols=TLSv1.2
oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL)

requestTimeoutMs
Exemple : "requestTimeoutMs" : 5000

Paramètre de configuration unique

storeName
helperHosts
table
includeTTL
ttlRelativeDate
schemaInfo
schemaInfo.schemaPath
schemaInfo.defaultSchema
schemaInfo.useSourceSchema
schemaInfo.DDBPartitionKey
schemaInfo.DDBSortKey
overwrite

storeName

Objectif : nom de la banque Oracle NoSQL Database.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple : "storeName" : "kvstore"

helperHosts

Objectif : liste des paires d'hôtes et de ports de registre au format hostname:port. Délimitez chaque élément de la liste à l'aide d'une virgule. Vous devez indiquer au moins un hôte helper.
Type de données : tableau de chaînes
Obligatoire (O/N) : Y (Oui)
Exemple : "helperHosts" : ["localhost:5000","localhost:6000"]

table

Objectif : indique le nom de la table pour stocker les données migrées.

Format : [namespace_name:]<table_name>

Si la table se trouve dans l'espace de noms DEFAULT, vous pouvez omettre namespace_name. La table doit exister dans l'emplacement de stockage pendant la migration et son schéma doit correspondre aux données source.

Si la table n'est pas disponible dans le récepteur, vous pouvez utiliser le paramètre schemaInfo pour demander à NoSQL Database Migrator de créer la table dans le récepteur.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple :
- Avec l'espace de noms DEFAULT "table" :"mytable"
- Avec un espace de noms autre que celui par défaut "table" : "mynamespace:mytable"
- Pour indiquer une table enfant "table" : "mytable.child"
  
  Remarques :
  Vous pouvez migrer les tables enfant d'une source de données valide vers Oracle NoSQL Database. NoSQL Database Migrator ne copie qu'une seule table à chaque exécution. Assurez-vous que la table parent est migrée avant la table enfant.

includeTTL

Objectif : indique si les métadonnées de durée de vie des lignes de table fournies par la source doivent être incluses lors de l'import des tables Oracle NoSQL Database.

Si vous ne spécifiez pas ce paramètre, la valeur par défaut est false. Dans ce cas, NoSQL Database Migrator n'inclut pas de métadonnées de durée de vie pour les lignes de table fournies par la source lors de l'import des tables Oracle NoSQL Database.
Si la valeur est True, l'outil NoSQL Database Migrator effectue les vérifications suivantes sur les métadonnées de durée de vie lors de l'import d'une ligne de table :
- Si vous importez une ligne qui n'a pas de définition _metadata, l'outil NoSQL Database Migrator définit la durée de vie sur 0, ce qui signifie que la ligne n'expire jamais.
- Si vous importez une ligne ayant une définition _metadata, l'outil NoSQL Database Migrator compare la valeur de durée de vie à une heure de référence lorsqu'une ligne est importée. Si la ligne a déjà expiré par rapport à l'heure de référence, elle est ignorée. Si la ligne n'a pas expiré, elle est importée avec la valeur de durée de vie. Par défaut, l'heure de référence 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 de migration de base de données NoSQL 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 immédiatement.
  La formule permettant de calculer le délai d'expiration d'une ligne est la suivante :
```
expiration = (TTL value of source row in milliseconds - Reference Time in milliseconds)
if (expiration <= 0) then it indicates that row has expired.
```
  Remarques :
  Etant donné que les limites de durée de vie Oracle NoSQL sont exprimées en heures et en jours, dans certains cas, la durée de vie de la ligne importée peut être ajustée à l'heure ou au jour le plus proche. Par exemple, prenons une ligne dont la valeur d'expiration est 1629709200000 (2021-08-23 09:00:00) et la valeur d'heure de référence est 1629707962582 (2021-08-23 08:39:22). Ici, même si la ligne n'a pas expiré par rapport à l'heure de référence lorsque ces données sont importées, la nouvelle durée de vie de la ligne est 1629712800000 (2021-08-23 10:00:00).
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "includeTTL" : true

ttlRelativeDate

Objectif : indiquez une date UTC au format AAAA-MM-JJ hh:mm:ss utilisée pour définir l'expiration de la durée de vie des lignes de table lors de l'import dans Oracle NoSQL Database.

Si une ligne de table dans les données que vous exportez a expiré, vous pouvez définir le paramètre ttlRelativeDate sur une date antérieure à l'heure d'expiration de la ligne de table dans les données exportées.

Si vous n'indiquez pas ce paramètre, il prend par défaut l'heure en cours en millisecondes, obtenue à partir de System.currentTimeMillis(), de l'ordinateur sur lequel l'outil NoSQL Database Migrator est exécuté.
Type de données : date
Obligatoire (O/N) : N
Exemple : "ttlRelativeDate" : "2021-01-03 04:31:17"
Prenons un scénario dans lequel les lignes de table expirent après sept jours à partir du 1er janvier 2021. Après avoir exporté cette table, le 7 janvier 2021, vous rencontrez un problème avec votre table et décidez d'importer les données. Les lignes de la table vont expirer dans un jour (date d'expiration des données moins la valeur par défaut du paramètre de configuration ttlRelativedate, qui est la date actuelle). Toutefois, si vous souhaitez étendre la date d'expiration des lignes de table à cinq jours au lieu d'un jour, utilisez le paramètre ttlRelativeDate et choisissez une date antérieure. Par conséquent, dans ce scénario, si vous voulez prolonger le délai d'expiration des lignes de table de cinq jours, définissez la valeur des paramètres de configuration ttlRelativeDate sur 3-Jan-2021, qui est utilisé comme heure de référence lorsque les lignes de table sont importées.

schémamainfo

Objectif : indique le schéma des données en cours de migration. Si cela n'est pas spécifié, l'NoSQL Database Migrator suppose que la table existe déjà dans l'emplacement de stockage du récepteur.
Type de données : objet
Obligatoire (O/N) : N

schemaInfo.schemaPath

Objectif : indique le chemin absolu d'un fichier contenant des instructions DDL pour la table NoSQL.

NoSQL Database Migrator exécute les commandes DDL répertoriées dans ce fichier avant de migrer les données.

NoSQL Database Migrator ne prend pas en charge plus d'une instruction DDL par ligne dans le fichier schemaPath.
Type de données : chaîne
Obligatoire (O/N) : N

Remarques :
defaultSchema et schemaPath s'excluent mutuellement.
Exemple : "schemaPath" : "/home/user/schema_file"

schemaInfo.defaultSchema

Objectif : la définition de ce paramètre sur true indique à NoSQL Database Migrator de créer une table avec le schéma par défaut. Le schéma par défaut est défini par le migrateur lui-même. Pour plus d'informations sur les définitions de schéma par défaut, reportez-vous à Schéma par défaut dans Utilisation d'Oracle NoSQL Data Migrator.
Type de données : booléen
Obligatoire (O/N) : N

Remarques :
defaultSchema et schemaPath s'excluent mutuellement.

schemaInfo.useSourceSchema

Objectif : indique si le récepteur utilise ou non la définition de schéma de table fournie par la source lors de la migration des tables NoSQL.
Type de données : booléen
Obligatoire (O/N) : N

Remarques :
Les paramètres defaultSchema, schemaPath et useSourceSchema s'excluent mutuellement. Ne spécifiez qu'un de ces paramètres.

Exemple :

Avec le schéma par défaut :

"schemaInfo" : {
  "defaultSchema" : true
}

Avec un schéma prédéfini :

"schemaInfo" : {
 "schemaPath" : "<complete/path/to/the/schema/definition/file>"
}

Avec le schéma source :

"schemaInfo" : {
  "useSourceSchema" : true
}

schemaInfo.DDBPartitionKey

Objectif : indique la clé de partition DynamoDB et le type Oracle NoSQL Database correspondant à utiliser dans la table Oracle NoSQL Database de récepteur. Cette clé sera utilisée en tant que clé de shard de table de base de données NoSQL. Cette option est applicable uniquement lorsque defaultSchema est défini sur True et que le format source est dynamodb_json. Pour plus d'informations, reportez-vous à Mise en correspondance des types DynamoDB avec les types Oracle NoSQL.
Obligatoire (O/N) : O, si defaultSchema est vrai et que la source est dynamodb_json.
Exemple : "DDBPartitionKey" : "PersonID:INTEGER"

Remarques :
Si la clé de partition contient un tiret (-) ou un point (.), Migrator la remplacera par un trait de soulignement (_) car le nom de colonne NoSQL ne prend pas en charge les points et les tirets.

schemaInfo.DDBSortKey

Objectif : indique la clé de tri DynamoDB et le type Oracle NoSQL Database correspondant à utiliser dans la table Oracle NoSQL Database cible. Si la table DynamoDB d'import ne comporte pas de clé de tri, cet attribut ne doit pas être défini. Cette clé sera utilisée en tant que partie non partagée de la clé primaire dans la table de base de données NoSQL. Cette option est applicable uniquement lorsque defaultSchema est défini sur True et que la source est dynamodb_json. Pour plus d'informations, reportez-vous à Mise en correspondance des types DynamoDB avec les types Oracle NoSQL.
Obligatoire (O/N) : N
Exemple : "DDBSortKey" : "Skey:STRING"

Remarques :
Si la clé de tri contient un tiret (-) ou un point (.), Migrator la remplacera par un trait de soulignement (_) car le nom de colonne NoSQL ne prend pas en charge les points et les tirets.

overwrite

Objectif : indique le comportement de NoSQL Database Migrator lorsque l'enregistrement en cours de migration à partir de la source est déjà présent dans le récepteur.

Si la valeur est définie sur False, lors de la migration des tables, NoSQL Database Migrator ignore les enregistrements pour lesquels la même clé primaire existe déjà dans le récepteur.

Si la valeur est définie sur Vrai, lors de la migration des tables, NoSQL Database Migrator écrase les enregistrements pour lesquels la même clé primaire existe déjà dans le récepteur.

Si elle n'est pas indiquée, la valeur par défaut est True.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "overwrite" : false

Oracle NoSQL Database Cloud Service

Le format du fichier de configuration pour Oracle NoSQL Database Cloud Service en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration de récepteur

"sink" : {
  "type" : "nosqldb_cloud",
  "endpoint" : "<Oracle NoSQL Cloud Service Endpoint>",
  "table" : "<table name>",
  "compartment" : "<OCI compartment name or id>",
  "includeTTL": <true|false>,
  "ttlRelativeDate" : "<date-to-use in UTC>",  
  "schemaInfo" : {
    "schemaPath" : "</path/to/a/schema/file>",
    "defaultSchema" : <true|false>,
    "useSourceSchema" : <true|false>,
    "DDBPartitionKey" : <"name:type">,
    "DDBSortKey" : "<name:type>",
    "onDemandThroughput" : <true|false>,
    "readUnits" : <table read units>,
    "writeUnits" : <table write units>,
    "storageSize" : <storage size in GB>
   },
  "credentials" : "</path/to/oci/credential/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "writeUnitsPercent" : <table writeunits percent>,
  "requestTimeoutMs" : <timeout in milli seconds>,
  "overwrite" : <true|false>
}

Paramètres d'évier

Paramètres de configuration communs

type
Utiliser "type" : "nosqldb_cloud"
endpoint
Par exemple :
- ID de région : "endpoint" : "us-ashburn-1"
- Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"
informations d'identification
Par exemple :
1. "credentials" : "/home/user/.oci/config"
2. "credentials" : "/home/user/security/config"
credentialsProfile
Par exemple :
1. "credentialsProfile" : "DEFAULT"
2. "credentialsProfile" : "ADMIN_USER"
useInstancePrincipal
Exemple : "useInstancePrincipal" : true
useDelegationToken
Exemple : "useDelegationToken" : true

Remarques :
L'authentification avec jeton de délégation est prise en charge uniquement lorsque NoSQL Database Migrator est exécuté à partir d'un shell Cloud Shell.
requestTimeoutMs
Exemple : "requestTimeoutMs" : 5000

Paramètre de configuration unique

table
compartiment
includeTTL
ttlRelativeDate
schemaInfo
schemaInfo.schemaPath
schemaInfo.defaultSchema
schemaInfo.useSourceSchema
schemaInfo.DDBPartitionKey
schemaInfo.DDBSortKey
schemaInfo.onDemandThroughput
schemaInfo.readUnits
schemaInfo.writeUnits
schemaInfo.storageSize
writeUnitsPercent
overwrite

table

Objectif : indique le nom de la table de stockage des données migrées.

Vous devez vous assurer que cette table existe dans Oracle NoSQL Database Cloud Service. Sinon, vous devez utiliser l'objet schemaInfo dans la configuration de récepteur pour demander à NoSQL Database Migrator de créer la table.

Le schéma de cette table doit correspondre aux données source.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)
Exemple :
- Pour indiquer une table, procédez comme suit : "table" : "mytable"
- Pour indiquer une table enfant "table" : "mytable.child"
  
  Remarques :
  Vous pouvez migrer les tables enfant d'une source de données valide vers Oracle NoSQL Database Cloud Service. NoSQL Database Migrator ne copie qu'une seule table à chaque exécution. Assurez-vous que la table parent est migrée avant la table enfant.

compartiment

Objectif : indique le nom ou l'OCID du compartiment dans lequel réside la table.

Si vous n'indiquez aucune valeur, le compartiment root est utilisé par défaut.

Vous pouvez trouver l'OCID de votre compartiment dans la fenêtre Explorateur de compartiment sous Gouvernance dans la console OCI Cloud.
Type de données : chaîne
Obligatoire (O/N) : O, si la table ne se trouve pas dans le compartiment racine de la location OU lorsque le paramètre useInstancePrincipal est défini sur True.

Remarques :
Si le paramètre useInstancePrincipal est défini sur True, le compartiment doit indiquer l'OCID du compartiment et non le nom.
Exemple :
- Nom de compartiment
  
  "compartment" : "mycompartment"
- Nom du compartiment qualifié avec son compartiment parent
  
  "compartment" : "parent.childcompartment"
- Aucune valeur fournie. La valeur par défaut est le compartiment racine.
  
  "compartment": ""
- OCID du compartiment.
  
  "compartment" : "ocid1.tenancy.oc1...4ksd"

includeTTL

Objectif : indique si les métadonnées de durée de vie des lignes de table fournies par la source doivent être incluses lors de l'import des tables Oracle NoSQL Database.

Si vous ne spécifiez pas ce paramètre, la valeur par défaut est false. Dans ce cas, NoSQL Database Migrator n'inclut pas de métadonnées de durée de vie pour les lignes de table fournies par la source lors de l'import des tables Oracle NoSQL Database.
Si la valeur est True, l'outil NoSQL Database Migrator effectue les vérifications suivantes sur les métadonnées de durée de vie lors de l'import d'une ligne de table :
- Si vous importez une ligne qui n'a pas de définition _metadata, l'outil NoSQL Database Migrator définit la durée de vie sur 0, ce qui signifie que la ligne n'expire jamais.
- Si vous importez une ligne ayant une définition _metadata, l'outil NoSQL Database Migrator compare la valeur de durée de vie à une heure de référence lorsqu'une ligne est importée. Si la ligne a déjà expiré par rapport à l'heure de référence, elle est ignorée. Si la ligne n'a pas expiré, elle est importée avec la valeur de durée de vie. Par défaut, l'heure de référence 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 de migration de base de données NoSQL 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 immédiatement.
  La formule permettant de calculer le délai d'expiration d'une ligne est la suivante :
```
expiration = (TTL value of source row in milliseconds - Reference Time in milliseconds)
if (expiration <= 0) then it indicates that row has expired.
```
  Remarques :
  Etant donné que les limites de durée de vie Oracle NoSQL sont exprimées en heures et en jours, dans certains cas, la durée de vie de la ligne importée peut être ajustée à l'heure ou au jour le plus proche. Par exemple, prenons une ligne dont la valeur d'expiration est 1629709200000 (2021-08-23 09:00:00) et la valeur d'heure de référence est 1629707962582 (2021-08-23 08:39:22). Ici, même si la ligne n'a pas expiré par rapport à l'heure de référence lorsque ces données sont importées, la nouvelle durée de vie de la ligne est 1629712800000 (2021-08-23 10:00:00).
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "includeTTL" : true

ttlRelativeDate

Objectif : indiquez une date UTC au format AAAA-MM-JJ hh:mm:ss utilisée pour définir l'expiration de la durée de vie des lignes de table lors de l'import dans Oracle NoSQL Database.

Si une ligne de table dans les données que vous exportez a expiré, vous pouvez définir le paramètre ttlRelativeDate sur une date antérieure à l'heure d'expiration de la ligne de table dans les données exportées.

Si vous n'indiquez pas ce paramètre, il prend par défaut l'heure en cours en millisecondes, obtenue à partir de System.currentTimeMillis(), de l'ordinateur sur lequel l'outil NoSQL Database Migrator est exécuté.
Type de données : date
Obligatoire (O/N) : N
Exemple : "ttlRelativeDate" : "2021-01-03 04:31:17"
Prenons un scénario dans lequel les lignes de table expirent après sept jours à partir du 1er janvier 2021. Après avoir exporté cette table, le 7 janvier 2021, vous rencontrez un problème avec votre table et décidez d'importer les données. Les lignes de la table vont expirer dans un jour (date d'expiration des données moins la valeur par défaut du paramètre de configuration ttlRelativedate, qui est la date actuelle). Toutefois, si vous souhaitez étendre la date d'expiration des lignes de table à cinq jours au lieu d'un jour, utilisez le paramètre ttlRelativeDate et choisissez une date antérieure. Par conséquent, dans ce scénario, si vous voulez prolonger le délai d'expiration des lignes de table de cinq jours, définissez la valeur des paramètres de configuration ttlRelativeDate sur 3-Jan-2021, qui est utilisé comme heure de référence lorsque les lignes de table sont importées.

schemaInfo

Objectif : indique le schéma des données en cours de migration.

Si vous n'indiquez pas ce paramètre, NoSQL Database Migrator suppose que la table existe déjà dans Oracle NoSQL Database Cloud Service.

Si ce paramètre n'est pas spécifié et que la table n'existe pas dans le récepteur, la migration échoue.
Type de données : objet
Obligatoire (O/N) : N

schemaInfo.schemaPath

Objectif : indique le chemin absolu d'un fichier contenant des instructions DDL pour la table NoSQL.

NoSQL Database Migrator exécute les commandes DDL répertoriées dans ce fichier avant de migrer les données.

NoSQL Database Migrator ne prend pas en charge plus d'une instruction DDL par ligne dans le fichier schemaPath.
Type de données : chaîne
Obligatoire (O/N) : N

Remarques :
defaultSchema et schemaPath s'excluent mutuellement.
Exemple : "schemaPath" : "/home/user/schema_file"

schemaInfo.defaultSchema

Objectif : la définition de ce paramètre sur Oui indique à NoSQL Database Migrator de créer une table avec le schéma par défaut. Le schéma par défaut est défini par le migrateur lui-même. Pour plus d'informations sur les définitions de schéma par défaut, reportez-vous à Schéma par défaut dans Utilisation d'Oracle NoSQL Data Migrator.
Type de données : booléen
Obligatoire (O/N) : N

Remarques :
defaultSchema et schemaPath s'excluent mutuellement.

schemaInfo.useSourceSchema

Objectif : indique si le récepteur utilise ou non la définition de schéma de table fournie par la source lors de la migration des tables NoSQL.
Type de données : booléen
Obligatoire (O/N) : N

Remarques :
Les paramètres defaultSchema, schemaPath et useSourceSchema s'excluent mutuellement. Ne spécifiez qu'un de ces paramètres.

Exemple :

Avec le schéma par défaut :

"schemaInfo": {
  "defaultSchema": true,
  "readUnits": 100,
  "writeUnits": 60,
  "storageSize": 1
}

Avec un schéma prédéfini :

"schemaInfo": {
  "schemaPath": "<complete/path/to/the/schema/definition/file>",
  "readUnits": 100,
  "writeUnits": 100,
  "storageSize": 1
}

Avec le schéma source :

"schemaInfo": {
  "useSourceSchema": true,
  "readUnits": 100,
  "writeUnits": 60,
  "storageSize": 1
}

schemaInfo.DDBPartitionKey

Objectif : indique la clé de partition DynamoDB et le type Oracle NoSQL Database correspondant à utiliser dans la table Oracle NoSQL Database de récepteur. Cette clé sera utilisée en tant que clé de shard de table de base de données NoSQL. Cette option est applicable uniquement lorsque defaultSchema est défini sur True et que le format source est dynamodb_json. Pour plus d'informations, reportez-vous à Mise en correspondance des types DynamoDB avec les types Oracle NoSQL.
Obligatoire (O/N) : O, si defaultSchema est vrai et que la source est dynamodb_json.
Exemple : "DDBPartitionKey" : "PersonID:INTEGER"

Remarques :
Si la clé de partition contient un tiret (-) ou un point (.), Migrator la remplacera par un trait de soulignement (_) car le nom de colonne NoSQL ne prend pas en charge les points et les tirets.

schemaInfo.DDBSortKey

Objectif : indique la clé de tri DynamoDB et le type Oracle NoSQL Database correspondant à utiliser dans la table Oracle NoSQL Database cible. Si la table DynamoDB d'import ne comporte pas de clé de tri, cet attribut ne doit pas être défini. Cette clé sera utilisée en tant que partie non partagée de la clé primaire dans la table de base de données NoSQL. Cette option est applicable uniquement lorsque defaultSchema est défini sur True et que la source est dynamodb_json. Pour plus d'informations, reportez-vous à Mise en correspondance des types DynamoDB avec les types Oracle NoSQL.
Obligatoire (O/N) : N
Exemple : "DDBSortKey" : "Skey:STRING"

Remarques :
Si la clé de tri contient un tiret (-) ou un point (.), Migrator la remplacera par un trait de soulignement (_) car le nom de colonne NoSQL ne prend pas en charge les points et les tirets.

schemaInfo.onDemandThroughput

Objectif : permet de créer la table avec un débit de lecture et d'écriture à la demande. Si ce paramètre n'est pas défini, la table est créée avec une capacité provisionnée.
La valeur par défaut est false.

Remarques :
Ce paramètre n'est pas applicable aux tables enfant car elles partagent le débit de la table parent de niveau supérieur.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "onDemandThroughput" : "true"

schemaInfo.readUnits

Objectif : indique le débit de lecture de la nouvelle table.
Remarques :
- Ce paramètre ne s'applique pas aux tables provisionnées avec une capacité à la demande.
- Ce paramètre n'est pas applicable aux tables enfant car elles partagent le débit de lecture de la table parent de niveau supérieur.
Type de données : entier
Obligatoire (O/N) : O, si la table n'est pas une table enfant ou si le paramètre schemaInfo.onDemandThroughput est défini sur false, sinon N.
Exemple : "readUnits" : 100

schemaInfo.writeUnits

Objectif : indique le débit d'écriture de la nouvelle table.
Remarques :
- Ce paramètre ne s'applique pas aux tables provisionnées avec une capacité à la demande.
- Ce paramètre n'est pas applicable aux tables enfant car elles partagent le débit d'écriture de la table parent de niveau supérieur.
Type de données : entier
Obligatoire (O/N) : O, si la table n'est pas une table enfant ou si le paramètre schemaInfo.onDemandThroughput est défini sur false, sinon N.
Exemple : "writeUnits" : 100

schemaInfo.storageSize

Objectif : indique la taille de stockage de la nouvelle table en Go.

Remarques :
Ce paramètre n'est pas applicable aux tables enfant car elles partagent la taille de stockage de la table parent de niveau supérieur.
Type de données : entier
Obligatoire (O/N) : O, si la table n'est pas une table enfant, sinon N.

Par exemple :

Avec schemaPath

"schemaInfo" : { 
  "schemaPath" : "</path/to/a/schema/file>",
  "readUnits" : 500,
  "writeUnits" : 1000,
  "storageSize" : 5 }

Avec defaultSchema

"schemaInfo" : {
  "defaultSchema" :Yes,
  "readUnits" : 500,   
  "writeUnits" : 1000,   
  "storageSize" : 5  
}

writeUnitsPercent

Objectif : indique le pourcentage d'unités d'écriture de table à utiliser pendant l'activité de migration. La durée nécessaire à la migration des données est directement proportionnelle à cet attribut.

La valeur par défaut est 90. La plage valide est tout entier compris entre 1 et 100.

Pour savoir comment utiliser cet attribut afin d'améliorer la vitesse de migration des données, reportez-vous à Dépannage d'Oracle NoSQL Database Migrator.
Type de données : entier
Obligatoire (O/N) : N
Exemple : "writeUnitsPercent" : 90

overwrite

Objectif : indique le comportement de NoSQL Database Migrator lorsque l'enregistrement en cours de migration à partir de la source est déjà présent dans le récepteur.

Si la valeur est définie sur False, lors de la migration des tables, NoSQL Database Migrator ignore les enregistrements pour lesquels la même clé primaire existe déjà dans le récepteur.

Si la valeur est définie sur Vrai, lors de la migration des tables, NoSQL Database Migrator écrase les enregistrements pour lesquels la même clé primaire existe déjà dans le récepteur.

Si elle n'est pas indiquée, la valeur par défaut est True.
Type de données : booléen
Obligatoire (O/N) : N
Exemple : "overwrite" : false

Modèles de configuration de transformation

Cette rubrique explique les paramètres de configuration des différentes transformations prises en charge par Oracle NoSQL Database Migrator. Pour obtenir le modèle de fichier de configuration complet, reportez-vous à Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Oracle NoSQL Database Migrator vous permet de modifier les données, c'est-à-dire d'ajouter des transformations de données dans le cadre de l'activité de migration. Vous pouvez définir plusieurs transformations dans une même migration. Dans un tel cas, l'ordre des transformations est vital car les données source subissent chaque transformation dans l'ordre donné. La sortie d'une transformation devient l'entrée de la transformation suivante dans le pipeline de migration.

Les différentes transformations prises en charge par NoSQL Data Migrator sont les suivantes :

Transformations de table

Attribut de configuration de transformation	Vous pouvez utiliser cette transformation pour :
`ignoreFields`	Ignorez les colonnes identifiées de la ligne source avant d'écrire dans le récepteur.
`includeFields`	Incluez les colonnes identifiées de la ligne source avant d'écrire dans le récepteur.
`renameFields`	Renommez les colonnes identifiées à partir de la ligne source avant d'écrire dans le récepteur.
`aggregateFields`	Agrégez plusieurs colonnes de la source en une seule colonne dans le récepteur. Dans le cadre de cette transformation, vous pouvez également identifier les colonnes à exclure de l'agrégation. Ces champs seront ignorés de la colonne agrégée.

Vous trouverez ci-dessous le modèle de configuration de chaque transformation prise en charge.

ignoreFields

Le format du fichier de configuration pour la transformation ignoreFields est illustré ci-dessous.

Modèle de configuration de la transformation

"transforms" : {
  "ignoreFields" : ["<field1>","<field2>",...]
}

Paramètre de transformation

ignoreFields

Objectif : tableau des noms de colonne à ignorer dans les enregistrements source.

Remarques :
Vous ne pouvez fournir que des champs de niveau supérieur. Les transformations ne peuvent pas être appliquées aux données des champs imbriqués.
Type de données : tableau de chaînes
Obligatoire (O/N) : Y (Oui)
Exemple : pour ignorer les colonnes nommées "name" et "address" de l'enregistrement source :

"ignoreFields" : ["name","address"]

includeFields

Le format du fichier de configuration pour la transformation includeFields est illustré ci-dessous.

Modèle de configuration de la transformation

"transforms" : {
  "includeFields" : ["<field1>","<field2>",...]
}

Paramètre de transformation

includeFields

Objectif : tableau des noms de colonne à inclure dans les enregistrements source. Il inclut uniquement les champs spécifiés dans le tableau, les autres champs sont ignorés.

Remarques :
L'outil NoSQL Database Migrator génère une erreur si vous indiquez un tableau vide. En outre, vous ne pouvez spécifier que les champs de niveau supérieur. L'outil NoSQL Database Migrator n'applique aucune transformation aux données des champs imbriqués.
Type de données : tableau de chaînes
Obligatoire (O/N) : Y (Oui)
Exemple : Pour ignorer les colonnes nommées "age" et "gender" de l'enregistrement source :

"includeFields" : ["age","gender"]

renameFields

Le format du fichier de configuration pour la transformation renameFields est illustré ci-dessous.

Modèle de configuration de la transformation

"transforms" : {
  "renameFields" : {
    "<old_name>" : "<new_name>",
    "<old_name>" : "<new_name>,"
    .....
  }
}

Paramètre de transformation

renameFields

Objet : Paires clé-valeur de l'ancien et du nouveau nom des colonnes à renommer.

Remarques :
Vous ne pouvez fournir que des champs de niveau supérieur. Les transformations ne peuvent pas être appliquées aux données des champs imbriqués.
Type de données : objet JSON
Obligatoire (O/N) : Y (Oui)
Exemple : pour renommer la colonne nommée "residence" en "address" et la colonne nommée "_id" en "id" :

"renameFields" : { "residence" : "address", "_id" : "id" }

aggregateFields

Le format du fichier de configuration pour la transformation aggregateFields est illustré ci-dessous.

Modèle de configuration de la transformation

"transforms" : {
  "aggregateFields" : {
    "fieldName" : "name of the new aggregate field",
    "skipFields" : ["<field1>","<field2">,...]
  }
}

Paramètre de transformation

aggregateFields

Objectif : nom du champ agrégé dans le récepteur.
Type de données : chaîne
Obligatoire (O/N) : Y (Oui)

Exemple : Si l'enregistrement donné est :

{
  "id" : 100,
  "name" : "john",
  "address" : "USA",
  "age" : 20
}

Si la transformation d'agrégation est :

"aggregateFields" : {
  "fieldName" : "document",
  "skipFields" : ["id"]
}

La colonne agrégée du récepteur se présente comme suit :

{
  "id": 100,
  "document": {
    "name": "john",
    "address": "USA",
    "age": 20
  }
}

Mise en correspondance des types DynamoDB avec les types Oracle NoSQL

Le tableau ci-dessous présente la mise en correspondance des types DynamoDB avec les types Oracle NoSQL.

Tableau - Mise en correspondance du type DynamoDB avec le type Oracle NoSQL

#	Type DynamoDB	Type de JSON pour la colonne JSON NoSQL	Type NoSQL Oracle
1	Chaîne (S)	Chaîne JSON	STRING
2	Type numérique (N)	Nombre JSON	ENTIER/LONG/FLOTTANT/DOUBLE/NOMBRE
3	Booléen (BOOL)	Booléen JSON	BOOLEAN
4	Type binaire (B) - Tampon d'octets	Chaîne JSON encodée BASE-64	BINARY
5	NULL	JSON NULL	NULL
6	Jeu de chaînes (SS)	Tableau de chaînes JSON	TABLEAU (CHAÎNE)
7	Jeu de nombres (NS)	Tableau de nombres JSON	TABLEAU (ENTIER/LONG/FLOTTANT/DOUBLE/NOMBRE)
8	Ensemble binaire (BS)	Tableau JSON de chaînes encodées en base 64	TABLEAU (BINAIRE)
9	LISTE (L)	Tableau de JSON	TABLEAU (JSON)
10	CARTE (M)	Objet JSON	JSON
11	CLÉ DE SÉPARATION	S/O	KEY PRIMARY et KEY SHARD
12	CLÉ DE TRI	S/O	CLÉ PRIMAIRE
13	Noms d'attribut avec tiret et point	Noms de champ JSON avec un trait de soulignement	Noms de colonne avec trait de soulignement

Quelques points supplémentaires à prendre en compte lors de la mise en correspondance des types DynamoDB avec les types Oracle NoSQL :

DynamoDB Prend en charge un seul type de données pour les nombres et peut comporter jusqu'à 38 chiffres de précision. En revanche, Oracle NoSQL prend en charge de nombreux types parmi lesquels choisir en fonction de la plage et la précision de data.You peut sélectionner le type de nombre approprié qui correspond à la plage de vos données d'entrée. Si vous n'êtes pas sûr de la nature des données, vous pouvez utiliser le type NoSQL NUMBER.
DynamoDB Prend en charge un seul type de données pour les nombres et peut comporter jusqu'à 38 chiffres de précision. En revanche, Oracle NoSQL prend en charge de nombreux types parmi lesquels choisir en fonction de la plage et la précision de data.You peut sélectionner le type de nombre approprié qui correspond à la plage de vos données d'entrée. Si vous n'êtes pas sûr de la nature des données, vous pouvez utiliser le type NoSQL NUMBER.
La clé de partitionnement dans DynamoDB est limitée à 2048 octets, mais Oracle NoSQL Cloud Service est limité à 64 octets pour la clé primaire/la clé de shard.
La clé de tri dans DynamoDB est limitée à 1024 octets, mais Oracle NoSQL Cloud Service est limité à 64 octets pour la clé primaire.
Les noms d'attribut dans DynamoDB peuvent avoir une longueur de 64 ko, mais les noms de colonne de service Oracle NoSQL Cloud ont une limite de 64 caractères.

Mise en correspondance de types de données Oracle NoSQL avec des types de données Parquet

décrit la mise en correspondance des types de données Oracle NoSQL avec les types de données Parquet.

Type NoSQL	Type Parquet
BOOLEAN	BOOLEAN
INTEGER	INT32
LONG	INT64
FLOAT	DOUBLE
DOUBLE	DOUBLE
BINARY	BINARY
FIXED_BINARY	BINARY
STRING	BINAIRE (CHAÎNE)
ENUM	BINAIRE (CHAÎNE) ou BINARY(ENUM), si l'ENUM logique est configuré
UUID	BINAIRE (CHAÎNE) ou FIXED_BINARY(16), si l'UUID logique est configuré
TIMESTAMP (p)	INT64(TIMESTAMP(p))
NUMBER	DOUBLE
field_name TABLEAU (T)	`group field_name(LIST) { repeated group list { required T element } }`
field_name CARTE(T)	`group field_name (MAP) { repeated group key_value (MAP_KEY_VALUE) { required binary key (STRING); required T value; } }`
field_name RECORD(K₁ T₁ N₁, Kٖ₂ T₂ N₂, ....) où : K = Nom de clé T = Type N = Nullable ou non	`group field_name { ni == true ? optional Ti ki : required Ti ki }`
JSON	BINAIRE (CHAÎNE) ou BINARY(JSON), si le JSON logique est configuré

Remarques :

Lorsque le type de nombre NoSQL est converti en type Parquet double, il peut y avoir une perte de précision dans le cas où la valeur ne peut pas être représentée en double. Si le nombre est trop grand pour représenter Double, il est converti en Double.NEGATIVE_INFINITY ou Double.POSITIVE_INFINITY.

Mise en correspondance de la table DynamoDB avec la table Oracle NoSQL

Dans DynamoDB, une table est un ensemble d'éléments et chaque élément est un ensemble d'attributs. Chaque élément de la table possède un identificateur unique ou une clé primaire. En dehors de la clé primaire, la table est sans schéma. Chaque article peut avoir ses propres attributs distincts.

DynamoDB prend en charge deux types de clé primaire différents :

Partition key : clé primaire simple, composée d'un attribut appelé partition key. DynamoDB utilise la valeur de la clé de partitionnement comme entrée d'une fonction de hachage interne. La sortie de la fonction de hachage détermine la partition dans laquelle l'élément sera stocké.
Clé de partition et clé de tri : en tant que clé primaire composite, ce type de clé est composé de deux attributs. Le premier attribut est la clé de partition et le second attribut est la clé de tri. DynamoDB utilise la valeur de clé de partitionnement comme entrée pour une fonction de hachage interne. La sortie de la fonction de hachage détermine la partition dans laquelle l'élément sera stocké. Tous les éléments ayant la même valeur de clé de partition sont stockés ensemble, triés par valeur de clé de tri.

En revanche, les tables NoSQL Oracle prennent en charge des modèles de données flexibles avec une conception sans schéma et sans schéma.

Il existe deux façons différentes de modéliser une table DynamoDB :

Modélisation de la table DynamoDB en tant que document JSON (recommandé) : dans cette modélisation, vous mettez en correspondance tous les attributs des tables de base de données Dynamo avec une colonne JSON de la table NoSQL, à l'exception de la clé de partitionnement et de la clé de tri. Vous modéliserez la clé de partitionnement et la clé de tri en tant que colonnes de clé primaire de la table NoSQL. Vous utiliserez AggregateFields transform afin d'agréger les données de clé secondaire dans une colonne JSON.

Remarques :
Le programme de migration fournit une configuration conviviale defaultSchema permettant de créer automatiquement une table DDL sans schéma qui agrège également les attributs dans une colonne JSON.
Modélisation de la table DynamoDB en tant que colonnes fixes dans la table NoSQL : dans cette modélisation, pour chaque attribut de la table DynamoDB, vous allez créer une colonne dans la table NoSQL comme indiqué dans la mise en correspondance des types DynamoDB avec les types Oracle NoSQL. Vous modéliserez les attributs de clé de partitionnement et de clé de tri en tant que clés primaires. Cette option ne doit être utilisée que lorsque vous êtes certain que l'import du schéma de table DynamoDB est fixe et que chaque élément possède des valeurs pour la plupart des attributs. Si les éléments DynamoDB n'ont pas d'attributs communs, cela peut entraîner la création d'un lot de colonnes NoSQL avec des valeurs vides.

Remarques :
Nous recommandons fortement l'utilisation de tables sans schéma lors de la migration de données de DynamoDB vers Oracle NoSQL Database en raison de la nature des tables DynamoDB sans schéma. C'est particulièrement le cas pour les tables volumineuses où le contenu de chaque enregistrement peut ne pas être uniforme dans la table.

Dépannage d'Oracle NoSQL Database Migrator

Découvrez les défis généraux que vous pouvez rencontrer lors de l'utilisation du , et comment les résoudre.

La migration a échoué. Comment résoudre ce problème ?

Un échec de la migration des données peut être dû à plusieurs raisons sous-jacentes. Les causes importantes sont énumérées ci-dessous :

Table - Causes d'échec de la migration

Message d'erreur	Signification	Résolution
`Failed to connect to Oracle NoSQL Database`	Le migrateur n'a pas pu établir de connexion avec la base de données NoSQL.	Vérifiez si les valeurs des attributs `storeName` et `helperHosts` dans le fichier JSON de configuration sont valides et si les hôtes sont accessibles. Pour un emplacement de stockage sécurisé, vérifiez si le fichier de sécurité est valide avec les valeurs de nom utilisateur et de mot de passe correctes.
`Failed to connect to Oracle NoSQL Database Cloud Service`	Le migrateur n'a pas pu établir de connexion avec Oracle NoSQL Database Cloud Service.	Vérifiez que l'URL endpoint ou le nom de région indiqué dans le fichier JSON de configuration est correct. Vérifiez si le fichier d'informations d'identification OCI est disponible dans le chemin indiqué dans le fichier JSON de configuration. Assurez-vous que les informations d'identification OCI fournies dans les informations d'identification OCI sont valides.
`Table not found`	La table identifiée pour la migration n'a pas pu être localisée par NoSQL Database Migrator.	Pour la source : Vérifiez si la table est présente dans la base de données source. Assurez-vous que la table est qualifiée avec son espace de noms dans le fichier JSON de configuration, si elle est créée dans un espace de noms autre que celui par défaut. Vérifiez que vous disposez de l'autorisation de lecture/écriture requise pour accéder à la table. Si la source est Oracle NoSQL Database Cloud Service, vérifiez si le nom de compartiment valide est indiqué dans le fichier JSON de configuration et assurez-vous que vous disposez de l'autorisation requise pour accéder à la table. Pour l'évier : Vérifiez si la table est présente dans l'évier. S'il n'existe pas, vous devez créer la table manuellement ou utiliser la configuration `schemaInfo` pour la créer via la migration.
`DDL Execution failed`	Les commandes LDD fournies dans le fichier de définition de schéma d'entrée ne sont pas valides.	Vérifiez la syntaxe des commandes DDL dans le fichier `schemaPath`. Assurez-vous qu'il n'y a qu'une seule instruction DDL par ligne dans le fichier `schemaPath`.
`failed to write record to the sink table with java.lang.IllegalArgumentException`	L'enregistrement d'entrée ne correspond pas au schéma de table du récepteur.	Vérifiez si les types de données et les noms de colonne indiqués dans la table de récepteur cible correspondent au schéma de table de récepteur. Si vous avez appliqué une transformation, vérifiez si les enregistrements transformés correspondent au schéma de la table récepteur.
`Request timeout`	L'opération de la source ou de l'évier n'a pas été terminée dans les temps prévus.	Vérifiez la connexion réseau. Vérifiez que la base de données NoSQL est en fonctionnement. Essayez d'augmenter la valeur `requestTimeout` dans le fichier JSON de configuration.

Que dois-je prendre en compte avant de redémarrer une migration ayant échoué ?

Lorsqu'une tâche de migration de données échoue, le récepteur se trouve à un état intermédiaire contenant les données importées jusqu'au point d'échec. Vous pouvez identifier les détails de l'erreur et de l'échec à partir des journaux et redémarrer la migration après avoir diagnostiqué et corrigé l'erreur. Une migration redémarrée recommence et traite toutes les données depuis le début. Il est impossible de créer un point de reprise et de redémarrer la migration à partir du point d'échec. Par conséquent, NoSQL Database Migrator écrase tout enregistrement qui a déjà été migré vers le récepteur.

La migration est trop lente. Comment puis-je l'accélérer ?

Le temps nécessaire à la migration des données dépend de plusieurs facteurs tels que le volume de données migrées, la vitesse du réseau et la charge actuelle sur la base de données. Dans le cas d'un service cloud, la vitesse de migration dépend également du débit de lecture et du débit d'écriture provisionnés. Ainsi, pour améliorer la vitesse de migration, vous pouvez :

Essayez de réduire la charge globale en cours sur Oracle NoSQL Database lors de la migration des données.
Assurez-vous que la machine qui exécute la migration, la source et le récepteur sont tous situés dans le même centre de données et que les latences réseau sont minimales.
Dans le cas d'Oracle NoSQL Database Cloud Service, provisionnez un débit élevé de lecture/écriture et vérifiez si le stockage alloué à la table est suffisant. Si NoSQL Database Migrator ne crée pas la table, vous pouvez augmenter le débit d'écriture. Si le migrateur crée la table, envisagez de spécifier une valeur plus élevée pour le paramètre schemaInfo.writeUnits dans la configuration du récepteur. Une fois la migration des données terminée, vous pouvez réduire cette valeur. Tenez compte des limites quotidiennes des modifications de débit. Reportez-vous à Limites cloud et à Modèles de configuration de récepteur.

J'ai une migration à long terme impliquant d'énormes ensembles de données. Comment suivre la progression de la migration ?

Vous pouvez activer la journalisation supplémentaire pour suivre la progression d'une migration à longue durée d'exécution. Pour contrôler le comportement de journalisation d'Oracle NoSQL Database Migrator, vous devez définir le niveau de journalisation souhaité dans le fichier logging.properties. Ce fichier est fourni avec le package NoSQL Database Migrator et disponible dans le répertoire dans lequel Oracle NoSQL Database Migrator a été décompressé. Les différents niveaux de journalisation sont OFF, SEVERE, WARNING, INFO, FINE, et ALL dans l'ordre d'augmentation de la verbosité. La définition du niveau de journalisation sur OFF désactive toutes les informations de journalisation, tandis que la définition du niveau de journalisation sur ALL fournit toutes les informations de journalisation. Le niveau de journalisation par défaut est WARNING. Toutes les sorties de journalisation sont configurées pour accéder à la console par défaut. Vous pouvez voir les commentaires dans le fichier logging.properties pour connaître chaque niveau de journalisation.

Informations relatives au titre et au copyright

Référence Oracle NoSQL Database Migrator

Oracle et/ou ses affiliés.