Sur cette page
Imaginez un écran de support qui cherche une réponse : cette commande a-t-elle été payée ? Le système de paiement le sait. Une équipe d’intégration propose de copier tous les paiements dans une seconde base, de tenir cette copie à jour et de la consulter quand la personne chargée du dossier ouvre la commande. C’est un exemple opérationnel hypothétique, pas le cas analytique de la démonstration citée.
Cette copie peut être nécessaire. Demandez d’abord si l’écran a simplement besoin d’une réponse autorisée maintenant.
Une démonstration technique de requêtes analytiques entre environnements cloud montre une requête sur des sources existantes sans créer d’abord une copie permanente de la table source à destination. La même démonstration matérialise une table issue d’une jointure : accès distant et copie peuvent donc coexister dans un même processus. C’est une capacité réelle du produit, pas une promesse qu’un service analytique convient à un écran opérationnel de paiement ni que les données ne bougent jamais pendant l’exécution. La documentation de Google Cloud sur les requêtes fédérées indique que certains résultats externes transitent temporairement par le service de requête. La distinction utile est celle entre une réplique synchronisée durable et une lecture limitée pour répondre à une question précise.
Partez de la tâche du système consommateur
« Connecter ces systèmes » cache deux demandes. La première : « Que dit la source maintenant ? » La seconde : « Quel état la destination doit-elle garder pour agir plus tard ? »
Pour l’écran de support, une lecture limitée peut renvoyer le statut d’une commande avec son heure d’observation. La source reste l’autorité. Si elle est indisponible, l’écran doit le dire ou étiqueter clairement une réponse tirée du cache. Une seconde copie créerait une nouvelle question : quel statut l’emporte quand les deux diffèrent ?
Un consommateur demande une réponse actuelle à la source par une requête autorisée et ciblée ; la requête peut traiter des données transitoires sans créer de réplique durable.
Pour une campagne de panier abandonné, la destination peut devoir agir sans qu’une personne ouvre un écran. Elle peut avoir besoin d’un événement rapide, d’un état de consentement et d’un moyen d’annuler un message programmé après l’achat. Une lecture en direct au moment de la campagne peut encore aider, mais une simple réponse à la demande ne résout pas toute la tâche.
| Besoin du consommateur | Premier modèle à tester | Principal compromis |
|---|---|---|
| Une réponse actuelle | Requête limitée auprès du responsable | Dépend de l’accès et de la latence de la source |
| Une action continue au changement | Événement ou synchronisation minimale des différences | Gérer délais, doublons et événements manqués |
| Une preuve historique de décision | Instantané versionné des champs pertinents | Gouverner conservation et accès |
| Fonctionner pendant une panne de la source | Cache ou réplique explicites | Risque d’obsolescence ; nécessite une limite d’âge |
Ce tableau guide un choix, ce n’est pas un banc d’essai. Il ne donne aucun seuil universel entre requête et copie.
Une copie engendre des coûts continus
La première extraction est facile à sous-estimer parce qu’elle se termine. La copie, elle, reste. Un champ apparaît, deux identifiants fusionnent, un droit change ou un vieil événement arrive après un nouveau. La destination peut alors conserver une réponse que la source rejetterait.
Le coût ne se limite pas au stockage. Il faut rapprocher les états : surveiller le retard, rejouer les changements manqués, effacer des données si nécessaire et expliquer pourquoi une décision a utilisé la valeur d’hier. Ces tâches sont justifiées quand la destination a besoin d’un état indépendant. Elles sont superflues si la seule livraison est une réponse actuelle.
Une requête a aussi des coûts. Elle peut charger la source, exposer des champs à une autre identité, franchir un réseau et échouer au mauvais moment. Le planificateur peut traiter plus de données que le résultat visible ne laisse penser. La documentation sur les requêtes fédérées décrit des détails à vérifier avant de supposer qu’une requête distante ne déplace rien.
Une requête sûre a un objectif et un résultat restreints. Nommez le propriétaire du champ. Limitez les droits du système ou de la personne qui interroge. Définissez l’âge maximal de la réponse, le temps d’attente et le message affiché en cas d’expiration. Conservez l’heure d’observation avec la réponse.
Quand une copie contrôlée justifie son coût
« Des données locales nous donnent une interface prévisible et moins de pannes distantes. » C’est un argument sérieux. Si le processus a une contrainte de latence forte ou doit continuer malgré une panne de la source, une réplique contrôlée peut être le bon choix.
Le mot contrôlée est décisif. Précisez quels champs sont copiés, sous quel délai ils doivent être mis à jour, ce qui se passe quand les mises à jour s’arrêtent et quand le consommateur refuse d’agir sur un état ancien. Testez une correction tardive autant que le cas normal. Une réponse rapide, mais périmée, peut être pire qu’une indisponibilité affichée.
Commencez par la plus petite question du consommateur. Si une lecture suffit, laissez la source décider. Si une action exige un état local, ne copiez que ce qu’elle justifie.
Un essai restreint peut trancher sans construire une couche générale de réplication. Choisissez une question réellement posée, définissez la fraîcheur nécessaire et faites une requête autorisée à la source. Observez latence, charge et comportement lors des pannes avec des droits réalistes. Essayez ensuite le plus petit état copié qui répondrait au même besoin. Comparez non seulement le temps de réponse, mais aussi les corrections, suppressions et pannes. Le guide de planification des intégrations fournit le contexte général ; cet essai choisit où doit vivre la réponse. Aucun des deux chemins n’est automatiquement moins cher une fois l’entretien compté.
Une connexion ne se mesure pas au nombre de lignes qui l’ont traversée.
Questions fréquemment posées
Quand une requête distante vaut-elle mieux qu’une synchronisation ?
Lorsqu’un système ou une personne a besoin d’une réponse de la source faisant autorité et peut accepter sa disponibilité et sa latence. Limitez l’accès et indiquez quand la réponse a été lue.
Quand faut-il copier des données ?
Copiez le minimum d’état nécessaire quand un autre système doit agir sans requête en direct, conserver une photographie vérifiable ou respecter des contraintes de latence ou de disponibilité que la source ne peut assurer.
Interroger les données sur place signifie-t-il qu’elles ne bougent jamais ?
Non. Un service de requêtes fédérées peut transférer des résultats ou données intermédiaires pendant l’exécution. Vérifiez le fonctionnement documenté du fournisseur pour l’exécution, la conservation et la sécurité.