Éléments à prendre en compte lors de l’accès aux données fédérées avec Amazon Redshift - Amazon Redshift
Versions prises en charge des bases de données fédérées

Amazon Redshift ne prendra plus en charge la création de nouvelles fonctions Python définies par l’utilisateur à compter du 1er novembre 2025. Si vous souhaitez utiliser des fonctions Python définies par l’utilisateur, créez-les avant cette date. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement. Pour plus d’informations, consultez le billet de blog .

Éléments à prendre en compte lors de l’accès aux données fédérées avec Amazon Redshift

Certaines fonctions Amazon Redshift ne prennent pas en charge l’accès aux données fédérées. Vous trouverez ci-dessous les limitations et considérations connexes.

Voici des limites et considérations à prendre en compte lors de l’utilisation de requêtes fédérées avec Amazon Redshift :

  • Les requêtes fédérées prennent en charge l’accès en lecture aux sources de données externes. Vous ne pouvez pas écrire ou créer des objets de base de données dans la source de données externe.

  • Dans certains cas, vous pouvez accéder à une base de données Amazon RDS ou cluster Aurora DB dans une région AWS autre que celle d’Amazon Redshift. Ces cas entraînent généralement une latence réseau et des frais pour le transfert de données entre des régions AWS. Nous vous recommandons d’utiliser une base de données globale Aurora avec un point de terminaison local dans la même région AWS que votre cluster Amazon Redshift. Les bases de données globales Aurora utilisent une infrastructure dédiée pour la réplication basée sur le stockage entre deux régions AWS quelles qu’elles soient, avec une latence typique de moins d’une seconde.

  • Considérez le coût de l’accès à Amazon RDS ou cluster Aurora DB. Par exemple, lorsque vous utilisez cette fonction pour accéder au cluster Aurora DB, les frais de cluster Aurora DB sont basés sur les IOPS.

  • Les requêtes fédérées n’autorisent pas l’accès à Amazon Redshift à partir de RDS ou cluster Aurora DB.

  • Les requêtes fédérées ne sont disponibles que dans les régions AWS où Amazon Redshift et Amazon RDS ou cluster Aurora DB sont disponibles.

  • Pour l’instant, les requêtes fédérées ne prennent pas en charge ALTER SCHEMA. Pour modifier un schéma, utilisez DROP et puis CREATE EXTERNAL SCHEMA.

  • Les requêtes fédérées ne fonctionnent pas avec la mise à l’échelle simultanée.

  • Pour l’instant, les requêtes fédérées ne prennent actuellement pas en charge l’accès via un wrapper de données distantes PostgreSQL (PostgreSQL Foreign Data Wrapper).

  • Les requêtes fédérées vers RDS MySQL ou Aurora MySQL prennent en charge l’isolement des transactions au niveau READ COMMITED.

  • S’il n’est pas spécifié, Amazon Redshift se connecte à RDS for MySQL ou à Aurora MySQL sur le port 3306. Vérifiez le numéro de port MySQL avant de créer un schéma externe pour MySQL.

  • S’il n’est pas spécifié, Amazon Redshift se connecte à RDS PostgreSQL ou à Aurora PostgreSQL sur le port 5432. Vérifiez le numéro de port PostgreSQL avant de créer un schéma externe pour PostgreSQL.

  • Lors de la récupération de types de données TIMESTAMP et DATE à partir de MySQL, les valeurs zéro sont traitées comme NULL.

  • Si un point de terminaison de lecteur de base de données de cluster Aurora DB est utilisé, une erreur « instantané non valide » peut survenir. Cette situation peut être évitée par l’une des méthodes suivantes :

    • Utilisez un point de terminaison d’instance de cluster Aurora DB spécifique (au lieu d’utiliser le point de terminaison du cluster Aurora DB). Cette méthode utilise l’isolation des transactions REPEATABLE READ pour les résultats de la base de données PostgreSQL.

    • Utilisez un point de terminaison du lecteur de cluster Aurora DB et définissez pg_federation_repeatable_read sur false pour la session. Cette méthode utilise l’isolation des transactions READ COMMITTED pour les résultats de la base de données PostgreSQL. Pour plus d’informations sur les points de terminaison du lecteur d’Amazon, consultez Types de points de terminaison de cluster Aurora DB dans le Guide de l’utilisateur d’Amazon Aurora. Pour de plus amples informations sur pg_federation_repeatable_read, consultez pg_federation_repeatable_read.

Les considérations suivantes concernent les transactions lors de l’utilisation de requêtes fédérées vers des bases de données PostgreSQL :

  • Si une requête est constituée de tables fédérées, le nœud de ligne démarre une transaction READ ONLY REPEATABLE READ sur la base de données distante. Cette transaction reste pour la durée de la transaction Amazon Redshift.

  • Le nœud leader crée un instantané de la base de données distante en appelant pg_export_snapshot et établit un verrou en lecture sur les tables affectées.

  • Un nœud de calcul démarre une transaction et utilise l’instantané créé au niveau du nœud de référence pour émettre des requêtes vers la base de données distante.

Versions prises en charge des bases de données fédérées

Un schéma externe Amazon Redshift référence une base de données dans un RDS PostgreSQL ou Aurora PostgreSQL externe. Dans ce cas, les limites suivantes s’appliquent :

  • Lors de la création d’un schéma externe référençant le cluster Aurora DB, la base de données Aurora PostgreSQL doit être à la version 9.6 ou ultérieure.

  • Lors de la création d’un schéma externe référençant Amazon RDS, la base de données Amazon RDS PostgreSQL doit être à la version 9.6 ou ultérieure.

Un schéma externe Amazon Redshift peut référencer une base de données dans un RDS MySQL ou Aurora MySQL. Dans ce cas, les limites suivantes s’appliquent :

  • Lors de la création d’un schéma externe référençant le cluster Aurora DB, la base de données Aurora MySQL doit être à la version 5.6 ou ultérieure.

  • Lors de la création d’un schéma externe référençant Amazon RDS, la base de données RDS MySQL doit être à la version 5.6 ou ultérieure.