Limitações do conector PostgreSQL

Esta página lista as limitações e considerações para a ingestão do PostgreSQL usando o Databricks Lakeflow Connect.

Limitações gerais do conector do banco de dados

As limitações nesta seção se aplicam a todos os conectores de banco de dados no Lakeflow Connect. Continue lendo para ver as limitações específicas do conector.

• Quando você executa um pipeline agendado, os alertas não são acionados imediatamente. Em vez disso, eles são acionados quando a próxima atualização é executada.
• Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do Lakeflow Spark Declarative Pipelines.
• O catálogo de preparo não pode ser um catálogo estrangeiro.
• Durante os períodos de manutenção de origem, o Databricks pode não conseguir acessar seus dados.
• Se um nome de tabela de origem entrar em conflito com um nome de tabela de destino existente, a atualização do pipeline falhará.
• O suporte a pipeline para múltiplos destinos é somente através da API.
• Opcionalmente, você pode renomear uma tabela ingerida. Se você renomear uma tabela em seu pipeline, ela se tornará um pipeline somente de API e você não poderá mais editar o pipeline na interface do usuário.
• Se você selecionar uma coluna depois que um pipeline já tiver iniciado, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir dados históricos, execute manualmente uma atualização completa na tabela.
• O Databricks não pode ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas venham de esquemas de origem diferentes.
• O sistema de origem assume que as colunas do cursor estão aumentando monotonicamente.

• Pipelines de ingestão geridas não são suportadas para espaços de trabalho FedRAMP High ou FedRAMP Moderate.

• O conector ingere dados brutos sem transformações. Use os pipelines declarativos de Lakeflow Spark a jusante para transformações.

• O conector só suporta replicação a partir das instâncias primárias do PostgreSQL.

Authentication

• O conector suporta apenas autenticação de nome de usuário e senha.

Variações do banco de dados

• O conector suporta PostgreSQL 13 ou superior.
• O conector suporta AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure Database para PostgreSQL, máquinas virtuais Azure e GCP Cloud SQL para PostgreSQL. O conector também suporta PostgreSQL local usando Azure ExpressRoute, AWS Direct Connect e redes VPN.

Tubulações

• Cada pipeline de entrada deve estar associado a exatamente um gateway de entrada. Os gateways não podem ser partilhados entre pipelines.
• Embora o pipeline de ingestão seja executado em computação sem servidor, o gateway de ingestão deve ser executado em computação clássica.
• O gateway de ingestão tem de funcionar em modo contínuo para evitar o aumento excessivo do Write-Ahead Log (WAL) e o acúmulo de ranhuras de replicação.

Replication

• A replicação lógica requer PostgreSQL 13 ou superior com o wal_level parâmetro definido como logical.

• Cada tabela que replicar deve ter a sua identidade de réplica definida como FULL ou DEFAULT. O Databricks recomenda usar FULL identidade réplica para tabelas sem chaves primárias ou com colunas TOASTable.
• Os slots de replicação não são removidos automaticamente quando se apagam pipelines. Tens de limpar manualmente os espaços de replicação para evitar o acúmulo de WAL. Consulte Limpeza dos slots de replicação.

Evolução do esquema

O conector trata automaticamente colunas novas e eliminadas.

• Quando uma nova coluna aparece na fonte, o Databricks ingere-a automaticamente na próxima execução do pipeline.
• Quando uma coluna é eliminada da fonte, o Databricks não a apaga automaticamente. Em vez disso, o conector usa uma propriedade de tabela para definir a coluna excluída como inactive no destino. Se aparecer mais tarde outra coluna com um nome conflitante com a inactive coluna, o pipeline falhará. Neste caso, execute uma atualização completa da tabela ou retire manualmente a coluna inativa.

O conector pode gerir os DDLs mencionados abaixo (por exemplo, renomeações de colunas), mas requer uma atualização completa das tabelas de destino.

As DDLs requerem uma atualização completa

• Alterar o tipo de dados de uma coluna
• Renomear uma coluna
• Alterar a chave primária de uma tabela
• Converter uma tabela de não logada para logada ou vice-versa
• Adição ou remoção de partições (para tabelas particionadas)

Staging

O catálogo de preparação não pode ser um catálogo estrangeiro.

Tables

• A Databricks recomenda a ingestão de no máximo 250 tabelas por pipeline. No entanto, não há limite para o número de linhas ou colunas suportadas nestas tabelas.
• Os Databricks não podem ingerir duas tabelas cujos nomes diferem apenas no caso (por exemplo, mytable e MyTable) usando um único pipeline. Para suportar estes casos, crie dois pares de pipeline de gateway e ingestão que publiquem em esquemas alvo diferentes.
• Os source_catalog, source_schema e source_table devem ser diferenciados por maiúsculas e minúsculas para o nome da base de dados, mas não distinguem maiúsculas de minúsculas para os nomes de esquemas e tabelas (seguindo o comportamento padrão do PostgreSQL). Por exemplo, se a base de dados de origem for nomeada MyDatabase, deve especificá-la como MyDatabase no ingestion_definition.
• Embora possa ingerir de várias bases de dados ou esquemas de origem num pipeline, não pode ingerir duas tabelas com o mesmo nome. Por exemplo, não pode ingerir tanto schema1.orders como schema2.orders no mesmo pipeline.
• Pode incluir múltiplas especificações de tabelas ou esquemas no objects campo do ingestion_definition. No entanto, os nomes das tabelas fonte em diferentes esquemas fonte não podem sobrepor-se. Nomes sobrepostos resultam na falha do pipeline de ingestão.

Tipos de dados

• Tipos definidos pelo utilizador e tipos de extensão de terceiros são lidos como cadeias de caracteres.
• Os TIME tipos de dados e TIMETZ são ingeridos como cadeias de caracteres.
• Para os tipos de dados NUMERIC e DECIMAL:
  • Se a precisão for 38 ou menos, NaN é mapeada para null.
  • Se a precisão for superior a 38, o valor é armazenado como uma cadeia e NaN é preservado como uma cadeia.
  • Inf e -Inf são suportados apenas para tipos numéricos ilimitados. Para precisão superior a 38, o valor é armazenado como uma cadeia e o valor do infinito é preservado.
• Para o tipo de DATE dados: É suportado o intervalo completo de datas do PostgreSQL. Inf e -Inf são convertidas em null. As datas a.C. são armazenadas usando numeração astronómica dos anos. Por exemplo, 1 a.C. mapeia para o ano 0 e 2 a.C. mapeia para -1.
• Para TIMESTAMP (sem fuso horário) tipo de dado: Os valores são ingeridos como strings. Inf e -Inf são preservados como cadeias de caracteres.
• Para o TIMESTAMP WITH TIME ZONE tipo de dado: O intervalo suportado pelo PostgreSQL é 4713-01-01 00:00:00.000000 BC até 294276-12-31 23:59:59.999999 AD, enquanto o intervalo suportado pelos Databricks é -290308-12-21 BCE 19:59:06 GMT até +294247-01-10 CE 04:00:54 GMT. Carimbos de tempo acima do carimbo máximo suportado do Databrick são convertidos para null. As datas a.C. são armazenadas usando numeração astronómica dos anos. Por exemplo, 1 a.C. mapeia para o ano 0 e 2 a.C. mapeia para -1. Inf e -Inf são convertidas em null.
• Para INTERVAL o tipo de dados: Valores infinitos são mapeados para 0 years 0 mins 0 days 0 hours 0 mins 0.0 secs.
• MONEY os valores são ingeridos como cadeias.
• Qualquer tipo de dado incorporado do PostgreSQL que não esteja listado na tabela de transformações automáticas de dados é ingerido como string.

Tabelas particionadas

• São suportadas tabelas particionadas PostgreSQL.
• Cada partição é tratada como uma tabela separada para fins de replicação.
• Adicionar ou remover partições requer uma atualização completa da tabela.

Limitações para variações específicas do PostgreSQL

Amazon RDS e Aurora

• O rds.logical_replication parâmetro deve ser definido como 1.

Base de Dados do Azure para PostgreSQL

• A replicação lógica deve estar ativada nos parâmetros do servidor.
• Para implementações de Servidor Único, a replicação lógica só está disponível nos níveis de Propósito Geral e Otimizado para Memória.
• Para implementações de Servidores Flexíveis, a replicação lógica é suportada em todos os níveis.
• O max_slot_wal_keep_size parâmetro é apenas de leitura, fixo em -1 (infinito) e não pode ser configurado.

Google Cloud SQL para PostgreSQL

• A cloudsql.logical_decoding bandeira tem de estar ativada.
• O Cloud SQL não permite configuração max_slot_wal_keep_size; é fixo em -1 (infinito) por defeito.