Preço

Visão geral

O BigQuery oferece opções de preços escalonáveis e flexíveis para atender às suas necessidades técnicas e ao 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: uma cobrança mensal por dados armazenados em tabelas ou partições que foram modificadas nos últimos 90 dias.
  • De longo prazo: uma cobrança mensal mais baixa 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 é calculado com base na quantidade de dados processados em cada consulta executada.
  • Preço fixo: essa é a opção de preço ideal para clientes que querem previsibilidade de custos. Os clientes com preço fixo compram recursos dedicados para processamento de consultas e não recebem cobranças por consultas individuais.

Para mais informações sobre preços de armazenamento e de consulta, veja SKUs do Google Cloud. Observe que o preço de consulta sob demanda é denominado preço de análise na página de SKUs.

Resumo dos preços

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

Como é feita a cobrança das taxas

Cada projeto criado tem uma conta de faturamento associada a ele. A cobrança de todos os valores referentes a jobs do BigQuery executados no projeto é realizada na conta de faturamento associada. A cobrança de armazenamento do BigQuery também é realizada 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 por meio de relatórios, consulte Visualizar relatórios de faturamento e tendências de custo.

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

Operações gratuitas

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

Operação Detalhes
Carregando dados

Não há cobranças pelo carregamento dos dados do Cloud Storage ou dos arquivos locais no BigQuery. Mas haverá cobrança pelo armazenamento de dados no Cloud Storage. Para mais detalhes, consulte Armazenamento de dados na página "Preços do Cloud Storage". Assim que os dados estiverem carregados no BigQuery, estarão sujeitos aos preços de armazenamento do BigQuery.

Se o conjunto de dados de destino estiver localizado na multirregião US, não haverá cobrança por saída de rede ao carregar de um bucket do Cloud Storage para qualquer outra região. Para mais informações, consulte Considerações de localização.

Como copiar dados Não há cobrança pela cópia de uma tabela, mas há cobrança pelo armazenamento da nova tabela e da tabela copiada. Para mais informações, consulte Como copiar uma tabela.
Exportação de dados Não há cobrança pela operação de exportação quando são exportados dados do BigQuery para o Cloud Storage, mas há cobrança pelo armazenamento dos dados no Cloud Storage. Para mais detalhes, consulte Armazenamento de dados na página "Preços do Cloud Storage". Para mais informações, consulte Como exportar dados do BigQuery.
Exclusão de conjuntos de dados Não há cobrança pela exclusão de um conjunto de dados.
Exclusão de tabelas, visualizações, partições e funções Não há cobranças 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 metadados Nã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.
Leitura de pseudocolunas Não há cobranças pela consulta do conteúdo das seguintes pseudocolunas:

_TABLE_SUFFIX: usada para consultar tabelas de caracteres curinga
_PARTITIONDATE: usada ao consultar tabelas particionadas por tempo de processamento
_PARTITIONTIME: usada ao consultar tabelas particionadas por tempo de processamento
_FILE_NAME: usada ao consultar tabelas baseadas em fontes de dados externas
Leitura de metatabelas Não há cobrança para consultar o conteúdo das seguintes metatabelas:

__PARTITIONS_SUMMARY__ — usada para conseguir metadados sobre partições em uma tabela particionada ou em uma tabela particionada por tempo de processamento
__TABLES_SUMMARY__ — usada para conseguir metadados sobre as tabelas e visualizações de um conjunto de dados
Criação, substituição ou chamada de UDFs Não há cobrança para criar, substituir ou invocar funções permanentes definidas pelo usuário (UDFs).

Limites de uso do programa 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 teste gratuito. Se você exceder esses limites e não estiver mais no período de teste, a cobrança será feita de acordo com os preços apresentados nesta página.

Recurso Limites mensais de uso gratuito Detalhes
Armazenamento Os 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 próprio nível gratuito de armazenamento da 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 dele. Já as consultas do BigQuery ML que contêm instruções CREATE MODEL não estão incluídas.
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 ML Os 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 e aplicam-se somente a modelos integrados do BigQuery ML (modelos que são treinados dentro do BigQuery).

Preços de consultas

Os preços da consulta são referentes ao custo de executar seus comandos SQL e funções definidas pelo usuário e qualificar instruções de linguagem de manipulação de dados (DML) e de linguagem de definição de dados (DDL).

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.

Por padrão, as cobranças são feitas de acordo com o modelo de preços sob demanda. É possível alterar o modelo de faturamento para o de taxa fixa ou escolher entre faturamento sob demanda e taxa fixa em cada combinação específica de projeto e local.

Preços sob demanda

Em 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ê será cobrado por esses bytes, mesmo se os dados estiverem armazenados no BigQuery ou em uma fonte de dados externa, como Cloud Storage, Drive ou Cloud Bigtable. Os preços das consultas 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 por coluna é calculado com base nos tipos de dados dela. Para mais informações sobre como o tamanho dos dados é calculado, consulte Cálculo do tamanho dos dados.
  • Não há cobranças 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 por consulta.
  • O cancelamento de um job de consulta em execução gera encargos que podem chegar até o custo total dela, como se a consulta 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 o clustering nelas pode reduzir a quantidade de dados processados pelas consultas. Como prática recomendada, use particionamento e clustering sempre que possível.
  • O preço de consulta sob demanda é denominado "preço de análise" na página SKUs do Google Cloud.

Controles de custos de consulta sob demanda

O BigQuery tem mecanismos de controle que permitem limitar os custos das consultas. É possível definir:

Como consultar dados do Cloud Storage

Na consulta de uma fonte de dados externa do BigQuery, a cobrança é aplicada pelo número de bytes lidos. Para mais informações, veja Preços de consulta. Há cobrança 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 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:

Preços fixos

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, compre compromissos de slots, ou seja, capacidade exclusiva para o processamento de consultas medida em slots do BigQuery. As consultas consomem essa capacidade sem gerar cobrança por bytes processados. Se as demandas por capacidade ultrapassarem a capacidade adquirida, os slots serão enfileirados pelo BigQuery, e não haverá outras cobranças. Consulte Slots para mais informações sobre como o BigQuery usa os slots no processamento de consultas.

O sistema de preços fixos:

  • 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 não podem ser usados em outra região ou várias regiões e não podem ser movidos;
  • permite que os clientes aumentem as cotas de simultaneidade por projeto entrando em contato com o suporte do Google Cloud;
  • está disponível em compromissos por segundo, mensais e anuais;
  • pode ser compartilhado na organização inteira. Não é necessário comprar compromissos de slot para cada projeto;
  • tem, no mínimo, 100 slots e é comprado em incrementos de 100 slots;
  • é cobrado por segundo de acordo com a duração do seu compromisso.

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: compromissos de curto prazo

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.

Os slots flexíveis estão sujeitos à disponibilidade de capacidade. Não garantimos que as tentativas de compra desses recursos serão bem-sucedidas. No entanto, quando você conseguir comprar um compromisso, a capacidade será garantida até o cancelamento.

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

Slots de avaliação (promoção)

No dia 20 de maio de 2020, o BigQuery apresentou uma promoção limitada para clientes novos e antigos da ferramenta. Os clientes que se qualificam podem comprar Slots de avaliação, que garantem um compromisso de 500 slots durante seis meses por uma taxa promocional.

Slots de avaliação têm o seguinte comportamento:

  • É necessário se comprometer por um período de seis meses.
  • Não é possível fazer o cancelamento nos primeiros 182 dias a partir do momento da compra.
  • Só é possível comprar 500 slots.
  • É possível comprar outros tipos de compromisso e combiná-los aos slots de avaliação.
  • Os slots de avaliação estão disponíveis apenas nos Estados Unidos e em multirregiões da Europa.
  • Esses slots têm disponibilidade limitada e são oferecidos por ordem de chegada.
  • Não há diferenças de desempenho ou disponibilidade entre slots de avaliação e outros tipos de compromissos de slot.

Os slots de avaliação estão sujeitos a critérios de qualificação e estão disponíveis para estes clientes:

  • Novos clientes do Google Cloud que se inscreverem no BigQuery.
  • Clientes atuais do Google Cloud que se inscreverem no BigQuery.
  • Clientes atuais do BigQuery que não excederam US$ 500 por mês de gastos totais nos últimos três meses.
  • Clientes que se inscreveram usando o endereço de e-mail da própria empresa
  • A oferta está disponível apenas para compras feitas diretamente no Google. Não é possível fazer a compra por meio de revendedores ou distribuidores.

Para mais informações sobre como os slots de avaliação funcionam, consulte Slots de avaliação.

Para participar desta promoção, preencha o formulário de promoção de slots de avaliação do BigQuery. Entraremos em contato com você em até cinco dias úteis.

Preços de armazenamento

Quando seus dados forem carregados no BigQuery, a cobrança será realizada conforme o armazenamento. O preço de armazenamento é baseado na quantidade de dados armazenados em suas tabelas quando estes são descompactados.

O tamanho dos dados é calculado com base nos tipos de dados das colunas individuais. 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 mais ou menos 50%. Não há degradação de desempenho, durabilidade, disponibilidade ou outra funcionalidade quando uma tabela é considerada de armazenamento de longo prazo.

Para o preço de armazenamento de longo prazo, cada partição de uma tabela fracionada é analisada separadamente. Se uma partição não foi modificada nos últimos 90 dias, os dados nela são considerados armazenamento em longo prazo e são cobrados pelo preço com desconto.

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

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

Ação Detalhes
Carregar dados em uma tabela Qualquer job de carregamento ou de consulta que anexe dados a uma tabela de destino ou substitua uma tabela de destino.
Copiar dados para uma tabela Qualquer job de cópia que anexe dados a uma tabela de destino ou a substitua.
Gravar resultados de consultas em uma tabela Qualquer job de consulta que anexe dados a uma tabela de destino ou a substitua.
Usar a linguagem de manipulação de dados (DML, na sigla em inglês) 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 tabela Ingestã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 tabelas que alcançam o limite de 90 dias durante um ciclo de faturamento, o preço é rateado de acordo.

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

Preços da API BigQuery Storage

A API BigQuery Storage tem um modelo de preço sob demanda. A cobrança é feita pelos dados lidos. Os clientes que se inscreveram em um sistema de preços de taxa fixa podem usar a API BigQuery Storage para ler até 300 TB de dados por mês sem custos. Quando a leitura ultrapassa esse limite mensal de 300 TB, 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 o número de bytes lidos do armazenamento do BigQuery por chamadas para ReadRows.

O número de bytes lidos inclui os dados usados para filtrar, mas não retornados a você como saída 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. O total e o tamanho dos dados lidos por coluna são calculados conforme o tipo de dados na coluna. Para uma explicação detalhada sobre como o tamanho dos dados é calculado, consulte esta página.
  • 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, haverá cobrança por todos os dados lidos antes do cancelamento. As cobranças podem incluir dados lidos, mas não retornados a você depois do cancelamento da chamada ReadRows.
  • Como prática recomendada, use tabelas particionadas e em cluster sempre que possível. É possível reduzir a quantidade de dados lidos usando uma cláusula WHERE para remover as partições. Para mais informações, consulte Como consultar tabelas particionadas.

Cálculo do tamanho dos dados

Quando você carrega ou consulta dados no BigQuery, a cobrança é realizada de acordo com o tamanho dos dados. O cálculo do tamanho dos dados é feito com base 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 representa 230 bytes. Esta unidade de medida também é conhecida como gibibyte (GiB). Da mesma forma, 1 TB equivale a 240 bytes, ou seja, 1.024 GB.

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

Tipo de dado Tamanho
INT64/INTEGER 8 bytes
FLOAT64/FLOAT 8 bytes
NUMERIC 16 bytes
BOOL/BOOLEAN 1 byte
STRING 2 bytes + o tamanho da string codificada em UTF-8
BYTES 2 bytes + o número de bytes no valor
DATE 8 bytes
DATETIME 8 bytes
TIME 8 bytes
TIMESTAMP 8 bytes
STRUCT/RECORD 0 byte + o tamanho dos campos contidos
GEOGRAPHY 16 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 o tamanho é calculado com base no número de valores. Por exemplo, uma coluna inteira (INT64) que é repetida (ARRAY<INT64>) e contém quatro entradas é calculada como 32 bytes (4 entradas x 8 bytes).

Preços de streaming

O carregamento de dados no BigQuery é gratuito, com exceção de uma pequena taxa por dados transferidos por streaming.

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

Preços para linguagem de manipulação de dados

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 DML Bytes processados
INSERT A soma dos bytes processados de todas as colunas referenciadas nas tabelas verificadas pela consulta.
UPDATE A 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.
DELETE A 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.
MERGE Se 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

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

Instrução DML Bytes processados
INSERT A soma dos bytes processados de todas as colunas referenciadas em todas as partições verificadas pela consulta.
UPDATE A 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).
DELETE A 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).
MERGE Se 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 com base no número de bytes processados pela consulta. Esse número é calculado da seguinte forma para instruções DDL:

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.

Preços de tabelas em cluster

Quando você cria e usa tabelas em cluster no BigQuery, as cobranças são baseadas na quantidade de dados armazenados nas tabelas e nas consultas de dados executadas. 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ê envia uma consulta que contém um filtro em uma coluna em cluster, o BigQuery usa as informações do cluster para determinar com eficiência se há dados relevantes para a consulta em um bloco. Desse modo, o BigQuery analisa somente os blocos relevantes, um 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 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.

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.

Preços de script

Na versão Beta de scripts do BigQuery, a equipe do BigQuery recomenda usar projetos com reserva por preço fixo para evitar custos não intencionais de consulta, já que o número de bytes verificados por um script não é conhecido antes de ele ser executado. Como alternativa, é possível usar o sandbox do BigQuery para execução de scripts grátis e limitada. No futuro, 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 da versão do BigQuery.

Se um script falhar, as instruções serão cobradas até o momento da falha. Instruções falhas não geram cobrança adicional.

O preço de execução para instruções públicas como SELECT, INSERT e UPDATE, é descrito na documentação de preço para o público. Os seguintes preços se aplicam às instruções específicas para script:

  • 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 o script estiver em execução. 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 exemplos de preços de consultas, acesse Como estimar custos de consultas.

Como estimar custos de armazenamento

Para 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. Para visualizar as representações de esquema JSON nas tabelas dos exemplos, consulte Tabelas usadas nos exemplos na página "Como atualizar dados de tabela particionada com 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 mytable, em que as linhas são inseridas, 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 mycolumntable, em que as linhas são inseridas, não afeta o custo da consulta.

Exemplo 3: UPDATE em tabela particionada por tempo de processamento

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 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"

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 processamento

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ç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.

Exemplo dos preços de script

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