Cette page explique comment interroger des données dans BigQuery et Cloud SQL grâce à une requête fédérée.
Aperçu
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 avec les instances MySQL (deuxième génération) aussi bien 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()
.
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 est uniquement disponible dans le langage SQL standard de BigQuery.
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 :
- Grâce à la fonction
EXTERNAL_QUERY()
, exécution de la requête externeSELECT customer_id, MIN(order_date) AS first_order_date FROM orders GROUP BY customer_id
dans la base de données opérationnelle PostgreSQL afin d'obtenir la date de première commande pour chaque client. - Jointure par
customer_id
de la table des résultats de la requête externe avec la table des clients dans BigQuery. - 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 ordonne 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 IAM géré par GCP est automatiquement créé pour vous. 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 |
Permissions
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 attribuer le rôle bigquery.admin
, procédez comme suit :
Console
Ouvrez la page Cloud IAM dans la console GCP.
Cliquez sur Sélectionner un projet.
Sélectionnez un projet et cliquez sur Ouvrir.
Cliquez sur Ajouter pour ajouter de nouveaux membres au projet et définir leurs autorisations.
Dans la boîte de dialogue Add members (Ajouter des membres) :
- Dans le champ Members (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 > BigQuery Admin (Administrateur BigQuery).
Cliquez sur Add (Ajouter).
CLI
Vous pouvez utiliser l'outil de ligne de commande gcloud pour accorder le rôle bigquery.admin
à un utilisateur ou à un groupe.
Pour ajouter une liaison unique à la stratégie Cloud IAM de votre projet, saisissez la commande suivante. Pour ajouter un utilisateur, fournissez l'indicateur --member
au format user:user@example.com
. Pour ajouter un groupe, fournissez l'indicateur --member
au format group:group@example.com
.
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
, soituser
. - address est l'adresse e-mail de l'utilisateur ou du groupe.
Exemple :
gcloud projects add-iam-policy-binding myproject \
--member group:group@example.com \
--role roles/bigquery.admin
La commande génère la stratégie mise à jour :
bindings: - members: - group:group@example.com 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.
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
Pour créer une ressource de connexion, accédez à l'UI Web de BigQuery dans la console GCP.
Sous Add data (Ajouter des données), sélectionnez Create connection (Créer une connexion) depuis le menu.
Dans le volet Create connection (Créer une connexion) :
- Dans le champ Connection type (Type de connexion), sélectionnez MySQL ou PostgresSQL.
- Dans le champ Connection ID (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 Connection location (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 Friendly name (Nom descriptif), saisissez un nom facile à lire 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 Cloud SQL instance ID (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 Database name (Nom de la base de données), saisissez le nom de la base de données.
- Comme Username (Nom d'utilisateur), saisissez le nom d'utilisateur de la base de données.
Dans le champ Password (Mot de passe), renseignez le mot de passe d'accès à la base de données.
- (Facultatif) Cochez la case Show password (Afficher le mot de passe) pour révéler le mot de passe.
Cliquez sur Create connection (Créer une connexion).
Ligne de commande
Saisissez la commande bq mk
et fournissez l'indicateur 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 toujoursCLOUD_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ètresinstanceID
,database
ettype
. Les paramètresfriendly_name
etdescription
sont facultatifs.--connection_credential
doit contenir les paramètresusername
etpassword
.--project_id
est l'ID du 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 nouvelle ressource de connexion nommée my_new_connection (nom descriptif : "My new connection") au sein du projet d'identifiant 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
Exécutez la méthode projects.locations.transferConfigs.create
et indiquez une instance de la ressource TransferConfig
.
Afficher les ressources de connexion
Console
Pour afficher l'état de vos ressources de connexion, accédez à l'UI Web de BigQuery.
Les ressources de connexion sont répertoriées au niveau supérieur de votre projet, sous un regroupement intitulé External connections (Connexions externes).
Cliquez sur une connexion pour afficher les informations relatives à cette ressource, telles que ses identifiants
connection ID
etCloud SQL instance ID
.
Ligne de commande
Saisissez la commande bq show
et fournissez l'indicateur 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 nouvelle ressource de connexion nommée my_new_connection
dans un projet d'identifiant 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 fournissez une instance de la ressource de connexion 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 soit en mesure d'utiliser la ressource de connexion dans le cadre de requêtes fédérées Cloud SQL, l'utilisateur bigquery.admin
doit attribuer 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 pour les connexions.
bigquery.connections.create
bigquery.connections.update
bigquery.connections.setIamPolicy
bigquery.connections.delete
Prix
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. Vous pouvez en apprendre davantage sur 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 mappés sur le même type de données BigQuery, à quelques exceptions près, telles que
decimal
,timestamp
ettime
. - 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 la conversion, 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 | |
Binaire | |||
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 PostgresSQL 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 à +2 147 483 647 | 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 à +92 233 720 368 547 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 | |
Binaire | |||
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.
Bien que, dans le cadre de cette version bêta, BigQuery et Cloud SQL soient disponibles dans les mêmes régions, certaines régions ne sont pas gérées. Pour un mappage détaillé, veuillez vous référer au tableau ci-dessous.
Région Cloud SQL | Région/Emplacement multi-régional BigQuery |
---|---|
northamerica-northeast1 | US / Northamerica-northeast1 |
us-central | NON COMPATIBLE : dans cette région, les instances Cloud SQL sont en V1. La requête fédérée est uniquement compatible avec les instances V2. |
us-central1 | US |
us-east1 | NON COMPATIBLE |
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 |
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 source 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 associée, il est recommandé d'interroger uniquement une instance dupliquée en lecture seule.
- Nombre maximal d'octets facturés autorisé : ce champ n'est pour le moment pas géré dans le cadre des requêtes fédérées. Il n'est à l'heure actuelle 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 géré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 limitations appliqués à 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 vise à vous aider à résoudre les problèmes les plus courants rencontrés lors de l'établissement d'une connexion. Cette section 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 vers Cloud SQL ne sont possibles que dans les régions gérant à 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
ouEU
. Reportez-vous à la section Limites et problèmes connus pour plus d'informations sur les régions. - 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 vers les types 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éesGEOMETRY
, non géré, enSTRING
.
- Message d'erreur :
Type de données PostgresSQL 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éesmoney
, non géré, enstring
.
- Message d'erreur :