Migre do PostgreSQL para o Spanner (dialeto PostgreSQL)

Esta página explica como migrar uma base de dados PostgreSQL de código aberto (a partir de agora denominada apenas PostgreSQL) para uma base de dados com dialeto PostgreSQL do Spanner (a partir de agora denominada Spanner).

Para obter informações sobre a migração para o Spanner e o dialeto GoogleSQL, consulte o artigo Migrar do PostgreSQL para o Spanner (dialeto GoogleSQL).

Restrições de migração

O Spanner usa determinados conceitos de forma diferente de outras ferramentas de gestão de bases de dados empresariais, pelo que pode ter de ajustar a arquitetura da sua aplicação para tirar total partido das respetivas capacidades. Também pode ter de complementar o Spanner com outros serviços da Google Cloud para satisfazer as suas necessidades.

Procedimentos armazenados e acionadores

O Spanner não suporta a execução de código do utilizador ao nível da base de dados. Como tal, no âmbito da migração, a lógica empresarial implementada por procedimentos e acionadores armazenados ao nível da base de dados tem de ser movida para a aplicação.

Sequências

O Spanner recomenda a utilização da versão 4 do UUID como o método predefinido para gerar valores de chave primária. A função GENERATE_UUID() (GoogleSQL, PostgreSQL) devolve valores da versão 4 do UUID representados como tipo STRING.

Se precisar de gerar valores inteiros, o Spanner suporta sequências positivas invertidas em bits (GoogleSQL, PostgreSQL), que produzem valores distribuídos uniformemente no espaço de números positivos de 64 bits. Pode usar estes números para evitar problemas de uso excessivo de recursos de chaves.

Para mais informações, consulte as estratégias de valor predefinido da chave principal.

Controlos de acesso

O Spanner suporta o controlo de acesso detalhado ao nível da tabela e da coluna. O controlo de acesso detalhado para visualizações não é suportado. Para mais informações, consulte o artigo Acerca do controlo de acesso detalhado.

Processo de migração

A migração envolve as seguintes tarefas:

• Mapear um esquema do PostgreSQL para o Spanner.
• Traduzir consultas SQL.
• Criar uma instância, uma base de dados e um esquema do Spanner.
• Refatorar a aplicação para funcionar com a sua base de dados do Spanner.
• Migrar os seus dados.
• Validar o novo sistema e movê-lo para o estado de produção.

Passo 1: mapeie o esquema do PostgreSQL para o Spanner

O primeiro passo para mover uma base de dados do PostgreSQL de código aberto para o Spanner é determinar que alterações ao esquema tem de fazer.

Chaves principais

No Spanner, todas as tabelas que têm de armazenar mais de uma linha têm de ter uma chave principal composta por uma ou mais colunas da tabela. A chave primária da tabela identifica exclusivamente cada linha numa tabela e o Spanner usa a chave primária para ordenar as linhas da tabela. Uma vez que o Spanner é altamente distribuído, é importante escolher uma técnica de geração de chaves primárias que seja bem dimensionada com o crescimento dos seus dados. Para mais informações, consulte as estratégias de migração de chaves primárias que recomendamos.

Tenha em atenção que, depois de designar a chave principal, não pode adicionar nem remover uma coluna de chave principal, nem alterar um valor de chave principal posteriormente sem eliminar e recriar a tabela. Para mais informações sobre como designar a chave principal, consulte o artigo Esquema e modelo de dados – chaves principais.

Índices

Os índices b-tree do PostgreSQL são semelhantes aos índices secundários no Spanner. Numa base de dados do Spanner, usa índices secundários para indexar colunas pesquisadas com frequência para um melhor desempenho e para substituir quaisquer restrições UNIQUE especificadas nas suas tabelas. Por exemplo, se o DDL do PostgreSQL tiver esta declaração:

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

Pode usar a seguinte declaração no seu LDD 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);

Pode encontrar os índices de qualquer uma das suas tabelas PostgreSQL executando o \di comando meta em psql.

Depois de determinar os índices de que precisa, adicione instruções CREATE INDEX para os criar. Siga as orientações em Índices secundários.

O Spanner implementa índices como tabelas, pelo que a indexação de colunas com aumento monotónico (como as que contêm dados TIMESTAMP) pode causar um ponto crítico. Consulte o artigo O que os DBAs precisam de saber sobre o Spanner, parte 1: chaves e índices para mais informações sobre métodos para evitar pontos ativos.

O Spanner implementa índices secundários da mesma forma que as tabelas. Por isso, os valores das colunas a usar como chaves de índice têm as mesmas restrições que as chaves primárias das tabelas. Isto também significa que os índices têm as mesmas características de consistência que as tabelas do Spanner.

As pesquisas de valores que usam índices secundários são efetivamente iguais a uma consulta com uma junção de tabelas. Pode melhorar o desempenho das consultas que usam índices armazenando cópias dos valores das colunas da tabela original no índice secundário através da cláusula INCLUDE, tornando-o um índice de cobertura.

É mais provável que o otimizador de consultas do Spanner use um índice secundário quando o próprio índice armazena todas as colunas que estão a ser consultadas (uma consulta coberta). Para forçar a utilização de um índice ao consultar colunas que não estão armazenadas no índice, tem de usar uma diretiva FORCE INDEX na declaração SQL, por exemplo:

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

Segue-se um exemplo de uma declaração DDL que cria um índice secundário para a tabela Albums:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Se criar índices adicionais depois de os dados serem carregados, o preenchimento do índice pode demorar algum tempo. Recomendamos que limite a taxa à qual os adiciona 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 índices, consulte as atualizações de esquemas.

Visualizações

As vistas do Spanner são só de leitura. Não podem ser usadas para inserir, atualizar nem eliminar dados. Para mais informações, consulte o artigo Visualizações.

Colunas geradas

O Spanner suporta colunas geradas. Consulte o artigo Crie e faça a gestão de colunas geradas para ver as diferenças de sintaxe e as restrições.

Entrelace de tabelas

O Spanner tem uma funcionalidade em que pode definir duas tabelas como tendo uma relação de 1 para muitos, ou seja, uma relação principal-secundário. Esta funcionalidade intercala as linhas de dados da criança junto à respetiva linha principal no armazenamento, juntando previamente a tabela e melhorando a eficiência da obtenção de dados quando a principal e as crianças são consultadas em conjunto.

A chave primária da tabela secundária tem de começar com as colunas da chave primária da tabela principal. Do ponto de vista da linha secundária, a chave principal da linha principal é denominada chave externa. Pode definir até 6 níveis de relações principal-secundário.

Pode definir ON DELETEações para tabelas secundárias para determinar o que acontece quando a linha principal é eliminada: todas as linhas secundárias são eliminadas ou a eliminação da linha principal é bloqueada enquanto existirem linhas secundárias.

Segue-se um exemplo de criação de uma tabela Albums intercalada na tabela Singers principal 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 o artigo Crie tabelas intercaladas.

Tipos de dados

A tabela seguinte apresenta os tipos de dados PostgreSQL de código aberto que a interface PostgreSQL para o Spanner não suporta.

Nota: a ferramenta de migração do Spanner pode fazer automaticamente algumas das conversões indicadas na coluna Use em alternativa. Para mais informações, consulte o artigo Avaliação e migração da ferramenta de migração do Spanner.

Tipo de dados	Use em alternativa
bigserial,serial8	bigint, int8
bit [ (n) ]	-
bit varying [ (n) ], varbit [ (n) ]	-
caixa	-
character [ (n) ], char [ (n) ]	character varying
cidr	texto
círculo	-
inet	texto
número inteiro, int4	bigint, int8
interval [fields] [ (p) ]	bigint
json	jsonb
linha	-
lseg	-
macaddr	texto
dinheiro	numérico, decimal
caminho	-
pg_lsn	-
ponto	-
polígono	-
realfloat4	dupla precisão, 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) ] with time zonetimetz	texto, usando a notação HH:MM:SS.sss+ZZZZ. Em alternativa, use duas colunas.
timestamp [ (p) ] [ without time zone ]	text ou timestamptz
tsquery	-
tsvector	-
txid_snapshot	-
uuid	text ou bytea
xml	texto

Passo 2: traduza quaisquer consultas SQL

O Spanner tem muitas das funções do PostgreSQL de código aberto disponíveis para ajudar a reduzir o encargo da conversão.

É possível criar perfis de consultas SQL através da página do Spanner Studio na consola para executar a consulta. Google Cloud Em geral, as consultas que efetuam análises completas de tabelas grandes são muito dispendiosas e devem ser usadas com moderação. Para mais informações sobre a otimização de consultas SQL, consulte a documentação de práticas recomendadas de SQL.

Passo 3: crie a instância, a base de dados e o esquema do Spanner

Crie a instância e uma base de dados no dialeto PostgreSQL. Em seguida, crie o seu esquema através da linguagem de definição de dados (LDD) do PostgreSQL.

Use pg_dump para criar declarações de LDD que definam os objetos na sua base de dados PostgreSQL e, em seguida, modifique as declarações conforme descrito nas secções anteriores. Depois de atualizar as declarações de LDD, use-as para criar a sua base de dados na instância do Spanner.

Para mais informações, consulte:

• Crie e faça a gestão de instâncias
• Crie e faça a gestão de bases de dados
• Acerca dos esquemas

Passo 4: refatore a aplicação

Adicione lógica de aplicação para ter em conta o esquema modificado e as consultas SQL revistas, e para substituir a lógica residente na base de dados, como procedimentos e acionadores.

Passo 5: migre os seus dados

Existem duas formas de migrar os seus dados:

• Através da ferramenta de migração do Spanner.

  A ferramenta de migração do Spanner suporta a migração de esquemas e dados. Pode importar um ficheiro pg_dump ou um ficheiro CSV, ou pode importar dados através de uma ligação direta à base de dados PostgreSQL de código aberto.

• Usando o comando COPY FROM STDIN.

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