Introduzione alle query federate

Questa pagina illustra come utilizzare le query federate e fornisce indicazioni su come che eseguono query su 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 per visualizzare i risultati sotto forma di tabella temporanea. Le query federate utilizzano API BigQuery Connection per stabilire una connessione con AlloyDB, Spanner o Cloud SQL. Nella query, utilizzi la funzione EXTERNAL_QUERY per inviare un un'istruzione di query al database esterno, utilizzando il dialetto SQL del 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 di cui su cui vuoi eseguire una query.
  • Un utente di 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 autorizzazione.
  • L'utente B scrive una query in BigQuery con il nuovo EXTERNAL_QUERY funzione SQL.

Aree geografiche supportate

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

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

Singole regioni

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

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

Più regioni

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

  • Una query eseguita nell'area multiregionale degli Stati Uniti di BigQuery può eseguire query su qualsiasi singola regione nell'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 in un'unica regione negli stati membri dell'Unione Europea, ad esempio europe-north1 o europe-west3.

  • La posizione in cui viene eseguita la query deve corrispondere a quella del server risorsa di connessione. Ad esempio, query eseguite dalla località multiregionale degli Stati Uniti deve utilizzare una connessione che si trova in più regioni degli Stati Uniti.

Le prestazioni delle query variano in base alla vicinanza tra il set di dati e un'origine dati esterna. Ad esempio, una query federata tra un set di dati in la località multiregionale degli Stati Uniti e un'istanza Cloud SQL in us-central1 rapidamente. Tuttavia, se esegui la stessa query tra più regioni degli Stati Uniti e un'istanza Cloud SQL in us-east4, le prestazioni potrebbero essere più lente.

La località di elaborazione delle query è la località multiregionale, US o EU.

Mappature dei tipi di dati

Quando esegui una query federata, i dati provenienti dall'origine dati esterna viene convertito in un codice GoogleSQL di testo. Per ulteriori informazioni, vedi Query federate di Cloud SQL.

Quote e limiti

  • Query federate tra regioni. Se Località di elaborazione delle query BigQuery e la località dell'origine dati esterna è diversa, si tratta di un query. Puoi eseguire fino a 1 TB di query tra regioni per progetto 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 in più regioni degli Stati Uniti. La Il percorso 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 è prevista un'impostazione di quota aggiuntiva per l'esecuzione di query. Per ottenere l'isolamento dei carichi di lavoro, ti consigliamo di eseguire query solo replica di lettura del database.
  • Numero massimo di byte fatturati consentiti. Questo campo non è supportato per il formato federato query. Calcolo dei byte fatturati prima dell'effettiva non è possibile eseguire query federate.
  • Numero di connessioni. Una query federata può avere al massimo 10 query e connessioni a Internet.
  • 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 come l'esecuzione di query solo spazio di archiviazione BigQuery. BigQuery deve attendere al database di origine per eseguire la query esterna e spostare temporaneamente i dati dall'origine dati esterna a BigQuery. Inoltre, la fonte 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 le sezioni Supportate regioni.

  • Le query federate sono di sola lettura. La query esterna che viene eseguita nel database di origine deve essere di sola lettura. Di conseguenza, le istruzioni DML o DDL non supportati.

  • Tipi di dati non supportati. Se la query esterna contiene un tipo di dati che non è supportato in BigQuery, la query non riesce 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 di l'istanza Cloud SQL o AlloyDB.

Prezzi

  • Se utilizzi on demand, ti viene addebitato il numero di byte restituiti la query esterna durante l'esecuzione di query federate in BigQuery. Per ulteriori informazioni, vedi Analisi on demand prezzi.

  • Se utilizzi Versioni di BigQuery: l'addebito avviene in base al numero di slot che usi. Per ulteriori informazioni, consulta Calcolo della capacità prezzi.

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 al livello inferiore all'origine dati esterna invece di eseguirle in BigQuery. La riduzione della quantità di dati trasferiti dall'origine dati esterna può ridurre tempi di esecuzione delle query e costi inferiori. Le creatività push-down SQL includono l'eliminazione delle colonne (SELECT clausole) e filtra le clausole 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 corrispondenti al filtro vengono restituiti 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. computing, join e l'aggregazione push-down non è supportata.
  • 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 è supportato 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 INT64, FLOAT64 e tipi DATE, tranne che 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