Condividi tramite

Limitazioni nei database replicati di Microsoft Fabric da Google BigQuery

Questa guida ti aiuta a imparare di più sulle limitazioni esistenti nel BigQuery mirrorato in Microsoft Fabric.

Importante

Attualmente supportiamo il mirroring per Google BigQuery per il gateway dati locale (OPDG). Usare la versione 3000.286.6 o successiva

Limitazioni a livello di database

Quando si esegue il mirroring delle tabelle senza chiavi primarie, è possibile eseguire solo modifiche di inserimento per garantire l'accuratezza dei dati. Se vengono rilevate modifiche non inserite, la tabella viene reinizializzata (la tabella viene rimirrored completamente). Se si verificano più modifiche di noninserimento dopo il ripristino iniziale, il mirroring entra in uno stato di attesa per un periodo di tempo; lo stato di attesa consente di ridurre i costi e limitare la replica completa della tabella non necessaria. Dopo il periodo di backoff, la tabella tornerà allo stato normale del mirroring (replica continua dei dati).

Limitazioni delle prestazioni

Se si modifica la maggior parte dei dati in una tabella di grandi dimensioni, è più efficiente arrestare e riavviare il mirroring. L'inserimento o l'aggiornamento di miliardi di record può richiedere molto tempo.

I dati con mirroring riflettono in genere le modifiche con un ritardo di 10-15 minuti a causa dell'architettura di Change Data Capture (CDC) di BigQuery. Se non vengono rilevate modifiche, il motore di replica entra in modalità backoff, aumentando gli intervalli di polling fino a 1 ora.

Limitazioni delle regioni supportate

Il mirroring del database è disponibile in tutte le aree di Microsoft Fabric. Per altre informazioni, si veda Disponibilità di Fabric a livello di area.

Limitazioni per l'autorizzazione

Sappiamo che alcuni clienti sono riluttanti ad abilitare le autorizzazioni di modifica per il mirroring per Google BigQuery. Il mirroring crea una replica a consumo dinamica e modificabile dei dati BigQuery in OneLake. Per supportare il mirroring per Google BigQuery, il motore di replica deve:

  • Accedere ed esportare dati da tabelle BigQuery
  • Tenere traccia delle modifiche usando Change Data Capture (CDC)
  • Creare set di dati temporanei e processi per la replica
  • Interagire con Google Cloud Storage per la preparazione e acquisizione dei dati

Limitazioni di cui è stato sottoposto a nuovo

La funzione CHANGES, che consente il rilevamento delle modifiche nelle tabelle BigQuery che usano la tecnologia CDC di Google, è soggetta a diverse importanti limitazioni di reinizialing che gli utenti devono prendere in considerazione quando implementano soluzioni di mirroring:

  • Limitazione del viaggio temporale: la funzione CHANGES restituisce solo i dati all'interno dell'intervallo di tempo configurato della tabella. Per le tabelle standard, si tratta in genere di sette giorni, ma può essere più breve se configurata in modo diverso. Eventuali modifiche all'esterno di questa finestra non sono accessibili.
  • Limitazione timestamp: l'intervallo di tempo della cronologia delle modifiche per CHANGES TVF supera il tempo massimo consentito. L'intervallo massimo consentito tra start_timestamp e end_timestamp è un giorno. Ciò limita l'elaborazione in batch di finestre temporali storiche più lunghe e possono essere necessarie più query per una copertura più ampia.
    -Limitazione cronologia modifiche: la funzione CHANGES richiede che il rilevamento della cronologia delle modifiche sia abilitato per la tabella prima dell'uso. Se non è abilitato, non è possibile eseguire query su modifiche delta.
  • Limitazione di più istruzioni: la funzione CHANGES non può essere usata all'interno di transazioni con più istruzioni. Non è inoltre possibile eseguire query sulle tabelle con transazioni con più istruzioni di cui è stato eseguito il commit nell'intervallo di tempo richiesto.

Per altre informazioni, fare riferimento alla documentazione relativa alle limitazioni delle modifiche di BigQuery di Google.

Contenuti correlati

  • Last updated on