Migrar do PostgreSQL para o Spanner (dialeto PostgreSQL)

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

Para informações sobre a migração para o Spanner e o dialeto GoogleSQL, consulte 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 bancos 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 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 o uso do UUID versão 4 como o método padrão para gerar valores de chave primária. A função GENERATE_UUID() (GoogleSQL, PostgreSQL) retorna valores UUID versão 4 representados como tipo STRING.

Se você precisar gerar valores inteiros, o Spanner oferece suporte a sequências positivas invertidas por bits (GoogleSQL, PostgreSQL), que produzem valores distribuídos uniformemente no espaço de números positivos de 64 bits. É possível usar esses números para evitar problemas de pontos de acesso.

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

Controles de acesso

O Spanner oferece suporte ao controle de acesso refinado no nível da tabela e da coluna. O controle de acesso refinado para visualizações está indisponível. Para mais informações, consulte Sobre o controle de acesso refinado.

Processo de migração

A migração envolve as seguintes tarefas:

  1. Mapear um esquema do PostgreSQL para o Spanner.
  2. Converter consultas SQL.
  3. Criar uma instância, um banco de dados e um esquema do Spanner.
  4. Definir o nível de isolamento da transação e o controle de simultaneidade.
  5. Refatorar o aplicativo para funcionar com o banco de dados Spanner.
  6. Migrar seus dados.
  7. Como verificar o novo sistema e movê-lo para o status de produção

Etapa 1: mapear o esquema do PostgreSQL para o Spanner

A primeira etapa para mover um banco de dados do PostgreSQL de código aberto para o Spanner é 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. A chave primária da tabela 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ído, é importante escolher uma técnica de geração de chave primária que seja bem dimensionada com o crescimento dos dados. Para mais informações, consulte as estratégias de migração de chave primária que recomendamos.

Depois de designar a chave primária, não é possível adicionar ou remover uma coluna de chave primária nem mudar um valor de chave primária 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.

Índices

Os índices de árvore B do PostgreSQL são semelhantes aos índices secundários no Spanner. Em um banco de dados do Spanner, você usa índices secundários para indexar colunas comumente pesquisadas para ter melhor desempenho e substituir qualquer restrição UNIQUE especificada 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
     );

You can use the following statement in your Spanner DDL:

    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 \di meta-comando em psql.

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

O Spanner implementa índices como tabelas. Portanto, a indexação de colunas que crescem constantemente (como aquelas que contêm dados TIMESTAMP) pode criar um ponto de acesso. Para mais informações sobre métodos para evitar pontos de acesso, consulte O que os DBAs precisam saber sobre o Spanner, parte 1: chaves e índices.

O 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 terão as mesmas restrições das chaves primárias das tabelas. Isso também significa que os índices têm as mesmas características 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. 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 INCLUDE cláusula, o que as transforma em índice abrangente.

O otimizador de consultas do Spanner tem mais chances de usar um índice secundário 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 que não estão armazenadas no índice, é necessário usar uma 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. Não é possível usá-las para inserir, atualizar ou 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 ver as diferenças e restrições de sintaxe.

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 ON DELETE 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      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 a Interface PostgreSQL para Spanner não oferece suporte.

Tipo de dado Usar estes comandos
bigserial,serial8 bigint, int8
bit [ (n) ] -
bit varying [ (n) ], varbit [ (n) ] -
box -
character [ (n) ], char [ (n) ] character varying
cidr texto
círculo -
inet texto
integer, int4 bigint, int8
interval [fields] [ (p) ] bigint
json jsonb
linha -
lseg -
macaddr texto
dinheiro 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) ] with time zonetimetz texto, 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 muitas das funções do PostgreSQL de código aberto disponíveis para ajudar a reduzir o trabalho de conversão.

É possível perfilar consultas SQL usando a página do Spanner Studio no console Google Cloud para executá-las. 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 otimização de consultas SQL, consulte a documentação de práticas recomendadas de SQL.

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

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

Use pg_dump para criar instruções DDL que definem os objetos no banco de dados do PostgreSQL e, em seguida, modifique as instruções conforme descrito 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:

Etapa 4: definir o nível de isolamento da transação e o controle de simultaneidade

O nível de isolamento padrão das transações no Spanner é o isolamento serializável, que garante a consistência externa dos dados. O Spanner também oferece isolamento de leitura repetível. Recomendamos que você defina o nível de isolamento como leitura repetível e o controle de simultaneidade como simultaneidade pessimista como parte do processo de migração do aplicativo para que a semântica de transação do Spanner corresponda à semântica de transação padrão do PostgreSQL. Para obter instruções sobre como definir o nível de isolamento e o controle de simultaneidade no aplicativo, consulte Usar o nível de isolamento de leitura repetível e Configurar o controle de simultaneidade.

Etapa 5: refatorar o aplicativo

Adicione lógica de aplicativo para considerar o esquema modificado e as consultas SQL revisadas e para substituir a lógica residente do banco de dados, como procedimentos e acionadores.

Etapa 6: migrar seus dados

Há duas maneiras de migrar seus dados:

  • Usando a ferramenta de migração do Spanner.

    A ferramenta de migração do Spanner oferece suporte à migração de esquema e de dados. É possível importar um arquivo pg_dump ou CSV ou importar dados usando uma conexão direta com o banco de dados PostgreSQL de código aberto.

  • Usando o comando COPY FROM STDIN.

    Para mais detalhes, consulte Comando COPY para importar dados.