Usando o Oracle NoSQL Database Migrator
Saiba mais sobre o Oracle NoSQL Database Migrator e como usá-lo para migração de dados.
O Oracle NoSQL Database Migrator é uma ferramenta que permite migrar tabelas Oracle NoSQL de uma origem de dados para outra. Essa ferramenta pode operar em tabelas no Oracle NoSQL Database Cloud Service, no Oracle NoSQL Database no local e no AWS S3. A ferramenta Migrator suporta vários formatos de dados diferentes e tipos de mídia física. Os formatos de dados suportados são arquivos JSON, Parquet, JSON formatado em MongoDB, JSON formatado em DynamoDB e CSV. Os tipos de mídia física suportados são arquivos, OCI Object Storage, Oracle NoSQL Database on-premises, Oracle NoSQL Database Cloud Service e AWS S3.
Este artigo tem os seguintes tópicos:
Tópicos Relacionados
Visão geral
O Oracle NoSQL Database Migrator permite mover tabelas Oracle NoSQL de uma origem de dados para outra, como o Oracle NoSQL Database on-premises ou na nuvem ou até mesmo um arquivo JSON simples.
Pode haver muitas situações que exigem que você migre tabelas NoSQL de ou para um Oracle NoSQL Database. Por exemplo, uma equipe de desenvolvedores que aprimora um aplicativo NoSQL Database pode querer testar seu código atualizado na instância local do Oracle NoSQL Database Cloud Service (NDCS) usando cloudsim. Para verificar todos os casos de teste possíveis, eles devem configurar os dados de teste semelhantes aos dados reais. Para fazer isso, eles devem copiar as tabelas NoSQL do ambiente de produção para sua instância NDCS local, o ambiente cloudsim. Em outra situação, os desenvolvedores do NoSQL podem precisar mover seus dados de aplicativos do local para a nuvem e vice-versa, seja para desenvolvimento ou teste.
Em todos esses casos e muito mais, você pode usar o Oracle NoSQL Database Migrator para mover suas tabelas NoSQL de uma origem de dados para outra, como o Oracle NoSQL Database no local ou na nuvem ou até mesmo um arquivo JSON simples. Você também pode copiar tabelas NoSQL de um arquivo de entrada JSON formatado em MongoDB, arquivo de entrada JSON formatado em DynamoDB (armazenado na origem ou nos arquivos do AWS S3) ou um arquivo CSV no seu NoSQL Database no local ou na nuvem.
Conforme descrito na figura a seguir, o utilitário NoSQL Database Migrator atua como um conector ou pipe entre a origem de dados e o destino (conhecido como coletor). Em essência, esse utilitário exporta dados da fonte selecionada e importa esses dados para o coletor. Essa ferramenta é orientada a tabelas, ou seja, você só pode mover os dados no nível da tabela. Uma única tarefa de migração opera em uma única tabela e suporta a migração de dados da tabela da origem para o sumário em vários formatos de dados.
Terminologia usada com o Oracle NoSQL Database Migrator
Saiba mais sobre os diferentes termos usados no diagrama acima, em detalhes.
- Origem: Uma entidade de onde as tabelas NoSQL são exportadas para migração. Alguns exemplos de origens são Oracle NoSQL Database no local ou na nuvem, arquivo JSON, arquivo JSON formatado em MongoDB, arquivo JSON formatado em DynamoDB e arquivos CSV.
- Dissipador: Uma entidade que importa as tabelas NoSQL do NoSQL Database Migrator. Alguns exemplos de coletores são Oracle NoSQL Database no local ou na nuvem e arquivo JSON.
A ferramenta NoSQL Database Migrator suporta diferentes tipos de origens e sumidouros (ou seja, mídia física ou repositórios de dados) e formatos de dados (é assim que os dados são representados na origem ou sumidouro). Os formatos de dados suportados são arquivos JSON, Parquet, JSON formatado em MongoDB, JSON formatado em DynamoDB e CSV. Os tipos de origem e sumário suportados são arquivos, OCI Object Storage, Oracle NoSQL Database no local e Oracle NoSQL Database Cloud Service.
- Tubulação de Migração: Os dados de uma origem serão transferidos para o coletor pelo NoSQL Database Migrator. Isso pode ser visualizado como um Pipe de Migração.
- Transformações: Você pode adicionar regras para modificar os dados da tabela NoSQL no pipe de migração. Essas regras são chamadas Transformações. O Oracle NoSQL Database Migrator permite transformações de dados somente nos campos ou colunas de nível superior. Ele não permite transformar os dados nos campos aninhados. Alguns exemplos de transformações permitidas são:
- Soltar ou ignorar uma ou mais colunas,
- Renomear uma ou mais colunas ou
- Agregue várias colunas em um único campo, geralmente um campo JSON.
- Arquivo de Configuração: É um arquivo de configuração no qual você define todos os parâmetros necessários para a atividade de migração em um formato JSON. Posteriormente, você passará esse arquivo de configuração como um único parâmetro para o comando
runMigratorna CLI. Um formato de arquivo de configuração típico é semelhante ao mostrado abaixo.{ "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> }Agrupar Parâmetros Obrigatório (S/N) Objetivo Valores Suportados sourcetypeY Representa a origem da qual os dados serão migrados. A origem fornece dados e metadados (se houver) para migração. Para saber o valor typede cada origem, consulte Origens e Pias Suportados.sourcesource-configuration para o tipo Y Define a configuração da origem. Esses parâmetros de configuração são específicos para o tipo de origem selecionado acima. Consulte Modelos de Configuração de Origem para obter a lista completa de parâmetros de configuração para cada tipo de origem. sinktypeY Representa o coletor para o qual migrar os dados. O coletor é o destino ou o destino da migração. Para saber o valor typede cada origem, consulte Origens e Pias Suportados.sinkconfiguração do coletor para tipo Y Define a configuração da pia. Esses parâmetros de configuração são específicos para o tipo de coletor selecionado acima. Consulte Modelos de Configuração de Vazamento para obter a lista completa de parâmetros de configuração para cada tipo de coletor. transformsconfiguração de transformações P Define as transformações a serem aplicadas aos dados no pipe de migração. Consulte Modelos de Configuração de Transformação para obter a lista completa de transformações suportadas pelo Migrador de Dados NoSQL. - migratorVersionP Versão do Migrador de Dados NoSQL - - abortOnErrorP Especifica se a atividade de migração deve ser interrompida em caso de erro ou não.
O valor padrão é verdadeiro indicando que a migração é interrompida sempre que encontra um erro de migração.
Se você definir esse valor como falso, a migração continuará mesmo no caso de registros com falha ou outros erros de migração. Os registros com falha e os erros de migração serão registrados como WARNINGs no terminal da CLI.
verdadeiro, falso Observação:
Como o arquivo JSON faz distinção entre maiúsculas e minúsculas, todos os parâmetros definidos no arquivo de configuração fazem distinção entre maiúsculas e minúsculas, a menos que especificado de outra forma.
Origens e Receptores Compatíveis
Este tópico fornece a lista de origens e sumários suportados pelo Oracle NoSQL Database Migrator.
Você pode usar qualquer combinação de uma origem e sumário válidos desta tabela para a atividade de migração. No entanto, você deve garantir que pelo menos uma das extremidades, ou seja, origem ou coletor, seja um produto Oracle NoSQL. Você não pode usar o NoSQL Database Migrator para mover os dados da tabela NoSQL de um arquivo para outro.
|
Digite |
Formato |
Origem Válida | Dissipador Válido |
|---|---|---|---|
|
Oracle NoSQL Database |
NA | Y | Y |
|
Oracle NoSQL Database Cloud Service |
NA | Y | Y |
|
Sistema de arquivos |
JSON |
Y | Y |
|
MongoDB JSON |
Y | P | |
|
DynamoDB JSON |
Y | P | |
|
Parquet( |
P | Y | |
|
CSV |
Y | P | |
|
OCI Object Storage |
JSON |
Y | Y |
|
MongoDB JSON |
Y | P | |
|
Parquet( |
P | Y | |
|
CSV |
Y | P | |
| AWS S3 |
DynamoDB JSON |
Y | P |
Observação:
Muitos parâmetros de configuração são comuns na configuração de origem e dissipador. Para facilitar a referência, a descrição desses parâmetros é repetida para cada fonte e sumidouro nas seções de documentação, que explicam os formatos de arquivo de configuração para vários tipos de fontes e sumidouros. Em todos os casos, a sintaxe e a semântica dos parâmetros com o mesmo nome são idênticas.Segurança de Origem e Destinação
Alguns dos tipos de origem e sumidouro têm informações de segurança opcionais ou obrigatórias para fins de autenticação.
Todas as origens e sumidouros que usam serviços no OCI (Oracle Cloud Infrastructure) podem usar determinados parâmetros para fornecer informações de segurança opcionais. Essas informações podem ser fornecidas usando um arquivo de configuração do OCI ou Controlador de Instâncias.
As origens e sumidouros do Oracle NoSQL Database exigirão informações de segurança obrigatórias se a instalação for segura e usar uma autenticação baseada no Oracle Wallet. Essas informações podem ser fornecidas adicionando um arquivo jar ao diretório <MIGRATOR_HOME>/lib.
Autenticação baseada em wallet
Se uma instalação do Oracle NoSQL Database usar a autenticação baseada no Oracle Wallet, você deverá incluir arquivos jar adicionais que façam parte da instalação do EE. Para obter mais informações, consulte Oracle Wallet.
Sem os arquivos jar, você receberá a seguinte mensagem de erro:
Não foi possível localizar kvstore-ee.jar e kvstore-ee-<version>.jar no diretório lib. Copie kvstore-ee.jar e kvstore-ee-<version>.jar para o diretório lib
kvstore-ee.jar e kvstore-ee-<version>.jar do pacote do servidor EE para o diretório <MIGRATOR_HOME>/lib. <MIGRATOR_HOME> é o diretório nosql-migrator-M.N.O/ criado extraindo o pacote Oracle NoSQL Database Migrator e o M.N.O representa os números do software release.major.minor. Por exemplo, nosql-migrator-1.1.0/lib.
Observação:
A autenticação baseada em wallet é suportada SOMENTE na Enterprise Edition (EE) do Oracle NoSQL Database.Autenticando com Principais da Instância
Os principais da instância são um recurso do serviço IAM que permite que as instâncias sejam atores autorizados (ou principais) e possam executar ações em recursos do serviço. Cada instância de computação tem sua própria identidade e faz a autenticação usando os certificados adicionados a ela.
O Oracle NoSQL Database Migrator fornece uma opção para estabelecer conexão com uma nuvem NoSQL e origens e sumidouros do OCI Object Storage usando autenticação do controlador de instâncias. Só é suportado quando a ferramenta NoSQL Database Migrator é usada em uma instância de computação do OCI, por exemplo, a ferramenta NoSQL Database Migrator em execução em uma VM hospedada no OCI. Para ativar esse recurso, use o atributo useInstancePrincipal do arquivo de configuração de origem e coletor de nuvem NoSQL. Para obter mais informações sobre parâmetros de configuração para diferentes tipos de origens e sumidouros, consulte Modelos de Configuração de Origem e Modelos de Configuração de Vazamento .
Para obter mais informações sobre principais de instância, consulte Chamando Serviços de uma Instância.
Workflow para o Oracle NoSQL Database Migrator
Saiba mais sobre as várias etapas envolvidas no uso do utilitário Oracle NoSQL Database Migrator para migrar seus dados NoSQL.
O fluxo de alto nível de tarefas envolvidas no uso do NoSQL Database Migrator é representado na figura abaixo.
Faça download do Utilitário de Migração de Dados NoSQL
runMigrator na interface da linha de comando.
Observação:
O utilitário Oracle NoSQL Database Migrator requer o Java 11 ou versões mais recentes para execução.Identificar a Origem e o Dissipador
- Identificar Esquema da Tabela Sink: Se o coletor for local ou na nuvem do Oracle NoSQL Database, você deverá identificar o esquema da tabela coletora e garantir que os dados de origem correspondam ao esquema de destino. Se necessário, use transformações para mapear os dados de origem para a tabela coletora.
- Esquema Padrão: O NoSQL Database Migrator fornece uma opção para criar uma tabela com o esquema padrão sem a necessidade de predefinir o esquema para a tabela. Isso é útil principalmente ao carregar arquivos de origem JSON no Oracle NoSQL Database.
Se a origem for um arquivo JSON formatado em MongoDB, o esquema padrão da tabela será o seguinte:
CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))Onde:
- tablename = valor fornecido para o atributo de tabela na configuração.
- ID = valor _id de cada documento do arquivo de origem JSON exportado mongoDB.
- DOCUMENTO = Para cada documento no arquivo exportado mongoDB, o conteúdo excluindo o campo _id é agregado na coluna DOCUMENTO.
Se a origem for um arquivo JSON formatado em DynamoDB, o esquema padrão da tabela será o seguinte:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type],DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))Onde:
- TABLE_NAME = valor fornecido para a tabela de sumidouros na configuração
- DDBPartitionKey_name = valor fornecido para a chave de partição na configuração
- DDBPartitionKey_type = valor fornecido para o tipo de dados da chave de partição na configuração
- DDBSortKey_name = valor fornecido para a chave de classificação na configuração, se houver
- DDBSortKey_type = valor fornecido para o tipo de dados da chave de classificação na configuração, se houver
- DOCUMENT = Todos os atributos, exceto a partição e a chave de classificação de um item da tabela do Dynamo DB agregados em uma coluna JSON NoSQL
Se o formato de origem for um arquivo CSV, um esquema padrão não será suportado para a tabela de destino. Você pode criar um arquivo de esquema com uma definição de tabela que contenha o mesmo número de colunas e tipos de dados do arquivo CSV de origem. Para obter mais detalhes sobre a criação do arquivo de Esquema, consulte Fornecendo Esquema de Tabela.
Para todas as outras origens, o esquema padrão será o seguinte:CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))Onde:
- tablename = valor fornecido para o atributo de tabela na configuração.
- ID = Um valor LONG gerado automaticamente.
- DOCUMENTO = O registro JSON fornecido pela origem é agregado na coluna DOCUMENTO.Observação:
Se o valor _id não for fornecido como uma string no arquivo JSON formatado em MongoDB, o NoSQL Database Migrator o converterá em uma string antes de inseri-lo no esquema padrão.
- Esquema Padrão: O NoSQL Database Migrator fornece uma opção para criar uma tabela com o esquema padrão sem a necessidade de predefinir o esquema para a tabela. Isso é útil principalmente ao carregar arquivos de origem JSON no Oracle NoSQL Database.
- Fornecendo Esquema de Tabela: O NoSQL Database Migrator permite que a origem forneça definições de esquema para os dados da tabela usando o atributo schemaInfo. O atributo schemaInfo está disponível em todas as origens de dados que não têm um esquema implícito já definido. Os armazenamentos de dados do dissipador podem escolher qualquer uma das seguintes opções.
- Use o esquema padrão definido pelo NoSQL Database Migrator.
- Use o esquema fornecido pela origem.
- Substitua o esquema fornecido pela origem definindo seu próprio esquema. Por exemplo, se você quiser transformar os dados do esquema de origem em outro esquema, substitua o esquema fornecido pela origem e use o recurso de transformação da ferramenta NoSQL Database Migrator.
O arquivo de esquema de tabela, por exemplo,mytable_schema.ddlpode incluir instruções DDL de tabela. A ferramenta NoSQL Database Migrator executa esse arquivo de esquema de tabela antes de iniciar a migração. A ferramenta de migração não suporta mais de uma instrução DDL por linha no arquivo de esquema. Por exemplo,CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))Observação:
A migração falhará se a tabela estiver presente no coletor e o DDL noschemaPathfor diferente da tabela. - Criar Tabela de Dissipador: Depois de identificar o esquema da tabela de sumário, crie a tabela de sumário por meio da CLI Admin ou usando o atributo
schemaInfodo arquivo de configuração do sumário. Consulte Modelos de Configuração de Vazamento.Observação:
Se a origem for um arquivo CSV, crie um arquivo com os comandos DDL para o esquema da tabela de destino. Forneça o caminho do arquivo no parâmetro schemaInfo.schemaPath do arquivo de configuração do coletor.
Migrando Metadados TTL para Linhas de Tabela
O Tempo de Vida (TTL) é um mecanismo que permite que você expire automaticamente as linhas da tabela. O TTL é expresso como a quantidade de tempo que os dados podem viver na loja. Os dados que atingiram seu valor de timeout de expiração não podem mais ser recuperados e não aparecerão em nenhuma estatística de armazenamento.
Tabela - Migrando metadados TTL
| Tipos de origens | Parâmetro de configuração de origem | Parâmetro de configuração do dissipador |
|---|---|---|
| Oracle NoSQL Database | includeTTL |
includeTTL |
| Oracle NoSQL Database Cloud Service | includeTTL |
includeTTL |
| Arquivo JSON Formatado em DynamoDB | ttlAttributeName |
includeTTL |
| Arquivo JSON formatado em DynamoDB armazenado no AWS S3 | ttlAttributeName |
includeTTL |
Exportando metadados TTL no Oracle NoSQL Database e no Oracle NoSQL Database Cloud Service
O NoSQL Database Migrator fornece o parâmetro de configuração includeTTL para suportar a exportação dos metadados TTL da linha da tabela.
_metadata não será incluído explicitamente nos dados exportados porque seu valor de expiração é sempre 0. O NoSQL Database Migrator exporta o tempo de expiração de cada linha como o número de milissegundos desde a época do UNIX (1o de janeiro de 1970). Por exemplo,//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
}Importando metadados TTL
Opcionalmente, você pode importar metadados TTL usando o parâmetro de configuração includeTTL no modelo de configuração do sumidouro.
O tempo de referência padrão da operação de importação é o tempo atual em milissegundos, obtido de System.currentTimeMillis(), da máquina em que a ferramenta NoSQL Database Migrator está em execução. No entanto, você também pode definir um tempo de referência personalizado usando o parâmetro de configuração ttlRelativeDate se quiser estender o tempo de expiração e importar linhas que, de outra forma, expirariam imediatamente. A extensão é calculada da seguinte forma e adicionada ao tempo de expiração.
Extended time = expiration time - reference timeA operação de importação trata os seguintes casos de uso ao migrar linhas da tabela que contêm metadados TTL. Esses casos de uso só são aplicáveis quando o parâmetro de configuração includeTTL é definido como verdadeiro.
- Caso de uso 1: Nenhuma informação de metadados TTL está presente na linha da tabela de importação.
Se a linha que você deseja importar não contiver informações de TTL, o NoSQL Database Migrator definirá o TTL=0 para a linha.
- Caso de Uso 2: O valor TTL da linha da tabela de origem expirou em relação ao tempo de referência quando a linha da tabela é importada.
A linha da tabela expirada é ignorada e não é gravada na loja.
- Caso de uso 3: O valor TTL da linha da tabela de origem não expirou em relação ao tempo de referência quando a linha da tabela é importada.
A linha da tabela é importada com um valor TTL. No entanto, o valor de TTL importado pode não corresponder ao valor de TTL exportado original por causa das restrições de janela de hora e dia inteiras na classe TimeToLive. Por exemplo,
Considere uma linha de tabela exportada:{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC } }O tempo de referência durante a importação é 1734480000000, que é quarta-feira, 18 de dezembro de 2024 12:00:00 AM.
Linha da tabela importada{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1734739200000 //Saturday, December 21, 2024 12:00:00 AM } }
Importando Metadados TTL no Arquivo JSON Formatado em DynamoDB e no Arquivo JSON Formatado em DynamoDB armazenados no AWS S3
O NoSQL Database Migrator fornece um parâmetro de configuração adicional, ttlAttributeName, para suportar a importação de metadados TTL dos itens de arquivo JSON formatados em DynamoDB.
Os arquivos JSON exportados DynamoDB incluem um atributo específico em cada item para armazenar o timestamp de expiração de TTL. Para, opcionalmente, importar os valores TTL dos arquivos JSON exportados DynamoDB, forneça o nome do atributo específico como um valor para o parâmetro de configuração ttlAttributeName no Arquivo JSON Formatado DynamoDB ou no Arquivo JSON Formatado DynamoDB armazenado nos arquivos de configuração de origem S3 do AWS. Além disso, você deve definir o parâmetro de configuração includeTTL no modelo de configuração do sumidouro. Os sumidouros válidos são Oracle NoSQL Database e Oracle NoSQL Database Cloud Service. O NoSQL Database Migrator armazena informações de TTL no objeto JSON _metadata do item importado.
-
Caso de uso 1: O valor do parâmetro de configuração ttlAttributeName é definido com o nome do atributo TTL especificado no arquivo JSON exportado DynamoDB.
NoSQL Database Migrator importa o tempo de expiração deste item como o número de milissegundos desde a época do UNIX (1o de janeiro de 1970).
Por exemplo, considere um item no arquivo JSON exportado DynamoDB:{ "Item": { "DeptId": { "N": "1" }, "DeptName": { "S": "Engineering" }, "ttl": { "N": "1734616800" } } }Aqui, o atributottlespecifica o valor de tempo de vida do item. Se você definir o parâmetro de configuração ttlAttributeName comottlno arquivo JSON formatado em DynamoDB ou no arquivo JSON formatado em DynamoDB armazenado no arquivo de configuração de origem S3 da AWS, o NoSQL Database Migrator importará o tempo de expiração do item da seguinte forma:{ "DeptId": 1, "document": { "DeptName": "Engineering" } "_metadata": { "expiration": 1734616800000 } }Observação:
Você pode fornecer o parâmetro de configuração ttlRelativeDate no modelo de configuração do sumidouro como o tempo de referência para calcular o tempo de expiração. - Caso de uso 2: O valor do parâmetro de configuração ttlAttributeName é definido; no entanto, o valor não existe como um atributo no item do arquivo JSON exportado DynamoDB.
O NoSQL Database Migrator não importa as informações de metadados TTL para o item fornecido.
- Caso de uso 3: O valor do parâmetro de configuração ttlAttributeName não corresponde ao nome do atributo no item do arquivo JSON exportado DynamoDB.
O NoSQL Database Migrator trata a importação de uma das seguintes maneiras com base na configuração do sumidouro:
- Copia o atributo como um campo normal, se configurado para importação usando o esquema padrão.
- Ignora o atributo se configurado para importação usando um esquema definido pelo usuário.
Importando dados para um sumidouro com uma coluna IDENTITY
Você pode importar os dados de uma origem válida para uma tabela coletora (On-premises/Cloud Services) com uma coluna IDENTITY. Você cria a coluna IDENTITY como GENERATED ALWAYS AS IDENTITY ou GENERATED BY DEFAULT AS IDENTITY. Para obter mais informações sobre a criação de tabelas com uma coluna IDENTITY, consulte Creating Tables With an IDENTITY Column no SQL Reference Guide.
Antes de importar os dados, certifique-se de que a tabela do Oracle NoSQL Database no coletor esteja vazia se existir. Se houver dados pré-existentes na tabela de depósito, a migração poderá levar a problemas como substituir dados existentes na tabela de depósito ou ignorar dados de origem durante a importação.
Tabela de dissipadores com a coluna IDENTITY como GENERATED ALWAY AS IDENTITY
Considere uma pia com a coluna IDENTITY criada como GENERATED ALWAYS AS IDENTITY. A importação de dados depende se a origem fornece ou não os valores para a coluna IDENTITY e o parâmetro de transformação ignoreFields no arquivo de configuração.
Por exemplo, você deseja importar dados de uma origem de arquivo JSON para a tabela do Oracle NoSQL Database como coletor. O esquema da tabela de sumidouros é:
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Condição de origem | Ação do usuário | Resultado da migração |
|---|---|---|
|
CASO 1: Os dados de origem não fornecem um valor para o campo IDENTITY da tabela de sumidouros. Exemplo: arquivo de origem JSON |
Criar/gerar o arquivo de configuração. |
A migração de dados foi bem-sucedida. Os valores da coluna IDENTITY são gerados automaticamente. Dados migrados na tabela sumária |
|
CASO 2: Os dados de origem fornecem valores para o campo IDENTITY da pia. Exemplo: arquivo de origem JSON |
Criar/gerar o arquivo de configuração. Você fornece uma transformação ignoreFields para a coluna de ID no modelo de configuração do coletor.
|
A migração de dados foi bem-sucedida. Os valores de ID fornecidos são ignorados e os valores da coluna IDENTITY são gerados automaticamente. Dados migrados na tabela sumária
migrateID do Oracle NoSQL Database: |
|
Você cria/gera o arquivo de configuração sem a transformação ignoreFields para a coluna IDENTITY. |
A migração de dados falha com a seguinte mensagem de erro: "Cannot set value for a generated always identity column". |
Para obter mais detalhes sobre os parâmetros de configuração de transformação, consulte o tópico Modelos de Configuração de Transformação.
Tabela de dissipadores com a coluna IDENTITY como GENERATED BY DEFAULT AS IDENTITY
Considere uma pia com a coluna IDENTITY criada como GENERATED BY DEFAULT AS IDENTITY. A importação de dados depende se a origem fornece ou não os valores para a coluna IDENTITY e o parâmetro de transformação ignoreFields.
Por exemplo, você deseja importar dados de uma origem de arquivo JSON para a tabela do Oracle NoSQL Database como coletor. O esquema da tabela de sumidouros é:
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Condição de origem | Ação do usuário | Resultado da migração |
|---|---|---|
|
CASO 1: Os dados de origem não fornecem um valor para o campo IDENTITY da tabela de sumidouros. Exemplo: arquivo de origem JSON |
Criar/gerar o arquivo de configuração. |
A migração de dados foi bem-sucedida. Os valores da coluna IDENTITY são gerados automaticamente. Dados migrados na tabela sumária
migrateID do Oracle NoSQL Database: |
|
CASO 2: Os dados de origem fornecem valores para o campo IDENTITY da tabela coletora e é um campo de Chave Primária. Exemplo: arquivo de origem JSON |
Criar/gerar o arquivo de configuração. Você fornece uma transformação ignoreFields para a coluna de ID no modelo de configuração do coletor (Recomendado).
|
A migração de dados foi bem-sucedida. Os valores de ID fornecidos são ignorados e os valores da coluna IDENTITY são gerados automaticamente. Dados migrados na tabela sumária
migrateID do Oracle NoSQL Database: |
|
Você cria/gera o arquivo de configuração sem a transformação ignoreFields para a coluna IDENTITY. |
A migração de dados foi bem-sucedida. Os valores Quando você tenta inserir mais uma linha na tabela sem fornecer um valor de ID, o gerador de sequência tenta gerar automaticamente o valor de ID. O valor inicial do gerador de sequência é 1. Como resultado, o valor do ID gerado pode potencialmente duplicar um dos valores de ID existentes na tabela coletora. Como isso viola a restrição de chave primária, um erro é retornado, e a linha não é inserida. Consulte Gerador de Sequência para obter informações adicionais. Para evitar a violação da restrição de chave primária, o gerador de sequência deve iniciar a sequência com um valor que não entra em conflito com os valores de ID existentes na pia. Para usar o atributo START WITH a fim de fazer essa modificação, consulte o exemplo abaixo: Exemplo: Dados migrados na tabela
migrateID do Oracle NoSQL Database:Para localizar o valor apropriado que o gerador de sequência insira na coluna de ID, extraia o valor máximo do campo
ID usando a seguinte consulta:Saída:
O valor máximo da coluna
ID na tabela de sumidouros é 3. Você deseja que o gerador de sequência comece a gerar os valores de ID além de 3 para evitar duplicação. Atualize o atributo START WITH do gerador de sequência para 4 usando a seguinte instrução:Isso iniciará a sequência em 4. Agora, quando você insere linhas na pia sem fornecer os valores de ID, o gerador de sequência gera automaticamente os valores de ID de 4 em diante, evitando a duplicação dos IDs. |
Para obter mais detalhes sobre os parâmetros de configuração de transformação, consulte o tópico Modelos de Configuração de Transformação.
Execute o comando runMigrator
O arquivo executável runMigrator está disponível nos arquivos extraídos do NoSQL Database Migrator. Você deve instalar o Java 11 ou uma versão superior e o bash no sistema para executar com sucesso o comando runMigrator.
runMigrator de duas maneiras:
- Criando o arquivo de configuração usando as opções de runtime do comando
runMigrator, conforme mostrado abaixo.[~]$ ./runMigrator configuration file is not provided. Do you want to generate configuration? (y/n) [n]: y ... ...- Quando você chama o utilitário
runMigrator, ele fornece uma série de opções de runtime e cria o arquivo de configuração com base em suas opções para cada opção. - Depois que o utilitário criar o arquivo de configuração, você terá a opção de continuar com a atividade de migração na mesma execução ou salvar o arquivo de configuração para uma migração futura.
- Independentemente de sua decisão de continuar ou adiar a atividade de migração com o arquivo de configuração gerado, o arquivo estará disponível para edições ou personalização para atender aos seus requisitos futuros. Você pode usar o arquivo de configuração personalizado para migração posteriormente.
- Quando você chama o utilitário
- Informando um arquivo de configuração criado manualmente (no formato JSON) como um parâmetro de runtime usando a opção
-cou--config. Crie o arquivo de configuração manualmente antes de executar o comandorunMigratorcom a opção-cou--config. Para obter ajuda com os parâmetros de configuração de origem e sumário, consulte Oracle NoSQL Database Migrator Reference.[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
Observação:
O NoSQL Database Migrator consome unidades de leitura ao executar a exportação de dados da tabela do Oracle NoSQL Cloud Service para qualquer sink válido.Andamento do Migrador do Logging
A ferramenta NoSQL Database Migrator fornece opções, que permitem que mensagens de rastreamento, depuração e andamento sejam impressas na saída padrão ou em um arquivo. Essa opção pode ser útil no rastreamento do andamento da operação de migração, especialmente para tabelas ou conjuntos de dados muito grandes.
- Níveis de Log
Para controlar o comportamento de log por meio da ferramenta NoSQL Database Migrator, passe o parâmetro de runtime --log-level ou -l para o comando
runMigrator. Você pode especificar a quantidade de informações de log a serem gravadas informando o valor de nível de log apropriado.$./runMigrator --log-level <loglevel>Exemplo:$./runMigrator --log-level debugTabela - Níveis de Log Suportados para o NoSQL Database Migrator
Nível de Log Descrição advertência Imprime erros e avisos. informações (padrão) Imprime o status do andamento da migração de dados, como validação de origem, validação de sumário, criação de tabelas e contagem do número de registros de dados migrados. depuração Imprimir informações de depuração adicionais. all Imprime tudo. Este nível ativa todos os níveis de registro. - Arquivo de Log:
Você pode especificar o nome do arquivo de log usando o parâmetro --log-file ou -f. Se --log-file for informado como parâmetro de tempo de execução para o comando
runMigrator, o NoSQL Database Migrator gravará todas as mensagens de log no arquivo e na saída padrão.$./runMigrator --log-file <log file name>Exemplo:$./runMigrator --log-file nosql_migrator.log
Demonstrações de Caso de Uso para o Oracle NoSQL Database Migrator
Saiba como executar a migração de dados usando o Oracle NoSQL Database Migrator para casos de uso específicos. Você pode encontrar instruções sistemáticas detalhadas com exemplos de código para executar a migração em cada um dos casos de uso.
Este artigo tem os seguintes tópicos:
Migrar do Oracle NoSQL Database Cloud Service para um arquivo JSON
Este exemplo mostra como usar o Oracle NoSQL Database Migrator para copiar dados e a definição de esquema de uma tabela NoSQL do Oracle NoSQL Database Cloud Service (NDCS) para um arquivo JSON.
Caso de Uso
Uma organização decide treinar um modelo usando os dados do Oracle NoSQL Database Cloud Service (NDCS) para prever comportamentos futuros e fornecer recomendações personalizadas. Eles podem obter uma cópia periódica dos dados das tabelas NDCS para um arquivo JSON e aplicá-la ao mecanismo analítico para analisar e treinar o modelo. Isso os ajuda a separar as consultas analíticas dos caminhos críticos de baixa latência.
Exemplo
Para a demonstração, vamos ver como migrar a definição de dados e esquema de uma tabela NoSQL chamadamyTable do NDCS para um arquivo JSON.- Identifique a origem e o sumário da migração.
- Origem: Oracle NoSQL Database Cloud Service
- Pia: Arquivo JSON
- Identifique suas credenciais da nuvem do OCI e capture-as no arquivo de configuração do OCI. Salve o arquivo de configuração em
/home/.oci/config. Consulte Adquirindo Credenciais.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifique o ponto final da região e o nome do compartimento do Oracle NoSQL Database Cloud Service.
- ponto final:
us-phoenix-1 - compartimento:
developers
- ponto final:
myTable do Oracle NoSQL Database Cloud Service para um arquivo JSON:
Para validar a migração, você pode navegar até o diretório sink especificado e exibir o esquema e os dados.
-- 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)))Migrar do Oracle NoSQL Database Local para o Oracle NoSQL Database Cloud Service
Este exemplo mostra como usar o Oracle NoSQL Database Migrator para copiar dados e a definição de esquema de uma tabela NoSQL do Oracle NoSQL Database para o Oracle NoSQL Database Cloud Service (NDCS).
Caso de Uso
Como desenvolvedor, você está explorando opções para evitar a sobrecarga de gerenciamento de recursos, clusters e coleta de lixo para suas cargas de trabalho existentes do Banco de Dados NoSQL KVStore. Como solução, você decide migrar suas cargas de trabalho KVStore locais existentes para o Oracle NoSQL Database Cloud Service porque o NDCS as gerencia automaticamente.
Exemplo
Para a demonstração, vamos ver como migrar a definição de dados e esquema de uma tabela NoSQL chamadamyTable do Banco de Dados NoSQL KVStore para o NDCS. Também usaremos esse caso de uso para mostrar como executar o utilitário runMigrator especificando um arquivo de configuração pré-criado.- Identifique a origem e o sumário da migração.
- Origem: Oracle NoSQL Database
- Pia: Oracle NoSQL Database Cloud Service
- Identifique suas credenciais da nuvem do OCI e capture-as no arquivo de configuração do OCI. Salve o arquivo de configuração em
/home/.oci/config. Consulte Adquirindo Credenciais em Usando o 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> - Identifique o ponto final da região e o nome do compartimento do Oracle NoSQL Database Cloud Service.
- ponto final:
us-phoenix-1 - compartimento:
developers
- ponto final:
- Identifique os seguintes detalhes para o KVStore local:
- storeName:
kvstore - helperHosts:
<hostname>:5000 - tabela:
myTable
- storeName:
myTable do Banco de Dados NoSQL KVStore para o NDCS:
Para validar a migração, você pode fazer log-in na console do NDCS e verificar se myTable foi criado com os dados de origem.
Migrar da origem de arquivo JSON para o Oracle NoSQL Database Cloud Service
Este exemplo mostra o uso do Oracle NoSQL Database Migrator para copiar dados de uma origem de arquivo JSON para o Oracle NoSQL Database Cloud Service.
Depois de avaliar várias opções, uma organização finaliza o Oracle NoSQL Database Cloud Service como sua plataforma de Banco de Dados NoSQL. Como seu conteúdo de origem está no formato de arquivo JSON, eles estão procurando uma maneira de migrá-los para o Oracle NoSQL Database Cloud Service.
Neste exemplo, você aprenderá a migrar os dados de um arquivo JSON chamado SampleData.json. Execute o utilitário runMigrator especificando um arquivo de configuração pré-criado. Se o arquivo de configuração não for fornecido como um parâmetro de tempo de execução, o utilitário runMigrator solicitará que você gere a configuração por meio de um procedimento interativo.
- Identifique a origem e o sumário da migração.
- Origem: arquivo de origem JSON.
SampleData.jsoné o arquivo de origem. Ele contém vários documentos JSON com um documento por linha, delimitados por um novo caractere de linha.{"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"}} - Pia: Oracle NoSQL Database Cloud Service.
- Origem: arquivo de origem JSON.
- Identifique suas credenciais da nuvem do OCI e capture-as no arquivo de configuração. Salve o arquivo de configuração em
/home/user/.oci/config. Para obter mais detalhes, consulte Adquirindo Credenciais em Usando o 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> - Identifique o ponto final da região e o nome do compartimento do Oracle NoSQL Database Cloud Service.
- ponto final:
us-ashburn-1 - compartimento:
Training-NoSQL
- ponto final:
- Identifique os seguintes detalhes para o arquivo de origem JSON:
-
schemaPath:
<absolute path to the schema definition file containing DDL statements for the NoSQL table at the sink>.Neste exemplo, o arquivo DDL éschema_json.ddl.create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id));O Oracle NoSQL Database Migrator fornece uma opção para criar uma tabela com o esquema padrão se o
schemaPathnão for fornecido. Para obter mais detalhes, consulte o tópico Identificar a Origem e o Dissipador no Workflow do Oracle NoSQL Database Migrator. - Caminho de dados:
<absolute path to a file or directory containing the JSON data for migration>.
-
SampleData.json para o Oracle NoSQL Database Cloud Service, execute o seguinte:
Migrate_JSON foi criada com os dados de origem. Para obter o procedimento para acessar a console, consulte o artigo Acessando o Serviço na Console de Infraestrutura no documento do Oracle NoSQL Database Cloud Service.
Figura - Tabelas da Console do Oracle NoSQL Database Cloud Service
Figura - Dados da Tabela da Console do Oracle NoSQL Database Cloud Service
Migrar do arquivo JSON MongoDB para um Oracle NoSQL Database Cloud Service
Este exemplo mostra como usar o Oracle NoSQL Database Migrator para copiar Dados Formatados do Mongo-DB para o Oracle NoSQL Database Cloud Service (NDCS).
Caso de Uso
Depois de avaliar várias opções, uma organização finaliza o Oracle NoSQL Database Cloud Service como sua plataforma de Banco de Dados NoSQL. Como suas tabelas e dados NoSQL estão em MongoDB, eles estão procurando uma maneira de migrar essas tabelas e dados para o Oracle NDCS.
Você pode copiar um arquivo ou diretório contendo os dados JSON exportados MongoDB para migração especificando o arquivo ou diretório no modelo de configuração de origem.
{"_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"}]}
O MongoDB suporta dois tipos de extensões para o formato JSON de arquivos, Modo canônico e Modo relaxado. Você pode fornecer o arquivo JSON formatado em MongoDB que é gerado usando a ferramenta mongoexport no modo Canônico ou Relaxado. Ambos os modos são suportados pelo NoSQL Database Migrator para migração.
Para obter mais informações sobre o arquivo MongoDB Extended JSON (v2), consulte mongoexport_formats.
Para obter mais informações sobre a geração de arquivo JSON formatado em MongoDB, consulte mongoexport.
Exemplo
Para a demonstração, vamos ver como migrar um arquivo JSON formatado em MongoDB para o NDCS. Usaremos um arquivo de configuração criado manualmente para este exemplo.- Identifique a origem e o sumário da migração.
- Origem: Arquivo JSON Formatado em MongoDB
- Pia: Oracle NoSQL Database Cloud Service
- Extraia os dados do BD Mongo usando o utilitário mongoexport. Para obter mais informações, consulte mongoexport.
- Crie uma tabela NoSQL no dissipador com um esquema de tabela que corresponda aos dados no arquivo JSON formatado pelo Mongo-DB. Como alternativa, você pode instruir o NoSQL Database Migrator a criar uma tabela com a estrutura de esquema padrão definindo o atributo
defaultSchemacomo verdadeiro.Observação:
Para uma origem JSON Formatada por MongoDB, o esquema padrão da tabela será:CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))Onde:tablename= valor da configuração da tabela.ID= valor_iddo arquivo de origem JSON exportado mongoDB.DOCUMENT= Todo o conteúdo do arquivo de origem JSON exportado mongoDB é agregado à colunaDOCUMENT, excluindo o campo_id.
- Identifique suas credenciais da nuvem do OCI e capture-as no arquivo de configuração do OCI. Salvar o arquivo de configuração em
/home/.oci/config. Consulte Adquirindo Credenciais em Usando o 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> - Identifique o ponto final da região e o nome do compartimento do Oracle NoSQL Database Cloud Service.
- ponto final:
us-phoenix-1 - compartimento:
developers
- ponto final:
Para migrar os dados JSON formatados em MongoDB para o Oracle NoSQL Database Cloud Service:
Para validar a migração, você pode fazer log-in na console do NDCS e verificar se myTable foi criado com os dados de origem.
Migrar do arquivo JSON DynamoDB para o Oracle NoSQL Database
Este exemplo mostra como usar o Oracle NoSQL Database Migrator para copiar o arquivo JSON DynamoDB para o NoSQL Database.
Caso de Uso:
Depois de avaliar várias opções, uma organização finaliza o Oracle NoSQL Database em relação ao banco de dados DynamoDB. A organização deseja migrar suas tabelas e dados do DynamoDB para o Oracle NoSQL Database (on-premises).
Consulte Mapeamento da tabela DynamoDB para a tabela Oracle NoSQL para obter mais detalhes.
Você pode migrar um arquivo ou diretório contendo os dados JSON exportados DynamoDB de um sistema de arquivos especificando o caminho no modelo de configuração de origem.
{"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"}}}
Copie os dados da tabela DynamoDB exportados do armazenamento S3 do AWS para um sistema de arquivos montado local.
Exemplo:
Para esta demonstração, você aprenderá a migrar um arquivo JSON DynamoDB para o Oracle NoSQL Database (on-premises). Você usará um arquivo de configuração criado manualmente para este exemplo.
Pré-requisitos
- Identifique a origem e o sumário da migração.
- Fonte: DynamoDB Arquivo JSON
- Sink: Oracle NoSQL Database (on-premises)
- Para importar dados da tabela DynamoDB para o Oracle NoSQL Database, primeiro exporte a tabela DynamoDB para S3. Consulte as etapas fornecidas em Exportando dados da tabela DynamoDB para o Amazon S3 para exportar sua tabela. Durante a exportação, você seleciona o formato como DynamoDB JSON. Os dados exportados contêm dados da tabela DynamoDB em vários arquivos
gzip, conforme mostrado abaixo./ 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 - Você deve fazer download dos arquivos do AWS S3. A estrutura dos arquivos após o download será como mostrado abaixo.
download-dir/01639372501551-bb4dd8c3 |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started
Procedimento
- Prepare o arquivo de configuração (no formato JSON) com a origem identificada e os detalhes do sumidouro. Para obter detalhes, consulte Modelos de Configuração de Origem e Modelos de Configuração de Dissipador.
Observação:
Se os itens da tabela JSON exportados DynamoDB contiverem o atributo TTL, para, opcionalmente, importar os valores de TTL, especifique o atributo no parâmetro de configuração ttlAttributeName do modelo de configuração de origem e defina o parâmetro de configuração includeTTL como verdadeiro no modelo de configuração de sumidouro.Você pode escolher uma das duas opções a seguir.- Opção 1: Importando a tabela DynamoDB como um documento JSON usando a configuração de esquema padrão.
Aqui, você define o parâmetro de configuração defaultSchema como verdadeiro. Portanto, o NoSQL Database Migrator cria o esquema padrão no sumidouro. Você deve especificar o
DDBPartitionKeye o tipo de coluna NoSQL correspondente. Caso contrário, um erro será exibido.Para obter detalhes sobre o esquema padrão de uma origem JSON exportada DynamoDB, consulte o tópico Identificar a Origem e o Sink no Workflow para o 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" }O seguinte esquema padrão é usado neste exemplo:CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) - Opção 2: Importando a tabela DynamoDB como colunas fixas usando um arquivo de esquema fornecido pelo usuário.
Aqui, você define o parâmetro de configuração defaultSchema como falso. Portanto, você especifica o arquivo que contém a instrução DDL da tabela de sumariação no parâmetro schemaPath. Consulte Mapeamento de tipos DynamoDB para tipos NoSQL Oracle para obter mais detalhes.
O seguinte esquema definido pelo usuário é usado neste exemplo:CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))NoSQL Database Migrator usa o arquivo de esquema para criar a tabela no sumidouro como parte da migração. Desde que os dados da chave primária sejam fornecidos, o registro JSON de entrada será inserido. Caso contrário, um erro será exibido.
Observação:
- Se a tabela do banco de dados Dynamo tiver um tipo de dados que não seja suportado no NoSQL Database, a migração falhará.
- Se os dados de entrada não contiverem um valor para uma coluna específica (diferente da chave primária), o valor padrão da coluna será usado. O valor padrão deve fazer parte da definição da coluna ao criar a tabela. Por exemplo,
id INTEGER not null default 0. Se a coluna não tiver uma definição padrão, SQL NULL será inserido se não forem fornecidos valores para a coluna. - Se você estiver modelando a tabela DynamoDB como um documento JSON, certifique-se de usar a transformação
AggregateFieldspara agregar dados de chave não primária em uma coluna JSON. Para obter detalhes, consulte 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" }
- Opção 1: Importando a tabela DynamoDB como um documento JSON usando a configuração de esquema padrão.
- Abra o prompt de comando e navegue até o diretório em que você extraiu o utilitário NoSQL Database Migrator.
- Execute o comando
runMigratorinformando arquivos de configuração separados para as opções 1 e 2. Use a opção--configou-c../runMigrator --config <complete/path/to/the/JSON/config/file> - O utilitário prossegue com a migração de dados conforme ilustrado no seguinte exemplo:
[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.
Validação
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoreSELECT * FROM sampledynDBImpSaída
_metadata para cada item importado.{"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}}}Migrar do arquivo JSON DynamoDB no AWS S3 para um Oracle NoSQL Database Cloud Service
Este exemplo mostra como usar o Oracle NoSQL Database Migrator para copiar o arquivo JSON DynamoDB armazenado em um armazenamento S3 da AWS para o Oracle NoSQL Database Cloud Service (NDCS).
Caso de Uso:
Depois de avaliar várias opções, uma organização finaliza o Oracle NoSQL Database Cloud Service no banco de dados DynamoDB. A organização deseja migrar suas tabelas e dados de DynamoDB para o Oracle NoSQL Database Cloud Service.
Consulte Mapeamento da tabela DynamoDB para a tabela Oracle NoSQL para obter mais detalhes.
Você pode migrar um arquivo contendo os dados JSON exportados DynamoDB do armazenamento S3 da AWS especificando o caminho no modelo de configuração de origem.
{"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"}}}
Exporte a tabela DynamoDB para o armazenamento S3 da AWS conforme especificado em Exportando dados da tabela DynamoDB para o Amazon S3.
Exemplo:
Para esta demonstração, você aprenderá a migrar um arquivo JSON DynamoDB em uma origem S3 da AWS para o NDCS. Você usará um arquivo de configuração criado manualmente para este exemplo.
Pré-requisitos
- Identifique a origem e o sumário da migração.
- Fonte: DynamoDB Arquivo JSON no AWS S3
- Dissipador: Oracle NoSQL Database Cloud Service
- Identifique a tabela no AWS DynamoDB que precisa ser migrada para o NDCS. Faça login no console da AWS usando suas credenciais. Vá para DynamoDB. Em Tabelas, escolha a tabela a ser migrada.
- Crie um bucket de objeto e exporte a tabela para S3. No console da AWS, vá para S3. Em buckets, crie um novo bucket de objeto. Volte para DynamoDB e clique em Exportações para S3. Forneça a tabela de origem e o bucket S3 de destino e clique em Exportar.
Consulte as etapas fornecidas em Exportando dados da tabela DynamoDB para o Amazon S3 para exportar sua tabela. Durante a exportação, você seleciona o formato como DynamoDB JSON. Os dados exportados contêm dados da tabela DynamoDB em vários arquivos
gzip, conforme mostrado abaixo./ 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 - Você precisa de credenciais da aws (incluindo ID da chave de acesso e chave de acesso secreto) e arquivos de configuração (credenciais e opcionalmente configuração) para acessar o AWS S3 do migrador. Consulte Definir e exibir definições de configuração para obter mais detalhes sobre os arquivos de configuração. Consulte Criando um par de chaves para obter mais detalhes sobre como criar chaves de acesso.
- Identifique suas credenciais da nuvem do OCI e capture-as no arquivo de configuração do OCI. Salve o arquivo de configuração em um diretório
.ocino diretório home (~/.oci/config). Consulte Adquirindo Credenciais para obter mais detalhes.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifique o ponto final da região e o nome do compartimento do Oracle NoSQL Database. Por exemplo,
- ponto final: us-phoenix-1
- compartimento: desenvolvedores
Procedimento
- Prepare o arquivo de configuração (no formato JSON) com a origem identificada e os detalhes do sumidouro. Para obter detalhes, consulte Modelos de Configuração de Origem e Modelos de Configuração de Dissipador.
Observação:
Se os itens em seu Arquivo JSON DynamoDB no AWS S3 contiverem o atributo TTL, para, opcionalmente, importar os valores de TTL, especifique o atributo no parâmetro de configuração ttlAttributeName do modelo de configuração de origem e defina o parâmetro de configuração includeTTL como verdadeiro no modelo de configuração de sumidouro. Para obter mais detalhes, consulte Migrando Metadados TTL para Linhas da Tabela.Você pode escolher uma das duas opções a seguir.- Opção 1: Importando a tabela DynamoDB como um documento JSON usando a configuração de esquema padrão.
Aqui, o defaultSchema é
TRUEe, portanto, o migrador cria o esquema padrão no sumidouro. Você precisa especificar o DDBPartitionKey e o tipo de coluna NoSQL correspondente. Caso contrário, um erro será gerado.{ "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" }Para uma origem JSON DynamoDB, o esquema padrão da tabela será conforme mostrado abaixo: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 = valor fornecido para a 'tabela' do coletor na configuração
DDBPartitionKey_name = valor fornecido para a chave de partição na configuração
DDBPartitionKey_type = valor fornecido para o tipo de dados da chave de partição na configuração
DDBSortKey_name = valor fornecido para a chave de classificação na configuração, se houver
DDBSortKey_type = valor fornecido para o tipo de dados da chave de classificação na configuração, se houver
DOCUMENT = Todos os atributos, exceto a partição e a chave de classificação de um item da tabela do Dynamo DB agregados em uma coluna JSON NoSQL
- Opção 2: Importando a tabela DynamoDB como colunas fixas usando um arquivo de esquema fornecido pelo usuário.
Aqui, o defaultSchema é
FALSEe você especifica o schemaPath como um arquivo que contém sua instrução DDL. Para obter detalhes, consulte Mapeamento de tipos DynamoDB para tipos NoSQL Oracle para obter mais detalhes.Observação:
Se a tabela do Dynamo DB tiver um tipo de dados não suportado em NoSQL, a migração falhará.Um arquivo de esquema de amostra é mostrado abaixo.CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, PRIMARY KEY(SHARD(AccountId)));O arquivo de esquema é usado para criar a tabela no coletor como parte da migração. Desde que os dados da chave primária sejam fornecidos, o registro JSON de entrada será inserido; caso contrário, ele gerará um erro.Observação:
- Se os dados de entrada não contiverem um valor para uma determinada coluna (diferente da chave primária), o valor padrão da coluna será usado. O valor padrão deve fazer parte da definição da coluna ao criar a tabela. Por exemplo,
id INTEGER not null default 0. Se a coluna não tiver uma definição padrão, SQL NULL será inserido se nenhum valor for fornecido para a coluna. - Se você estiver modelando a tabela DynamoDB como um documento JSON, certifique-se de usar a transformação
AggregateFieldspara agregar dados de chave não primária em uma coluna JSON. Para obter detalhes, consulte 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 os dados de entrada não contiverem um valor para uma determinada coluna (diferente da chave primária), o valor padrão da coluna será usado. O valor padrão deve fazer parte da definição da coluna ao criar a tabela. Por exemplo,
- Opção 1: Importando a tabela DynamoDB como um documento JSON usando a configuração de esquema padrão.
- Abra o prompt de comando e navegue até o diretório em que você extraiu o utilitário NoSQL Database Migrator.
- Execute o comando
runMigratorinformando o arquivo de configuração com a opção--configou-c.[~/nosqlMigrator]$./runMigrator --config <complete/path/to/the/JSON/config/file> - O utilitário prossegue com a migração de dados, conforme mostrado abaixo.
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
Validação
Você pode fazer log-in na console do NDCS e verificar se a nova tabela foi criada com os dados de origem.
Migrar entre regiões do Oracle NoSQL Database Cloud Service
Este exemplo mostra o uso do Oracle NoSQL Database Migrator para executar a migração entre regiões.
Caso de uso
Uma organização usa o Oracle NoSQL Database Cloud Service para armazenar e gerenciar seus dados. Ele decide replicar dados de uma região existente para uma região mais nova para fins de teste antes que a nova região possa ser iniciada para o ambiente de produção.
Nesse caso de uso, você aprenderá a usar o NoSQL Database Migrator para copiar dados da tabela user_data na região Ashburn para a região Phoenix.
Execute o utilitário runMigrator especificando um arquivo de configuração pré-criado. Se você não fornecer o arquivo de configuração como um parâmetro de runtime, o utilitário runMigrator solicitará que você gere a configuração por meio de um procedimento interativo.
- Faça download do Oracle NoSQL Database Migrator na página Downloads do Oracle NoSQL e extraia o conteúdo para sua máquina. Para obter detalhes, consulte Workflow para o Oracle NoSQL Database Migrator.
- Identifique a origem e o sumário da migração.
- Origem: A tabela
user_datana região Ashburn.A tabelauser_datainclui os seguintes dados:{"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":"***"}Identifique o ponto final da região ou o ponto final de serviço e o nome do compartimento da sua origem.- ponto final:
us-ashburn-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- ponto final:
- Sink: A tabela
user_datana região Phoenix.Identifique o ponto final da região ou o ponto final de serviço e o nome do compartimento do seu dissipador.- ponto final:
us-phoenix-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identifica o esquema da tabela de sumários.
Você pode usar o mesmo nome e esquema de tabela da tabela de origem. Para obter informações sobre outras opções de esquema, consulte o tópico Identificar a Origem e o Dissipador em Workflow do Oracle NoSQL Database Migrator
- ponto final:
- Origem: A tabela
- Identifique suas credenciais da nuvem do OCI para ambas as regiões e capture-as no arquivo de configuração. Salve o arquivo de configuração em sua máquina no local
/home/<user>/.oci/config. Para obter mais detalhes, consulte Adquirindo Credenciais.
Observação:
- Se as regiões estiverem em tenancies diferentes, forneça perfis diferentes no arquivo
/home/<user>/.oci/configcom credenciais apropriadas da nuvem do OCI para cada uma delas. - Se as regiões estiverem na mesma tenancy, você poderá ter um único perfil no arquivo
/home/<user>/.oci/config.
Neste exemplo, as regiões estão em tenancies diferentes. O perfil DEFAULT inclui credenciais do OCI para a região Ashburn e DEFAULT2 inclui credenciais do OCI para a região Phoenix.
endpoint do arquivo de configuração do migrador (modelos de configuração de origem e dissipador), você pode fornecer o URL do ponto final de serviço ou o ID da região das regiões. Para obter a lista de regiões de dados suportadas para o Oracle NoSQL Database Cloud Service e seus URLs de ponto final de serviço, consulte Regiões de Dados e URLs de Serviço Associados no documento do 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 da região Ashburn para a região Phoenix, execute o seguinte:
Para validar a migração, você pode fazer log-in na console do Oracle NoSQL Database Cloud Service na região Phoenix. Verifique se os dados de origem da tabela user_data na região Ashburn são copiados para a tabela user_data nessa região. Para obter o procedimento para acessar a console, consulte o artigo Accessing the Service from the Infrastructure Console.
Migre do Oracle NoSQL Database Cloud Service para o OCI Object Storage
Este exemplo mostra o uso do Oracle NoSQL Database Migrator de um Cloud Shell.
Caso de uso
Uma empresa iniciante planeja usar o Oracle NoSQL Database Cloud Service como sua solução de armazenamento de dados. A empresa deseja usar o Oracle NoSQL Database Migrator para copiar dados de uma tabela no Oracle NoSQL Database Cloud Service para o OCI Object Storage a fim de fazer backups periódicos de seus dados. Como medida econômica, eles desejam executar o utilitário NoSQL Database Migrator no Cloud Shell, que é acessível a todos os usuários do OCI.
Nesse caso de uso, você aprenderá a copiar o utilitário NoSQL Database Migrator para um Cloud Shell na região assinada e executar uma migração de dados. Você migra os dados de origem da tabela do Oracle NoSQL Database Cloud Service para um arquivo JSON no OCI Object Storage.
Execute o utilitário runMigrator especificando um arquivo de configuração pré-criado. Se você não fornecer o arquivo de configuração como um parâmetro de runtime, o utilitário runMigrator solicitará que você gere a configuração por meio de um procedimento interativo.
- Faça download do Oracle NoSQL Database Migrator na página Downloads do Oracle NoSQL para sua máquina local.
- Inicie o Cloud Shell no menu Ferramentas do desenvolvedor na console da nuvem. O navegador da Web abre o diretório home. Clique no menu do Cloud Shell no canto superior direito da janela do Cloud Shell e selecione a opção fazer upload na lista drop-down. Na janela pop-up, arraste e solte o pacote Oracle NoSQL Database Migrator da sua máquina local ou clique na opção Selecionar no seu computador, selecione o pacote na sua máquina local e clique no botão Fazer Upload. Você também pode arrastar e soltar o pacote Oracle NoSQL Database Migrator diretamente da sua máquina local para o diretório home no Cloud Shell. Extraia o conteúdo do pacote.
- Identifique a origem e o sumidouro do backup.
-
Origem: tabela
NDCSuploadna região Ashburn do Oracle NoSQL Database Cloud Service.Para demonstração, considere os seguintes dados na tabelaNDCSupload:{"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}Identifique o ponto final e o ID do compartimento de sua origem. Para o ponto final, você pode fornecer o identificador de região ou o ponto final de serviço. Para obter a lista de regiões de dados suportadas no Oracle NoSQL Database Cloud Service, consulte Regiões de Dados e URLs de Serviços Associados.
- ponto final:
us-ashburn-1 - ID do compartimento:
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- ponto final:
-
Pia: arquivo JSON no Bucket do OCI Object Storage.
Identifique o ponto final, o namespace, o bucket e o prefixo da região para o OCI Object Storage. Para obter mais detalhes, consulte Acessando o Oracle Cloud Object Storage. Para obter a lista de pontos finais do serviço OCI Object Storage, consulte Pontos Finais do Serviço Object Storage.
- ponto final:
us-ashburn-1 - bucket:
Migrate_oci - prefixo:
Delegation - namespace: <> Se você não fornecer um namespace, o utilitário usará o namespace padrão da tenancy.
Observação:
Se o Bucket do Object Storage estiver em outro compartimento, certifique-se de ter os privilégios para gravar objetos no bucket. Para obter mais detalhes sobre como definir as políticas, consulte Gravar objetos no serviço Object Storage. - ponto final:
-
NDCSupload do Oracle NoSQL Database Cloud Service para um arquivo JSON no Bucket do OCI Object Storage usando o Cloud Shell, faça o seguinte:
Para validar seu backup de dados, faça log-in na console do Oracle NoSQL Database Cloud Service. Navegue pelos menus, Storage > Object Storage & Archive Storage > Buckets. Acesse os arquivos do diretório NDCSupload/Delegation no bucket Migrate_oci. Para obter o procedimento para acessar a console, consulte o artigo Accessing the Service from the Infrastructure Console.
Migrar do OCI Object Storage para o Oracle NoSQL Database Cloud Service Usando a Autenticação do OKE
Este exemplo mostra como usar o Oracle NoSQL Database Migrator com a Autenticação de Identidade de Carga de Trabalho do OKE para copiar dados de um arquivo JSON no OCI Object Storage para a tabela do Oracle NoSQL Database Cloud Service.
Uso do caso
Como desenvolvedor, você está explorando uma opção para restaurar dados de um arquivo JSON no bucket do OCI Object Storage (OCI OS) para a tabela do Oracle NoSQL Database Cloud Service (NDCS) usando o NoSQL Database Migrator em um aplicativo em contêiner. Um aplicativo conteinerizado é um ambiente virtualizado que agrupa o aplicativo e todas as suas dependências (como bibliotecas, binários e arquivos de configuração) em um pacote. Isso permite que o aplicativo seja executado de forma consistente em diferentes ambientes, independentemente da infraestrutura subjacente.
Você deseja executar o NoSQL Database Migrator em um pod do Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). Para acessar com segurança OS serviços OS e NDCS do OCI no pod do OKE, você usará o método de Autenticação de Identidade de Carga de Trabalho (WIA).
Nesta demonstração, você criará uma imagem do docker para o NoSQL Database Migrator, copiará a imagem em um repositório no Container Registry, criará um cluster do OKE e implantará a imagem do Migrator no pod de cluster do OKE para executar o utilitário Migrator. Aqui, você fornecerá um arquivo de configuração NoSQL Database Migrator criado manualmente para executar o utilitário Migrator como um aplicativo em contêiner.
- Identifique a origem e o sumário da migração.
- Origem: arquivos JSON e arquivo de esquema no bucket do SO do OCI.
Identifique o ponto final da região, o namespace, o bucket e o prefixo do OCI OS em que OS arquivos e o esquema JSON de origem estão disponíveis. Para obter mais detalhes, consulte Acessando o Oracle Cloud Object Storage. Para obter a lista de pontos finais do serviço OCI OS, consulte Pontos Finais do Serviço Object Storage.
- ponto final:
us-ashburn-1 - bucket:
Migrate_oci - prefixo:
userSession - namespace:
idhkv1iewjzjO nome do namespace de um bucket é o mesmo do namespace da tenancy e é gerado automaticamente quando sua tenancy é criada. Você pode obter o nome do namespace da seguinte forma:- Na console do Oracle NoSQL Database Cloud Service, navegue até Armazenamento > Buckets.
- Selecione o Compartimento no Escopo da Lista e selecione o bloco. A página Detalhes do Bucket exibe o nome no parâmetro Namespace.
Se você não fornecer um nome de namespace do OCI OS, o utilitário Migrator usará o namespace padrão da tenancy.
- ponto final:
- Dissipador: tabela
usersno Oracle NoSQL Database Cloud Service.Identifique o ponto final da região ou o ponto final do serviço e o nome do compartimento do seu dissipador:
- ponto final:
us-ashburn-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identifique o esquema da tabela sumidoura:
Para usar o nome da tabela e o esquema armazenados no bucket do SO do OCI, defina o parâmetro useSourceSchema como verdadeiro. Para obter informações sobre outras opções de esquema, consulte o tópico Identificar Origem e Dissipador no Workflow para o Oracle NoSQL Database Migrator.
Observação:
Certifique-se de ter os privilégios de gravação no compartimento no qual você está restaurando dados para a tabela NDCS. Para obter mais detalhes, consulte Gerenciando Compartimentos. - ponto final:
- Origem: arquivos JSON e arquivo de esquema no bucket do SO do OCI.
- Prepare uma imagem do Docker para o NoSQL Database Migrator e mova-a para o Container Registry.
- Obtenha o namespace da tenancy na console do OCI.
Faça log-in na console do Oracle NoSQL Database Cloud Service. Na barra de navegação, selecione o menu Perfil e, em seguida, selecione Tenancy: <Tenany name>.
Copie o nome do namespace do Object Storage, que é o espaço de nomes da tenancy, para a área de transferência.
- Crie uma imagem do Docker para o utilitário Migrator.
Navegue até o diretório em que você extraiu o utilitário NoSQL Database Migrator. O pacote Migrator inclui um arquivo do docker denominado Dockerfile. Em uma interface de comando, use o seguinte comando para criar uma imagem do Docker do utilitário Migrator:
#Command: docker build -t nosqlmigrator:<tag> .#Example: docker build -t nosqlmigrator:1.0 .Você pode especificar um identificador de versão para a imagem do Docker na opçãotag. Verifique sua imagem do Docker usando o 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 ------------------------------------------------------------------------------------------ - Gere um token de Autenticação.
Você precisa de um token de Autenticação para fazer log-in no Container Registry a fim de armazenar a imagem do Migrator Docker. Se você ainda não tiver um token de Autenticação, deverá gerar um. Para obter detalhes, consulte Obtendo um Token de Autorização.
- Armazene a imagem do Migrator Docker no Container Registry.
Para acessar a Imagem do Migrator Docker no pod do Kubernetes, você deve armazenar a imagem em qualquer registro público ou privado. Por exemplo, Docker, Artifact Hub, OCI Container Registry etc. são alguns registros. Nesta demonstração, usamos Container Registry. Para obter detalhes, consulte Visão Geral do Serviço Container Registry.
- Na console do OCI, crie um repositório no Container Registry. Para obter detalhes, consulte Criando um Repositório.
Para esta demonstração, você cria o repositório
okemigrator. - Faça login no Container Registry na interface de comando usando o seguinte 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!No comando acima,
region-key: Especifica a chave da região na qual você está usando o Container Registry. Para obter detalhes, consulte Disponibilidade por Região.tenancy-namespace: Especifica o namespace da tenancy que você copiou da console do OCI.user name: Especifica o nome do usuário da console do OCI.password: Especifica seu token de Autenticação. - Marque e envie sua imagem do Migrator Docker para o Container Registry usando os seguintes comandos:
#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.0No comando acima,
repo: Especifica o nome do repositório que você criou no Container Registry.tag: Especifica o identificador de versão da imagem do 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
- Na console do OCI, crie um repositório no Container Registry. Para obter detalhes, consulte Criando um Repositório.
- Obtenha o namespace da tenancy na console do OCI.
- Configurar um cluster do OKE com WIA para NDCS e SO do OCI.
- Criar um cluster do Kubernetes usando o OKE.
Na console do OCI, defina e crie um cluster do Kubernetes com base na disponibilidade de recursos de rede usando o OKE. Você precisa do cluster do Kubernetes para executar o utilitário Migrator como um aplicativo em contêiner. Para obter detalhes sobre a criação de clusters, consulte Criando Clusters do Kubernetes Usando Workflows da Console.
Para esta demonstração, você pode criar um cluster gerenciado por um único nó usando o workflow Criação Rápida detalhado no link acima.
Figura - Cluster do Kubernetes para o Contêiner do Migrador
- Configurar o WIA na console do OCI para acessar outros recursos do OCI do Cluster do Kubernetes.
Para conceder ao utilitário Migrator acesso ao bucket do NDCS e do OCI OS durante a execução dos pods de cluster do Kubernetes, configure o WIA. Siga estas etapas:
- Configure o arquivo de configuração kubeconfig do cluster.
- Na console do OCI, abra o cluster do Kubernetes que você criou e clique no botão Access Cluster.
- Na caixa de diálogo Acessar Seu Cluster, clique em Acesso ao Cloud Shell.
- Clique em Iniciar Cloud Shell para exibir a janela do Cloud Shell.
- Execute o comando do Oracle Cloud Infrastructure CLI para configurar o arquivo kubeconfig. Você pode copiar o comando da caixa de diálogo Acessar Seu Cluster. Você pode esperar a seguinte saída:
#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
- Copie o OCID do cluster da opção
cluster-idno comando acima e salve-o para usar em etapas adicionais.ocid1.cluster.oc1.iad.aaa...muqzq - Crie um namespace para a conta de serviço do Kubernetes usando o seguinte comando na janela do Cloud Shell:
#Command: kubectl create namespace <namespace-name>#Example: kubectl create namespace migrator#Output: namespace/migrator created - Crie uma conta de serviço do Kubernetes para o aplicativo Migrator em um namespace usando o seguinte comando na janela do Cloud Shell:
#Command: kubectl create serviceaccount <service-account-name> --namespace <namespace-name>#Example: kubectl create serviceaccount migratorsa --namespace migrator#Output: serviceaccount/migratorsa created - Definir uma política do IAM na console do OCI para permitir que a carga de trabalho acesse os recursos do OCI no cluster do Kubernetes.
Na console do OCI, navegue pelos menus Identity & Security > Identity > Policies. Crie as políticas a seguir para permitir o acesso aos recursos
nosql-familyeobject-family. Use o OCID dos valores de cluster, namespace e conta de serviço das etapas anteriores.#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'}Para obter mais detalhes sobre como criar políticas, consulte Usando a Console para Criar Política.
- Configure o arquivo de configuração kubeconfig do cluster.
- Criar um cluster do Kubernetes usando o OKE.
Para migrar do arquivo JSON no bucket do SO do OCI para a tabela NDCS, execute o seguinte na janela do Cloud Shell:
Para verificar sua restauração de dados, faça log-in na console do Oracle NoSQL Database Cloud Service. Na barra de navegação, vá para Bancos de Dados > Banco de Dados NoSQL. Selecione seu compartimento na lista drop-down para exibir a tabela users. Para obter o procedimento para acessar a console, consulte Acessando o Serviço na Console de Infraestrutura.
Migrar do Oracle NoSQL Database para o OCI Object Storage Usando a Autenticação de Token de Sessão
Este exemplo mostra como usar o Oracle NoSQL Database Migrator com autenticação de token de sessão para copiar dados da tabela do Oracle NoSQL Database para um arquivo JSON em um bucket do OCI Object Storage.
Como desenvolvedor, você está explorando uma opção para fazer backup dos dados da tabela do Oracle NoSQL Database no OCI Object Storage (SO da OCI). Você deseja usar a autenticação baseada em token de sessão.
Nesta demonstração, você usará os comandos da CLI (Interface de Linha de Comando) do OCI para criar um token de sessão. Você criará manualmente um arquivo de configuração do Migrator e executará a migração de dados.
- Identifique a origem e o dissipador da migração.
- Origem: tabela
usersno Oracle NoSQL Database. - Dissipador: arquivo JSON no bucket do SO do OCI
Identifique o ponto final, o namespace, o bucket e o prefixo da região para o SO do OCI. Para obter mais detalhes, consulte Acessando o Oracle Cloud Object Storage. Para obter a lista de pontos finais do serviço OCI OS, consulte Pontos Finais do Serviço Object Storage.
- ponto final:
us-ashburn-1 - bucket:
Migrate_oci - prefixo:
userSession - namespace:
idhkv1iewjzjO nome do namespace de um bucket é o mesmo do namespace da tenancy e é gerado automaticamente quando sua tenancy é criada. Você pode obter o nome do namespace da seguinte forma:- Na console do Oracle NoSQL Database Cloud Service, navegue até Storage> Buckets.
- Selecione o Compartimento no Escopo da Lista e selecione o bloco. A página Detalhes do Bucket exibe o nome no parâmetro Namespace.
Se você não fornecer um nome de namespace do OCI OS, o utilitário Migrator usará o namespace padrão da tenancy.
Observação:
Certifique-se de ter OS privilégios para gravar objetos no bucket do SO do OCI. Para obter mais detalhes sobre como definir as políticas, consulte Gravar no Serviço Object Storage. - ponto final:
- Origem: tabela
- Gere um token de sessão seguindo estas etapas:
- Instalar e configurar o OCI CLI. Consulte Início Rápido.
- Use um dos comandos da CLI do OCI a seguir para gerar um token de sessão. Para obter mais detalhes sobre as opções disponíveis, consulte Autenticação baseada em Token para a 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 SESSIONPROFILEou
#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 SESSIONPROFILENo comando acima,
region_name: Especifica o ponto final da região do seu SO do OCI. Para obter uma lista de regiões de dados suportadas no Oracle NoSQL Database Cloud Service, consulte Regiões de Dados e URLs de Serviço Associados.profile_name: Especifica o perfil, que o comando da CLI do OCI usa para gerar um token de sessão.O comando da CLI do OCI cria uma entrada no arquivo de configuração do OCI no caminho$HOME/.oci/config, conforme mostrado na seguinte amostra:[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/tokenO
security_token_fileaponta para o caminho do token de sessão que você gerou usando o comando da CLI do OCI acima.Observação:
- Se o perfil já existir no arquivo de configuração do OCI, o comando da CLI do OCI substituirá o perfil pela configuração relacionada ao token de sessão ao gerar o token de sessão.
- Especifique o seguinte no modelo de configuração do sumidouro:
- O caminho para o arquivo de configuração do OCI no parâmetro credentials.
- O perfil usado ao gerar o token de sessão no parâmetro credentialsProfile.
"credentials" : "$HOME/.oci/config" "credentialsProfile" : "SESSIONPROFILE"O utilitário Migrator extrai automaticamente os detalhes do token de sessão gerado usando os parâmetros acima. Se você não especificar o parâmetro credentials, o utilitário Migrator procurará o arquivo de credenciais no caminho
$HOME/.oci. Se você não especificar o parâmetro credentialsProfile, o utilitário Migrator usará o nome de perfil padrão (DEFAULT) do arquivo de configuração do OCI. - O token de sessão é válido por 60 minutos. Para estender a duração da sessão, você pode atualizar a sessão. Para obter detalhes, consulte Atualizando um Token.
Para migrar da tabela do Oracle NoSQL Database para um arquivo JSON no bucket do SO do OCI:
Para verificar seu backup de dados, faça log-in na console do Oracle NoSQL Database Cloud Service. Navegue pelos menus, Storage > Object Storage & Archive Storage > Buckets. Acesse os arquivos do diretório userSession no bucket Migrate_oci. Para obter o procedimento para acessar a console, consulte Acessando o Serviço na Console de Infraestrutura
Migrar do arquivo CSV para o Oracle NoSQL Database
Este exemplo mostra o uso do Oracle NoSQL Database Migrator para copiar dados de um arquivo CSV para o Oracle NoSQL Database.
Exemplo
Depois de avaliar várias opções, uma organização finaliza o Oracle NoSQL Database como sua plataforma de Banco de Dados NoSQL. Como seu conteúdo de origem está no formato de arquivo CSV, eles estão procurando uma maneira de migrá-los para o Oracle NoSQL Database.
Neste exemplo, você aprenderá a migrar os dados de um arquivo CSV chamado course.csv, que contém informações sobre vários cursos oferecidos por uma universidade. Você gera o arquivo de configuração a partir do utilitário runMigrator.
Você também pode preparar o arquivo de configuração com os detalhes de origem e sumidouro identificados. Consulte a Oracle NoSQL Database Migrator Reference.
- Identifique a origem e o dissipador da migração.
- Origem: arquivo CSV
Neste exemplo, o arquivo de origem é
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" - Pia: Oracle NoSQL Database
- Origem: arquivo CSV
- O arquivo CSV deve estar de acordo com o formato
RFC4180. - Crie um arquivo contendo os comandos DDL para o esquema da tabela de destino,
course. A definição da tabela deve corresponder ao arquivo de dados CSV relativo ao número de colunas e seus tipos.Neste exemplo, o arquivo 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 para o Oracle NoSQL Database Service, execute as seguintes etapas:
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