Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Ce guide vous aide à en savoir plus sur les limitations existantes dans votre BigQuery mis en miroir dans Microsoft Fabric.
Important
Nous soutenons actuellement la mise en miroir pour la passerelle de données locale (OPDG) avec Google BigQuery. Utiliser la version 3000.286.6 ou ultérieure
Limitations au niveau de la base de données
Lors de la mise en miroir de tables sans clés primaires, vous pouvez uniquement effectuer des modifications d’insertion uniquement pour garantir la précision des données. Si des modifications de non-insertion sont trouvées, la table est automatiquement resinimée (la table est remiroirée dans son intégralité). Si plusieurs modifications non-insert se produisent après ce réensemencement initial, la mise en miroir passe à un état de repli pendant une période ; cet état de repli aide à garder les coûts bas et limite les réplicas inutiles de table complète. Après la période d’interruption, la table revient à son état normal de mirroring (réplication continue des données).
Limitations des performances
Si vous modifiez la plupart des données d’une table volumineuse, il est plus efficace d’arrêter et de redémarrer la mise en miroir. L’insertion ou la mise à jour de milliards d’enregistrements peut prendre beaucoup de temps.
Les données mises en miroir reflètent généralement les modifications avec un délai de 10 à 15 minutes en raison de l’architecture de capture de données modifiées (CDC) de BigQuery. Si aucune modification n’est détectée, le moteur de réplication entre en mode de ralentissement, augmentant les intervalles de vérification allant jusqu’à 1 heure.
Limitations des régions prises en charge
La mise en miroir de bases de données est disponible dans toutes les régions Microsoft Fabric. Pour plus d'informations, voir Disponibilité des régions Fabric.
Limitations de l’autorisation
Nous comprenons que certains clients hésitent à activer les autorisations de modification pour la mise en miroir pour Google BigQuery. La mise en miroir crée une réplique de consommation éditable en temps réel de vos données BigQuery dans OneLake. Pour prendre en charge la mise en miroir pour Google BigQuery, le moteur de réplication doit :
- Accéder et exporter des données à partir de tables BigQuery
- Suivre les modifications à l’aide de la capture de données modifiées (CDC)
- Créer des jeux de données et des travaux temporaires pour la réplication
- Travailler avec Google Cloud Storage pour la préparation et l'ingestion.
Limitations du réensemencement
La fonction CHANGES, qui permet le suivi des modifications dans les tables BigQuery à l’aide de la technologie CDC de Google, est soumise à plusieurs limitations importantes de reseeding que les utilisateurs doivent prendre en compte lors de l’implémentation de solutions de mise en miroir :
- Limitation du voyage dans le temps : la fonction CHANGES retourne uniquement les données dans la fenêtre de déplacement de temps configurée de la table. Pour les tables standard, il s’agit généralement de sept jours, mais peut être plus court s’il est configuré différemment. Toutes les modifications en dehors de cette fenêtre sont inaccessibles.
- Limitation de l’horodatage : la fenêtre temporelle de l’historique des modifications pour CHANGES TVF dépasse la durée maximale autorisée. La plage maximale autorisée entre
start_timestampetend_timestampest d’un jour. Cela limite le traitement par lots de fenêtres historiques plus longues, et plusieurs requêtes peuvent être requises pour une couverture plus large.
-Limitation de l’historique des modifications : la fonction CHANGES exige que le suivi de l’historique des modifications soit activé pour la table avant d’utiliser. S’il n’est pas activé, les modifications delta ne peuvent pas être consultées. - Limitation à plusieurs instructions : la fonction CHANGES ne peut pas être utilisée dans les transactions multi-instructions. Il ne peut pas non plus interroger les tables qui avaient des transactions à plusieurs instructions validées dans la fenêtre de temps demandée.
Pour en savoir plus, reportez-vous à la documentation relative à la limitation des modifications BigQuery de Google.