Introduzione alle tabelle in cluster

Le tabelle in cluster in BigQuery sono tabelle con un ordinamento delle colonne definito dall'utente mediante colonne in cluster. Le tabelle in cluster possono migliorare le prestazioni delle query e ridurne i costi.

In BigQuery, una colonna in cluster è una proprietà di tabella definita dall'utente che ordina i blocchi di archiviazione in base ai valori nelle colonne in cluster. Le dimensioni dei blocchi di archiviazione sono adatte in base a quelle della tabella. La colocation avviene a livello dei blocchi di archiviazione e non a livello delle singole righe. Per ulteriori informazioni sulla colocation in questo contesto, consulta Cluster.

Una tabella in cluster mantiene le proprietà di ordinamento nel contesto di ogni operazione che la modifica. Le query che filtrano o aggregano in base alle colonne in cluster analizzano solo i blocchi pertinenti in base alle colonne in cluster, anziché l'intera partizione della tabella o della tabella. Di conseguenza, BigQuery potrebbe non essere in grado di stimare con precisione i byte che devono essere elaborati dalla query o i costi delle query, ma tenta di ridurre i byte totali al momento dell'esecuzione.

Quando raggruppi una tabella utilizzando più colonne, l'ordine delle colonne determina quali colonne hanno la precedenza quando BigQuery ordina e raggruppa i dati in blocchi di archiviazione. L'esempio seguente confronta il layout a blocchi di archiviazione logico di una tabella non in cluster con il layout delle tabelle in cluster che hanno una o più colonne in cluster:

BigQuery ordina i dati in tabelle in cluster per migliorare le prestazioni delle query.

Quando esegui una query su una tabella in cluster, non ricevi una stima accurata dei costi delle query prima dell'esecuzione della query, perché il numero di blocchi di archiviazione da scansionare non è noto prima dell'esecuzione della query. Il costo finale viene determinato al termine dell'esecuzione della query e si basa sui blocchi di archiviazione specifici sottoposti a scansione.

Quando usare il clustering

Il clustering risolve il modo in cui una tabella viene archiviata, quindi in genere rappresenta una prima opzione ottima per migliorare le prestazioni delle query. Pertanto, considera sempre il clustering considerati i seguenti vantaggi:

  • È probabile che le tabelle non partizionate di dimensioni superiori a 64 MB traggano vantaggio dal clustering. Allo stesso modo, è probabile che anche le partizioni delle tabelle più grandi di 64 MB traggano vantaggio dal clustering. Il clustering di tabelle o partizioni più piccole è possibile, ma il miglioramento delle prestazioni è solitamente trascurabile.
  • Se le tue query di solito filtrano in base a colonne specifiche, il clustering accelera le query perché la query analizza solo i blocchi che corrispondono al filtro.
  • Se le tue query filtrano in base a colonne che hanno molti valori distinti (cardinalità elevata), il clustering accelera queste query fornendo a BigQuery metadati dettagliati su dove ottenere i dati di input.
  • Il clustering consente di dimensionare in modo adattiva i blocchi di archiviazione sottostanti della tabella in base alle dimensioni della tabella.

Potresti considerare di partizionare la tabella oltre al clustering. Con questo approccio, devi prima segmentare i dati in partizioni, quindi raggruppa i dati all'interno di ogni partizione in base alle colonne di clustering. Prendi in considerazione questo approccio nelle seguenti circostanze:

  • Devi avere una stima rigorosa dei costi delle query prima di eseguire una query. Il costo delle query sulle tabelle in cluster può essere determinato solo dopo l'esecuzione della query. Il partizionamento fornisce stime granulari dei costi delle query prima di eseguire una query.
  • Il partizionamento della tabella determina una dimensione media delle partizioni di almeno 10 GB per partizione. La creazione di molte partizioni di piccole dimensioni aumenta i metadati della tabella e può influire sui tempi di accesso ai metadati quando si esegue una query sulla tabella.
  • Devi aggiornare continuamente la tabella, ma vuoi comunque usufruire dei prezzi dell'archiviazione a lungo termine. Il partizionamento consente a ciascuna partizione di essere considerata separatamente ai fini dell'idoneità per i prezzi a lungo termine. Se la tabella non è partizionata, l'intera tabella non deve essere modificata per 90 giorni consecutivi affinché venga considerata per i prezzi a lungo termine.

Per maggiori informazioni, consulta Combinare tabelle in cluster e partizionate.

Tipi e ordinamento delle colonne del cluster

Questa sezione descrive i tipi di colonna e il funzionamento dell'ordine delle colonne nel clustering delle tabelle.

Tipi di colonna del cluster

Le colonne del cluster devono essere colonne di primo livello non ripetute che rappresentano uno dei seguenti tipi:

  • STRING
  • INT64
  • NUMERIC
  • BIGNUMERIC
  • DATE
  • DATETIME
  • TIMESTAMP
  • BOOL
  • GEOGRAPHY

Per ulteriori informazioni sui tipi di dati, consulta Tipi di dati GoogleSQL.

Ordinamento delle colonne del cluster

L'ordine delle colonne in cluster influisce sulle prestazioni delle query. Per trarre vantaggio dal clustering, l'ordine dei filtri delle query deve corrispondere all'ordine delle colonne in cluster e deve includere almeno la prima colonna in cluster.

Nell'esempio seguente, la tabella degli ordini è raggruppata in cluster utilizzando un ordinamento di colonne Order_Date, Country e Status. Una query con filtri in base a Order_Date e Country è ottimizzata per il clustering, mentre una query che applica filtri solo in base a Country e Status non viene ottimizzata. Per ottimizzare i risultati del clustering, devi filtrare le colonne in cluster in base alla prima colonna in cluster.

Le query sulle tabelle in cluster devono includere colonne in cluster in ordine a partire dalla prima.

Eliminazione dei blocchi

Le tabelle in cluster possono aiutarti a ridurre i costi delle query eliminando i dati in modo che non vengano elaborati dalla query. Questo processo è chiamato eliminazione dei blocchi. BigQuery ordina i dati in una tabella in cluster in base ai valori nelle colonne di clustering e li organizza in blocchi.

Quando esegui una query su una tabella in cluster e la query include un filtro sulle colonne in cluster, BigQuery utilizza l'espressione di filtro e i metadati del blocco per eliminare i blocchi analizzati dalla query. In questo modo BigQuery può analizzare solo i blocchi pertinenti.

Quando un blocco viene eliminato, non viene scansionato. Solo i blocchi analizzati vengono utilizzati per calcolare i byte dei dati elaborati dalla query. Il numero di byte elaborati da una query su una tabella in cluster corrisponde alla somma dei byte letti in ogni colonna a cui fa riferimento la query nei blocchi analizzati.

Se una query che utilizza diversi filtri fa riferimento più volte a una tabella in cluster, BigQuery addebita l'analisi delle colonne nei blocchi appropriati in ciascuno dei rispettivi filtri. Per un esempio di come funziona l'eliminazione dei blocchi, vedi Esempio.

Combina tabelle in cluster e partizionate

Puoi combinare il clustering delle tabelle con il partizionamento delle tabelle per ottenere un ordinamento granulare per un'ulteriore ottimizzazione delle query.

In una tabella partizionata, i dati vengono archiviati in blocchi fisici, ognuno dei quali contiene una partizione di dati. Ogni tabella partizionata conserva vari metadati sulle proprietà di ordinamento in tutte le operazioni che la modificano. I metadati consentono a BigQuery di stimare in modo più accurato il costo di una query prima che venga eseguita. Tuttavia, il partizionamento richiede che BigQuery contenga più metadati rispetto a una tabella non partizionata. Con l'aumento del numero delle partizioni, aumenta la quantità di metadati da mantenere.

Quando crei una tabella in cluster e partizionata, puoi ottenere un ordinamento più granulare, come mostra il seguente diagramma:

Confronto tra tabelle non in cluster o partizionate con tabelle in cluster e partizionate.

Esempio

Hai una tabella in cluster denominata ClusteredSalesData. La tabella è partizionata in base alla colonna timestamp ed è raggruppata in cluster in base alla colonna customer_id. I dati sono organizzati nel seguente insieme di blocchi:

Identificatore di partizione ID blocco Valore minimo per customer_id nel blocco Valore massimo per customer_id nel blocco
20160501 B1 10000 19999
20160501 B2 20000 24999
20160502 B3 15000 17999
20160501 B4 22000 27999

Esegui la seguente query sulla tabella. La query contiene un filtro nella colonna customer_id.

SELECT
  SUM(totalSale)
FROM
  `mydataset.ClusteredSalesData`
WHERE
  customer_id BETWEEN 20000
  AND 23000
  AND DATE(timestamp) = "2016-05-01"

La query precedente prevede i seguenti passaggi:

  • Analizza le colonne timestamp, customer_id e totalSale nei blocchi B2 e B4.
  • Elimina il blocco B3 a causa del predicato del filtro DATE(timestamp) = "2016-05-01" nella colonna di partizionamento timestamp.
  • Elimina il blocco B1 a causa del predicato del filtro customer_id BETWEEN 20000 AND 23000 nella colonna di clustering customer_id.

Riclustering automatico

Quando i dati vengono aggiunti a una tabella in cluster, i nuovi dati vengono organizzati in blocchi, il che potrebbe creare nuovi blocchi di archiviazione o aggiornare blocchi esistenti. L'ottimizzazione dei blocchi è necessaria per ottenere prestazioni ottimali da query e archiviazione perché i nuovi dati potrebbero non essere raggruppati con dati esistenti che hanno gli stessi valori del cluster.

Per mantenere le caratteristiche prestazionali di una tabella in cluster, BigQuery esegue il riclustering automatico in background. Per le tabelle partizionate, viene mantenuto il clustering per i dati nell'ambito di ciascuna partizione.

Limitazioni

  • È supportato solo GoogleSQL per l'esecuzione di query su tabelle in cluster e per scrivere i risultati delle query nelle tabelle in cluster.
  • Puoi specificare solo fino a quattro colonne di clustering. Se hai bisogno di colonne aggiuntive, valuta la possibilità di combinare il clustering con il partizionamento.
  • Quando utilizzi colonne di tipo STRING per il clustering, BigQuery utilizza solo i primi 1024 caratteri per raggruppare i dati. I valori nelle colonne possono a loro volta contenere più di 1024 caratteri.
  • Se modifichi una tabella non in cluster esistente in modo che sia in cluster, i dati esistenti non vengono raggruppati automaticamente. Utilizza le colonne in cluster solo i nuovi dati e sono soggetti a riclustering automatico. Per ulteriori informazioni sul riclustering dei dati esistenti utilizzando un'istruzione UPDATE in loco, consulta Modificare la specifica di clustering.

Quote e limiti delle tabelle in cluster

BigQuery limita l'uso delle risorse Google Cloud condivise con quote e limiti, incluse le limitazioni su alcune operazioni tabella o al numero di job eseguiti in un giorno.

Quando utilizzi la funzionalità delle tabelle in cluster con una tabella partizionata, si applicano i limiti delle tabelle partizionate.

Quote e limiti si applicano anche ai diversi tipi di job che è possibile eseguire su tabelle in cluster. Per informazioni sulle quote per i job che si applicano alle tabelle, vedi Job in "Quote e limiti".

Prezzi delle tabelle in cluster

Quando crei e utilizzi tabelle in cluster in BigQuery, i tuoi addebiti si basano sulla quantità di dati archiviati nelle tabelle e sulle query che esegui sui dati. Per ulteriori informazioni, vedi Prezzi dell'archiviazione e Prezzi delle query.

Come per altre operazioni sulle tabelle BigQuery, le operazioni sulle tabelle in cluster sfruttano le operazioni gratuite di BigQuery come caricamento batch, copia delle tabelle, riclustering automatico ed esportazione dati. Queste operazioni sono soggette a quote e limiti di BigQuery. Per informazioni sulle operazioni gratuite, vedi Operazioni gratuite.

Per un esempio dettagliato dei prezzi di tabelle in cluster, consulta Stimare i costi di archiviazione e query.

Sicurezza dei tavoli

Per controllare l'accesso alle tabelle in BigQuery, consulta Introduzione ai controlli di accesso alle tabelle.

Passaggi successivi