Replica del database mediante Change Data Capture

Last reviewed 2020-10-20 UTC

Questo documento descrive diversi approcci all'utilizzo di Change Data Capture (CDC) per integrare varie origini dati con BigQuery. Questo documento fornisce un'analisi dei compromessi tra coerenza dei dati, facilità d'uso e costi per ciascuno degli approcci. Ti aiuterà a conoscere le soluzioni esistenti, a scoprire diversi approcci per utilizzare i dati replicati dal CDC e a creare un'analisi costi-benefici degli approcci.

Questo documento ha lo scopo di aiutare data architect, data engineer e business analyst a sviluppare un approccio ottimale per l'accesso ai dati replicati in BigQuery. Presuppone che tu conosca BigQuery, SQL e strumenti a riga di comando.

Panoramica della replica dei dati CDC

Database come MySQL, Oracle e SAP sono le origini dati CDC più discusse. Tuttavia, qualsiasi sistema può essere considerato un'origine dati se acquisisce e apporta modifiche agli elementi di dati identificati da chiavi primarie. Se un sistema non fornisce un processo CDC integrato, ad esempio un log delle transazioni, puoi eseguire il deployment di un lettore batch incrementale per ottenere le modifiche.

Questo documento illustra i processi CDC che soddisfano i seguenti criteri:

1. La replica dei dati acquisisce le modifiche per ogni tabella separatamente.
2. Ogni tabella ha una chiave primaria o una chiave primaria composita.
3. A ogni evento CDC emesso viene assegnato un ID modifica monotonicamente crescente, di solito un valore numerico come un ID transazione o un timestamp.
4. Ogni evento CDC contiene lo stato completo della riga che è stata modificata.

Il seguente diagramma mostra un'architettura generica che utilizza la tecnologia CDC per la replica delle origini dati in BigQuery:

Nel diagramma precedente, per ogni tabella di dati di origine vengono create una tabella principale e una tabella delta in BigQuery. La tabella principale contiene tutte le colonne della tabella di origine, più una colonna per il valore dell'ID dell'ultima modifica. Puoi considerare il valore dell'ID della modifica più recente come l'ID versione dell'entità identificata dalla chiave primaria del record e utilizzarlo per trovare la versione più recente.

La tabella delta contiene tutte le colonne della tabella di origine, oltre a una colonna per il tipo di operazione (aggiornamento, inserimento o eliminazione) e il valore dell'ID modifica.

Di seguito è riportato il processo complessivo per replicare i dati in BigQuery utilizzando CDC:

1. Viene estratto un dump dei dati iniziale di una tabella di origine.
2. I dati estratti vengono facoltativamente trasformati e caricati nella tabella principale corrispondente. Se la tabella non ha una colonna che può essere utilizzata come ID modifica, ad esempio un timestamp dell'ultimo aggiornamento, l'ID modifica è impostato sul valore più basso possibile per il tipo di dati di quella colonna. Ciò consente all'elaborazione successiva di identificare i record principali della tabella che sono stati aggiornati dopo il dump iniziale dei dati.
3. Le righe che cambiano dopo il dump iniziale dei dati vengono acquisite dal processo di acquisizione CDC.
4. Se necessario, il livello di elaborazione CDC esegue un'ulteriore trasformazione dei dati. Ad esempio, il livello di elaborazione CDC potrebbe riformattare il timestamp per l'utilizzo da parte di BigQuery, suddividere le colonne verticalmente o rimuoverle.
5. I dati vengono inseriti nella tabella delta corrispondente in BigQuery utilizzando caricamenti di micro-batch o inserimento di flussi di dati.

Se vengono eseguite ulteriori trasformazioni prima dell'inserimento dei dati in BigQuery, il numero e il tipo di colonne possono differire dalla tabella di origine. Tuttavia, lo stesso insieme di colonne è presente nella tabella principale e in quella delta.

Le tabelle delta contengono tutti gli eventi di modifica per una determinata tabella dal caricamento iniziale. Avere tutti gli eventi di modifica disponibili può essere utile per identificare le tendenze, lo stato delle entità rappresentate da una tabella in un determinato momento o la frequenza di modifica.

Per ottenere lo stato attuale di un'entità rappresentata da una determinata chiave primaria, puoi eseguire una query nella tabella principale e nella tabella delta relativa al record con l'ID modifica più recente. Questa query può essere costosa perché potrebbe essere necessario eseguire un join tra le tabelle principali e delta e completare una scansione completa della tabella di una o entrambe le tabelle per trovare la voce più recente per una determinata chiave primaria. Puoi evitare di eseguire una scansione completa della tabella mediante il clustering o il partizionamento delle tabelle in base alla chiave primaria, ma non è sempre possibile.

Questo documento mette a confronto i seguenti approcci generici che possono aiutarti a ottenere lo stato attuale di un'entità quando non puoi eseguire il partizionamento o il clustering delle tabelle:

• Approccio alla coerenza immediata: le query riflettono lo stato attuale dei dati replicati. La coerenza immediata richiede una query che unisce la tabella principale e la tabella delta e selezioni la riga più recente per ogni chiave primaria.
• Approccio ottimizzato per i costi: vengono eseguite query più veloci e meno costose a scapito di un certo ritardo nella disponibilità dei dati. Puoi unire periodicamente i dati nella tabella principale.
• Approccio ibrido: utilizzi l'approccio della coerenza immediata o quello dell'ottimizzazione dei costi, a seconda dei requisiti e del budget.

Nel documento vengono illustrati ulteriori modi per migliorare le prestazioni oltre a questi approcci.

Prima di iniziare

Questo documento illustra l'utilizzo dello strumento a riga di comando bq e delle istruzioni SQL per visualizzare ed eseguire query sui dati di BigQuery. Esempi di layout di tabella e query vengono mostrati più avanti in questo documento. Se vuoi fare esperimenti con dati di esempio, completa la seguente configurazione:

1. Seleziona un progetto o crea un progetto e abilita la fatturazione per il progetto.
   • Se crei un progetto, BigQuery viene abilitato automaticamente.
   • Se selezioni un progetto esistente, abilita l'API BigQuery.
2. Nella console Google Cloud, apri Cloud Shell.

3. Per aggiornare il file di configurazione di BigQuery, apri il file ~/.bigqueryrc in un editor di testo e aggiungi o aggiorna le seguenti righe in qualsiasi punto del file:

   [query]
   --use_legacy_sql=false
   
   [mk]
   --use_legacy_sql=false
   

4. Clona il repository GitHub che contiene gli script per configurare l'ambiente BigQuery:

   git clone https://github.com/GoogleCloudPlatform/bq-mirroring-cdc.git
   

5. Crea il set di dati, le tabelle principali e delta:

   cd bq-mirroring-cdc/tutorial
   chmod +x *.sh
   ./create-tables.sh
   

Per evitare potenziali addebiti al termine della sperimentazione, arresta il progetto o elimina il set di dati.

Configurare i dati BigQuery

Per dimostrare diverse soluzioni per la replica dei dati CDC in BigQuery, utilizza una coppia di tabelle principali e delta che vengono completate con dati di esempio come le semplici tabelle di esempio riportate di seguito.

Per lavorare con una configurazione più sofisticata rispetto a quella descritta in questo documento, puoi utilizzare la demo dell'integrazione di BigQuery con CDC. La demo automatizza il processo di compilazione delle tabelle e include script per monitorare il processo di replica. Se vuoi eseguire la demo, segui le istruzioni nel file README della directory principale del repository GitHub che hai clonato nella sezione Prima di iniziare di questo documento.

I dati di esempio utilizzano un modello dei dati semplice: una sessione web che contiene un ID sessione generato dal sistema obbligatorio e un nome utente facoltativo. All'avvio della sessione, il nome utente è null. Dopo che l'utente ha eseguito l'accesso, il nome utente viene completato.

Per caricare i dati nella tabella principale dagli script di ambiente BigQuery, puoi eseguire un comando come questo:

bq load cdc_tutorial.session_main init.csv

Per recuperare i contenuti principali della tabella, puoi eseguire una query come la seguente:

bq query "select * from cdc_tutorial.session_main limit 1000"

L'output sarà simile al seguente:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | NULL     |         1 |
| 101 | Sam      |         2 |
| 102 | Jamie    |         3 |
+-----+----------+-----------+

Successivamente, caricherai il primo gruppo di modifiche CDC nella tabella delta. Per caricare il primo batch di modifiche CDC nella tabella delta dagli script di ambiente BigQuery, puoi eseguire un comando come questo:

bq load cdc_tutorial.session_delta first-batch.csv

Per ottenere i contenuti della tabella delta, puoi eseguire una query come la seguente:

bq query "select * from cdc_tutorial.session_delta limit 1000"

L'output sarà simile al seguente:

+-----+----------+-----------+-------------+
| id  | username | change_id | change_type |
+-----+----------+-----------+-------------+
| 100 | Cory     |         4 | U           |
| 101 | Sam      |         5 | D           |
| 103 | NULL     |         6 | I           |
| 104 | Jamie    |         7 | I           |
+-----+----------+-----------+-------------+

Nell'output precedente, il valore change_id è l'ID univoco di una modifica alla riga della tabella. I valori nella colonna change_type rappresentano quanto segue:

• U: operazioni di aggiornamento
• D: operazioni di eliminazione
• I: operazioni di inserimento

La tabella principale contiene informazioni sulle sessioni 100, 101 e 102. La tabella delta presenta le seguenti modifiche:

• La sessione 100 viene aggiornata con il nome utente "Cory".
• La sessione 101 è stata eliminata.
• Vengono create nuove sessioni 103 e 104.

Lo stato attuale delle sessioni nel sistema di origine è il seguente:

+-----+----------+
| id  | username |
+-----+----------+
| 100 | Cory     |
| 102 | Jamie    |
| 103 | NULL     |
| 104 | Jamie    |
+-----+----------+

Sebbene lo stato attuale venga visualizzato sotto forma di tabella, questa tabella non esiste in formato materializzato. Questa è la combinazione della tabella principale e della tabella delta.

Eseguire query sui dati

Per determinare lo stato generale delle sessioni, puoi utilizzare diversi approcci. I vantaggi e gli svantaggi di ciascun approccio sono descritti nelle sezioni seguenti.

Approccio immediato alla coerenza

Se il tuo obiettivo principale è la coerenza immediata dei dati e i dati di origine cambiano spesso, puoi utilizzare una singola query che unisce le tabelle principali e delta e selezioni la riga più recente (la riga con il timestamp più recente o il valore numerico più alto).

Per creare una vista BigQuery che unisca le tabelle principali e delta e trovi la riga più recente, puoi eseguire un comando dello strumento bq come segue:

bq mk --view \
"SELECT * EXCEPT(change_type, row_num)
FROM (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num
  FROM (
    SELECT * EXCEPT(change_type), change_type
    FROM \`$(gcloud config get-value project).cdc_tutorial.session_delta\` UNION ALL
    SELECT *, 'I'
    FROM \`$(gcloud config get-value project).cdc_tutorial.session_main\`))
WHERE
  row_num = 1
  AND change_type <> 'D'" \
 cdc_tutorial.session_latest_v

L'istruzione SQL nella vista BigQuery precedente:

• L'elemento UNION ALL più interno produce le righe delle tabelle principali e delta:
  • SELECT * EXCEPT(change_type), change_type FROM session_delta forza la colonna change_type a essere l'ultima colonna dell'elenco.
  • SELECT *, 'I' FROM session_main seleziona la riga dalla tabella principale come se fosse una riga di inserimento.
  • L'utilizzo dell'operatore * semplifica l'esempio. Se sono presenti altre colonne o un ordine delle colonne diverso, sostituisci la scorciatoia con elenchi di colonne espliciti.
• SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num utilizza una funzione finestra in BigQuery per assegnare numeri di riga sequenziali che iniziano con 1 a ciascuno dei gruppi di righe che hanno lo stesso valore di id, definito da PARTITION BY. Le righe sono ordinate in base a change_id in ordine decrescente all'interno del gruppo. Poiché è garantito un aumento di change_id, l'ultima modifica ha una colonna row_num con valore 1.
• WHERE row_num = 1 AND change_type <> 'D' seleziona solo l'ultima riga di ogni gruppo. Questa è una tecnica di deduplicazione comune in BigQuery. Questa clausola rimuove la riga anche dal risultato se il tipo di modifica è delete.
• L'elemento SELECT * EXCEPT(change_type, row_num) più in alto rimuove le colonne aggiuntive che sono state introdotte per l'elaborazione e che non sono pertinenti altrimenti.

L'esempio precedente non utilizza i tipi di modifica di inserimento e aggiornamento nella vista perché, facendo riferimento al valore change_id più alto, si seleziona l'inserimento originale o l'aggiornamento più recente. In questo caso, ogni riga contiene i dati completi per tutte le colonne.

Dopo averla creata, puoi eseguire query su una vista. Per ottenere le modifiche più recenti, puoi eseguire una query come la seguente:

bq query 'select * from cdc_tutorial.session_latest_v order by id limit 10'

L'output sarà simile al seguente:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | Cory     |         4 |
| 102 | Jamie    |         3 |
| 103 | NULL     |         6 |
| 104 | Jamie    |         7 |
+-----+----------+-----------+

Quando esegui una query sulla vista, i dati nella tabella delta sono immediatamente visibili se sono stati aggiornati nella tabella delta utilizzando un'istruzione DML (Data Manipulation Language) o quasi immediatamente se sono stati inviati flussi di dati.

Approccio ottimizzato per i costi

L'approccio immediato alla coerenza è semplice, ma può essere inefficiente perché richiede a BigQuery di leggere tutti i record storici, ordinare per chiave primaria ed elaborare le altre operazioni nella query per implementare la vista. Se esegui spesso query sullo stato della sessione, l'approccio di coerenza immediata potrebbe ridurre le prestazioni e aumentare i costi di archiviazione ed elaborazione dei dati in BigQuery.

Per ridurre al minimo i costi, puoi unire le modifiche alla tabella delta nella tabella principale ed eliminare periodicamente le righe unite dalla tabella delta. È previsto un costo aggiuntivo per l'unione e l'eliminazione definitiva, ma se esegui spesso query sulla tabella principale, il costo è trascurabile rispetto al costo della ricerca continua dell'ultimo record per una chiave nella tabella delta.

Per unire i dati della tabella delta nella tabella principale, puoi eseguire un'istruzione MERGE come la seguente:

bq query \
'MERGE `cdc_tutorial.session_main` m
USING
  (
  SELECT * EXCEPT(row_num)
  FROM (
    SELECT *, ROW_NUMBER() OVER(PARTITION BY delta.id ORDER BY delta.change_id DESC) AS row_num
    FROM `cdc_tutorial.session_delta` delta )
  WHERE row_num = 1) d
ON  m.id = d.id
  WHEN NOT MATCHED
AND change_type IN ("I", "U") THEN
INSERT (id, username, change_id)
VALUES (d.id, d.username, d.change_id)
  WHEN MATCHED
  AND d.change_type = "D" THEN
DELETE
  WHEN MATCHED
  AND d.change_type = "U"
  AND (m.change_id < d.change_id) THEN
UPDATE
SET username = d.username, change_id = d.change_id'

L'istruzione MERGE precedente riguardava quattro righe e la tabella principale mostra lo stato attuale delle sessioni. Per eseguire una query sulla tabella principale in questa visualizzazione, puoi eseguire una query come la seguente:

  bq query 'select * from cdc_tutorial.session_main order by id limit 10'

L'output ha il seguente aspetto:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | Cory     |         4 |
| 102 | Jamie    |         3 |
| 103 | NULL     |         6 |
| 104 | Jamie    |         7 |
+-----+----------+-----------+

I dati nella tabella principale riflettono gli stati delle sessioni più recenti.

Il modo migliore per unire i dati di frequente e in modo coerente è utilizzare un'istruzione MERGE, che consente di combinare più istruzioni INSERT, UPDATE e DELETE in una singola operazione atomica. Di seguito sono riportate alcune delle sfumature dell'istruzione MERGE precedente:

• La tabella session_main viene unita all'origine dati specificata nella clausola USING, una sottoquery in questo caso.
• La sottoquery utilizza la stessa tecnica della vista nell'approccio con coerenza immediata: seleziona la riga più recente nel gruppo di record che hanno lo stesso valore id, una combinazione di ROW_NUMBER() OVER(PARTITION BY id ORDER BY change_id DESC) row_num e WHERE row_num = 1.
• L'unione viene eseguita nelle colonne id di entrambe le tabelle, che è la chiave primaria.
• La clausola WHEN NOT MATCHED controlla se è presente una corrispondenza. Se non esiste una corrispondenza, la query controlla che il record più recente sia di inserimento o aggiornamento, quindi inserisce il record.
  • Quando viene trovata una corrispondenza per il record e il tipo di modifica viene eliminato, il record viene eliminato nella tabella principale.
  • Quando viene trovata una corrispondenza per il record, il tipo di modifica viene aggiornato e il valore change_id della tabella delta è superiore al valore change_id del record principale, i dati vengono aggiornati, incluso il valore change_id più recente.

L'istruzione MERGE precedente funziona correttamente per qualsiasi combinazione delle seguenti modifiche:

• Aggiorna più righe per la stessa chiave primaria: verrà applicato solo l'ultimo aggiornamento.

• Aggiornamenti senza corrispondenza nella tabella principale: se la tabella principale non contiene il record nella chiave primaria, viene inserito un nuovo record.

  Questo approccio salta l'estrazione della tabella principale e inizia con la tabella delta. La tabella principale viene completata automaticamente.

• Inserisci e aggiorna le righe nel batch delta non elaborato. Viene utilizzata la riga di aggiornamento più recente e un nuovo record viene inserito nella tabella principale.

• Inserisci ed elimina le righe nel batch non elaborato. Il record non è stato inserito.

L'istruzione MERGE precedente è idempotente: l'esecuzione più volte determina lo stesso stato della tabella principale e non causa effetti collaterali. Se esegui nuovamente l'istruzione MERGE senza aggiungere nuove righe alla tabella delta, l'output sarà simile al seguente:

Number of affected rows: 0

Puoi eseguire l'istruzione MERGE a intervalli regolari per aggiornare la tabella principale dopo ogni unione. L'aggiornamento dei dati nella tabella principale dipende dalla frequenza delle unioni. Per informazioni su come eseguire automaticamente l'istruzione MERGE, consulta la sezione "Pianificazione delle unioni" nel file demo README che hai scaricato in precedenza.

Approccio ibrido

L'approccio con coerenza immediata e quello con ottimizzazione dei costi non si escludono a vicenda. Se esegui query sulla vista session_latest_v e sulla tabella session_main, vengono restituiti gli stessi risultati. Puoi selezionare l'approccio da utilizzare in base ai tuoi requisiti e al tuo budget: costi più elevati e coerenza quasi immediata o costo inferiore, ma dati potenzialmente inattivi. Le seguenti sezioni descrivono come confrontare gli approcci e le potenziali alternative.

Confronta gli approcci

Questa sezione descrive come confrontare gli approcci considerando il costo e le prestazioni di ogni soluzione e il rapporto tra latenza accettabile dei dati e costo dell'esecuzione di unioni.

Costo delle query

Per valutare il costo e le prestazioni di ogni soluzione, l'esempio seguente fornisce un'analisi di circa 500.000 sessioni generate dalla demo di integrazione di BigQuery CDC. Il modello di sessione nella demo è leggermente più complesso rispetto al modello introdotto in precedenza in questo documento e ne è stato eseguito il deployment in un set di dati diverso, ma i concetti sono gli stessi.

Puoi confrontare il costo delle query utilizzando una semplice query di aggregazione. La query di esempio seguente verifica l'approccio di coerenza immediata rispetto alla vista che combina i dati delta con la tabella principale:

SELECT status, count(*) FROM `cdc_demo.session_latest_v`
GROUP BY status ORDER BY status

La query comporta il seguente costo:

Slot time consumed: 15.115 sec, Bytes shuffled 80.66 MB

La query di esempio seguente verifica l'approccio con ottimizzazione dei costi rispetto alla tabella principale:

SELECT status, count(*) FROM `cdc_demo.session_main`
GROUP BY status ORDER BY status

La query comporta il seguente costo inferiore:

Slot time consumed: 1.118 sec, Bytes shuffled 609 B

Il consumo del tempo di slot può variare quando esegui le stesse query più volte, ma le medie sono abbastanza coerenti. Il valore Bytes shuffled è coerente tra le diverse esecuzioni.

I risultati dei test delle prestazioni variano in base ai tipi di query e al layout della tabella. La demo precedente non utilizza il clustering o il partizionamento dei dati.

Latenza dei dati

Quando utilizzi l'approccio con ottimizzazione dei costi, la latenza dei dati è la somma di quanto segue:

• Ritardo del trigger della replica dei dati. Questo è il periodo di tempo che intercorre tra il momento in cui i dati vengono conservati durante l'evento di origine e il momento in cui il sistema di replica attiva il processo di replica.
• Tempo per inserire i dati in BigQuery (varia in base alla soluzione di replica).
• Tempo necessario per la visualizzazione dei dati del buffer dei flussi di dati BigQuery nella tabella delta. Se utilizzi l'inserimento di flussi di dati, l'operazione in genere richiede alcuni secondi.
• Ritardo tra le esecuzioni di unione.
• È il momento di eseguire l'unione.

Quando utilizzi l'approccio alla coerenza immediata, la latenza dei dati è la somma di quanto segue:

• Ritardo del trigger della replica dei dati.
• È il momento di inserire i dati in BigQuery.
• Tempo necessario per la visualizzazione dei dati del buffer del flusso di bigQuery nella tabella delta.

Puoi configurare il ritardo tra le esecuzioni di un'unione a seconda del compromesso tra i costi dell'esecuzione delle unioni e della necessità che i dati siano più coerenti. Se necessario, puoi utilizzare uno schema più complesso, come le unioni frequenti eseguite durante l'orario di apertura e le unioni orarie al di fuori dell'orario di lavoro.

Alternative da considerare

L'approccio per la coerenza immediata e l'approccio ottimizzato per i costi sono le opzioni CDC più generiche per l'integrazione di varie origini dati con BigQuery. Questa sezione descrive le opzioni di integrazione dei dati più semplici e meno costose.

Tabella delta come unica fonte attendibile

Se la tabella delta contiene la cronologia completa delle modifiche, puoi creare una visualizzazione solo sulla base della tabella delta e non utilizzare la tabella principale. L'utilizzo di una tabella delta come unica fonte attendibile è un esempio di database di eventi. Questo approccio offre coerenza istantanea a basso costo con penalità di prestazioni ridotte. Prendi in considerazione questo approccio se hai una tabella delle dimensioni che cambia molto lentamente con un numero ridotto di record.

Dump dei dati completo senza CDC

Se hai tabelle di dimensioni gestibili (ad esempio, meno di 1 GB), potrebbe essere più semplice eseguire un dump completo dei dati nella seguente sequenza:

1. Importa il dump dei dati iniziale in una tabella con un nome univoco.
2. Crea una vista che faccia solo riferimento alla nuova tabella.
3. Esegue query sulla vista, non sulla tabella sottostante.
4. Importa il successivo dump dei dati in un'altra tabella.
5. Ricrea la vista in modo che punti ai dati appena caricati.
6. Se vuoi, elimina la tabella originale.
7. Ripeti i passaggi precedenti per importare, ricreare ed eliminare regolarmente.

Conserva la cronologia delle modifiche nella tabella principale

Con l'approccio con ottimizzazione dei costi, la cronologia delle modifiche non viene conservata e l'ultima modifica sovrascrive i dati precedenti. Se hai bisogno di conservare la cronologia, puoi archiviarla utilizzando una serie di modifiche, facendo attenzione a non superare il limite massimo di dimensione delle righe. Se conservi la cronologia delle modifiche nella tabella principale, il DML di unione è più complesso perché una singola operazione MERGE può unire più righe della tabella delta in una singola riga della tabella principale.

Utilizzare origini dati federate

In alcuni casi, puoi replicare in un'origine dati diversa da BigQuery per poi esporre l'origine dati utilizzando una query federata. BigQuery supporta diverse origini dati esterne. Ad esempio, se replichi uno schema simile a una stella da un database MySQL, puoi replicare le dimensioni che cambiano lentamente in una versione di sola lettura di MySQL utilizzando la replica nativa di MySQL. Quando utilizzi questo metodo, replichi solo la tabella dei fatti che cambia spesso in BigQuery. Se vuoi utilizzare origini dati federate, tieni presente che esistono diverse limitazioni alle query sulle origini federate.

Migliorare ulteriormente il rendimento

Questa sezione illustra come migliorare ulteriormente le prestazioni eseguendo il clustering e il partizionamento delle tabelle ed eliminando i dati uniti.

Tabelle BigQuery di cluster e partizione

Se hai un set di dati sottoposto a query di frequente, analizza l'utilizzo di ogni tabella e ottimizza la progettazione della tabella utilizzando il clustering e il partizionamento. Il clustering di una o entrambe le tabelle principale e delta in base a chiave primaria può portare a prestazioni migliori rispetto agli altri approcci. Per verificare le prestazioni, testa le query su un set di dati di almeno 10 GB.

Elimina i dati uniti

La tabella delta cresce nel tempo e ogni richiesta di unione fa perdere risorse grazie alla lettura di un numero di righe non necessarie per il risultato finale. Se utilizzi i dati della tabella delta solo per calcolare lo stato più recente, l'eliminazione dei record uniti può ridurre i costi dell'unione e ridurre i costi complessivi riducendo la quantità di dati archiviati in BigQuery.

Puoi eliminare i dati uniti nei seguenti modi:

• Esegui periodicamente una query sulla tabella principale per ottenere il valore change_id massimo ed elimina tutti i record delta con un valore change_id inferiore a questo valore massimo. Se esegui il flusso di inserti nella tabella delta, questi potrebbero non essere eliminati per un determinato periodo di tempo.
• Utilizza il partizionamento basato su importazione delle tabelle delta ed esegui uno script giornaliero per eliminare le partizioni già elaborate. Quando sarà disponibile un partizionamento più granulare di BigQuery, puoi aumentare la frequenza di eliminazione definitiva. Per informazioni sull'implementazione, consulta la sezione "Eliminazione dei dati elaborati" nel file demo README che hai scaricato in precedenza.

Conclusioni

Per scegliere l'approccio giusto o più approcci, considera i casi d'uso che stai cercando di risolvere. Potresti essere in grado di soddisfare le tue esigenze di replica dei dati utilizzando le tecnologie di migrazione dei database esistenti. Se hai esigenze complesse, ad esempio se devi risolvere un caso d'uso dei dati quasi in tempo reale e ottimizzare i costi per il resto del modello di accesso ai dati, potresti dover impostare una frequenza di migrazione dei database personalizzata in base ad altri prodotti o soluzioni open source. Gli approcci e le tecniche descritti in questo documento possono aiutarti a implementare correttamente questa soluzione.

Passaggi successivi

• Consulta la pagina Eseguire la migrazione delle pipeline di dati.
• Scopri di più sulla progettazione dell'architettura ETL per un data warehouse cloud-native su Google Cloud e sull'esecuzione di ETL da un database relazionale in BigQuery con Dataflow.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.