Considerazioni sull'utilizzo delle integrazioni Zero-ETL con Amazon Redshift

Il data warehouse Amazon Redshift di destinazione deve soddisfare i seguenti prerequisiti:

Se elimini un'origine di integrazione autorizzata per un data warehouse Amazon Redshift, tutte le integrazioni associate avranno lo stato FAILED. Tutti i dati precedentemente replicati rimangono nel database Amazon Redshift e possono essere sottoposti a query.

Il database di destinazione è di sola lettura. Non puoi creare tabelle, viste o viste materializzate nel database di destinazione. Tuttavia, puoi utilizzare le viste materializzate su altre tabelle nel data warehouse di destinazione.

Le viste materializzate sono supportate se utilizzate nelle query tra database. Per informazioni sulla creazione delle viste materializzate con i dati replicati dalle integrazioni Zero-ETL, consulta Esecuzione di query sui dati replicati con viste materializzate.

Per impostazione predefinita puoi eseguire query solo sulle tabelle con lo stato Synced presenti nel data warehouse di destinazione. Per eseguire query sulle tabelle in un altro stato, imposta il parametro del database QUERY_ALL_STATES su TRUE. Per informazioni sull’impostazione di QUERY_ALL_STATES, consulta CREATE DATABASE e ALTER DATABASE nella Guida per sviluppatori di database di Amazon Redshift. Per ulteriori informazioni sullo stato del database, consulta SVV_INTEGRATION_TABLE_STATE nella Guida per sviluppatori di database di Amazon Redshift.

Amazon Redshift accetta solo caratteri UTF-8, quindi potrebbe non rispettare le regole di confronto definite nell'origine. Le regole di ordinamento e confronto potrebbero essere diverse, il che può in ultima analisi modificare i risultati delle query.

Le integrazioni Zero-ETL sono limitate a 50 per destinazione del data warehouse di Amazon Redshift.

Le tabelle nell’origine di integrazione devono avere una chiave primaria. In alternativa le tabelle non possono essere replicate nel data warehouse di destinazione in Amazon Redshift.

Per informazioni su come aggiungere una chiave primaria in Amazon Aurora PostgreSQL, consulta Handle tables without primary keys while creating Amazon Aurora PostgreSQL zero-ETL integrations with Amazon Redshift in AWS Database Blog. Per informazioni su come aggiungere una chiave primaria in Amazon Aurora MySQL o Amazon RDS per MySQL, consulta Handle tables without primary keys while creating Amazon Aurora MySQL or Amazon RDS for MySQL zero-ETL integrations with Amazon Redshift in AWS Database Blog.

Puoi utilizzare il filtraggio dei dati per le integrazioni Zero-ETL di Aurora per definire l’ambito della replica dal cluster di database Aurora di origine al data warehouse Amazon Redshift di destinazione. Invece di replicare tutti i dati nella destinazione, puoi definire uno o più filtri che includono o escludono selettivamente determinate tabelle dalla replica. Per ulteriori informazioni, consulta Filtraggio dei dati per le integrazioni Zero-ETL di Aurora con Amazon Redshift nella Guida per l’utente di Amazon Aurora.

Per le integrazioni Zero-ETL di Aurora PostgreSQL con Amazon Redshift, Amazon Redshift supporta un massimo di 100 database di Aurora PostgreSQL. Ogni database viene replicato dall’origine alla destinazione in modo indipendente.

L’integrazione Zero-ETL non supporta le trasformazioni durante la replica dei dati dagli archivi di dati transazionali ad Amazon Redshift. I dati vengono replicati così come sono dal database di origine. Tuttavia puoi applicare trasformazioni ai dati replicati in Amazon Redshift.

L’integrazione Zero-ETL viene eseguita in Amazon Redshift utilizzando connessioni parallele. Viene eseguita con le credenziali dell’utente che ha creato il database dall’integrazione. Quando la query viene eseguita, il dimensionamento simultaneo non si attiva per queste connessioni durante la sincronizzazione (scritture). Le letture di dimensionamento simultaneo (dai client Amazon Redshift) funzionano per gli oggetti sincronizzati.

Puoi impostare REFRESH_INTERVAL per un’integrazione Zero-ETL per controllare la frequenza della replica dei dati in Amazon Redshift. Per ulteriori informazioni, consulta CREATE DATABASE e ALTER DATABASE nella Guida per sviluppatori di database di Amazon Redshift.

Dopo avere creato un database Amazon Redshift da un’integrazione Zero-ETL con Amazon DynamoDB, lo stato del database deve cambiare da Creazione in corso ad Attivo. Ciò avvia la replica dei dati dalle tabelle DynamoDB di origine nelle tabelle Redshift di destinazione, che vengono create secondo lo schema pubblico del database di destinazione (ddb_rs_customerprofiles_zetl_db).

Quando rimuovi una tabella per un’origine, la tabella per la destinazione non viene rimossa, ma lo stato diventa DroppedSource. Puoi rimuovere o rinominare la tabella del database Amazon Redshift.

Quando tronchi una tabella per un’origine, le eliminazioni vengono eseguite per la tabella di destinazione. Ad esempio, se tutti i record vengono troncati nell’origine, i record corrispondenti nella colonna di destinazione _record_is_active vengono cambiati in false.

Quando esegui il comando SQL TRUNCATE TABLE per la tabella di destinazione, le righe della cronologia attive vengono contrassegnate come inattive con un timestamp corrispondente.

Quando una riga di una tabella è impostata su Inattiva, può essere eliminata dopo un breve ritardo (circa 10 minuti). Per eliminare le righe inattive, connettiti al database zero-ETL con Query Editor V2 o un altro client SQL.

Puoi eliminare solo le righe inattive da una tabella con la modalità cronologia attiva. Ad esempio, un comando SQL simile al seguente elimina solo le righe inattive.

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

Equivale a un comando SQL come il seguente.

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

Quando disattivi la modalità cronologia per una tabella, tutti i dati storici vengono salvati nella tabella denominata <schema>.<table-name>_historical_<timestamp>, mentre la tabella originale denominata <schema>.<table-name> viene aggiornata.

Quando una tabella con la modalità cronologia attivata viene esclusa dalla replica utilizzando un filtro di tabella, tutte le righe diventano inattive e lo stato viene cambiato in DroppedSource. Per ulteriori informazioni sui filtri della tabella, consulta Filtraggio dei dati per le integrazioni Zero-ETL di Aurora con Amazon Redshift nella Guida per l’utente di Amazon Aurora.

La modalità cronologia può essere impostata su true o false per le tabelle nello stato Synced.

Le viste materializzate per le tabelle con la modalità cronologia attivata vengono create come ricalcolo completo.

Puoi utilizzare il filtraggio dei dati per le integrazioni Zero-ETL di Aurora e RDS per MySQL per definire l’ambito della replica dal cluster di database di origine al data warehouse Amazon Redshift di destinazione. Invece di replicare tutti i dati nella destinazione, puoi definire uno o più filtri che includono o escludono selettivamente determinate tabelle dalla replica. Per ulteriori informazioni, consulta Filtraggio dei dati per le integrazioni Zero-ETL di Aurora con Amazon Redshift nella Guida per l’utente di Amazon Aurora.

Le tabelle nell’origine di integrazione devono avere una chiave primaria. In alternativa le tabelle non possono essere replicate nel data warehouse di destinazione in Amazon Redshift.

Per informazioni su come aggiungere una chiave primaria in Amazon Aurora PostgreSQL, consulta Handle tables without primary keys while creating Amazon Aurora PostgreSQL zero-ETL integrations with Amazon Redshift in AWS Database Blog. Per informazioni su come aggiungere una chiave primaria in Amazon Aurora MySQL o Amazon RDS per MySQL, consulta Handle tables without primary keys while creating Amazon Aurora MySQL or Amazon RDS for MySQL zero-ETL integrations with Amazon Redshift in AWS Database Blog.

La lunghezza massima di un tipo di dati VARCHAR Amazon Redshift è 65.535 byte. Quando il contenuto dell’origine non rientra in questo limite, la replica non procede e la tabella viene messa in uno stato di errore. Puoi possibile impostare il parametro del database TRUNCATECOLUMNS su TRUE per troncare il contenuto per adattarlo alla colonna. Per informazioni sull’impostazione di TRUNCATECOLUMNS, consulta CREATE DATABASE e ALTER DATABASE nella Guida per sviluppatori di database di Amazon Redshift.

Per ulteriori informazioni sulle differenze tra i tipi di dati tra le origini delle integrazioni Zero-ETL e i database Amazon Redshift, consulta Differenze dei tipi di dati tra Aurora e Amazon Redshift nella Guida per l’utente di Amazon Aurora.

I nomi delle tabelle di DynamoDB con più di 127 caratteri non sono supportati.

I dati di un’integrazione Zero-ETL di DynamoDB vengono mappati su una colonna di tipi di dati SUPER in Amazon Redshift.

I nomi di colonna per la chiave di partizione o la chiave di ordinamento con più di 127 caratteri non sono supportati.

Un’integrazione Zero-ETL di DynamoDB può essere mappata a un solo database Amazon Redshift.

Per le chiavi di partizione e ordinamento, la precisione e la scala massime sono (38,18). I tipi di dati numerici in DynamoDB supportano una precisione massima fino a 38. Amazon Redshift supporta anche una precisione massima di 38, ma la precisione/scala decimale predefinita in Amazon Redshift è (38,10). Ciò significa che i valori della scala dei valori possono essere troncati.

Per una corretta integrazione Zero-ETL, un singolo attributo (composto da nome+valore) in un elemento DynamoDB non deve superare i 64 KB.

All’attivazione, l’integrazione Zero-ETL esporta la tabella DynamoDB completa per popolare il database Amazon Redshift. Il tempo necessario per completare questo processo iniziale dipende dalle dimensioni della tabella DynamoDB. L’integrazione Zero-ETL replica quindi in modo incrementale gli aggiornamenti da DynamoDB ad Amazon Redshift utilizzando le esportazioni incrementali di DynamoDB. Ciò significa che i dati DynamoDB replicati in Amazon Redshift vengono aggiornati automaticamente.

Attualmente la latenza minima per l’integrazione Zero-ETL di DynamoDB è 15 minuti. Puoi aumentarla ulteriormente impostando un valore REFRESH_INTERVAL diverso da zero per un’integrazione Zero-ETL. Per ulteriori informazioni, consulta CREATE DATABASE e ALTER DATABASE nella Guida per sviluppatori di database di Amazon Redshift.

I nomi di tabelle e di colonne provenienti da origini con le applicazioni con più di 127 caratteri non sono supportati.

La lunghezza massima di un tipo di dati VARCHAR Amazon Redshift è 65.535 byte. Quando il contenuto dell’origine non rientra in questo limite, la replica non procede e la tabella viene messa in uno stato di errore. Puoi possibile impostare il parametro del database TRUNCATECOLUMNS su TRUE per troncare il contenuto per adattarlo alla colonna. Per informazioni sull’impostazione di TRUNCATECOLUMNS, consulta CREATE DATABASE e ALTER DATABASE nella Guida per sviluppatori di database di Amazon Redshift.

Per ulteriori informazioni sulle differenze tra i tipi di dati tra le origini delle integrazioni Zero-ETL con le applicazioni e i database Amazon Redshift, consulta Integrazioni Zero-ETL nella Guida per gli sviluppatori di AWS Glue.

La latenza minima per un’integrazione Zero-ETL con le applicazioni è un’ora. Puoi aumentarla ulteriormente impostando un valore REFRESH_INTERVAL diverso da zero per un’integrazione Zero-ETL. Per ulteriori informazioni, consulta CREATE DATABASE e ALTER DATABASE nella Guida per sviluppatori di database di Amazon Redshift.