Introduzione alle query federate

Questa pagina spiega come utilizzare le query federate e fornisce indicazioni su come eseguire query sui dati di Spanner, AlloyDB e Cloud SQL da BigQuery.

Le query federate ti consentono di inviare un'istruzione di query ai database AlloyDB, Spanner o Cloud SQL e ottenere il risultato come tabella temporanea. Le query federate utilizzano l'API BigQuery Connection per stabilire una connessione con AlloyDB, 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 query federate con i seguenti datastore:

Flusso di lavoro

  • Identifica il progetto Google Cloud che include l'origine dati su cui vuoi eseguire la query.
  • Un utente bigquery.admin crea una risorsa di connessione in BigQuery.
  • L'utente amministratore concede l'autorizzazione per 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 su una risorsa solo nella stessa regione.

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

Più regioni

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

  • Una query eseguita nell'area 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 in una 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 essere uguale a quella della risorsa di connessione. Ad esempio, le query eseguite dalla località multiregionale 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 essere inferiori.

La località di elaborazione query è la località multiregionale, 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 ulteriori informazioni, consulta Query federate di Cloud SQL.

Quote e limiti

  • Query federate tra regioni. Se la località di elaborazione delle query BigQuery e la località dell'origine dati esterna sono diverse, si tratta di una query tra regioni. 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 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 o AlloyDB. Non sono previste ulteriori impostazioni di quota per l'esecuzione di query federate. Per ottenere l'isolamento dei carichi di lavoro, ti consigliamo di eseguire una query solo su una replica di lettura del database.
  • Numero massimo di byte fatturati consentiti. Questo campo non è supportato per le query federate. 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.
  • Cloud SQL MySQL e PostgreSQL. Si applicano quote e limitazioni.

Limitazioni

Le query federate sono soggette alle seguenti limitazioni:

  • Prestazioni. È probabile che una query federata non sia veloce quanto 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 le query analitiche complesse.

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

  • Le query federate sono di sola lettura. La query esterna eseguita nel database di origine deve essere di sola lettura. Di conseguenza, 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 non viene eseguita immediatamente. Puoi trasmettere il tipo di dati non supportato a un altro tipo di dati supportato.

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

Prezzi

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

  • Se utilizzi le versioni di BigQuery, gli addebiti vengono effettuati in base al numero di slot utilizzati. Per ulteriori informazioni, vedi 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 l'applicazione di filtri all'origine dati esterna anziché 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 creatività push-down SQL includono l'eliminazione delle colonne (SELECT clausole) e i filtri push-down (WHERE clausole).

Quando utilizzi la funzione EXTERNAL_QUERY, le creatività 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 creatività push-down SQL, viene inviata la seguente query 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 creatività push-down SQL, la seguente query viene inviata a Cloud SQL:

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

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

Puoi esaminare gli eventuali push-down applicati nel piano di query.

Limitazioni

  • Le creatività push-down SQL vengono applicate solo alle query federate nel formato SELECT * FROM T.
  • Sono supportati solo l'eliminazione delle colonne e i push-down filtro. Le creatività push-down di calcolo, join e aggregazione non sono supportate.
  • Per i push-down filtro, 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 creatività push-down SQL sono supportate solo per AlloyDB, Cloud SQL e Spanner. Le creatività push-down SQL non sono supportate per SAP DataSphere.

Funzioni supportate dall'origine dati

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

MySQL e 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 e AlloyDB

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