É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 Amazon RDS ou Aurora DB 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 sur les IOPS.

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

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

• 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 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 transactions REPEATABLE READ pour les résultats de la base de données PostgreSQL.

  • 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 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 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.

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 un cluster de base de données Aurora, la base de données Aurora PostgreSQL doit être de 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 un cluster de base de données Aurora, la base de données Aurora MySQL doit être de 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.