À propos de Snowflake Connector for PostgreSQL¶

Note

Le Snowflake Connector for PostgreSQL est soumis aux Conditions du connecteur.

Le Snowflake Connector for PostgreSQL vous permet :

Chargez des données dans Snowflake à partir d’une base de données PostgreSQL.
Configurez la réplication afin que les modifications dans votre base de données PostgreSQL soient répliquées sur Snowflake.

Pour gérer les connexions entre Snowflake et PostgreSQL, le connecteur utilise un agent. L’agent est distribué sous forme d’image Docker. L’agent est exécuté au sein de votre réseau et utilisé pour pousser des données dans votre compte Snowflake.

Note

Snowflake Connector for PostgreSQL nécessite une seule instance de l’application d’agent exécutée à tout moment.

Les mises à jour incrémentielles en cours utilisent la technique de capture des données modifiées (Change Data Capture ou CDC), qui capture les modifications effectuées sur la base de données source. Les modifications incluent les opérations INSERT, UPDATE et DELETE, qui sont automatiquement répliquées sur la base de données de destination dans Snowflake.

Plusieurs instances d’application¶

Vous pouvez installer plusieurs instances de Snowflake Connector for PostgreSQL sur votre compte Snowflake. Pour plus d’informations, voir Facultatif : Installation de plusieurs instances de Snowflake Connector for PostgreSQL.

Liens privés¶

Snowflake Connector pour PostgreSQL prend en charge les liens privés. Pour plus d’informations, voir :

Compatibilités des applications Agent et Connecteur¶

Snowflake Connector for PostgreSQL est publié en fonction d’une version spécifique, décrite comme version x.y.z, où x est la version majeure, y la version mineure et z le correctif. Les Agents sur dockerhub sont également publiés avec la version X.Y.Z. Chaque version x.y.z de Snowflake Connector for PostgreSQL prend en charge tous les agents présentant la même version majeure X=x et non une version mineure supérieure de l’agent. De plus, chaque version x.0.0 de Snowflake Connector for PostgreSQL prend en charge toutes les versions (x-1).Y.Z de l’agent pour toutes les versions Y et Z.

Limitations connues¶

Les sections suivantes décrivent les limitations connues du connecteur.

Les répliques de lecture ne sont pas prises en charge¶

En raison des limitations de PostgreSQL, la réplication logique n’est pas prise en charge sur les répliques ; par conséquent, Snowflake Connector for PostgreSQL doit être connecté uniquement à la base de données principale.

Nombre maximal de tables¶

Le connecteur fonctionne bien avec un maximum de 200 tables sources ajoutées à la réplication. L’ajout de tables supplémentaires peut rendre le connecteur instable.

Disponibilité du connecteur¶

Lors de l’installation du connecteur, notez les limitations suivantes :

Les comptes dans les régions gouvernementales ne sont pas pris en charge.
Pour installer et configurer le connecteur, vous devez être connecté en tant qu’utilisateur ayant le rôle ACCOUNTADMIN. Les autres rôles ne sont pas pris en charge pour le moment.

Compatibilité des types¶

En raison des différences entre la base de données source et les types de colonne Snowflake, certaines valeurs ne peuvent pas être converties ni écrites dans Snowflake à cause de la capacité de colonne ou des plages autorisées maximales. Par exemple :

La longueur maximale du type BINARY Snowflake est de 8 MB (8 388 608 octets)
L’année maximale des types date Snowflake tels que DATE, DATETIME et TIMESTAMP est 9999
La longueur maximale du type VARCHAR Snowflake est de 16 MB (16 777 216 octets)

S’il se produit une telle incompatibilité, la réplication d’une table est arrêtée avec un échec.

Modifications du schéma de la table source¶

Le tableau suivant présente les différents types de modifications apportées au schéma de la table source et indique s’ils sont pris en charge et si oui, de quelle manière.

Les nouveaux noms de colonne sont soumis aux mêmes limitations que celles décrites à la section Limitations des identificateurs.

Type de modification de schéma	Pris en charge ?	Remarques
Ajout d’une nouvelle colonne	Oui	La nouvelle colonne sera visible dans la table de destination comme n’importe quelle autre colonne qui existait au début de la réplication. Il n’est pas possible d’ajouter une nouvelle colonne portant le même nom qu’une colonne précédemment supprimée ou renommée. Par exemple, si les colonnes `A` et `B` existaient à l’origine, mais que la colonne `A` a été supprimée et que la colonne `B` a été renommée `B2`, il n’est pas possible d’ajouter une colonne nommée `A` ou `B`.
Suppression d’une colonne existante	Oui	Si une colonne est supprimée dans la table source, elle ne sera pas supprimée dans la table de destination. Au lieu de cela, on adopte une approche de type suppression logicielle et le nom de la colonne sera remplacé par le `<nom précédent>__SNOWFLAKE_DELETED` afin que les valeurs historiques puissent encore être interrogées. Toutes les lignes répliquées après la suppression de la colonne auront une valeur NULL dans cette colonne. Par exemple, si une colonne `A` est supprimée, son nom sera remplacé par `A__SNOWFLAKE_DELETED` dans la table de destination et le contenu de la colonne restera inchangé.
Renommage d’une colonne	Oui	Le renommage d’une colonne équivaut à supprimer la colonne et à en créer une nouvelle portant le nouveau nom. La suppression suit l’approche de type suppression logicielle expliquée dans la ligne précédente. Par exemple, si la colonne `A` a été renommée `B`, dans la table de destination, la colonne `A` est renommée `A__SNOWFLAKE_DELETED` et une nouvelle colonne `B` est ajoutée. Toutes les lignes existantes avant la modification conservent les valeurs de la colonne dans la colonne `A__SNOWFLAKE_DELETED`, tandis que les valeurs des nouvelles lignes ajoutées après la modification sont placées dans la colonne `B`. Il n’est pas possible de renommer une colonne en lui donnant le même nom que celui d’une colonne précédemment supprimée ou renommée. Par exemple, si les colonnes `A`, `B` et `C` existaient à l’origine, mais que la colonne `A` a été supprimée et que la colonne `B` a été renommée `B2`, il n’est pas possible de remplacer le nom de la colonne `C` par `A` ou `B`.
Modification du type de colonne	Partiellement	La modification du type de colonne de la table source n’est possible que si le type précédent et le nouveau type sont mappés vers le même type dans Snowflake. Dans tous les autres cas, la réplication échouera définitivement.
Modification de la précision d’une colonne numérique	Non	La modification de la précision d’une colonne de la table source entraînera l’échec définitif de la réplication.
Modification de l’échelle d’une colonne numérique	Non	La modification de l’échelle d’une colonne de la table source entraînera l’échec définitif de la réplication.
Modification de la définition de la clé primaire	Non	La modification de la définition de la clé primaire d’une colonne de la table source entraînera l’échec définitif de la réplication.

Colonnes haute capacité¶

Un agent actif lit en permanence tous les événements à l’aide d’un mécanisme de réplication logique, même si certains événements font référence à des tables sources qui n’ont pas été ajoutées pour la réplication. Si la réplication logique contient des événements très volumineux comme des mises à jour de colonnes de type TEXT, l’agent risque de planter en raison du manque de mémoire disponible.

Clés primaires¶

Les tables sans clés primaires ne sont pas prises en charge.

Limitations des identificateurs¶

Actuellement, le connecteur ne prend pas en charge le caractère " dans les noms de schéma, de table ou de colonne répliqués. De plus, les mots clés suivants ne sont pas pris en charge :

Pour les noms de schéma :

INFORMATION_SCHEMA

Pour les noms de colonne :

_SNOWFLAKE_INSERTED_AT
_SNOWFLAKE_UPDATED_AT
_SNOWFLAKE_DELETED
Noms avec le suffixe __SNOWFLAKE_DELETED
Noms de colonne marqués comme Cannot be used as column name dans Mots clés réservés et limités Snowflake

PostgreSQL version >= 11¶

Actuellement, le connecteur dépend de la propriété de configuration wal_level = logical qui a été lancée dans PostgreSQL, version 11.

Paramètre d’identité de réplique¶

L”identité de réplique des tables répliquées doit être définie sur DEFAULT.

Valeurs TOAST¶

La réplication de tables avec des valeurs TOAST n’est actuellement pas prise en charge. Cela comprend l’ajout de colonnes compatibles avec TOAST au schéma source lorsque la réplication est déjà en cours d’exécution.

Autorisation de la base de données source¶

L’autorisation de clé privée sur la base de données source n’est pas prise en charge. Seule l’autorisation via l’utilisateur et le mot de passe est prise en charge.

Identité de réplique¶

L’identité de réplique d’une table donnée doit être identique à la clé primaire, sinon la réplication échouera.