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 autenticação baseada no Oracle Wallet, você precisará de um arquivo jar adicional que faça parte da instalação do EE. Para obter mais informações, consulte Oracle Wallet.
Sem esse arquivo jar, você receberá a seguinte mensagem de erro:
Não foi possível localizar kvstore-ee.jar no diretório lib. Copie kvstore-ee.jar para o diretório lib.
kvstore-ee.jar do pacote do servidor EE para o diretório <MIGRATOR_HOME>/lib. <MIGRATOR_HOME> é o diretório nosql-migrator-M.N.O/ criado pela extração do pacote Oracle NoSQL Database Migrator e M.N.O representa os números release.major.minor do software. 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
Observação:
O suporte para a migração de metadados TTL para linhas de tabela está somente disponível para o Oracle NoSQL Database e o Oracle NoSQL Database Cloud Service.Exportação de metadados TTL
_metadata para cada linha exportada. O NoSQL Database Migrator exporta o tempo de expiração para cada linha como o número de milissegundos desde a época 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 um parâmetro de configuração, includeTTL. A operação de importação trata os seguintes casos de uso ao migrar linhas da tabela contendo metadados TTL. Esses casos de uso são aplicáveis somente quando o parâmetro de configuração includeTTL é especificado.
- Caso de uso 1: Nenhuma informação de metadados TTL está presente na linha da tabela de importação.
Quando você importa um arquivo de origem JSON produzido de uma origem externa ou exportado usando versões anteriores do migrador, a linha de importação não tem informações de TTL. Mas como o parâmetro de configuração includeTTL é igual a
true, o migrador define o TTL=0 para a linha da tabela, o que significa que a linha da tabela de importação nunca expira. - Caso de Uso 2: O valor TTL da linha da tabela de origem expirou em relação ao Horário de Referência quando a linha da tabela é importada.
Quando você exporta uma linha da tabela para um arquivo e tenta importá-la após o tempo de expiração da linha da tabela, a linha da tabela é 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 Horário de Referência quando a linha da tabela é importada.
Quando você exporta uma linha da tabela para um arquivo e tenta importá-la antes do tempo de expiração da linha da tabela, a linha da tabela é importada com um valor TTL. Mas o novo valor de TTL para a linha da tabela pode não ser igual ao valor de TTL exportado devido às restrições de hora e dia inteiros na classe TimeToLive. Por exemplo,
Linha da tabela exportada{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC } }O tempo de referência durante a importação é 1629707962582, que é segunda-feira, 23 de agosto de 2021 8:39:22.582 AM.
Linha da tabela importada{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC } }
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>
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 abrir os arquivos JSON Sink e exibir o esquema e os dados.
-- Exported myTable Data
[~/nosqlMigrator]$cat myTableJSON
{
"id" : 10,
"document" : {
"course" : "Computer Science",
"name" : "Neena",
"studentid" : 105
}
}
{
"id" : 3,
"document" : {
"course" : "Computer Science",
"name" : "John",
"studentid" : 107
}
}
{
"id" : 4,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 6,
"document" : {
"course" : "Bio-Technology",
"name" : "Rekha",
"studentid" : 104
}
}
{
"id" : 7,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 5,
"document" : {
"course" : "Journalism",
"name" : "Rani",
"studentid" : 106
}
}
{
"id" : 8,
"document" : {
"course" : "Computer Science",
"name" : "Tom",
"studentid" : 103
}
}
{
"id" : 9,
"document" : {
"course" : "Computer Science",
"name" : "Peter",
"studentid" : 109
}
}
{
"id" : 1,
"document" : {
"course" : "Journalism",
"name" : "Tracy",
"studentid" : 110
}
}
{
"id" : 2,
"document" : {
"course" : "Bio-Technology",
"name" : "Raja",
"studentid" : 108
}
}-- Exported myTable Schema
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))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 coletor com um esquema de tabela que corresponda aos dados no arquivo JSON formatado em 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 Oracle NoSQL Database.
Caso de Uso:
Depois de avaliar várias opções, uma organização finaliza o Oracle NoSQL Database no banco de dados DynamoDB. A organização deseja migrar suas tabelas e dados de 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"}}}
{"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"}}}
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 - Faça 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 details.See Modelos de Configuração de Origem e Modelos de Configuração de Distribuição .
Você pode escolher uma das duas opções a seguir.
- Opção 1: Importando a tabela DynamoDB como documento JSON usando a configuração de esquema padrão.
Aqui, o
defaultSchemaéTRUEe, portanto, o migrador cria o esquema padrão no coletor. Você precisa especificar o tipo de colunaDDBPartitionKeye NoSQL correspondente. Caso contrário, será gerado um erro.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] "schemaInfo" : { "defaultSchema" : true, "DDBPartitionKey" : "<PrimaryKey:Datatype>", }, }, "abortOnError" : true, "migratorVersion" : "1.0.0" }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,
defaultSchemaéFALSEe você especifica schemaPath como um arquivo que contém sua instrução DDL. Consulte Mapeamento de tipos DynamoDB para tipos Oracle NoSQL 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.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- Opção 1: Importando a tabela DynamoDB como 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/nosql-migrator-1.0.0]$./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
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoredesc <table_name>
SELECT * from <table_name>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 os detalhes de origem e coletor identificados. Consulte Modelos de Configuração de Origem e Modelos de Configuração de Recebimento.
Você pode escolher uma das duas opções a seguir.
- Opção 1: Importando a tabela DynamoDB como documento JSON usando a configuração de esquema padrão.
Aqui, o
defaultSchemaéTRUEe, portanto, o migrador cria o esquema padrão no coletor. Você precisa especificar o tipo de colunaDDBPartitionKeye NoSQL correspondente. Caso contrário, será gerado um erro.{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : true, "readUnits" : 100, "writeUnits" : 60, "DDBPartitionKey" : "<PrimaryKey:Datatype>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }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,
defaultSchemaéFALSEe você especifica schemaPath como um arquivo que contém sua instrução DDL. Consulte Mapeamento de tipos DynamoDB para tipos Oracle NoSQL 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.{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- Opção 1: Importando a tabela DynamoDB como 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/nosql-migrator-1.0.0]$./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 Permitir que os usuários gravem objetos em buckets do 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 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 sumário 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