Oracle NoSQL Database Migrator Reference

Découvrez les paramètres des modèles de configuration de source, d'évier et de transformation disponibles pour Oracle NoSQL Database Migrator.

Cet article contient les informations suivantes :

Paramètres

NoSQL Database Migrator nécessite 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 une liste de ces paramètres communs. Pour obtenir la liste des autres paramètres propres aux sources ou aux puits individuels, consultez les sections correspondantes du modèle de configuration.

Paramètres de configuration communs

Voici les paramètres de configuration communs. Pour obtenir des exemples, voir les sections de modèle de configuration individuelles.

bucket

• Objet : Spécifie le nom du seau de stockage d'objets OCI, qui contient les objets source/dissipateur.

  Assurez-vous que le seau requis existe déjà dans l'instance de stockage d'objets OCI et qu'il dispose d'autorisations de lecture/écriture.

• Type de données : chaîne
• Obligatoire (O/N) : O

chunkSize

• Objet : Spécifie la taille maximale d'une chunk de données de table à stocker dans l'évier. La valeur est en Mo. Lors de la migration, une table est fractionnée en fragments chunkSize et chaque fragment est écrit en tant que fichier distinct dans l'évier. Un nouveau fichier est créé lorsque les données sources en cours de migration dépassent la valeur chunkSize.

  S'il n'est pas spécifié, 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

• Objet : Spécifie le chemin absolu vers un fichier contenant les données d'identification OCI. L'outil de migration de bases de données NoSQL utilise ce fichier pour se connecter au service OCI tel qu'Oracle NoSQL Database Cloud Service, le service de stockage d'objets OCI, etc.

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

  Voir Exemple de configuration pour un exemple de fichier de données d'identification.

  Note :

  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

• Objet : Indique le nom du profil de configuration à utiliser pour se connecter au service OCI, par exemple Oracle NoSQL Database Cloud Service, le service de stockage d'objets OCI, etc. Les données d'identification du compte d'utilisateur sont référencées en tant que profil.

  Si vous ne spécifiez pas cette valeur, NoSQL Database Migrator utilise le profil DEFAULT.

  Note :

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

point d'extrémité

• Objet : Spécifie l'un des éléments suivants :
  • URL du point d'extrémité du service ou ID région pour le service de stockage d'objets OCI.

    Pour obtenir la liste des points d'extrémité du service de stockage d'objets pour OCI, voir Points d'extrémité du service de stockage d'objets.

  • URL du point d'extrémité du service ou ID région pour Oracle NoSQL Database Cloud Service.

    Vous pouvez spécifier l'URL complète ou l'ID région seul. Pour obtenir la liste des régions de données prises en charge pour Oracle NoSQL Database Cloud Service, voir Régions de données et URL de service associé dans le document Oracle NoSQL Database Cloud Service.

• Type de données : chaîne
• Obligatoire (O/N) : O

format

• Objet : Spécifie le format source/dissipateur.
• Type de données : chaîne
• Obligatoire (O/N) : O

namespace

• Objet : Spécifie l'espace de nom du service de stockage d'objets pour OCI. Ce paramètre est facultatif. Si vous ne spécifiez 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

• Objet : Le préfixe agit comme un conteneur ou un répertoire logique pour stocker des données dans le seau de stockage d'objets OCI.

  • Modèle de configuration source : Si le paramètre prefix spécifié, tous les objets du répertoire nommé dans le paramètre prefix sont migrés. Sinon, tous les objets présents dans le seau sont migrés.
  • Modèle de configuration du récepteur : Si le paramètre prefix est spécifié, un répertoire avec le préfixe indiqué est créé dans le seau et les objets sont migrés dans ce répertoire. Sinon, le nom de la table de la source est utilisé comme préfixe. Si un objet portant le même nom existe déjà dans le seau, il est remplacé.

  Pour plus d'informations sur les préfixes, voir Nom d'objet à l'aide des préfixes et des hiérarchies.

• Type de données : chaîne
• Obligatoire (O/N) : N

requestTimeoutMs

• Objet : Indique le temps d'attente avant la fin de chaque opération de lecture/écriture de/vers le magasin. Ceci est fourni en millisecondes. La valeur par défaut est 5000. La valeur peut être n'importe quel entier positif.

• Type de données : entier
• Obligatoire (O/N) : N

sécurité

• Objet : Indique le chemin absolu du fichier de connexion de sécurité qui contient vos données d'identification de magasin si celui-ci est un magasin sécurisé. Pour plus d'informations sur le fichier de connexion de sécurité, voir Configuration de la sécurité avec accès à distance dans le guide de l'administrateur.

  Vous pouvez utiliser l'authentification basée sur un fichier de mots de passe ou l'authentification basée sur un portefeuille. Toutefois, l'authentification basée sur un portefeuille n'est prise en charge que dans Enterprise Edition (EE) d'Oracle NoSQL Database. Pour plus d'informations sur l'authentification basée sur un portefeuille, voir Sécurité des sources et des éviers.

  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

• Objet : Identifie le type de source/produit.
• Type de données : chaîne
• Obligatoire (O/N) : O

useDelegationToken

• Objet : 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 Migrator à partir de Cloud Shell. Le jeton de délégation est créé automatiquement pour l'utilisateur lors de l'appel de Cloud Shell.

  La valeur par défaut est false.

• Type de données : boolean
• Obligatoire (O/N) : N

  Note :

  • L'authentification avec jeton de délégation n'est prise en charge que lorsque l'outil NoSQL Database Migrator s'exécute à partir d'un 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 en charge la migration uniquement entre les sources et les puits suivants :

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

useInstancePrincipal

• Objet : Indique si l'outil NoSQL Database Migrator utilise ou non l'authentification du principal d'instance pour se connecter au service OCI, par exemple Oracle NoSQL Database Cloud Service, le stockage d'objets OCI, etc. Pour plus d'informations sur la méthode d'authentification du principal d'instance, voir Sécurité de la source et du récepteur.

  La valeur par défaut est false.

  Note :

  • L'authentification avec les principaux d'instance n'est prise en charge que lorsque l'outil NoSQL Database Migrator s'exécute dans une instance de calcul OCI, par exemple, l'outil NoSQL Database Migrator s'exécutant dans une machine virtuelle hébergée sur OCI.
  • 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 : boolean
• Obligatoire (O/N) : N

Modèles de configuration de 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, voir Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Pour plus de détails sur les formats d'évier valides pour chaque source, voir Modèles de configuration d'évier.

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 indiquée vers un évier valide.

• Source de fichier JSON

  Fichier ou répertoire spécifié contenant les données JSON.

• Fichier JSON dans le seau de stockage d'objets OCI

  Fichier JSON spécifié dans le seau de stockage d'objets pour OCI.

• Fichier JSON formaté par MongoDB

  Fichier ou répertoire spécifié contenant les données JSON formatées MongoDB.

• Fichier JSON formaté par MongoDB dans le seau de stockage d'objets OCI

  Fichier JSON exporté MongoDB spécifié stocké dans le seau de stockage d'objets OCI.

• Fichier JSON au format DynamoDB stocké dans AWS S3

  Fichier JSON exporté DynamoDB spécifié stocké dans le stockage AWS S3.

• Fichier JSON formaté par DynamoDB

  Fichier JSON exporté DynamoDB spécifié à partir d'un système de fichiers.

• Oracle NoSQL Database (en anglais)

  Table spécifiée dans Oracle NoSQL Database.

• Service Oracle NoSQL Database Cloud

  Table spécifiée dans Oracle NoSQL Database Cloud Service.

• Source de fichier CSV

  Fichier ou répertoire spécifié contenant les données CSV.

• Fichier CSV dans le seau de stockage d'objets OCI

  Fichier CSV spécifié dans le seau de stockage d'objets OCI.

Source de fichier JSON

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

Vous pouvez migrer un fichier source JSON en spécifiant le chemin d'accès au fichier ou un répertoire dans le modèle de configuration source.

Un exemple de fichier source JSON est le suivant :

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

Paramètres de configuration communs

• type

  Utilisez "type" : "file"

• format

  Utiliser "format" : "json"

Paramètres de configuration uniques

• dataPath
• schemaInfo
• schemaInfo.schemaPath

dataPath

• Objet : Indique le chemin absolu d'un fichier ou d'un répertoire contenant les données JSON pour la migration.

  Vous devez vous assurer que ces données correspondent au schéma de la table NoSQL défini au niveau de l'évier. Si vous spécifiez un répertoire, NoSQL Database Migrator identifie tous les fichiers avec 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) : O
• Exemple :

  • Spécification d'un fichier JSON

    "dataPath" : "/home/user/sample.json"

  • Définition d'un répertoire

    "dataPath" : "/home/user"

schemaInfo

• Objet : Spécifie le schéma des données sources en cours de migration. Ce schéma est transmis à l'évier NoSQL.

• Type de données : Objet
• Obligatoire (O/N) : N

schemaInfo.schemaPath

• Objet : Spécifie le chemin absolu du fichier de définition de schéma contenant des énoncés LDD pour la table NoSQL en cours de migration.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :

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

Fichier JSON dans le seau de stockage d'objets OCI

Le format du fichier de configuration pour le fichier JSON dans le seau de stockage d'objets OCI en tant que source de NoSQL Database Migrator est affiché ci-dessous.

Vous pouvez migrer un fichier JSON dans le seau de stockage d'objets OCI en spécifiant le nom du seau dans le modèle de configuration source.

Un exemple de fichier source JSON dans le seau de stockage d'objets OCI est le suivant :

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

Note :

Les types de dissipateur valides pour le type de source du stockage d'objets OCI 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 sources

Paramètres de configuration communs

• type

  Utilisez "type" : "object_storage_oci"

• format

  Utiliser "format" : "json"

• point d'extrémité
  Exemple :

  • ID région : "endpoint" : "us-ashburn-1"

  • Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• namespace

  Exemple : "namespace" : "my-namespace"

• bucket

  Exemple : "bucket" : "my-bucket"

• préfixe
  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)
• credentials
  Exemple :

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Exemple :

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Exemple : "useInstancePrincipal" : true

• useDelegationToken

  Exemple : "useDelegationToken" : true

  Note :

  L'authentification avec jeton de délégation n'est prise en charge que lorsque l'outil de migration de bases de données NoSQL s'exécute à partir d'un Cloud Shell.

Paramètres de configuration uniques

• schemaInfo
• schemaInfo.schemaObject

schemaInfo

• Objet : Spécifie le schéma des données sources en cours de migration. Ce schéma est transmis à l'évier NoSQL.

• Type de données : Objet
• Obligatoire (O/N) : N

schemaInfo.schemaObject

• Objet : Spécifie le nom de l'objet dans le seau où sont stockées les définitions de schéma de table NoSQL pour les données migrées.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :

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

Fichier JSON formaté par MongoDB

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

Vous pouvez migrer des données JSON exportées MongoDB en spécifiant 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, le mode canonique et le mode relaxé. Vous pouvez fournir le fichier JSON au format MongoDB généré à l'aide de l'outil mongoexport en mode canonique ou relaxé. Les deux modes sont pris en charge par NoSQL Database Migrator pour la migration.

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

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

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

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 sources

Paramètres de configuration communs

• type

  Utilisez "type" : "file"

• format

  Utilisez "format" : "mongodb_json"

Paramètres de configuration uniques

• dataPath
• schemaInfo
• schemaInfo.schemaPath

dataPath

• Objet : Spécifie le chemin absolu vers un fichier ou 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 avec 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 la table NoSQL défini au niveau de l'évier.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :

  • Spécification d'un fichier JSON formaté MongoDB

    "dataPath" : "/home/user/sample.json"

  • Définition d'un répertoire

    "dataPath" : "/home/user"

schemaInfo

• Objet : Spécifie le schéma des données sources en cours de migration. Ce schéma est transmis à l'évier NoSQL.

• Type de données : Objet
• Obligatoire (O/N) : N

schemaInfo.schemaPath

• Objet : Spécifie le chemin absolu du fichier de définition de schéma contenant des énoncés LDD pour la table NoSQL en cours de migration.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :

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

Fichier JSON formaté par MongoDB dans le seau de stockage d'objets OCI

Le format de fichier de configuration du fichier JSON formaté MongoDB dans le seau de stockage d'objets OCI en tant que source de NoSQL Database Migrator est affiché ci-dessous.

Vous pouvez migrer les données JSON exportées MongoDB dans le seau de stockage d'objets OCI en spécifiant le nom du seau dans le modèle de configuration source.

Extrayez les données de MongoDB à l'aide de l'utilitaire mongoexport et chargez-les dans le seau de stockage d'objets OCI. Voir mongoexport pour plus d'informations. MongoDB prend en charge deux types d'extension au format JSON des fichiers, le mode canonique et le mode relaxé. Les deux formats sont pris en charge dans le seau de stockage d'objets d'OCI.

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

Note :

Les types de dissipateur valides pour le type de source du stockage d'objets OCI 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 sources

Paramètres de configuration communs

• type

  Utilisez "type" : "object_storage_oci"

• format

  Utilisez "format" : "mongodb_json"

• point d'extrémité
  Exemple :

  • ID région : "endpoint" : "us-ashburn-1"

  • Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• namespace

  Exemple : "namespace" : "my-namespace"

• bucket

  Exemple : "bucket" : "my-bucket"

• préfixe
  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)

  Note :

  Si vous n'indiquez aucune valeur, tous les objets présents dans le seau sont migrés.
• credentials
  Exemple :

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Exemple :

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Exemple : "useInstancePrincipal" : true

Paramètres de configuration uniques

• schemaInfo
• schemaInfo.schemaObject

schemaInfo

• Objet : Spécifie le schéma des données sources en cours de migration. Ce schéma est transmis à l'évier NoSQL.

• Type de données : Objet
• Obligatoire (O/N) : N

schemaInfo.schemaObject

• Objet : Spécifie le nom de l'objet dans le seau où sont stockées les définitions de schéma de table NoSQL pour les données migrées.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :

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

Fichier JSON au format DynamoDB stocké dans AWS S3

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

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

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

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

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

Les types de dissipateur valides pour JSON au format DynamoDB stockés 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 sources

Paramètres de configuration communs

• type

  Utilisez "type" : "aws_s3"

• format

  Utilisez "format" : "dynamodb_json"

  Note :

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

Paramètres de configuration uniques

• s3URL
• credentials
• credentialsProfile

s3URL

• Objet : Spécifie 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>. NoSQL Database Migrator recherche les fichiers json.gz dans le préfixe lors de l'importation.

  Note :

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

credentials

• Objet : Spécifie le chemin absolu vers un fichier contenant les données 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 de données d'identification, voir Paramètres des fichiers de données d'identification et de configuration.
• Type de données : chaîne
• Obligatoire (O/N) : N
• Exemple :

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

  Note :

  L'outil de migration de bases de données NoSQL n'enregistre aucune des informations de données d'identification. Vous devez protéger correctement le fichier de données d'identification contre tout accès non autorisé.

credentialsProfile

• Objet : Nom du profil dans le fichier de données d'identification AWS à utiliser pour la connexion à AWS S3. Les données d'identification du compte d'utilisateur sont référencées en tant que profil. Si vous ne spécifiez pas cette valeur, NoSQL Database Migrator utilise le profil default. Pour plus d'informations sur le fichier de données d'identification, voir Paramètres des fichiers de données d'identification et de configuration.
• Type de données : chaîne
• Obligatoire (O/N) : N
• Exemple :

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

Fichier JSON formaté par DynamoDB

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

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

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

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

Vous devez copier les données de table DynamoDB exportées à partir du stockage AWS S3 vers un système de fichiers monté local.

Les types de dissipateur 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 sources

Paramètres de configuration communs

• type

  Utilisez "type" : "file"

• format

  Utilisez "format" : "dynamodb_json"

Paramètre de configuration unique

dataPath

• Objet : Spécifie le chemin absolu d'un fichier ou d'un répertoire contenant les données de la table DynamoDB exportées. Vous devez copier les données de table DynamoDB exportées depuis AWS S3 vers un système de fichiers monté local. Vous devez vous assurer que ces données correspondent au schéma de la table NoSQL défini au niveau de l'évier. Si vous spécifiez un répertoire, 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) : O
• Exemple :
  • Définition d'un fichier

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

  • Définition d'un répertoire

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

Oracle NoSQL Database (en anglais)

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 spécifiant le nom de la table dans le modèle de configuration source.

Un exemple de table Oracle NoSQL Database est le suivant :

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

Paramètre de configuration commun

• type

  Utilisez "type" : "nosqldb"

• sécurité

  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

• Objet : Nom du magasin Oracle NoSQL Database.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple : "storeName" : "kvstore"

helperHosts

• Objet : Liste des paires de ports d'hôte et de registre au format hostname:port. Délimitez chaque élément de la liste à l'aide d'une virgule. Vous devez spécifier au moins un hôte d'aide.

• Type de données : Tableau de chaînes
• Obligatoire (O/N) : O
• Exemple : "helperHosts" : ["localhost:5000","localhost:6000"]

table

• Objet : 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) : O
• Exemple :

  • Avec l'espace de noms DEFAULT "table" :"mytable"

  • Avec un espace de noms non par défaut "table" : "mynamespace:mytable"

  • Pour spécifier une table enfant "table" : "mytable.child"

includeTTL

• Objet : Indique si les métadonnées de durée de vie des rangées de table doivent être incluses ou non lors de l'exportation des tables Oracle NoSQL Database. Si cette option est réglée à 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 rangée. 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 rangées ayant une valeur d'expiration positive pour la durée de vie sont incluses dans les rangées exportées. Si une ligne n'expire pas, ce qui signifie TTL=0, ses métadonnées TTL ne sont pas incluses explicitement. 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 : boolean
• Obligatoire (O/N) : N
• Exemple : "includeTTL" : true

Service Oracle NoSQL Database Cloud

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 spécifiant le nom ou l'OCID du compartiment dans lequel la table réside dans le modèle de configuration source.

Un exemple de table Oracle NoSQL Database Cloud Service est le suivant :

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

Paramètres de configuration communs

• type

  Utilisez "type" : "nosqldb_cloud"

• point d'extrémité
  Exemple :

  • ID région : "endpoint" : "us-ashburn-1"

  • Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• credentials
  Exemple :

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Exemple :

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Exemple : "useInstancePrincipal" : true

• useDelegationToken

  Exemple : "useDelegationToken" : true

  Note :

  L'authentification avec jeton de délégation n'est prise en charge que lorsque l'outil de migration de bases de données NoSQL s'exécute à partir d'un Cloud Shell.
• requestTimeoutMs

  Exemple : "requestTimeoutMs" : 5000

Paramètres de configuration uniques

• table
• compartiment
• readUnitsPercent
• includeTTL

table

• Objet : Nom de la table à partir de laquelle migrer les données.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :
  • Pour spécifier une table "table" : "myTable"
  • Pour spécifier une table enfant "table" : "mytable.child"

compartiment

• Objet : Spécifie le nom ou l'OCID du compartiment dans lequel réside la table.

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

  Vous pouvez trouver l'OCID de votre compartiment dans la fenêtre Explorateur de compartiments sous Gouvernance dans la console OCI Cloud.

• Type de données : chaîne
• Obligatoire (O/N) : O, si la table n'est pas dans le compartiment racine de la location OU lorsque le paramètre useInstancePrincipal est réglé à Vrai.

  Note :

  Si le paramètre useInstancePrincipal est réglé à Vrai, le compartiment doit spécifier l'OCID du compartiment et non le nom.
• Exemple :

  • Nom du compartiment

    "compartment" : "mycompartment"

  • Nom de compartiment qualifié avec son compartiment parent

    "compartment" : "parent.childcompartment"

  • Aucune valeur fournie. Par défaut, il s'agit du compartiment racine.

    "compartment": ""

  • OCID du compartiment.

    "compartment" : "ocid1.tenancy.oc1...4ksd"

readUnitsPercent

• Objet : Pourcentage d'unités de lecture de table à utiliser lors de la migration de la table NoSQL.

  La valeur par défaut est 90. L'intervalle valide est un entier compris entre 1 et 100. Le temps nécessaire à la migration des données est directement proportionnel à 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 connaître les limites quotidiennes des modifications de débit, voir Limites du nuage dans le document Oracle NoSQL Database Cloud Service.

  Voir Dépannage de l'outil de migration d'Oracle NoSQL Database pour savoir comment utiliser cet attribut pour améliorer la vitesse de migration des données.

• Type de données : entier
• Obligatoire (O/N) : N
• Exemple : "readUnitsPercent" : 90

includeTTL

• Objet : Indique s'il faut inclure ou non les métadonnées de durée de vie pour les rangées de table lors de l'exportation des tables Oracle NoSQL Database Cloud Service. Si cette option est réglée à 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 rangée. 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 rangées ayant une valeur d'expiration positive pour la durée de vie sont incluses dans les rangées exportées. Si une ligne n'expire pas, ce qui signifie TTL=0, ses métadonnées TTL ne sont pas incluses explicitement. 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 : boolean
• Obligatoire (O/N) : N
• Exemple : "includeTTL" : true

Source de fichier CSV

Le format du fichier de configuration du fichier CSV en tant que source de NoSQL Database Migrator est affiché ci-dessous. Le fichier CSV doit respecter le format RFC4180.

Vous pouvez migrer un fichier CSV ou un répertoire contenant les données CSV en spécifiant 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 sources

Paramètres de configuration communs

• type

  Utilisez "type" : "file"

• format

  Utilisez "format" : "csv"

Paramètres de configuration uniques

• dataPath

• hasHeader

• colonnes

• csvOptions

• csvOptions.encoding

• csvOptions.trim

chemin de données

• Objet : Spécifie le chemin absolu vers un fichier ou un répertoire contenant les données CSV à migrer. Si vous spécifiez un répertoire, NoSQL Database Migrator importe tous les fichiers ayant 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 la table NoSQL Database défini dans la table source. Les sous- répertoires ne sont pas pris en charge.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :

  • Spécification d'un fichier CSV

    "dataPath" : "/home/user/sample.csv"

  • Définition d'un répertoire

    "dataPath" : "/home/user"

Note :

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 dans le 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 corrompues, l'outil NoSQL Database Migrator n'analyse pas les enregistrements CSV. En cas d'erreur lors de la migration, l'outil NoSQL Database Migrator enregistre les informations sur les enregistrements d'entrée en échec à des fins de débogage et d'information. Pour plus de détails, voir Progression de l'outil de migration de journalisation dans Utilisation de l'outil de migration de données d'Oracle NoSQL.

hasHeader

• Objet : Indique si le fichier CSV a un en-tête ou non. Si cette valeur est réglée à true, la première ligne est ignorée. S'il est réglé à false, la première ligne est considérée comme un enregistrement CSV. La valeur par défaut est false.

• Type de données : Booléen
• Obligatoire (O/N) : N

• Exemple : "hasHeader" : "false"

colonnes

• Objet : Spécifie la liste des noms de colonne de la table NoSQL Database. L'ordre des noms de colonne indique le mappage des champs de fichier CSV avec les colonnes de la 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'importation dans une table comportant une colonne d'identité, vous pouvez ignorer le nom de la colonne d'identité dans le paramètre columns.

  Note :

  • 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 nulle est insérée lors de la migration. Pour plus d'informations sur les valeurs par défaut, voir la section Définitions de type de données dans le 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 quelconque de l'enregistrement CSV est vide, elle est réglée à la valeur par défaut des colonnes correspondantes dans la table NoSQL Database. Si aucune valeur par défaut n'est fournie, une valeur nulle 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

• Objet : Spécifie les options de formatage d'un fichier CSV. Indiquez le format d'encodage du jeu de caractères du fichier CSV et choisissez de couper ou non les espaces vides.

• Type de données : Objet
• Obligatoire (O/N) : N

csvOptions.encoding

• Objet : Spécifie 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

• Objet : Indique si les blancs 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 seau de stockage d'objets OCI

Le format du fichier de configuration du fichier CSV dans le seau de stockage d'objets OCI en tant que source de NoSQL Database Migrator est affiché ci-dessous. Le fichier CSV doit respecter le format RFC4180.

Vous pouvez migrer un fichier CSV dans le seau de stockage d'objets OCI en spécifiant le nom du seau dans le modèle de configuration source.

Un exemple de fichier CSV dans le seau de stockage d'objets OCI est le suivant :

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

Note :

Les types de dissipateur valides pour le type de source du stockage d'objets OCI 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 sources

Paramètres de configuration communs

• type

  Utilisez "type" : "object_storage_oci"

• format

  Utilisez "format" : "csv"

• point d'extrémité
  Exemple :

  • ID région : "endpoint" : "us-ashburn-1"

  • Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• namespace

  Exemple : "namespace" : "my-namespace"

• bucket

  Exemple : "bucket" : "my-bucket"

  Note :

  • NoSQL Database Migrator importe tous les fichiers avec l'extension .csv ou .CSV en fonction de l'objet et les copie dans une seule table 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 dans le 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 corrompues, l'outil NoSQL Database Migrator n'analyse pas les enregistrements CSV. En cas d'erreur lors de la migration, l'outil NoSQL Database Migrator enregistre les informations sur les enregistrements d'entrée en échec à des fins de débogage et d'information. Pour plus de détails, voir Progression de l'outil de migration de journalisation dans Utilisation de l'outil de migration de données d'Oracle NoSQL.

• préfixe
  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)
• credentials
  Exemple :

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  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

• Objet : Indique si le fichier CSV a un en-tête ou non. Si cette valeur est réglée à true, la première ligne est ignorée. S'il est réglé à false, la première ligne est considérée comme un enregistrement CSV. La valeur par défaut est false.

• Type de données : Booléen
• Obligatoire (O/N) : N

• Exemple : "hasHeader" : "false"

colonnes

• Objet : Spécifie la liste des noms de colonne de la table NoSQL Database. L'ordre des noms de colonne indique le mappage des champs de fichier CSV avec les colonnes de la 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'importation dans une table comportant une colonne d'identité, vous pouvez ignorer le nom de la colonne d'identité dans le paramètre columns.

  Note :

  • 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 nulle est insérée lors de la migration. Pour plus d'informations sur les valeurs par défaut, voir la section Définitions de type de données dans le 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 quelconque de l'enregistrement CSV est vide, elle est réglée à la valeur par défaut des colonnes correspondantes dans la table NoSQL Database. Si aucune valeur par défaut n'est fournie, une valeur nulle 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

• Objet : Spécifie les options de formatage d'un fichier CSV. Indiquez le format d'encodage du jeu de caractères du fichier CSV et choisissez de couper ou non les espaces vides.

• Type de données : Objet
• Obligatoire (O/N) : N

csvOptions.encoding

• Objet : Spécifie 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

• Objet : Indique si les blancs 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 l'évier pour chaque évier valide et la fonction de chaque paramètre de configuration.

Pour le modèle de fichier de configuration, voir Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Pour plus de détails sur les formats sources valides pour chacun des éviers, voir Modèles de configuration de la source.

Rubriques

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

• Dissipateur de fichier JSON

  Fichier JSON spécifié.

• Fichier Parquet

  Fichier Parquet dans le répertoire spécifié.

• Fichier JSON dans le seau de stockage d'objets OCI

  Fichier JSON dans le seau de stockage d'objets OCI spécifié.

• Fichier Parquet dans le seau de stockage d'objets OCI

  Fichier Parquet dans le seau de stockage d'objets OCI spécifié.

• Oracle NoSQL Database (en anglais)

  Table spécifiée dans Oracle NoSQL Database.

• Service Oracle NoSQL Database Cloud

  Table spécifiée dans Oracle NoSQL Database Cloud Service.

Dissipateur de fichier JSON

Le format du fichier de configuration du fichier JSON comme évier de NoSQL Database Migrator est affiché ci-dessous.

Modèle de configuration des éviers

"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

  Utilisez "type" : "file"

• format

  Utiliser "format" : "json"

• chunkSize

  Exemple : "chunkSize" : 40

  Note :

  Ce paramètre est applicable UNIQUEMENT lorsque le paramètre useMultiFiles est réglé à Vrai.

Paramètres de configuration uniques

• dataPath
• schemaPath
• jolie
• useMultiFiles

dataPath

• Objet : Indique le chemin absolu d'un fichier dans lequel les données sources seront copiées au format JSON.

  Si le fichier n'existe pas dans le chemin de données spécifié, NoSQL Database Migrator le crée. S'il existe, NoSQL Database Migrator remplace son contenu par les données sources.

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

  Note :

  Si le paramètre useMultiFiles est réglé à Vrai, spécifiez le chemin d'accès à un répertoire sinon spécifiez le chemin d'accès au fichier.
• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :

  • Avec le paramètre useMultiFiles réglé à Vrai

    "dataPath" :"/home/user/data"

  • Avec le paramètre useMultiFiles non spécifié ou réglé à Faux

    "dataPath" :"/home/user/sample.json"

schemaPath

• Objet : Spécifie le chemin absolu vers un fichier pour é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 l'évier. Si cette valeur est spécifié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 en tant que commande LDD par ligne dans ce fichier. Si le fichier n'existe pas dans le chemin de données spécifié, NoSQL Database Migrator le crée. S'il existe déjà, NoSQL Database Migrator remplace son contenu par les données sources. 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

• Objet : Spécifie si la sortie JSON doit être embellie ou non pour augmenter la lisibilité.

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

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "pretty" : true

useMultiFiles

• Objet : Spécifie si les données de la table NoSQL doivent être fractionnées en plusieurs fichiers lors de la migration des données sources vers un fichier.

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

  Si ce paramètre est réglé à Vrai, lors de la migration des données sources vers un fichier, les données de la table NoSQL sont fractionnées en plusieurs fichiers plus petits. Par exemple, <chunk>.json, où chunk=000000, 000001, 000002, etc.

  dataPath
           |--000000.json
           |--000001.json

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "useMultiFiles" : true

Fichier Parquet

Le format du fichier de configuration du fichier Parquet en tant que lavabo de NoSQL Database Migrator est affiché ci-dessous.

Modèle de configuration des éviers

"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

  Utilisez "type" : "file"

• format

  Utilisez "format" : "parquet"

• chunkSize

  Exemple : "chunkSize" : 40

Paramètres de configuration uniques

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

dataPath

• Objet : Spécifie le chemin d'accès à un répertoire pour stocker les données de la table NoSQL migrées. Assurez-vous que le répertoire existe déjà et qu'il dispose des autorisations de lecture et d'écriture.

• Type de données : chaîne
• Obligatoire (O/N) : O

• Exemple : "dataPath" : "/home/user/migrator/my_table"

compression

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

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

• Type de données : chaîne
• Obligatoire (O/N) : N

• Exemple : "compression" : "GZIP"

parquetOptions

• Objet : Spécifie les options permettant de sélectionner les types logiques Parquet pour les colonnes NoSQL ENUM, JSON et UUID.

  Si vous ne spécifiez pas ce paramètre, NoSQL Database Migrator é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

• Objet : Spécifie si les données de colonne JSON NoSQL doivent être écrites ou non en tant que type JSON logique Parquet. Pour plus d'informations, voir Définitions de type logique Parquet.

  S'il n'est pas spécifié ou réglé à Faux, NoSQL Database Migrator écrit les données de colonne JSON NoSQL en tant que chaîne.

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "useLogicalJson" : true

parquetOptions.useLogicalEnum

• Objet : Spécifie si les données de colonne ENUM NoSQL doivent être écrites ou non en tant que type ENUM logique Parquet. Pour plus d'informations, voir Définitions de type logique Parquet.

  S'il n'est pas spécifié ou réglé à Faux, NoSQL Database Migrator écrit les données de colonne ENUM NoSQL en tant que chaîne.

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "useLogicalEnum" : true

parquetOptions.useLogicalUUID

• Objet : Spécifie si les données de colonne d'UUID NoSQL doivent être écrites ou non en tant que type d'UUID logique Parquet. Pour plus d'informations, voir Définitions de type logique Parquet.

  S'il n'est pas spécifié ou réglé à Faux, NoSQL Database Migrator écrit les données de colonne UUID NoSQL en tant que chaîne.

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "useLogicalUUID" : true

parquetOptions.truncateDoubleSpecials

• Objet : Spécifie si les valeurs +Infinity, -Infinity et NaN doivent être tronquées ou non.

  Par défaut, elle est réglée à false. Si le paramètre est réglé à true,

  • Positive_Infinity est tronqué à Double.MAX_VALUE.
  • NEGATIVE_INFINITY est tronqué à -Double.MAX_VALUE.
  • NaN est tronqué à 9.9999999999999990E307.
• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "truncateDoubleSpecials" : true

Fichier JSON dans le seau de stockage d'objets OCI

Le format du fichier de configuration pour le fichier JSON dans le seau de stockage d'objets OCI en tant qu'évier de l'outil de migration de bases de données NoSQL est affiché ci-dessous.

Note :

Les types de source valides pour le stockage d'objets OCI en tant qu'émetteur sont nosqldb et nosqldb_cloud.

Modèle de configuration des éviers

"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

  Utilisez "type" : "object_storage_oci"

• format

  Utiliser "format" : "json"

• point d'extrémité
  Exemple :

  • ID région : "endpoint" : "us-ashburn-1"

  • Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• namespace

  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 sources sont migrées vers les fichiers <prefix>/Data/<chunk>.json, où chunk=000000.json, 000001.json, etc.

  Exemple :

  1. "prefix" : "my_export"
  2. "prefix" : "my_export/2021-04-05/"
• chunkSize

  Exemple : "chunkSize" : 40

• credentials
  Exemple :

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Exemple :

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Exemple : "useInstancePrincipal" : true

• useDelegationToken

  Exemple : "useDelegationToken" : true

  Note :

  L'authentification avec jeton de délégation n'est prise en charge que lorsque l'outil de migration de bases de données NoSQL s'exécute à partir d'un Cloud Shell.

Paramètre de configuration unique

jolie

• Objet : Spécifie si la sortie JSON doit être embellie ou non pour augmenter la lisibilité.

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

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "pretty" : true

Fichier Parquet dans le seau de stockage d'objets OCI

Le format du fichier de configuration pour le fichier Parquet dans le seau de stockage d'objets OCI en tant qu'évier de NoSQL Database Migrator est affiché ci-dessous.

Note :

Les types de source valides pour le type de source du service de stockage d'objets OCI sont nosqldb et nosqldb_cloud.

Modèle de configuration des éviers

"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

  Utilisez "type" : "object_storage_oci"

• format

  Utilisez "format" : "parquet"

• point d'extrémité
  Exemple :

  • ID région : "endpoint" : "us-ashburn-1"

  • Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• namespace

  Exemple : "namespace" : "my-namespace"

• bucket

  Exemple : "bucket" : "my-bucket"

• préfixe

  Les données sources sont migrées vers les fichiers <prefix>/Data/<chunk>.parquet, où chunk=000000.parquet, 000001.parquet, etc.

  Exemple :

  1. "prefix" : "my_export"
  2. "prefix" : "my_export/2021-04-05/"
• chunkSize

  Exemple : "chunkSize" : 40

• credentials
  Exemple :

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Exemple :

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Exemple : "useInstancePrincipal" : true

• useDelegationToken

  Exemple : "useDelegationToken" : true

  Note :

  L'authentification avec jeton de délégation n'est prise en charge que lorsque l'outil de migration de bases de données NoSQL s'exécute à partir d'un Cloud Shell.

Paramètre de configuration unique

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

compression

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

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

• Type de données : chaîne
• Obligatoire (O/N) : N

• Exemple : "compression" : "GZIP"

parquetOptions

• Objet : Spécifie les options permettant de sélectionner les types logiques Parquet pour les colonnes NoSQL ENUM, JSON et UUID.

  Si vous ne spécifiez pas ce paramètre, NoSQL Database Migrator é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

• Objet : Spécifie si les données de colonne JSON NoSQL doivent être écrites ou non en tant que type JSON logique Parquet. Pour plus d'informations, voir Définitions de type logique Parquet.

  S'il n'est pas spécifié ou réglé à Faux, NoSQL Database Migrator écrit les données de colonne JSON NoSQL en tant que chaîne.

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "useLogicalJson" : true

parquetOptions.useLogicalEnum

• Objet : Spécifie si les données de colonne ENUM NoSQL doivent être écrites ou non en tant que type ENUM logique Parquet. Pour plus d'informations, voir Définitions de type logique Parquet.

  S'il n'est pas spécifié ou réglé à Faux, NoSQL Database Migrator écrit les données de colonne ENUM NoSQL en tant que chaîne.

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "useLogicalEnum" : true

parquetOptions.useLogicalUUID

• Objet : Spécifie si les données de colonne d'UUID NoSQL doivent être écrites ou non en tant que type d'UUID logique Parquet. Pour plus d'informations, voir Définitions de type logique Parquet.

  S'il n'est pas spécifié ou réglé à Faux, NoSQL Database Migrator écrit les données de colonne UUID NoSQL en tant que chaîne.

• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "useLogicalUUID" : true

parquetOptions.truncateDoubleSpecials

• Objet : Spécifie si les valeurs +Infinity, -Infinity et NaN doivent être tronquées ou non.

  Par défaut, elle est réglée à false. Si le paramètre est réglé à true,

  • Positive_Infinity est tronqué à Double.MAX_VALUE.
  • NEGATIVE_INFINITY est tronqué à -Double.MAX_VALUE.
  • NaN est tronqué à 9.9999999999999990E307.
• Type de données : boolean
• Obligatoire (O/N) : N

• Exemple : "truncateDoubleSpecials" : true

Oracle NoSQL Database (en anglais)

Le format du fichier de configuration pour Oracle NoSQL Database en tant qu'évier de NoSQL Database Migrator est affiché ci-dessous.

Modèle de configuration des éviers

"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 commun

• type

  Utilisez "type" : "nosqldb"

• sécurité

  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
• remplacer

storeName

• Objet : Nom du magasin Oracle NoSQL Database.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple : "storeName" : "kvstore"

helperHosts

• Objet : Liste des paires de ports d'hôte et de registre au format hostname:port. Délimitez chaque élément de la liste à l'aide d'une virgule. Vous devez spécifier au moins un hôte d'aide.

• Type de données : Tableau de chaînes
• Obligatoire (O/N) : O
• Exemple : "helperHosts" : ["localhost:5000","localhost:6000"]

table

• Objet : Spécifie 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 le magasin pendant la migration et son schéma doit correspondre aux données sources.

  Si la table n'est pas disponible dans l'évier, vous pouvez utiliser le paramètre schemaInfo pour demander à NoSQL Database Migrator de créer la table dans l'évier.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :

  • Avec l'espace de noms DEFAULT "table" :"mytable"

  • Avec un espace de noms non par défaut "table" : "mynamespace:mytable"

  • Pour spécifier une table enfant "table" : "mytable.child"

    Note :

    Vous pouvez migrer les tables enfants d'une source de données valide vers Oracle NoSQL Database. NoSQL Database Migrator copie une seule table dans chaque exécution. Assurez-vous que la table parent est migrée avant la table enfant.

includeTTL

• Objet : Indique s'il faut inclure ou non les métadonnées de durée de vie pour les rangées de table fournies par la source lors de l'importation 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 rangées de table fournies par la source lors de l'importation de tables Oracle NoSQL Database.

  Si ce paramètre est réglé à Vrai, l'outil NoSQL Database Migrator effectue les vérifications suivantes sur les métadonnées de durée de vie lors de l'importation d'une rangée de table :

  • Si vous importez une rangée qui n'a pas de définition _metadata, l'outil NoSQL Database Migrator règle la durée de vie à 0, ce qui signifie que la rangée n'expire jamais.
  • Si vous importez une rangée 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 rangée est importée. Si la ligne a déjà expiré par rapport à l'heure de référence, elle est ignorée. Si l'enregistrement n'a pas expiré, il est importé avec la valeur de durée de vie. Par défaut, l'heure de référence de l'opération d'importation est l'heure courante en millisecondes, obtenue à partir de System.currentTimeMillis(), de l'ordinateur sur lequel l'outil NoSQL Database Migrator est exécuté. Mais vous pouvez également définir une heure de référence personnalisée à l'aide du paramètre de configuration ttlRelativeDate si vous souhaitez prolonger l'heure d'expiration et importer des rangées qui, autrement, expireront immédiatement.
    La formule utilisée pour 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.

    Note :

    Comme les limites de durée de vie d'Oracle NoSQL sont en heures et en jours, dans certains cas, la durée de vie de la rangée importée peut être ajustée à l'heure ou au jour le plus proche. Par exemple, considérez une rangée 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 rangée n'a pas expiré par rapport à l'heure de référence lors de l'importation de ces données, la nouvelle durée de vie de la rangée est 1629712800000 (2021-08-23 10:00:00).
• Type de données : boolean
• Obligatoire (O/N) : N
• Exemple : "includeTTL" : true

ttlRelativeDate

• Objet : Spécifiez une date UTC dans le format AAAA-MM-JJ hh:mm:ss utilisé pour définir l'expiration de durée de vie des rangées de table lors de l'importation dans Oracle NoSQL Database.

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

  Si vous ne spécifiez pas ce paramètre, il prend par défaut l'heure courante 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"

  Considérons un scénario où 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 rangées 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 courante). Mais si vous voulez prolonger la date d'expiration des rangées 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 souhaitez prolonger de cinq jours le délai d'expiration des rangées de la table, réglez la valeur des paramètres de configuration ttlRelativeDate à 3-janv.-2021, qui est utilisée comme heure de référence lors de l'importation des rangées de la table.

schémamainfo

• Objet : Spécifie le schéma pour les données en cours de migration. Si ce n'est pas spécifié, NoSQL Database Migrator suppose que la table existe déjà dans le magasin de l'évier.

• Type de données : Objet
• Obligatoire (O/N) : N

schemaInfo.schemaPath

• Objet : Spécifie le chemin absolu vers un fichier contenant des énoncés LDD pour la table NoSQL.

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

  NoSQL Database Migrator ne prend pas en charge plus d'un énoncé LDD par ligne dans le fichier schemaPath.

• Type de données : chaîne

• Obligatoire (O/N) : N

  Note :

  defaultSchema et schemaPath s'excluent mutuellement.

• Exemple : "schemaPath" : "/home/user/schema_file"

schemaInfo.defaultSchema

• Objet : Le réglage de ce paramètre à Vrai indique à NoSQL Database Migrator de créer une table avec un schéma par défaut. Le schéma par défaut est défini par l'outil de migration lui-même. Pour plus d'informations sur les définitions de schéma par défaut, voir Schéma par défaut dans Utilisation d'Oracle NoSQL Data Migrator.

• Type de données : boolean

• Obligatoire (O/N) : N

  Note :

  defaultSchema et schemaPath s'excluent mutuellement.

schemaInfo.useSourceSchema

• Objet : Indique si l'émetteur 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 : boolean

• Obligatoire (O/N) : N

  Note :

  Les paramètres defaultSchema, schemaPath et useSourceSchema s'excluent mutuellement. Spécifiez seulement un de ces paramètres.
• Exemple :
  • Avec 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

• Objet : Spécifie la clé de partition DynamoDB et le type Oracle NoSQL Database correspondant à utiliser dans la table Oracle NoSQL Database de l'émetteur. Cette clé sera utilisée comme clé de partition de table de base de données NoSQL. Cela s'applique uniquement lorsque defaultSchema est réglé à Vrai et que le format source est dynamodb_json. Pour plus de détails, voir Mappage des types DynamoDB aux types Oracle NoSQL .
• Obligatoire (O/N) : O, si defaultSchema est vrai et que la source est dynamodb_json.
• Exemple : "DDBPartitionKey" : "PersonID:INTEGER"

  Note :

  Si la clé de partition contient dash(-) ou dot(.), Migrator la remplace par le trait de soulignement(_), car le nom de la colonne NoSQL ne prend pas en charge les points et les tirets.

schemaInfo.DDBSortKey

• Objet : Spécifie 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'importation 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 partitionnée de la clé primaire dans la table de base de données NoSQL. Cela s'applique uniquement lorsque defaultSchema est réglé à Vrai et que la source est dynamodb_json. Pour plus de détails, voir Mappage des types DynamoDB aux types Oracle NoSQL .
• Obligatoire (O/N) : N
• Exemple : "DDBSortKey" : "Skey:STRING"

  Note :

  Si la clé de tri contient un tiret (-) ou un point (-), l'outil de migration le remplacera par un trait de soulignement (_), car le nom de la colonne NoSQL ne prend pas en charge le point et le tiret.

remplacer

• Objet : Indique le comportement de NoSQL Database Migrator lorsque l'enregistrement en cours de migration à partir de la source est déjà présent dans l'évier.

  Si la valeur est réglée à Faux, lors de la migration des tables, NoSQL Database Migrator ignore les enregistrements pour lesquels la même clé primaire existe déjà dans l'évier.

  Si la valeur est réglée à Vrai, lors de la migration des tables, NoSQL Database Migrator remplace les enregistrements pour lesquels la même clé primaire existe déjà dans l'évier.

  Si elle n'est pas spécifiée, la valeur par défaut est Vrai.

• Type de données : boolean
• Obligatoire (O/N) : N
• Exemple : "overwrite" : false

Service Oracle NoSQL Database Cloud

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

Modèle de configuration des éviers

"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

  Utilisez "type" : "nosqldb_cloud"

• point d'extrémité
  Exemple :

  • ID région : "endpoint" : "us-ashburn-1"

  • Format d'URL : "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• credentials
  Exemple :

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Exemple :

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Exemple : "useInstancePrincipal" : true

• useDelegationToken

  Exemple : "useDelegationToken" : true

  Note :

  L'authentification avec jeton de délégation n'est prise en charge que lorsque l'outil de migration de bases de données NoSQL s'exécute à partir d'un 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
• remplacer

table

• Objet : Spécifie le nom de la table pour stocker les 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 l'évier pour demander à NoSQL Database Migrator de créer la table.

  Le schéma de cette table doit correspondre aux données sources.

• Type de données : chaîne
• Obligatoire (O/N) : O
• Exemple :
  • Pour spécifier une table "table" : "mytable"
  • Pour spécifier une table enfant "table" : "mytable.child"

    Note :

    Vous pouvez migrer les tables enfants d'une source de données valide vers Oracle NoSQL Database Cloud Service. NoSQL Database Migrator copie une seule table dans chaque exécution. Assurez-vous que la table parent est migrée avant la table enfant.

compartiment

• Objet : Spécifie le nom ou l'OCID du compartiment dans lequel réside la table.

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

  Vous pouvez trouver l'OCID de votre compartiment dans la fenêtre Explorateur de compartiments sous Gouvernance dans la console OCI Cloud.

• Type de données : chaîne
• Obligatoire (O/N) : O, si la table n'est pas dans le compartiment racine de la location OU lorsque le paramètre useInstancePrincipal est réglé à Vrai.

  Note :

  Si le paramètre useInstancePrincipal est réglé à Vrai, le compartiment doit spécifier l'OCID du compartiment et non le nom.
• Exemple :

  • Nom du compartiment

    "compartment" : "mycompartment"

  • Nom de compartiment qualifié avec son compartiment parent

    "compartment" : "parent.childcompartment"

  • Aucune valeur fournie. Par défaut, il s'agit du compartiment racine.

    "compartment": ""

  • OCID du compartiment.

    "compartment" : "ocid1.tenancy.oc1...4ksd"

includeTTL

• Objet : Indique s'il faut inclure ou non les métadonnées de durée de vie pour les rangées de table fournies par la source lors de l'importation 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 rangées de table fournies par la source lors de l'importation de tables Oracle NoSQL Database.

  Si ce paramètre est réglé à Vrai, l'outil NoSQL Database Migrator effectue les vérifications suivantes sur les métadonnées de durée de vie lors de l'importation d'une rangée de table :

  • Si vous importez une rangée qui n'a pas de définition _metadata, l'outil NoSQL Database Migrator règle la durée de vie à 0, ce qui signifie que la rangée n'expire jamais.
  • Si vous importez une rangée 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 rangée est importée. Si la ligne a déjà expiré par rapport à l'heure de référence, elle est ignorée. Si l'enregistrement n'a pas expiré, il est importé avec la valeur de durée de vie. Par défaut, l'heure de référence de l'opération d'importation est l'heure courante en millisecondes, obtenue à partir de System.currentTimeMillis(), de l'ordinateur sur lequel l'outil NoSQL Database Migrator est exécuté. Mais vous pouvez également définir une heure de référence personnalisée à l'aide du paramètre de configuration ttlRelativeDate si vous souhaitez prolonger l'heure d'expiration et importer des rangées qui, autrement, expireront immédiatement.
    La formule utilisée pour 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.

    Note :

    Comme les limites de durée de vie d'Oracle NoSQL sont en heures et en jours, dans certains cas, la durée de vie de la rangée importée peut être ajustée à l'heure ou au jour le plus proche. Par exemple, considérez une rangée 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 rangée n'a pas expiré par rapport à l'heure de référence lors de l'importation de ces données, la nouvelle durée de vie de la rangée est 1629712800000 (2021-08-23 10:00:00).
• Type de données : boolean
• Obligatoire (O/N) : N
• Exemple : "includeTTL" : true

ttlRelativeDate

• Objet : Spécifiez une date UTC dans le format AAAA-MM-JJ hh:mm:ss utilisé pour définir l'expiration de durée de vie des rangées de table lors de l'importation dans Oracle NoSQL Database.

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

  Si vous ne spécifiez pas ce paramètre, il prend par défaut l'heure courante 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"

  Considérons un scénario où 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 rangées 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 courante). Mais si vous voulez prolonger la date d'expiration des rangées 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 souhaitez prolonger de cinq jours le délai d'expiration des rangées de la table, réglez la valeur des paramètres de configuration ttlRelativeDate à 3-janv.-2021, qui est utilisée comme heure de référence lors de l'importation des rangées de la table.

schemaInfo

• Objet : Spécifie le schéma pour les données en cours de migration.

  Si vous ne spécifiez 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 l'évier, la migration échoue.

• Type de données : Objet
• Obligatoire (O/N) : N

schemaInfo.schemaPath

• Objet : Spécifie le chemin absolu vers un fichier contenant des énoncés LDD pour la table NoSQL.

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

  NoSQL Database Migrator ne prend pas en charge plus d'un énoncé LDD par ligne dans le fichier schemaPath.

• Type de données : chaîne

• Obligatoire (O/N) : N

  Note :

  defaultSchema et schemaPath s'excluent mutuellement.

• Exemple : "schemaPath" : "/home/user/schema_file"

schemaInfo.defaultSchema

• Objet : Le réglage de ce paramètre à Oui indique à NoSQL Database Migrator de créer une table avec un schéma par défaut. Le schéma par défaut est défini par l'outil de migration lui-même. Pour plus d'informations sur les définitions de schéma par défaut, voir Schéma par défaut dans Utilisation d'Oracle NoSQL Data Migrator.

• Type de données : boolean

• Obligatoire (O/N) : N

  Note :

  defaultSchema et schemaPath s'excluent mutuellement.

schemaInfo.useSourceSchema

• Objet : Indique si l'émetteur 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 : boolean

• Obligatoire (O/N) : N

  Note :

  Les paramètres defaultSchema, schemaPath et useSourceSchema s'excluent mutuellement. Spécifiez seulement un de ces paramètres.
• Exemple :
  • Avec 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

• Objet : Spécifie la clé de partition DynamoDB et le type Oracle NoSQL Database correspondant à utiliser dans la table Oracle NoSQL Database de l'émetteur. Cette clé sera utilisée comme clé de partition de table de base de données NoSQL. Cela s'applique uniquement lorsque defaultSchema est réglé à Vrai et que le format source est dynamodb_json. Pour plus de détails, voir Mappage des types DynamoDB aux types Oracle NoSQL .
• Obligatoire (O/N) : O, si defaultSchema est vrai et que la source est dynamodb_json.
• Exemple : "DDBPartitionKey" : "PersonID:INTEGER"

  Note :

  Si la clé de partition contient dash(-) ou dot(.), Migrator la remplace par le trait de soulignement(_), car le nom de la colonne NoSQL ne prend pas en charge les points et les tirets.

schemaInfo.DDBSortKey

• Objet : Spécifie 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'importation 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 partitionnée de la clé primaire dans la table de base de données NoSQL. Cela s'applique uniquement lorsque defaultSchema est réglé à Vrai et que la source est dynamodb_json. Pour plus de détails, voir Mappage des types DynamoDB aux types Oracle NoSQL .
• Obligatoire (O/N) : N
• Exemple : "DDBSortKey" : "Skey:STRING"

  Note :

  Si la clé de tri contient un tiret (-) ou un point (-), l'outil de migration le remplacera par un trait de soulignement (_), car le nom de la colonne NoSQL ne prend pas en charge le point et le tiret.

schemaInfo.onDemandThroughput

• Objet : Indique de créer la table avec un débit de lecture et d'écriture sur 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.

  Note :

  Ce paramètre ne s'applique pas aux tables enfants car elles partagent le débit de la table parent de niveau supérieur.

• Type de données : Boolean

• Obligatoire (O/N) : N

• Exemple : "onDemandThroughput" : "true"

schemaInfo.readUnits

• Objet : Indique le débit de lecture de la nouvelle table.

  Note :

  • Ce paramètre ne s'applique pas aux tables provisionnées avec une capacité sur demande.
  • Ce paramètre ne s'applique pas aux tables enfants 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 réglé à false, sinon N.

• Exemple : "readUnits" : 100

schemaInfo.writeUnits

• Objet : Indique le débit d'écriture de la nouvelle table.

  Note :

  • Ce paramètre ne s'applique pas aux tables provisionnées avec une capacité sur demande.
  • Ce paramètre ne s'applique pas aux tables enfants 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 réglé à false, sinon N.

• Exemple : "writeUnits" : 100

schemaInfo.storageSize

• Objet : Spécifie la taille de stockage de la nouvelle table en Go.

  Note :

  Ce paramètre ne s'applique pas aux tables enfants, 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.

• 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

• Objet : Spécifie le pourcentage d'unités d'écriture de table à utiliser pendant l'activité de migration. Le temps nécessaire à la migration des données est directement proportionnel à cet attribut.

  La valeur par défaut est 90. L'intervalle valide est un entier compris entre 1 et 100.

  Voir Dépannage de l'outil de migration d'Oracle NoSQL Database pour savoir comment utiliser cet attribut pour améliorer la vitesse de migration des données.

• Type de données : entier
• Obligatoire (O/N) : N
• Exemple : "writeUnitsPercent" : 90

remplacer

• Objet : Indique le comportement de NoSQL Database Migrator lorsque l'enregistrement en cours de migration à partir de la source est déjà présent dans l'évier.

  Si la valeur est réglée à Faux, lors de la migration des tables, NoSQL Database Migrator ignore les enregistrements pour lesquels la même clé primaire existe déjà dans l'évier.

  Si la valeur est réglée à Vrai, lors de la migration des tables, NoSQL Database Migrator remplace les enregistrements pour lesquels la même clé primaire existe déjà dans l'évier.

  Si elle n'est pas spécifiée, la valeur par défaut est Vrai.

• Type de données : boolean
• Obligatoire (O/N) : N
• Exemple : "overwrite" : false

Modèles de configuration de transformation

Cette rubrique décrit les paramètres de configuration des différentes transformations prises en charge par l'outil de migration d'Oracle NoSQL Database. Pour obtenir le modèle de fichier de configuration complet, voir Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Migrateur Oracle NoSQL Database 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 en une seule migration. Dans un tel cas, l'ordre des transformations est vital car les données sources subissent chaque transformation dans l'ordre donné. La sortie d'une transformation devient l'entrée de la suivante dans le pipeline de migration.

Les différentes transformations prises en charge par l'outil de migration de données NoSQL sont les suivantes :

Table - Transformations

Attribut de config de transformation	Vous pouvez utiliser cette transformation pour...
ignoreFields	Ignorez les colonnes identifiées de la rangée source avant d'écrire dans l'évier.
includeFields	Incluez les colonnes identifiées de la rangée source avant d'écrire dans l'évier.
renameFields	Renommez les colonnes identifiées de la rangée source avant d'écrire dans l'évier.
aggregateFields	Agréger plusieurs colonnes de la source en une seule colonne dans l'évier. 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 affiché ci-dessous.

Modèle de configuration de transformation

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

Paramètre de transformation

ignoreFields

• Objet : Tableau des noms de colonne à ignorer dans les enregistrements sources.

  Note :

  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) : O

• Exemple : Pour ignorer les colonnes nommées "nom" et "adresse" de l'enregistrement source :

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

includeFields

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

Modèle de configuration de transformation

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

Paramètre de transformation

includeFields

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

  Note :

  L'outil NoSQL Database Migrator génère une erreur si vous spécifiez un tableau vide. De plus, vous ne pouvez spécifier que les champs de niveau supérieur. L'outil NoSQL Database Migrator n'applique pas de transformations aux données des champs imbriqués.
• Type de données : Tableau de chaînes
• Obligatoire (O/N) : O

• 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 affiché ci-dessous.

Modèle de configuration de transformation

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

Paramètre de transformation

renameFields

• Objet : Paires clé-valeur des anciens et nouveaux noms des colonnes à renommer.

  Note :

  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) : O

• Exemple : Pour renommer la colonne nommée "résidence" en "adresse" 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 affiché ci-dessous.

Modèle de configuration de transformation

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

Paramètre de transformation

aggregateFields

• Objet : Nom du champ agrégé dans l'évier.

• Type de données : chaîne
• Obligatoire (O/N) : O

• Exemple : Si l'enregistrement indiqué 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 de l'évier se présente comme suit :

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

Mappage des types DynamoDB aux types Oracle NoSQL

Le tableau ci-dessous présente le mappage des types DynamoDB aux types Oracle NoSQL.

Table - Mappage du type DynamoDB au type Oracle NoSQL

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

Peu de points supplémentaires à prendre en compte lors du mappage des types DynamoDB aux types Oracle NoSQL :

• DynamoDB Prend en charge un seul type de données pour Numbers et peut comporter jusqu'à 38 chiffres de précision. En revanche, Oracle NoSQL prend en charge de nombreux types à choisir en fonction de l'intervalle et de la précision de data.You peut sélectionner le type de numéro approprié qui correspond à l'intervalle de vos données d'entrée. Si vous n'êtes pas sûr de la nature des données, le type NoSQL NUMBER peut être utilisé.
• DynamoDB Prend en charge un seul type de données pour Numbers et peut comporter jusqu'à 38 chiffres de précision. En revanche, Oracle NoSQL prend en charge de nombreux types à choisir en fonction de l'intervalle et de la précision de data.You peut sélectionner le type de numéro approprié qui correspond à l'intervalle de vos données d'entrée. Si vous n'êtes pas sûr de la nature des données, le type NoSQL NUMBER peut être utilisé.
• La clé de partition dans DynamoDB a une limite de 2048 octets, mais Oracle NoSQL Cloud Service a une limite de 64 octets pour la clé primaire/clé de partition.
• La clé de tri dans DynamoDB a une limite de 1024 octets, mais Oracle NoSQL Cloud Service a une limite de 64 octets pour la clé primaire.
• Les noms d'attribut dans DynamoDB peuvent avoir une longueur de 64 Ko, mais les noms de colonne du service Oracle NoSQL Cloud ont une limite de 64 caractères.

Mappage de types de données Oracle NoSQL et Parquet

Décrit le mappage des types de données Oracle NoSQL aux 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
TABLEAU field_name (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 la clé T = Type N = Nulable ou non	group field_name { ni == true ? optional Ti ki : required Ti ki }
JSON	BINAIRE (CHAÎNE) ou BINARY(JSON), si JSON logique est configuré

Note :

Lorsque le type de numéro NoSQL est converti en type Double Parquet, il peut y avoir une perte de précision au 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.

Mappage de la table DynamoDB à la table Oracle NoSQL

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

DynamoDB prend en charge deux types de clé primaire :

• Clé de partition - Clé primaire simple, composée d'un attribut appelé clé de partition. DynamoDB utilise la valeur de la clé de partition 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é.
• 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 deuxième est la clé de tri. DynamoDB utilise la valeur de clé de partition 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 Oracle NoSQL 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 :

1. Modélisation de la table DynamoDB en tant que document JSON (recommandé) : Dans cette modélisation, vous mappez tous les attributs des tables de base de données Dynamo dans une colonne JSON de la table NoSQL à l'exception de la clé de partition et de la clé de tri. Vous modéliserez la clé de partition et la clé de tri en tant que colonnes de clé primaire de la table NoSQL. Vous utiliserez la transformation AggregateFields pour agréger les données de clé non principale dans une colonne JSON.

   Note :

   L'outil de migration fournit une configuration conviviale defaultSchema pour créer automatiquement une table LDD sans schéma qui regroupe également les attributs dans une colonne JSON.
2. 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 spécifié dans le mappage des types DynamoDB aux types Oracle NoSQL. Vous modéliserez la clé de partition et trierez les attributs de clé en tant que clé(s) principale(s). Cette option ne doit être utilisée que lorsque vous êtes certain que l'importation du schéma de table DynamoDB est corrigée et que chaque élément a des valeurs pour la plupart des attributs. Si les articles DynamoDB n'ont pas d'attributs communs, cela peut entraîner un grand nombre de colonnes NoSQL avec des valeurs vides.

   Note :

   Il est fortement recommandé d'utiliser des tables sans schéma lors de la migration des 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 grandes tables où le contenu de chaque enregistrement peut ne pas être uniforme dans l'ensemble de la table.

Dépannage d'Oracle NoSQL Database Migrator

Découvrez les défis généraux auxquels vous pouvez faire face lors de l'utilisation de la , et comment les résoudre.

Échec de la migration. Comment résoudre cette erreur?

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 migration

Error Message	Signification	Résolution et
Failed to connect to Oracle NoSQL Database	L'outil de migration 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 magasin sécurisé, vérifiez si le fichier de sécurité est valide avec les valeurs correctes de nom d'utilisateur et de mot de passe.
Failed to connect to Oracle NoSQL Database Cloud Service	L'outil de migration n'a pas pu établir de connexion avec Oracle NoSQL Database Cloud Service.	Vérifiez si l'URL du point d'extrémité ou le nom de région spécifié dans le fichier JSON de configuration est correct. Vérifiez si le fichier de données d'identification OCI est disponible dans le chemin spécifié dans le fichier JSON de configuration. Assurez-vous que les données d'identification OCI fournies dans les données 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 la table est créée dans un espace de noms non par défaut. Vérifiez si 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 spécifié dans le fichier JSON de configuration et assurez-vous que vous disposez de l'autorisation requise pour accéder à la table. Pour le puits : 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 au moyen de la migration.
DDL Execution failed	Les commandes LDD fournies dans le fichier de définition du schéma d'entrée ne sont pas valides.	Vérifiez la syntaxe des commandes LDD dans le fichier schemaPath. Assurez-vous qu'il n'y a qu'un seul énoncé LDD 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 de l'évier.	Vérifiez si les types de données et les noms de colonne spécifiés dans la table d'évier cible correspondent au schéma de la table d'évier. Si vous avez appliqué une transformation, vérifiez si les enregistrements transformés correspondent au schéma de la table source.
Request timeout	L'opération de la source ou du puits n'a pas été terminée dans le délai prévu.	Vérifiez la connexion réseau. Vérifiez si la base de données NoSQL est active. Essayez d'augmenter la valeur requestTimeout dans le fichier de configuration JSON.

Que dois-je considérer avant de redémarrer une migration en échec?

Lorsqu'une tâche de migration de données échoue, le puits se trouve à un état intermédiaire contenant les données importées jusqu'au point de défaillance. 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 n'y a aucun moyen de vérifier et de redémarrer la migration à partir du point de défaillance. Par conséquent, NoSQL Database Migrator remplace tout enregistrement qui a déjà été migré vers l'évier.

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

Le temps nécessaire pour la migration de données dépend de plusieurs facteurs tels que le volume de données à migrer, la vitesse du réseau, la charge courante de la base de données. Dans le cas d'un service en nuage, 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 de travail courante dans Oracle NoSQL Database lors de la migration des données.
• Assurez-vous que la machine qui exécute la migration, la source et le puits 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 de lecture/écriture élevé et vérifiez si le stockage affecté à la table est suffisant ou non. Si NoSQL Database Migrator ne crée pas la table, vous pouvez augmenter le débit d'écriture. Si l'outil de migration crée la table, envisagez de spécifier une valeur supérieure pour le paramètre schemaInfo.writeUnits dans la configuration de l'évier. 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. Voir Limites du nuage et Modèles de configuration de noeud.

J'ai une migration de longue date impliquant d'énormes ensembles de données. Comment suivre la progression de la migration?

Vous pouvez activer une journalisation supplémentaire pour suivre la progression d'une migration de longue durée. 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 l'ensemble NoSQL Database Migrator et disponible dans le répertoire où l'outil de migration d'Oracle NoSQL Database 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é. Le réglage du niveau de journal à OFF désactive toutes les informations de journalisation, tandis que le réglage du niveau de journal à ALL fournit les informations de journal complètes. Le niveau de journalisation par défaut est WARNING. Toutes les sorties de journalisation sont configurées pour aller à la console par défaut. Vous pouvez voir des commentaires dans le fichier logging.properties pour connaître chaque niveau de journal.

---

Titre et droits d'auteur

Oracle NoSQL Database Migrator Reference

Copyright ©2022,2024,

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