Limitações do conector do 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 de 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 saber sobre as limitações específicas do conector.

• Quando você executa um pipeline agendado, os alertas não são disparados imediatamente. Em vez disso, eles são disparados quando a próxima atualização é executada.
• Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você precisa excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do Lakeflow Spark Declarative Pipelines.
• Durante os períodos de manutenção, o Databricks pode não conseguir acessar seus dados.
• Se o nome da tabela de origem entrar em conflito com um nome de tabela de destino existente, o fluxo falhará.
• O suporte a pipeline de vários destinos é somente para API.
• Opcionalmente, você pode renomear uma tabela que ingerir. 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 sido iniciado, o conector não fará o backfill de dados automaticamente para a 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 pressupõe que as colunas de cursor estão aumentando monotonicamente.

• Não há suporte para pipelines de ingestão gerenciada para espaços de trabalho nas regiões do Azure GovCloud.

• Com o SCD tipo 1 habilitado, as exclusões não produzem um evento explícito delete no feed de dados de alteração. Para exclusões auditáveis, use o SCD tipo 2 se o conector der suporte a ele. Para obter detalhes, consulte Exemplo: processamento SCD tipo 1 e SCD tipo 2 com dados de origem CDF.
• O conector ingere dados brutos sem transformações. Use os pipelines de transformação downstream do Lakeflow Spark Declarative Pipelines.

• O conector dá suporte apenas à replicação de instâncias postgreSQL primárias.

Authentication

• O conector só dá suporte à autenticação de nome de usuário e senha.

Variações de banco de dados

• O conector dá suporte ao PostgreSQL 13 ou superior.
• O conector dá suporte ao AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Banco de Dados do Azure para PostgreSQL, máquinas virtuais do Azure e SQL de Nuvem do GCP para PostgreSQL. O conector também dá suporte ao PostgreSQL local usando o Azure ExpressRoute, o AWS Direct Connect e a rede VPN.

Pipelines

• Cada pipeline de ingestão deve ser associado a exatamente um gateway de ingestão.
• Embora o pipeline de ingestão seja executado na computação sem servidor, o gateway de ingestão deve ser executado na computação clássica.
• O gateway de ingestão deve ser executado no modo contínuo para evitar o inchaço do Log de Pré-gravação (WAL) e o acúmulo de slots 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 você replicar deve ter sua identidade de réplica definida como FULL ou DEFAULT. O Databricks recomenda o uso da FULL identidade de réplica para tabelas sem chaves primárias ou com colunas TOASTable.
• Os slots de replicação não são removidos automaticamente quando você exclui pipelines. Você deve limpar manualmente os slots de replicação para evitar o acúmulo de WAL. Veja Limpeza dos slots de replicação.

Evolução do esquema

O conector manipula automaticamente colunas novas e excluídas.

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

O conector pode lidar com as DDLs mencionadas abaixo (por exemplo, renomeações de coluna), mas requer uma atualização completa das tabelas de destino.

DDL está exigindo atualização completa

• Alterando o tipo de dados de uma coluna
• Renomeando uma coluna
• Alterando a chave primária de uma tabela
• Convertendo uma tabela de não registrada em log ou vice-versa
• Adicionando ou removendo partições (para tabelas particionadas)

De preparo

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

Tables

• O Databricks recomenda a ingestão de 250 tabelas ou menos por pipeline. No entanto, não há limite no número de linhas ou colunas com suporte nessas tabelas.
• O Databricks não pode carregar duas tabelas cujos nomes diferem apenas no caso (por exemplo, mytable e MyTable) usando um único pipeline. Para dar suporte a esses casos, crie dois pares de pipeline de ingestão de gateway que publicam em esquemas de destino diferentes.
• Os nomes source_catalog, source_schema e source_table são sensíveis a maiúsculas e minúsculas para o nome do banco de dados, mas são insensíveis a maiúsculas e minúsculas para os nomes de esquema e tabela (seguindo o comportamento padrão do PostgreSQL). Por exemplo, se o banco de dados de origem for nomeado MyDatabase, você deve especificá-lo como MyDatabase no ingestion_definition.
• Embora você possa carregar dados de vários bancos de dados de origem ou esquemas em um pipeline, não é possível carregar duas tabelas de mesmo nome. Por exemplo, você não pode ingerir ambos schema1.orders e schema2.orders no mesmo pipeline.
• Você pode incluir várias especificações de tabela ou esquema no objects campo do ingestion_definition. No entanto, os nomes da tabela de origem em esquemas de origem diferentes não podem se sobrepor. Nomes sobrepostos resultam em falha no pipeline de ingestão.

Tipos de dados

• Tipos definidos pelo usuário e tipos de extensão de terceiros são ingeridos como cadeias de caracteres.
• Os tipos de dados TIME e TIMETZ são ingeridos como cadeias de caracteres.
• Qualquer tipo de dados interno do PostgreSQL não listado na tabela Transformações automáticas de dados é ingerido como cadeia de caracteres.
• Para tipo de dados numérico: NaN é convertido em nulo.
• Para datas e timestamp: não damos suporte a datas a.C. ou datas após 9999 d.C.
• Não há suporte para o infinito em data, timestamp ou intervalo.

Tabelas particionadas

• Há suporte para tabelas particionadas do 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.

Banco de Dados do Azure para PostgreSQL

• A replicação lógica deve ser habilitada nos parâmetros do servidor.
• Para implantações de Servidor Único, a replicação lógica só está disponível nas camadas Uso Geral e Otimizado para Memória.
• Para implantações de Servidor Flexível, há suporte para replicação lógica em todas as camadas.
• O max_wal_slot_keep_size parameter é somente leitura, fixado no valor -1 (infinito) e não pode ser configurado.

SQL do Google Cloud para PostgreSQL

• O cloudsql.logical_decoding sinalizador deve estar habilitado.
• O SQL de Nuvem não permite configurar max_wal_slot_keep_size; ele é corrigido em -1 (infinito) por padrão.