Uso di Oracle NoSQL Database Migrator
Scopri di più su Oracle NoSQL Database Migrator e su come utilizzarlo per la migrazione dei dati.
Oracle NoSQL Database Migrator è uno strumento che consente di eseguire la migrazione delle tabelle NoSQL di Oracle da un'origine dati a un'altra. Questo strumento può essere utilizzato su tabelle in Oracle NoSQL Database Cloud Service, Oracle NoSQL Database on premise e AWS S3. Lo strumento Migrator supporta diversi formati di dati e tipi di supporti fisici. I formati di dati supportati sono i file JSON, Parquet, JSON in formato MongoDB, JSON in formato DynamoDB e CSV. I tipi di supporto fisici supportati sono file, OCI Object Storage, Oracle NoSQL Database on-premise, Oracle NoSQL Database Cloud Service e AWS S3.
Questo articolo contiene i seguenti argomenti:
Argomenti correlati
Panoramica
Oracle NoSQL Database Migrator consente di spostare le tabelle NoSQL di Oracle da un'origine dati a un'altra, ad esempio Oracle NoSQL Database on-premise o nel cloud o persino un semplice file JSON.
In molti casi è necessario eseguire la migrazione delle tabelle NoSQL da o a un Oracle NoSQL Database. Ad esempio, un team di sviluppatori che migliora un'applicazione NoSQL Database potrebbe voler eseguire il test del codice aggiornato nell'istanza locale di Oracle NoSQL Database Cloud Service (NDCS) utilizzando cloudim. Per verificare tutti i casi di prova possibili, devono impostare i dati di prova simili ai dati effettivi. A tale scopo, devono copiare le tabelle NoSQL dall'ambiente di produzione all'istanza NDCS locale, l'ambiente cloudim. In un'altra situazione, gli sviluppatori di NoSQL potrebbero dover spostare i dati delle applicazioni da on premise al cloud e viceversa, sia per lo sviluppo che per i test.
In tutti questi casi e in molti altri, puoi utilizzare Oracle NoSQL Database Migrator per spostare le tabelle NoSQL da un'origine dati all'altra, ad esempio Oracle NoSQL Database on premise o cloud o anche un semplice file JSON. È inoltre possibile copiare le tabelle NoSQL da un file di input JSON in formato MongoDB, da un file di input JSON in formato DynamoDB (archiviato nell'origine S3 AWS o dai file) oppure da un file CSV nel database NoSQL in locale o nel cloud.
Come illustrato nella figura riportata di seguito, la utility NoSQL Migrator database funge da connettore o pipe tra l'origine dati e la destinazione (definita sink). In sostanza, questa utility esporta i dati dall'origine selezionata e li importa nel sink. Questo strumento è orientato alle tabelle, ovvero è possibile spostare i dati solo a livello di tabella. Un singolo task di migrazione opera su una singola tabella e supporta la migrazione dei dati di tabella dall'origine al sink in vari formati di dati.
Terminologia utilizzata con Oracle NoSQL Database Migrator
Informazioni dettagliate sui diversi termini utilizzati nel diagramma precedente.
- Origine: entità da cui vengono esportate le tabelle NoSQL per la migrazione. Alcuni esempi di origini sono Oracle NoSQL Database in locale o cloud, file JSON, file JSON in formato MongoDB, file JSON in formato DynamoDB e file CSV.
- Sink: entità che importa le tabelle NoSQL da NoSQL Migrator database. Alcuni esempi di sink sono Oracle NoSQL Database on premise o file cloud e JSON.
Lo strumento NoSQL Migrator database supporta diversi tipi di origini e sink (ovvero supporti fisici o repository di dati) e formati di dati (ovvero il modo in cui i dati vengono rappresentati nell'origine o nel sink). I formati di dati supportati sono i file JSON, Parquet, JSON in formato MongoDB, JSON in formato DynamoDB e CSV. I tipi di origine e sink supportati sono file, OCI Object Storage, Oracle NoSQL Database on premise e Oracle NoSQL Database Cloud Service.
- Pipe di migrazione: i dati di un'origine verranno trasferiti al sink da NoSQL Database Migrator. Può essere visualizzata come pipe di migrazione.
- Trasformazioni: è possibile aggiungere regole per modificare i dati della tabella NoSQL nella pipe di migrazione. Queste regole sono chiamate trasformazioni. Oracle NoSQL Database Migrator consente le trasformazioni dei dati solo nei campi o nelle colonne di livello superiore. Non consente di trasformare i dati nei campi nidificati. Alcuni esempi di trasformazioni consentite sono:
- Eliminare o ignorare una o più colonne,
- Rinominare una o più colonne oppure
- Aggrega diverse colonne in un singolo campo, in genere un campo JSON.
- File di configurazione: un file di configurazione consente di definire tutti i parametri necessari per l'attività di migrazione in formato JSON. Successivamente, si passa questo file di configurazione come singolo parametro al comando
runMigratordall'interfaccia CLI. Un tipico formato di file di configurazione è simile a quello mostrato di seguito.{ "source": { "type" : <source type>, //source-configuration for type. See Source Configuration Templates . }, "sink": { "type" : <sink type>, //sink-configuration for type. See Sink Configuration Templates . }, "transforms" : { //transforms configuration. See Transformation Configuration Templates . }, "migratorVersion" : "<migrator version>", "abortOnError" : <true|false> }Raggruppa Parametri Obbligatorio (S/N) Scopo Valori supportati sourcetypeY Rappresenta l'origine da cui eseguire la migrazione dei dati. L'origine fornisce dati e metadati (se presenti) per la migrazione. Per conoscere il valore typeper ogni origine, vedere Origini e lavandini supportati.sourceconfigurazione-origine per il tipo Y Definisce la configurazione per l'origine. Questi parametri di configurazione sono specifici del tipo di origine selezionato in precedenza. Per l'elenco completo dei parametri di configurazione per ciascun tipo di origine, vedere Modelli di configurazione di origine. sinktypeY Rappresenta il sink in cui eseguire la migrazione dei dati. Il sink è la destinazione o la destinazione per la migrazione. Per conoscere il valore typeper ogni origine, vedere Origini e lavandini supportati.sinksink-configuration per il tipo Y Definisce la configurazione per il sink. Questi parametri di configurazione sono specifici del tipo di sink selezionato in precedenza. Per l'elenco completo dei parametri di configurazione per ciascun tipo di sink, vedere Modelli di configurazione del sink. transformsconfigurazione trasformazioni N Definisce le trasformazioni da applicare ai dati nella pipe di migrazione. Per l'elenco completo delle trasformazioni supportate da NoSQL Data Migrator, vedere Modelli di configurazione della trasformazione. - migratorVersionN Versione di NoSQL Data Migrator - - abortOnErrorN Specifica se arrestare o meno l'attività di migrazione in caso di errore.
Il valore predefinito è true, che indica che la migrazione si interrompe ogni volta che si verifica un errore di migrazione.
Se si imposta questo valore su false, la migrazione continua anche in caso di record non riusciti o di altri errori di migrazione. I record non riusciti e gli errori di migrazione verranno registrati come WARNINGs sul terminale CLI.
true, false Nota
Poiché il file JSON distingue tra maiuscole e minuscole, tutti i parametri definiti nel file di configurazione fanno distinzione tra maiuscole e minuscole, a meno che non sia specificato diversamente.
Fonti e lavandini supportati
In questo argomento viene fornita la lista delle origini e dei sink supportati dall'Oracle NoSQL Database Migrator.
È possibile utilizzare qualsiasi combinazione di origine e sink valida da questa tabella per l'attività di migrazione. Tuttavia, è necessario assicurarsi che almeno una delle estremità, ovvero l'origine o il sink, debba essere un prodotto Oracle NoSQL. Non è possibile utilizzare NoSQL Migrator database per spostare i dati della tabella NoSQL da un file a un altro.
|
Tipo |
Formato |
Origine valida | Lavello valido |
|---|---|---|---|
|
Oracle NoSQL Database |
ND | Y | Y |
|
Oracle NoSQL Database Cloud Service |
ND | Y | Y |
|
File system |
JSON |
Y | Y |
|
MongoDB JSON |
Y | N | |
|
DynamoDB JSON |
Y | N | |
|
Parquet( |
N | Y | |
|
CSV |
Y | N | |
|
Storage degli oggetti OCI |
JSON |
Y | Y |
|
MongoDB JSON |
Y | N | |
|
Parquet( |
N | Y | |
|
CSV |
Y | N | |
| AWS S3 |
DynamoDB JSON |
Y | N |
Nota
Molti parametri di configurazione sono comuni nella configurazione di origine e sink. Per facilità di riferimento, la descrizione di tali parametri viene ripetuta per ogni sorgente e sink nelle sezioni della documentazione, che spiegano i formati dei file di configurazione per vari tipi di sorgenti e sink. In tutti i casi, la sintassi e la semantica dei parametri con lo stesso nome sono identiche.Sicurezza origine e lavandino
Alcuni tipi di origine e sink dispongono di informazioni di sicurezza facoltative o obbligatorie per l'autenticazione.
Tutte le origini e i sink che utilizzano i servizi in Oracle Cloud Infrastructure (OCI) possono utilizzare determinati parametri per fornire informazioni di sicurezza opzionali. Queste informazioni possono essere fornite utilizzando un file di configurazione o un principal dell'istanza OCI.
Le origini e i sink di Oracle NoSQL Database richiedono informazioni di sicurezza obbligatorie se l'installazione è sicura e utilizza un'autenticazione basata su Oracle Wallet. Queste informazioni possono essere fornite aggiungendo un file jar alla directory <MIGRATOR_HOME>/lib.
Autenticazione basata su wallet
Se un'installazione di Oracle NoSQL Database utilizza l'autenticazione basata su Oracle Wallet, è necessario un file jar aggiuntivo che faccia parte dell'installazione EE. Per ulteriori informazioni, vedere Oracle Wallet.
Senza questo file jar, verrà visualizzato il seguente messaggio di errore:
Impossibile trovare kvstore-ee.jar nella directory lib. Copiare kvstore-ee.jar nella directory lib.
kvstore-ee.jar dal package server EE nella directory <MIGRATOR_HOME>/lib. <MIGRATOR_HOME> è la directory nosql-migrator-M.N.O/ creata estraendo il package Oracle NoSQL Database Migrator e M.N.O rappresenta i numeri release.major.minor del software. Ad esempio, nosql-migrator-1.1.0/lib.
Nota
L'autenticazione basata su wallet è supportata SOLO nella Enterprise Edition (EE) di Oracle NoSQL Database.Autenticazione con i principal dell'istanza
I principal delle istanze sono una funzione del servizio IAM che consente agli attori o ai principal autorizzati di eseguire azioni sulle risorse del servizio. Ogni istanza di computazione dispone di una propria identità ed esegue l'autenticazione utilizzando i certificati aggiunti.
Oracle NoSQL Database Migrator offre un'opzione per connettersi a un cloud NoSQL e a origini e sink di storage degli oggetti OCI utilizzando l'autenticazione del principal dell'istanza. È supportato solo quando lo strumento NoSQL Migrator di database viene utilizzato all'interno di un'istanza di computazione OCI, ad esempio lo strumento NoSQL Database Migrator in esecuzione in una VM ospitata su OCI. Per abilitare questa funzione, utilizzare l'attributo useInstancePrincipal del file di configurazione dell'origine e del sink del cloud NoSQL. Per ulteriori informazioni sui parametri di configurazione per diversi tipi di origini e lavandini, vedere Modelli di configurazione di origine e Modelli di configurazione del lavandino.
Per ulteriori informazioni sui principal delle istanze, vedere Chiamata di servizi da un'istanza.
Flusso di lavoro per Oracle NoSQL Database Migrator
Scopri i vari passi necessari per utilizzare la utility Oracle NoSQL Database Migrator per la migrazione dei dati NoSQL.
Nella figura riportata di seguito viene illustrato il flusso di task di alto livello coinvolti nell'utilizzo di NoSQL Migrator database.
Scarica la utility NoSQL Data Migrator
runMigrator dall'interfaccia della riga di comando.
Nota
La utility Oracle NoSQL Database Migrator richiede l'esecuzione di Java 11 o versioni successive.Identificare l'origine e il lavandino
- Identifica schema tabella sink: se il sink è Oracle NoSQL Database in locale o nel cloud, è necessario identificare lo schema per la tabella sink e assicurarsi che i dati di origine corrispondano allo schema di destinazione. Se necessario, utilizzare le trasformazioni per mappare i dati di origine alla tabella sink.
- Schema predefinito: NoSQL Database Migrator fornisce un'opzione per creare una tabella con lo schema predefinito senza dover definire preventivamente lo schema per la tabella. Ciò è utile soprattutto quando si caricano file di origine JSON in Oracle NoSQL Database.
Se l'origine è un file JSON in formato MongoDB, lo schema predefinito per la tabella sarà il seguente:
CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))dove:
- tablename = valore fornito per l'attributo tabella nella configurazione.
- ID = valore _id da ogni documento del file di origine JSON esportato mongoDB.
- DOCUMENT = Per ogni documento nel file esportato mongoDB, i contenuti esclusi il campo _id vengono aggregati nella colonna DOCUMENT.
Se l'origine è un file JSON in formato DynamoDB, lo schema predefinito per la tabella sarà il seguente:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type],DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))dove:
- TABLE_NAME = valore fornito per la tabella sink nella configurazione
- DDBPartitionKey_name = valore fornito per la chiave di partizione nella configurazione
- DDBPartitionKey_type = valore fornito per il tipo di dati della chiave di partizione nella configurazione
- DDBSortKey_name = valore fornito per la chiave di ordinamento nella configurazione, se presente
- DDBSortKey_type = valore fornito per il tipo di dati della chiave di ordinamento nella configurazione, se presente
- DOCUMENT = Tutti gli attributi tranne la partizione e la chiave di ordinamento di un elemento tabella Dynamo DB aggregato in una colonna JSON NoSQL
Se il formato di origine è un file CSV, uno schema predefinito non è supportato per la tabella di destinazione. È possibile creare un file di schema con una definizione di tabella contenente lo stesso numero di colonne e tipi di dati del file CSV di origine. Per ulteriori dettagli sulla creazione del file di schema, vedere Fornitura dello schema tabella.
Per tutte le altre origini, lo schema predefinito sarà il seguente:CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))dove:
- tablename = valore fornito per l'attributo tabella nella configurazione.
- ID = un valore LONG generato automaticamente.
- DOCUMENT = Il record JSON fornito dall'origine viene aggregato nella colonna DOCUMENT.Nota
Se il valore _id non viene fornito come stringa nel file JSON in formato MongoDB, NoSQL Database Migrator lo converte in una stringa prima di inserirlo nello schema predefinito.
- Schema predefinito: NoSQL Database Migrator fornisce un'opzione per creare una tabella con lo schema predefinito senza dover definire preventivamente lo schema per la tabella. Ciò è utile soprattutto quando si caricano file di origine JSON in Oracle NoSQL Database.
- Fornitura dello schema tabella: NoSQL Migrator database consente all'origine di fornire definizioni di schema per i dati della tabella utilizzando l'attributo schemaInfo. L'attributo schemaInfo è disponibile in tutte le origini dati per le quali non è già stato definito uno schema implicito. I data store del lavandino possono scegliere una delle seguenti opzioni.
- Utilizzare lo schema predefinito definito da NoSQL Migrator database.
- Utilizzare lo schema fornito dall'origine.
- Eseguire l'override dello schema fornito dall'origine definendone il proprio schema. Ad esempio, se si desidera trasformare i dati dallo schema di origine in un altro schema, è necessario sostituire lo schema fornito dall'origine e utilizzare la funzionalità di trasformazione dello strumento NoSQL Migrator database.
Il file di schema della tabella, ad esempiomytable_schema.ddl, può includere le istruzioni DDL della tabella. Lo strumento NoSQL Migrator database esegue questo file di schema tabella prima di avviare la migrazione. Lo strumento di migrazione supporta non più di un'istruzione DDL per riga nel file di schema. Di seguito sono riportati alcuni esempi.CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))Nota
La migrazione non riuscirà se la tabella è presente nel sink e la DDL inschemaPathè diversa dalla tabella. - Crea tabella sink: una volta identificato lo schema della tabella sink, creare la tabella sink tramite l'interfaccia CLI di amministrazione o utilizzando l'attributo
schemaInfodel file di configurazione sink. Vedere Modelli di configurazione del lavandino.Nota
Se l'origine è un file CSV, creare un file con i comandi DDL per lo schema della tabella di destinazione. Fornire il percorso del file nel parametro schemaInfo.schemaPath del file di configurazione del sink.
Migrazione dei metadati TTL per le righe tabella
Nota
Il supporto per la migrazione dei metadati TTL per le righe di tabella è solo disponibile per Oracle NoSQL Database e Oracle NoSQL Database Cloud Service.Importazione di metadati TTL
_metadata per ogni riga esportata. NoSQL Migrator database esporta l'ora di scadenza per ogni riga come numero di millisecondi dall'epoca UNIX (1° gennaio 1970). Di seguito sono riportati alcuni esempi.//Row 1
{
"id" : 1,
"name" : "xyz",
"age" : 45,
"_metadata" : {
"expiration" : 1629709200000 //Row Expiration time in milliseconds
}
}
//Row 2
{
"id" : 2,
"name" : "abc",
"age" : 52,
"_metadata" : {
"expiration" : 1629709400000 //Row Expiration time in milliseconds
}
}
//Row 3 No Metadata for below row as it will not expire
{
"id" : 3,
"name" : "def",
"age" : 15
}Importazione dei metadati TTL
Facoltativamente, è possibile importare i metadati TTL utilizzando un parametro di configurazione, includeTTL. L'operazione di importazione gestisce i casi d'uso riportati di seguito durante la migrazione delle righe di tabella contenenti metadati TTL. Questi casi d'uso sono applicabili solo quando viene specificato il parametro di configurazione includeTTL.
- Caso d'uso 1: nella riga della tabella di importazione non sono presenti informazioni sui metadati TTL.
Quando si importa un file di origine JSON prodotto da un'origine esterna o esportato utilizzando versioni precedenti del migratore, la riga di importazione non dispone di informazioni TTL. Tuttavia, poiché il parametro di configurazione includeTTL è uguale a
true, il migratore ha impostato TTL=0 per la riga della tabella, il che significa che la riga della tabella di importazione non scade mai. - Caso d'uso 2: il valore TTL della riga della tabella di origine è scaduto rispetto al tempo di riferimento quando la riga della tabella viene importata.
Quando si esporta una riga di tabella in un file e si tenta di importarla dopo l'ora di scadenza della riga di tabella, la riga di tabella viene ignorata e non viene scritta nell'area di memorizzazione.
- Caso d'uso 3: il valore TTL della riga della tabella di origine non è scaduto rispetto al tempo di riferimento quando la riga della tabella viene importata.
Quando si esporta una riga di tabella in un file e si tenta di importarla prima dell'ora di scadenza della riga di tabella, la riga di tabella viene importata con un valore TTL. Il nuovo valore TTL per la riga della tabella potrebbe tuttavia non essere uguale al valore TTL esportato a causa dei vincoli della finestra di ore e giorni interi nella classe TimeToLive. Di seguito sono riportati alcuni esempi.
Riga tabella esportata{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC } }Il tempo di riferimento durante l'importazione è 1629707962582, che è lunedì 23 agosto 2021 8:39:22.582 AM.
Riga della tabella importata{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC } }
Importazione dei dati in un sink con una colonna IDENTITY
È possibile importare i dati da un'origine valida in una tabella sink (On premise/Cloud Services) con una colonna IDENTITY. La colonna IDENTITÀ viene creata come GENERATA SEMPRE COME IDENTITÀ o GENERATA DA IDENTITÀ PREDEFINITA. Per ulteriori informazioni sulla creazione di tabelle con una colonna IDENTITY, vedere Creazione di tabelle con una colonna IDENTITY nel manuale SQL Reference Guide (in lingua inglese).
Prima di importare i dati, assicurarsi che la tabella Oracle NoSQL Database nel sink sia vuota se esiste. Se nella tabella sink sono presenti dati preesistenti, la migrazione può causare problemi quali la sovrascrittura dei dati esistenti nella tabella sink o l'omissione dei dati di origine durante l'importazione.
Tabella lavandino con colonna IDENTITÀ GENERATA SEMPRE COME IDENTITÀ
Considerare una tabella sink con la colonna IDENTITY creata come GENERATA SEMPRE COME IDENTITÀ. L'importazione dei dati dipende dal fatto che l'origine fornisca o meno i valori alla colonna IDENTITY e al parametro di trasformazione ignoreFields nel file di configurazione.
Ad esempio, si desidera importare i dati da un'origine file JSON nella tabella Oracle NoSQL Database come sink. Lo schema della tabella sink è:
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Condizione di origine | Azione utente | Risultato migrazione |
|---|---|---|
|
CASO 1: i dati di origine non forniscono un valore per il campo IDENTITY della tabella sink. Esempio: file di origine JSON |
Creare/generare il file di configurazione. |
Impossibile eseguire la migrazione dei dati. I valori delle colonne IDENTITY vengono generati automaticamente. Dati migrati nella tabella sink di Oracle NoSQL Database |
|
CASO 2: i dati di origine forniscono valori per il campo IDENTITY della tabella sink. Esempio: file di origine JSON |
Creare/generare il file di configurazione. Fornire una trasformazione ignoreFields per la colonna ID nel modello di configurazione sink.
|
Impossibile eseguire la migrazione dei dati. I valori ID forniti vengono ignorati e i valori della colonna IDENTITY vengono generati automaticamente. Dati migrati nella tabella sink di Oracle NoSQL Database
migrateID: |
|
Il file di configurazione viene creato o generato senza la trasformazione ignoreFields per la colonna IDENTITY. |
Migrazione dei dati non riuscita con il seguente messaggio di errore: "Cannot set value for a generated always identity column". |
Per ulteriori dettagli sui parametri di configurazione della trasformazione, vedere l'argomento Modelli di configurazione della trasformazione.
Tabella lavandino con colonna IDENTITÀ GENERATA DA PREDEFINITO COME IDENTITÀ
Considerare una tabella sink con la colonna IDENTITY creata come GENERATA DA PREDEFINITO COME IDENTITÀ. L'importazione dei dati dipende dal fatto che l'origine fornisca o meno i valori alla colonna IDENTITY e al parametro di trasformazione ignoreFields.
Ad esempio, si desidera importare i dati da un'origine file JSON nella tabella Oracle NoSQL Database come sink. Lo schema della tabella sink è:
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Condizione di origine | Azione utente | Risultato migrazione |
|---|---|---|
|
CASO 1: i dati di origine non forniscono un valore per il campo IDENTITY della tabella sink. Esempio: file di origine JSON |
Creare/generare il file di configurazione. |
Impossibile eseguire la migrazione dei dati. I valori delle colonne IDENTITY vengono generati automaticamente. Dati migrati nella tabella sink di Oracle NoSQL Database
migrateID: |
|
CASO 2: i dati di origine forniscono valori per il campo IDENTITY della tabella sink ed è un campo Chiave primaria. Esempio: file di origine JSON |
Creare/generare il file di configurazione. Fornire una trasformazione ignoreFields per la colonna ID nel modello di configurazione sink (consigliato).
|
Impossibile eseguire la migrazione dei dati. I valori ID forniti vengono ignorati e i valori della colonna IDENTITY vengono generati automaticamente. Dati migrati nella tabella sink di Oracle NoSQL Database
migrateID: |
|
Il file di configurazione viene creato o generato senza la trasformazione ignoreFields per la colonna IDENTITY. |
Impossibile eseguire la migrazione dei dati. I valori Quando si tenta di inserire una riga aggiuntiva nella tabella senza fornire un valore ID, il generatore di sequenze tenta di generare automaticamente il valore ID. Il valore di partenza del generatore di sequenze è 1. Di conseguenza, il valore ID generato può potenzialmente duplicare uno dei valori ID esistenti nella tabella sink. Poiché si tratta di una violazione del vincolo della chiave primaria, viene restituito un errore e la riga non viene inserita. Per ulteriori informazioni, vedere Generatore di sequenze. Per evitare la violazione del vincolo della chiave primaria, il generatore di sequenze deve avviare la sequenza con un valore che non sia in conflitto con i valori ID esistenti nella tabella sink. Per utilizzare l'attributo START WITH per apportare questa modifica, vedere l'esempio riportato di seguito. Esempio: dati migrati nella tabella sink di Oracle NoSQL Database
migrateID:Per trovare il valore appropriato per il generatore di sequenze da inserire nella colonna ID, recuperare il valore massimo del campo
ID utilizzando la seguente query:Output:
Il valore massimo della colonna
ID nella tabella sink è 3. Si desidera che il generatore di sequenze inizi a generare i valori ID oltre 3 per evitare la duplicazione. L'attributo START WITH del generatore di sequenze viene aggiornato su 4 utilizzando la seguente istruzione:La sequenza inizierà a 4. Quando si inseriscono righe nella tabella sink senza fornire i valori ID, il generatore di sequenze genera automaticamente i valori ID da 4 in poi evitando la duplicazione degli ID. |
Per ulteriori dettagli sui parametri di configurazione della trasformazione, vedere l'argomento Modelli di configurazione della trasformazione.
Eseguire il comando runMigrator
Il file eseguibile runMigrator è disponibile nei file estratti di NoSQL Database Migrator. Per eseguire correttamente il comando runMigrator è necessario installare Java 11 o versione successiva e bash sul sistema.
runMigrator in due modi:
- Creando il file di configurazione utilizzando le opzioni di runtime del comando
runMigratorcome mostrato di seguito.[~]$ ./runMigrator configuration file is not provided. Do you want to generate configuration? (y/n) [n]: y ... ...- Quando si richiama la utility
runMigrator, viene fornita una serie di opzioni di runtime e viene creato il file di configurazione in base alle scelte effettuate per ciascuna opzione. - Dopo che la utility ha creato il file di configurazione, è possibile scegliere se procedere con l'attività di migrazione nella stessa esecuzione o salvare il file di configurazione per una migrazione futura.
- Indipendentemente dalla decisione di procedere o differire l'attività di migrazione con il file di configurazione generato, il file sarà disponibile per le modifiche o la personalizzazione per soddisfare i requisiti futuri. È possibile utilizzare il file di configurazione personalizzato per la migrazione in un secondo momento.
- Quando si richiama la utility
- Passando un file di configurazione creato manualmente (in formato JSON) come parametro runtime utilizzando l'opzione
-co--config. È necessario creare il file di configurazione manualmente prima di eseguire il comandorunMigratorcon le opzioni-co--config. Per assistenza sui parametri di configurazione di origine e sink, consultare Oracle NoSQL Database Migrator Reference.[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
Avanzamento migrazione log
Lo strumento NoSQL Migrator di database fornisce opzioni che consentono di stampare messaggi di trace, debug e avanzamento su un output standard o su un file. Questa opzione può essere utile per tenere traccia dell'avanzamento dell'operazione di migrazione, in particolare per tabelle o data set di grandi dimensioni.
- Livelli di log
Per controllare il funzionamento del log mediante lo strumento NoSQL Migrator database, passare il parametro --log-level o -l run time al comando
runMigrator. È possibile specificare la quantità di informazioni di log da scrivere passando il valore del livello di log appropriato.$./runMigrator --log-level <loglevel>Esempio:$./runMigrator --log-level debugTabella - Livelli di log supportati per NoSQL Migrator del database
Livello di log Descrizione avvertenza Stampa errori e avvisi. informazioni (predefinite) Stampa lo stato di avanzamento della migrazione dei dati, ad esempio la convalida dell'origine, la convalida del sink, la creazione di tabelle e il conteggio del numero di record di dati migrati. debug Visualizza ulteriori informazioni di debug. all Stampa tutto. Questo livello attiva tutti i livelli di registrazione. - File di log:
È possibile specificare il nome del file di log utilizzando il parametro --log-file o -f. Se --log-file viene passato come parametro di runtime al comando
runMigrator, NoSQL Database Migrator scrive tutti i messaggi di log nel file e nell'output standard.$./runMigrator --log-file <log file name>Esempio:$./runMigrator --log-file nosql_migrator.log
Dimostrazioni sui casi d'uso per Oracle NoSQL Database Migrator
Scopri come eseguire la migrazione dei dati utilizzando Oracle NoSQL Database Migrator per casi d'uso specifici. È possibile trovare istruzioni sistematiche dettagliate con esempi di codice per eseguire la migrazione in ciascuno dei casi d'uso.
Questo articolo contiene i seguenti argomenti:
Eseguire la migrazione da Oracle NoSQL Database Cloud Service a un file JSON
Questo esempio mostra come utilizzare Oracle NoSQL Database Migrator per copiare i dati e la definizione dello schema di una tabella NoSQL da Oracle NoSQL Database Cloud Service (NDCS) a un file JSON.
Caso d'uso
Un'organizzazione decide di addestrare un modello utilizzando i dati Oracle NoSQL Database Cloud Service (NDCS) per prevedere comportamenti futuri e fornire consigli personalizzati. Possono prendere una copia periodica dei dati delle tabelle NDCS in un file JSON e applicarlo al motore di analisi per analizzare e addestrare il modello. In questo modo è possibile separare le query analitiche dai percorsi critici a bassa latenza.
Esempio
Per la dimostrazione, esaminiamo come eseguire la migrazione dei dati e della definizione dello schema di una tabella NoSQL denominatamyTable da NDCS a un file JSON.- Identifica l'origine e il sink per la migrazione.
- Origine: Oracle NoSQL Database Cloud Service
- Lavello: file JSON
- Identificare le credenziali cloud OCI e acquisirle nel file di configurazione OCI. Salvare il file di configurazione in
/home/.oci/config. Vedere Acquisizione delle credenziali.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identificare l'endpoint dell'area e il nome del compartimento per Oracle NoSQL Database Cloud Service.
- endpoint:
us-phoenix-1 - compartimento:
developers
- endpoint:
myTable da Oracle NoSQL Database Cloud Service a un file JSON, effettuare le operazioni riportate di seguito.
Per convalidare la migrazione, è possibile aprire i file JSON Sink e visualizzare lo schema e i dati.
-- Exported myTable Data
[~/nosqlMigrator]$cat myTableJSON
{
"id" : 10,
"document" : {
"course" : "Computer Science",
"name" : "Neena",
"studentid" : 105
}
}
{
"id" : 3,
"document" : {
"course" : "Computer Science",
"name" : "John",
"studentid" : 107
}
}
{
"id" : 4,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 6,
"document" : {
"course" : "Bio-Technology",
"name" : "Rekha",
"studentid" : 104
}
}
{
"id" : 7,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 5,
"document" : {
"course" : "Journalism",
"name" : "Rani",
"studentid" : 106
}
}
{
"id" : 8,
"document" : {
"course" : "Computer Science",
"name" : "Tom",
"studentid" : 103
}
}
{
"id" : 9,
"document" : {
"course" : "Computer Science",
"name" : "Peter",
"studentid" : 109
}
}
{
"id" : 1,
"document" : {
"course" : "Journalism",
"name" : "Tracy",
"studentid" : 110
}
}
{
"id" : 2,
"document" : {
"course" : "Bio-Technology",
"name" : "Raja",
"studentid" : 108
}
}-- Exported myTable Schema
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))Eseguire la migrazione da Oracle NoSQL Database in locale a Oracle NoSQL Database Cloud Service
Questo esempio mostra come utilizzare Oracle NoSQL Database Migrator per copiare i dati e la definizione dello schema di una tabella NoSQL da Oracle NoSQL Database a Oracle NoSQL Database Cloud Service (NDCS).
Caso d'uso
Gli sviluppatori stanno esplorando le opzioni per evitare il sovraccarico della gestione delle risorse, dei cluster e della garbage collection per i carichi di lavoro NoSQL Database KVStore esistenti. Come soluzione, decidi di eseguire la migrazione dei carichi di lavoro KVStore on-premise esistenti in Oracle NoSQL Database Cloud Service perché NDCS li gestisce automaticamente.
Esempio
Per la dimostrazione, esaminiamo come eseguire la migrazione dei dati e della definizione dello schema di una tabella NoSQL denominatamyTable dal database NoSQL KVStore a NDCS. Questo caso d'uso verrà inoltre utilizzato per mostrare come eseguire la utility runMigrator passando un file di configurazione precreato.- Identifica l'origine e il sink per la migrazione.
- Origine: Oracle NoSQL Database
- Lavello: Oracle NoSQL Database Cloud Service
- Identificare le credenziali cloud OCI e acquisirle nel file di configurazione OCI. Salvare il file di configurazione in
/home/.oci/config. Vedere Acquisizione delle credenziali in Uso di Oracle NoSQL Database Cloud Service.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identificare l'endpoint dell'area e il nome del compartimento per Oracle NoSQL Database Cloud Service.
- endpoint:
us-phoenix-1 - compartimento:
developers
- endpoint:
- Identificare i seguenti dettagli per KVStore in locale:
- storeName:
kvstore - helperHosts:
<hostname>:5000 - tabella:
myTable
- storeName:
myTable dal database NoSQL KVStore a NDCS:
Per convalidare la migrazione, è possibile eseguire il login alla console NDCS e verificare che myTable sia stato creato con i dati di origine.
Eseguire la migrazione dall'origine file JSON a Oracle NoSQL Database Cloud Service
Questo esempio mostra l'uso di Oracle NoSQL Database Migrator per copiare i dati da un'origine file JSON a Oracle NoSQL Database Cloud Service.
Dopo aver valutato più opzioni, un'organizzazione finalizza Oracle NoSQL Database Cloud Service come piattaforma di database NoSQL. Poiché i contenuti di origine sono in formato file JSON, stanno cercando un modo per eseguirne la migrazione a Oracle NoSQL Database Cloud Service.
In questo esempio verrà descritto come eseguire la migrazione dei dati da un file JSON denominato SampleData.json. Per eseguire la utility runMigrator, passare un file di configurazione già creato. Se il file di configurazione non viene fornito come parametro runtime, la utility runMigrator richiede di generare la configurazione mediante una procedura interattiva.
- Identifica l'origine e il sink per la migrazione.
- Origine: file di origine JSON.
SampleData.jsonè il file di origine. Contiene più documenti JSON con un documento per riga, delimitati da un nuovo carattere di riga.{"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-03-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-02T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-02T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-02T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":7,"val_json":{"array":["a","b","c"],"date":"2023-02-20T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-01-20T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-01-22T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":4,"val_json":{"array":["j","k","l"],"date":"2023-02-03T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-03T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-02-03T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} - Lavandino: Oracle NoSQL Database Cloud Service.
- Origine: file di origine JSON.
- Identificare le credenziali cloud OCI e acquisirle nel file di configurazione. Salvare il file di configurazione in
/home/user/.oci/config. Per ulteriori dettagli, vedere Acquisizione delle credenziali in Uso di Oracle NoSQL Database Cloud Service.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... region=us-ashburn-1 key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identificare l'endpoint dell'area e il nome del compartimento per Oracle NoSQL Database Cloud Service.
- endpoint:
us-ashburn-1 - compartimento:
Training-NoSQL
- endpoint:
- Identificare i seguenti dettagli per il file di origine JSON:
-
schemaPath:
<absolute path to the schema definition file containing DDL statements for the NoSQL table at the sink>.In questo esempio, il file DDL èschema_json.ddl.create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id));Oracle NoSQL Database Migrator fornisce un'opzione per creare una tabella con lo schema predefinito se
schemaPathnon viene fornito. Per ulteriori dettagli, vedere l'argomento relativo all'identificazione dell'origine e del lavandino nel workflow per Oracle NoSQL Database Migrator. - Percorso dati:
<absolute path to a file or directory containing the JSON data for migration>.
-
SampleData.json a Oracle NoSQL Database Cloud Service, effettuare le operazioni riportate di seguito.
Migrate_JSON sia stata creata con i dati di origine. Per la procedura di accesso alla console, vedere l'articolo Accesso al servizio dalla console dell'infrastruttura nel documento Oracle NoSQL Database Cloud Service.
Figura - Tabelle della console di Oracle NoSQL Database Cloud Service
Figura - Dati tabella console di Oracle NoSQL Database Cloud Service
Eseguire la migrazione da un file JSON MongoDB a un Oracle NoSQL Database Cloud Service
In questo esempio viene descritto come utilizzare Oracle NoSQL Database Migrator per copiare i dati formattati Mongo-DB in Oracle NoSQL Database Cloud Service (NDCS).
Caso d'uso
Dopo aver valutato più opzioni, un'organizzazione finalizza Oracle NoSQL Database Cloud Service come piattaforma di database NoSQL. Poiché le tabelle e i dati di NoSQL si trovano in MongoDB, stanno cercando un modo per eseguire la migrazione di tali tabelle e dati in Oracle NDCS.
È possibile copiare un file o una directory contenente i dati JSON esportati MongoDB per la migrazione specificando il file o la directory nel modello di configurazione di origine.
{"_id":0,"name":"Aimee Zank","scores":[{"score":1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}
MongoDB 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.
Esempio
Per la dimostrazione, esaminiamo come migrare un file JSON in formato MongoDB in NDCS. Per questo esempio verrà utilizzato un file di configurazione creato manualmente.- Identifica l'origine e il sink per la migrazione.
- Origine: file JSON MongoDB formattato
- Lavello: Oracle NoSQL Database Cloud Service
- Estrarre i dati da Mongo DB utilizzando la utility mongoexport. Vedere mongoexport.
- Creare una tabella NoSQL nel sink con uno schema di tabella che corrisponda ai dati nel file JSON in formato Mongo-DB. In alternativa, è possibile impostare NoSQL Migrator database per creare una tabella con la struttura di schema predefinita impostando l'attributo
defaultSchemasu true.Nota
Per un'origine MongoDB-Formatted JSON , lo schema predefinito per la tabella sarà il seguente:CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))dove:tablename= valore della configurazione della tabella.ID= valore_iddal file di origine JSON esportato mongoDB.DOCUMENT= L'intero contenuto del file di origine JSON esportato mongoDB viene aggregato nella colonnaDOCUMENT, escluso il campo_id.
- Identificare le credenziali cloud OCI e acquisirle nel file di configurazione OCI. Salva il file di configurazione in
/home/.oci/config. Vedere Acquisizione delle credenziali in Uso di Oracle NoSQL Database Cloud Service.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identificare l'endpoint dell'area e il nome del compartimento per Oracle NoSQL Database Cloud Service.
- endpoint:
us-phoenix-1 - compartimento:
developers
- endpoint:
Per eseguire la migrazione dei dati JSON in formato MongoDB in Oracle NoSQL Database Cloud Service:
Per convalidare la migrazione, è possibile eseguire il login alla console NDCS e verificare che myTable sia stato creato con i dati di origine.
Eseguire la migrazione dal file JSON DynamoDB a Oracle NoSQL Database
Questo esempio mostra come utilizzare Oracle NoSQL Database Migrator per copiare il file JSON DynamoDB in Oracle NoSQL Database.
Caso d'uso:
Dopo aver valutato più opzioni, un'organizzazione finalizza Oracle NoSQL Database sul database DynamoDB. L'organizzazione desidera eseguire la migrazione di tabelle e dati da DynamoDB a Oracle NoSQL Database (on-premise).
Per ulteriori dettagli, vedere Mapping della tabella DynamoDB alla tabella NoSQL di Oracle.
È 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.
{"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"}}}
Copiare i dati della tabella DynamoDB esportati dallo storage AWS S3 in un file system attivato locale.
Esempio:
Per questa demo, imparerai come eseguire la migrazione di un file JSON DynamoDB in Oracle NoSQL Database (on-premise). Per questo esempio verrà utilizzato un file di configurazione creato manualmente.
Prerequisiti
- Identifica l'origine e il sink per la migrazione.
- Origine: DynamoDB File JSON
- Sink: Oracle NoSQL Database (in locale)
- Per importare i dati della tabella DynamoDB in Oracle NoSQL Database, è innanzitutto necessario esportare la tabella DynamoDB in S3. Fare riferimento ai passi forniti in Esportazione dei dati della tabella DynamoDB in Amazon S3 per esportare la tabella. Durante l'esportazione, selezionare il formato DynamoDB JSON. I dati esportati contengono i dati della tabella DynamoDB in più file
gzip, come mostrato di seguito./ 01639372501551-bb4dd8c3 |-- 01639372501551-bb4dd8c3 ==> exported data prefix |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started - È necessario scaricare i file da AWS s3. La struttura dei file dopo il download sarà come mostrato di seguito.
download-dir/01639372501551-bb4dd8c3 |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started
Procedura
- Preparare il file di configurazione (in formato JSON) con l'origine e il sink identificati details.See Modelli di configurazione di origine e Modelli di configurazione del lavandino .
È possibile scegliere una delle due opzioni seguenti.
- Opzione 1: importazione della tabella DynamoDB come documento JSON mediante la configurazione dello schema predefinito.
Qui
defaultSchemaèTRUEe quindi il migratore crea lo schema predefinito nel sink. È necessario specificare il tipo di colonnaDDBPartitionKeye il tipo di colonna NoSQL corrispondente. Altrimenti viene restituito un errore.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] "schemaInfo" : { "defaultSchema" : true, "DDBPartitionKey" : "<PrimaryKey:Datatype>", }, }, "abortOnError" : true, "migratorVersion" : "1.0.0" }Per un'origine JSON DynamoDB, lo schema predefinito per la tabella sarà il seguente:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type], DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))Where
TABLE_NAME = valore fornito per la 'tabella' sink nella configurazione
DDBPartitionKey_name = valore fornito per la chiave partiiton nella configurazione
DDBPartitionKey_type = valore fornito per il tipo di dati della chiave di partizione nella configurazione
DDBSortKey_name = valore fornito per la chiave di ordinamento nella configurazione, se presente
DDBSortKey_type = valore fornito per il tipo di dati della chiave di ordinamento nella configurazione, se presente
DOCUMENT = Tutti gli attributi tranne la partizione e la chiave di ordinamento di un elemento tabella DB Dynamo aggregati in una colonna JSON NoSQL
- Opzione 2: importazione della tabella DynamoDB come colonne fisse mediante un file di schema fornito dall'utente.
Qui
defaultSchemaèFALSEe si specifica schemaPath come file contenente l'istruzione DDL. Per ulteriori dettagli, vedere Mapping dei tipi DynamoDB ai tipi NoSQL Oracle.Nota
Se la tabella DB Dynamo contiene un tipo di dati non supportato in NoSQL, la migrazione non riesce.Un file di schema di esempio è riportato di seguito.CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, PRIMARY KEY(SHARD(AccountId)));Il file di schema viene utilizzato per creare la tabella nel sink come parte della migrazione. Se vengono forniti i dati della chiave primaria, verrà inserito il record JSON di input, altrimenti verrà generato un errore.Nota
Se i dati di input non contengono un valore per una determinata colonna (diversa dalla chiave primaria), verrà utilizzato il valore predefinito della colonna. Il valore predefinito deve far parte della definizione della colonna durante la creazione della tabella. Ad esempioid INTEGER not null default 0. Se la colonna non ha una definizione predefinita, viene inserito SQL NULL se non vengono forniti valori per la colonna.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- Opzione 1: importazione della tabella DynamoDB come documento JSON mediante la configurazione dello schema predefinito.
- Aprire il prompt dei comandi e andare alla directory in cui è stata estratta la utility NoSQL Database Migrator.
- Eseguire il comando
runMigratorpassando il file di configurazione utilizzando l'opzione--configo-c.[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file> - La utility procede con la migrazione dei dati, come mostrato di seguito.
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
Convalida
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoredesc <table_name>
SELECT * from <table_name>Eseguire la migrazione dal file JSON DynamoDB in AWS S3 a un Oracle NoSQL Database Cloud Service
Questo esempio mostra come utilizzare Oracle NoSQL Database Migrator per copiare il file JSON DynamoDB memorizzato in un'area di memorizzazione S3 AWS in Oracle NoSQL Database Cloud Service (NDCS).
Caso d'uso:
Dopo aver valutato più opzioni, un'organizzazione completa Oracle NoSQL Database Cloud Service tramite il database DynamoDB. L'organizzazione desidera eseguire la migrazione delle tabelle e dei dati da DynamoDB a Oracle NoSQL Database Cloud Service.
Per ulteriori dettagli, vedere Mapping della tabella DynamoDB alla tabella NoSQL di Oracle.
È 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.
{"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"}}}
La tabella DynamoDB viene esportata nello storage AWS S3 come specificato in Esportazione dei dati della tabella DynamoDB in Amazon S3.
Esempio:
Per questa demo, imparerai come migrare un file JSON DynamoDB in un'origine AWS S3 in NDCS. Per questo esempio verrà utilizzato un file di configurazione creato manualmente.
Prerequisiti
- Identifica l'origine e il sink per la migrazione.
- Fonte: DynamoDB File JSON in AWS S3
- Sink: Oracle NoSQL Database Cloud Service
- Identificare la tabella in AWS DynamoDB che deve essere migrata in NDCS. Eseguire il login alla console AWS utilizzando le credenziali. Passare a DynamoDB. In Tabelle scegliere la tabella di cui eseguire la migrazione.
- Creare un bucket oggetto ed esportare la tabella in S3. Dalla console AWS, vai a S3. Sotto i bucket, creare un nuovo bucket oggetto. Tornare a DynamoDB e fare clic su Esporta in S3. Fornire la tabella di origine e il bucket S3 di destinazione e fare clic su Esporta.
Fare riferimento ai passi forniti in Esportazione dei dati della tabella DynamoDB in Amazon S3 per esportare la tabella. Durante l'esportazione, selezionare il formato DynamoDB JSON. I dati esportati contengono i dati della tabella DynamoDB in più file
gzip, come mostrato di seguito./ 01639372501551-bb4dd8c3 |-- 01639372501551-bb4dd8c3 ==> exported data prefix |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started - Per accedere ad AWS S3 dal migratore, sono necessarie le credenziali (inclusi l'ID della chiave di accesso e la chiave di accesso segreta) e i file di configurazione (credenziali e facoltativamente configurabili). Per ulteriori dettagli sui file di configurazione, vedere Impostare e visualizzare le impostazioni di configurazione. Per ulteriori dettagli sulla creazione delle chiavi di accesso, vedere Creazione di una coppia di chiavi.
- Identificare le credenziali cloud OCI e acquisirle nel file di configurazione OCI. Salvare il file di configurazione in una directory
.ocinella directory home (~/.oci/config). Vedere Acquisizione delle credenziali per ulteriori informazioni.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identificare l'endpoint dell'area e il nome del compartimento per Oracle NoSQL Database. Di seguito sono riportati alcuni esempi.
- endpoint: us-phoenix-1
- compartimento: sviluppatori
Procedura
- Preparare il file di configurazione (in formato JSON) con i dettagli di origine e sink identificati. Vedere Modelli di configurazione di origine e Modelli di configurazione del lavandino.
È possibile scegliere una delle due opzioni seguenti.
- Opzione 1: importazione della tabella DynamoDB come documento JSON mediante la configurazione dello schema predefinito.
Qui
defaultSchemaèTRUEe quindi il migratore crea lo schema predefinito nel sink. È necessario specificare il tipo di colonnaDDBPartitionKeye il tipo di colonna NoSQL corrispondente. Altrimenti viene restituito un errore.{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : true, "readUnits" : 100, "writeUnits" : 60, "DDBPartitionKey" : "<PrimaryKey:Datatype>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }Per un'origine JSON DynamoDB, lo schema predefinito per la tabella sarà il seguente:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type], DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))Where
TABLE_NAME = valore fornito per la 'tabella' sink nella configurazione
DDBPartitionKey_name = valore fornito per la chiave partiiton nella configurazione
DDBPartitionKey_type = valore fornito per il tipo di dati della chiave di partizione nella configurazione
DDBSortKey_name = valore fornito per la chiave di ordinamento nella configurazione, se presente
DDBSortKey_type = valore fornito per il tipo di dati della chiave di ordinamento nella configurazione, se presente
DOCUMENT = Tutti gli attributi tranne la partizione e la chiave di ordinamento di un elemento tabella DB Dynamo aggregati in una colonna JSON NoSQL
- Opzione 2: importazione della tabella DynamoDB come colonne fisse mediante un file di schema fornito dall'utente.
Qui
defaultSchemaèFALSEe si specifica schemaPath come file contenente l'istruzione DDL. Per ulteriori dettagli, vedere Mapping dei tipi DynamoDB ai tipi NoSQL Oracle.Nota
Se la tabella DB Dynamo contiene un tipo di dati non supportato in NoSQL, la migrazione non riesce.Un file di schema di esempio è riportato di seguito.CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, PRIMARY KEY(SHARD(AccountId)));Il file di schema viene utilizzato per creare la tabella nel sink come parte della migrazione. Se vengono forniti i dati della chiave primaria, verrà inserito il record JSON di input, altrimenti verrà generato un errore.Nota
Se i dati di input non contengono un valore per una determinata colonna (diversa dalla chiave primaria), verrà utilizzato il valore predefinito della colonna. Il valore predefinito deve far parte della definizione della colonna durante la creazione della tabella. Ad esempioid INTEGER not null default 0. Se la colonna non ha una definizione predefinita, viene inserito SQL NULL se non vengono forniti valori per la colonna.{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- Opzione 1: importazione della tabella DynamoDB come documento JSON mediante la configurazione dello schema predefinito.
- Aprire il prompt dei comandi e andare alla directory in cui è stata estratta la utility NoSQL Database Migrator.
- Eseguire il comando
runMigratorpassando il file di configurazione utilizzando l'opzione--configo-c.[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file> - La utility procede con la migrazione dei dati, come mostrato di seguito.
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
Convalida
È possibile eseguire il login alla console NDCS e verificare che la nuova tabella venga creata con i dati di origine.
Esegui la migrazione tra le aree Oracle NoSQL Database Cloud Service
Questo esempio mostra l'uso di Oracle NoSQL Database Migrator per eseguire la migrazione tra più aree.
caso d'uso
Un'organizzazione utilizza Oracle NoSQL Database Cloud Service per memorizzare e gestire i propri dati. Decide di replicare i dati da un'area esistente a un'area più recente a scopo di test prima che la nuova area possa essere avviata per l'ambiente di produzione.
In questo caso d'uso, verrà descritto come utilizzare NoSQL Migrator di database per copiare i dati dalla tabella user_data nell'area Ashburn nell'area Phoenix.
Per eseguire la utility runMigrator, passare un file di configurazione già creato. Se il file di configurazione non viene fornito come parametro runtime, la utility runMigrator richiede di generare la configurazione mediante una procedura interattiva.
- Scarica Oracle NoSQL Database Migrator dalla pagina Download di Oracle NoSQL ed estrai i contenuti sul tuo computer. Per i dettagli, vedere Workflow for Oracle NoSQL Database Migrator.
- Identifica l'origine e il sink per la migrazione.
- Origine: la tabella
user_datanell'area Ashburn.La tabellauser_datainclude i dati riportati di seguito.{"id":40,"firstName":"Joanna","lastName":"Smith","otherNames":[{"first":"Joanna","last":"Smart"}],"age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085},"connections":[70,30,40],"email":"joanna.smith123@reachmail.com","communityService":"**"} {"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"Good"},{"first":"Johny2","last":"Brave"},{"first":"Johny3","last":"Kind"},{"first":"Johny4","last":"Humble"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"email":"john.smith@reachmail.com","communityService":"****"} {"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"BeGood"}],"age":22,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"email":"jane.smith201@reachmail.com","communityService":"*****"} {"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"BeGood"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"email":"adam.smith201reachmail.com","communityService":"***"}Identificare l'endpoint dell'area o l'endpoint del servizio e il nome del compartimento per l'origine.- endpoint:
us-ashburn-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- endpoint:
- La tabella
user_datanell'area Phoenix.Identificare l'endpoint dell'area o l'endpoint del servizio e il nome del compartimento per il sink.- endpoint:
us-phoenix-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identificare lo schema della tabella sink.
È possibile utilizzare lo stesso nome tabella e lo stesso schema della tabella di origine. Per informazioni su altre opzioni dello schema, vedere l'argomento Identificazione dell'origine e del lavandino in Workflow for Oracle NoSQL Database Migrator
- endpoint:
- Origine: la tabella
- Identificare le credenziali cloud OCI per entrambe le aree e acquisirle nel file di configurazione. Salvare il file di configurazione sul computer nella posizione
/home/<user>/.oci/config. Per ulteriori dettagli, vedere Acquisizione delle credenziali.
Nota
- Se le aree si trovano in tenancy diverse, è necessario fornire profili diversi nel file
/home/<user>/.oci/configcon le credenziali cloud OCI appropriate per ciascuna di esse. - Se le aree si trovano nella stessa tenancy, è possibile avere un singolo profilo nel file
/home/<user>/.oci/config.
In questo esempio, le aree si trovano in tenancy diverse. Il profilo DEFAULT include credenziali OCI per l'area Ashburn e DEFAULT2 include credenziali OCI per l'area Phoenix.
endpoint del file di configurazione del migratore (modelli di configurazione di origine e sink), è possibile fornire l'URL dell'endpoint del servizio o l'ID dell'area delle aree. Per la lista delle aree dati supportate per Oracle NoSQL Database Cloud Service e gli URL degli endpoint dei servizi, vedere Aree dati e URL dei servizi associati nel documento Oracle NoSQL Database Cloud Service.[DEFAULT]
user=ocid1.user.oc1....
fingerprint=fd:96:....
tenancy=ocid1.tenancy.oc1....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=abcd
[DEFAULT2]
user=ocid1.user.oc1....
fingerprint=1b:68:....
tenancy=ocid1.tenancy.oc1....
region=us-phoenix-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=23456user_data dall'area Ashburn all'area Phoenix, eseguire le operazioni riportate di seguito.
Per convalidare la migrazione, è possibile eseguire il login alla console di Oracle NoSQL Database Cloud Service nell'area Phoenix. Verificare che i dati di origine della tabella user_data nell'area Ashburn vengano copiati nella tabella user_data in quest'area. Per la procedura di accesso alla console, vedere l'articolo Accessing the Service from the Infrastructure Console.
Esegui la migrazione da Oracle NoSQL Database Cloud Service a OCI Object Storage
Questo esempio mostra l'uso di Oracle NoSQL Database Migrator da una Cloud Shell.
Caso di utilizzo
Una start-up prevede di utilizzare Oracle NoSQL Database Cloud Service come soluzione di storage dei dati. L'azienda desidera utilizzare Oracle NoSQL Database Migrator per copiare i dati da una tabella in Oracle NoSQL Database Cloud Service a OCI Object Storage per eseguire backup periodici dei propri dati. Come misura a costi contenuti, desiderano eseguire la utility NoSQL Database Migrator da Cloud Shell, accessibile a tutti gli utenti OCI.
In questo caso d'uso, verrà descritto come copiare la utility NoSQL Database Migrator in una Cloud Shell nell'area sottoscritta ed eseguire una migrazione dei dati. È possibile eseguire la migrazione dei dati di origine dalla tabella Oracle NoSQL Database Cloud Service a un file JSON nello storage degli oggetti OCI.
Per eseguire la utility runMigrator, passare un file di configurazione già creato. Se il file di configurazione non viene fornito come parametro runtime, la utility runMigrator richiede di generare la configurazione mediante una procedura interattiva.
- Scarica Oracle NoSQL Database Migrator dalla pagina Oracle NoSQL Download sul tuo computer locale.
- Avviare Cloud Shell dal menu Strumenti di sviluppo nella console cloud. Il browser Web apre la directory home. Fare clic sul menu Cloud Shell nell'angolo superiore destro della finestra Cloud Shell e selezionare l'opzione upload dall'elenco a discesa. Nella finestra popup trascinare il package Oracle NoSQL Database Migrator dal computer locale oppure fare clic sull'opzione Seleziona dal computer, selezionare il package dal computer locale e fare clic sul pulsante Carica. È inoltre possibile trascinare il package Oracle NoSQL Database Migrator direttamente dal computer locale alla directory home in Cloud Shell. Estrarre il contenuto del pacchetto.
- Identificare l'origine e il sink per il backup.
-
Origine: tabella
NDCSuploadnell'area Oracle NoSQL Database Cloud Service Ashburn.A titolo dimostrativo, tenere presenti i seguenti dati nella tabellaNDCSupload:{"id":1,"name":"Jane Smith","email":"iamjane@somemail.co.us","age":30,"income":30000.0} {"id":2,"name":"Adam Smith","email":"adam.smith@mymail.com","age":25,"income":25000.0} {"id":3,"name":"Jennifer Smith","email":"jenny1_smith@mymail.com","age":35,"income":35000.0} {"id":4,"name":"Noelle Smith","email":"noel21@somemail.co.us","age":40,"income":40000.0}Identificare l'endpoint e l'ID compartimento per l'origine. Per l'endpoint, è possibile fornire l'identificativo dell'area o l'endpoint del servizio. Per la lista delle aree dati supportate in Oracle NoSQL Database Cloud Service, vedere Aree dati e URL dei servizi associati.
- endpoint:
us-ashburn-1 - ID compartimento:
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- endpoint:
-
Sink: file JSON nel bucket di storage degli oggetti OCI.
Identifica l'endpoint, lo spazio di nomi, il bucket e il prefisso dell'area per lo storage degli oggetti OCI. Per ulteriori dettagli, consulta la sezione relativa all'accesso allo storage degli oggetti Oracle Cloud. Per la lista degli endpoint del servizio di storage degli oggetti OCI, vedere Endpoint di storage degli oggetti.
- endpoint:
us-ashburn-1 - bucket:
Migrate_oci - prefisso:
Delegation - spazio di nomi: <> Se non si fornisce uno spazio di nomi, la utility utilizza lo spazio di nomi predefinito della tenancy.
Nota
Se il bucket di storage degli oggetti si trova in un compartimento diverso, assicurarsi di disporre dei privilegi per scrivere gli oggetti nel bucket. Per ulteriori dettagli sull'impostazione dei criteri, vedere Consenti agli utenti di scrivere oggetti nei bucket di storage degli oggetti. - endpoint:
-
NDCSupload da Oracle NoSQL Database Cloud Service a un file JSON nel bucket di storage degli oggetti OCI utilizzando Cloud Shell, eseguire le operazioni riportate di seguito.
Per convalidare il backup dei dati, eseguire il login alla console di Oracle NoSQL Database Cloud Service. Esplora i menu, Storage > Object Storage & Archive Storage > Buckets. Accedere ai file dalla directory NDCSupload/Delegation nel bucket Migrate_oci. Per la procedura di accesso alla console, vedere l'articolo Accessing the Service from the Infrastructure Console.
Esegui migrazione da file CSV a Oracle NoSQL Database
Questo esempio mostra l'uso di Oracle NoSQL Database Migrator per copiare i dati da un file CSV in Oracle NoSQL Database.
Esempio
Dopo aver valutato più opzioni, un'organizzazione finalizza Oracle NoSQL Database come piattaforma di database NoSQL. Poiché i contenuti di origine sono in formato CSV, stanno cercando un modo per eseguirne la migrazione in Oracle NoSQL Database.
In questo esempio, imparerai a migrare i dati da un file CSV chiamato course.csv, che contiene informazioni sui vari corsi offerti da un'università. Il file di configurazione viene generato dalla utility runMigrator.
È inoltre possibile preparare il file di configurazione con i dettagli di origine e sink identificati. Vedere Oracle NoSQL Database Migrator Reference.
- Identifica l'origine e il sink per la migrazione.
- Origine: file CSV
In questo esempio, il file di origine è
course.csvcat [~/nosql-migrator-1.5.0]/course.csv 1,"Computer Science", "San Francisco", "2500" 2,"Bio-Technology", "Los Angeles", "1200" 3,"Journalism", "Las Vegas", "1500" 4,"Telecommunication", "San Francisco", "2500" - Lavello: Oracle NoSQL Database
- Origine: file CSV
- Il file CSV deve essere conforme al formato
RFC4180. - Creare un file contenente i comandi DDL per lo schema della tabella di destinazione,
course. La definizione della tabella deve corrispondere al file di dati CSV relativo al numero di colonne e ai relativi tipi.In questo esempio, il file DDL è
mytable_schema.ddlcat [~/nosql-migrator-1.5.0]/mytable_schema.ddl create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
course.csv a Oracle NoSQL Database Service, effettuare le operazioni riportate di seguito.
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
sql-> select * from course;
{"id":4,"name":"Telecommunication","location":"San Francisco","fees":2500}
{"id":1,"name":"Computer Science","location":"San Francisco","fees":2500}
{"id":2,"name":"Bio-Technology","location":"Los Angeles","fees":1200}
{"id":3,"name":"Journalism","location":"Las Vegas","fees":1500}
4 rows returned