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

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 Interrogazione di dati replicati con viste materializzate.

Per impostazione predefinita, puoi interrogare le tabelle solo nel data warehouse di destinazione che si trova nello stato. Synced Per interrogare le tabelle in un altro stato, imposta il parametro del database QUERY_ALL_STATES suTRUE. Per informazioni sull'impostazioneQUERY_ALL_STATES, consulta CREATE DATABASE e ALTER DATABASE nella Amazon Redshift Database Developer Guide. Per ulteriori informazioni sullo stato del database, consulta SVV_INTEGRATION_TABLE_STATE nella Amazon Redshift Database Developer Guide.

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 target di data warehouse di Amazon Redshift.

Le tabelle nella fonte di integrazione devono avere una chiave primaria. Altrimenti, le tabelle non possono essere replicate nel data warehouse di destinazione in Amazon Redshift.

Per informazioni su come aggiungere una chiave primaria ad Amazon Aurora PostgreSQL, consulta Gestire tabelle senza chiavi primarie durante la creazione di integrazioni Zero-ETL di Amazon Aurora PostgreSQL con Amazon Redshift nel Database Blog.AWS Per informazioni su come aggiungere una chiave primaria ad Amazon Aurora MySQL o RDS for MySQL, consulta Gestire tabelle senza chiavi primarie durante la creazione di integrazioni Amazon Aurora MySQL o Amazon RDS for MySQL Zero-ETL con Amazon Aurora MySQL o Amazon RDS for MySQL Zero-ETL con Amazon Redshift nel Database Blog.AWS

Puoi utilizzare il filtraggio dei dati per le integrazioni Aurora zero-ETL per definire l'ambito della replica dal cluster Aurora DB di origine al data warehouse Amazon Redshift di destinazione. Invece di replicare tutti i dati sulla 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 Aurora zero-ETL con Amazon Redshift nella Guida per l'utente di Amazon Aurora.

Per le integrazioni Aurora PostgreSQL Zero-ETL 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 utilizzando le credenziali dell'utente che ha creato il database dall'integrazione. Quando la query viene eseguita, il ridimensionamento della concorrenza non si attiva per queste connessioni durante la sincronizzazione (scrittura). Le letture di scalabilità simultanea (dai client Amazon Redshift) funzionano per oggetti sincronizzati.

Puoi impostare un'integrazione zero-ETL REFRESH_INTERVAL per controllare la frequenza di replica dei dati in Amazon Redshift. Per ulteriori informazioni, consulta CREATE DATABASE e ALTER DATABASE nella Amazon Redshift Database Developer Guide.

Quando si rilascia una tabella su una fonte, la tabella sulla destinazione non viene eliminata, ma viene modificata in DroppedSource stato. Puoi eliminare o rinominare la tabella dal database Amazon Redshift.

Quando tronchi una tabella su un'origine, le eliminazioni vengono eseguite sulla tabella di destinazione. Ad esempio, se tutti i record vengono troncati nell'origine, i record corrispondenti nella colonna di destinazione vengono modificati in. _record_is_active false

Quando si esegue TRUNCATE table SQL sulla tabella di destinazione, le righe della cronologia attive vengono contrassegnate come inattive con un timestamp corrispondente.

Quando una riga di una tabella è impostata come inattiva, può essere eliminata dopo un breve ritardo (circa 10 minuti). Per eliminare le righe inattive, connettiti al database zero-ETL con l'editor di query v2 o un altro client SQL.

È possibile 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'

È equivalente 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 si disattiva la modalità cronologia per una tabella, tutti i dati storici vengono salvati nella tabella denominata with <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 vengono impostate come inattive e viene modificata lo stato. DroppedSource Per ulteriori informazioni sui filtri delle tabelle, consulta Filtraggio dei dati per le integrazioni Aurora zero-ETL con Amazon Redshift nella Amazon Aurora User Guide.

La modalità cronologia può essere attivata o attivata solo per le tabelle in stato. true false Synced

Puoi utilizzare il filtraggio dei dati per le integrazioni Aurora e RDS for MySQL Zero-ETL per definire l'ambito della replica dal cluster DB di origine al data warehouse Amazon Redshift di destinazione. Invece di replicare tutti i dati sulla 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 Aurora zero-ETL con Amazon Redshift nella Guida per l'utente di Amazon Aurora.

Le tabelle nella fonte di integrazione devono avere una chiave primaria. Altrimenti, le tabelle non possono essere replicate nel data warehouse di destinazione in Amazon Redshift.

Per informazioni su come aggiungere una chiave primaria ad Amazon Aurora PostgreSQL, consulta Gestire tabelle senza chiavi primarie durante la creazione di integrazioni Zero-ETL di Amazon Aurora PostgreSQL con Amazon Redshift nel Database Blog.AWS Per informazioni su come aggiungere una chiave primaria ad Amazon Aurora MySQL o RDS for MySQL, consulta Gestire tabelle senza chiavi primarie durante la creazione di integrazioni Amazon Aurora MySQL o Amazon RDS for MySQL Zero-ETL con Amazon Aurora MySQL o Amazon RDS for MySQL Zero-ETL con Amazon Redshift nel Database Blog.AWS

La lunghezza massima di un tipo di dati Amazon Redshift VARCHAR è di 65.535 byte. Quando il contenuto della fonte non rientra in questo limite, la replica non procede e la tabella viene messa in uno stato di errore. È possibile impostare il parametro del database TRUNCATECOLUMNS su TRUE per troncare il contenuto per adattarlo alla colonna. Per informazioni sull'impostazioneTRUNCATECOLUMNS, consulta CREATE DATABASE e ALTER DATABASE nella Amazon Redshift Database Developer Guide.

Per ulteriori informazioni sulle differenze tra i tipi di dati tra le fonti di integrazione zero-ETL e i database Amazon Redshift, consulta Differenze tra i tipi di dati tra Aurora e Amazon Redshift nella Guida per l'utente di Amazon Aurora.

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

I dati di un'integrazione DynamoDB zero-ETL 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 su 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 su DynamoDB supportano una precisione massima fino a 38. Amazon Redshift supporta anche una precisione massima di 38, ma la precisione/scala decimale predefinita su 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 il completamento di questo processo iniziale dipende dalla dimensione 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 conservati automaticamente. up-to-date

Attualmente, la latenza minima per l'integrazione zero-ETL di DynamoDB è di 15 minuti. È possibile aumentarla ulteriormente impostando un valore diverso da zero per un'integrazione zero-ETL. REFRESH_INTERVAL Per ulteriori informazioni, consulta CREATE DATABASE e ALTER DATABASE nella Amazon Redshift Database Developer Guide.

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

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

Per ulteriori informazioni sulle differenze tra i tipi di dati tra le sorgenti di applicazioni di integrazione Zero-ETL e i database Amazon Redshift, consulta le integrazioni Zero-ETL nella Developer Guide.AWS Glue

La latenza minima per un'integrazione zero-ETL con le applicazioni è di 1 ora. È possibile aumentarla ulteriormente impostando un valore diverso da zero REFRESH_INTERVAL per un'integrazione zero-ETL. Per ulteriori informazioni, consulta CREATE DATABASE e ALTER DATABASE nella Amazon Redshift Database Developer Guide.