Migrar do PostgreSQL para o Spanner (dialeto PostgreSQL)

Nesta página, explicamos como migrar um banco de dados PostgreSQL de código aberto (de agora em diante referido apenas como PostgreSQL) para um Banco de dados de dialeto PostgreSQL do Spanner (de agora em diante chamado de Spanner).

Para informações sobre migrar para o Spanner e o dialeto GoogleSQL, consulte Como migrar do PostgreSQL para o Spanner (dialeto GoogleSQL).

Restrições de migração

O Spanner usa determinados conceitos de forma diferente de outras ferramentas corporativas de gerenciamento de banco de dados. Portanto, talvez seja necessário ajustar a arquitetura do aplicativo para aproveitar ao máximo os recursos. Talvez seja necessário complementar o Spanner com outros serviços do Google Cloud para atender às suas necessidades.

Acionadores e procedimentos armazenados

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

Sequências

O Spanner recomenda usar o UUID versão 4 como método padrão para gerar chaves-valor primárias. A função GENERATE_UUID() (GoogleSQL, PostgreSQL) retorna valores de UUID versão 4 representados como tipo STRING.

Se você precisar gerar valores inteiros, o Spanner oferece suporte sequências positivas invertidas em bits (GoogleSQL, PostgreSQL), que produzem distribuídos uniformemente pelo espaço numérico positivo de 64 bits. Você pode use esses números para evitar problemas de ponto de acesso.

Para mais informações, consulte estratégias de valor padrão da chave primária.

Controles de acesso

O Spanner dá suporte a controle de acesso refinado na tabela e na coluna nível O controle de acesso detalhado para visualizações não é compatível. Para mais informações, consulte Sobre controle de acesso detalhado.

Processo de migração

A migração envolve as seguintes tarefas:

• Mapeamento de um esquema do PostgreSQL para o Spanner.
• Traduzir consultas SQL.
• Criar uma instância, um banco de dados e um esquema do Spanner.
• Refatorar o aplicativo para funcionar com o banco de dados do Spanner.
• Como migrar os dados
• Como verificar o novo sistema e movê-lo para o status de produção

Etapa 1: mapear o esquema do PostgreSQL para o Spanner

Sua primeira etapa na migração de um banco de dados do PostgreSQL de código aberto para o Spanner é responsável por determinar quais alterações de esquema você precisa fazer.

Chaves primárias

No Spanner, cada tabela que precisa armazenar mais de uma linha precisa ter uma chave primária que consiste em uma ou mais colunas da tabela. da sua tabela; a chave primária identifica exclusivamente cada linha em uma tabela, e o Spanner usa a chave primária para classificar as linhas da tabela. Como o Spanner é é altamente distribuída, é importante escolher uma técnica que escalona bem de acordo com o crescimento dos dados. Para mais informações, consulte a estratégias de migração das chaves primárias que que recomendamos.

Após designar sua chave primária, você não poderá adicionar ou remover um coluna de chave primária ou altere o valor de uma chave primária posteriormente sem excluir e de recriar a tabela. Para mais informações sobre como designar a chave primária, consulte Esquema e modelo de dados – primário chaves.

Índices

PostgreSQL índices de árvore B são semelhantes aos índices secundários no no Spanner. Em um banco de dados do Spanner, você usa índices secundários para indexar as colunas mais pesquisadas para melhorar o desempenho e substituir qualquer UNIQUE restrições especificadas nas tabelas. Por exemplo, se a DDL do PostgreSQL tiver esta instrução:

 CREATE TABLE customer (
    id CHAR (5) PRIMARY KEY,
    first_name VARCHAR (50),
    last_name VARCHAR (50),
    email VARCHAR (50) UNIQUE
 );

Você usaria esta instrução na DDL do Spanner:

CREATE TABLE customer (
   id VARCHAR(5) PRIMARY KEY,
   first_name VARCHAR(50),
   last_name VARCHAR(50),
   email VARCHAR(50)
   );

CREATE UNIQUE INDEX customer_emails ON customer(email);

Para encontrar os índices de qualquer uma das tabelas do PostgreSQL, execute o comando \di em psql.

Depois de determinar os índices necessários, adicione instruções CREATE INDEX para criá-los. Siga as orientações em Índices secundários.

O Spanner implementa índices como tabelas, para que a indexação seja monotônica colunas crescentes (como as que contêm dados de TIMESTAMP) podem causar um ponto de acesso. Consulte O que os DBAs precisam saber sobre o Spanner, parte 1: chaves e índices para mais informações sobre métodos para evitar pontos de acesso.

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

Pesquisas de valor por índices secundários são, na prática, iguais a consultas com uma mesclagem de tabela. Você pode melhorar o desempenho de consultas usando índices ao armazenar cópias dos valores de coluna da tabela original no índice secundário usando o cláusula INCLUDE, tornando-a uma índice que cobre.

O otimizador de consultas do Spanner usa automaticamente um índice secundário somente quando o próprio índice armazena todas as colunas que estão sendo consultadas (uma consulta coberta). Para forçar o uso de um índice ao consultar colunas no original use uma string Diretiva FORCE INDEX na instrução SQL, por exemplo:

SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;

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 outros índices depois que seus dados forem carregados, o preenchimento do índice poderá levar algum tempo. Recomendamos que você limite a taxa usada para adicionar esses índices a uma média de três por dia. Para mais orientações sobre a criação de índices secundários, consulte Índices secundários. Para mais informações sobre as limitações na criação de índice, consulte Atualizações de esquema.

Visualizações

As visualizações do Spanner são somente leitura. Eles não podem ser usados para inserir, atualizar ou e excluir dados. Para mais informações, consulte Visualizações.

Colunas geradas

O Spanner oferece suporte a colunas geradas. Consulte Criar e gerenciar colunas geradas para sintaxe diferenças e restrições.

Intercalação de tabelas

O Spanner tem um recurso com que é possível definir duas tabelas como tendo um relacionamento pai e filho de um para muitos. Esse recurso intercala as linhas de dados filhas com as linhas pai no armazenamento, fazendo efetivamente a pré-junção da tabela e melhorando a eficiência da recuperação de dados quando pai e filhas são consultadas em conjunto.

É preciso que a chave primária da tabela filha comece com a(s) coluna(s) de chave primária da tabela pai. 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 do ON DELETE para tabelas filhas para determinar o que acontece quando a linha pai é 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      bigint,
 AlbumID       bigint,
 AlbumTitle    varchar,
 PRIMARY KEY (SingerID, AlbumID)
 )
 INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Para mais informações, consulte Criar tabelas intercaladas.

Tipos de dados

A tabela a seguir lista os tipos de dados do PostgreSQL de código aberto que que a Interface PostgreSQL para o Spanner não oferece suporte.

Tipo de dados	Em vez disso, use
bigserial,serial8	bigint, int8
bit [ (n) ]	-
variação de bits [ (n) ], varbit [ (n) ]	-
box	-
caractere [ (n) ], caractere [ (n) ]	variação de caracteres
cidr	texto
circle	-
inet	texto
Número inteiro, int4	bigint, int8
intervalo [campos] [ (p) ]	bigint
json	jsonb
line	-
lseg	-
macaddr	texto
money	numérico, decimal
path	-
pg_lsn	-
point	-
polygon	-
realfloat4	precisão dupla, float8
smallint, int2	bigint, int8
smallserial, serial2	bigint, int8
serial, serial4	bigint, int8
time [ (p) ] [ without time zone ]	texto, usando a notação HH:MM:SS.sss
time [ (p) ] com fuso horário	usando a notação HH:MM:SS.sss+ZZZZ. Ou use duas colunas.
timestamp [ (p) ] [ without time zone ]	texto ou timestamptz
tsquery	-
tsvector	-
txid_snapshot	-
uuid	texto ou bytea
xml	texto

Etapa 2: converter consultas SQL

O Spanner tem muitos dos comandos PostgreSQL de código aberto funções para reduzir a carga de conversão.

É possível criar perfis de consultas SQL usando a página do Spanner Studio na console do Google Cloud para executar a consulta. Em geral, as consultas que executam varreduras de tabela completas em tabelas grandes são muito caras e devem ser usadas com moderação. Para mais informações sobre a otimização de consultas SQL, consulte a Práticas recomendadas de SQL na documentação do Google Cloud.

Etapa 3: criar a instância, o banco de dados e o esquema do Spanner

Criar a instância e um banco de dados no PostgreSQL dialeto. Em seguida, crie seu esquema usando a definição de dados do PostgreSQL do Google (DDL).

Usar pg_dump para criar instruções DDL que definem os objetos em seu banco de dados PostgreSQL e, em seguida, modificar as instruções conforme descrito nas nas seções anteriores. Depois de atualizar as instruções DDL, use-as para criar o banco de dados na instância do Spanner.

Veja mais informações em:

• Criar e gerenciar instâncias
• Criar e gerenciar bancos de dados
• Sobre esquemas

Etapa 4: refatorar o aplicativo

Adicionar lógica do aplicativo para considerar o esquema modificado e o SQL revisado. consultas e substituir a lógica residente do banco de dados, como procedimentos e gatilhos.

Etapa 5: migrar seus dados

Há duas maneiras de migrar seus dados:

• Usando o Harbourbridge.

  O Harbourbridge dá suporte à migração de esquema e dados. É possível importar um arquivo pg_dump ou CSV ou você pode importar através de uma conexão direta com o banco de dados PostgreSQL de código aberto.

• Usando o comando COPY FROM STDIN.

  Para mais detalhes, consulte o comando COPY para importar dados.