Riferimento per Oracle NoSQL Database Migrator

Informazioni sui parametri dei modelli di configurazione di origine, sink e trasformazione disponibili per Oracle NoSQL Database Migrator.

Questo articolo contiene i seguenti argomenti:

Parametri

NoSQL Migratore database richiede un file di configurazione in cui definire tutti i parametri per eseguire l'attività di migrazione. Alcuni parametri sono comuni in diverse fonti e lavandini. Questo argomento fornisce un elenco di questi parametri comuni. Per l'elenco di altri parametri univoci per singole origini o sink, vedere le sezioni corrispondenti del modello di configurazione.

Parametri di configurazione comuni

Di seguito sono riportati i parametri di configurazione comuni. Per esempi, vedere le singole sezioni dei modelli di configurazione.

bucket

• Scopo: specifica il nome del bucket di storage degli oggetti OCI, che contiene gli oggetti di origine/sink.

  Assicurarsi che il bucket richiesto esista già nell'istanza di OCI Object Storage e disponga delle autorizzazioni di lettura/scrittura.

• Tipo di dati: string
• Obbligatorio (S/N): Y

chunkSize

• Scopo: specifica la dimensione massima di un chunk di dati di tabella da memorizzare nel sink. Il valore è in MB. Durante la migrazione, una tabella viene suddivisa in chunk chunkSize e ogni chunk viene scritto come file separato nel sink. Viene creato un nuovo file quando i dati di origine di cui viene eseguita la migrazione superano il valore chunkSize.

  Se non specificato, il valore predefinito è 32 MB. Il valore valido è un numero intero compreso tra 1 e 1024.

• Tipo di dati: intero
• Obbligatorio (S/N): N

credenziali

• Scopo: specifica il percorso assoluto di un file contenente le credenziali OCI. NoSQL Migrator di database utilizza questo file per connettersi al servizio OCI, ad esempio Oracle NoSQL Database Cloud Service, OCI Object Storage e così via.

  Il valore predefinito è $HOME/.oci/config

  Per un esempio del file delle credenziali, vedere Configurazione di esempio.

  Nota

  I parametri di autenticazione credentials, useInstancePrincipal e useDelegationToken si escludono a vicenda. Specificare solo uno di questi parametri nel modello di configurazione.
• Tipo di dati: string
• Obbligatorio (S/N): N

credentialsProfile

• Scopo: specifica il nome del profilo di configurazione da utilizzare per connettersi al servizio OCI, ad esempio Oracle NoSQL Database Cloud Service, OCI Object Storage e così via. Le credenziali dell'account utente vengono definite profilo.

  Se questo valore non viene specificato, NoSQL Database Migrator utilizza il profilo DEFAULT.

  Nota

  Questo parametro è valido solo se è specificato il parametro credentials.
• Tipo di dati: string
• Obbligatorio (S/N): N

endpoint

• Scopo: specifica una delle seguenti opzioni:
  • URL dell'endpoint del servizio o ID dell'area per il servizio di storage degli oggetti OCI.

    Per la lista degli endpoint del servizio di storage degli oggetti OCI, vedere Endpoint di storage degli oggetti.

  • URL dell'endpoint del servizio o ID area per Oracle NoSQL Database Cloud Service.

    È possibile specificare solo l'URL completo o l'ID area. Per la lista delle aree dati supportate per Oracle NoSQL Database Cloud Service, vedere Aree dati e URL dei servizi associati nel documento Oracle NoSQL Database Cloud Service.

• Tipo di dati: string
• Obbligatorio (S/N): Y

format

• Scopo: specifica il formato origine/sink.
• Tipo di dati: string
• Obbligatorio (S/N): Y

spazio di nomi

• Scopo: specifica lo spazio di nomi del servizio OCI Object Storage. Questo è un parametro facoltativo. Se non si specifica questo parametro, viene utilizzato lo spazio di nomi predefinito della tenancy.

• Tipo di dati: string
• Obbligatorio (S/N): N

prefisso

• Scopo: il prefisso funge da contenitore logico o directory per la memorizzazione dei dati nel bucket di storage degli oggetti OCI.

  • Modello di configurazione di origine: se il parametro prefix specificato, viene eseguita la migrazione di tutti gli oggetti della directory denominata nel parametro prefix. In caso contrario, viene eseguita la migrazione di tutti gli oggetti presenti nel bucket.
  • Modello di configurazione del lavandino: se si specifica il parametro prefix, nel bucket viene creata una directory con il prefisso specificato e gli oggetti vengono migrati in questa directory. In caso contrario, come prefisso viene utilizzato il nome della tabella dell'origine. Se un oggetto con lo stesso nome esiste già nel bucket, viene sovrascritto.

  Per ulteriori informazioni sui prefissi, vedere Denominazione degli oggetti mediante prefissi e gerarchie.

• Tipo di dati: string
• Obbligatorio (S/N): N

requestTimeoutMs

• Scopo: specifica il tempo di attesa per il completamento di ogni operazione di lettura/scrittura da/verso il negozio. Viene fornito in millisecondi. Il valore predefinito è 5000. Il valore può essere qualsiasi numero intero positivo.

• Tipo di dati: intero
• Obbligatorio (S/N): N

security

• Scopo: specifica il percorso assoluto del file di login di sicurezza che contiene le credenziali dell'area di memorizzazione se l'area di memorizzazione è un'area di memorizzazione sicura. Per ulteriori informazioni sul file di login di sicurezza, vedere Configuring Security with Remote Access in Administrator's Guide.

  È possibile utilizzare l'autenticazione basata su password file o su wallet. Tuttavia, l'autenticazione basata su wallet è supportata solo nella Enterprise Edition (EE) di Oracle NoSQL Database. Per ulteriori informazioni sull'autenticazione basata su wallet, vedere Sicurezza di origine e lavandino.

  L'edizione Community Edition(CE) supporta solo l'autenticazione basata su password file.

• Tipo di dati: stringa
• Obbligatorio (S/N): S, per un negozio sicuro

type

• Scopo: identifica il tipo di origine/dissipatore.
• Tipo di dati: string
• Obbligatorio (S/N): Y

useDelegationToken

• Scopo: specifica se lo strumento NoSQL Migrator database utilizza l'autenticazione di un token di delega per connettersi ai servizi OCI. È necessario utilizzare l'autenticazione del token di delega per eseguire la utility Migrator da Cloud Shell. Il token di delega viene creato automaticamente per l'utente quando viene richiamata Cloud Shell.

  Il valore predefinito è false.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

  Nota

  • L'autenticazione con token di delega è supportata solo quando lo strumento NoSQL Migrator database è in esecuzione da una Cloud Shell.
  • I parametri di autenticazione credentials, useInstancePrincipal e useDelegationToken si escludono a vicenda. Specificare solo uno di questi parametri nel modello di configurazione.
  • Cloud Shell supporta la migrazione solo tra le origini e i sink seguenti:

    Type	Origine valida	Lavello valido
    Oracle NoSQL Database Cloud Service (nosqldb_cloud)	Y	Y
    File (file JSON nella directory home)	Y	Y
    Memorizzazione degli oggetti OCI (file JSON) (object_storage_oci)	Y	Y
    Memorizzazione degli oggetti OCI (file Parquet) (object_storage_oci)	N	Y

useInstancePrincipal

• Scopo: specifica se lo strumento NoSQL Migrator database utilizza l'autenticazione del principal dell'istanza per connettersi al servizio OCI, ad esempio Oracle NoSQL Database Cloud Service, OCI Object Storage e così via. Per ulteriori informazioni sul metodo di autenticazione del principal dell'istanza, vedere Sicurezza di origine e lavandino.

  Il valore predefinito è false.

  Nota

  • L'autenticazione con principal delle istanze è supportata solo quando lo strumento NoSQL Migrator di database è in esecuzione all'interno di un'istanza di computazione OCI, ad esempio lo strumento NoSQL Migrator di database in esecuzione in una VM ospitata su OCI.
  • I parametri di autenticazione credentials, useInstancePrincipal e useDelegationToken si escludono a vicenda. Specificare solo uno di questi parametri nel modello di configurazione.
• Tipo di dati: booleano
• Obbligatorio (S/N): N

Modelli di configurazione di origine

Informazioni sui formati dei file di configurazione di origine per ogni origine valida e sullo scopo di ogni parametro di configurazione.

Per il modello di file di configurazione, vedere File di configurazione in Terminologia utilizzata con NoSQL Data Migrator.

Per i dettagli sui formati sink validi per ciascuna origine, vedere Modelli di configurazione sink.

Argomenti

Negli argomenti riportati di seguito vengono descritti i modelli di configurazione di origine a cui fa riferimento Oracle NoSQL Database Migrator per copiare i dati dall'origine specificata in un sink valido.

• Origine file JSON

  File o directory specificata contenente i dati JSON.

• File JSON nel bucket di storage degli oggetti OCI

  File JSON specificato nel bucket di OCI Object Storage.

• MongoDB: file JSON formattato

  File o directory specificata contenente i dati JSON in formato MongoDB.

• MongoDB: file JSON formattato nel bucket di storage degli oggetti OCI

  File JSON esportato MongoDB specificato memorizzato nel bucket di OCI Object Storage.

• DynamoDB: file JSON formattato memorizzato in AWS S3

  Specificato file JSON esportato DynamoDB memorizzato nello storage AWS S3.

• DynamoDB: file JSON formattato

  Il file JSON esportato DynamoDB specificato da un file system.

• Oracle NoSQL Database

  Tabella specificata in Oracle NoSQL Database.

• Oracle NoSQL Database Cloud Service

  Tabella specificata in Oracle NoSQL Database Cloud Service.

• Origine file CSV

  File o directory specificata contenente i dati CSV.

• File CSV nel bucket di storage degli oggetti OCI

  File CSV specificato nel bucket di storage degli oggetti OCI.

Origine file JSON

Di seguito è riportato il formato del file di configurazione per il file JSON come origine di NoSQL Database Migrator.

È possibile eseguire la migrazione di un file di origine JSON specificando il percorso del file o una directory nel modello di configurazione di origine.

Un file di origine JSON di esempio è il seguente:

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

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "file"

• formato

  Usa "format" : "json"

Parametri di configurazione univoci

• dataPath
• schemaInfo
• schemaInfo.schemaPath

dataPath

• Scopo: specifica il percorso assoluto di un file o di una directory contenente i dati JSON per la migrazione.

  Assicurarsi che questi dati corrispondano allo schema di tabella NoSQL definito nel sink. Se si specifica una directory, NoSQL Database Migrator identifica tutti i file con l'estensione .json in tale directory per la migrazione. Le sottodirectory non sono supportate.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

  • Specifica di un file JSON

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

  • Come specificare una directory

    "dataPath" : "/home/user"

schemaInfo

• Scopo: specifica lo schema dei dati di origine di cui viene eseguita la migrazione. Questo schema viene passato al sink NoSQL.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

schemaInfo.schemaPath

• Scopo: specifica il percorso assoluto del file di definizione dello schema contenente le istruzioni DDL per la tabella NoSQL di cui viene eseguita la migrazione.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

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

File JSON nel bucket di storage degli oggetti OCI

Di seguito è riportato il formato del file di configurazione per il file JSON nel bucket di storage degli oggetti OCI come origine di NoSQL Database Migrator.

Puoi eseguire la migrazione di un file JSON nel bucket di storage degli oggetti OCI specificando il nome del bucket nel modello di configurazione di origine.

Un file di origine JSON di esempio nel bucket di storage degli oggetti OCI è il seguente:

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

Nota

I tipi di sink validi per il tipo di origine dello storage degli oggetti OCI sono nosqldb e nosqldb_cloud.

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "object_storage_oci"

• formato

  Usa "format" : "json"

• endpoint
  Esempio:

  • ID area: "endpoint" : "us-ashburn-1"

  • Formato URL: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• spazio di nomi

  Esempio: "namespace" : "my-namespace"

• bucket

  Esempio: "bucket" : "my-bucket"

• prefisso
  Esempio:

  1. "prefix" : "my_table/Data/000000.json" (migra solo 000000.json)
  2. "prefix" : "my_table/Data" (migra tutti gli oggetti con prefisso my_table/Data)
• credenziali
  Esempio:

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

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

  Esempio: "useInstancePrincipal" : true

• useDelegationToken

  Esempio: "useDelegationToken" : true

  Nota

  L'autenticazione con token di delega è supportata solo quando NoSQL Database Migrator è in esecuzione da una Cloud Shell.

Parametri di configurazione univoci

• schemaInfo
• schemaInfo.schemaObject

schemaInfo

• Scopo: specifica lo schema dei dati di origine di cui viene eseguita la migrazione. Questo schema viene passato al sink NoSQL.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

schemaInfo.schemaObject

• Scopo: specifica il nome dell'oggetto nel bucket in cui vengono memorizzate le definizioni dello schema tabella NoSQL per i dati di cui viene eseguita la migrazione.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

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

MongoDB: file JSON formattato

Di seguito è riportato il formato del file di configurazione per il file JSON in formato MongoDB come origine di NoSQL Database Migrator.

È possibile eseguire la migrazione dei dati JSON esportati MongoDB specificando il file o la directory nel modello di configurazione di origine.

MongoDB supporta due tipi di estensioni per il formato JSON dei file, la modalità canonica e la modalità rilassata. È possibile fornire il file JSON in formato MongoDB generato utilizzando lo strumento mongoexport in modalità Canonica o Rilassata. Entrambe le modalità sono supportate da NoSQL Database Migrator per la migrazione.

Per ulteriori informazioni sul file MongoDB Extended JSON (v2), vedere mongoexport_formats.

Per ulteriori informazioni sulla generazione del file JSON in formato MongoDB, vedere mongoexport per ulteriori informazioni.

Un file JSON di esempio in MongoDB formato modalità Rilassata è il seguente:

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

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "file"

• formato

  Utilizzare "format" : "mongodb_json"

Parametri di configurazione univoci

• dataPath
• schemaInfo
• schemaInfo.schemaPath

dataPath

• Scopo: specifica il percorso assoluto di un file o di una directory contenente i dati JSON esportati MongoDB per la migrazione.

  È possibile fornire il file JSON in formato MongoDB generato utilizzando lo strumento mongoexport.

  Se si specifica una directory, NoSQL Database Migrator identifica tutti i file con l'estensione .json in tale directory per la migrazione. Le sottodirectory non sono supportate. Assicurarsi che questi dati corrispondano allo schema di tabella NoSQL definito nel sink.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

  • Specifica di un file JSON in formato MongoDB

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

  • Come specificare una directory

    "dataPath" : "/home/user"

schemaInfo

• Scopo: specifica lo schema dei dati di origine di cui viene eseguita la migrazione. Questo schema viene passato al sink NoSQL.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

schemaInfo.schemaPath

• Scopo: specifica il percorso assoluto del file di definizione dello schema contenente le istruzioni DDL per la tabella NoSQL di cui viene eseguita la migrazione.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

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

MongoDB: file JSON formattato nel bucket di storage degli oggetti OCI

Il formato del file di configurazione per il file JSON MongoDB formattato nel bucket di storage degli oggetti OCI come origine di NoSQL Database Migrator è mostrato di seguito.

Puoi eseguire la migrazione dei dati JSON esportati MongoDB nel bucket di storage degli oggetti OCI specificando il nome del bucket nel modello di configurazione di origine.

Estrarre i dati da MongoDB utilizzando la utility mongoexport e caricarli nel bucket di storage degli oggetti OCI. Vedere mongoexport. MongoDB supporta due tipi di estensioni per il formato JSON dei file, la modalità canonica e la modalità rilassata. Entrambi i formati sono supportati nel bucket di OCI Object Storage.

Un file JSON di esempio in MongoDB formato modalità Rilassata è il seguente:

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

Nota

I tipi di sink validi per il tipo di origine dello storage degli oggetti OCI sono nosqldb e nosqldb_cloud.

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "object_storage_oci"

• formato

  Utilizzare "format" : "mongodb_json"

• endpoint
  Esempio:

  • ID area: "endpoint" : "us-ashburn-1"

  • Formato URL: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• spazio di nomi

  Esempio: "namespace" : "my-namespace"

• bucket

  Esempio: "bucket" : "my-bucket"

• prefisso
  Esempio:

  1. "prefix" : "mongo_export/Data/table.json" (migra solo table.json)
  2. "prefix" : "mongo_export/Data" (migra tutti gli oggetti con prefisso mongo_export/Data)

  Nota

  Se non si specifica alcun valore, viene eseguita la migrazione di tutti gli oggetti presenti nel bucket.
• credenziali
  Esempio:

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

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

  Esempio: "useInstancePrincipal" : true

Parametri di configurazione univoci

• schemaInfo
• schemaInfo.schemaObject

schemaInfo

• Scopo: specifica lo schema dei dati di origine di cui viene eseguita la migrazione. Questo schema viene passato al sink NoSQL.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

schemaInfo.schemaObject

• Scopo: specifica il nome dell'oggetto nel bucket in cui vengono memorizzate le definizioni dello schema tabella NoSQL per i dati di cui viene eseguita la migrazione.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

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

DynamoDB: file JSON formattato memorizzato in AWS S3

Di seguito è riportato il formato del file di configurazione per il file JSON in formato DynamoDB in AWS S3 come origine di NoSQL Database Migrator.

È possibile eseguire la migrazione di un file contenente i dati JSON esportati DynamoDB dallo storage AWS S3 specificando il percorso nel modello di configurazione di origine.

Un file JSON di esempio in formato DynamoDB è il seguente:

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

È necessario esportare la tabella DynamoDB nello storage AWS S3 come specificato in Esportazione dei dati della tabella DynamoDB in Amazon S3.

I tipi di sink validi per JSON in formato DynamoDB memorizzati in AWS S3 sono nosqldb e nosqldb_cloud.

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "aws_s3"

• formato

  Utilizzare "format" : "dynamodb_json"

  Nota

  Se il valore del parametro type è aws_s3, il formato deve essere dynamodb_json.

Parametri di configurazione univoci

• s3URL
• credenziali
• credentialsProfile

s3URL

• Scopo: specifica l'URL di una tabella DynamoDB esportata memorizzata in AWS S3. È possibile ottenere questo URL dalla console AWS S3. Il formato URL valido è https://<bucket-name>.<s3_endpoint>/<prefix>. Durante l'importazione, NoSQL Database Migrator cerca i file json.gz nel prefisso.

  Nota

  È necessario esportare la tabella DynamoDB come specificato in Esportazione dei dati della tabella DynamoDB in Amazon S3.
• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio: https://my-bucket.s3.ap-south-1.amazonaws.com/AWSDynamoDB/01649660790057-14f642be

credenziali

• Scopo: specifica il percorso assoluto di un file contenente le credenziali AWS. Se non specificato, viene utilizzato il valore predefinito $HOME/.aws/credentials. Per ulteriori informazioni sul file delle credenziali, vedere Impostazioni del file delle credenziali e configurazione.
• Tipo di dati: string
• Obbligatorio (S/N): N
• Esempio:

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

  Nota

  NoSQL Migrator database non registra alcuna delle informazioni sulle credenziali. È necessario proteggere correttamente il file delle credenziali da accessi non autorizzati.

credentialsProfile

• Scopo: nome del profilo nel file delle credenziali AWS da utilizzare per la connessione ad AWS S3. Le credenziali dell'account utente vengono definite profilo. Se questo valore non viene specificato, NoSQL Database Migrator utilizza il profilo default. Per ulteriori informazioni sul file delle credenziali, vedere Impostazioni del file delle credenziali e configurazione.
• Tipo di dati: string
• Obbligatorio (S/N): N
• Esempio:

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

DynamoDB: file JSON formattato

Di seguito è riportato il formato del file di configurazione per il file JSON in formato DynamoDB come origine di NoSQL Database Migrator.

È possibile eseguire la migrazione da un file system di un file o di una directory contenente i dati JSON esportati DynamoDB specificando il percorso nel modello di configurazione di origine.

Un file JSON di esempio in formato DynamoDB è il seguente:

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

È necessario copiare i dati della tabella DynamoDB esportati dallo storage AWS S3 in un file system attivato locale.

I tipi di sink validi per il file JSON DynamoDB sono nosqldb e nosqldb_cloud.

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "file"

• formato

  Utilizzare "format" : "dynamodb_json"

Parametro di configurazione univoco

dataPath

• Scopo: specifica il percorso assoluto di un file o di una directory contenente i dati della tabella DynamoDB esportati. È necessario copiare i dati della tabella DynamoDB esportati da AWS S3 in un file system attivato locale. Assicurarsi che questi dati corrispondano allo schema di tabella NoSQL definito nel sink. Se si specifica una directory, NoSQL Database Migrator identifica tutti i file con l'estensione .json.gz in tale directory e la sottodirectory data.
• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:
  • Specifica di un file

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

  • Come specificare una directory

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

Oracle NoSQL Database

Di seguito è riportato il formato del file di configurazione per Oracle NoSQL Database come origine di NoSQL Database Migrator.

È possibile eseguire la migrazione di una tabella da Oracle NoSQL Database specificando il nome della tabella nel modello di configurazione di origine.

Di seguito è riportata una tabella di esempio di Oracle NoSQL Database.

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"teacher"}],"age":25,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"expenses":null}
{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"chef"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"expenses":null}
{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"handyman"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"expenses":null}

Modello di configurazione di origine

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

Parametri origine

Parametro di configurazione comune

• tipo

  Utilizzare "type" : "nosqldb"

• sicurezza

  Esempio:

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

  Esempio di contenuto del file di sicurezza per l'autenticazione basata su password file:

  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)

  Esempio di contenuto del file di sicurezza per l'autenticazione basata su wallet:

  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

  Esempio: "requestTimeoutMs" : 5000

Parametri di configurazione univoci

• storeName
• helperHosts
• tabella
• includeTTL

storeName

• Scopo: nome dell'area di memorizzazione di Oracle NoSQL Database.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio: "storeName" : "kvstore"

helperHosts

• Scopo: lista di coppie di porte host e registro nel formato hostname:port. Delimitare ogni elemento dell'elenco utilizzando una virgola. Specificare almeno un host dell'applicazione di supporto.

• Tipo dati: array di stringhe
• Obbligatorio (S/N): Y
• Esempio: "helperHosts" : ["localhost:5000","localhost:6000"]

Tabella

• Scopo: nome di tabella completamente qualificato da cui eseguire la migrazione dei dati.

  Formato: [namespace_name:]<table_name>

  Se la tabella si trova nello spazio di nomi DEFAULT, è possibile omettere namespace_name. La tabella deve esistere nel negozio.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

  • Con lo spazio di nomi DEFAULT "table" :"mytable"

  • Con uno spazio di nomi non predefinito "table" : "mynamespace:mytable"

  • Per specificare una tabella figlio "table" : "mytable.child"

includeTTL

• Scopo: specifica se includere o meno i metadati TTL per le righe di tabella durante l'esportazione delle tabelle di Oracle NoSQL Database. Se impostato su true, i dati TTL per le righe vengono inclusi anche nei dati forniti dall'origine. TTL è presente nell'oggetto JSON _metadata associato a ogni riga. L'ora di scadenza di ogni riga viene esportata come numero di millisecondi dall'epoca UNIX (1° gennaio 1970).

  Se il parametro non viene specificato, viene utilizzato per impostazione predefinita false.

  Solo le righe con un valore di scadenza positivo per TTL vengono incluse come parte delle righe esportate. Se una riga non scade, ovvero TTL=0, i relativi metadati TTL non vengono inclusi in modo esplicito. Ad esempio, se ROW1 scade alle 2021-10-19 00:00:00 e ROW2 non scade, i dati esportati hanno il seguente aspetto:

  //ROW1
  {
    "id" : 1,
    "name" : "abc",
    "_metadata" : {
      "expiration" : 1634601600000
    }
  }
  
  //ROW2
  {
    "id" : 2,
    "name" : "xyz"
  }

• Tipo di dati: booleano
• Obbligatorio (S/N): N
• esempio: "includeTTL" : true

Oracle NoSQL Database Cloud Service

Di seguito è riportato il formato del file di configurazione per Oracle NoSQL Database Cloud Service come origine di NoSQL Database Migrator.

È possibile eseguire la migrazione di una tabella da Oracle NoSQL Database Cloud Service specificando il nome o l'OCID del compartimento in cui risiede la tabella nel modello di configurazione di origine.

Di seguito è riportata una tabella di esempio di Oracle NoSQL Database Cloud Service.

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"teacher"}],"age":25,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"expenses":null}
{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"chef"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"expenses":null}
{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"handyman"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"expenses":null}

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "nosqldb_cloud"

• endpoint
  Esempio:

  • ID area: "endpoint" : "us-ashburn-1"

  • Formato URL: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• credenziali
  Esempio:

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

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

  Esempio: "useInstancePrincipal" : true

• useDelegationToken

  Esempio: "useDelegationToken" : true

  Nota

  L'autenticazione con token di delega è supportata solo quando NoSQL Database Migrator è in esecuzione da una Cloud Shell.
• requestTimeoutMs

  Esempio: "requestTimeoutMs" : 5000

Parametri di configurazione univoci

• tabella
• compartimento
• readUnitsPercent
• includeTTL

Tabella

• Scopo: nome della tabella da cui eseguire la migrazione dei dati.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:
  • Per specificare una tabella "table" : "myTable"
  • Per specificare una tabella figlio "table" : "mytable.child"

compartimento

• Scopo: specifica il nome o l'OCID del compartimento in cui risiede la tabella.

  Se non si fornisce alcun valore, per impostazione predefinita viene utilizzato il compartimento root.

  Puoi trovare l'OCID del compartimento dalla finestra Explorer compartimenti in Governance nella console cloud OCI.

• Tipo di dati: string
• Obbligatorio (Y/N): Y, se la tabella non si trova nel compartimento radice della tenancy OPPURE quando il parametro useInstancePrincipal è impostato su true.

  Nota

  Se il parametro useInstancePrincipal è impostato su true, il compartimento deve specificare l'OCID del compartimento e non il nome.
• Esempio:

  • Nome compartimento

    "compartment" : "mycompartment"

  • Nome del compartimento qualificato con il relativo compartimento padre

    "compartment" : "parent.childcompartment"

  • Nessun valore fornito. Per impostazione predefinita, viene utilizzato il compartimento radice.

    "compartment": ""

  • OCID compartimento

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

readUnitsPercent

• Scopo: percentuale delle unità di lettura della tabella da utilizzare durante la migrazione della tabella NoSQL.

  Il valore predefinito per il server di amministrazione è 90. L'intervallo valido è qualsiasi numero intero compreso tra 1 e 100. Il tempo necessario per eseguire la migrazione dei dati è direttamente proporzionale a questo attributo. È meglio aumentare il throughput di lettura della tabella per l'attività di migrazione. È possibile ridurre il throughput di lettura al termine del processo di migrazione.

  Per conoscere i limiti giornalieri per le modifiche al throughput, vedere Limiti cloud nel documento Oracle NoSQL Database Cloud Service.

  Per ulteriori informazioni su come utilizzare questo attributo per migliorare la velocità di migrazione dei dati, vedere Risoluzione dei problemi di Oracle NoSQL Database Migrator.

• Tipo di dati: intero
• Obbligatorio (S/N): N
• Esempio: "readUnitsPercent" : 90

includeTTL

• Scopo: specifica se includere o meno i metadati TTL per le righe di tabella durante l'esportazione delle tabelle di Oracle NoSQL Database Cloud Service. Se impostato su true, i dati TTL per le righe vengono inclusi anche nei dati forniti dall'origine. TTL è presente nell'oggetto JSON _metadata associato a ogni riga. L'ora di scadenza di ogni riga viene esportata come numero di millisecondi dall'epoca UNIX (1° gennaio 1970).

  Se il parametro non viene specificato, viene utilizzato per impostazione predefinita false.

  Solo le righe con un valore di scadenza positivo per TTL vengono incluse come parte delle righe esportate. Se una riga non scade, ovvero TTL=0, i relativi metadati TTL non vengono inclusi in modo esplicito. Ad esempio, se ROW1 scade alle 2021-10-19 00:00:00 e ROW2 non scade, i dati esportati hanno il seguente aspetto:

  //ROW1
  {
    "id" : 1,
    "name" : "abc",
    "_metadata" : {
      "expiration" : 1634601600000
    }
  }
  
  //ROW2
  {
    "id" : 2,
    "name" : "xyz"
  }

• Tipo di dati: booleano
• Obbligatorio (S/N): N
• esempio: "includeTTL" : true

Origine file CSV

Di seguito è riportato il formato del file di configurazione per il file CSV come origine di NoSQL Migrator database. Il file CSV deve essere conforme al formato RFC4180.

È possibile eseguire la migrazione di un file CSV o di una directory contenente i dati CSV specificando il nome o la directory del file nel modello di configurazione di origine.

Di seguito è riportato un file CSV di esempio.

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

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "file"

• formato

  Usa "format" : "csv"

Parametri di configurazione univoci

• dataPath

• hasHeader

• colonne

• csvOptions

• csvOptions.encoding

• csvOptions.trim

percorso dati

• Scopo: specifica il percorso assoluto di un file o di una directory contenente i dati CSV per la migrazione. Se si specifica una directory, NoSQL Migrator database importa tutti i file con l'estensione .csv o .CSV in tale directory. Tutti i file CSV vengono copiati in un'unica tabella, ma non in un ordine particolare.

  I file CSV devono essere conformi allo standard RFC4180. Assicurarsi che i dati di ogni file CSV corrispondano allo schema di tabella Database NoSQL definito nella tabella sink. Le sottodirectory non sono supportate.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

  • Specifica di un file CSV

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

  • Come specificare una directory

    "dataPath" : "/home/user"

Nota

I file CSV devono contenere solo valori scalari. L'importazione di file CSV contenenti tipi complessi come MAP, RECORD, ARRAY e JSON non è supportata. Lo strumento NoSQL Migratore database non controlla la correttezza dei dati nel file CSV di input. Lo strumento NoSQL Migratore database supporta l'importazione di dati CSV conformi al formato RFC4180. I file CSV contenenti dati non conformi allo standard RFC4180 potrebbero non essere copiati correttamente o causare un errore. Se i dati di input sono danneggiati, lo strumento NoSQLMigratore database non analizzerà i record CSV. Se si verificano errori durante la migrazione, lo strumento NoSQL Database Migrator registra le informazioni relative ai record di input non riusciti per scopi informativi e di debug. Per ulteriori dettagli, vedere Logging Migrator Progress in Using Oracle NoSQL Data Migrator.

hasHeader

• Scopo: specifica se il file CSV ha o meno un'intestazione. Se questa opzione è impostata su true, la prima riga viene ignorata. Se è impostato su false, la prima riga viene considerata un record CSV. Il valore predefinito è false.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• Esempio: "hasHeader" : "false"

colonne

• Scopo: specifica la lista dei nomi di colonna della tabella NoSQL Database. L'ordine dei nomi delle colonne indica il mapping dei campi file CSV con le corrispondenti colonne della tabella Database NoSQL. Se l'ordine delle colonne del file CSV di input non corrisponde alle colonne della tabella del database NoSQL esistenti o appena create, è possibile mappare l'ordine utilizzando questo parametro. Inoltre, quando si esegue l'importazione in una tabella con una colonna identità, è possibile saltare il nome della colonna identità nel parametro columns.

  Nota

  • Se la tabella Database NoSQL contiene colonne aggiuntive non disponibili nel file CSV, i valori delle colonne mancanti vengono aggiornati con il valore predefinito definito nella tabella Database NoSQL. Se non viene fornito un valore predefinito, durante la migrazione viene inserito un valore nullo. Per ulteriori informazioni sui valori predefiniti, vedere la sezione Definizioni dei tipi di dati nel manuale SQL Reference Guide.
  • Se il file CSV contiene colonne aggiuntive non definite nella tabella Database NoSQL, le informazioni aggiuntive sulle colonne vengono ignorate.
  • Se un valore qualsiasi nel record CSV è vuoto, viene impostato sul valore predefinito delle colonne corrispondenti nella tabella Database NoSQL. Se non viene fornito un valore predefinito, durante la migrazione viene inserito un valore nullo.
• Tipo dati: array di stringhe
• Obbligatorio (S/N): N

• Esempio: "columns" : ["table_column_1", "table_column_2"]

csvOptions

• Scopo: specifica le opzioni di formattazione per un file CSV. Fornire il formato di codifica del set di caratteri del file CSV e scegliere se rimuovere o meno gli spazi vuoti.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

csvOptions.encoding

• Scopo: specifica il set di caratteri per decodificare il file CSV. Il valore predefinito è UTF-8. I set di caratteri supportati sono US-ASCII, ISO-8859-1, UTF-8, e UTF-16.

• Tipo di dati: string
• Obbligatorio (S/N): N

• Esempio: "encoding" : "UTF-8"

csvOptions.trim

• Scopo: specifica se è necessario tagliare gli spazi vuoti iniziali e finali di un valore di campo CSV. Il valore predefinito è false.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• Esempio: "trim" : "true"

File CSV nel bucket di storage degli oggetti OCI

Di seguito è riportato il formato del file di configurazione per il file CSV nel bucket di storage degli oggetti OCI come origine di NoSQL Database Migrator. Il file CSV deve essere conforme al formato RFC4180.

È possibile eseguire la migrazione di un file CSV nel bucket di OCI Object Storage specificando il nome del bucket nel modello di configurazione di origine.

Un file CSV di esempio nel bucket di storage degli oggetti OCI è il seguente:

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

Nota

I tipi di sink validi per il tipo di origine dello storage degli oggetti OCI sono nosqldb e nosqldb_cloud.

Modello di configurazione di origine

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

Parametri origine

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "object_storage_oci"

• formato

  Usa "format" : "csv"

• endpoint
  Esempio:

  • ID area: "endpoint" : "us-ashburn-1"

  • Formato URL: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• spazio di nomi

  Esempio: "namespace" : "my-namespace"

• bucket

  Esempio: "bucket" : "my-bucket"

  Nota

  • NoSQL Database Migrator importa tutti i file con estensione .csv o .CSV in senso object e li copia in una singola tabella nello stesso ordine.

  • I file CSV devono contenere solo valori scalari. L'importazione di file CSV contenenti tipi complessi come MAP, RECORD, ARRAY e JSON non è supportata. Lo strumento NoSQL Migratore database non controlla la correttezza dei dati nel file CSV di input. Lo strumento NoSQL Migratore database supporta l'importazione di dati CSV conformi al formato RFC4180. I file CSV contenenti dati non conformi allo standard RFC4180 potrebbero non essere copiati correttamente o causare un errore. Se i dati di input sono danneggiati, lo strumento NoSQLMigratore database non analizzerà i record CSV. Se si verificano errori durante la migrazione, lo strumento NoSQL Database Migrator registra le informazioni relative ai record di input non riusciti per scopi informativi e di debug. Per ulteriori dettagli, vedere Logging Migrator Progress in Using Oracle NoSQL Data Migrator.

• prefisso
  Esempio:

  1. "prefix" : "my_table/Data/000000.csv" (migra solo 000000.csv)
  2. "prefix" : "my_table/Data" (migra tutti gli oggetti con prefisso my_table/Data)
• credenziali
  Esempio:

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

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

  Esempio: "useInstancePrincipal" : true

Parametri di configurazione univoci

• hasHeader
• colonne
• csvOptions
• csvOptions.encoding
• csvOptions.trim

hasHeader

• Scopo: specifica se il file CSV ha o meno un'intestazione. Se questa opzione è impostata su true, la prima riga viene ignorata. Se è impostato su false, la prima riga viene considerata un record CSV. Il valore predefinito è false.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• Esempio: "hasHeader" : "false"

colonne

• Scopo: specifica la lista dei nomi di colonna della tabella NoSQL Database. L'ordine dei nomi delle colonne indica il mapping dei campi file CSV con le corrispondenti colonne della tabella Database NoSQL. Se l'ordine delle colonne del file CSV di input non corrisponde alle colonne della tabella del database NoSQL esistenti o appena create, è possibile mappare l'ordine utilizzando questo parametro. Inoltre, quando si esegue l'importazione in una tabella con una colonna identità, è possibile saltare il nome della colonna identità nel parametro columns.

  Nota

  • Se la tabella Database NoSQL contiene colonne aggiuntive non disponibili nel file CSV, i valori delle colonne mancanti vengono aggiornati con il valore predefinito definito nella tabella Database NoSQL. Se non viene fornito un valore predefinito, durante la migrazione viene inserito un valore nullo. Per ulteriori informazioni sui valori predefiniti, vedere la sezione Definizioni dei tipi di dati nel manuale SQL Reference Guide.
  • Se il file CSV contiene colonne aggiuntive non definite nella tabella Database NoSQL, le informazioni aggiuntive sulle colonne vengono ignorate.
  • Se un valore qualsiasi nel record CSV è vuoto, viene impostato sul valore predefinito delle colonne corrispondenti nella tabella Database NoSQL. Se non viene fornito un valore predefinito, durante la migrazione viene inserito un valore nullo.
• Tipo dati: array di stringhe
• Obbligatorio (S/N): N

• Esempio: "columns" : ["table_column_1", "table_column_2"]

csvOptions

• Scopo: specifica le opzioni di formattazione per un file CSV. Fornire il formato di codifica del set di caratteri del file CSV e scegliere se rimuovere o meno gli spazi vuoti.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

csvOptions.encoding

• Scopo: specifica il set di caratteri per decodificare il file CSV. Il valore predefinito è UTF-8. I set di caratteri supportati sono US-ASCII, ISO-8859-1, UTF-8, e UTF-16.

• Tipo di dati: string
• Obbligatorio (S/N): N

• Esempio: "encoding" : "UTF-8"

csvOptions.trim

• Scopo: specifica se è necessario tagliare gli spazi vuoti iniziali e finali di un valore di campo CSV. Il valore predefinito è false.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• Esempio: "trim" : "true"

Modelli di configurazione del lavandino

Informazioni sui formati dei file di configurazione del sink per ciascun sink valido e sullo scopo di ciascun parametro di configurazione.

Per il modello di file di configurazione, vedere File di configurazione in Terminologia utilizzata con NoSQL Data Migrator.

Per informazioni dettagliate sui formati di origine validi per ciascun sink, vedere Modelli di configurazione di origine.

Argomenti

Negli argomenti riportati di seguito vengono descritti i modelli di configurazione sink a cui fa riferimento Oracle NoSQL Database Migrator per copiare i dati da un'origine valida al sink specificato.

• Lavello file JSON

  File JSON specificato.

• File Parquet

  File parquet nella directory specificata.

• File JSON nel bucket di storage degli oggetti OCI

  File JSON nel bucket di storage degli oggetti OCI specificato.

• File Parquet nel bucket di storage degli oggetti OCI

  File Parquet nel bucket di storage degli oggetti OCI specificato.

• Oracle NoSQL Database

  Tabella specificata in Oracle NoSQL Database.

• Oracle NoSQL Database Cloud Service

  Tabella specificata in Oracle NoSQL Database Cloud Service.

Lavello file JSON

Di seguito è riportato il formato del file di configurazione per il file JSON come sink di NoSQL Database Migrator.

Modello configurazione lavandino

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

Parametri lavandino

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "file"

• formato

  Usa "format" : "json"

• chunkSize

  Esempio: "chunkSize" : 40

  Nota

  Questo parametro è applicabile SOLO se il parametro useMultiFiles è impostato su true.

Parametri di configurazione univoci

• dataPath
• schemaPath
• carino
• useMultiFiles

dataPath

• Scopo: specifica il percorso assoluto di un file in cui i dati di origine verranno copiati in formato JSON.

  Se il file non esiste nel percorso dati specificato, viene creato da NoSQL Database Migrator. Se esiste, NoSQL Database Migrator sovrascriverà il relativo contenuto con i dati di origine.

  Assicurarsi che la directory padre nel percorso dati sia valida per il file specificato.

  Nota

  Se il parametro useMultiFiles è impostato su true, specificare il percorso di una directory, altrimenti specificare il percorso del file.
• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

  • Con il parametro useMultiFiles impostato su true

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

  • Con il parametro useMultiFiles non specificato o impostato su false

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

schemaPath

• Scopo: specifica il percorso assoluto di un file per la scrittura delle informazioni sullo schema di tabella fornite dall'origine.

  Se questo valore non è definito, le informazioni sullo schema di origine non verranno migrate nel sink. Se questo valore viene specificato, la utility di migrazione scrive lo schema della tabella di origine nel file specificato qui.

  Le informazioni sullo schema vengono scritte come un comando DDL per riga in questo file. Se il file non esiste nel percorso dati specificato, NoSQL Migrator database lo crea. Se esiste già, NoSQL Migrator database sovrascriverà il relativo contenuto con i dati di origine. Assicurarsi che la directory padre nel percorso dati sia valida per il file specificato.

• Tipo di dati: string
• Obbligatorio (S/N): N

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

pretty

• Scopo: specifica se abbellire o meno l'output JSON per aumentare la leggibilità.

  Se non specificato, il valore predefinito è false.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• Esempio: "pretty" : true

useMultiFiles

• Scopo: specifica se dividere o meno i dati della tabella NoSQL in più file durante la migrazione dei dati di origine in un file.

  Se non specificato, il valore predefinito è false.

  Se impostato su true, durante la migrazione dei dati di origine in un file, i dati della tabella NoSQL vengono suddivisi in più file più piccoli. Ad esempio, <chunk>.json, dove chunk=000000, 000001, 000002 e così via.

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

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "useMultiFiles" : true

File Parquet

Di seguito è riportato il formato del file di configurazione per il file Parquet come sink di NoSQL Database Migrator.

Modello configurazione lavandino

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

Parametri lavandino

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "file"

• formato

  Utilizzare "format" : "parquet"

• chunkSize

  Esempio: "chunkSize" : 40

Parametri di configurazione univoci

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

dataPath

• Scopo: specifica il percorso di una directory per la memorizzazione dei dati della tabella NoSQL migrati. Verificare che la directory esista già e che si disponga delle autorizzazioni di lettura e scrittura.

• Tipo di dati: string
• Obbligatorio (S/N): Y

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

compressione

• Scopo: specifica il tipo di compressione da utilizzare per comprimere i dati Parquet. I valori validi sono SNAPPY, GZIP e NONE.

  Se non viene specificato, viene utilizzato il valore predefinito SNAPPY.

• Tipo di dati: string
• Obbligatorio (S/N): N

• Esempio: "compression" : "GZIP"

parquetOptions

• Scopo: specifica le opzioni per selezionare i tipi logici Parquet per le colonne NoSQL ENUM, JSON e UUID.

  Se non si specifica questo parametro, NoSQL Migrator database scrive i dati delle colonne ENUM, JSON e UUID come stringa.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

parquetOptions.useLogicalJson

• Scopo: specifica se scrivere o meno i dati della colonna JSON NoSQL come tipo JSON logico Parquet. Per ulteriori informazioni, vedere Definizioni dei tipi logici di parquet.

  Se non specificato o impostato su falso, NoSQL Database Migrator scrive i dati della colonna JSON NoSQL come stringa.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "useLogicalJson" : true

parquetOptions.useLogicalEnum

• Scopo: specifica se scrivere o meno i dati della colonna NoSQL ENUM come tipo ENUM logico Parquet. Per ulteriori informazioni, vedere Definizioni dei tipi logici di parquet.

  Se non specificato o impostato su falso, NoSQL Migratore database scrive i dati della colonna NoSQL ENUM come stringa.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "useLogicalEnum" : true

parquetOptions.useLogicalUUID

• Scopo: specifica se scrivere o meno i dati della colonna UUID NoSQL come tipo di UUID logico Parquet. Per ulteriori informazioni, vedere Definizioni dei tipi logici di parquet.

  Se non viene specificato o impostato su falso, NoSQL Migrator database scrive i dati della colonna UUID NoSQL come stringa.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "useLogicalUUID" : true

parquetOptions.truncateDoubleSpecials

• Scopo: specifica se troncare o meno i valori +Infinity, -Infinity e NaN doppi.

  L'impostazione predefinita è false. Se impostato su true,

  • Positive_Infinity viene troncato in Double.MAX_VALUE.
  • NEGATIVE_INFINITY viene troncato in -Double.MAX_VALUE.
  • NaN viene troncato in 9.9999999999999990E307.
• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "truncateDoubleSpecials" : true

File JSON nel bucket di storage degli oggetti OCI

Il formato del file di configurazione per il file JSON nel bucket di storage degli oggetti OCI come sink di NoSQL Database Migrator viene mostrato di seguito.

Nota

I tipi di origine validi per lo storage degli oggetti OCI come sink sono nosqldb e nosqldb_cloud.

Modello configurazione lavandino

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

Parametri lavandino

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "object_storage_oci"

• formato

  Usa "format" : "json"

• endpoint
  Esempio:

  • ID area: "endpoint" : "us-ashburn-1"

  • Formato URL: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• spazio di nomi

  Esempio: "namespace" : "my-namespace"

• bucket

  Esempio: "bucket" : "my-bucket"

• prefisso

  Viene eseguita la migrazione dello schema nel file <prefix>/Schema/schema.ddl e viene eseguita la migrazione dei dati di origine nei file <prefix>/Data/<chunk>.json, dove chunk=000000.json, 000001.json e così via.

  Esempio:

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

  Esempio: "chunkSize" : 40

• credenziali
  Esempio:

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

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

  Esempio: "useInstancePrincipal" : true

• useDelegationToken

  Esempio: "useDelegationToken" : true

  Nota

  L'autenticazione con token di delega è supportata solo quando NoSQL Database Migrator è in esecuzione da una Cloud Shell.

Parametro di configurazione univoco

pretty

• Scopo: specifica se abbellire o meno l'output JSON per aumentare la leggibilità.

  Se non specificato, il valore predefinito è false.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• Esempio: "pretty" : true

File Parquet nel bucket di storage degli oggetti OCI

Il formato del file di configurazione per il file Parquet nel bucket di storage degli oggetti OCI come sink di NoSQL Database Migrator viene mostrato di seguito.

Nota

I tipi di origine validi per il tipo di origine dello storage degli oggetti OCI sono nosqldb e nosqldb_cloud.

Modello configurazione lavandino

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

Parametri lavandino

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "object_storage_oci"

• formato

  Utilizzare "format" : "parquet"

• endpoint
  Esempio:

  • ID area: "endpoint" : "us-ashburn-1"

  • Formato URL: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• spazio di nomi

  Esempio: "namespace" : "my-namespace"

• bucket

  Esempio: "bucket" : "my-bucket"

• prefisso

  I dati di origine vengono migrati nei file <prefix>/Data/<chunk>.parquet, dove chunk=000000.parquet, 000001.parquet e così via.

  Esempio:

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

  Esempio: "chunkSize" : 40

• credenziali
  Esempio:

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

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

  Esempio: "useInstancePrincipal" : true

• useDelegationToken

  Esempio: "useDelegationToken" : true

  Nota

  L'autenticazione con token di delega è supportata solo quando NoSQL Database Migrator è in esecuzione da una Cloud Shell.

Parametro di configurazione univoco

• compressione
• parquetOptions
• parquetOptions.useLogicalJson
• parquetOptions.useLogicalEnum
• parquetOptions.useLogicalUUID
• parquetOptions.truncateDoubleSpecials

compressione

• Scopo: specifica il tipo di compressione da utilizzare per comprimere i dati Parquet. I valori validi sono SNAPPY, GZIP e NONE.

  Se non viene specificato, viene utilizzato il valore predefinito SNAPPY.

• Tipo di dati: string
• Obbligatorio (S/N): N

• Esempio: "compression" : "GZIP"

parquetOptions

• Scopo: specifica le opzioni per selezionare i tipi logici Parquet per le colonne NoSQL ENUM, JSON e UUID.

  Se non si specifica questo parametro, NoSQL Migrator database scrive i dati delle colonne ENUM, JSON e UUID come stringa.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

parquetOptions.useLogicalJson

• Scopo: specifica se scrivere o meno i dati della colonna JSON NoSQL come tipo JSON logico Parquet. Per ulteriori informazioni, vedere Definizioni dei tipi logici di parquet.

  Se non specificato o impostato su falso, NoSQL Database Migrator scrive i dati della colonna JSON NoSQL come stringa.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "useLogicalJson" : true

parquetOptions.useLogicalEnum

• Scopo: specifica se scrivere o meno i dati della colonna NoSQL ENUM come tipo ENUM logico Parquet. Per ulteriori informazioni, vedere Definizioni dei tipi logici di parquet.

  Se non specificato o impostato su falso, NoSQL Migratore database scrive i dati della colonna NoSQL ENUM come stringa.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "useLogicalEnum" : true

parquetOptions.useLogicalUUID

• Scopo: specifica se scrivere o meno i dati della colonna UUID NoSQL come tipo di UUID logico Parquet. Per ulteriori informazioni, vedere Definizioni dei tipi logici di parquet.

  Se non viene specificato o impostato su falso, NoSQL Migrator database scrive i dati della colonna UUID NoSQL come stringa.

• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "useLogicalUUID" : true

parquetOptions.truncateDoubleSpecials

• Scopo: specifica se troncare o meno i valori +Infinity, -Infinity e NaN doppi.

  L'impostazione predefinita è false. Se impostato su true,

  • Positive_Infinity viene troncato in Double.MAX_VALUE.
  • NEGATIVE_INFINITY viene troncato in -Double.MAX_VALUE.
  • NaN viene troncato in 9.9999999999999990E307.
• Tipo di dati: booleano
• Obbligatorio (S/N): N

• esempio: "truncateDoubleSpecials" : true

Oracle NoSQL Database

Di seguito è riportato il formato del file di configurazione per Oracle NoSQL Database come sink di NoSQL Database Migrator.

Modello configurazione lavandino

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

Parametri lavandino

Parametro di configurazione comune

• tipo

  Utilizzare "type" : "nosqldb"

• sicurezza

  Esempio:

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

  Esempio di contenuto del file di sicurezza per l'autenticazione basata su password file:

  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)

  Esempio di contenuto del file di sicurezza per l'autenticazione basata su wallet:

  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

  Esempio: "requestTimeoutMs" : 5000

Parametro di configurazione univoco

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

storeName

• Scopo: nome dell'area di memorizzazione di Oracle NoSQL Database.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio: "storeName" : "kvstore"

helperHosts

• Scopo: lista di coppie di porte host e registro nel formato hostname:port. Delimitare ogni elemento dell'elenco utilizzando una virgola. Specificare almeno un host dell'applicazione di supporto.

• Tipo dati: array di stringhe
• Obbligatorio (S/N): Y
• Esempio: "helperHosts" : ["localhost:5000","localhost:6000"]

Tabella

• Scopo: specifica il nome della tabella per memorizzare i dati migrati.

  Formato: [namespace_name:]<table_name>

  Se la tabella si trova nello spazio di nomi DEFAULT, è possibile omettere namespace_name. La tabella deve esistere nell'area di memorizzazione durante la migrazione e il relativo schema deve corrispondere ai dati di origine.

  Se la tabella non è disponibile nel sink, è possibile utilizzare il parametro schemaInfo per indicare al NoSQL Database Migrator di creare la tabella nel sink.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:

  • Con lo spazio di nomi DEFAULT "table" :"mytable"

  • Con uno spazio di nomi non predefinito "table" : "mynamespace:mytable"

  • Per specificare una tabella figlio "table" : "mytable.child"

    Nota

    È possibile eseguire la migrazione delle tabelle figlio da un'origine dati valida a Oracle NoSQL Database. NoSQL Migrator database copia una sola tabella in ogni esecuzione. Assicurarsi che la tabella padre venga migrata prima della tabella figlio.

includeTTL

• Scopo: specifica se includere o meno i metadati TTL per le righe di tabella fornite dall'origine durante l'importazione delle tabelle di Oracle NoSQL Database.

  Se il parametro non viene specificato, viene utilizzato per impostazione predefinita false. In tal caso, NoSQL Migrator database non include metadati TTL per le righe di tabella fornite dall'origine durante l'importazione delle tabelle di Oracle NoSQL Database.

  Se impostato su true, lo strumento NoSQL Migratore database esegue i controlli riportati di seguito sui metadati TTL durante l'importazione di una riga di tabella.

  • Se si importa una riga senza definizione _metadata, lo strumento NoSQL Migrator database imposta il TTL su 0, ovvero la riga non scade mai.
  • Se si importa una riga con definizione _metadata, lo strumento NoSQL Migratore database confronta il valore TTL con un'ora di riferimento quando una riga viene importata. Se la riga è già scaduta rispetto all'ora di riferimento, viene saltata. Se la riga non è scaduta, viene importata insieme al valore TTL. Per impostazione predefinita, l'ora di riferimento dell'operazione di importazione è l'ora corrente in millisecondi, ottenuta da System.currentTimeMillis(), del computer in cui è in esecuzione lo strumento Migratore database NoSQL. È tuttavia possibile impostare un tempo di riferimento personalizzato utilizzando il parametro di configurazione ttlRelativeDate se si desidera estendere l'ora di scadenza e importare le righe che altrimenti scadrebbero immediatamente.
    La formula per calcolare l'ora di scadenza di una riga è la seguente:

    expiration = (TTL value of source row in milliseconds - Reference Time in milliseconds)
    if (expiration <= 0) then it indicates that row has expired.

    Nota

    Poiché i limiti TTL di Oracle NoSQL sono espressi in ore e giorni, in alcuni casi il TTL della riga importata potrebbe essere adeguato all'ora o al giorno più vicini. Si consideri, ad esempio, una riga con valore di scadenza 1629709200000 (2021-08-23 09:00:00) e valore ora di riferimento 1629707962582 (2021-08-23 08:39:22). In questo caso, anche se la riga non è scaduta rispetto all'ora di riferimento quando questi dati vengono importati, il nuovo TTL per la riga è 1629712800000 (2021-08-23 10:00:00).
• Tipo di dati: booleano
• Obbligatorio (S/N): N
• esempio: "includeTTL" : true

ttlRelativeDate

• Scopo: specificare una data UTC nel formato AAAA-MM-GG hh:mm:ss utilizzato per impostare la scadenza TTL delle righe della tabella durante l'importazione in Oracle NoSQL Database.

  Se una riga di tabella nei dati che si stanno esportando è scaduta, è possibile impostare il parametro ttlRelativeDate su una data precedente all'ora di scadenza della riga di tabella nei dati esportati.

  Se non si specifica questo parametro, per impostazione predefinita viene utilizzata l'ora corrente in millisecondi, ottenuta da System.currentTimeMillis(), del computer in cui è in esecuzione lo strumento NoSQL Migrator database.

• Tipo di dati: data
• Obbligatorio (S/N): N
• Esempio: "ttlRelativeDate" : "2021-01-03 04:31:17"

  Consideriamo uno scenario in cui le righe della tabella scadono dopo sette giorni dal 1° gennaio 2021. Dopo aver esportato questa tabella, il 7 gennaio 2021 si verifica un problema con la tabella e si decide di importare i dati. Le righe della tabella scadranno tra un giorno (data di scadenza meno il valore predefinito del parametro di configurazione ttlRelativedate, che è la data corrente). Se invece si desidera estendere la data di scadenza delle righe della tabella a cinque giorni anziché a un giorno, utilizzare il parametro ttlRelativeDate e scegliere una data precedente. Pertanto, in questo scenario, se si desidera estendere di cinque giorni l'ora di scadenza delle righe della tabella, impostare il valore dei parametri di configurazione ttlRelativeDate su 3 gennaio 2021, utilizzato come ora di riferimento quando le righe della tabella vengono importate.

Informazioni schema

• Scopo: specifica lo schema per i dati di cui viene eseguita la migrazione. Se questa opzione non viene specificata, NoSQL Migrator database presuppone che la tabella esista già nell'area di memorizzazione del sink.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

schemaInfo.schemaPath

• Scopo: specifica il percorso assoluto di un file contenente le istruzioni DDL per la tabella NoSQL.

  NoSQL Database Migrator esegue i comandi DDL elencati in questo file prima di eseguire la migrazione dei dati.

  NoSQL Database Migrator non supporta più di un'istruzione DDL per riga nel file schemaPath.

• Tipo di dati: stringa

• Obbligatorio (S/N): N

  Nota

  defaultSchema e schemaPath si escludono a vicenda.

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

schemaInfo.defaultSchema

• Scopo: l'impostazione di questo parametro su true indica a NoSQL Database Migrator di creare una tabella con lo schema predefinito. Lo schema predefinito è definito dal migratore stesso. Per ulteriori informazioni sulle definizioni di schema predefinite, vedere Schema predefinito in Uso di Oracle NoSQL Data Migrator.

• Tipo di dati: booleano

• Obbligatorio (S/N): N

  Nota

  defaultSchema e schemaPath si escludono a vicenda.

schemaInfo.useSourceSchema

• Scopo: specifica se il sink utilizza o meno la definizione dello schema di tabella fornita dall'origine durante la migrazione delle tabelle NoSQL.

• Tipo di dati: booleano

• Obbligatorio (S/N): N

  Nota

  I parametri defaultSchema, schemaPath e useSourceSchema si escludono a vicenda. Specificare solo uno di questi parametri.
• Esempio:
  • Con schema predefinito:

    "schemaInfo" : {
      "defaultSchema" : true
    }

  • Con uno schema predefinito:

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

  • Con lo schema di origine:

    "schemaInfo" : {
      "useSourceSchema" : true
    }

schemaInfo.DDBPartitionKey

• Scopo: specifica la chiave di partizione DynamoDB e il tipo di Oracle NoSQL Database corrispondente da utilizzare nella tabella sink di Oracle NoSQL Database. Questa chiave verrà utilizzata come chiave partizione tabella DB NoSQL. È applicabile solo quando defaultSchema è impostato su true e il formato di origine è dynamodb_json. Per ulteriori dettagli, vedere Mapping dei tipi DynamoDB ai tipi NoSQL Oracle.
• Obbligatorio (S/N): Y, se defaultSchema è true e l'origine è dynamodb_json.
• Esempio: "DDBPartitionKey" : "PersonID:INTEGER"

  Nota

  Se la chiave di partizione contiene trattini (-) o punti (-), Migrator la sostituirà con caratteri di sottolineatura (-) poiché il nome della colonna NoSQL non supporta punti e trattini.

schemaInfo.DDBSortKey

• Scopo: specifica la chiave di ordinamento DynamoDB e il tipo di Oracle NoSQL Database corrispondente da utilizzare nella tabella Oracle NoSQL Database di destinazione. Se la tabella DynamoDB di importazione non dispone di una chiave di ordinamento, questo attributo non deve essere impostato. Questa chiave verrà utilizzata come parte non della partizione della chiave primaria nella tabella DB NoSQL. Ciò è applicabile solo quando defaultSchema è impostato su true e l'origine è dynamodb_json. Per ulteriori dettagli, vedere Mapping dei tipi DynamoDB ai tipi NoSQL Oracle.
• Obbligatorio (S/N): N
• Esempio: "DDBSortKey" : "Skey:STRING"

  Nota

  Se la chiave di ordinamento contiene trattini (-) o punti (-), Migrator la sostituirà con caratteri di sottolineatura (-) poiché il nome della colonna NoSQL non supporta punti e trattini.

overwrite

• Scopo: indica il funzionamento di NoSQL Migratore database quando il record di cui si esegue la migrazione dall'origine è già presente nel sink.

  Se il valore è impostato su false, durante la migrazione delle tabelle NoSQL Migrator database salta i record per i quali esiste già la stessa chiave primaria nel sink.

  Se il valore è impostato su true, durante la migrazione delle tabelle NoSQL Migrator database sovrascrive i record per i quali esiste già la stessa chiave primaria nel sink.

  Se non specificato, il valore predefinito è true.

• Tipo di dati: booleano
• Obbligatorio (S/N): N
• Esempio: "overwrite" : false

Oracle NoSQL Database Cloud Service

Di seguito è riportato il formato del file di configurazione per Oracle NoSQL Database Cloud Service come sink di NoSQL Database Migrator.

Modello configurazione lavandino

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

Parametri lavandino

Parametri di configurazione comuni

• tipo

  Utilizzare "type" : "nosqldb_cloud"

• endpoint
  Esempio:

  • ID area: "endpoint" : "us-ashburn-1"

  • Formato URL: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• credenziali
  Esempio:

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

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

  Esempio: "useInstancePrincipal" : true

• useDelegationToken

  Esempio: "useDelegationToken" : true

  Nota

  L'autenticazione con token di delega è supportata solo quando NoSQL Database Migrator è in esecuzione da una Cloud Shell.
• requestTimeoutMs

  Esempio: "requestTimeoutMs" : 5000

Parametro di configurazione univoco

• tabella
• compartimento
• includeTTL
• ttlRelativeDate
• schemaInfo
• schemaInfo.schemaPath
• schemaInfo.defaultSchema
• schemaInfo.useSourceSchema
• schemaInfo.DDBPartitionKey
• schemaInfo.DDBSortKey
• schemaInfo.onDemandThroughput
• schemaInfo.readUnits
• schemaInfo.writeUnits
• schemaInfo.storageSize
• writeUnitsPercent
• overwrite

Tabella

• Scopo: specifica il nome della tabella per la memorizzazione dei dati migrati.

  È necessario assicurarsi che questa tabella esista in Oracle NoSQL Database Cloud Service. In caso contrario, è necessario utilizzare l'oggetto schemaInfo nella configurazione sink per impostare NoSQL Database Migrator su come creare la tabella.

  Lo schema di questa tabella deve corrispondere ai dati di origine.

• Tipo di dati: string
• Obbligatorio (S/N): Y
• Esempio:
  • Per specificare una tabella "table" : "mytable"
  • Per specificare una tabella figlio "table" : "mytable.child"

    Nota

    È possibile eseguire la migrazione delle tabelle figlio da un'origine dati valida a Oracle NoSQL Database Cloud Service. NoSQL Migrator database copia una sola tabella in ogni esecuzione. Assicurarsi che la tabella padre venga migrata prima della tabella figlio.

compartimento

• Scopo: specifica il nome o l'OCID del compartimento in cui risiede la tabella.

  Se non si fornisce alcun valore, per impostazione predefinita viene utilizzato il compartimento root.

  Puoi trovare l'OCID del compartimento dalla finestra Explorer compartimenti in Governance nella console cloud OCI.

• Tipo di dati: string
• Obbligatorio (Y/N): Y, se la tabella non si trova nel compartimento radice della tenancy OPPURE quando il parametro useInstancePrincipal è impostato su true.

  Nota

  Se il parametro useInstancePrincipal è impostato su true, il compartimento deve specificare l'OCID del compartimento e non il nome.
• Esempio:

  • Nome compartimento

    "compartment" : "mycompartment"

  • Nome del compartimento qualificato con il relativo compartimento padre

    "compartment" : "parent.childcompartment"

  • Nessun valore fornito. Per impostazione predefinita, viene utilizzato il compartimento radice.

    "compartment": ""

  • OCID compartimento

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

includeTTL

• Scopo: specifica se includere o meno i metadati TTL per le righe di tabella fornite dall'origine durante l'importazione delle tabelle di Oracle NoSQL Database.

  Se il parametro non viene specificato, viene utilizzato per impostazione predefinita false. In tal caso, NoSQL Migrator database non include metadati TTL per le righe di tabella fornite dall'origine durante l'importazione delle tabelle di Oracle NoSQL Database.

  Se impostato su true, lo strumento NoSQL Migratore database esegue i controlli riportati di seguito sui metadati TTL durante l'importazione di una riga di tabella.

  • Se si importa una riga senza definizione _metadata, lo strumento NoSQL Migrator database imposta il TTL su 0, ovvero la riga non scade mai.
  • Se si importa una riga con definizione _metadata, lo strumento NoSQL Migratore database confronta il valore TTL con un'ora di riferimento quando una riga viene importata. Se la riga è già scaduta rispetto all'ora di riferimento, viene saltata. Se la riga non è scaduta, viene importata insieme al valore TTL. Per impostazione predefinita, l'ora di riferimento dell'operazione di importazione è l'ora corrente in millisecondi, ottenuta da System.currentTimeMillis(), del computer in cui è in esecuzione lo strumento Migratore database NoSQL. È tuttavia possibile impostare un tempo di riferimento personalizzato utilizzando il parametro di configurazione ttlRelativeDate se si desidera estendere l'ora di scadenza e importare le righe che altrimenti scadrebbero immediatamente.
    La formula per calcolare l'ora di scadenza di una riga è la seguente:

    expiration = (TTL value of source row in milliseconds - Reference Time in milliseconds)
    if (expiration <= 0) then it indicates that row has expired.

    Nota

    Poiché i limiti TTL di Oracle NoSQL sono espressi in ore e giorni, in alcuni casi il TTL della riga importata potrebbe essere adeguato all'ora o al giorno più vicini. Si consideri, ad esempio, una riga con valore di scadenza 1629709200000 (2021-08-23 09:00:00) e valore ora di riferimento 1629707962582 (2021-08-23 08:39:22). In questo caso, anche se la riga non è scaduta rispetto all'ora di riferimento quando questi dati vengono importati, il nuovo TTL per la riga è 1629712800000 (2021-08-23 10:00:00).
• Tipo di dati: booleano
• Obbligatorio (S/N): N
• esempio: "includeTTL" : true

ttlRelativeDate

• Scopo: specificare una data UTC nel formato AAAA-MM-GG hh:mm:ss utilizzato per impostare la scadenza TTL delle righe della tabella durante l'importazione in Oracle NoSQL Database.

  Se una riga di tabella nei dati che si stanno esportando è scaduta, è possibile impostare il parametro ttlRelativeDate su una data precedente all'ora di scadenza della riga di tabella nei dati esportati.

  Se non si specifica questo parametro, per impostazione predefinita viene utilizzata l'ora corrente in millisecondi, ottenuta da System.currentTimeMillis(), del computer in cui è in esecuzione lo strumento NoSQL Migrator database.

• Tipo di dati: data
• Obbligatorio (S/N): N
• Esempio: "ttlRelativeDate" : "2021-01-03 04:31:17"

  Consideriamo uno scenario in cui le righe della tabella scadono dopo sette giorni dal 1° gennaio 2021. Dopo aver esportato questa tabella, il 7 gennaio 2021 si verifica un problema con la tabella e si decide di importare i dati. Le righe della tabella scadranno tra un giorno (data di scadenza meno il valore predefinito del parametro di configurazione ttlRelativedate, che è la data corrente). Se invece si desidera estendere la data di scadenza delle righe della tabella a cinque giorni anziché a un giorno, utilizzare il parametro ttlRelativeDate e scegliere una data precedente. Pertanto, in questo scenario, se si desidera estendere di cinque giorni l'ora di scadenza delle righe della tabella, impostare il valore dei parametri di configurazione ttlRelativeDate su 3 gennaio 2021, utilizzato come ora di riferimento quando le righe della tabella vengono importate.

schemaInfo

• Scopo: specifica lo schema per i dati di cui viene eseguita la migrazione.

  Se non si specifica questo parametro, NoSQL Migrator database presuppone che la tabella esista già in Oracle NoSQL Database Cloud Service.

  Se questo parametro non viene specificato e la tabella non esiste nel sink, la migrazione non riesce.

• Tipo di dati: oggetto
• Obbligatorio (S/N): N

schemaInfo.schemaPath

• Scopo: specifica il percorso assoluto di un file contenente le istruzioni DDL per la tabella NoSQL.

  NoSQL Database Migrator esegue i comandi DDL elencati in questo file prima di eseguire la migrazione dei dati.

  NoSQL Database Migrator non supporta più di un'istruzione DDL per riga nel file schemaPath.

• Tipo di dati: stringa

• Obbligatorio (S/N): N

  Nota

  defaultSchema e schemaPath si escludono a vicenda.

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

schemaInfo.defaultSchema

• Scopo: l'impostazione di questo parametro su Sì indica a NoSQL Migrator database di creare una tabella con lo schema predefinito. Lo schema predefinito è definito dal migratore stesso. Per ulteriori informazioni sulle definizioni di schema predefinite, vedere Schema predefinito in Uso di Oracle NoSQL Data Migrator.

• Tipo di dati: booleano

• Obbligatorio (S/N): N

  Nota

  defaultSchema e schemaPath si escludono a vicenda.

schemaInfo.useSourceSchema

• Scopo: specifica se il sink utilizza o meno la definizione dello schema di tabella fornita dall'origine durante la migrazione delle tabelle NoSQL.

• Tipo di dati: booleano

• Obbligatorio (S/N): N

  Nota

  I parametri defaultSchema, schemaPath e useSourceSchema si escludono a vicenda. Specificare solo uno di questi parametri.
• Esempio:
  • Con schema predefinito:

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

  • Con uno schema predefinito:

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

  • Con lo schema di origine:

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

schemaInfo.DDBPartitionKey

• Scopo: specifica la chiave di partizione DynamoDB e il tipo di Oracle NoSQL Database corrispondente da utilizzare nella tabella sink di Oracle NoSQL Database. Questa chiave verrà utilizzata come chiave partizione tabella DB NoSQL. È applicabile solo quando defaultSchema è impostato su true e il formato di origine è dynamodb_json. Per ulteriori dettagli, vedere Mapping dei tipi DynamoDB ai tipi NoSQL Oracle.
• Obbligatorio (S/N): Y, se defaultSchema è true e l'origine è dynamodb_json.
• Esempio: "DDBPartitionKey" : "PersonID:INTEGER"

  Nota

  Se la chiave di partizione contiene trattini (-) o punti (-), Migrator la sostituirà con caratteri di sottolineatura (-) poiché il nome della colonna NoSQL non supporta punti e trattini.

schemaInfo.DDBSortKey

• Scopo: specifica la chiave di ordinamento DynamoDB e il tipo di Oracle NoSQL Database corrispondente da utilizzare nella tabella Oracle NoSQL Database di destinazione. Se la tabella DynamoDB di importazione non dispone di una chiave di ordinamento, questo attributo non deve essere impostato. Questa chiave verrà utilizzata come parte non della partizione della chiave primaria nella tabella DB NoSQL. Ciò è applicabile solo quando defaultSchema è impostato su true e l'origine è dynamodb_json. Per ulteriori dettagli, vedere Mapping dei tipi DynamoDB ai tipi NoSQL Oracle.
• Obbligatorio (S/N): N
• Esempio: "DDBSortKey" : "Skey:STRING"

  Nota

  Se la chiave di ordinamento contiene trattini (-) o punti (-), Migrator la sostituirà con caratteri di sottolineatura (-) poiché il nome della colonna NoSQL non supporta punti e trattini.

schemaInfo.onDemandThroughput

• Scopo: specifica di creare la tabella con throughput di lettura e scrittura su richiesta. Se questo parametro non è impostato, la tabella viene creata con la capacità di cui è stato eseguito il provisioning.

  Il valore predefinito è false.

  Nota

  Questo parametro non è applicabile per le tabelle figlio perché condividono il throughput della tabella padre di livello superiore.

• Tipo di dati: booleano

• Obbligatorio (S/N): N

• esempio: "onDemandThroughput" : "true"

schemaInfo.readUnits

• Scopo: specifica il throughput di lettura della nuova tabella.

  Nota

  • Questo parametro non è applicabile per le tabelle di cui è stato eseguito il provisioning con capacità su richiesta.
  • Questo parametro non è applicabile per le tabelle figlio perché condividono il throughput di lettura della tabella padre di livello superiore.

• Tipo di dati: numero intero

• Obbligatorio (S/N): Y, se la tabella non è una tabella figlio o se il parametro schemaInfo.onDemandThroughput è impostato su false, altrimenti N.

• esempio: "readUnits" : 100

schemaInfo.writeUnits

• Scopo: specifica il throughput di scrittura della nuova tabella.

  Nota

  • Questo parametro non è applicabile per le tabelle di cui è stato eseguito il provisioning con capacità su richiesta.
  • Questo parametro non è applicabile per le tabelle figlio perché condividono il throughput di scrittura della tabella padre di livello superiore.

• Tipo di dati: numero intero

• Obbligatorio (S/N): Y, se la tabella non è una tabella figlio o se il parametro schemaInfo.onDemandThroughput è impostato su false, altrimenti N.

• esempio: "writeUnits" : 100

schemaInfo.storageSize

• Scopo: specifica la dimensione di memorizzazione della nuova tabella in GB.

  Nota

  Questo parametro non è applicabile per le tabelle figlio perché condividono le dimensioni di memorizzazione della tabella padre di livello superiore.

• Tipo di dati: numero intero

• Obbligatorio (S/N): S, se la tabella non è una tabella figlio, altrimenti N.

• Esempio:

  • Con schemaPath

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

  • Con defaultSchema

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

writeUnitsPercent

• Scopo: specifica la percentuale di unità di scrittura della tabella da utilizzare durante l'attività di migrazione. Il tempo necessario per eseguire la migrazione dei dati è direttamente proporzionale a questo attributo.

  Il valore predefinito per il server di amministrazione è 90. L'intervallo valido è qualsiasi numero intero compreso tra 1 e 100.

  Per ulteriori informazioni su come utilizzare questo attributo per migliorare la velocità di migrazione dei dati, vedere Risoluzione dei problemi di Oracle NoSQL Database Migrator.

• Tipo di dati: intero
• Obbligatorio (S/N): N
• Esempio: "writeUnitsPercent" : 90

overwrite

• Scopo: indica il funzionamento di NoSQL Migratore database quando il record di cui si esegue la migrazione dall'origine è già presente nel sink.

  Se il valore è impostato su false, durante la migrazione delle tabelle NoSQL Migrator database salta i record per i quali esiste già la stessa chiave primaria nel sink.

  Se il valore è impostato su true, durante la migrazione delle tabelle NoSQL Migrator database sovrascrive i record per i quali esiste già la stessa chiave primaria nel sink.

  Se non specificato, il valore predefinito è true.

• Tipo di dati: booleano
• Obbligatorio (S/N): N
• Esempio: "overwrite" : false

Modelli di configurazione della trasformazione

In questo argomento vengono descritti i parametri di configurazione per le diverse trasformazioni supportate da Oracle NoSQL Database Migrator. Per il modello completo di file di configurazione, vedere File di configurazione in Terminologia utilizzata con NoSQL Data Migrator.

Oracle NoSQL Database Migrator consente di modificare i dati, ovvero di aggiungere trasformazioni dei dati nell'ambito dell'attività di migrazione. È possibile definire più trasformazioni in una singola migrazione. In questo caso, l'ordine delle trasformazioni è vitale perché i dati di origine subiscono ogni trasformazione nell'ordine dato. L'output di una trasformazione diventa l'input alla successiva nella pipeline del migratore.

Le diverse trasformazioni supportate dal Data Migrator NoSQL sono:

Trasformazioni - tabella

Attributo di configurazione trasformazione	Questa trasformazione può essere utilizzata per...
ignoreFields	Ignorare le colonne identificate dalla riga di origine prima di scrivere nel sink.
includeFields	Includere le colonne identificate dalla riga di origine prima di scrivere nel sink.
renameFields	Rinominare le colonne identificate dalla riga di origine prima di scrivere nel sink.
aggregateFields	Aggrega più colonne dall'origine in una singola colonna nel sink. Nell'ambito di questa trasformazione, è inoltre possibile identificare le colonne che si desidera escludere nell'aggregazione. Tali campi verranno ignorati dalla colonna aggregata.

Di seguito è riportato il modello di configurazione per ogni trasformazione supportata.

ignoreFields

Di seguito è riportato il formato del file di configurazione per la trasformazione ignoreFields.

Modello di configurazione della trasformazione

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

Parametro trasformazione

ignoreFields

• Scopo: un array dei nomi delle colonne da ignorare dai record di origine.

  Nota

  È possibile fornire solo campi di livello superiore. Impossibile applicare le trasformazioni ai dati nei campi nidificati.
• Tipo dati: array di stringhe
• Obbligatorio (S/N): Y

• Esempio: per ignorare le colonne denominate "name" e "address" dal record di origine:

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

includeFields

Di seguito è riportato il formato del file di configurazione per la trasformazione includeFields.

Modello di configurazione della trasformazione

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

Parametro trasformazione

includeFields

• Scopo: un array dei nomi di colonna da includere nei record di origine. Solo include i campi specificati nell'array e gli altri campi vengono ignorati.

  Nota

  Lo strumento NoSQL Migrator database restituisce un errore se si specifica un array vuoto. È inoltre possibile specificare solo i campi di livello superiore. Lo strumento NoSQL Migratore database non applica trasformazioni ai dati nei campi nidificati.
• Tipo dati: array di stringhe
• Obbligatorio (S/N): Y

• Esempio: per ignorare le colonne denominate "age" e "gender" dal record di origine:

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

renameFields

Di seguito è riportato il formato del file di configurazione per la trasformazione renameFields.

Modello di configurazione della trasformazione

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

Parametro trasformazione

renameFields

• Scopo: coppie chiave-valore dei nomi vecchi e nuovi delle colonne da rinominare.

  Nota

  È possibile fornire solo campi di livello superiore. Impossibile applicare le trasformazioni ai dati nei campi nidificati.
• Tipo di dati: oggetto JSON
• Obbligatorio (S/N): Y

• Esempio: per rinominare la colonna denominata "residence" in "address" e la colonna denominata "_id" in "id":

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

aggregateFields

Di seguito è riportato il formato del file di configurazione per la trasformazione aggregateFields.

Modello di configurazione della trasformazione

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

Parametro trasformazione

aggregateFields

• Scopo: nome del campo aggregato nel sink.

• Tipo di dati: string
• Obbligatorio (S/N): Y

• Esempio: se il record specificato è:

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

  Se la trasformazione aggregata è:

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

  La colonna aggregata nel sink è simile alla seguente:

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

Mapping dei tipi DynamoDB ai tipi NoSQL Oracle

La tabella riportata di seguito mostra il mapping dei tipi DynamoDB ai tipi NoSQL Oracle.

Tabella - Mapping del tipo DynamoDB al tipo NoSQL Oracle

#	Tipo DynamoDB	Tipo JSON per la colonna JSON NoSQL	Tipo NoSQL Oracle
1	Stringa (S)	Stringa JSON	STRING
2	Tipo di numero (N)	Numero JSON	NUMERO INTERO/LUNGO/FLOAT/DOPPIO/NUMERO
3	Booleano (BOOL)	Booleano JSON	BOOLEAN
4	Tipo binario (B) - Byte buffer	Stringa JSON con codifica BASE-64	BINARIO
5	NULL	JSON nullo	NULL
6	Set di stringhe (SS)	Array JSON di stringhe	ARRAY (STRINGA)
7	Serie di numeri (NS)	Array di numeri JSON	ARRAY (INTERO/LUNGO/FLOAT/DOPPIO/NUMERO)
8	Set binario (BS)	Array JSON di stringhe con codifica Base-64	ARRAY (BINARIO)
9	ELENCO (L)	Array di JSON	ARRAY (JSON)
10	MAPPA (M)	Oggetto JSON	JSON
11	CHIAVE DI PARTIZIONAMENTO	ND	CHIAVE PRIMARIA E TASCIA
12	CHIAVE DI ORDINAMENTO	ND	CHIAVE PRIMARIA
13	Nomi di attributi con trattino e punto	Nomi di campi JSON con un carattere di sottolineatura	Nomi colonne con carattere di sottolineatura

Alcuni punti aggiuntivi da considerare durante il mapping dei tipi DynamoDB ai tipi NoSQL di Oracle:

• DynamoDB Supporta un solo tipo di dati per i numeri e può avere fino a 38 cifre di precisione. Al contrario, Oracle NoSQL supporta molti tipi tra cui scegliere in base all'intervallo e alla precisione di data.You può selezionare il tipo di numero appropriato che si adatta all'intervallo dei dati di input. In caso di dubbi sulla natura dei dati, è possibile utilizzare il tipo NUMBER NoSQL.
• DynamoDB Supporta un solo tipo di dati per i numeri e può avere fino a 38 cifre di precisione. Al contrario, Oracle NoSQL supporta molti tipi tra cui scegliere in base all'intervallo e alla precisione di data.You può selezionare il tipo di numero appropriato che si adatta all'intervallo dei dati di input. In caso di dubbi sulla natura dei dati, è possibile utilizzare il tipo NUMBER NoSQL.
• La chiave di partizione in DynamoDB ha un limite di 2048 byte, ma Oracle NoSQL Cloud Service ha un limite di 64 byte per la chiave primaria/chiave partizione.
• La chiave di ordinamento in DynamoDB ha un limite di 1024 byte, ma Oracle NoSQL Cloud Service ha un limite di 64 byte per la chiave primaria.
• I nomi degli attributi in DynamoDB possono essere lunghi 64 KB, ma i nomi delle colonne del servizio cloud Oracle NoSQL non possono superare i 64 caratteri.

Mapping tra Oracle NoSQL e tipo di dati parquet

Descrive il mapping dei tipi di dati NoSQL Oracle ai tipi di dati Parquet.

NoSQL Tipo	Tipo di parquet
BOOLEAN	BOOLEAN
INTEGER	INT32
LONG	INT64
FLOAT	DOUBLE
DOUBLE	DOUBLE
BINARIO	BINARIO
FIXED_BINARY	BINARIO
STRING	BINARIO (STRINGA)
ENUM	BINARIO (STRINGA) o BINARY(ENUM), se è configurato ENUM logico
UUID	BINARIO (STRINGA) o FIXED_BINARY(16), se è configurato l'UUID logico
TIMESTAMP(p)	INT64(TIMESTAMP(p))
NUMBER	DOUBLE
field_name ARRAY (T)	group field_name(LIST) { repeated group list { required T element } }
field_name MAPPA(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₂, ....) dove: K = Nome chiave T = Tipo N = annullabile o no	group field_name { ni == true ? optional Ti ki : required Ti ki }
JSON	BINARIO (STRINGA) o BINARY(JSON), se la notazione JSON logica è configurata

Nota

Quando il tipo di numero NoSQL viene convertito in Parquet di tipo Doppio, potrebbe verificarsi una perdita di precisione nel caso in cui il valore non possa essere rappresentato in Doppio. Se il numero è troppo grande per essere rappresentato come Doppio, viene convertito in Double.NEGATIVE_INFINITY o Double.POSITIVE_INFINITY.

Mapping della tabella DynamoDB alla tabella NoSQL Oracle

In DynamoDB, una tabella è una raccolta di elementi e ogni elemento è una raccolta di attributi. Ogni elemento della tabella ha un identificativo univoco o una chiave primaria. Oltre alla chiave primaria, la tabella è priva di schema. Ogni elemento può avere i propri attributi distinti.

DynamoDB supporta due tipi diversi di chiavi primarie:

• Chiave di partizione: chiave primaria semplice, composta da un attributo denominato chiave di partizione. DynamoDB utilizza il valore della chiave di partizione come input per una funzione hash interna. L'output della funzione hash determina la partizione in cui verrà memorizzato l'elemento.
• Chiave di partizione e chiave di ordinamento: come chiave primaria composta, questo tipo di chiave è composto da due attributi. Il primo attributo è partition key, mentre il secondo attributo è sort key. DynamoDB utilizza il valore della chiave di partizione come input per una funzione hash interna. L'output della funzione hash determina la partizione in cui verrà memorizzato l'elemento. Tutti gli elementi con lo stesso valore chiave di partizione vengono memorizzati insieme, in ordine per valore chiave di ordinamento.

Al contrario, le tabelle NoSQL di Oracle supportano modelli di dati flessibili con progettazione senza schema e senza schema.

Esistono due modi diversi per modellare una tabella DynamoDB:

1. Modellazione della tabella DynamoDB come documento JSON (consigliato): in questa modellazione è possibile mappare tutti gli attributi delle tabelle DB Dynamo in una colonna JSON della tabella NoSQL ad eccezione della chiave di partizione e della chiave di ordinamento. La chiave di partizione e la chiave di ordinamento verranno modellate come colonne della chiave primaria della tabella NoSQL. Verrà utilizzata la trasformazione AggregateFields per aggregare i dati della chiave non primaria in una colonna JSON.

   Nota

   Migrator fornisce una configurazione intuitiva defaultSchema per creare automaticamente una tabella DDL priva di schema che aggrega anche gli attributi in una colonna JSON.
2. Modellazione della tabella DynamoDB come colonne fisse nella tabella NoSQL: in questa modellazione, per ogni attributo della tabella DynamoDB verrà creata una colonna nella tabella NoSQL come specificato nella Mapping dei tipi DynamoDB ai tipi NoSQL Oracle. Sarà possibile modellare la chiave di partizione e ordinare gli attributi chiave come chiavi primarie. Questa opzione deve essere utilizzata solo quando si è certi che l'importazione dello schema di tabella DynamoDB è fissa e che ogni elemento contiene valori per la maggior parte degli attributi. Se gli articoli DynamoDB non dispongono di attributi comuni, il risultato potrebbe essere un lotto di colonne NoSQL con valori vuoti.

   Nota

   È consigliabile utilizzare tabelle senza schema durante la migrazione dei dati da DynamoDB a Oracle NoSQL Database a causa della natura delle tabelle DynamoDB senza schema. Ciò vale soprattutto per le tabelle di grandi dimensioni in cui il contenuto di ciascun record potrebbe non essere uniforme in tutta la tabella.

Risoluzione dei problemi di Oracle NoSQL Database Migrator

Informazioni sulle sfide generali che è possibile affrontare quando si utilizza la , e su come risolverle.

Impossibile eseguire la migrazione. Come posso risolvere questo problema?

Un errore della migrazione dei dati può essere dovuto a più motivi di base. Le cause importanti sono elencate di seguito:

Tabella - Cause errore migrazione

Messaggio di errore	Significato	Risoluzione
Failed to connect to Oracle NoSQL Database	Il migratore non è stato in grado di stabilire una connessione con il database NoSQL.	Controllare che i valori degli attributi storeName e helperHosts nel file JSON di configurazione siano validi e che gli host siano raggiungibili. Per un'area di memorizzazione protetta, verificare se il file di sicurezza è valido con i valori corretti per nome utente e password.
Failed to connect to Oracle NoSQL Database Cloud Service	Il migratore non è stato in grado di stabilire una connessione con Oracle NoSQL Database Cloud Service.	Verificare se l'URL dell'endpoint o il nome dell'area specificato nel file JSON di configurazione è corretto. Controllare se il file delle credenziali OCI è disponibile nel percorso specificato nel file JSON di configurazione. Assicurarsi che le credenziali OCI fornite nelle credenziali OCI siano valide.
Table not found	Impossibile individuare la tabella identificata per la migrazione da NoSQL Migrator database.	Per la fonte: Verificare se la tabella è presente nel database di origine. Assicurarsi che la tabella sia qualificata con il relativo spazio di nomi nel file JSON di configurazione, se la tabella viene creata in uno spazio di nomi non predefinito. Verificare di disporre dell'autorizzazione di lettura/scrittura necessaria per accedere alla tabella. Se l'origine è Oracle NoSQL Database Cloud Service, verificare se il nome del compartimento valido è specificato nel file JSON di configurazione e assicurarsi di disporre dell'autorizzazione necessaria per accedere alla tabella. Per il lavandino: Verificare se la tabella è presente nel lavandino. Se non esiste, è necessario creare la tabella manualmente oppure utilizzare la configurazione schemaInfo per crearla mediante la migrazione.
DDL Execution failed	I comandi DDL forniti nel file di definizione dello schema di input non sono validi.	Controllare la sintassi dei comandi DDL nel file schemaPath. Assicurarsi che nel file schemaPath sia presente una sola istruzione DDL per riga.
failed to write record to the sink table with java.lang.IllegalArgumentException	Il record di input non corrisponde allo schema tabella del sink.	Controllare se i tipi di dati e i nomi di colonna specificati nella tabella sink di destinazione corrispondono allo schema della tabella sink. Se è stata applicata una trasformazione, verificare se i record trasformati corrispondono allo schema della tabella sink.
Request timeout	L'operazione dell'origine o del sink non è stata completata nel tempo previsto.	Verificare la connessione di rete. Controllare se il database NoSQL è attivo e in esecuzione. Provare ad aumentare il valore requestTimeout nel file JSON di configurazione.

Cosa devo considerare prima di riavviare una migrazione non riuscita?

Quando un task di migrazione dei dati non riesce, il sink si trova in uno stato intermedio contenente i dati importati fino al punto di errore. È possibile identificare i dettagli dell'errore e dell'errore dai log e riavviare la migrazione dopo aver diagnosticato e corretto l'errore. Una migrazione riavviata ricomincia, elaborando tutti i dati dall'inizio. Non è possibile eseguire il checkpoint e riavviare la migrazione dal punto di errore. Pertanto, NoSQL Migrator database sovrascrive qualsiasi record di cui è già stata eseguita la migrazione nel sink.

La migrazione è troppo lenta. Come posso velocizzarlo?

Il tempo impiegato per la migrazione dei dati dipende da più fattori, ad esempio il volume di dati di cui viene eseguita la migrazione, la velocità della rete e il carico corrente sul database. Nel caso di un servizio cloud, la velocità di migrazione dipende anche dal throughput di lettura e dal throughput di scrittura di cui è stato eseguito il provisioning. Quindi, per migliorare la velocità di migrazione, puoi:

• Prova a ridurre il carico di lavoro corrente su Oracle NoSQL Database durante la migrazione dei dati.
• Assicurarsi che il computer che esegue la migrazione, l'origine e il sink sia posizionato nello stesso data center e che le latenze di rete siano minime.
• Nel caso di Oracle NoSQL Database Cloud Service, eseguire il provisioning di throughput di lettura/scrittura elevato e verificare se lo storage allocato per la tabella è sufficiente o meno. Se NoSQL Database Migrator non sta creando la tabella, è possibile aumentare il throughput di scrittura. Se il migratore sta creando la tabella, considerare di specificare un valore superiore per il parametro schemaInfo.writeUnits nella configurazione del sink. Una volta completata la migrazione dei dati, è possibile ridurre questo valore. Tenere presenti i limiti giornalieri delle modifiche al throughput. Vedere Limiti cloud e Modelli di configurazione del collegamento.

Ho una migrazione con tempi di esecuzione lunghi che coinvolge set di dati enormi. Come posso tenere traccia dell'avanzamento della migrazione?

È possibile abilitare la registrazione aggiuntiva per tenere traccia dell'avanzamento di una migrazione con tempi di esecuzione lunghi. Per controllare il funzionamento del log di Oracle NoSQL Database Migrator, è necessario impostare il livello di log desiderato nel file logging.properties. Questo file viene fornito con il package NoSQL Database Migrator e disponibile nella directory in cui è stato decompresso Oracle NoSQL Database Migrator. I diversi livelli di log sono OFF, SEVERE, WARNING, INFO, FINE, e ALL in ordine di dettaglio crescente. L'impostazione del livello di log su OFF disattiva tutte le informazioni di log, mentre l'impostazione del livello di log su ALL fornisce le informazioni complete sul log. Il livello di log predefinito è WARNING. Tutto l'output di log è configurato per passare alla console per impostazione predefinita. È possibile visualizzare i commenti nel file logging.properties per conoscere ogni livello di log.

---

Titolo e informazioni sul copyright

Riferimento per Oracle NoSQL Database Migrator

Copyright ©2022,2024,

Oracle e/o relative consociate.