Limitations du connecteur PostgreSQL

Cette page répertorie les limitations et considérations relatives à l’ingestion PostgreSQL à l’aide de Databricks Lakeflow Connect.

Limitations générales du connecteur de base de données

Les limitations de cette section s’appliquent à tous les connecteurs de base de données dans Lakeflow Connect. Continuez à lire les limitations spécifiques au connecteur.

• Lorsque vous exécutez un pipeline planifié, les alertes ne se déclenchent pas immédiatement. Au lieu de cela, elles se déclenchent lorsque la prochaine mise à jour s’exécute.
• Lorsqu’une table source est supprimée, la table de destination n’est pas automatiquement supprimée. Vous devez supprimer manuellement la table de destination. Ce comportement n’est pas cohérent avec le comportement des pipelines déclaratifs Spark Lakeflow.
• Le catalogue de préparation ne peut pas être un catalogue étranger.
• Pendant les périodes de maintenance source, Databricks peut ne pas être en mesure d’accéder à vos données.
• Si un nom de table source est en conflit avec un nom de table de destination existant, la mise à jour du pipeline échoue.
• Le support du pipeline multi-destination est disponible uniquement via l'API.
• Vous pouvez éventuellement renommer une table que vous ingérez. Si vous renommez une table dans votre pipeline, elle devient un pipeline API uniquement et vous ne pouvez plus modifier le pipeline dans l’interface utilisateur.
• Si vous sélectionnez une colonne après le démarrage d’un pipeline, le connecteur ne reremplit pas automatiquement les données de la nouvelle colonne. Pour ingérer des données historiques, exécutez manuellement une actualisation complète sur la table.
• Databricks ne peut pas ingérer deux tables ou plus portant le même nom dans le même pipeline, même si elles proviennent de schémas sources différents.
• Le système source suppose que les colonnes de curseur augmentent de façon monotonique.

• Les pipelines d’ingestion managés ne sont pas pris en charge pour les espaces de travail FedRAMP High ou FedRAMP Moderate.

• Le connecteur ingère des données brutes sans transformations. Utilisez les pipelines déclaratifs de Lakeflow Spark en aval pour les transformations.

• Le connecteur prend uniquement en charge la réplication à partir d’instances PostgreSQL principales.

Authentication

• Le connecteur prend uniquement en charge l’authentification par nom d’utilisateur et mot de passe.

Variations de base de données

• Le connecteur prend en charge PostgreSQL 13 ou version ultérieure.
• Le connecteur prend en charge AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure Database pour PostgreSQL, les machines virtuelles Azure et GCP Cloud SQL pour PostgreSQL. Le connecteur prend également en charge PostgreSQL local à l’aide d’Azure ExpressRoute, AWS Direct Connect et de la mise en réseau VPN. Pour plus d’informations sur la connectivité entre les clouds, consultez Connectivité réseau.

Pipelines

• Chaque pipeline d’ingestion doit être associé à une seule passerelle d’ingestion. Les passerelles ne peuvent pas être partagées entre les pipelines.
• Bien que le pipeline d’ingestion s’exécute sur une infrastructure sans serveur, la passerelle d’ingestion doit s’exécuter sur une infrastructure traditionnelle.
• La passerelle d’ingestion doit fonctionner en mode continu pour prévenir l'encombrement du Write-Ahead Log (WAL) et l'accumulation des slots de réplication.

Réplication

• La réplication logique nécessite PostgreSQL 13 ou version ultérieure avec le wal_level paramètre défini sur logical.

• Chaque table que vous répliquez doit avoir son identité de réplica définie sur FULL ou DEFAULT. Databricks recommande d’utiliser l'identité de réplica FULL pour les tables sans clés primaires ou avec des colonnes TOASTables.
• Les emplacements de réplication ne sont pas automatiquement supprimés lorsque vous supprimez des pipelines. Vous devez nettoyer manuellement les emplacements de réplication pour empêcher l'accumulation de WAL. Consultez Nettoyer les emplacements de réplication.

Évolution du schéma

Le connecteur gère automatiquement les colonnes nouvelles et supprimées.

• Lorsqu’une nouvelle colonne apparaît dans la source, Databricks l’intègre automatiquement lors de l’exécution suivante du pipeline.
• Lorsqu’une colonne est supprimée de la source, Databricks ne la supprime pas automatiquement. Au lieu de cela, le connecteur utilise une propriété de table pour attribuer à la colonne supprimée la valeur inactive dans la destination. Si une autre colonne apparaît ultérieurement avec un nom en conflit avec la inactive colonne, le pipeline échoue. Dans ce cas, exécutez une actualisation complète de la table ou supprimez manuellement la colonne inactive.

Le connecteur peut gérer les DLL mentionnées ci-dessous (par exemple, les renommages de colonnes), mais nécessite une actualisation complète des tables cibles.

DDL nécessite une actualisation complète

• Modification du type de données d’une colonne
• Renommage d’une colonne
• Modification de la clé primaire d’une table
• Conversion d’une table non journalisée en journalisation ou inversement
• Ajout ou suppression de partitions (pour les tables partitionnées)

Staging

Le catalogue de mise en scène ne peut pas être un catalogue étranger.

Tables

• Databricks recommande d’ingérer 250 tables au maximum par pipeline. Toutefois, il n’existe aucune limite quant au nombre de lignes ou de colonnes prises en charge dans ces tables.
• Databricks ne peut pas ingérer deux tables dont les noms diffèrent uniquement dans le cas (par exemple, mytable et MyTable) à l’aide d’un pipeline. Pour prendre en charge ces cas, créez deux paires de pipelines d’ingestion de gateway qui publient sur différents schémas cibles.
• Les noms source_catalog, source_schema, et source_table sont sensibles à la casse pour le nom de la base de données, mais insensibles à la casse pour les noms de schéma et de table (suivant le comportement par défaut de PostgreSQL). Par exemple, si la base de données source est nommée MyDatabase, vous devez la spécifier comme MyDatabase dans le ingestion_definition.
• Bien que vous puissiez ingérer à partir de plusieurs bases de données ou schémas sources dans un pipeline, vous ne pouvez pas ingérer deux tables du même nom. Par exemple, vous ne pouvez pas ingérer les deux schema1.orders et schema2.orders dans le même pipeline.
• Vous pouvez inclure plusieurs spécifications de table ou de schéma dans le objects champ du ingestion_definition. Toutefois, les noms de tables sources dans différents schémas sources ne peuvent pas se chevaucher. Les noms qui se chevauchent entraînent l’échec du pipeline d’ingestion.

Types de données

• Les types définis par l’utilisateur et les types d’extension tiers sont ingérés en tant que chaînes.
• Les types de données TIME et TIMETZ sont ingérés sous forme de chaînes.
• Pour les types de données NUMERIC et DECIMAL :
  • Si la précision est de 38 ou moins, NaN est mappée à null.
  • Si la précision est supérieure à 38, la valeur est stockée sous forme de chaîne et NaN est conservée sous forme de chaîne.
  • Inf et -Inf sont pris en charge uniquement pour les types numériques non liés. Pour une précision supérieure à 38, la valeur est stockée sous forme de chaîne et la valeur infini est conservée.
• Pour DATE le type de données : la plage de dates PostgreSQL complète est prise en charge. Inf et -Inf sont convertis en null. Les dates BC sont stockées à l’aide d’une numérotation d’année astronomique. Par exemple, 1 av. J.-C. correspond à l'année 0 et 2 av. J.-C. correspond à l'année -1.
• Pour le type de données TIMESTAMP (sans fuseau horaire), les valeurs sont ingérées sous forme de chaînes. Inf et -Inf sont conservés sous forme de chaînes.
• Pour TIMESTAMP WITH TIME ZONE le type de données : la plage PostgreSQL prise en charge est 4713-01-01 00:00:00.000000 BC à 294276-12-31 23:59:59.999999 AD, tandis que la plage prise en charge par Databricks est -290308-12-21 BCE 19:59:06 GMT à +294247-01-10 CE 04:00:54 GMT. Les horodatages dépassant le seuil maximal pris en charge par Databricks sont convertis en null. Les dates BC sont stockées à l’aide d’une numérotation d’année astronomique. Par exemple, 1 av. J.-C. correspond à l'année 0 et 2 av. J.-C. correspond à l'année -1. Inf et -Inf sont convertis en null.
• Pour le type de données INTERVAL, les valeurs Infinity sont mappées à 0 years 0 mins 0 days 0 hours 0 mins 0.0 secs.
• MONEY les valeurs sont ingérées en tant que chaînes.
• Tout type de données intégré PostgreSQL non répertorié dans la table transformations de données automatiques est ingéré en tant que chaîne.

tables partitionnées

• La prise en charge des tables PostgreSQL partitionnées est assurée.
• Chaque partition est traitée comme une table distincte à des fins de réplication.
• L’ajout ou la suppression de partitions nécessite une actualisation complète de la table.

Limitations pour les variantes PostgreSQL spécifiques

Amazon RDS et Aurora

• Le rds.logical_replication paramètre doit être défini sur 1.

Base de données Azure pour PostgreSQL

• La réplication logique doit être activée dans les paramètres du serveur.
• Pour les déploiements à serveur unique, la réplication logique n’est disponible que dans les niveaux Usage général et Mémoire optimisée.
• Pour les déploiements de serveur flexible, la réplication logique est prise en charge sur tous les niveaux.
• Le max_slot_wal_keep_size paramètre est en lecture seule, fixe à -1 (infini) et ne peut pas être configuré.

Google Cloud SQL pour PostgreSQL

• L’indicateur cloudsql.logical_decoding doit être activé.
• Cloud SQL n’autorise pas la configuration max_slot_wal_keep_size; il est résolu à -1 (infini) par défaut.