Requêtes fédérées Cloud SQL

Cette page explique comment interroger des données dans BigQuery et Cloud SQL grâce à une requête fédérée.

Ce produit ou cette fonctionnalité est disponible dans sa version préliminaire, et peut changer ou bénéficier d'une assistance limitée. Pour en savoir plus, consultez les étapes de lancement des produits.

Présentation

Il est fréquent que les données soient dispersées dans plusieurs emplacements. Vous pouvez stocker une table de clients dans BigQuery tout en hébergeant une table des ventes dans Cloud SQL, et vous pouvez être amené à effectuer une jointure entre ces deux tables au sein d'une même requête.

La fédération de BigQuery et Cloud SQL permet à BigQuery d'interroger les données résidant dans Cloud SQL en temps réel, sans avoir à copier ni déplacer de données. La fédération est compatible aussi bien avec les instances MySQL (deuxième génération) que PostgreSQL dans Cloud SQL.

Une fois la configuration initiale unique effectuée, vous pouvez rédiger une requête à l'aide de la nouvelle fonction SQL EXTERNAL_QUERY().

Workflow

• Choisissez un projet GCP qui inclut l'instance Cloud SQL à interroger.
• Un utilisateur bigquery.admin crée une ressource de connexion dans BigQuery.
• L'utilisateur administrateur accorde l'autorisation d'utiliser la ressource de connexion à l'utilisateur B.
  • Si l'administrateur et l'utilisateur B sont la même personne, il n'est pas nécessaire d'accorder une autorisation.
• L'utilisateur B écrit une requête dans BigQuery à l'aide de la nouvelle fonction EXTERNAL_QUERY().

Attention : Les requêtes fédérées peuvent avoir des performances inférieures aux requêtes effectuées sur des données résidant dans le stockage BigQuery.

Syntaxe des requêtes fédérées

La requête fédérée introduit une nouvelle fonction : EXTERNAL_QUERY.

Syntaxe

SELECT * FROM EXTERNAL_QUERY(connection_id, external_database_query);

• connection_id (chaîne) : nom de la ressource de connexion à la base de données que vous créez dans l'UI Web, la CLI ou l'API.

  Exemple d'ID de connexion : bigquery-federation-test.us.test-mysql

• external_database_query (chaîne) : requête en lecture seule dans le dialecte SQL (MySQL ou PostgreSQL) de la base de données externe. La requête est exécutée dans la base de données externe dans Cloud SQL.

Description

EXTERNAL_QUERY exécute la requête dans Cloud SQL et renvoie les résultats sous forme de table temporaire. Le type de données de la base de données source (MySQL ou PostgreSQL) est converti en type de données BigQuery dans la table de résultats temporaire, en suivant le mappage des types de données décrit ci-dessous. La fonction EXTERNAL_QUERY est généralement utilisée dans une clause FROM. Cette fonction n'est disponible que dans le langage SQL standard de BigQuery.

Point clé : Vous pouvez également utiliser la fonction EXTERNAL_QUERY() pour accéder aux métadonnées sur la base de données externe. Pour en savoir plus, consultez la section Afficher un schéma de table Cloud SQL.

Type renvoyé

Une table BigQuery.

Exemple de requête

Supposons que vous ayez besoin de la date de la première commande pour chacun de vos clients, afin de l'inclure dans le rapport décrit dans la section de présentation. Ces données ne figurent pas actuellement dans BigQuery, mais elles sont disponibles dans votre base de données PostgreSQL opérationnelle hébergée dans Cloud SQL. L'exemple de requête fédérée ci-dessous permet de réaliser cette opération.

SELECT c.customer_id, c.name, SUM(t.amount) AS total_revenue,
rq.first_order_date
FROM customers AS c
INNER JOIN transaction_fact AS t ON c.customer_id = t.customer_id
LEFT OUTER JOIN EXTERNAL_QUERY(
  'connection_id',
  '''SELECT customer_id, MIN(order_date) AS first_order_date
  FROM orders
  GROUP BY customer_id''') AS rq ON rq.customer_id = c.customer_id
GROUP BY c.customer_id, c.name, rq.first_order_date;

L'exemple de requête comprend trois parties :

1. Grâce à la fonction EXTERNAL_QUERY(), exécution de la requête externe SELECT customer_id, MIN(order_date) AS first_order_date FROM orders GROUP BY customer_id dans la base de données PostgreSQL opérationnelle afin d'obtenir la date de première commande pour chaque client.
2. Jointure par customer_id de la table des résultats de la requête externe avec la table des clients dans BigQuery.
3. Sélection des informations client et de la date de la première commande.

L'ordre n'est pas préservé

EXTERNAL_QUERY() ne respecte pas l'ordre des résultats de la requête externe, même si votre requête externe inclut une clause ORDER BY. L'exemple de requête suivant trie les lignes par identifiant client dans Cloud SQL, mais BigQuery ne les affichera pas dans cet ordre.

SELECT * EXTERNAL_QUERY(
'connection_id',
'''SELECT * FROM customers AS c ORDER BY c.customer_id'');

Avant de commencer

Activer le service de connexion BigQuery

• Ouvrez la page API de connexion BigQuery dans la bibliothèque d'API.
• Dans le menu déroulant, sélectionnez le projet contenant votre instance Cloud SQL.
• Cliquez sur le bouton ACTIVER.

Compte de service

BigQuery utilise un compte de service pour se connecter à votre instance Cloud SQL. Lorsque vous activez l'API de connexion BigQuery, un compte de service Cloud IAM géré par Google Cloud est automatiquement créé en votre nom. Le compte de service possède les rôles suivants :

Rôle	Description
cloudsql.client	Connexion à une instance Cloud SQL
logging.logWriter	Écriture dans cloud-logging
metrics.metricWriter	Écriture dans cloud-monitoring

Autorisations

• Pour créer et gérer une ressource de connexion, l'utilisateur doit disposer du rôle IAM prédéfini bigquery.admin.

• Le rôle bigquery.admin inclut les autorisations suivantes sur le service de connexion BigQuery :

  • bigquery.connections.create
  • bigquery.connections.get
  • bigquery.connections.list
  • bigquery.connections.update
  • bigquery.connections.use
  • bigquery.connections.delete

Pour accorder des autorisations à un autre utilisateur et lui permettre d'utiliser la ressource de connexion pour effectuer des requêtes Cloud SQL, consultez la section Accorder des autorisations à un autre utilisateur.

Accorder un accès bigquery.admin

Pour accorder le rôle bigquery.admin, procédez comme suit :

Console

1. Ouvrez la page Cloud IAM dans Cloud Console.

   Ouvrir la page IAM

2. Cliquez sur Sélectionner un projet.

3. Sélectionnez un projet et cliquez sur Ouvrir.

4. Cliquez sur Ajouter pour ajouter de nouveaux membres au projet et définir leurs autorisations.

5. Dans la boîte de dialogue Ajouter des membres :

   • Dans le champ Membres, entrez l'adresse e-mail de l'utilisateur ou du groupe.
   • Dans la liste déroulante Sélectionner un rôle, cliquez sur BigQuery > Administrateur BigQuery.

   • Cliquez sur Ajouter.

     

CLI

Vous pouvez accorder le rôle bigquery.admin à un utilisateur ou à un groupe à l'aide de l'outil de ligne de commande gcloud.

Pour ajouter une liaison unique à la stratégie Cloud IAM de votre projet, saisissez la commande suivante. Pour ajouter un utilisateur, indiquez l'option --member au format user:[e-mail]. Pour ajouter un groupe, indiquez l'option --member au format group:[e-mail].

gcloud projects add-iam-policy-binding project_id \
--member group/user:address \
--role roles/bigquery.admin

Où :

• project_id est l'ID du projet ;
• group/user est soit group, soit user.
• address est l'adresse e-mail de l'utilisateur ou du groupe.

Exemple :

gcloud projects add-iam-policy-binding myproject \
--member group:[e-mail] \
--role roles/bigquery.admin

La commande génère la règle mise à jour :

    bindings:
    - members:
      - group:[e-mail]
        role: roles/bigquery.admin
    

Pour en savoir plus sur les rôles Cloud IAM dans BigQuery, consultez la page Rôles et autorisations prédéfinis.

Adresse IP publique

La fédération de BigQuery et Cloud SQL ne fonctionne qu'avec les instances Cloud SQL disposant d'une connectivité IP publique. Veuillez configurer la connectivité IP publique sur votre instance Cloud SQL.

Remarque : Vous pouvez ajouter une connectivité IP publique SANS adresse autorisée. Bien que le niveau de sécurité soit inférieur à l'utilisation d'une adresse IP privée uniquement, votre instance restera inaccessible depuis l'Internet public mais pourra être interrogée depuis BigQuery.

Configurer les connexions à la base de données Cloud SQL

Pour éviter de faire apparaître les identifiants d'accès à la base de données sous forme de texte clair dans une requête fédérée, vous devez d'abord créer dans BigQuery une ressource de connexion pour chaque base de données, puis référencer la ressource de connexion dans votre requête fédérée.

La ressource de connexion dispose d'un ensemble d'autorisations IAM, que vous pouvez accorder à d'autres utilisateurs. La ressource de connexion est chiffrée et stockée de manière sécurisée dans le service de connexion BigQuery et ne peut être utilisée que pour des requêtes fédérées.

Pour en savoir plus sur les rôles et les autorisations Cloud IAM dans BigQuery, consultez la page Rôles et autorisations prédéfinis.

Créer une ressource de connexion

Console

Point clé : Vous créez la connexion dans votre projet BigQuery GCP.

1. Pour créer une ressource de connexion, accédez à l'UI Web de BigQuery dans Cloud Console.

   Accéder à Cloud Console

2. Sous Ajouter des données, sélectionnez Créer une connexion depuis le menu.

   

3. Dans le volet Créer une connexion :

   • Dans le champ Type de connexion, sélectionnez MySQL ou Postgre.
   • Dans le champ ID de connexion, saisissez un identifiant pour la ressource de connexion. Les lettres, les chiffres et les traits de soulignement sont autorisés.
   • Dans le champ Emplacement de connexion, sélectionnez l'emplacement de l'instance Cloud SQL, avec les exceptions suivantes : pour une instance Cloud SQL située dans la région us-central1, sélectionnez l'emplacement US ; pour la région europe-west1, sélectionnez l'emplacement EU.
   • (Facultatif) Dans le champ Nom descriptif, saisissez un nom clair pour identifier la connexion, tel que My connection resource. Le nom descriptif peut être n'importe quelle valeur permettant d'identifier facilement la ressource de connexion si vous devez la modifier par la suite.
   • (Facultatif) : Dans le champ Description, saisissez une description de la ressource de connexion.
   • Dans le champ ID d'instance Cloud SQL, saisissez le nom complet de l'instance Cloud SQL, généralement au format project-id:location-id:instance-id. Vous pouvez trouver l'ID d'instance sur la page des détails de l'instance Cloud SQL que vous souhaitez interroger.
   • Dans le champ Nom de la base de données, saisissez le nom de la base de données.
   • Comme Nom d'utilisateur, saisissez le nom d'utilisateur de la base de données.

   • Dans le champ Mot de passe, renseignez le mot de passe d'accès à la base de données.

     • (Facultatif) Cochez la case Afficher le mot de passe pour révéler le mot de passe.

     

4. Cliquez sur Créer une connexion.

Ligne de commande

Saisissez la commande bq mk, puis indiquez l'option de connexion --connection. Les paramètres suivants sont également requis :

• --connection_type
• --properties
• --connection_credential
• --project_id
• --location

• (nom de la connexion)

  bq mk --connection --connection_type='CLOUD_SQL' --properties=[PROPERTIES] --connection_credential=[CREDENTIALS] --project_id=[PROJECT_ID] --location=[LOCATION] new_connection
  

Où :

• --connection_type est toujours CLOUD_SQL.
• --properties contient les paramètres de la connexion créée au format JSON. Par exemple : --properties='{"param":"param_value"}'. Pour créer une ressource de connexion, vous devez fournir les paramètres instanceID, database et type. Les paramètres friendly_name et description sont facultatifs.
• --connection_credential doit contenir les paramètres username et password.
• --project_id est l'ID de votre projet.
• --location est la région dans laquelle se trouve votre instance Cloud SQL.
• Renseignez un nom pour identifier la connexion, en utilisant uniquement des lettres, des chiffres et des traits de soulignement.

Par exemple, la commande suivante crée une ressource de connexion nommée "my_new_connection" (nom descriptif : "My new connection") dans un projet ayant l'ID federation-test.

bq mk --connection --connection_type='CLOUD_SQL' --properties='{"instanceId":"federation-test:us-central1:mytestsql","database":"mydatabase","type":"MYSQL"}' --connection_credential='{"username":"myusername", "password":"mypassword"}' --project_id=federation-test --location=us my_new_connection

API

Utilisez la méthode projects.locations.transferConfigs.create et fournissez une instance de la ressource TransferConfig.

Afficher les ressources de connexion

Console

1. Pour afficher l'état de vos ressources de connexion, accédez à l'UI Web de BigQuery.

   Accéder à l'UI Web de BigQuery

2. Les ressources de connexion sont répertoriées au niveau supérieur de votre projet, sous un regroupement intitulé External connections (Connexions externes).

3. Cliquez sur une connexion pour afficher des informations sur cette ressource de connexion, telles que connection ID et Cloud SQL instance ID.

   

Ligne de commande

Saisissez la commande bq show, puis indiquez l'option de connexion --connection. Le nom connection_id sous forme complète est obligatoire.

    bq show --connection project.location.connection_id

Par exemple, la commande suivante crée une ressource de connexion nommée my_new_connection dans un projet ayant l'ID federation-test, situé dans la région us.

    bq show --connection federation-test:us.my_new_connection

API

Utilisez la méthode projects.locations.connections.list et indiquez une instance de la ressource list. Consultez la section de la documentation de référence consacrée à l'API REST.

Accorder des autorisations à un autre utilisateur

Pour qu'un autre utilisateur puisse utiliser la ressource de connexion pour les requêtes fédérées Cloud SQL, l'utilisateur bigquery.admin doit accorder le rôle suivant dans IAM : BigQuery Connection User. Ce rôle IAM inclut les autorisations suivantes :

• bigquery.connections.get
• bigquery.connections.list
• bigquery.connections.use
• bigquery.connections.getIamPolicy

L'utilisateur bigquery.admin peut également attribuer à d'autres utilisateurs un rôle différent, appelé BigQuery Connection Admin, qui inclut les mêmes autorisations que BigQuery Connection User ainsi que des autorisations supplémentaires permettant de créer, mettre à jour et supprimer des connexions existantes, ainsi que de définir une stratégie IAM sur les connexions.

• bigquery.connections.create
• bigquery.connections.update
• bigquery.connections.setIamPolicy
• bigquery.connections.delete

Tarifs

Lorsque vous interrogez Cloud SQL depuis BigQuery, vous êtes facturé sur la base du nombre d'octets lus par la requête. Pour plus d'informations, consultez la section Tarifs des requêtes. Aucuns frais supplémentaires ou quotas ne sont appliqués aux requêtes fédérées Cloud SQL pendant la phase bêta.

Référence

Afficher un schéma de table Cloud SQL

Vous pouvez utiliser la fonction EXTERNAL_QUERY() pour interroger les tables "information_schema" afin d'accéder aux métadonnées de la base de données, par exemple pour répertorier l'ensemble des tables de la base de données ou afficher le schéma d'une table. Les exemples de requête "information_schema" suivants fonctionnent à la fois avec MySQL et PostgreSQL. Pour en savoir plus, consultez les pages concernant les tables "information_schema" dans MySQL et les tables "information_schema" dans PostgreSQL.

// List all tables in a database
SELECT * FROM EXTERNAL_QUERY("connection_id",
"select * from information_schema.tables;");

// List all columns in a table.
SELECT * FROM EXTERNAL_QUERY("connection_id",
"select * from information_schema.columns where table_name='x';");

Détails de la ressource de connexion

Nom de propriété	Valeur	Description
name	chaîne	Nom de la ressource de connexion au format : project_id.location_id.connection_id.
location	chaîne	Emplacement de la connexion, identique à l'emplacement de l'instance Cloud SQL, à quelques exceptions près : Cloud SQL us-central1 est mappé sur BigQuery US, tandis que Cloud SQL europe-west1 est mappé sur BigQuery EU.
friendlyName	chaîne	Nom d'affichage facile à lire pour la connexion.
description	chaîne	Description de la connexion.
cloudSql.type	chaîne	Valeurs possibles : "POSTGRES" ou "MYSQL".
cloudSql.instanceId	chaîne	Nom de l'instance Cloud SQL, généralement au format : Project-id:location-id:instance-id Vous pouvez trouver l'ID de l'instance sur la page de détails de l'instance Cloud SQL.
cloudSql.database	chaîne	Base de données Cloud SQL à laquelle vous souhaitez vous connecter.

Détails de la ressource des identifiants de connexion

Nom de propriété	Valeur	Description
username	chaîne	Nom d'utilisateur de la base de données
password	chaîne	Mot de passe de la base de données

Mappages des types de données

Lorsque vous exécutez une requête fédérée Cloud SQL, les données de Cloud SQL (qui possèdent des types de données MySQL ou PostgreSQL) sont converties vers les types SQL standards de BigQuery. Vous trouverez ci-dessous les mappages des types de données de MySQL vers BigQuery et de PostgreSQL vers BigQuery.

Voici quelques points à retenir concernant ces mappages :

• La plupart des types de données MySQL peuvent être mis en correspondance avec le même type de données BigQuery, à quelques exceptions près, telles que decimal, timestamp et time.
• PostgreSQL accepte de nombreux types de données non standards, qui ne sont pas gérés dans BigQuery, par exemple money,path, uuid, boxer, etc.
• La plage de valeurs numériques de BigQuery est moins étendue que celles de MySQL et PostgreSQL.

Traiter les erreurs

Si votre requête externe contient un type de données non géré dans BigQuery, la requête échoue immédiatement. Vous pouvez convertir le type de données non géré vers un autre type de données MySQL/PostgreSQL compatible. Pour plus d'informations sur le casting, consultez la section Types de données non compatibles dans la section Dépannage.

Mappage des types MySQL vers les types BigQuery

Type MySQL	Description pour MySQL	Type BigQuery	Différence entre les types
Entier
ENT	4 octets, 2^32 - 1	INT64
TINYINT	1 octet, 2^8 - 1	INT64
SMALLINT	2 octets, 2^16 - 1	INT64
MEDIUMINT	3 octets, 2^24 - 1	INT64
BIGINT	8 octets, 2^64 - 1	INT64
UNSIGNED BIGINT	8 octets, 2^64 - 1	NUMERIC
Valeurs numériques exactes
DECIMAL (M,D)	Un nombre décimal représenté par (M,D), où M est le nombre total de chiffres avant la virgule et D le nombre de décimales. M <= 65	NUMERIC	La plage de valeurs NUMERIC de BigQuery est moins étendue et ne gère que 38 chiffres décimaux de précision et 9 chiffres décimaux d'échelle.
Valeurs numériques approchées
FLOAT (M,D)	4 octets, M <= 23	FLOAT64
DOUBLE (M,D)	8 octets, M <= 53	FLOAT64
Date et heure
TIMESTAMP	De '1970-01-01 00:00:01'UTC à ' 2038-01-19 03:14:07'UTC	TIMESTAMP	Une valeur TIMESTAMP de MySQL est récupérée au fuseau horaire UTC, quelle que soit l'origine de l'appel BigQuery.
DATETIME	De '1000-01-01 00:00:00' à '9999-12-31 23:59:59'	DATETIME
DATE	De '1000-01-01' à '9999-12-31'	DATE
TIME	Heure au format "HH:MM:SS" De "-838:59:59" à "838:59:59"	TIME	La plage de valeurs TIME de BigQuery est moins étendue, de 00:00:00 à 23:59:59.
ANNÉE		INT64
Caractères et chaînes de caractères
ENUM	Objet chaîne ayant une valeur sélectionnée parmi une liste de valeurs autorisées	STRING
CHAR (M)	Chaîne de longueur fixe comprise entre 1 et 255 caractères	STRING
VARCHAR (M)	Chaîne de longueur variable comprise entre 1 et 255 caractères	STRING
TEXT	Champ d'une longueur maximale de 65 535 caractères	STRING
TINYTEXT	Colonne TEXT d'une longueur maximale de 255 caractères	STRING
MEDIUMTEXT	Colonne TEXT d'une longueur maximale de 16 777 215 caractères	STRING
LONGTEXT	Colonne TEXT d'une longueur maximale de 4 294 967 295 caractères	STRING
Binary
Blob	Objet binaire de grande taille (Binary Large Object) d'une longueur maximale de 65 535 caractères	BYTE
MEDIUM_BLOB	BLOB d'une longueur maximale de 16 777 215 caractères	BYTE
LONG_BLOB	BLOB d'une longueur maximale de 4 294 967 295 caractères	BYTE
TINY_BLOB	BLOB d'une longueur maximale de 255 caractères	BYTE
Autre
SET	Lors de la déclaration d'une colonne SET, prédéfinissez certaines valeurs, puis insérez (INSERT) dans cette colonne tout ensemble de valeurs prédéfinies	STRING
GEOMETRY		GEOMETRY	PAS ENCORE COMPATIBLE
BIT		INT64	PAS ENCORE COMPATIBLE

Mappage des types PostgreSQL vers les types BigQuery

Nom	Description	Type BigQuery	Différence entre les types
Entier
smallint	2 octets, de -32 768 à +32 767	INT64
smallserial	Voir smallint	INT64
Entier	4 octets, de -2 147 483 648 à [phone]	INT64
serial	Voir integer	INT64
bigint	8 octets, de -9 223 372 036 854 775 808 à 9 223 372 036 854 775 807	INT64
bigserial	Voir bigint	INT64
Valeurs numériques exactes
numeric [ (p, s) ]	Précision jusqu'à 1 000	NUMERIC	La plage de valeurs NUMERIC de BigQuery est moins étendue et ne gère que 38 chiffres décimaux de précision et 9 chiffres décimaux d'échelle.
Decimal [ (p, s) ]	Voir numeric	NUMERIC	Voir numeric
argent	8 octets, 2 chiffres décimaux d'échelle, de -92 233 720 368 547 758.08 à [phone] 758.07	NON COMPATIBLE
Valeurs numériques approchées
real	4 octets, nombre à virgule flottante à simple précision	FLOAT64
double precision	8 octets, nombre à virgule flottante à double précision	FLOAT64
Date et heure
date	Date du calendrier (année, mois, jour)	DATE
time [ (p) ] [ sans fuseau horaire ]	Heure de la journée (sans fuseau horaire)	TIME
time [ (p) ] avec fuseau horaire	Heure de la journée, fuseau horaire compris	NON COMPATIBLE
timestamp [ (p) ] [ sans fuseau horaire ]	Date et heure (sans fuseau horaire)	DATETIME
timestamp [ (p) ] avec fuseau horaire	Date et heure, fuseau horaire compris	TIMESTAMP	Une valeur TIMESTAMP de PostGreSQL est récupérée au fuseau horaire UTC, quelle que soit l'origine de l'appel BigQuery.
interval	Durée	NON COMPATIBLE
Caractères et chaînes de caractères
character [ (n) ]	Chaîne de caractères de longueur fixe	STRING
character varying [ (n) ]	Chaîne de caractères de longueur variable	STRING
text	Chaîne de caractères de longueur variable	STRING
Binary
bytea	Données binaires ("tableau d'octets")	BYTES
bit [ (n) ]	Chaîne de bits de longueur fixe	BYTES
bit varying [ (n) ]	Chaîne de bits de longueur variable	BYTES
Autre
booléen	Valeur logique booléenne (true/false)	BOOL
inet	Adresse d'hôte, au format IPv4 ou IPv6	NON COMPATIBLE
path	Chemin géométrique dans un plan	NON COMPATIBLE
pg_lsn	Numéro de séquence de journal PostgreSQL	NON COMPATIBLE
point	Point géométrique dans un plan	NON COMPATIBLE
polygon	Chemin géométrique fermé dans un plan	NON COMPATIBLE
tsquery	Requête de recherche de texte	NON COMPATIBLE
tsvector	Document de recherche de texte	NON COMPATIBLE
txid_snapshot	Instantané d'ID de transaction au niveau utilisateur	NON COMPATIBLE
uuid	identifiant universel unique	NON COMPATIBLE
xml	Données XML	STRING
box	Cadre rectangulaire dans un plan	NON COMPATIBLE
cidr	Adresse réseau, au format IPv4 ou IPv6	NON COMPATIBLE
cercle	Cercle dans un plan	NON COMPATIBLE
interval [ fields ] [ (p) ]	Intervalle de temps	NON COMPATIBLE
json	Données JSON textuelles	STRING
jsonb	Données JSON binaires, décomposées	NON COMPATIBLE
line	Ligne infinie dans un plan	NON COMPATIBLE
lseg	Segment dans un plan	NON COMPATIBLE
macaddr	Adresse MAC (Media Access Control)	NON COMPATIBLE
macaddr8	Adresse MAC (Media Access Control) (format EUI-64)	NON COMPATIBLE

Limites et problèmes connus

Régions

Les requêtes fédérées Cloud SQL ne sont possibles que dans les régions gérant à la fois Cloud SQL et BigQuery. (La fédération de requêtes est possible dans toutes les régions BigQuery, mais pas dans toutes les régions Cloud SQL.)

Vous pouvez exécuter une requête fédérée sur plusieurs régions, selon les règles suivantes.

Emplacements multirégionaux

Un emplacement BigQuery multirégional peut interroger n'importe quelle région Cloud SQL située au même emplacement (États-Unis, Europe). Exemple :

• Les emplacements BigQuery multirégionaux US peuvent interroger les emplacements Cloud SQL us-central1, us-east4, us-west2, etc.
• L'emplacement BigQuery multirégional EU peut interroger les emplacements Cloud SQL europe-north1, europe-west2, etc.

Régions uniques

Une région unique BigQuery peut interroger Cloud SQL uniquement dans la même région. Exemple :

• La région BigQuery us-east4 peut uniquement interroger la région Cloud SQL us-east4.

Cloud SQL est disponible dans plus de régions que BigQuery. Consultez le tableau suivant pour obtenir un mappage détaillé des régions disponibles pour chaque produit.

Région Cloud SQL	Région/Emplacement multirégional BigQuery
northamerica-northeast1	US / Northamerica-northeast1
us-central	NON COMPATIBLE : dans cette région, les instances Cloud SQL sont en V1. Les requêtes fédérées ne sont compatibles qu'avec les instances V2.
us-central1	US
us-east1	US / us-east1
us-east4	US / us-east4
us-west1	NON COMPATIBLE
us-west2	US / us-west2
southamerica-east1	southamerica-east1
europe-north1	EU / europe-north1
europe-west1	EU
europe-west2	EU / europe-west2
europe-west3	NON COMPATIBLE
europe-west4	NON COMPATIBLE
europe-west6	EU / europe-west6
asia-east1	asia-east1
asia-east2	asia-east2
asia-northeast1	asia-northeast1
asia-south1	asia-south1
asia-southeast1	asia-southeast1
australia-southeast1	australia-southeast1

Attention : Bien que les requêtes fédérées entre régions soient compatibles, les performances varient en fonction de la proximité. Par exemple, comme l'emplacement BigQuery multirégional US est proche de la région us-central1, une requête fédérée entre ces deux régions est rapide. Cependant, si vous exécutez la même requête de BigQuery US vers Cloud SQL us-east4, les performances risquent d'être considérablement ralenties.

Quotas et autres limites

• Performances : une requête fédérée ne sera probablement pas aussi rapide qu'une requête sur le stockage BigQuery. BigQuery doit attendre que la base de données source exécute la requête externe et déplace les données de façon temporaire de Cloud SQL vers BigQuery. Les bases de données sources telles que MySQL ou PostgreSQL ne sont généralement pas optimisées pour des requêtes analytiques complexes.
• Quotas : les utilisateurs doivent contrôler les quotas de requêtes dans Cloud SQL. Il n'y a pas de paramètres de quotas distincts pour les requêtes fédérées. Pour isoler la charge de travail, il est recommandé de n'interroger qu'une instance dupliquée de base de données avec accès en lecture.
• Nombre maximal d'octets facturés autorisé : ce champ n'est pour le moment pas disponible dans le cadre des requêtes fédérées. À l'heure actuelle, il n'est pas possible de calculer les octets facturés avant l'exécution effective des requêtes fédérées.
• Instances Cloud SQL limitées : les requêtes fédérées ne sont acceptées que par les instances Cloud SQL v2 avec adresses IP publiques (par opposition aux adresses IP privées).
• Les requêtes fédérées sont soumises aux quotas et limites appliquées à Cloud SQL MySQL et PostgreSQL.
• Nombre de connexions : une requête fédérée peut compter au plus 10 connexions uniques.

Dépannage

Cette section est conçue pour vous aider à résoudre les problèmes les plus courants rencontrés lors de l'établissement d'une connexion. Elle n'inclut pas tous les messages d'erreur ou problèmes possibles.

Problèmes d'ordre général

Lors du diagnostic des problèmes de connexion généraux, vérifiez les points suivants :

• Vérifiez que vous avez bien effectué pour votre connexion toutes les étapes de la section "Avant de commencer" de la page de documentation.
• Les propriétés de configuration de la connexion sont correctes.

Si votre configuration de connexion est correcte et que les autorisations appropriées ont été accordées, reportez-vous aux éléments ci-dessous pour obtenir des solutions aux problèmes les plus courants.

Problème : BigQuery et Cloud SQL ne sont pas co-localisés.

Solution : Les requêtes fédérées Cloud SQL ne sont possibles que dans les régions acceptant à la fois Cloud SQL et BigQuery. L'ensemble de données BigQuery et l'instance Cloud SQL doivent se trouver dans la même région, ou au même emplacement si l'ensemble de données se trouve dans un emplacement multirégional tel que US ou EU. Pour en savoir plus sur les régions, consultez la section Limites et problèmes connus.

Problème : les performances sont plus lentes que prévu.

Solution : Les requêtes fédérées ne sont pas aussi performantes que les requêtes sur des données stockées dans BigQuery, car elles doivent interroger Cloud SQL en externe, renvoyer les données dans une table BigQuery temporaire, mapper les données avec le type de données BigQuery, puis exécuter la requête dans BigQuery. Bien que les performances des requêtes fédérées soient inférieures, l'avantage est que les données n'ont pas besoin d'être à nouveau copiées, déplacées ou stockées.

Problème : quel format utiliser pour le nom de la connexion ?

Solution : Le nom de la connexion doit inclure le projet, l'emplacement et l'identifiant de connexion connection_id. Le nom de la connexion doit suivre ce modèle : project_id.location_id.connection_id Exemple : federation-test.us.my_new_connection

Types de données non compatibles

Si votre requête externe contient un type de données non géré dans BigQuery, la requête échoue immédiatement. Vous pouvez convertir le type de données non géré vers un autre type de données MySQL/PostgreSQL compatible.

• Type de données MySQL non compatible

  • Message d'erreur : Invalid table-valued function external_query Found unsupported MySQL type in BigQuery. at [1:15]
  • Types non compatibles : GEOMETRY, BIT
  • Solution : Convertissez le type de données non compatible en STRING.
  • Exemple : SELECT ST_AsText(ST_GeomFromText('POINT(1 1)')); Cette commande convertit le type de données GEOMETRY, non compatible, en STRING.

• Type de données PostgreSQL non compatible

  • Message d'erreur : Invalid table-valued function external_query Postgres type (OID = 790) is not supported now at [1:15]
  • Types non compatibles : money, time with time zone, inet, path, pg_lsn, point, polygon, tsquery, tsvector, txid_snapshot, uuid, box, cidr, circle, interval, jsonb, line, lseg, macaddr, macaddr8
  • Solution : Convertissez le type de données non compatible en STRING.
  • Exemple : SELECT CAST('12.34'::float8::numeric::money AS varchar(30)); Cette commande convertit le type de données money, non compatible, en string.