Esta página descreve as principais considerações e os passos a seguir quando migrar do Spanner para outra base de dados com dialeto PostgreSQL se quiser mover uma aplicação do Spanner ou Google Cloud. Também pode usar as informações nesta página se precisar de compreender ou demonstrar a viabilidade da mudança da sua base de dados, por exemplo, para o planeamento de desastres de saída sob stress.
A interface PostgreSQL do Spanner é a melhor escolha para aplicações que precisam da opção de implementação noutro ambiente compatível com PostgreSQL, quer dentro Google Cloud quer noutro local. Usando uma sintaxe familiar e clientes padrão do ecossistema PostgreSQL, a interface PostgreSQL permite que os programadores e os operadores usem os seus conhecimentos e competências existentes do PostgreSQL.
Usa o mesmo processamento de consultas, coordenação de transações, armazenamento distribuído e infraestrutura de rede que o dialeto GoogleSQL. Se precisar de uma base de dados que suporte a portabilidade, não está a comprometer as vantagens de escalabilidade, consistência ou preço/desempenho do Spanner quando seleciona a interface do PostgreSQL.
Saiba mais sobre as diferenças entre os dialetos PostgreSQL e GoogleSQL no Spanner.
A um nível elevado, os passos são os seguintes:
- Remova extensões específicas do Spanner de consultas e declarações DDL
- Migre o esquema
- Migre os dados
- Migre a aplicação
Considerações específicas do Spanner
A interface PostgreSQL do Spanner suporta consultas PostgreSQL prontas a usar, pelo que a maioria das consultas SQL executadas numa base de dados com dialeto PostgreSQL do Spanner tem o mesmo comportamento que outras bases de dados compatíveis com PostgreSQL. Com esta abordagem, o número de alterações de SQL e de acesso aos dados necessárias para mover uma aplicação de uma plataforma para outra é provavelmente baixo. Isto torna o processo de portabilidade mais rápido, mais fácil e menos propenso a erros do que uma base de dados com um dialeto GoogleSQL semelhante.
Além da ampla compatibilidade com o PostgreSQL, a interface do PostgreSQL oferece várias extensões específicas do Spanner. Se usar estas extensões nas suas aplicações, tem de as remover ou mapeá-las manualmente para funcionalidades do PostgreSQL. Alguns exemplos notáveis são apresentados nas extensões de sintaxe de consulta e nas extensões de gestão de esquemas (DDL).
Extensões de sintaxe de consulta
A interface PostgreSQL do Spanner oferece várias extensões específicas do Spanner. A maioria usa o prefixo spanner.
para identificação. Na tabela seguinte, apresentamos estas extensões e as ações que pode ter de realizar antes de a mesma aplicação poder ser executada numa base de dados PostgreSQL.
Tipo de extensão | Extensões específicas | Ações a realizar antes da migração |
Funções específicas do Spanner |
|
Encontre funções com o prefixo spanner. e remova estas chamadas.
|
Extensões de tipo |
|
Remova a sintaxe VECTOR LENGTH ou pondere usar pgvector.
|
Sintaxe de consulta | Não é necessária nenhuma ação, uma vez que as sugestões são representadas em comentários.
Para ver detalhes sobre considerações de desempenho, consulte Migração de consultas. |
|
Procedimentos do sistema armazenados | Remova as chamadas para spanner.cancel_query() .
Opcionalmente, pode substituir as chamadas por um equivalente do PostgreSQL. |
|
Operações SET/SHOW | Pode ser ignorado, uma vez que o PostgreSQL não tem parâmetros incorporados que comecem por spanner. , pelo que a definição de variáveis com esse prefixo não tem qualquer impacto no comportamento esperado. |
Extensões de gestão de esquemas (DDL)
O Spanner oferece uma variedade de extensões relacionadas com a gestão de dados, conforme descrito na página linguagem de definição de dados (LDD).
Extensão | Ações a realizar antes da migração |
Tabelas intercaladas
Coloca dados relacionados de muitos para um no armazenamento físico, o que torna as junções entre eles significativamente mais eficientes. |
Remova a cláusula INTERLEAVE IN . |
Datas/horas de confirmação
Permite armazenar atomicamente a data/hora de confirmação de uma transação numa coluna. |
Substitua SPANNER.COMMIT_TIMESTAMP por um tipo de data/hora do PostgreSQL e faça a gestão da definição da data/hora na sua aplicação ou remova essa coluna.
|
Recuperação pontual
Oferece proteção contra eliminação ou escrita acidental. |
Remova todas as declarações DDL que definam
spanner.version_retention_period .
|
Tempo de vida (TTL)
Pede a eliminação automática de registos com base na idade. |
Remova a cláusula TTL INTERVAL . Considere tirar partido de uma
cron ou de uma tarefa agendada para eliminar periodicamente dados desatualizados.
linhas.
|
Opções do otimizador
Define opções para minimizar qualquer potencial regressão do desempenho quando o otimizador de consultas ou as estatísticas mudam. |
Remova as declarações DDL que definem opções do otimizador. |
Streams de alterações
Monitoriza e transmite as alterações de dados de uma base de dados do Spanner (inserções, atualizações e eliminações) quase em tempo real. |
Remova todas as declarações DDL relacionadas com streams de alterações. |
Líder predefinido
Permite-lhe especificar o líder da sua base de dados em configurações de duas e várias regiões. |
Remova todas as declarações DDL que definam spanner.default_leader .
|
Partição geográfica
Permite segmentar e armazenar ainda mais linhas na tabela da base de dados em diferentes configurações de instâncias. |
Remova todas as declarações DDL relacionadas com a geopartição. |
Sequências
O Spanner só suporta a sequência bit_reversed_positive . |
Substitua bit_reversed_positive por uma sequência disponível no
PostgreSQL. Remova todas as declarações DDL que definam spanner.default_sequence_kind . |
Grupos de localidades
Permite-lhe definir a estratégia de grupo de colunas para armazenar colunas separadamente ou usar o armazenamento hierárquico. |
Remova todas as declarações DDL relacionadas com grupos de localidades. |
Pesquisar índices
Permite definir índices para realizar uma pesquisa de texto completo. |
Remova todas as declarações DDL relacionadas com índices de pesquisa. |
Migração de esquemas
Pode exportar um esquema de base de dados de dialeto PostgreSQL na sintaxe do PostgreSQL. Para bases de dados configuradas para usar a interface PostgreSQL, pode fazê-lo com o psql
usando o PGAdapter, o proxy sidecar que lhe permite usar controladores PostgreSQL padrão ou bibliotecas de cliente para se ligar ao Spanner:
psql -v ON_ERROR_STOP=1 \
--host "$PGADAPTER_HOST" \
--port "$PGADAPTER_PORT" \
--dbname "$SPANNER_DATABASE" \
-qAtX \
-c "show database ddl"
Também pode usar o seguinte gcloud
comando para gerar o esquema como um script SQL compatível com o PostgreSQL:
gcloud spanner databases ddl describe databasename
Se a base de dados usar extensões de esquema específicas do Spanner, como as abordadas em Extensões de gestão de esquemas, estas são apresentadas quando executa este comando. Tem de os remover antes de migrar o esquema para o PostgreSQL.
Migração de dados
A interface PostgreSQL do Spanner suporta as extensões COPY TO STDIN
e STDOUT
do PostgreSQL através do PGAdapter. Esta é uma forma de carregar dados para dentro e para fora do Spanner. Leia mais sobre o comando COPY
na documentação da ferramenta de linha de comandos psql para o Spanner.
Este script exporta quantidades mais pequenas de dados (recomendado para menos de 100 GB de dados) da interface PostgreSQL do Spanner para a nova base de dados PostgreSQL:
psql -h pgadapter-host -c "COPY $TABLE TO STDOUT BINARY" | \
psql -h postgresql-host -c "COPY $TABLE FROM STDIN BINARY"
Para tabelas maiores (com 100 GB ou mais de dados), pode iniciar uma exportação do Dataflow para um modelo CSV.
Pode fazer migrações de dados em direto usando o conetor do Debezium Kafka para transmitir atualizações do Spanner para o PostgreSQL. Pode personalizá-lo ainda mais se usar a API Spanner Change Streams para aceder diretamente aos streams de captura de dados de alterações (CDC).
Migração de consultas
A interface do PostgreSQL para o Spanner implementa grande parte da sintaxe de consulta, das funções e dos operadores do PostgreSQL mais comuns.
Se estiver a usar sugestões nas suas consultas, não precisa de reescrever as consultas, porque as sugestões de consultas no Spanner estão definidas em comentários compatíveis com o PostgreSQL:
SELECT s.FirstName, s.LastName,
s.SingerInfo, a.AlbumTitle, a.Charts
FROM Singers AS s
LEFT OUTER JOIN/*@JOIN_METHOD=APPLY_JOIN*/ Albums AS a
ON s.SingerId = a.SingerId;
Estes comentários são processados pelo planeador de consultas do Spanner, mas uma base de dados PostgreSQL ignora-os, pelo que pode incluí-los ou removê-los.
Para alcançar um desempenho ideal no novo ambiente, as consultas e o esquema da base de dados (como os índices) podem ter de ser otimizados para o novo ambiente. Recomendamos que execute verificações de referência para confirmar isto empiricamente.
Migração de aplicações
No que diz respeito à conetividade das suas aplicações, a sua estratégia de migração depende das escolhas iniciais feitas ao configurar a sua aplicação para usar o Spanner, como se usa controladores PostgreSQL, controladores Spanner ou bibliotecas de cliente Spanner. Esta secção descreve as considerações para cada opção.
Controladores do PostgreSQL
O Spanner suporta clientes PostgreSQL comuns através do PGAdapter, um proxy simples que traduz o protocolo de rede do PostgreSQL em APIs de consulta gRPC de baixo nível do Spanner. Se estiver a usar um destes, a alteração para um destino PostgreSQL diferente envolve a atualização da string de ligação para apontar diretamente para a nova base de dados PostgreSQL em vez do proxy PGAdapter. Esta abordagem oferece um bom desempenho e uma forte compatibilidade, pelo que é adequada quando a portabilidade é uma das principais preocupações. A maioria das consultas executadas na interface PostgreSQL do Spanner funciona da mesma forma noutros ambientes PostgreSQL. No entanto, o oposto não é necessariamente verdadeiro. O PostgreSQL suporta sintaxe e funcionalidades que o Spanner não suporta.
Controladores do Spanner
Estes controladores são implementações específicas do Spanner para linguagens comuns e frameworks de aplicações. Por exemplo, o controlador JDBC (Java) do Spanner implementa a mesma API que o controlador JDBC do PostgreSQL implementa, pelo que as aplicações que usam o controlador JDBC do Spanner podem atualizar o respetivo processo de compilação para incluir o controlador PostgreSQL integrado equivalente quando quiserem executar a aplicação com o PostgreSQL. Esta opção é a melhor se já estiver a usar o Spanner ou se estiver à procura de uma solução de alto desempenho que tire partido das funcionalidades do Spanner, como a API Mutations, que não seria exposta através de um controlador PostgreSQL incorporado. Se precisar de compatibilidade total com controladores incorporados e portabilidade de valores, deve considerar usar os controladores incorporados do PostgreSQL com o PGAdapter para garantir algum nível de portabilidade da aplicação.
Para mais informações, consulte o artigo Controladores e ORMs do PostgreSQL.
Bibliotecas cliente do Spanner
O Spanner também oferece várias bibliotecas de cliente idiomáticas que fornecem acesso direto ao Spanner sem implementar nem passar por uma interface padronizada do PostgreSQL. Estes clientes oferecem o máximo acesso às funcionalidades específicas do Spanner, mas não são compatíveis com a API com controladores PostgreSQL. Estas opções oferecem o nível mais elevado de desempenho das funcionalidades, mas são menos portáteis do que as opções mencionadas acima.
O que se segue?
- Saiba como escolher entre o PostgreSQL e o GoogleSQL.
- Siga o início rápido para criar e interagir com uma base de dados PostgreSQL.
- Saiba mais sobre o suporte do idioma PostgreSQL do Spanner.
- Saiba mais sobre o PGAdapter.
- Saiba mais sobre o repositório do GitHub do PGAdapter.
- Reveja os problemas conhecidos na interface do PostgreSQL.