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 includere file jar aggiuntivi che fanno parte dell'installazione di EE. Per ulteriori informazioni, vedere Oracle Wallet.
Senza i file jar, verrà visualizzato il seguente messaggio di errore:
Impossibile trovare kvstore-ee.jar e kvstore-ee-<version>.jar nella directory lib. Copiare kvstore-ee.jar e kvstore-ee-<version>.jar nella directory lib
kvstore-ee.jar e kvstore-ee-<version>.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
Time to Live (TTL) è un meccanismo che consente di far scadere automaticamente le righe delle tabelle. TTL è espresso come la quantità di tempo, i dati sono autorizzati a vivere nel negozio. I dati che hanno raggiunto il valore di timeout di scadenza non possono più essere recuperati e non verranno visualizzati in alcuna statistica di memorizzazione.
Tabella - Migrazione dei metadati TTL
| Tipi di origine | Parametro di configurazione origine | Parametro di configurazione del lavandino |
|---|---|---|
| Oracle NoSQL Database | includeTTL |
includeTTL |
| Oracle NoSQL Database Cloud Service | includeTTL |
includeTTL |
| DynamoDB: file JSON formattato | ttlAttributeName |
includeTTL |
| DynamoDB: file JSON formattato memorizzato in AWS S3 | ttlAttributeName |
includeTTL |
Esportazione dei metadati TTL in Oracle NoSQL Database e Oracle NoSQL Database Cloud Service
NoSQL Migratore database fornisce il parametro di configurazione includeTTL per supportare l'esportazione dei metadati TTL della riga di tabella.
_metadata non viene incluso in modo esplicito nei dati esportati perché il relativo valore di scadenza è sempre 0. 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 il parametro di configurazione includeTTL nel modello di configurazione del sink.
L'ora di riferimento predefinita dell'operazione di importazione è l'ora corrente in millisecondi, ottenuta da System.currentTimeMillis(), del computer in cui è in esecuzione lo strumento NoSQL Database Migrator. Tuttavia, è anche possibile impostare un'ora di riferimento personalizzata utilizzando il parametro di configurazione ttlRelativeDate se si desidera estendere l'ora di scadenza e importare le righe che altrimenti scadrebbero immediatamente. L'estensione viene calcolata come segue e aggiunta all'ora di scadenza.
Extended time = expiration time - reference timeL'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 il parametro di configurazione includeTTL è impostato su true.
- Caso d'uso 1: nella riga della tabella di importazione non sono presenti informazioni sui metadati TTL.
Se la riga che si desidera importare non contiene informazioni TTL, NoSQL Migrator database imposta il TTL=0 per la riga.
- 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.
La riga della tabella scaduta viene ignorata e non 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.
La riga della tabella viene importata con un valore TTL. Tuttavia, il valore TTL importato potrebbe non corrispondere al valore TTL esportato originale a causa dei vincoli della finestra di ore e giorni interi nella classe TimeToLive. Di seguito sono riportati alcuni esempi.
Considera riga tabella esportata:{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC } }L'ora di riferimento durante l'importazione è 1734480000000, ovvero mercoledì 18 dicembre 2024 alle 12:00:00.
Riga della tabella importata{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1734739200000 //Saturday, December 21, 2024 12:00:00 AM } }
Importazione dei metadati TTL in DynamoDB: file JSON formattato e file JSON formattato DynamoDB memorizzato in AWS S3
NoSQL Migrator database fornisce un parametro di configurazione aggiuntivo, ttlAttributeName, per supportare l'importazione dei metadati TTL dagli elementi del file JSON in formato DynamoDB.
I file JSON esportati DynamoDB includono un attributo specifico in ogni elemento per memorizzare l'indicatore orario di scadenza TTL. Per importare facoltativamente i valori TTL dai file JSON esportati DynamoDB, è necessario fornire il nome dell'attributo specifico come valore al parametro di configurazione ttlAttributeName nel file DynamoDB-Formatted JSON File o nel file JSON formattato DynamoDB memorizzato nei file di configurazione di origine AWS S3. Inoltre, è necessario impostare il parametro di configurazione includeTTL nel modello di configurazione del sink. I sink validi sono Oracle NoSQL Database e Oracle NoSQL Database Cloud Service. NoSQL Migrator database memorizza le informazioni TTL nell'oggetto JSON _metadata per l'elemento importato.
-
Caso d'uso 1: il valore del parametro di configurazione ttlAttributeName è impostato sul nome dell'attributo TTL specificato nel file JSON esportato DynamoDB.
NoSQL Migrator database importa l'ora di scadenza per questo elemento come numero di millisecondi dall'epoca UNIX (1° gennaio 1970).
Ad esempio, si consideri un elemento nel file JSON esportato DynamoDB:{ "Item": { "DeptId": { "N": "1" }, "DeptName": { "S": "Engineering" }, "ttl": { "N": "1734616800" } } }In questo caso, l'attributottlspecifica il valore Time To Live per l'elemento. Se si imposta il parametro di configurazione ttlAttributeName comettlnel file JSON in formato DynamoDB o nel file JSON in formato DynamoDB memorizzato nel file di configurazione di origine S3 AWS, NoSQL Database Migrator importa l'ora di scadenza per l'elemento come indicato di seguito.{ "DeptId": 1, "document": { "DeptName": "Engineering" } "_metadata": { "expiration": 1734616800000 } }Nota
È possibile fornire il parametro di configurazione ttlRelativeDate nel modello di configurazione del sink come ora di riferimento per il calcolo dell'ora di scadenza. - Caso d'uso 2: il valore del parametro di configurazione ttlAttributeName è impostato, ma il valore non esiste come attributo nell'elemento del file JSON esportato DynamoDB.
NoSQL Migrator database non importa le informazioni sui metadati TTL per l'elemento specificato.
- Caso d'uso 3: il valore del parametro di configurazione ttlAttributeName non corrisponde al nome dell'attributo nell'elemento del file JSON esportato DynamoDB.
NoSQL Migrator database gestisce l'importazione in uno dei modi riportati di seguito in base alla configurazione del sink.
- Copia l'attributo come campo normale se configurato per l'importazione utilizzando lo schema predefinito.
- Salta l'attributo se configurato per l'importazione utilizzando uno schema definito dall'utente.
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>
Nota
NoSQL Migrator del database utilizza unità di lettura durante l'esecuzione dell'esportazione dei dati dalla tabella Oracle NoSQL Cloud Service a qualsiasi sink valido.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 passare alla directory sink specificata e visualizzare lo schema e i dati.
-- Exported myTable Data. JSON files are created in the supplied data path
[~/nosqlMigrator]$cat myTable_1_5.json
{
"id" : 10,
"document" : {
"course" : "Computer Science",
"name" : "Neena",
"studentid" : 105
}
}
{
"id" : 3,
"document" : {
"course" : "Computer Science",
"name" : "John",
"studentid" : 107
}
}
{
"id" : 4,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 6,
"document" : {
"course" : "Bio-Technology",
"name" : "Rekha",
"studentid" : 104
}
}
{
"id" : 7,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 5,
"document" : {
"course" : "Journalism",
"name" : "Rani",
"studentid" : 106
}
}
{
"id" : 8,
"document" : {
"course" : "Computer Science",
"name" : "Tom",
"studentid" : 103
}
}
{
"id" : 9,
"document" : {
"course" : "Computer Science",
"name" : "Peter",
"studentid" : 109
}
}
{
"id" : 1,
"document" : {
"course" : "Journalism",
"name" : "Tracy",
"studentid" : 110
}
}
{
"id" : 2,
"document" : {
"course" : "Bio-Technology",
"name" : "Raja",
"studentid" : 108
}
}-- Exported myTable Schema
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))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 indicare a NoSQL Database Migrator di 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 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 delle tabelle e dei 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"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}
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 (on-premise)
- Per importare i dati della tabella DynamoDB in Oracle NoSQL Database, è innanzitutto necessario esportare la tabella DynamoDB in S3. Per esportare la tabella, vedere la procedura descritta in Esportazione dei dati della tabella DynamoDB in Amazon S3. 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 i dettagli di origine e sink identificati. Per informazioni dettagliate, vedere Modelli di configurazione di origine e Modelli di configurazione del lavandino.
Nota
Se gli elementi della tabella JSON esportati DynamoDB contengono un attributo TTL, per importare facoltativamente i valori TTL, specificare l'attributo nel parametro di configurazione ttlAttributeName del modello di configurazione di origine e impostare il parametro di configurazione includeTTL su true nel modello di configurazione del sink.È possibile scegliere una delle due opzioni seguenti.- Opzione 1: importazione della tabella DynamoDB come documento JSON mediante la configurazione dello schema predefinito.
In questo caso, impostare il parametro di configurazione defaultSchema su true. Pertanto, NoSQL Migrator database crea lo schema predefinito nel sink. È necessario specificare il tipo di colonna
DDBPartitionKeye il tipo di colonna NoSQL corrispondente. In caso contrario, viene visualizzato un errore.Per i dettagli sullo schema predefinito per un'origine JSON esportata DynamoDB, vedere l'argomento relativo all'identificazione dell'origine e del collegamento in Workflow for Oracle NoSQL Database Migrator.{ "source" : { "type" : "file", "format" : "dynamodb_json", "ttlAttributeName" : "ttl", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"], "table" : "sampledynDBImp", "includeTTL" : true, "schemaInfo" : { "DDBPartitionKey" : "Id:INTEGER", "defaultSchema" : true }, "overwrite" : true, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.6.5" }In questo esempio viene utilizzato il seguente schema predefinito:CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) - Opzione 2: importazione della tabella DynamoDB come colonne fisse mediante un file di schema fornito dall'utente.
In questo caso, impostare il parametro di configurazione defaultSchema su false. È pertanto possibile specificare il file che contiene l'istruzione DDL della tabella sink nel parametro schemaPath. Per ulteriori dettagli, vedere Mapping dei tipi DynamoDB ai tipi NoSQL Oracle.
In questo esempio viene utilizzato il seguente schema definito dall'utente:CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))NoSQL Migrator database utilizza il file di schema per creare la tabella nel sink nell'ambito della migrazione. Finché vengono forniti i dati della chiave primaria, verrà inserito il record JSON di input. In caso contrario, viene visualizzato un errore.
Nota
- Se la tabella DB Dynamo contiene un tipo di dati non supportato nel database NoSQL, la migrazione non riesce.
- 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 esempio,
id INTEGER not null default 0. Se la colonna non ha una definizione predefinita, SQL NULL viene inserito se non vengono forniti valori per la colonna. - Se si sta modellando la tabella DynamoDB come documento JSON, assicurarsi di utilizzare la trasformazione
AggregateFieldsper aggregare i dati della chiave non primaria in una colonna JSON. Per ulteriori informazioni, vedere aggregateFields.
{ "source" : { "type" : "file", "format" : "dynamodb_json", "ttlAttributeName" : "ttl", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"], "table" : "sampledynDBImp", "includeTTL" : true, "schemaInfo" : { "schemaPath" : "<full path of the schema file with the DDL statement>" }, "overwrite" : true, "requestTimeoutMs" : 5000 }, "transforms": { "aggregateFields" : { "fieldName" : "document", "skipFields" : ["Id"] } }, "abortOnError" : true, "migratorVersion" : "1.6.5" }
- 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 file di configurazione separati per le opzioni 1 e 2. Utilizzare le opzioni--configo-c../runMigrator --config <complete/path/to/the/JSON/config/file> - La utility procede con la migrazione dei dati come illustrato nel seguente esempio:
[INFO] creating source from given configuration: [INFO] source creation completed [INFO] creating sink from given configuration: [INFO] sink creation completed [INFO] creating migrator pipeline [INFO] [nosqldb sink] : start loading DDLs [INFO] [nosqldb sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) [INFO] [nosqldb sink] : completed loading DDLs [INFO] migration started [INFO] Start writing data to OnDB Sink [INFO] executing for source:DynamoSample [INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz [INFO] Writing data to OnDB Sink completed. [INFO] migration completed. Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0. Elapsed time: 0min 0sec 45ms Migration completed.
Convalida
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoreSELECT * FROM sampledynDBImpOutput
_metadata per ogni elemento importato.{"Id":102,"document":{"Address":{"City":"Wales","DoorNum":1024,"Street":"32 main","Zip":560014},"Age":48,"FavColors":["Blue"],"FavNumbers":[10],"FirstName":"John","LastName":"White","Phones":[["222-222"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}
{"Id":101,"document":{"Address":{"City":"London","DoorNum":201,"Street":"21 main","Zip":570004},"Age":22,"FavColors":["Red","Green"],"FavNumbers":[10],"FirstName":"Fred","LastName":"Smith","Phones":[["555-222","123-567"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}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. Per informazioni dettagliate, vedere Modelli di configurazione di origine e Modelli di configurazione del lavandino.
Nota
Se gli elementi nel file JSON DynamoDB in AWS S3 contengono l'attributo TTL, per importare facoltativamente i valori TTL, specificare l'attributo nel parametro di configurazione ttlAttributeName del modello di configurazione di origine e impostare il parametro di configurazione includeTTL su true nel modello di configurazione del sink. Per ulteriori dettagli, vedere Migrazione dei metadati TTL per le righe di tabella.È possibile scegliere una delle due opzioni seguenti.- Opzione 1: importazione della tabella DynamoDB come documento JSON mediante la configurazione dello schema predefinito.
In questo caso, defaultSchema è
TRUEe quindi il migratore crea lo schema predefinito nel sink. È necessario specificare il tipo di colonna DDBPartitionKey e il tipo di colonna NoSQL corrispondente. In caso contrario, viene generato 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.6.5" }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 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 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.
In questo caso, defaultSchema è
FALSEe si specifica schemaPath come file contenente l'istruzione DDL. Per informazioni dettagliate, vedere Mapping dei tipi DynamoDB ai tipi NoSQL Oracle per ulteriori dettagli.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 esempio
id 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. - Se si sta modellando la tabella DynamoDB come documento JSON, assicurarsi di utilizzare la trasformazione
AggregateFieldsper aggregare i dati della chiave non primaria in una colonna JSON. Per ulteriori informazioni, vedere aggregateFields.
{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "transforms": { "aggregateFields" : { "fieldName" : "document", "skipFields" : ["AccountId"] } }, "abortOnError" : true, "migratorVersion" : "1.6.5" } - 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 esempio
- 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]$./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 Scrivere gli oggetti nello 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.
Eseguire la migrazione dallo storage degli oggetti OCI a Oracle NoSQL Database Cloud Service utilizzando l'autenticazione OKE
Questo esempio mostra come utilizzare Oracle NoSQL Database Migrator con OKE Workload Identity Authentication per copiare i dati da un file JSON nello storage degli oggetti OCI nella tabella Oracle NoSQL Database Cloud Service.
Caso d'uso
Come sviluppatore, stai esplorando un'opzione per ripristinare i dati da un file JSON nel bucket di OCI Object Storage (OCI OS) alla tabella Oracle NoSQL Database Cloud Service (NDCS) utilizzando NoSQL Database Migrator in un'applicazione containerizzata. Un'applicazione containerizzata è un ambiente virtualizzato che raggruppa l'applicazione e tutte le sue dipendenze (come librerie, file binari e file di configurazione) in un pacchetto. Ciò consente all'applicazione di essere eseguita in modo coerente in ambienti diversi, indipendentemente dall'infrastruttura sottostante.
Si desidera eseguire NoSQL Database Migrator all'interno di un pod Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). Per accedere in modo sicuro al sistema operativo OCI e ai servizi NDCS dal pod OKE, utilizzerai il metodo WIA (Workload Identity Authentication).
In questa dimostrazione, si creerà un'immagine docker per NoSQL Database Migrator, si copierà l'immagine in un repository nel Container Registry, si creerà un cluster OKE e si distribuirà l'immagine Migrator nel pod del cluster OKE per eseguire la utility Migrator. Qui verrà fornito un file di configurazione NoSQL Database Migrator creato manualmente per eseguire la utility Migrator come applicazione containerizzata.
- Identifica l'origine e il sink per la migrazione.
- Origine: file JSON e file di schema nel bucket del sistema operativo OCI.
Identifica l'endpoint dell'area, lo spazio di nomi, il bucket e il prefisso per il bucket del sistema operativo OCI in cui sono disponibili i file e lo schema JSON di origine. Per ulteriori dettagli, vedere Accesso allo storage degli oggetti Oracle Cloud. Per la lista degli endpoint del servizio del sistema operativo OCI, vedere Endpoint di storage degli oggetti.
- endpoint:
us-ashburn-1 - bucket:
Migrate_oci - prefisso:
userSession - spazio di nomi:
idhkv1iewjzjIl nome dello spazio di nomi per un bucket è lo stesso dello spazio di nomi della tenancy e viene generato automaticamente quando viene creata la tenancy. È possibile ottenere il nome dello spazio di nomi come indicato di seguito.- Dalla console di Oracle NoSQL Database Cloud Service, passare a Memorizzazione> Bucket.
- Selezionare un valore per Compartimento dal campo Ambito lista e selezionare il bucket. La pagina Dettagli bucket visualizza il nome nel parametro Spazio di nomi.
Se non si fornisce un nome per lo spazio di nomi del sistema operativo OCI, la utility Migrator utilizza lo spazio di nomi predefinito della tenancy.
- endpoint:
- Lavello: tabella
usersin Oracle NoSQL Database Cloud Service.Identificare l'endpoint dell'area o l'endpoint del servizio e il nome del compartimento per il sink:
- endpoint:
us-ashburn-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identificare lo schema della tabella sink:
Per utilizzare il nome tabella e lo schema memorizzati nel bucket del sistema operativo OCI, impostare il parametro useSourceSchema su true. Per informazioni su altre opzioni di schema, vedere l'argomento Identificare l'origine e ilink in Workflow per Oracle NoSQL Database Migrator.
Nota
Assicurarsi di disporre dei privilegi di scrittura per il compartimento in cui si stanno ripristinando i dati nella tabella NDCS. Per ulteriori dettagli, vedere Gestione dei compartimenti. - endpoint:
- Origine: file JSON e file di schema nel bucket del sistema operativo OCI.
- Preparare un'immagine Docker per NoSQL Database Migrator e spostarla in Container Registry.
- Recupera lo spazio di nomi della tenancy dalla console OCI.
Eseguire il login alla console di Oracle NoSQL Database Cloud Service. Nella barra di navigazione selezionare il menu Profilo, quindi selezionare Tenancy: <Nome tenany>.
Copiare il nome dello spazio di nomi dello storage degli oggetti, ovvero lo spazio di nomi della tenancy, negli appunti.
- Creare un'immagine Docker per la utility Migrator.
Passare alla directory in cui è stata estratta la utility NoSQL Database Migrator. Il pacchetto Migrator include un file docker denominato Dockerfile. Da un'interfaccia di comando, utilizzare il comando seguente per creare un'immagine Docker della utility Migrator:
#Command: docker build -t nosqlmigrator:<tag> .#Example: docker build -t nosqlmigrator:1.0 .È possibile specificare un identificativo di versione per l'immagine Docker nell'opzionetag. Controllare l'immagine Docker utilizzando il comando:#Command: Docker images#Example output ------------------------------------------------------------------------------------------ REPOSITORY TAG IMAGE ID CREATED SIZE localhost/nosqlmigrator 1.0 e1dcec27a5cc 10 seconds ago 487 MB quay.io/podman/hello latest 83fc7ce1224f 10 months ago 580 kB docker.io/library/openjdk 17-jdk-slim 8a3a2ffec52a 2 years ago 406 MB ------------------------------------------------------------------------------------------ - Generare un token autenticazione.
È necessario un token di autenticazione per eseguire il login al Container Registry e memorizzare l'immagine Docker di Migrator. Se non si dispone già di un token di autenticazione, è necessario generarne uno. Per i dettagli, vedere Come ottenere un token di autenticazione.
- Memorizzare l'immagine Docker Migrator in Container Registry.
Per accedere all'immagine Docker Migrator dal pod Kubernetes, è necessario memorizzare l'immagine in qualsiasi registro pubblico o privato. Ad esempio, Docker, Artifact Hub, OCI Container Registry e così via sono alcuni registri. In questa dimostrazione, utilizziamo Container Registry. Per informazioni dettagliate, vedere Panoramica del registro container.
- Dalla console OCI, creare un repository nel Container Registry. Per informazioni dettagliate, vedere Creazione di un repository.
Per questa dimostrazione, creare il repository
okemigrator.Figura - Repository nel registro contenitori
- Eseguire il login al Container Registry dall'interfaccia a comandi utilizzando il seguente comando:
#Command: docker login <region-key>.ocir.io -u <tenancy-namespace>/<user name>password: <Auth token>#Example: docker login iad.ocir.io -u idhx..xxwjzj/rx..xxxxh@oracle.com password: <Auth token>#Output: Login Succeeded!Nel comando precedente,
region-key: specifica la chiave per l'area in cui si utilizza Container Registry. Per informazioni dettagliate, vedere Disponibilità per area.tenancy-namespace: specifica lo spazio di nomi della tenancy copiato dalla console OCI.user name: specifica il nome utente della console OCI.password: specifica il token di autenticazione. - Contrassegnare e inviare l'immagine Docker di Migrator a Container Registry utilizzando i comandi seguenti:
#Command: docker tag <Migrator Docker image> <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag> docker push <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>#Example: docker tag localhost/nosqlmigrator:1.0 iad.ocir.io/idhx..xxwjzj/okemigrator:1.0 docker push iad.ocir.io/idhx..xxwjzj/okemigrator:1.0Nel comando precedente,
repo: specifica il nome del repository creato in Container Registry.tag: specifica l'identificativo della versione per l'immagine Docker.#Output: Getting image source signatures Copying blob 0994dbbf9a1b done | Copying blob 37849399aca1 done | Copying blob 5f70bf18a086 done | Copying blob 2f263e87cb11 done | Copying blob f941f90e71a8 done | Copying blob c82e5bf37b8a done | Copying blob 2ad58b3543c5 done | Copying blob 409bec9cdb8b done | Copying config e1dcec27a5 done | Writing manifest to image destination
- Dalla console OCI, creare un repository nel Container Registry. Per informazioni dettagliate, vedere Creazione di un repository.
- Recupera lo spazio di nomi della tenancy dalla console OCI.
- Configurare un cluster OKE con WIA a NDCS e sistema operativo OCI.
- Creare un cluster Kubernetes utilizzando OKE.
Dalla console OCI, definire e creare un cluster Kubernetes in base alla disponibilità delle risorse di rete utilizzando OKE. È necessario un cluster Kubernetes per eseguire la utility Migrator come applicazione containerizzata. Per i dettagli sulla creazione del cluster, vedere Creazione di cluster Kubernetes mediante i workflow della console.
Per questa dimostrazione, è possibile creare un cluster gestito a nodo singolo utilizzando il flusso di lavoro Creazione rapida dettagliato nel collegamento sopra riportato.
Figura - Cluster Kubernetes per Migrator Container
- Imposta WIA dalla console OCI per accedere ad altre risorse OCI dal cluster Kubernetes.
Per concedere alla utility Migrator l'accesso al bucket del sistema operativo NDCS e OCI durante l'esecuzione dai pod del cluster Kubernetes, è necessario impostare WIA. Attenersi alla procedura riportata di seguito.
- Impostare il file di configurazione kubeconfig del cluster.
- Dalla console OCI, aprire il cluster Kubernetes creato e fare clic sul pulsante Accedi al cluster.
- Nella finestra di dialogo Accedi al cluster, fare clic su Accesso a Cloud Shell.
- Fare clic su Avvia Cloud Shell per visualizzare la finestra Cloud Shell.
- Eseguire il comando CLI di Oracle Cloud Infrastructure per impostare il file kubeconfig. È possibile copiare il comando dalla finestra di dialogo Accedi al cluster. Potete aspettarvi il seguente output:
#Example: oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aaa...muqzq --file $HOME/.kube/config --region us-ashburn-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT#Output: New config written to the Kubeconfig file /home/<user>/.kube/config
- Copiare l'OCID del cluster dall'opzione
cluster-idnel comando precedente e salvarlo per utilizzarlo nei passi successivi.ocid1.cluster.oc1.iad.aaa...muqzq - Creare uno spazio di nomi per l'account del servizio Kubernetes utilizzando il comando seguente nella finestra della shell cloud:
#Command: kubectl create namespace <namespace-name>#Example: kubectl create namespace migrator#Output: namespace/migrator created - Creare un account di servizio Kubernetes per l'applicazione Migrator in uno spazio di nomi utilizzando il comando seguente nella finestra della shell cloud:
#Command: kubectl create serviceaccount <service-account-name> --namespace <namespace-name>#Example: kubectl create serviceaccount migratorsa --namespace migrator#Output: serviceaccount/migratorsa created - Definisci un criterio IAM dalla console OCI per consentire al carico di lavoro di accedere alle risorse OCI dal cluster Kubernetes.
Dalla console OCI, spostarsi tra i menu Identità e sicurezza > Identità > Criteri. Creare i criteri riportati di seguito per consentire l'accesso alle risorse
nosql-familyeobject-family. Usare l'OCID del cluster, dello spazio di nomi e dei valori dell'account di servizio dai passi precedenti.#Command: Allow <subject> to <verb> <resource-type> in <location> where <conditions>#Example: Allow any-user to manage nosql-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'} Allow any-user to manage object-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}Per ulteriori dettagli sulla creazione dei criteri, vedere Utilizzo della console per creare i criteri.
- Impostare il file di configurazione kubeconfig del cluster.
- Creare un cluster Kubernetes utilizzando OKE.
Per eseguire la migrazione dal file JSON nel bucket del sistema operativo OCI alla tabella NDCS, eseguire le operazioni riportate di seguito dalla finestra Cloud Shell.
Per verificare il ripristino dei dati, eseguire il login alla console di Oracle NoSQL Database Cloud Service. Dalla barra di navigazione, andare a Database > Database NoSQL. Selezionare il compartimento dall'elenco a discesa per visualizzare la tabella users. Per la procedura di accesso alla console, vedere Accesso al servizio dalla console dell'infrastruttura.
Eseguire la migrazione da Oracle NoSQL Database a OCI Object Storage utilizzando l'autenticazione del token di sessione
Questo esempio mostra come utilizzare Oracle NoSQL Database Migrator con l'autenticazione del token di sessione per copiare i dati dalla tabella Oracle NoSQL Database in un file JSON in un bucket di storage degli oggetti OCI.
Come sviluppatore, stai esplorando un'opzione per eseguire il backup dei dati della tabella di Oracle NoSQL Database nello storage degli oggetti OCI (OCI OS). Si desidera utilizzare l'autenticazione basata su token di sessione.
In questa dimostrazione, si utilizzeranno i comandi OCI Command Line Interface (CLI) per creare un token di sessione. Sarà possibile creare manualmente un file di configurazione Migrator ed eseguire la migrazione dei dati.
- Identifica l'origine e il flusso per la migrazione.
- Origine: tabella
usersin Oracle NoSQL Database. - Lavello: file JSON nel bucket del sistema operativo OCI
Identifica endpoint, spazio di nomi, bucket e prefisso dell'area per il sistema operativo OCI. Per ulteriori dettagli, vedere Accesso allo storage degli oggetti Oracle Cloud. Per la lista degli endpoint del servizio del sistema operativo OCI, vedere Endpoint di storage degli oggetti.
- endpoint:
us-ashburn-1 - bucket:
Migrate_oci - prefisso:
userSession - spazio di nomi:
idhkv1iewjzjIl nome dello spazio di nomi per un bucket è lo stesso dello spazio di nomi della tenancy e viene generato automaticamente quando viene creata la tenancy. È possibile ottenere il nome dello spazio di nomi come indicato di seguito.- Dalla console di Oracle NoSQL Database Cloud Service, vai a Memorizzazione> Bucket.
- Selezionare un valore per Compartimento dal campo Ambito lista e selezionare il bucket. La pagina Dettagli bucket visualizza il nome nel parametro Spazio di nomi.
Se non si fornisce un nome per lo spazio di nomi del sistema operativo OCI, la utility Migrator utilizza lo spazio di nomi predefinito della tenancy.
Nota
Assicurarsi di disporre dei privilegi per scrivere gli oggetti nel bucket del sistema operativo OCI. Per ulteriori dettagli sull'impostazione dei criteri, vedere Scrivi nello storage degli oggetti. - endpoint:
- Origine: tabella
- Generare un token di sessione effettuando le operazioni riportate di seguito.
- Installare e configurare l'interfaccia CLI OCI. Vedere Avvio rapido.
- Utilizzare uno dei comandi CLI OCI riportati di seguito per generare un token di sessione. Per ulteriori informazioni sulle opzioni disponibili, vedere Autenticazione basata su token per l'interfaccia CLI.
#Create a session token using OCI CLI from a web browser: oci session authenticate --region <region_name> --profile-name <profile_name>#Example: oci session authenticate --region us-ashburn-1 --profile-name SESSIONPROFILEoppure
#Create a session token using OCI CLI without a web browser: oci session authenticate --no-browser --region <region_name> --profile-name <profile_name>#Example: oci session authenticate --no-browser --region us-ashburn-1 --profile-name SESSIONPROFILENel comando precedente,
region_name: specifica l'endpoint dell'area per il sistema operativo OCI. Per una lista di aree dati supportate in Oracle NoSQL Database Cloud Service, vedere Aree dati e URL del servizio associato.profile_name: specifica il profilo utilizzato dal comando CLI OCI per generare un token di sessione.Il comando CLI OCI crea una voce nel file di configurazione OCI nel percorso$HOME/.oci/config, come mostrato nell'esempio riportato di seguito.[SESSIONPROFILE] fingerprint=f1:e9:b7:e6:25:ff:fe:05:71:be:e8:aa:cc:3d:0d:23 key_file=$HOME/.oci/sessions/SESSIONPROFILE/oci_api_key.pem tenancy=ocid1.tenancy.oc1..aaaaa ... d6zjq region=us-ashburn-1 security_token_file=$HOME/.oci/sessions/SESSIONPROFILE/tokensecurity_token_filepunta al percorso del token di sessione generato utilizzando il comando CLI OCI sopra riportato.Nota
- Se il profilo esiste già nel file di configurazione OCI, il comando CLI OCI sovrascrive il profilo con una configurazione correlata alla sessione durante la generazione del token di sessione.
- Specificare quanto segue nel modello di configurazione sink:
- Percorso del file di configurazione OCI nel parametro credentials.
- Profilo utilizzato durante la generazione del token di sessione nel parametro credentialsProfile.
"credentials" : "$HOME/.oci/config" "credentialsProfile" : "SESSIONPROFILE"La utility Migrator recupera automaticamente i dettagli del token di sessione generato utilizzando i parametri precedenti. Se non si specifica il parametro credentials, la utility Migrator cerca il file delle credenziali nel percorso
$HOME/.oci. Se non si specifica il parametro credentialsProfile, la utility Migrator utilizza il nome di profilo predefinito (DEFAULT) dal file di configurazione OCI. - Il token di sessione è valido per 60 minuti. Per estendere la durata della sessione, è possibile aggiornare la sessione. Per informazioni dettagliate, vedere Aggiornamento di un token.
Per eseguire la migrazione dalla tabella Oracle NoSQL Database a un file JSON nel bucket del sistema operativo OCI:
Per verificare il backup dei dati, eseguire il login alla console di Oracle NoSQL Database Cloud Service. Navigare tra i menu, Storage > Object Storage & Archive Storage > Buckets. Accedere ai file dalla directory userSession nel bucket Migrate_oci. Per la procedura di accesso alla console, vedere Accesso al servizio dalla console dell'infrastruttura.
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 flusso 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