Como migrar de um sistema Oracle OLTP para o Cloud Spanner

Neste artigo, explicamos como migrar seu banco de dados de sistemas de processamento de transações on-line (OLTP, na sigla em inglês) Oracle® para o Cloud Spanner.

Alguns conceitos do Cloud Spanner são diferentes de outras ferramentas de gerenciamento de bancos de dados corporativos, por isso poderá ser necessário ajustar seu aplicativo para aproveitar ao máximo os recursos do Cloud Spanner. Poderá ser necessário também complementar o Cloud Spanner com outros serviços do Google Cloud Platform (GCP) para atender às suas necessidades.

Restrições de migração

Ao migrar seu aplicativo para o Cloud Spanner, considere os diferentes recursos disponíveis. Provavelmente será necessário reformular a arquitetura do aplicativo para se adequar ao conjunto de recursos do Cloud Spanner e fazer a integração com outros serviços do GCP.

Procedimentos e acionadores armazenados

O Cloud Spanner não é compatível com a execução de código do usuário no nível do banco de dados. Portanto, como parte da migração, é necessário mover para o aplicativo qualquer lógica de negócios implementada por procedimentos e acionadores armazenados no nível do banco de dados.

Sequências

Não há gerador de sequência implementado no Cloud Spanner. Conforme explicado abaixo, usar números monotônicos crescentes como chaves primárias é um antipadrão no Cloud Spanner. Uma alternativa para gerar chaves primárias exclusivas é usar um UUID aleatório.

Se for necessário usar sequências por motivos externos, você precisará implementá-las na camada do aplicativo.

Controles de acesso

O Cloud Spanner é compatível apenas com controles de acesso no nível do banco de dados usando as permissões de acesso e os papéis do Cloud IAM. Os papéis predefinidos podem oferecer acesso de leitura e gravação ou somente leitura ao banco de dados.

Se precisar de permissões mais granulares, você precisará implementá-las na camada do aplicativo. Em situações normais, apenas o aplicativo deve ter permissão para ler e gravar no banco de dados.

Se for necessário expor o banco de dados aos usuários para a geração de relatórios e você quiser usar permissões de segurança granulares (como permissões no nível da tabela e da exibição), exporte o banco de dados para o BigQuery.

Restrições de validação de dados

O Cloud Spanner é compatível com um conjunto limitado de restrições de validação de dados na camada do banco de dados.

Se você precisar de restrições de dados mais complexas, implemente-as na camada do aplicativo.

A tabela a seguir apresenta os tipos de restrições encontradas com frequência em bancos de dados Oracle e mostra como implementá-las com o Cloud Spanner.

Restrição Implementação com o Cloud Spanner
Não nulo Restrição de coluna NOT NULL.
Único Índice secundário com restrição UNIQUE.
Chave estrangeira (para tabelas normais) Implementado na camada do aplicativo.
Chave estrangeira em ações ON DELETE/ON UPDATE Possível apenas em tabelas intercaladas. Em outros casos, deve ser implementado na camada do aplicativo.
Verificações de valor e validação via restrições ou acionadores CHECK Implementado na camada do aplicativo.

Tipos de dados compatíveis

Oracle e Cloud Spanner são compatíveis com diferentes conjuntos de tipos de dados. A tabela a seguir apresenta os tipos de dados do Oracle e os equivalentes no Cloud Spanner. Consulte definições detalhadas de cada tipo de dados do Cloud Spanner em Tipos de dados.

Conforme descrito na coluna "Observações", poderá ser necessário realizar também outras transformações para ajustar os dados do Oracle para o banco de dados do Cloud Spanner.

Por exemplo, é possível armazenar um BLOB grande como objeto em um intervalo do Cloud Storage, em vez de armazená-lo no banco de dados, e armazenar a referência do URI do objeto do Cloud Storage no banco de dados como STRING.

Tipo de dados Oracle Equivalente do Cloud Spanner Observações
Tipos de caracteres (CHAR, VARCHAR, NCHAR, NVARCHAR) STRING Observação: o Cloud Spanner usa apenas strings Unicode.
O Oracle aceita até 32.000 bytes ou caracteres (dependendo do tipo), enquanto o Cloud Spanner aceita até 2.621.440 caracteres.
BLOB, LONG RAW, BFILE BYTES ou STRING contendo o URI do objeto. Objetos pequenos (menos de 10 MiB) podem ser armazenados como BYTES.
Considere o uso de ofertas alternativas do GCP, como o Cloud Storage, para armazenar objetos maiores.
CLOB, NCLOB, LONG STRING (contendo dados ou o URI do objeto externo) Objetos pequenos (menos de 2.621.440 caracteres) podem ser armazenados como STRING. Considere o uso de ofertas alternativas do GCP, como o Cloud Storage, para armazenar objetos maiores.
NUMBER, NUMERIC, DECIMAL STRING, FLOAT64, INT64 O tipo de dados NUMBER do Oracle aceita até 38 dígitos de precisão, enquanto o tipo de dados FLOAT64 do Cloud Spanner aceita até 16 dígitos de precisão. Consulte mecanismos alternativos em Como armazenar dados numéricos de precisão arbitrária.
INT, INTEGER, SMALLINT INT64
BINARY_FLOAT, BINARY_DOUBLE FLOAT64
DATE DATE A representação STRING padrão do tipo de dados DATE do Cloud Spanner é yyyy-mm-dd. Isso é diferente em bancos de dados Oracle, portanto, tenha cuidado ao converter automaticamente de/para representações de datas em STRING. Oferecemos funções SQL para converter datas em strings formatadas.
DATETIME TIMESTAMP O Cloud Spanner armazena horários independentemente do fuso horário. Para armazenar um fuso horário é necessários usar uma coluna STRING separada. Oferecemos funções SQL para converter registros de data e hora em strings formatadas que usam fusos horários.
XML STRING (contendo dados ou o URI do objeto externo) Objetos XML pequenos (menos de 2.621.440 caracteres) podem ser armazenados como STRING. Considere o uso de ofertas alternativas do GCP, como o Cloud Storage, para armazenar objetos maiores.
URI, DBURI, XDBURI, HTTPURI STRING
ROWID PRIMARY KEY O Cloud Spanner usa a chave primária da tabela para classificar e referenciar as linhas internamente. Portanto, no Cloud Spanner esse chave é efetivamente igual ao tipo de dados ROWID.
SDO_GEOMETRY, SDO_TOPO_GEOMETRY_SDO_GEORASTER   O Cloud Spanner não aceita tipos de dados geoespaciais. É necessário armazenar esses dados usando tipos de dados padrão e implementar alguma lógica de pesquisa e filtragem na camada do aplicativo.
ORDAudio, ORDDicom, ORDDoc, ORDImage, ORDVideo, ORDImageSignature O Cloud Spanner não aceita tipos de dados de mídia. Considere usar o Cloud Storage para armazenar dados de mídia.

Processo de migração

Este é um exemplo do cronograma geral do processo de migração:

  • Conversão do esquema e do modelo de dados
  • Conversão de consultas SQL
  • Migração do aplicativo para usar o Cloud Spanner e o Oracle
  • Exportação em massa dos dados do Oracle e importação no Cloud Spanner usando o Cloud Dataflow
  • Manutenção da consistência entre os dois bancos de dados durante a migração
  • Migração do aplicativo do Oracle

Como converter o esquema e o modelo de dados

Você pode converter o esquema existente em um esquema do Cloud Spanner para armazenar seus dados. Isso deve fazer a melhor correspondência possível com o esquema Oracle existente, simplificando as modificações no aplicativo. No entanto, devido às diferenças nos recursos, algumas alterações serão necessárias.

Usar as práticas recomendadas do design de esquemas ajudará você a aumentar a capacidade e reduzir os gargalos no banco de dados do Cloud Spanner.

Chaves primárias

Toda tabela que precisa armazenar mais de uma linha precisa de uma chave primária composta por uma ou mais colunas da tabela. A chave primária de uma tabela identifica exclusivamente cada linha. Além disso, como as linhas da tabela são classificadas pela chave primária, a tabela em si funciona como um índice primário.

Evite designar como primeira parte da chave primária colunas com incremento monotônico (por exemplo, sequências ou carimbos de data/hora). Isso pode levar a gargalos causados por inserções ocorridas no final do keyspace. Gargalos são a concentração de operações em um único nó, o que reduz a capacidade de gravação total para a capacidade do nó, já que não será possível se beneficiar do balanceamento de carga de todas as gravações entre os nós do Cloud Spanner.

Use as técnicas a seguir para gerar valores únicos de chave primária e reduzir o risco de gargalos:

Depois de designar a chave primária da tabela, não será possível alterá-la sem excluir e recriar a tabela. Para mais informações sobre como designar sua chave primária, consulte Esquema e modelo de dados: chaves primárias.

Veja um exemplo de instrução DDL que cria uma tabela para um banco de dados de músicas:

CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
  BirthDate  DATE,
) PRIMARY KEY(SingerId);

Como intercalar tabelas

Um recurso do Cloud Spanner permite definir um relacionamento pai-filho um para muitos entre duas tabelas. Isso intercala as linhas de dados filhas com a linha mãe no armazenamento, efetivamente realizando a mesclagem prévia da tabela e melhorando a eficiência da recuperação de dados quando mãe e filhas são consultadas juntas.

A chave primária da tabela filha precisa começar com as colunas da chave primária da tabela mãe. Da perspectiva da linha filha, a chave primária da linha mãe é chamada de chave estrangeira. Você pode definir até seis níveis de relacionamentos pai-filho.

Você pode definir ações acionadas na exclusão para tabelas filhas, determinando o que acontece quando a linha mãe é excluída: todas as linhas filhas são excluídas ou a exclusão da linha mãe é bloqueada enquanto existem linhas filhas.

Veja um exemplo da criação de uma tabela de álbuns intercalada com a tabela mãe de intérpretes definida anteriormente:

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId)
INTERLEAVE IN PARENT (Singers)
ON DELETE CASCADE;

Como criar índices secundários

Você também pode criar índices secundários para indexar dados da tabela fora da chave primária.

O Cloud Spanner implementa índices secundários da mesma forma que as tabelas, então os valores das colunas que serão usados como chaves de índice têm as mesmas restrições das chaves primárias das tabelas. Isso também significa que os índices têm as mesmas garantias de consistência das tabelas do Cloud Spanner.

Pesquisas de valor por índices secundários são, na prática, iguais a consultas com uma mesclagem de tabela. Para melhorar o desempenho das consultas que usam índices armazenando cópias dos valores de coluna da tabela original no índice secundário, use a cláusula STORING, o que as transforma em índice abrangente.

O otimizador de consultas do Cloud Spanner usará automaticamente os índices secundários somente quando o próprio índice armazenar todas as colunas consultadas (uma consulta coberta). Para forçar o uso de um índice ao consultar colunas na tabela original, é necessário usar uma diretiva FORCE INDEX na instrução SQL. Por exemplo:

SELECT *
FROM MyTable@{FORCE_INDEX=MyTableIndex}
WHERE IndexedColumn=@value

É possível usar índices para aplicar valores exclusivos em uma coluna da tabela, basta definir um índice UNIQUE nessa coluna. O índice impedirá a inclusão de valores duplicados.

Veja um exemplo de instrução DDL que cria um índice secundário para a tabela de álbuns:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Se você criar mais índices depois de carregar os dados, o preenchimento do índice poderá levar algum tempo. Evite adicionar mais de três por dia. Consulte mais orientações sobre como criar índices secundários em Índices secundários. Para mais informações sobre as limitações na criação de índice, consulte Atualizações de esquema.

Traduzir qualquer consulta SQL

O Cloud Spanner usa o dialeto ANSI 2011 do SQL com extensões e tem muitas funções e operadores para ajudar a converter e agregar seus dados. Você precisa converter consultas SQL que usam sintaxe, funções e tipos específicos do Oracle para que sejam compatíveis com o Cloud Spanner.

Embora o Cloud Spanner não aceite dados estruturados como definições de coluna, os dados estruturados podem ser usados em consultas SQL por meio dos tipos ARRAY e STRUCT.

Por exemplo, é possível escrever uma consulta para retornar todos os álbuns de um artista usando um ARRAY de STRUCTs em uma única consulta (aproveitando os dados pré-combinados). Para mais informações, consulte a seção Observações sobre subconsultas da documentação.

É possível perfilar consultas SQL usando a interface de consultas do Cloud Spanner no Console do GCP para executá-las. Em geral, as consultas que realizam varreduras completas em tabelas grandes exigem muitos recursos e devem ser usadas com moderação.

Consulte a documentação Práticas recomendadas do SQL para mais informações sobre como otimizar consultas SQL.

Migrar seu aplicativo para usar o Cloud Spanner

O Cloud Spanner oferece um conjunto de bibliotecas de cliente para várias linguagens e a capacidade de ler e gravar dados usando chamadas de API específicas do Cloud Spanner, consultas SQL e instruções da linguagem de manipulação de dados (DML, na sigla em inglês). Algumas consultas podem ser mais rápidas por chamadas de API, como leituras diretas de linha por chave, porque não é necessário converter a instrução SQL.

Você também pode usar o Driver Java de conectividade ao banco de dados (JDBC, na sigla em inglês) para se conectar ao Cloud Spanner, aproveitando ferramentas e infraestruturas atuais que não têm integração nativa.

Como parte do processo de migração, os recursos não disponíveis no Cloud Spanner precisam ser implementados no aplicativo. Por exemplo, seria necessário implementar no aplicativo um acionador para verificar valores de dados e atualizar uma tabela relacionada por meio de uma transação de leitura/gravação para ler a linha atual, verificar a restrição e gravar as linhas atualizadas em ambas as tabelas.

O Cloud Spanner oferece transações de leitura e gravação e somente leitura, o que garante a consistência externa de seus dados. Além disso, as transações de leitura podem ter limites de data e hora, assim você lê uma versão consistente dos dados especificados das seguintes formas:

  • Em um momento exato no passado (até uma hora atrás).
  • No futuro (a leitura será bloqueada até que chegue a hora).
  • Com uma quantidade aceitável de inatividade definida, o que retornará uma visualização consistente até algum tempo no passado sem a necessidade de verificar se dados posteriores estão disponíveis em outra réplica. Isso pode aumentar o desempenho, mas pode retornar dados obsoletos.

Como transferir os dados do Oracle para o Cloud Spanner

Para transferir dados do Oracle para o Cloud Spanner, será necessário exportar o banco de dados Oracle para um formato de arquivo portátil, como CSV, e importar esses dados no Cloud Spanner usando o Cloud Dataflow.

O processo de extração, transformação e carregamento no Cloud Dataflow

Exportação em massa do Oracle

O Oracle não oferece utilitários integrados para exportar ou descarregar todo o banco de dados em um formato de arquivo portátil.

Algumas opções para exportar estão nas perguntas frequentes sobre o Oracle.

São elas:

Cada uma delas tem a desvantagem de exportar apenas uma tabela por vez, o que significa que será necessário pausar seu aplicativo ou desativar o banco de dados para que ele permaneça em um estado consistente para exportação.

Outras opções incluem as ferramentas de terceiros apresentadas na página de perguntas frequentes sobre o Oracle, sendo que algumas podem descarregar uma visualização consistente de todo o banco de dados.

Depois de descarregar, você deve fazer o upload dos arquivos de dados para um intervalo do Cloud Storage para que possam ser acessados e importados.

Importação em massa para o Cloud Spanner

Como os esquemas do banco de dados provavelmente são diferentes entre o Oracle e o Cloud Spanner, o processo de importação pode exigir algumas conversões de dados.

A maneira mais fácil de realizá-las e importar os dados para o Cloud Spanner é por meio do Cloud Dataflow.

O Cloud Dataflow é o serviço distribuído do GCP para extração, transformação e carregamento (ETL, na sigla em inglês). Ele oferece uma plataforma para executar canais de dados criados com o SDK do Apache Beam, além de ler e processar grandes quantidades de dados em paralelo em várias máquinas.

O SDK do Apache Beam exige a criação de um programa Java simples para definir a leitura, a transformação e a gravação dos dados. Existem conectores do Beam para Cloud Storage e Cloud Spanner, portanto, o único código que precisa ser escrito é a própria transformação dos dados.

Veja um exemplo de canal simples que lê arquivos CSV e grava no Cloud Spanner no repositório de exemplos de código que acompanha este artigo.

Se as tabelas mães-filhas intercaladas forem usadas no esquema do Cloud Spanner, você deverá tomar cuidado durante o processo de importação para que a linha mãe seja criada antes da linha filha. O código do canal de importação do Cloud Spanner lida com essa situação ao importar primeiro todos os dados para as tabelas de nível superior, depois todas as tabelas filhas de primeiro nível, todas as tabelas filhas de segundo nível e assim por diante.

O canal de importação do Cloud Spanner pode ser usado diretamente para importar seus dados em massa, mas isso exige que os dados estejam em arquivos Avro com o esquema correto.

Como manter a consistência entre os dois bancos de dados

Muitos aplicativos têm requisitos de disponibilidade que impossibilitam que fiquem off-line pelo tempo necessário para exportar e importar os dados. Enquanto você está transferindo os dados para o Cloud Spanner, seu aplicativo continua modificando o banco de dados existente. É necessário duplicar as atualizações no banco de dados do Cloud Spanner enquanto o aplicativo estiver em execução.

Existem vários métodos para manter os dois bancos de dados em sincronia, incluindo o Change Data Capture e a implementação de atualizações simultâneas no aplicativo.

Change Data Capture

O Oracle GoldenGate pode fornecer um fluxo de Change Data Capture para o banco de dados. Você pode escrever um aplicativo inscrito nesse fluxo e aplica as mesmas modificações (após a conversão dos dados) ao banco de dados do Cloud Spanner.

Atualizações simultâneas no aplicativo em ambos os bancos de dados

Um método alternativo seria o de modificar o aplicativo para executar gravações em ambos os bancos de dados. Um banco de dados (inicialmente Oracle) seria considerado a fonte da verdade e, após cada gravação do banco de dados, a linha inteira seria lida, convertida e gravada no banco de dados do Cloud Spanner.

Dessa forma, o aplicativo substitui constantemente as linhas do Cloud Spanner pelos dados mais recentes.

Depois de ter certeza de que todos os dados foram transferidos corretamente, você pode mudar a fonte da verdade para o banco de dados do Cloud Spanner.

Com esse mecanismo, você tem um caminho de reversão caso tenha problemas ao mudar para o Cloud Spanner.

Como verificar a consistência dos dados

À medida que os dados chegam ao banco de dados do Cloud Spanner, é possível executar periodicamente uma comparação entre os dados do Cloud Spanner e do Oracle para garantir que sejam consistentes.

Você pode validar a consistência consultando as duas fontes de dados e comparando os resultados.

Você pode usar o Cloud Dataflow para realizar uma comparação detalhada em grandes conjuntos de dados com a transformação Join. Essa transformação usa dois conjuntos de dados com chaves e corresponde os valores pelas chaves. Você pode comparar os valores correspondentes por igualdade.

Execute essa verificação regularmente até que o nível de consistência corresponda aos requisitos do seu negócio.

Mudança para o Cloud Spanner como fonte da verdade do aplicativo

Quando você tiver confiança na migração dos dados, poderá mudar o aplicativo para usar o Cloud Spanner como fonte da verdade. Continue gravando alterações no banco de dados Oracle para mantê-lo atualizado, assim você tem um caminho de reversão em caso de problemas.

Por fim, você poderá desabilitar e remover o código de atualização do banco de dados Oracle e desativar esse banco.

Como exportar e importar bancos de dados do Cloud Spanner

Você também tem a opção de exportar suas tabelas do Cloud Spanner para um intervalo do Cloud Storage usando um modelo do Cloud Dataflow para realizar a exportação. A pasta resultante incluirá um conjunto de arquivos Avro e arquivos de manifesto JSON contendo as tabelas exportadas. Esses arquivos podem ter várias funções, como:

  • fazer backup do banco de dados para conformidade com a política de retenção de dados ou recuperação de desastres;
  • importar o arquivo Avro em outras ofertas do GCP, como o BigQuery.

Veja mais informações sobre o processo de exportação e importação em Como exportar bancos de dados e Como importar bancos de dados.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…