Nesta página, explicamos como migrar um banco de dados PostgreSQL de código aberto (de agora em diante chamado apenas de PostgreSQL) para um banco de dados de dialeto PostgreSQL do Spanner (de agora em diante chamado de Spanner).
Para informações sobre como 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 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 é compatível com sequências positivas invertidas em bits (GoogleSQL, PostgreSQL), que produzem valores que distribuem de maneira uniforme no espaço numérico positivo de 64 bits. É possível usar esses números para evitar problemas de uso excessivo do ponto de acesso.
Para mais informações, consulte as estratégias de valor padrão da chave primária.
Controles de acesso
O Spanner é compatível com controle de acesso refinado nos níveis de tabela e coluna. Não há suporte para controle de acesso refinado para visualizações. 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.
- Tradução de 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 seu 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 sua 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 primária de geração de chaves que se adapte bem ao crescimento dos dados. Para mais informações, consulte as estratégias de migração de chave primária recomendadas.
Depois de designar sua chave primária, não é possível adicionar ou remover uma coluna de chave primária ou alterar um valor de chave primária posteriormente 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 para substituir quaisquer restrições UNIQUE 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
);
Use 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 meta-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. Portanto, a indexação de colunas que crescem constantemente (como aquelas que contêm dados TIMESTAMP) pode criar 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, de modo que os valores das colunas, que serão usados como chaves de índice, terão as mesmas restrições que 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. É possível melhorar o desempenho de consultas que usam índices ao armazenar cópias dos valores de coluna da tabela original no índice secundário usando a cláusula INCLUDE, tornando-a um índice de cobertura.
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 na tabela original, é necessário usar uma diretiva FORCE INDEX na instrução SQL. Por exemplo:
SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;
Aqui está um exemplo de instrução DDL em que é criado um índice secundário para a tabela "Á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 é compatível com colunas geradas. Consulte Criar e gerenciar colunas geradas para conhecer 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.
É possível definir ações ON DELETE para tabelas filhas para determinar 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 as linhas filhas existem.
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 não são compatíveis com a Interface PostgreSQL para o Spanner.
| Tipo de dados | Usar em vez disso |
|---|---|
| bigserial,serial8 | Bigint, int8 |
| bit [ (n) ] | - |
| bit variando [ (n) ], varbit [ (n) ] | - |
| box | - |
| caractere [ (n) ], caractere [ (n) ] | variação de caracteres |
| cidr | texto |
| circle | - |
| inet | texto |
| 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 |
| número de série, serial4 | Bigint, int8 |
| time [ (p) ] [ without time zone ] | texto, usando a notação HH:MM:SS.sss |
| time [ (p) ] com fuso horáriotz | usando a notação HH:MM:SS.sss+ZZZZ. Ou use duas colunas. |
| timestamp [ (p) ] [ without time zone ] | text 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 a carga de conversão.
É possível criar perfis de consultas SQL usando a página do Spanner Studio no console do 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 do 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 PostgreSQL e 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.
Confira mais informações:
Etapa 4: refatorar o aplicativo
Adicione lógica de aplicativo para considerar o esquema modificado e consultas SQL revisadas, além de 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 oferece suporte à migração de esquema e dados. Importe um arquivo pg_dump ou CSV ou faça a importação por meio de uma conexão direta com o banco de dados de código aberto PostgreSQL.
Usando o comando
COPY FROM STDIN.Para detalhes, consulte Comando COPY para importar dados.