Introduzione alle tabelle in cluster

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

In BigQuery, una colonna in cluster è una proprietà della tabella definita dall'utente che ordina i blocchi di archiviazione in base ai valori delle colonne in cluster. Le dimensioni dei blocchi di archiviazione vengono adattate in base alle dimensioni della tabella. La collocazione si verifica a livello dei blocchi di archiviazione e non a livello delle singole righe. Per saperne di più sulla collocazione in questo contesto, consulta Clustering.

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 tabella o partizione della tabella. Di conseguenza, BigQuery potrebbe non essere in grado di stimare con precisione i byte da elaborare dalla query o i costi della query, ma tenta di ridurre i byte totali durante l'esecuzione.

Quando raggruppi una tabella usando più colonne, l'ordine delle colonne determina quali colonne hanno la precedenza quando BigQuery ordina e raggruppa i dati in blocchi di archiviazione, come mostrato nell'esempio seguente. La Tabella 1 mostra il layout logico dei blocchi di archiviazione di una tabella non in cluster. Al contrario, la Tabella 2 è in cluster solo in base alla colonna Country, mentre la Tabella 3 è in cluster in base a più colonne, Country e Status.

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

Quando esegui una query su una tabella in cluster, non ricevi una stima precisa del costo della query prima dell'esecuzione della query perché il numero di blocchi di archiviazione da analizzare 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 analizzati.

Il clustering non garantisce una riduzione degli slot necessari per eseguire query su una tabella.

Quando usare il clustering

Il clustering riguarda la modalità di archiviazione di una tabella, quindi in genere è una buona prima opzione per migliorare le prestazioni delle query. Pertanto, dovresti sempre prendere in considerazione il clustering, dati i seguenti vantaggi che offre:

  • Le tabelle non partizionate di dimensioni superiori a 64 MB probabilmente trarranno vantaggio dal clustering. Allo stesso modo, anche le partizioni di tabella di dimensioni superiori a 64 MB probabilmente trarranno vantaggio dal clustering. È possibile raggruppare in cluster tabelle o partizioni più piccole, ma il miglioramento delle prestazioni è in genere trascurabile.
  • Se le query filtrano comunemente colonne specifiche, il clustering accelera le query perché la query analizza solo i blocchi che corrispondono al filtro.
  • Se le query filtrano le colonne con molti valori distinti (cardinalità elevata), il clustering accelera queste query fornendo a BigQuery metadati dettagliati su dove recuperare i dati di input.
  • Il clustering consente di ridimensionare in modo adattivo i blocchi di archiviazione sottostanti della tabella in base alle dimensioni della tabella.

Potresti prendere in considerazione il partizionamento della tabella oltre al clustering. In questo approccio, segmenti prima i dati in partizioni, quindi raggruppi i dati all'interno di ogni partizione in base alle colonne di clustering. Prendi in considerazione questo approccio nelle seguenti circostanze:

  • Hai bisogno di una stima precisa del costo della query prima di eseguirla. Il costo delle query sulle tabelle in cluster può essere determinato solo dopo l'esecuzione della query. Il partizionamento fornisce stime granulari del costo della query prima dell'esecuzione della query.
  • Il partizionamento della tabella comporta una dimensione media della partizione 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 durante l'esecuzione di query sulla tabella.
  • Devi aggiornare continuamente la tabella, ma vuoi comunque usufruire dei prezzi di archiviazione a lungo termine. Il partizionamento consente di considerare ogni partizione separatamente per l'idoneità ai prezzi a lungo termine. Se la tabella non è partizionata, l'intera tabella non deve essere modificata per 90 giorni consecutivi per essere presa in considerazione per i prezzi a lungo termine.

Per saperne di più, consulta Combinare tabelle in cluster e partizionate.

Tipi di colonne in cluster e ordinamento

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

Tipi di colonne in cluster

Le colonne in cluster devono essere colonne di primo livello, non ripetute e di uno dei seguenti tipi:

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

Per saperne di più sui tipi di dati, consulta Tipi di dati GoogleSQL.

Ordinamento delle colonne in cluster

L'ordine delle colonne in cluster influisce sulle prestazioni delle query. Nell'esempio seguente, la tabella Orders è in cluster utilizzando un ordinamento delle colonne Order_Date, Country e Status. La prima colonna in cluster in questo esempio è Order_Date, quindi una query che filtra in base a Order_Date e Country è ottimizzata per il clustering, mentre una query che filtra solo in base a Country e Status non è ottimizzata.

Le query sulle tabelle in cluster devono includere le 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, consulta Esempio.

Combinare tabelle in cluster e partizionate

Puoi combinare il clustering delle tabelle con il partizionamento delle tabelle per ottenere un ordinamento più preciso 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 mantiene vari metadati sulle proprietà di ordinamento in tutte le operazioni che la modificano. I metadati consentono a BigQuery di stimare con maggiore precisione il costo di una query prima dell'esecuzione della query. Tuttavia, il partizionamento richiede a BigQuery di gestire più metadati rispetto a una tabella non partizionata. Man mano che aumenta il numero di partizioni, aumenta anche la quantità di metadati da gestire.

Quando crei una tabella in cluster e partizionata, puoi ottenere un ordinamento più preciso, come mostrato nel seguente diagramma:

Confronto tra tabelle non in cluster o partizionate e 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 customer_id BETWEEN 20000 AND 23000 predicato del filtro nella colonna di clustering customer_id.

Riclassificazione automatica

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 i blocchi esistenti. L'ottimizzazione dei blocchi è necessaria per prestazioni ottimali di query e archiviazione, perché i nuovi dati potrebbero non essere raggruppati con i dati esistenti che hanno gli stessi valori di cluster.

Per mantenere le caratteristiche di prestazioni di una tabella in cluster, BigQuery esegue la riclassificazione automatica in background. Per le tabelle partizionate, il clustering viene mantenuto per i dati nell'ambito di ogni partizione.

Limitazioni

  • Solo GoogleSQL è supportato per l'esecuzione di query sulle tabelle in cluster e per la scrittura dei 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 in cluster. I valori nelle colonne possono essere più lunghi di 1024 caratteri.
  • Se modifichi una tabella non in cluster esistente in modo che sia in cluster, i dati esistenti non vengono raggruppati automaticamente in cluster. Solo i nuovi dati archiviati utilizzando le colonne in cluster sono soggetti alla riclassificazione automatica. Per saperne di più sulla riclassificazione dei dati esistenti utilizzando un'istruzione UPDATE statement, consulta Modificare la specifica di clustering.

Quote e limiti delle tabelle in cluster

BigQuery limita l'utilizzo di risorse condivise con quote e limiti, incluse limitazioni su determinate operazioni sulle tabelle o il numero di job eseguiti in un giorno. Google Cloud

Quando utilizzi la funzionalità delle tabelle in cluster con una tabella partizionata, sei soggetto ai limiti delle tabelle partizionate.

Le quote e i limiti si applicano anche ai diversi tipi di job che puoi eseguire sulle tabelle in cluster. Per informazioni sulle quote dei job che si applicano alle tue tabelle, consulta la sezione Job in "Quote e limiti".

Prezzi delle tabelle in cluster

Quando crei e utilizzi tabelle in cluster in BigQuery, i tuoi addebiti dipendono dalla quantità di dati archiviati nelle tabelle e dalle query eseguite sui dati. Per saperne di più, consulta Prezzi dello spazio di archiviazione e Prezzi delle query.

Come altre operazioni sulle tabelle BigQuery, le operazioni sulle tabelle in cluster sfruttano le operazioni senza costi di BigQuery, come il caricamento in batch, la copia delle tabelle, la riclassificazione automatica e l'esportazione dei dati. Queste operazioni sono soggette a quote e limiti di BigQuery. Per informazioni sulle operazioni senza costi, consulta Operazioni senza costi.

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

Sicurezza delle tabelle

Per controllare l'accesso alle tabelle in BigQuery, consulta Controllare l'accesso alle risorse con IAM.

Passaggi successivi