Preços do BigQuery

Para preços do BigQuery, consulte esta página.

Para o BigQuery ML, consulte a página Preços do BigQuery ML.

Para o serviço de transferência de dados do BigQuery, consulte a página 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 à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: esta opção de preços previsível é mais indicada para clientes com orçamento fixo. 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 consulta, veja SKUs do Google Cloud Platform. Observe que o sistema de preços de consultas sob demanda é denominado preço de análise na página das 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 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 os custos e tendências do BigQuery usando a página "Relatórios de faturamento da nuvem" no Console do GCP. 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 Exportar os dados de faturamento 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
Carregar dados

Quando dados são carregados no BigQuery a partir do Cloud Storage, não há cobrança pela operação de carregamento, apenas pelo armazenamento dos dados no Cloud Storage. Consulte Armazenamento de dados na página "Preços do Cloud Storage" para ver mais detalhes. 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.

Quando você cria um conjunto de dados no BigQuery, é preciso escolher um local para os dados. Caso US seja escolhido, será possível carregar dados em tabelas no conjunto de dados de um intervalo do Cloud Storage em qualquer outra região. Atualmente, não há cobrança pela saída da Internet quando dados de outra região são carregados em um conjunto de dados dos EUA.

Caso seja escolhido um local diferente de US, será preciso executar um dos seguintes procedimentos:

  • Carregar dados de um intervalo do Cloud Storage nessa região (o intervalo pode ser multirregional ou regional na mesma região do conjunto de dados)
  • Copiar os dados para um intervalo nessa região

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

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.
Exportar 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. Consulte Armazenamento de dados na página "Preços do Cloud Storage" para ver mais detalhes. Para mais informações, consulte Como exportar dados do BigQuery.
Excluir conjuntos de dados Não há cobrança pela exclusão de um conjunto de dados.
Excluir 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 listagem, busca, patch, atualização e exclusão. 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 pseudocolunas Não há cobrança para consultar o conteúdo das seguintes pseudo-colunas:
_TABLE_SUFFIX — usada para consultar tabelas curinga ou para usar 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 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 uma tabela particionada 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 UDFs Não há cobrança para 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 Sempre gratuito

Como parte do Nível gratuito do Google Cloud Platform, 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.

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 BigQuery ML CREATE MODEL 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 dele.

Preços de consulta

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, na sigla em inglês) e de 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 precificação que atende às suas necessidades. Também é possível combinar os dois modelos de preços para cada 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). Esses bytes também entram na cobrança, 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 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 armazenamento em cluster sempre que possível.
  • O sistema de preços de consulta sob demanda é chamado de sistema de preços de análise na página SKUs do Google Cloud Platform.

Controles de custos de consulta sob demanda

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

Preço fixo

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

Ao se inscrever em um plano de preço fixo, você compra uma capacidade de processamento de consultas dedicada medida em slots do BigQuery. O custo de todos os bytes processados é incluído nesse preço fixo mensal. Se as consultas excederem a capacidade de preço fixo, elas serão executadas mais lentamente de forma proporcional até que mais recursos de preço fixo sejam disponibilizados.

No caso do preço fixo:

  • É aplicado aos custos de consultas, incluindo instruções DML e DDL.
  • Não se aplica a custos de armazenamento. Consulte Preços de armazenamento para detalhes sobre os custos de armazenamento.
  • É comprado como um recurso regional. A capacidade de preço fixo adquirida em uma região não pode ser usada em outra região.
  • Permite que os clientes aumentem as cotas de simultaneidade por projeto entrando em contato com o suporte do Google Cloud Platform.
  • Está disponível em compromissos mensais e anuais.

Detalhes do preço fixo

Quando você se inscreve no preço fixo:

  • Os compromissos mensais não podem ser cancelados nem rebaixados por 30 dias corridos a partir da data de confirmação da compra.

    Após os primeiros 30 dias corridos, será possível cancelar ou fazer o downgrade a qualquer momento. Se você cancelar ou fizer o downgrade, suas cobranças serão calculadas proporcionalmente por segundo conforme o preço mensal.

    Exemplo:

    • Não é possível cancelar no 29º dia.
    • Se o cancelamento for feito durante o primeiro segundo do dia 31, a cobrança será de 30 dias e 1 segundo.
    • Se o cancelamento for feito na metade do terceiro mês, a cobrança será de 50% de sua taxa mensal para aquele mês.
  • Não é possível cancelar nem fazer o downgrade de compromissos anuais por um ano.

    Até a data de aniversário de seu compromisso, é possível renovar por mais um ano, ou passar para um plano mensal de preço fixo a partir do final do ano. Se você mudar para o preço mensal, poderá cancelar a qualquer momento, e a cobrança será calculada por segundo utilizado no preço mensal.

    Exemplo:

    • Se você renovar por mais um ano após a data do seu compromisso anual, assumirá um novo compromisso e continuará a receber cobranças conforme a taxa de compromisso anual.
    • Se você não renovar por mais um ano após a data de seu compromisso anual, será possível cancelar a qualquer momento e suas cobranças serão pagas proporcionalmente por segundo no preço mensal.
  • Para adquirir slots adicionais do BigQuery, é necessário assumir um novo compromisso.

  • O preço fixo é comprado para um local específico do BigQuery
    Ao adquirir um plano de preço fixo, você especifica a alocação de slots por local. Para usar slots em vários locais, é necessário comprar slots em cada local.
  • Preços fixos e sob demanda podem ser combinados
    Um projeto pode usar preços fixos ou sob demanda. Se você tiver vários projetos em um determinado local, poderá escolher quais projetos usam preços fixos e quais usam preços sob demanda.
  • Para descontinuar um plano de preço fixo, é necessário cancelar ou fazer o downgrade do seu compromisso.

Preço fixo mensal

Quando você se inscreve no preço fixo, a capacidade adquirida é medida em slots do BigQuery. Veja na tabela a seguir o número de slots alocados com base na compra de preço fixo mensal.

Preços fixos anuais

Quando você se inscreve no preço fixo, a capacidade adquirida é medida em slots do BigQuery. A tabela a seguir mostra o número de slots alocados com base na compra de preço fixo anual. Ao se inscrever em um plano de preço fixo anual, a cobrança é realizada mensalmente.

A compra de slots em compromissos mensais e anuais está atualmente na versão Alfa. Para participar do Alfa, preencha este formulário.

Não há alterações para os clientes que preferem continuar com o plano de preço fixo atual. Para continuar em seu plano de preço fixo atual, converse com seu representante de vendas.

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 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 do armazenamento para essa tabela 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 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 substitua uma tabela de destino.
Gravar resultados de consultas em uma tabela Qualquer 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, 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, na sigla em inglês) Usar uma instrução DDL `CREATE OR REPLACE TABLE` para substituir uma tabela.
Fazer streaming de dados para a tabela Ingerir dados por meio da 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 fracionada é analisada separadamente. Se uma partição não foi modificada nos últimos 90 dias, os dados nela são considerados armazenamento de 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.

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

Preços da API BigQuery Storage

A API BigQuery Storage tem um modelo de preço sob demanda. Você é cobrado pelos dados que lê. Os clientes que se inscreveram em um modelo de preço fixo podem usar a API BigQuery Storage para ler até 300 TB de dados por mês sem qualquer cobrança. Quando a leitura ultrapassa esse limite mensal, a cobrança do valor excedido é realizada de acordo com a taxa sob demanda.

Preços sob demanda

No preço sob demanda, a cobrança da sua 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 resposta de ReadRows. Não há cobrança para os 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 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ê depois do cancelamento da chamada ReadRows.
  • Como prática recomendada, use tabelas particionadas e em cluster sempre que possível. Você pode reduzir a quantidade de dados lidos usando uma cláusula WHERE para eliminar 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 é 230 bytes. Esta 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 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 (é possível verificar o número de vértices por meio da função ST_NumPoints)

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 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 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 pesquisa
+ a soma dos bytes de todas as colunas na tabela modificada no momento em que a instrução UPDATE é iniciada.
DELETE A soma dos bytes de todas as colunas referenciadas das tabelas verificadas pela pesquisa
+ 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 verificadas pela consulta
+ a soma dos bytes de todas as colunas nas partições atualizadas ou verificadas para a 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 verificadas pela consulta
+ a soma dos bytes de todas as colunas nas partições atualizadas ou verificadas para a tabela que está sendo atualizada (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

Ao criar e usar 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 os 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 apenas 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

No Beta de scripting do Big Query, a equipe BigQuery recomenda usar projetos com reserva de taxa fixa para evitar custos não intencionais de consulta, já que o número de bytes verificados por um script não é conhecido antes de executá-lo. Como alternativa, também é possível usar a sandbox do BigQuery para execução de scripts grátis e limitada. No futuro, a equipe BigQuery dará mais controle explícito sobre o número 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, veja as notas de 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, UPDATE, etc é descrito na documentação de preço para o público. Os seguintes preços se aplicam às instruções específicas para scripting:

  • 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/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 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 por 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 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 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 na 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 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"

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 na 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 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 23000 na coluna de particionamento customer_id.

Exemplo dos preços de scripting

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

-- 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;
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.