Introduzione alle tabelle in cluster
Le tabelle in cluster in BigQuery sono tabelle con una colonna definita dall'utente utilizzando le colonne in cluster. Le tabelle in cluster possono migliorare la query per ridurre i costi delle query.
In BigQuery, una colonna in cluster è una tabella definita dall'utente che ordina i blocchi di archiviazione in base ai valori nelle colonne in cluster. I blocchi di archiviazione sono adattivi con le dimensioni della tabella. La colocation avviene a livello dello spazio di archiviazione blocchi e non a livello di 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 e ridurre il numero di 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 in blocchi di archiviazione. L'esempio seguente mette a confronto l'archiviazione logica layout a blocchi di una tabella non in cluster con il layout delle tabelle in cluster che avere una o più colonne in cluster:
Quando esegui una query su una tabella in cluster, non ricevi un costo delle query accurato una stima prima dell'esecuzione della query in quanto il numero di blocchi di archiviazione da non è noto prima dell'esecuzione della query. Il costo finale viene determinato dopo l'esecuzione della query viene completata e si basa sui blocchi di archiviazione specifici sono stati sottoposti a scansione.
Quando usare il clustering
Il clustering risolve il modo in cui una tabella viene archiviata, quindi in genere è una buona soluzione per migliorare le prestazioni delle query. Dovresti quindi considerare sempre il clustering, considerati i seguenti vantaggi:
- È probabile che le tabelle non partizionate più grandi di 64 MB traggano vantaggio per il clustering. Allo stesso modo, è probabile che anche le partizioni delle tabelle più grandi di 64 MB per trarre vantaggio dal clustering. Il clustering di tabelle o partizioni più piccole è possibile, ma il miglioramento delle prestazioni è solitamente trascurabile.
- Se le query di solito filtrano in base a colonne particolari, il clustering velocizza le query perché analizza solo i blocchi che corrispondono filtro.
- Se le query filtrano in base a colonne che hanno molti valori distinti (cardinalità elevata), il clustering accelera queste query fornendo BigQuery con metadati dettagliati su dove recuperare i dati di input.
- Il clustering consente di usare in modo adattivo i blocchi di archiviazione sottostanti della tabella con le dimensioni della tabella.
Potresti considerare di partizionare la tabella oltre al clustering. In questo approccio, per prima cosa segmenti i dati in e raggruppa i dati all'interno di ogni partizione in base 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 di query su tabelle in cluster può essere determinato solo dopo che la query vengono eseguiti tutti i test delle unità. Il partizionamento fornisce stime granulari dei costi delle query prima di eseguire una query.
- Il partizionamento della tabella determina una dimensione media della partizione pari a di almeno 10 GB per partizione. La creazione di molte partizioni piccole aumenta metadati della tabella e può influire sui tempi di accesso ai metadati quando si esegue una query .
- 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 l'idoneità per prezzi a lungo termine. Se la tabella non è partizionata, l'intera tabella non deve essere modificata per 90 giorni consecutivi per i prezzi a lungo termine.
Per ulteriori informazioni, vedi 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 nella tabella per il clustering.
Tipi di colonna del cluster
Le colonne del cluster devono essere colonne di primo livello non ripetute che fanno parte i 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 il clustering, l'ordine dei filtri delle query deve corrispondere all'ordine delle colonne cluster e deve includere almeno la prima colonna in cluster.
Nell'esempio seguente, la tabella degli ordini è raggruppata in cluster utilizzando un ordinamento a colonne
ordine di Order_Date
, Country
e Status
. Una query che applica un filtro in base a
Order_Date
e Country
sono ottimizzate per il clustering, ma una query che filtra
solo su Country
, mentre Status
non è ottimizzato. per ottimizzare il clustering
devi filtrare le colonne in cluster in ordine a partire dal primo
in cluster.
Eliminazione dei blocchi
Le tabelle in cluster possono aiutarti a ridurre i costi delle query eliminando i dati 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 nelle colonne in cluster, BigQuery utilizza l'espressione di filtro i metadati del blocco per eliminare i blocchi analizzati dalla query. Ciò consente a BigQuery di eseguire la scansione solo dei 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 sono archiviati in blocchi fisici, ognuno dei quali contiene una partizione di dati. Ogni tabella partizionata conserva vari metadati le proprietà di ordinamento in tutte le operazioni che lo modificano. I metadati consentono di BigQuery stima in modo più accurato il costo di una query prima della query viene eseguito. Tuttavia, il partizionamento richiede BigQuery per mantenere rispetto a una tabella non partizionata. Con l'aumento del numero di partizioni, di metadati per mantenere un aumento.
Quando crei una tabella in cluster e partizionata, puoi ottenere un ordinamento granulare, come mostra il seguente diagramma:
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
etotalSale
nei blocchi B2 e B4. - Elimina il blocco B3 a causa del predicato del filtro
DATE(timestamp) = "2016-05-01"
nella colonna di partizionamentotimestamp
. - Elimina il blocco B1 a causa del predicato del filtro
customer_id BETWEEN 20000 AND 23000
nella colonna di clusteringcustomer_id
.
Riclustering automatico
Quando i dati vengono aggiunti a una tabella in cluster, i nuovi dati vengono organizzati in blocchi, che potrebbero creare nuovi blocchi di archiviazione o aggiornare blocchi esistenti. Blocca l'ottimizzazione è necessaria per ottimizzare le prestazioni di query e archiviazione, dato che nuovi 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 partizionate, il clustering viene mantenuto per i dati nell'ambito della partizione di testo.
Limitazioni
- È supportato solo GoogleSQL per l'esecuzione di query in cluster e scrivere i risultati delle query nelle tabelle in cluster.
- Puoi specificare solo fino a quattro colonne di clustering. Se hai bisogno 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 nei e le colonne possono 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. Soltanto i nuovi dati archiviati utilizzando
in cluster è soggetto a riclustering automatico. Per ulteriori informazioni
sul riclustering dei dati esistenti mediante
UPDATE
, vedi Modifica 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 limitazioni a determinate tabelle operazioni o il numero di job eseguiti in un giorno.
Quando utilizzi la funzionalità delle tabelle in cluster con una tabella partizionata, soggetto alle limiti per le tabelle partizionate.
Quote e limiti si applicano anche ai diversi tipi di job che puoi eseguire rispetto alle tabelle in cluster. Per informazioni sulle quote dei job applicabili nelle tabelle, consulta Job in "Quote e limiti".
Prezzi delle tabelle in cluster
Quando crei e utilizzi tabelle in cluster in BigQuery, gli addebiti si basano sulla quantità di dati archiviati nelle tabelle e sulle query che esegui sui dati. Per ulteriori informazioni, vedi Prezzi dello spazio di archiviazione e Prezzi delle query.
Come per altre operazioni sulle tabelle BigQuery, le operazioni sulle tabelle in cluster sfruttare le operazioni gratuite di BigQuery come il caricamento in batch, copia delle tabelle, riclustering automatico ed esportazione dei dati. Queste operazioni sono soggetti a quote e limiti di BigQuery. Per informazioni sulle operazioni gratuite, vedi Operazioni gratuite.
Per un esempio dettagliato dei prezzi di tabelle in cluster, vedi Stima 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
- Per scoprire come creare e utilizzare le tabelle in cluster, vedi Creazione e utilizzo di tabelle in cluster.
- Per informazioni sull'esecuzione di query su tabelle in cluster, consulta Esecuzione di query su tabelle in cluster.