É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

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

É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 de cluster de bases de données Amazon RDS ou Aurora dans une AWS région différente de celle d'Amazon Redshift. Dans ces cas, vous devez généralement payer des frais de latence réseau et de facturation pour le transfert de données entre AWS les régions. Nous vous recommandons d'utiliser une base de données globale Aurora avec un point de terminaison local dans la même AWS région 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.

  • Tenez compte du coût d'accès au cluster de base de données Amazon RDS ou Aurora. Par exemple, lorsque vous utilisez cette fonctionnalité pour accéder au cluster de base de données Aurora, les frais de cluster de base de données Aurora sont basés surIOPS.

  • Les requêtes fédérées ne permettent pas d'accéder à Amazon Redshift RDS depuis un cluster de base de données Aurora.

  • Les requêtes fédérées ne sont disponibles que dans AWS les régions où Amazon Redshift et le cluster de base de données Amazon RDS ou Aurora 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.

  • Les requêtes fédérées ne prennent actuellement pas en charge l'accès via un wrapper de données SQL étranger Postgre.

  • Les requêtes fédérées adressées à RDS My SQL ou Aurora My permettent SQL d'isoler les transactions au READ COMMITTED niveau supérieur.

  • Si ce n'est pas spécifié, Amazon Redshift se connecte à RDS for My ou SQL Aurora My SQL sur le port 3306. Confirmez le numéro de SQL port My avant de créer un schéma externe pour MySQL.

  • Si ce n'est pas spécifié, Amazon Redshift se connecte à RDS Postgre ou SQL Aurora Postgre SQL sur le port 5432. Vérifiez le numéro de SQL port Postgre avant de créer un schéma externe pour SQL Postgre.

  • Lors de la récupération TIMESTAMP et DATE des types de données depuis MySQL, les valeurs nulles sont traitées commeNULL.

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

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

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

Voici quelques considérations relatives aux transactions lorsque vous travaillez avec des requêtes fédérées vers des bases de données Postgre SQL :

  • Si une requête est composée de tables fédérées, le nœud principal lance une READ ONLY REPEATABLE READ transaction 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 peut référencer une base de données dans un Postgre RDS ou SQL Aurora Postgre externe. SQL Dans ce cas, les limites suivantes s’appliquent :

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

  • Lorsque vous créez un schéma externe faisant référence à AmazonRDS, la SQL base de données Amazon RDS Postgre 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 My ou SQL Aurora RDS My externe. SQL Dans ce cas, les limites suivantes s’appliquent :

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

  • Lorsque vous créez un schéma externe faisant référence à AmazonRDS, la version 5.6 ou ultérieure de la SQL base de données RDS Ma base de données doit être installée.