Estimar os custos de armazenamento e consulta

No BigQuery, as consultas sob demanda são cobradas com base no número de bytes lidos. Para saber os preços atuais de consultas sob demanda, consulte esta página.

Para estimar custos antes de executar uma consulta, use um destes métodos:

• Validador de consultas no Console do Cloud
• Sinalização --dry_run na ferramenta de linha de comando bq
• o parâmetro dryRun ao enviar um job de consulta usando a API
• A calculadora de preços do Google Cloud
• Bibliotecas de cliente

Os custos estimados fornecidos por esses métodos podem variar dos custos reais devido a vários fatores. Por exemplo, considere os seguintes cenários:

• Uma cláusula de consulta que filtra dados, como uma cláusula WHERE, pode reduzir significativamente o número de bytes lidos.
• Os dados adicionados ou excluídos depois que a estimativa é fornecida podem aumentar ou diminuir o número de bytes lidos quando a consulta é executada.

Estimar custos de consulta

Para estimar esses custos:

Console

Quando você insere uma consulta no Console do Cloud, o validador de consulta verifica a sintaxe dela e fornece uma estimativa do número de bytes lidos. Essa estimativa pode ser usada para calcular o custo da consulta na calculadora de preços.

bq

Ao executar uma consulta na ferramenta de linha de comando bq, use a sinalização --dry_run para estimar o número de bytes lidos. Essa estimativa pode ser usada para calcular o custo da consulta na calculadora de preços.

Uma consulta da ferramenta bq que usa a sinalização --dry_run tem esta aparência:

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
  column1,
  column2,
  column3
FROM
  `project_id.dataset.table`
LIMIT
  1000'

Quando você executa o comando, a resposta contém os bytes estimados lidos: Query successfully validated. Assuming the tables are not modified, running this query will process 10918 bytes of data.

API

Para executar uma simulação usando a API, envie um job de consulta com dryRun definido como true.

ir

Antes de testar essa amostra, siga as instruções de configuração para Go no Guia de início rápido do BigQuery: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API BigQuery em Go.

Ver no GitHub Feedback

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/bigquery"
)

// queryDryRun demonstrates issuing a dry run query to validate query structure and
// provide an estimate of the bytes scanned.
func queryDryRun(w io.Writer, projectID string) error {
	// projectID := "my-project-id"
	ctx := context.Background()
	client, err := bigquery.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("bigquery.NewClient: %v", err)
	}
	defer client.Close()

	q := client.Query(`
	SELECT
		name,
		COUNT(*) as name_count
	FROM ` + "`bigquery-public-data.usa_names.usa_1910_2013`" + `
	WHERE state = 'WA'
	GROUP BY name`)
	q.DryRun = true
	// Location must match that of the dataset(s) referenced in the query.
	q.Location = "US"

	job, err := q.Run(ctx)
	if err != nil {
		return err
	}
	// Dry run is not asynchronous, so get the latest status and statistics.
	status := job.LastStatus()
	if err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

Java

Antes de testar esta amostra, siga as instruções de configuração do Java no Guia de início rápido do BigQuery: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API BigQuery em Java.

Ver no GitHub Feedback

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Job;
import com.google.cloud.bigquery.JobInfo;
import com.google.cloud.bigquery.JobStatistics;
import com.google.cloud.bigquery.QueryJobConfiguration;

// Sample to run dry query on the table
public class QueryDryRun {

  public static void runQueryDryRun() {
    String query =
        "SELECT name, COUNT(*) as name_count "
            + "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
            + "WHERE state = 'WA' "
            + "GROUP BY name";
    queryDryRun(query);
  }

  public static void queryDryRun(String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      QueryJobConfiguration queryConfig =
          QueryJobConfiguration.newBuilder(query).setDryRun(true).setUseQueryCache(false).build();

      Job job = bigquery.create(JobInfo.of(queryConfig));
      JobStatistics.QueryStatistics statistics = job.getStatistics();

      System.out.println(
          "Query dry run performed successfully." + statistics.getTotalBytesProcessed());
    } catch (BigQueryException e) {
      System.out.println("Query not performed \n" + e.toString());
    }
  }
}

Node.js

Antes de testar esta amostra, siga as instruções de configuração do Node.js no Guia de início rápido do BigQuery: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API BigQuery Node.js.

Ver no GitHub Feedback

// Import the Google Cloud client library
const {BigQuery} = require('@google-cloud/bigquery');
const bigquery = new BigQuery();

async function queryDryRun() {
  // Runs a dry query of the U.S. given names dataset for the state of Texas.

  const query = `SELECT name
    FROM \`bigquery-public-data.usa_names.usa_1910_2013\`
    WHERE state = 'TX'
    LIMIT 100`;

  // For all options, see https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/query
  const options = {
    query: query,
    // Location must match that of the dataset(s) referenced in the query.
    location: 'US',
    dryRun: true,
  };

  // Run the query as a job
  const [job] = await bigquery.createQueryJob(options);

  // Print the status and statistics
  console.log('Status:');
  console.log(job.metadata.status);
  console.log('\nJob Statistics:');
  console.log(job.metadata.statistics);
}

Python

Antes de testar esta amostra, siga as instruções de configuração do Python no Guia de início rápido do BigQuery: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API BigQuery em Python.

Para executar uma simulação usando a biblioteca de cliente em Python, configure a propriedade QueryJobConfig.dry_run como True. Se uma configuração de consulta de simulação for fornecida, Client.query() sempre retornará um QueryJob concluído (links em inglês).

Ver no GitHub Feedback

from google.cloud import bigquery

# Construct a BigQuery client object.
client = bigquery.Client()

job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Start the query, passing in the extra configuration.
query_job = client.query(
    (
        "SELECT name, COUNT(*) as name_count "
        "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
        "WHERE state = 'WA' "
        "GROUP BY name"
    ),
    job_config=job_config,
)  # Make an API request.

# A dry run query completes immediately.
print("This query will process {} bytes.".format(query_job.total_bytes_processed))

Estimar custos de consulta com a calculadora de preços do Google Cloud

Para estimar custos de consulta sob demanda na Calculadora de preços do Google Cloud, digite o número de bytes processados pela consulta como B, KB, MB, GB, TB ou PB. Se sua consulta processar menos de 1 TB, a estimativa será de US$ 0, porque o BigQuery dá 1 TB de processamento de consultas sob demanda gratuito por mês.

Para estimar o custo de uma consulta usando a calculadora de preços, siga estas etapas:

1. Abra a Calculadora de preços do Google Cloud.
2. Clique em BigQuery.
3. Clique na guia Sob demanda.
4. Digite o Nome da tabela. Por exemplo, airports.
5. Em Preço de armazenamento, insira 0 no campo Armazenamento.
6. Para Preços de consulta, insira os bytes estimados lidos da sua simulação ou do validador de consulta.
7. Clique em Adicionar à estimativa.
8. A estimativa aparece à direita. É possível salvar ou enviar a estimativa por e-mail.

Nesse caso, o número de bytes lidos pela consulta está abaixo de 1 TB, fornecido para processamento sob demanda pelo nível gratuito. Dessa forma, o custo estimado é de US$ 0.

Incluir preços fixos na calculadora de preços

Se você tiver preços fixos aplicados à sua conta de faturamento, clique na aba Taxa fixa, escolha seu plano e adicione os custos de armazenamento à estimativa.

Para saber mais, consulte Preços fixos.

Estimar custos de armazenamento com a calculadora de preços do Google Cloud

Para estimar os custos de armazenamento na Calculadora de preços do Google Cloud, insira o número de bytes armazenados como B, KB, MB, GB, TB ou PB. O BigQuery armazena 10 GB gratuitamente por mês.

Para estimar os custos de armazenamento usando a calculadora de preços, siga estas etapas:

1. Abra a Calculadora de preços do Google Cloud.
2. Clique em BigQuery.
3. Clique na guia Sob demanda.
4. Digite o Nome da tabela. Por exemplo, airports.
5. Em Preço de armazenamento, insira 100 no campo Armazenamento. Deixe a medida como GB.
6. Clique em Adicionar à estimativa.
7. A estimativa aparece à direita. É possível salvar ou enviar a estimativa por e-mail.

Cálculo do tamanho da consulta

Nesta seção, descrevemos como calcular o número de bytes processados por vários tipos de consulta usando o modelo de faturamento sob demanda.

Instruções DML

Se você usa o faturamento sob demanda, o BigQuery cobra as instruções da linguagem de manipulação de dados (DML, na sigla em inglês) com base no número de bytes processados pela instrução.

Tabelas não particionadas

Para tabelas não particionadas, o número de bytes processados é calculado da seguinte forma:

• q = a soma dos bytes processados das colunas referenciadas nas tabelas verificadas pela consulta.
• t = a soma dos bytes de todas as colunas na tabela atualizada no momento em que a consulta é iniciada, independentemente de essas colunas serem referenciadas ou modificadas na consulta.

Instrução DML	Bytes processados
INSERT	q
UPDATE	q + t
DELETE	q + t
MERGE	Se houver apenas cláusulas INSERT: q. Se houver uma cláusula UPDATE ou DELETE: q + t.

Tabelas particionadas

Para tabelas particionadas, o número de bytes processados é calculado da seguinte forma:

• q' = a soma dos bytes processados das colunas referenciadas em todas as partições verificadas pela consulta.
• t = A soma dos bytes paratodas as colunas nas partições atualizadas ou verificadas das linhas atualizadas, no momento em que a consulta é iniciada, independentemente de essas colunas serem referenciadas ou modificadas na consulta.

Instrução DML	Bytes processados
INSERT	q'
UPDATE	q' + t'
DELETE	q' + t'
MERGE	Se houver apenas cláusulas INSERT na instrução MERGE: q'. Se houver uma cláusula UPDATE ou DELETE na instrução MERGE: q' + t'.

Instruções DDL

Se você usar o faturamento sob demanda, o BigQuery cobrará pelas consultas de linguagem de definição de dados (DDL) com base no número de bytes processados pela consulta.

Instrução DDL	Bytes processados
CREATE TABLE	Nenhum.
CREATE TABLE ... AS SELECT ...	A soma dos bytes processados de todas as colunas referenciadas nas tabelas verificadas pela consulta.
CREATE VIEW	Nenhum.
DROP TABLE	Nenhum.
DROP VIEW	Nenhum

Consultas de múltiplas instruções

Se você usa o faturamento sob demanda, o BigQuery cobra por consultas de várias instruções com base no número de bytes processados durante a execução das consultas de várias instruções.

Observação: o número de bytes verificados por uma consulta de várias instruções geralmente não é conhecido antes da execução. Para evitar custos não intencionais de consulta, considere usar preços fixos. Como alternativa, é possível usar o sandbox do BigQuery para execução de consulta sem custo e limitada.

Os preços a seguir são aplicáveis a estas consultas de várias instruções:

• DECLARE: a soma dos bytes verificados para todas as tabelas referenciadas pela expressão DEFAULT. Instruções DECLARE sem referências de tabela não geram custo.
• SET: a soma dos bytes verificados para todas as tabelas referenciadas pela expressão. Instruções SET sem referências de tabela não geram custo.
• IF: a soma dos bytes verificados para todas as tabelas referenciadas pela expressão condicional. Expressões condicionais IF sem referências de tabela não geram custo. Instruções no bloco IF que não forem executadas não geram custo.
• WHILE: a soma dos bytes verificados para todas as tabelas referenciadas pela expressão condicional. Instruções WHILE sem referências de tabela na expressão condicional não geram custo. Instruções no bloco WHILE que não forem executadas não geram custo.
• CONTINUE ou ITERATE: sem custo associado.
• BREAK ou LEAVE: sem custo associado.
• BEGIN ou END: sem custo associado.

Tabelas temporárias não geram custo de armazenamento enquanto a consulta de múltiplas instruções estiver em execução. Porém, se as instruções criarem, modificarem ou consultarem as tabelas, será cobrado o preço normal.

Se uma consulta de várias instruções falhar, o custo das instruções até a falha ainda se aplicará. Instruções falhas não geram cobrança adicional.

Exemplo de preços de consulta de várias instruções

O exemplo a seguir contém comentários acima de cada instrução que explicam o custo da instrução a seguir, se houver.

-- No cost, since no tables are referenced.
DECLARE x DATE DEFAULT CURRENT_DATE();
-- Incurs the cost of scanning string_col from dataset.table.
DECLARE y STRING DEFAULT (SELECT MAX(string_col) FROM dataset.table);
-- Incurs the cost of copying the data from dataset.big_table.  Once the
-- table is created, you are not charged for storage while the rest of the
-- multi-statement query runs.
CREATE TEMP TABLE t AS SELECT * FROM dataset.big_table;
-- Incurs the cost of scanning column1 from temporary table t.
SELECT column1 FROM t;
-- No cost, since y = 'foo' doesn't reference a table.
IF y = 'foo' THEN
  -- Incurs the cost of scanning all columns from dataset.other_table, if
  -- y was equal to 'foo', or otherwise no cost since it is not executed.
  SELECT * FROM dataset.other_table;
ELSE
  -- Incurs the cost of scanning all columns from dataset.different_table, if
  -- y was not equal to 'foo', or otherwise no cost since it is not executed.
  UPDATE dataset.different_table
  SET col = 10
  WHERE true;
END IF;
-- Incurs the cost of scanning date_col from dataset.table for each
-- iteration of the loop.
WHILE x < (SELECT MIN(date_col) FROM dataset.table) DO
  -- No cost, since the expression does not reference any tables.
  SET x = DATE_ADD(x, INTERVAL 1 DAY);
  -- No cost, since the expression does not reference any tables.
  IF true THEN
    -- LEAVE has no associated cost.
    LEAVE;
  END IF;
  -- Never executed, since the IF branch is always taken, so does not incur
  -- a cost.
  SELECT * FROM dataset.big_table;
END WHILE;

Tabelas em cluster

As tabelas em cluster ajudam a reduzir os custos de consulta removendo dados para que não sejam processados pela consulta. Este processo é chamado de remoção de blocos.

Remoção de blocos

O BigQuery classifica os dados em uma tabela em cluster com base nos valores atuais nas colunas em cluster e os organiza em blocos.

Quando você executa uma consulta em uma tabela em cluster e a consulta inclui um filtro nas colunas em cluster, o BigQuery usa a expressão de filtro e os metadados do bloco para remover os blocos verificados pela consulta. Isso permite que o BigQuery verifique apenas os blocos relevantes.

Os blocos removidos não são verificados. Somente os blocos verificados são usados para calcular os bytes de dados processados pela consulta. O número de bytes processados por uma consulta em uma tabela em cluster é igual à soma dos bytes lidos em cada coluna referenciada pela consulta nos blocos verificados.

Se uma tabela em cluster for referenciada várias vezes em uma consulta que usa vários filtros, o BigQuery cobra pela verificação das colunas nos blocos apropriados em cada um dos respectivos filtros.

Exemplo de preços de tabela em cluster

Temos uma tabela em cluster chamada ClusteredSalesData. A tabela é particionada na coluna timestamp e agrupada pela coluna customer_id. Os dados são organizados no seguinte conjunto de blocos:

Identificador de partição	ID do bloco	Valor mínimo para customer_id no bloco	Valor máximo para customer_id no bloco
20160501	B1	10000	19999
20160501	B2	20000	24999
20160502	B3	15000	17999
20160501	B4	22000	27999

A consulta a seguir é executada na tabela Ela tem um filtro na coluna customer_id.

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

Esta consulta:

• verifica as colunas timestamp, customer_id e totalSale nos blocos B2 e B4;
• remove o bloco B3 devido ao predicado de filtro DATE(timestamp) = "2016-05-01" na coluna de particionamento timestamp;
• remove a coluna B1 devido ao predicado de filtro customer_id BETWEEN 20000 AND 23000na coluna de particionamento customer_id.

Consultar formatos em colunas no Cloud Storage

Se os dados externos forem armazenados no ORC ou no Parquet, o número de bytes cobrados será limitado às colunas que são lidas pelo BigQuery. Como os tipos de dados de uma fonte de dados externa são convertidos em tipos de dados do BigQuery pela consulta, o número de bytes lidos é calculado com base no tamanho dos tipos de dados do BigQuery. Para informações sobre conversões de tipos de dados, consulte as seguintes páginas:

• Conversões ORC
• Conversões Parquet