Preços do BigQuery

Nesta página, veremos algumas informações sobre preços do BigQuery.

Para informações sobre o BigQuery ML, consulte Preços do BigQuery ML.

Para informações sobre o serviço de transferência de dados do BigQuery, consulte Preços do serviço de transferência de dados do BigQuery.

Visão geral

O BigQuery oferece opções de preços escalonáveis e flexíveis para atender suas necessidades técnicas e seu orçamento.

Os custos de armazenamento são calculados com base na quantidade de dados armazenados no BigQuery. As cobranças de armazenamento podem ser:

  • Ativas: cobrança mensal por dados armazenados em tabelas ou partições que foram modificadas nos últimos 90 dias.
  • De longo prazo: cobrança mensal com valor menor para dados armazenados em tabelas ou partições que não foram modificadas nos últimos 90 dias.

Para custos de consultas, é possível escolher entre dois modelos de preços:

  • Sob demanda: esta é a opção mais flexível. O preço sob demanda é baseado na quantidade de dados processados por cada consulta executada.
  • Preço fixo: essa é a opção de preço ideal para clientes que querem previsibilidade de custos. Os clientes que adquirem o plano de preço fixo compram recursos dedicados para processamento de consultas e não são cobrados por consultas individuais.

Para mais informações sobre preços de armazenamento e de consulta, veja SKUs do Google Cloud Platform (em inglês). Observe que o sistema de preços de consultas sob demanda é denominado preço de análise na página de SKUs.

Resumo de preços

Veja na tabela a seguir um resumo dos preços do BigQuery. As cotas e limites do BigQuery se aplicam a essas operações.

Como é feita a cobrança das taxas

Cada projeto criado tem uma conta de faturamento associada a ele. A cobrança referente aos jobs do BigQuery executados no projeto é realizada na conta de faturamento associada. A cobrança de armazenamento do BigQuery também aparece na conta de faturamento associada.

Como analisar dados de faturamento

É possível visualizar custos e tendências do BigQuery usando a página de relatórios do Faturamento do Cloud, no Console do Cloud. Para informações sobre como analisar dados de faturamento usando relatórios, consulte Visualizar suas tendências de custo com relatórios de faturamento.

Para informações sobre como analisar os dados de faturamento no BigQuery, consulte a seção Exportar os dados de faturamento para o BigQuery na documentação do Faturamento do Cloud.

Operações gratuitas

A tabela a seguir apresenta as operações do BigQuery gratuitas em todos os locais. As cotas e limites do BigQuery se aplicam a essas operações.

OperaçãoDetalhes
Carregar dados

Quando você carrega dados no BigQuery a partir do Cloud Storage, não é cobrado por essa operação de carregamento, apenas pelo armazenamento dos dados no Cloud Storage. Para mais detalhes, consulte Armazenamento de dados na página de preços do Cloud Storage. Após serem carregados no BigQuery, os dados estão sujeitos aos preços de armazenamento do BigQuery. Para mais informações, consulte Como carregar dados no BigQuery.

Ao criar um conjunto de dados no BigQuery, você precisa escolher um local para esses dados. Caso escolha US, você poderá carregar dados em tabelas no conjunto de dados de um bucket do Cloud Storage em qualquer outra região. Atualmente, não há cobrança pela saída de Internet quando dados de outra região são carregados em um conjunto de dados dos EUA.

Se você escolher um local diferente de US, terá que realizar um dos seguintes procedimentos:

  • carregar dados de um bucket do Cloud Storage nessa região (o bucket pode ser multirregional ou regional na mesma região do conjunto de dados);
  • copiar os dados em um bucket nessa região.

Quando dados de uma região do Cloud Storage são copiados para outra, aplicam-se os preços de rede do Cloud Storage.

Copiar dadosVocê não é cobrado pela cópia de uma tabela, mas sim pelo armazenamento da nova tabela e da tabela copiada. Para mais informações, consulte Como copiar uma tabela.
Exportar dadosVocê não é cobrado pela operação de exportação quando dados do BigQuery são exportados para o Cloud Storage, mas é cobrado pelo armazenamento dos dados no Cloud Storage. Para mais detalhes, consulte Armazenamento de dados na página de preços do Cloud Storage. Para mais informações, consulte Como exportar dados do BigQuery.
Excluir conjuntos de dadosNão há cobrança pela exclusão de um conjunto de dados.
Excluir tabelas, visualizações, partições e funçõesVocê não é cobrado pela exclusão de uma tabela, de uma visualização, de partições individuais de uma tabela ou de uma função definida pelo usuário.
Operações de metadadosNão há cobranças por chamadas de list, get, patch, update e delete. Exemplos incluem, entre outros: listagem de conjuntos de dados, atualização de uma lista de controle de acesso de um conjunto de dados, atualização da descrição de uma tabela ou listagem das funções definidas pelo usuário em um conjunto de dados.
Ler pseudocolunasVocê não é cobrado por consultar o conteúdo das seguintes pseudocolunas:

_TABLE_SUFFIX — usada para consultar tabelas de caractere curinga ou conseguir a semântica de decoradores de tabela no SQL padrão
._PARTITIONDATE — usada para consultar tabelas particionadas por tempo de ingestão
._PARTITIONTIME — usada para consultar tabelas particionadas por tempo de ingestão
._FILE_NAME — usada para consultar tabelas baseadas em fontes de dados externas.
Ler metatabelasVocê não é cobrado por consultar o conteúdo das seguintes metatabelas:

__PARTITIONS_SUMMARY__ — usada para conseguir metadados sobre partições em uma tabela particionada normal ou por tempo de ingestão
.__TABLES_SUMMARY__ — usada para conseguir metadados sobre as tabelas e visualizações de um conjunto de dados.
Criar, substituir ou chamar UDFsVocê não é cobrado por criar, substituir ou invocar funções definidas pelo usuário (UDFs, na sigla em inglês) permanentes. No momento, as UDFs permanentes estão na versão Beta, e o preço delas está sujeito a mudanças.

Limites de uso do nível Sempre gratuito

Como parte do Nível gratuito do Google Cloud, o BigQuery oferece alguns recursos gratuitos até um limite específico. Esses limites de uso gratuito estão disponíveis durante e após o período de avaliação gratuita. Se você exceder esses limites de uso e não estiver mais no período de avaliação gratuita, será cobrado de acordo com os preços apresentados nesta página.

RecursoLimites mensais de uso gratuitoDetalhes
ArmazenamentoOs primeiros 10 GB por mês são gratuitos.Os modelos do BigQuery ML e os dados de treinamento armazenados no BigQuery estão incluídos no Nível gratuito de armazenamento da própria ferramenta.
Consultas (análise)O primeiro 1 TB de dados de consulta processados por mês é gratuito.As consultas que usam as funções de previsão, inspeção e avaliação do BigQuery ML estão incluídas no Nível gratuito de análise. Já as consultas do BigQuery ML que contêm instruções CREATE MODEL, não estão.
Os preços fixos do BigQuery também estão disponíveis para clientes de alto volume que preferem um custo mensal estável.
Consultas CREATE MODEL do BigQuery MLOs primeiros 10 GB de dados processados por consultas que contêm instruções CREATE MODEL por mês são gratuitos.As consultas CREATE MODEL do BigQuery ML são independentes do Nível gratuito de análise da ferramenta.

Preços de consultas

Os preços das consultas são referentes ao custo de executar seus comandos SQL e funções definidas pelo usuário, e qualificar as instruções de Linguagem de manipulação de dados (DML, na sigla em inglês) e Linguagem de definição de dados (DDL, na sigla em inglês).

O BigQuery oferece duas opções de modelos de preços:

  • O preço sob demanda é flexível e eficiente. Você paga apenas pelas consultas que executa.
  • O preço fixo oferece custos mensais consistentes e previsíveis.

O padrão de cobrança é o modelo de preços sob demanda. É possível escolher o modelo de preços que atende às suas necessidades. Também é possível combinar os dois modelos de preços para cada projeto e para cada local.

Preços sob demanda

No sistema de preços sob demanda, o BigQuery realiza cobranças por consultas usando uma métrica: o número de bytes processados (também chamados de bytes lidos). Você é cobrado pela quantidade desses bytes, independentemente de os dados estarem armazenados no BigQuery ou em uma fonte de dados externa, como o Cloud Storage, o Google Drive ou o Cloud Bigtable. Os preços de consulta sob demanda são calculados apenas conforme o uso.

O sistema de preços de consulta sob demanda é o seguinte:

Em relação a taxas de consulta, observe os seguintes pontos:

  • O BigQuery usa uma estrutura de dados por coluna. A cobrança é realizada de acordo com o total de dados processados nas colunas selecionadas, e o total de dados por coluna é calculado com base nos tipos desses dados. Para mais informações sobre como o tamanho dos dados é calculado, consulte Cálculo do tamanho dos dados.
  • Você não é cobrado por consultas que retornam um erro ou que recuperam resultados do cache.
  • As cobranças são arredondadas para o MB mais próximo, com um mínimo de 10 MB de dados processados por tabela consultada e com um mínimo de 10 MB de dados processados por consulta.
  • O cancelamento de um job de consulta em execução gera encargos que podem chegar até o custo total da consulta, como se ela tivesse sido concluída.
  • Quando você executa uma consulta, a cobrança é feita de acordo com o total de dados processados nas colunas selecionadas, mesmo que você defina um LIMIT explícito nos resultados.
  • Particionar as tabelas e realizar a clusterização pode reduzir a quantidade de dados processados pelas consultas. Como prática recomendada, use particionamento e clusterização sempre que possível.
  • Na página SKUs do Google Cloud Platform (em inglês), o sistema de preços de consulta sob demanda é chamado de sistema de preços de análise.

Controles de custos de consulta sob demanda

O BigQuery tem mecanismos de controle de custos que permitem fixar um limite para os custos de consultas. É possível definir:

Como consultar dados do Cloud Storage

Ao consultar uma fonte de dados externa a partir do BigQuery, a cobrança é aplicada pelo número de bytes lidos pela consulta. Para mais informações, veja Preços de consultas. Você também é cobrado pelo armazenamento de dados no Cloud Storage. Para mais informações, consulte Preços do Cloud Storage.

Como consultar formatos de coluna no Cloud Storage

Se os dados externos forem armazenados no ORC ou no Parquet, o número de bytes cobrados será limitado às colunas lidas pelo BigQuery. Como a consulta converte os tipos de dados de uma fonte de dados externa em tipos de dados do BigQuery, 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, acesse as seguintes páginas:

Preços para dados particionados externamente no Cloud Storage

Há uma cobrança adicional para consultar tabelas particionadas do Hive armazenadas no Cloud Storage.

O BigQuery calcula a quantidade total, em bytes, dos tamanhos dos nomes de arquivo não reduzidos. A cobrança total do particionamento do Hive é arredondada até o MB mais próximo, com um mínimo de 10 MB de dados processados por tabela particionada do Hive incluída na consulta.

Preço fixo

O BigQuery oferece preços fixos para clientes que preferem contar com um custo estável de consultas em vez de pagar o preço sob demanda por TB de dados processados.

Escolha usar o sistema de preços fixos com Reservas do BigQuery.

Ao se inscrever no sistema de preços fixos, você adquire compromissos de slots, ou seja, uma capacidade dedicada de processamento de consultas medida em slots do BigQuery. As consultas consomem essa capacidade e não há cobrança por bytes processados. Se as demandas por capacidade ultrapassarem a capacidade adquirida, os slots serão colocados em fila pelo BigQuery e não haverá cobrança de outras taxas. Para mais detalhes sobre como os slots são utilizados pelo BigQuery para o processamento de consultas, acesse Slots do BigQuery.

No caso do preço fixo:

  • aplica-se a custos de consulta, incluindo instruções DDL, DML e do BigQuery ML;
  • não se aplica a custos de armazenamento, de ingestão de streaming ou do BI Engine;
  • é comprado como um recurso regional. Os compromissos de slots adquiridos em uma ou várias regiões precisam ser usados nela e não podem ser movidos;
  • permite que os clientes aumentem as cotas simultâneas por projeto ao entrar em contato com o suporte do Google Cloud Platform;
  • está disponível em compromissos por segundo, mensais e anuais;
  • pode ser compartilhado na organização inteira. Não é necessário adquirir compromissos de slots para cada projeto.
  • é comprado em incrementos de 500 slots;
  • é cobrado por segundo de acordo com a duração do seu compromisso.

Os compromissos de slots não estão disponíveis em todas as regiões. No entanto, em breve estarão em mais algumas. Para mais detalhes, entre em contato com seu representante de vendas.

Compromissos fixos mensais

Na tabela a seguir, mostramos o custo do seu compromisso de slot mensal.

Compromissos fixos anuais

Na tabela a seguir, mostramos o custo do seu compromisso de slot anual.

Slots flexíveis: compromisso de curto prazo (Beta)

Os slots flexíveis fazem parte de um tipo especial de compromisso:

  • O compromisso dura apenas 60 segundos.
  • É possível cancelar slots flexíveis a qualquer momento.
  • Você receberá a cobrança apenas pelos segundos de atividade do seu compromisso.

Na tabela a seguir, mostramos o custo dos seus compromissos de slot flexível.

Preço de armazenamento

Ao carregar seus dados no BigQuery, você será cobrado pelo armazenamento. O preço de armazenamento tem como base a quantidade de dados armazenados nas suas tabelas quando eles são descompactados.

O tamanho dos dados é calculado com base nos tipos de dados de cada coluna. Para uma explicação detalhada sobre como o tamanho dos dados é calculado, consulte Cálculo do tamanho dos dados.

Armazenamento ativo

As taxas de armazenamento ativo são estas:

Os preços de armazenamento são rateados por MB, por segundo. Por exemplo, ao armazenar:

  • 100 MB pela metade de um mês: você paga US$ 0,001 (um décimo de centavo);
  • 500 GB pela metade de um mês, você paga US$ 5;
  • 1 TB por um mês completo, você paga US$ 20.

Armazenamento de longo prazo

Se uma tabela não for editada por 90 dias consecutivos, o preço de armazenamento para ela cairá automaticamente em aproximadamente 50%. Não há degradação de desempenho, durabilidade, disponibilidade ou outra funcionalidade quando uma tabela é considerada de armazenamento de longo prazo.

As taxas para o armazenamento de longo prazo são estas:

Se a tabela for editada, o preço será revertido para o valor de armazenamento regular e o contador de 90 dias será reiniciado. Qualquer ação que modifique os dados de uma tabela reinicia o contador, incluindo:

Detalhesda Ação
Carregar dados em uma tabelaQualquer job de carregamento ou de consulta que anexe dados a uma tabela de destino ou substitua uma tabela de destino.
Copiar dados para uma tabelaQualquer job de cópia que anexe dados a uma tabela de destino ou substitua uma tabela de destino.
Gravar resultados de consultas em uma tabelaQualquer job de consulta que anexe dados a uma tabela de destino ou substitua uma tabela de destino.
Usar a linguagem de manipulação de dados (DML)Usar uma instrução DML para modificar os dados da tabela.
Usar a linguagem de definição de dados (DDL)Usar uma instrução DDL `CREATE OR REPLACE TABLE` para substituir uma tabela.
Streaming de dados para a tabelaIngestão de dados usando a chamada de API tabledata.insertAll.

Todas as outras ações não reiniciam o contador, incluindo estas:

  • Consultar uma tabela
  • Criar uma visualização que consulta uma tabela
  • Exportar dados de uma tabela
  • Copiar uma tabela (para outra tabela de destino)
  • Corrigir ou atualizar um recurso de tabela

Para o preço de armazenamento de longo prazo, cada partição de uma tabela particionada é analisada separadamente. Se uma partição não foi modificada nos últimos 90 dias, os dados dela são considerados de armazenamento a longo prazo e a cobrança é realizada conforme o preço com desconto.

Para tabelas que alcançam o limite de 90 dias durante um ciclo de faturamento, o preço é rateado de acordo.

Os preços de armazenamento de longo prazo se aplicam apenas ao armazenamento do BigQuery, e não aos dados armazenados em fontes de dados externas, como Cloud Bigtable, Cloud Storage e Google Drive.

Preços da API BigQuery Storage

A API BigQuery Storage tem um modelo de preço sob demanda. A cobrança é feita de acordo com os dados lidos. Os clientes que adquiriram o plano de preços fixos podem usar a API BigQuery Storage para ler até 300 TB de dados por mês sem custos. Quando esse limite mensal é ultrapassado, a cobrança do valor excedido é feita de acordo com a taxa sob demanda.

Preços sob demanda

No sistema de preços sob demanda, a cobrança da API BigQuery Storage é feita de acordo com a quantidade de bytes lidos do armazenamento do BigQuery por chamadas para ReadRows.

O número de bytes lidos inclui os dados usados para filtragem, mas não retornados a você como resposta de ReadRows. Não há cobrança pelos dados lidos de tabelas temporárias.

Veja a seguir as cobranças sob demanda da API BigQuery Storage:

Veja as seguintes cobranças da API BigQuery Storage:

  • Você é cobrado de acordo com o volume total de dados lidos. A quantidade total de dados lidos por coluna é calculada com base no tipo dos dados da coluna, assim como o tamanho dos dados. Para uma explicação detalhada sobre como o tamanho dos dados é calculado, consulte Cálculo do tamanho dos dados.
  • Você será cobrado por todos os dados lidos em uma sessão, mesmo que ocorra falha na chamada ReadRows.
  • Se você cancelar uma chamada ReadRows antes do fim do stream, será cobrado por todos os dados lidos antes do cancelamento. As cobranças podem incluir dados lidos, mas não retornados a você antes do cancelamento da chamada ReadRows.
  • Como prática recomendada, use tabelas particionadas e clusterizadas sempre que possível. É possível diminuir a quantidade de dados lidos usando uma cláusula WHERE para reduzir as partições. Para mais informações, consulte Como consultar tabelas particionadas.

Cálculo do tamanho dos dados

Quando os dados são carregados no BigQuery ou consultados, a cobrança é realizada de acordo com o tamanho deles. O cálculo do tamanho dos dados é baseado no tamanho do tipo de dados de cada coluna.

O tamanho dos dados armazenados e dos dados processados pelas consultas é calculado em gigabytes (GB), em que 1 GB equivale a 230 bytes. Essa unidade de medida também é conhecida como gibibyte (GiB). Da mesma forma, 1 TB equivale a 240 bytes (1.024 GB).

Veja a seguir o tamanho dos tipos de dados do BigQuery:

Tipo de dadoTamanho
INT64/INTEGER8 bytes
FLOAT64/FLOAT8 bytes
NUMERIC16 bytes
BOOL/BOOLEAN1 byte
STRING2 bytes + o tamanho da string codificada em UTF-8
BYTES2 bytes + o número de bytes no valor
DATE8 bytes
DATETIME8 bytes
TIME8 bytes
TIMESTAMP8 bytes
STRUCT/RECORD0 byte + o tamanho dos campos contidos
GEOGRAPHY16 bytes + 24 bytes * o número de vértices no tipo de geografia (use a função ST_NumPoints para verificar o número de vértices)

Valores nulos para qualquer tipo de dado são calculados como 0 byte.

Uma coluna repetida é armazenada como uma matriz, e seu tamanho é calculado com base no número de valores. Por exemplo, uma coluna de números inteiros (INT64) que é repetida (ARRAY<INT64>) e contém 4 entradas é calculada com o tamanho de 32 bytes (4 entradas x 8 bytes).

Preços de streaming

O carregamento de dados no BigQuery é gratuito, exceto por uma pequena taxa cobrada por dados transferidos por streaming.

Veja a seguir as taxas para inserções de streaming:

Preços para DML

O BigQuery cobra por consultas DML com base no número de bytes processados pela consulta.

Preços para DML em tabelas não particionadas

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

Instrução DMLBytes processados
INSERTA soma dos bytes processados de todas as colunas referenciadas nas tabelas verificadas pela consulta.
UPDATEA soma dos bytes de todas as colunas referenciadas das tabelas verificadas pela consulta
+ a soma dos bytes de todas as colunas na tabela atualizada no momento em que a instrução UPDATE é iniciada.
DELETEA soma dos bytes de todas as colunas referenciadas das tabelas verificadas pela consulta
+ a soma dos bytes de todas as colunas na tabela modificada no momento em que a instrução DELETE é iniciada.
MERGESe houver apenas cláusulas INSERT na instrução MERGE, você será cobrado pela soma dos bytes processados de todas as colunas referenciadas em todas as tabelas verificadas pela consulta.
Se houver uma cláusula UPDATE ou DELETE na instrução MERGE, você será cobrado pela soma dos bytes processados de todas as colunas referenciadas nas tabelas de origem verificadas pela consulta
+ a soma dos bytes de todas as colunas na tabela de destino (no momento em que a instrução MERGE é iniciada).

Preços para DML em tabelas particionadas

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

Instrução DMLBytes processados
INSERTA soma dos bytes processados de todas as colunas referenciadas em todas as partições verificadas pela consulta.
UPDATEA soma dos bytes processados de todas as colunas referenciadas em todas as partições das tabelas verificadas pela consulta
+ a soma dos bytes de todas as colunas nas partições atualizadas ou verificadas da tabela que está sendo atualizada (no momento em que a instrução UPDATE é iniciada).
DELETEA soma dos bytes processados de todas as colunas referenciadas em todas as partições das tabelas verificadas pela consulta
+ a soma dos bytes de todas as colunas nas partições modificadas ou verificadas da tabela que está sendo modificada (no momento em que a instrução DELETE é iniciada).
MERGESe houver apenas cláusulas INSERT na instrução MERGE, você será cobrado pela soma dos bytes processados de todas as colunas referenciadas em todas as partições verificadas pela consulta.
Se houver uma cláusula UPDATE ou DELETE na instrução MERGE, você será cobrado pela soma dos bytes processados de todas as colunas referenciadas em todas as partições para as tabelas de origem verificadas pela consulta
+ a soma dos bytes de todas as colunas nas partições atualizadas, excluídas ou verificadas para a tabela de destino (no momento em que a instrução MERGE é iniciada).

Preços para Linguagem de definição de dados

O BigQuery cobra pelas consultas DDL baseando-se no número de bytes processados pela consulta. Esse número é calculado da seguinte forma para instruções DDL:

Instrução DDLBytes processados
CREATE TABLENenhum.
CREATE TABLE ... AS SELECT ...A soma dos bytes processados de todas as colunas referenciadas nas tabelas verificadas pela consulta.
CREATE VIEWNenhum.
DROP TABLENenhum.
DROP VIEWNenhum.

Preços de tabelas clusterizadas

Ao criar e usar tabelas clusterizadas no BigQuery, as cobranças são baseadas na quantidade de dados armazenados nas tabelas e nas consultas de dados executadas. As tabelas clusterizadas ajudam a reduzir os custos das consultas ao diminuir a quantidade de dados para que eles não sejam processados pela consulta. Esse processo é chamado de remoção de blocos.

Remoção de blocos

O BigQuery classifica os dados em uma tabela clusterizada baseando-se nos valores das colunas em cluster e os organiza em blocos.

Quando você envia uma consulta que contém um filtro em uma coluna clusterizada, o BigQuery usa as informações agrupadas para determinar com eficiência se há dados relevantes para a consulta em determinado bloco. Desse modo, o BigQuery consegue analisar apenas os blocos relevantes. Esse processo é conhecido como remoção de blocos.

O preço da consulta é baseado no número de bytes processados. Quando você executa uma consulta em uma tabela clusterizada e essa consulta inclui um filtro nas colunas clusterizadas, o BigQuery usa a expressão de filtro e os metadados do bloco para remover os blocos verificados pela consulta.

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

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

Preços de scripts

beta feature BigQuery support for scripting

Na versão Beta de scripts do Big Query, a equipe do BigQuery recomenda usar projetos com reservas de preço fixo para evitar custos não intencionais de consulta, já que antes da execução o número de bytes verificados por um script é desconhecido. Como alternativa, é possível usar o sandbox do BigQuery para aproveitar a execução limitada de scripts gratuitamente. Ao longo do tempo, a equipe do BigQuery dará mais controle explícito sobre o total de bytes verificados por scripts e por instruções individuais dentro de scripts. Esta é uma versão Beta. Para ver as atualizações de preços, consulte as notas de versão do BigQuery.

Mesmo se um script falhar, o custo das instruções até o momento da falha ainda será válido. Instruções falhas não geram cobrança adicional.

O preço de execução para tipos de instruções públicas como SELECT, INSERT, UPDATE, entre outros, é descrito na documentação pública de preços. Os seguintes preços se aplicam aos tipos de instruções específicas de scripts:

  • DECLARE: a soma dos bytes verificados para quaisquer tabelas referenciadas na 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. As instruções SET sem referências de tabela não geram custo.
  • IF: a soma dos bytes verificados para quaisquer tabelas referenciadas na expressão condicional. As expressões condicionais IF sem referências de tabela não geram custo. As instruções no bloco IF que não forem executadas não geram custo.
  • WHILE: a soma dos bytes verificados para quaisquer tabelas referenciadas pela expressão condicional. As instruções WHILE sem referências de tabela na expressão condicional não geram custo. As instruções no bloco WHILE que não forem executadas não geram custo.
  • CONTINUE/ITERATE: sem custo associado.
  • BREAK/LEAVE: sem custo associado.
  • BEGIN/END: sem custo associado.

Tabelas temporárias não geram custo de armazenamento enquanto o script é executado. Porém, se as instruções criarem, modificarem ou consultarem as tabelas, será cobrado o preço normal.

Exemplos de preços do BigQuery

Como estimar custos de consultas

Para conferir exemplos de preços de consultas, veja Como estimar custos de consultas.

Como estimar custos de armazenamento

Para conferir exemplos de preços de armazenamento, consulte Como estimar custos de armazenamento.

Exemplos de preços para DML em tabelas não particionadas

Veja nos exemplos a seguir como o BigQuery calcula bytes lidos para instruções DML que modificam tabelas não particionadas.

Exemplo 1: UPDATE em tabela não particionada

table1 tem duas colunas: col1 do tipo INTEGER e col2 do tipo STRING.

UPDATE table1 SET col1 = 1 WHERE col2 = 2;

Bytes processados neste exemplo =

  • soma do número de bytes na col1 +
  • soma do número de bytes na col2

Exemplo 2: UPDATE em tabela não particionada

table1 tem duas colunas: col1 do tipo INTEGER e col2 do tipo STRING. table2 tem uma coluna: field1 do tipo INTEGER.

UPDATE table1 SET col1 = 1 WHERE col1 in (SELECT field1 from table2)

Bytes processados neste exemplo =

  • soma do número de bytes na table1.col1 antes de UPDATE +
  • soma do número de bytes na table1.col2 antes de UPDATE +
  • soma do número de bytes na table2.field1

Exemplos de preços para DML em tabelas particionadas

Veja nos exemplos a seguir como o BigQuery calcula bytes lidos para instruções DML que modificam tabelas particionadas e de tempo de ingestão. Para visualizar as representações de esquema JSON nas tabelas dos exemplos, consulte Tabelas usadas nos exemplos na página "Como atualizar dados de uma tabela particionada por meio de instruções DML".

Exemplo 1: INSERT em tabela particionada por tempo de ingestão

mytable2 tem duas colunas: id do tipo INTEGER e ts do tipo TIMESTAMP. mytable tem duas colunas: field1 do tipo INTEGER e field2 do tipo STRING.

INSERT INTO mytable (_PARTITIONTIME, field1) AS SELECT TIMESTAMP(DATE(ts)), id from mytable2

Bytes processados neste exemplo =

  • soma do número de bytes na mytable2.ts +
  • soma do número de bytes na mytable2.id

O tamanho da tabela em que as linhas são inseridas (mytable) não afeta o custo da consulta.

Exemplo 2: INSERT em tabela particionada

mytable2 tem duas colunas: id do tipo INTEGER e ts do tipo TIMESTAMP. mycolumntable tem quatro colunas: field1 do tipo INTEGER, field2 do tipo STRING, field3 do tipo BOOLEAN e ts do tipo TIMESTAMP.

INSERT INTO mycolumntable (ts, field1) AS SELECT ts, id from mytable2

Bytes processados neste exemplo =

  • soma do número de bytes na mytable2.ts +
  • soma do número de bytes na mytable2.id

O tamanho da tabela em que as linhas são inseridas (mycolumntable) não afeta o custo da consulta.

Exemplo 3: UPDATE em tabela particionada por tempo de ingestão

Instrução DML 1: atualização de uma única partição

mytable2 tem duas colunas: id do tipo INTEGER e ts do tipo TIMESTAMP. mytable tem duas colunas: field1 do tipo INTEGER e field2 do tipo STRING.

UPDATE project.mydataset.mytable T SET T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Bytes processados neste exemplo =

  • soma do número de bytes na mytable2.id +
  • soma do número de bytes em mytable.field1 na partição "2017-05-01" +
  • soma do número de bytes em mytable.field2 na partição "2017-05-01"

Instrução DML 2: atualização de uma partição com base em outra partição na tabela

UPDATE project.mydataset.mytable T SET T._PARTITIONTIME = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT 1 from project.mydataset.mytable S WHERE S.field1 = T.field1 AND S._PARTITIONTIME = TIMESTAMP("2017-06-01") )

Bytes processados neste exemplo =

  • soma do número de bytes em mytable.field1 na partição "2017-05-01" +
  • soma do número de bytes em mytable.field2 na partição "2017-05-01" +
  • soma do número de bytes em mytable.field1 na partição "2017-06-01" +
  • soma do número de bytes em mytable.field2 na partição "2017-06-01"

Nesse caso, o custo da instrução UPDATE é a soma dos tamanhos de todos os campos nas partições correspondentes a "2017-05-01" e "2017-06-01".

Exemplo 4: UPDATE em tabela particionada

Instrução DML 1: atualização de uma única partição

mytable2 tem duas colunas: id do tipo INTEGER e ts do tipo TIMESTAMP. mycolumntable tem quatro colunas: field1 do tipo INTEGER, field2 do tipo STRING, field3 do tipo BOOLEAN e ts do tipo TIMESTAMP.

UPDATE project.mydataset.mycolumntable T SET T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Bytes processados neste exemplo =

  • soma do número de bytes em mytable2.id +
  • soma do número de bytes em mycolumntable.field1 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.field2 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.field3 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.ts na partição "2017-05-01"

Instrução DML 2: atualização de uma partição com base em outra partição na tabela

UPDATE project.mydataset.mycolumntable T SET T.ts = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT 1 from project.mydataset.mycolumntable S WHERE S.field1 = T.field1 AND DATE(S.ts) = "2017-06-01")

Bytes processados neste exemplo =

  • soma do número de bytes em mycolumntable.field1 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.field2 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.field3 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.ts na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.field1 na partição "2017-06-01" +
  • soma do número de bytes em mycolumntable.field2 na partição "2017-06-01" +
  • soma do número de bytes em mycolumntable.field3 na partição "2017-06-01" +
  • soma do número de bytes em mycolumntable.ts na partição "2017-06-01"

Nesse caso, o custo da instrução UPDATE é a soma dos tamanhos de todos os campos nas partições correspondentes a "2017-05-01" e "2017-06-01".

Exemplo 5: DELETE em tabela particionada por tempo de ingestão

mytable2 tem duas colunas: id do tipo INTEGER e ts do tipo TIMESTAMP. mytable tem duas colunas: field1 do tipo INTEGER e field2 do tipo STRING.

DELETE project.mydataset.mytable T WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Bytes processados neste exemplo =

  • soma do número de bytes em mytable2.id +
  • soma do número de bytes em mytable.field1 na partição "2017-05-01" +
  • soma do número de bytes em mytable.field2 na partição "2017-05-01"

Exemplo 6: DELETE em tabela particionada

mytable2 tem duas colunas: id do tipo INTEGER e ts do tipo TIMESTAMP. mycolumntable tem quatro colunas: field1 do tipo INTEGER, field2 do tipo STRING, field3 do tipo BOOLEAN e ts do tipo TIMESTAMP.

DELETE project.mydataset.mycolumntable T WHERE DATE(T.ts) =“2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Bytes processados neste exemplo =

  • soma do número de bytes em mytable2.id +
  • soma do número de bytes em mycolumntable.field1 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.field2 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.field3 na partição "2017-05-01" +
  • soma do número de bytes em mycolumntable.ts na partição "2017-05-01"

Exemplo de preço de tabela clusterizada

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

Identificador de partiçãoID do blocoValor mínimo para customer_id no blocoValor máximo para customer_id no bloco
20160501B11000019999
20160501B22000024999
20160502B31500017999
20160501B42200027999

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 23000 na coluna de clusterização customer_id.

Exemplo de preços de scripts

O exemplo de script a seguir contém comentários acima de cada instrução que explicam quais são os custos dessas instruções se for o caso.

-- 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
    -- script 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;