Considérations relatives au moment d’utiliser les intégrations zéro ETL avec Amazon Redshift

Votre entrepôt des données Amazon Redshift cible doit répondre aux conditions préalables suivantes :

Si vous supprimez une source d’intégration autorisée pour un entrepôt des données Amazon Redshift, toutes les intégrations associées passeront à l’état FAILED. Toutes les données précédemment répliquées restent dans votre base de données Amazon Redshift et peuvent être consultées.

La base de données de destination est en lecture seule. Vous ne pouvez pas créer de tables, de vues ni de vues matérialisées dans la base de données de destination. Toutefois, vous pouvez utiliser des vues matérialisées sur d’autres tables dans l’entrepôt des données cible.

Les vues matérialisées sont prises en charge lorsqu’elles sont utilisées dans des requêtes entre bases de données. Pour en savoir plus sur la création de vues matérialisées avec des données répliquées via des intégrations zéro ETL, consultez Interrogation de données répliquées à l'aide de vues matérialisées.

Par défaut, vous ne pouvez interroger que les tables de l'entrepôt de données cible qui sont en Synced état. Pour interroger des tables dans un autre état, définissez le paramètre de base de données QUERY_ALL_STATES surTRUE. Pour plus d'informations sur les paramètresQUERY_ALL_STATES, consultez CREATE DATABASE et ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide. Pour plus d'informations sur l'état de votre base de données, consultez SVV_INTEGRATION_TABLE_STATE dans le manuel Amazon Redshift Database Developer Guide.

Amazon Redshift n’acceptant que les caractères UTF-8, il est possible qu’il ne respecte pas le classement défini dans votre source. Les règles de tri et de comparaison peuvent être différentes, ce qui peut finalement modifier les résultats de la requête.

Les intégrations sans ETL sont limitées à 50 par objectif d'entrepôt de données Amazon Redshift.

Les tables de la source d'intégration doivent avoir une clé primaire. Dans le cas contraire, vos tables ne pourront pas être répliquées vers l'entrepôt de données cible dans Amazon Redshift.

Pour plus d'informations sur la façon d'ajouter une clé primaire à Amazon Aurora PostgreSQL, consultez Gérer les tables sans clés primaires lors de la création d'intégrations Amazon Aurora PostgreSQL Zero-ETL avec Amazon Redshift sur le blog de base de données.AWS Pour plus d'informations sur la façon d'ajouter une clé primaire à Amazon Aurora MySQL ou RDS for MySQL, consultez la section Gérer les tables sans clé primaire lors de la création d'intégrations Amazon Aurora MySQL ou Amazon RDS for MySQL Zero-ETL avec Amazon Redshift sur le blog de base de données.AWS

Vous pouvez utiliser le filtrage des données pour les intégrations Aurora Zero-ETL afin de définir l'étendue de la réplication entre le cluster de base de données Aurora source et l'entrepôt de données Amazon Redshift cible. Plutôt que de répliquer toutes les données vers la cible, vous pouvez définir un ou plusieurs filtres qui incluent ou excluent de manière sélective certaines tables de la réplication. Pour plus d'informations, consultez la section Filtrage des données pour les intégrations Aurora Zero-ETL avec Amazon Redshift dans le guide de l'utilisateur Amazon Aurora.

Pour les intégrations Zero-ETL d'Aurora PostgreSQL avec Amazon Redshift, Amazon Redshift prend en charge un maximum de 100 bases de données issues d'Aurora PostgreSQL. Chaque base de données est répliquée de la source vers la cible de manière indépendante.

L'intégration Zero-ETL ne prend pas en charge les transformations lors de la réplication des données des magasins de données transactionnels vers Amazon Redshift. Les données sont répliquées telles quelles à partir de la base de données source. Vous pouvez toutefois appliquer des transformations aux données répliquées dans Amazon Redshift.

L'intégration Zero-ETL s'exécute dans Amazon Redshift à l'aide de connexions parallèles. Il s'exécute à l'aide des informations d'identification de l'utilisateur qui a créé la base de données à partir de l'intégration. Lorsque la requête est exécutée, la mise à l'échelle de la simultanéité n'intervient pas pour ces connexions lors de la synchronisation (écritures). Les lectures de dimensionnement simultanées (provenant des clients Amazon Redshift) fonctionnent pour les objets synchronisés.

Vous pouvez définir une intégration zéro ETL afin de contrôler la fréquence de réplication des données dans Amazon Redshift. REFRESH_INTERVAL Pour plus d'informations, consultez CREATE DATABASE et ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.

Lorsque vous déposez une table sur une source, la table sur la cible n'est pas supprimée, mais prend son DroppedSource état. Vous pouvez supprimer ou renommer la table depuis la base de données Amazon Redshift.

Lorsque vous tronquez une table sur une source, des suppressions sont effectuées sur la table cible. Par exemple, si tous les enregistrements sont tronqués sur la source, les enregistrements correspondants de la colonne cible _record_is_active sont remplacés par. false

Lorsque vous exécutez le SQL de la table TRUNCATE sur la table cible, les lignes d'historique actives sont marquées comme inactives avec l'horodatage correspondant.

Lorsqu'une ligne d'un tableau est définie comme inactive, elle peut être supprimée après un court délai (environ 10 minutes). Pour supprimer des lignes inactives, connectez-vous à votre base de données Zero-ETL à l'aide de l'éditeur de requêtes v2 ou d'un autre client SQL.

Vous ne pouvez supprimer des lignes inactives d'un tableau que lorsque le mode historique est activé. Par exemple, une commande SQL similaire à la suivante supprime uniquement les lignes inactives.

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56'

Cela équivaut à une commande SQL telle que la suivante.

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56' and _record_is_active = False

Lorsque le mode historique est désactivé pour une table, toutes les données historiques sont enregistrées dans la table nommée avec <schema>.<table-name>_historical_<timestamp> tandis que la table d'origine <schema>.<table-name> est actualisée.

Lorsqu'une table dont le mode historique est activé est exclue de la réplication à l'aide d'un filtre de table, toutes les lignes sont définies comme inactives et leur DroppedSource état est changé. Pour plus d'informations sur les filtres de table, consultez la section Filtrage des données pour les intégrations Aurora Zero-ETL avec Amazon Redshift dans le guide de l'utilisateur Amazon Aurora.

Le mode historique ne peut être basculé que pour true ou false pour les tables en Synced état.

Vous pouvez utiliser le filtrage des données pour les intégrations Zero-ETL Aurora et RDS for MySQL afin de définir l'étendue de la réplication entre le cluster de base de données source et l'entrepôt de données Amazon Redshift cible. Plutôt que de répliquer toutes les données vers la cible, vous pouvez définir un ou plusieurs filtres qui incluent ou excluent de manière sélective certaines tables de la réplication. Pour plus d'informations, consultez la section Filtrage des données pour les intégrations Aurora Zero-ETL avec Amazon Redshift dans le guide de l'utilisateur Amazon Aurora.

Les tables de la source d'intégration doivent avoir une clé primaire. Dans le cas contraire, vos tables ne pourront pas être répliquées vers l'entrepôt de données cible dans Amazon Redshift.

Pour plus d'informations sur la façon d'ajouter une clé primaire à Amazon Aurora PostgreSQL, consultez Gérer les tables sans clés primaires lors de la création d'intégrations Amazon Aurora PostgreSQL Zero-ETL avec Amazon Redshift sur le blog de base de données.AWS Pour plus d'informations sur la façon d'ajouter une clé primaire à Amazon Aurora MySQL ou RDS for MySQL, consultez la section Gérer les tables sans clé primaire lors de la création d'intégrations Amazon Aurora MySQL ou Amazon RDS for MySQL Zero-ETL avec Amazon Redshift sur le blog de base de données.AWS

La longueur maximale d'un type de données Amazon Redshift VARCHAR est de 65 535 octets. Lorsque le contenu de la source ne correspond pas à cette limite, la réplication ne se poursuit pas et la table est mise en état d'échec. Vous pouvez définir le paramètre de base de données TRUNCATECOLUMNS sur TRUE pour tronquer le contenu afin qu'il tienne dans la colonne. Pour plus d'informations sur les paramètresTRUNCATECOLUMNS, consultez CREATE DATABASE et ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.

Pour plus d'informations sur les différences de type de données entre les sources d'intégration zéro ETL et les bases de données Amazon Redshift, consultez la section Différences entre les types de données entre Aurora et Amazon Redshift dans le guide de l'utilisateur Amazon Aurora.

Les noms de table de DynamoDB supérieurs à 127 caractères ne sont pas pris en charge.

Les données issues d'une intégration DynamoDB Zero-ETL correspondent à une colonne de type de données SUPER dans Amazon Redshift.

Les noms de colonne de plus de 127 caractères pour la clé de partition ou la clé de tri ne sont pas pris en charge.

Une intégration zéro ETL provenant de DynamoDB ne peut être mappée qu'à une seule base de données Amazon Redshift.

Pour les clés de partition et de tri, la précision et l'échelle maximales sont de (38,18). Les types de données numériques sur DynamoDB offrent une précision maximale allant jusqu'à 38. Amazon Redshift prend également en charge une précision maximale de 38, mais la précision/échelle décimale par défaut sur Amazon Redshift est (38,10). Cela signifie que les valeurs d'échelle peuvent être tronquées.

Pour que l'intégration zéro-ETL soit réussie, un attribut individuel (composé du nom+de la valeur) d'un élément DynamoDB ne doit pas dépasser 64 Ko.

Lors de l'activation, l'intégration Zero-ETL exporte la table DynamoDB complète pour alimenter la base de données Amazon Redshift. Le temps nécessaire à l'exécution de ce processus initial dépend de la taille de la table DynamoDB. L'intégration Zero-ETL réplique ensuite de manière incrémentielle les mises à jour de DynamoDB vers Amazon Redshift à l'aide d'exportations incrémentielles DynamoDB. Cela signifie que les données DynamoDB répliquées dans Amazon Redshift sont conservées automatiquement. up-to-date

Actuellement, la latence minimale pour l'intégration DynamoDB Zero-ETL est de 15 minutes. Vous pouvez l'augmenter encore en définissant une valeur différente de zéro REFRESH_INTERVAL pour une intégration zéro ETL. Pour plus d'informations, consultez CREATE DATABASE et ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.

Les noms de table et de colonne provenant de sources d'application de plus de 127 caractères ne sont pas pris en charge.

La longueur maximale d'un type de données Amazon Redshift VARCHAR est de 65 535 octets. Lorsque le contenu de la source ne correspond pas à cette limite, la réplication ne se poursuit pas et la table est mise en état d'échec. Vous pouvez définir le paramètre de base de données TRUNCATECOLUMNS sur TRUE pour tronquer le contenu afin qu'il tienne dans la colonne. Pour plus d'informations sur la configuration, TRUNCATECOLUMNS consultez CREATE DATABASE et ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.

Pour plus d'informations sur les différences de type de données entre les sources d'applications d'intégration zéro ETL et les bases de données Amazon Redshift, consultez la section Intégrations zéro ETL dans le guide du développeur.AWS Glue

La latence minimale pour une intégration sans ETL avec les applications est d'une heure. Vous pouvez l'augmenter encore en définissant une valeur différente de zéro REFRESH_INTERVAL pour une intégration zéro ETL. Pour plus d'informations, consultez CREATE DATABASE et ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.