Limitazioni nei database di Microsoft Fabric replicati da Snowflake

Le limitazioni correnti nei database con mirroring Microsoft Fabric di Snowflake sono elencate in questa pagina. Questa pagina è soggetta a variazioni.

Limitazioni di connessione e autenticazione

• Nella tabella seguente sono elencati i metodi di autenticazione supportati per il mirroring per Snowflake:

• L'identità dell'area di lavoro non è attualmente supportata per il mirroring di Snowflake. È disponibile per le origini selezionate, ad esempio SharePoint.

• La connettività collegamento privato tra un'area di lavoro Fabric e Snowflake non è ancora disponibile. Usa un gateway dati di rete virtuale o un gateway dati locale per la connettività privata temporaneamente.

• È necessario aggiungere destinatari di condivisione all'area di lavoro. Per condividere un set di dati o un report, aggiungere prima di tutto access all'area di lavoro con un ruolo di amministratore, membro, lettore o collaboratore.

• Sensibilità alle maiuscole e alle minuscole: tutti gli identificatori Snowflake, inclusi il nome del warehouse, il nome del database, il nome dello schema, i nomi delle tabelle e i nomi delle viste, sono sensibili alle maiuscole e alle minuscole durante la configurazione delle connessioni di mirroring e quando si utilizza l'API REST di mirroring. La combinazione di maiuscole e minuscole immessa in Fabric deve corrispondere esattamente a ciò che è configurato in Snowflake. La mancata corrispondenza tra maiuscole e minuscole può causare errori di connessione o impedire la visualizzazione delle tabelle per la replica, spesso senza alcun messaggio di errore descrittivo. Ad esempio, se il magazzino Snowflake è denominato ANALYTICS_WH, è necessario immettere ANALYTICS_WH nella connessione Fabric, non analytics_wh.

Tipi di oggetto supportati

• Nella tabella seguente sono elencati i tipi di oggetto Snowflake supportati per il mirroring:

Limitazioni relative alla replica e ai dati

• Se non ci sono aggiornamenti in una tabella di origine, il motore di replica inizia a ridurre gradualmente l'attività aumentando la durata in maniera esponenziale per quella tabella, fino a un'ora. Lo stesso può verificarsi se si verifica un errore temporaneo, impedendo l'aggiornamento dei dati. Il motore di replicatore riprenderà automaticamente il regolare polling dopo il rilevamento dei dati aggiornati.
• La gerarchia dello schema di origine viene replicata nel database mirror. Per i database con mirroring creati prima dell'abilitazione di questa funzionalità, lo schema di origine viene appiattito e il nome dello schema viene codificato nel nome della tabella. Se si desidera riorganizzare le tabelle con schemi, ricreare il database specchiato. Per altre informazioni, vedere Replicare la gerarchia dello schema di origine.
• Il mirroring supporta la replica di colonne contenenti spazi o caratteri speciali nei nomi , ad esempio ,;{}()\n\t=. Per le tabelle in fase di replica prima che questa funzionalità sia abilitata, è necessario aggiornare le impostazioni del database con mirroring o riavviare il mirroring per includere tali colonne. Scopri di più sul supporto per il mapping delle colonne Delta .
• Il numero massimo di tabelle che può essere replicato in Fabric è 1.000. Tutte le tabelle che superano il limite di 1000 non possono essere replicate.
  • Se si seleziona Mirror all data when configuring Mirroring ( Mirroring di tutti i dati durante la configurazione del mirroring), le tabelle su cui eseguire il mirroring verranno determinate prendendo le prime 1.000 tabelle quando tutte le tabelle vengono ordinate alfabeticamente in base al nome dello schema e quindi al nome della tabella. L'insieme rimanente di tabelle alla fine dell'elenco alfabetico non verrà replicato.
  • Se si deseleziona Mirror tutti i dati e si selezionano singole tabelle, non è possibile selezionare più di 1.000 tabelle.
• Colonne calcolate e tabelle calcolate: i database con mirroring sono di sola lettura. Non è possibile creare colonne calcolate o tabelle calcolate direttamente in un database con mirroring. Per aggiungere colonne calcolate, creare un lakehouse e usare i collegamenti per fare riferimento ai dati replicati tramite mirroring, quindi creare le colonne calcolate nel lakehouse tramite notebook o SQL.

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.
• Alcune modifiche dello schema non vengono riflesse immediatamente. Alcune modifiche dello schema richiedono una modifica dei dati (inserimento, aggiornamento o eliminazione) prima che le modifiche dello schema vengano replicate in Fabric.
• Considerazioni tra aree: se l'istanza di Snowflake e la capacità di Fabric si trovano in aree cloud diverse, potrebbero verificarsi costi di replica e uscita dei dati più elevati. Per ottenere prestazioni ottimali ed evitare costi di trasferimento dati in uscita tra aree geografiche, distribuisci la capacità Fabric nella stessa area geografica del cloud in cui si trova l'istanza Snowflake. Se la distribuzione tra aree è inevitabile, tenere conto delle tariffe aggiuntive in uscita da Snowflake e/o Azure. Per informazioni dettagliate, vedere la documentazione sull'uscita di Snowflake .
• Quando si esegue il mirroring dei dati da Snowflake a OneLake di un cliente, il processo esegue normalmente lo stage dei dati tramite un URL inline per migliorare le prestazioni. Se il parametro a livello di account Snowflake PREVENT_UNLOAD_TO_INLINE_URL è impostato su true, si applica il comportamento seguente:

Risoluzione pianificata: il supporto per l'integrazione con l'archiviazione è in fase di sviluppo e fornirà un percorso di staging alternativo utilizzabile quando PREVENT_UNLOAD_TO_INLINE_URL è impostato su true. Questa soluzione sblocca gli scenari di rete virtuale e OPDG. Controllare questa pagina per verificare la disponibilità degli aggiornamenti.

• Comportamento di reinsediamento: Un nuovo oggetto è un ricaricamento completo dei dati di un'intera tabella. A differenza della sincronizzazione incrementale (che elabora solo le righe modificate), un reseed rilegge e riscrive tutti i dati nella tabella. Le operazioni di reseed possono comportare costi di calcolo elevati su Snowflake, soprattutto per le tabelle di grandi dimensioni.
  • Che cosa attiva una reinizializzazione:

• Procedure consigliate per evitare le rese non necessarie:
  • Pianificare le modifiche dello schema al di fuori del mirroring attivo. Se si usa DBT o altri strumenti di gestione dello schema, pianificarli durante le finestre di manutenzione o sospendere il mirroring prima di eseguire le modifiche dello schema.
  • Evitare modifiche frequenti al DDL. Consolidare le modifiche dello schema in un numero minore di batch di dimensioni maggiori anziché apportare modifiche incrementali durante il giorno.
  • Monitorare eventuali nuove inizializzazioni impreviste. Nella pagina Stato mirroring, controllare se vi sono tabelle che presentano ripetutamente il comportamento di copia iniziale. Se una tabella di grandi dimensioni viene sottoposta a reseeding ogni pochi minuti, verificare se ci sono modifiche DDL a monte.
  • Tenere presente l'impatto sui costi. Una nuova tabella di 226 milioni di righe (~26,5 GB) richiede tempo di calcolo significativo. Moltiplicare questo costo in base alla frequenza delle modifiche dello schema per stimare l'impatto sui costi.

Limitazioni di sicurezza

• Fabric non replica i criteri di sicurezza a livello di riga (RLS) e di sicurezza a livello di colonna (CLS) di Snowflake. È necessario riconfigurare manualmente i criteri di sicurezza equivalenti in Fabric.
• I destinatari della condivisione devono essere aggiunti all'area di lavoro. Per condividere un set di dati o un report, aggiungere prima di tutto access all'area di lavoro con un ruolo di amministratore, membro, lettore o collaboratore.

Considerazioni su costi e fatturazione

Per ridurre al minimo i costi di elaborazione di Snowflake dovuti al mirroring, considera le seguenti best practice:

• Riutilizzare un magazzino esistente. Anziché creare un warehouse dedicato per il mirroring, configurare il mirroring per usare lo stesso warehouse già usato dalle applicazioni per aggiornare le tabelle di origine. Questo approccio evita i cicli di riattivazione e sospensione automatica del magazzino non necessari. Quando l'applicazione aggiorna una tabella, il replicatore di mirroring rileva le modifiche quasi immediatamente mentre il warehouse è ancora attivo, eliminando la necessità di attivare un warehouse separato. Alcune organizzazioni potrebbero preferire un warehouse dedicato per isolare il budget. Questa scelta è un compromesso tra risparmio sui costi e granularità del budget.
• Esegui il mirroring solo delle tabelle necessarie. Il mirroring di un intero database può causare un consumo di Snowflake inaspettatamente elevato e picchi della capacità di Fabric. Per iniziare, selezionare solo le tabelle necessarie per gli scenari di analisi. È possibile aggiungere tabelle in un secondo momento in base alle esigenze.
• Monitorare eventuali nuove inizializzazioni impreviste. Un reload completo dei dati elabora l'intera tabella e comporta costi di calcolo proporzionali alle dimensioni della tabella. Le modifiche dello schema, incluse quelle attivate da strumenti come DBT, possono causare la reinizialità continua. Monitorare la pagina Stato mirroring per individuare le tabelle che mostrano un comportamento ripetuto di copia iniziale e consultare la sezione Reseeding per informazioni sui trigger e indicazioni per la risoluzione dei problemi.
• Tenere presente che il mirroring viene eseguito in modo continuo. Il mirroring non supporta attualmente la pianificazione o le finestre di replica. Il replicatore interroga continuamente le modifiche, generando un consumo continuo delle risorse di calcolo di Snowflake. Pianificate di conseguenza i budget di Snowflake.

Regioni supportate

Il mirroring del database e il mirroring aperto sono disponibili in tutte le aree Microsoft Fabric. Per altre informazioni, si veda Disponibilità di Fabric a livello di area.

Contenuti correlati

• Che cos'è il mirroring in Fabric?
• Mirroring Snowflake
• Tutorial: Configurare i database mirror di Microsoft Fabric con Snowflake