Introduzione alle query federate

Questa pagina illustra come utilizzare le query federate e fornisce indicazioni sull'esecuzione di query sui dati di Spanner e Cloud SQL da BigQuery.

Le query federate consentono di inviare un'istruzione di query ai database Spanner o Cloud SQL e di restituire il risultato come tabella temporanea. Le query federate utilizzano l'API BigQuery Connection per stabilire una connessione con Spanner o Cloud SQL. Nella query, utilizzerai la funzione EXTERNAL_QUERY per inviare un'istruzione di query al database esterno, utilizzando il dialetto SQL di quel database. I risultati vengono convertiti in tipi di dati GoogleSQL.

Datastore supportati

Puoi utilizzare le query federate con i seguenti datastore:

Flusso di lavoro

  • Identifica il progetto Google Cloud che include l'origine dati su cui vuoi eseguire una query.
  • Un utente bigquery.admin crea una risorsa di connessione in BigQuery.
  • L'utente amministratore concede l'autorizzazione a utilizzare la risorsa di connessione all'utente B.
    • Se l'amministratore e l'utente B sono la stessa persona, non è necessario concedere l'autorizzazione.
  • L'utente B scrive una query in BigQuery con la nuova funzione SQL EXTERNAL_QUERY.

Aree geografiche supportate

Le query federate sono supportate solo nelle regioni che supportano sia l'origine dati esterna sia BigQuery. Per un elenco delle località supportate, consulta le seguenti sezioni:

Puoi creare una connessione ed eseguire una query federata tra regioni in base alle seguenti regole:

Singole regioni

Una singola regione BigQuery può eseguire query solo su una risorsa nella stessa regione.

Ad esempio, se il tuo set di dati si trova in us-east4, puoi eseguire query sulle istanze Cloud SQL o sui database Spanner che si trovano solo in us-east4. La località di elaborazione delle query è la regione singola di BigQuery.

Più regioni

Una multiregione BigQuery può eseguire query su qualsiasi regione di origine dati nella stessa vasta area geografica (Stati Uniti, UE). Le località in più regioni non sono disponibili per le istanze Cloud SQL perché vengono utilizzate solo per i backup. Una multiregione BigQuery può eseguire query su un'istanza di Spanner nella stessa multiregione.

  • Una query eseguita nella località multiregionale degli Stati Uniti di BigQuery può eseguire query su qualsiasi singola regione dell'area geografica degli Stati Uniti, ad esempio us-central1, us-east4 o us-west2.

  • Una query eseguita nella località multiregionale dell'UE di BigQuery può eseguire query su qualsiasi singola regione degli stati membri dell'Unione Europea, ad esempio europe-north1 o europe-west3.

  • La località in cui viene eseguita la query deve corrispondere a quella della risorsa di connessione. Ad esempio, le query eseguite da più regioni degli Stati Uniti devono utilizzare una connessione situata nella località multiregionale degli Stati Uniti.

Le prestazioni delle query variano in base alla vicinanza tra il set di dati e l'origine dati esterna. Ad esempio, una query federata tra un set di dati nella località multiregionale degli Stati Uniti e un'istanza Cloud SQL in us-central1 è rapida. Tuttavia, se esegui la stessa query tra la località multiregionale degli Stati Uniti e un'istanza Cloud SQL in us-east4, le prestazioni potrebbero risultare inferiori.

La località di elaborazione delle query è la località a più regioni, ovvero US o EU.

Mappature dei tipi di dati

Quando esegui una query federata, i dati dell'origine dati esterna vengono convertiti in tipi GoogleSQL. Per maggiori informazioni, consulta Query federate di Cloud SQL.

Quote e limiti

  • Query federate tra regioni: se la località di elaborazione delle query BigQuery e quella dell'origine dati esterna sono diverse, si tratta di una query interregionale. Puoi eseguire fino a 1 TB di query tra regioni per progetto al giorno. Di seguito è riportato un esempio di query tra regioni.
    • L'istanza Cloud SQL si trova in us-west1, mentre la connessione a BigQuery si trova nella località multiregionale degli Stati Uniti. La località di elaborazione della query BigQuery è US.
  • Quota: gli utenti devono controllare la quota di query nell'origine dati esterna, come Cloud SQL. Non sono previste impostazioni di quota aggiuntive per le query federate. Per ottenere l'isolamento dei carichi di lavoro, si consiglia di eseguire query solo su una replica di lettura del database.
  • Numero massimo di byte fatturati: questo campo non è attualmente supportato per le query federate. Al momento non è possibile calcolare i byte fatturati prima di eseguire effettivamente le query federate.
  • Numero di connessioni: una query federata può avere al massimo 10 connessioni univoche.
  • Si applicano le quote e le limitazioni di Cloud SQL MySQL e PostgreSQL.

Limitazioni

Le query federate sono soggette alle seguenti limitazioni:

  • Prestazioni. È probabile che una query federata non sia così veloce come l'esecuzione di query solo sullo spazio di archiviazione di BigQuery. BigQuery deve attendere che il database di origine esegua la query esterna e sposti temporaneamente i dati dall'origine dati esterna a BigQuery. Inoltre, il database di origine potrebbe non essere ottimizzato per query analitiche complesse.

    Le prestazioni delle query variano anche in base alla vicinanza tra il set di dati e l'origine dati esterna. Per ulteriori informazioni, consulta Regioni supportate.

  • Le query federate sono di sola lettura. La query esterna eseguita nel database di origine deve essere di sola lettura. Pertanto, le istruzioni DML o DDL non sono supportate.

  • Tipi di dati non supportati. Se la query esterna contiene un tipo di dati non supportato in BigQuery, la query avrà esito negativo immediatamente. Puoi trasmettere il tipo di dati non supportato a un tipo di dati supportato diverso.

  • Progetto. Devi creare la risorsa di connessione nello stesso progetto dell'istanza Cloud SQL.

Prezzi

  • Se utilizzi il modello di prezzi on demand, ti viene addebitato il numero di byte restituiti dalla query esterna durante l'esecuzione di query federate da BigQuery. Per ulteriori informazioni, vedi Prezzi dell'analisi on demand.

  • Se utilizzi le versioni di BigQuery, l'addebito avviene in base al numero di slot utilizzati. Per ulteriori informazioni, consulta i prezzi di calcolo della capacità.

Push-down SQL

Le query federate sono soggette alla tecnica di ottimizzazione nota come push-down SQL. Migliorano le prestazioni di una query delegando operazioni come il filtro verso l'origine dati esterna invece di eseguirle in BigQuery. La riduzione della quantità di dati trasferiti dall'origine dati esterna può ridurre i tempi di esecuzione delle query e i costi. Le push-down SQL includono l'eliminazione delle colonne (SELECT clausole) e il filtro push-down (WHERE clausole).

Quando utilizzi la funzione EXTERNAL_QUERY, le push-down SQL funzionano riscrivendo la query originale. Nell'esempio seguente, la funzione EXTERNAL_QUERY viene utilizzata per comunicare con un database Cloud SQL:

SELECT COUNT(*)
FROM (
  SELECT * FROM EXTERNAL_QUERY("<connection>", "select * from operations_table")
  )
WHERE a = 'Y' AND b NOT IN ('COMPLETE','CANCELLED');

Senza le push-down SQL, la query seguente viene inviata a Cloud SQL:

SELECT *
FROM operations_table

Quando viene eseguita questa query, l'intera tabella viene inviata a BigQuery, anche se sono necessarie solo alcune righe e colonne.

Con le push-down SQL, la query seguente viene inviata a Cloud SQL:

SELECT `a`, `b`
FROM (
  SELECT * FROM operations_table) t
WHERE ((`a` = 'Y') AND (NOT `b` IN ('COMPLETE', 'CANCELLED'))

Quando questa query viene eseguita, solo due colonne e le righe che corrispondono al predicato di filtro vengono inviate nuovamente a BigQuery.

Puoi esaminare le eventuali push-down applicate nel piano di query.

Limitazioni

  • Le push-down SQL vengono applicate solo alle query federate nel formato SELECT * FROM T.
  • Sono supportati solo l'eliminazione delle colonne e i filtri push-down. I push-down di calcolo, join e aggregazione non sono supportati.
  • Per i filtri push-down, i valori letterali devono essere di uno dei seguenti tipi: BOOL, INT64, FLOAT64, STRING, DATE, DATETIME, TIMESTAMP. I valori letterali che sono struct o array non sono supportati.
  • Le push-down SQL sono supportate solo per Cloud SQL e Spanner. Le push-down SQL non sono supportate per SAP DataSphere.

Funzioni supportate per origine dati

Di seguito sono riportate le funzioni SQL supportate per origine dati. Nessuna funzione è supportata per SAP DataSphere.

MySQL Cloud SQL

  • Operatori logici: AND, OR, NOT.
  • Operatori di confronto: =, >, >=, <, <=, <>, IN, BETWEEN, IS NULL.
  • Operatori aritmetici: +, -, * (solo per INT64 e FLOAT64).

Funzioni supportate da Cloud SQL PostgreSQL

  • Operatori logici: AND, OR, NOT.
  • Operatori di confronto: =, >, >=, <, <=, <>, IN, BETWEEN, IS NULL.
  • Operatori aritmetici: +, -, *, / (solo per i tipi INT64, FLOAT64 e DATE, tranne la sottrazione di DATE).

Spanner - Dialetto PostgreSQL

  • Operatori logici: AND, OR, NOT.
  • Operatori di confronto: =, >, >=, <, <=, <>, IN, BETWEEN, IS NULL.
  • Operatori aritmetici: +, -, *, / (solo per INT64, FLOAT64, NUMERIC).

Spanner: dialetto GoogleSQL

Il dialetto GoogleSQL supporta le stesse funzioni del dialetto PostgreSQL e inoltre:

  • Operatori aritmetici sicuri: SAFE_ADD, SAFE_SUBTRACT, SAFE_MULTIPLY, SAFE_DIVIDE (solo per INT64, FLOAT64, NUMERIC).

Passaggi successivi