Cotas e limites

Nas listas a seguir, você verá os limites de taxa e de cota do BigQuery.

O BigQuery limita a taxa máxima de solicitações de entrada e aplica cotas apropriadas por projeto. As políticas específicas variam de acordo com a disponibilidade do recurso, o perfil do usuário, o histórico de uso do serviço e de outros fatores, e estão sujeitas a alterações sem prévio aviso.

Jobs de consulta

Os limites a seguir se aplicam a jobs de consulta criados automaticamente com a execução de consultas interativas e a jobs enviados de maneira programática por meio das chamadas dos métodos jobs.query e jobs.insert do tipo consulta.

As consultas com resultados retornados do cache de consulta são descontadas desse limite durante o tempo que leva para o BigQuery determinar que é uma ocorrência em cache. Consultas de simulação não são descontadas desse limite. É possível especificar uma consulta de simulação usando a sinalização --dry_run ou definindo a propriedade dryRun em um job de consulta.

Esse limite é aplicado no nível do projeto. Para aumentá-lo, entre em contato com a equipe de suporte ou com a equipe de vendas.

  • Limite de taxa simultânea para consultas interativas em fontes de dados externas do Cloud Bigtable: quatro consultas simultâneas

É possível fazer apenas quatro consultas simultâneas em uma fonte de dados externa do Cloud Bigtable.

  • Limite de taxa simultânea para consultas de SQL legado com UDFs: seis consultas simultâneas

O limite de taxa simultânea para consultas de SQL legado que contêm UDFs inclui consultas interativas e em lote. Consultas interativas que contêm UDFs são contabilizadas em relação ao limite de taxa simultânea para consultas interativas. Esse limite não se aplica a consultas de SQL padrão.

  • Consultas federadas entre regiões: 1 TB por projeto por dia

Uma consulta será entre regiões se o local de processamento da consulta do BigQuery e o local da instância do Cloud SQL forem diferentes. É possível executar até 1 TB em consultas entre regiões por projeto por dia. Veja as consultas federadas do Cloud SQL.

  • Limite diário do tamanho da consulta: ilimitado por padrão

Para especificar limites na quantidade de dados que os usuários podem consultar, defina cotas personalizadas.

  • Limite diário de atualização da tabela de destino: 1.500 atualizações por tabela por dia

As tabelas de destino em um job de consulta estão sujeitas ao limite de 1.500 atualizações por tabela por dia. As atualizações da tabela de destino incluem operações de anexação e substituição, feitas por consultas executadas usando o Console do Cloud, usando a ferramenta de linha de comando bq ou chamando o método jobs.query e métodos de API jobs.insert do tipo de consulta.

  • Limite de tempo de execução de consulta/script: seis horas

Não é possível alterar esse limite. Em alguns casos, as consultas podem ser feitas novamente. Quando isso acontece, a consulta pode ser executada por mais seis horas e feita novamente até três vezes. Isso pode resultar em um tempo de execução maior do que seis horas.

  • Número máximo de tabelas referenciadas por consulta: 1.000

  • Tamanho máximo de uma consulta de SQL legado não resolvida: 256 KB

  • Tamanho máximo de uma consulta de SQL padrão não resolvida: 1 MB

  • Tamanho máximo de uma consulta de SQL legado e padrão resolvida: 12 MB

O limite no tamanho da consulta resolvida inclui o tamanho de todas as visualizações e tabelas curinga referenciadas pela consulta.

  • Número máximo de parâmetros de consulta de SQL padrão: 10.000

  • Tamanho máximo da resposta: 10 GB compactados1

1Os tamanhos variam de acordo com as taxas de compactação dos dados. O tamanho real da resposta pode ser significativamente superior a 10 GB.

O tamanho máximo da resposta é ilimitado ao gravar grandes resultados de consultas em uma tabela de destino.

  • Tamanho máximo da linha: 100 MB2

2O limite máximo de tamanho da linha é aproximado, porque se baseia na representação interna dos dados da linha. Esse limite é aplicado durante determinados estágios da execução do job de consulta.

  • Máximo de colunas em uma tabela, resultado de consulta ou definição de visualização: 10.000

  • Máximo de slots simultâneos por projeto para preços sob demanda: 2.000

Os slots do BigQuery são compartilhados entre todas as consultas em um único projeto. É possível que o BigQuery vá além desse limite para acelerar suas consultas.

Para verificar quantos slots você está usando, consulte Como monitorar o BigQuery usando o Cloud Monitoring.

  • Máximo de consultas simultâneas a uma fonte de dados externa do Cloud Bigtable: 4

Para informações sobre os limites aplicáveis a funções definidas pelo usuário em consultas SQL, consulte Limites de UDF.

  • Consultas programadas

As consultas programadas usam recursos do serviço de transferência de dados do BigQuery, mas não são transferências e não estão sujeitas à cota de jobs de carregamento. As consultas programadas estão sujeitas às mesmas cotas e limites do BigQuery que as consultas manuais.

Jobs de carregamento

Os limites a seguir se aplicam a jobs criados automaticamente ao carregar dados usando o Console do Cloud ou a ferramenta de linha de comando bq. Esses limites também se aplicam a jobs de carregamento enviados de maneira programática usando o método de API jobs.insert do tipo carregamento.

Os limites a seguir se aplicam ao carregamento de dados no BigQuery.

  • Jobs de carregamento em cada tabela por dia: 1.500 (incluindo falhas)
  • Jobs de carregamento em cada projeto por dia: 100.000 (incluindo falhas)
  • Limites de tamanho de linhas e células:
    Formato de dados Limite máximo
    CSV 100 MB (tamanho da linha e célula)
    JSON 100 MB (tamanho da linha)
  • Máximo de colunas por tabela: 10.000
  • Tamanho máximo dos arquivos:
    Tipo de arquivo Compactado Não compactado
    CSV 4 GB 5 TB
    JSON 4 GB 5 TB
  • Tamanho máximo por job de carregamento: 15 TB em todos os arquivos de entrada para CSV, JSON, Avro, Parquet e ORC
  • Número máximo de URIs de origem na configuração do job: 10.000 URIs
  • Número máximo de arquivos por job de carregamento: 10 milhões de arquivos no total, incluindo todos os arquivos correspondentes a todos os URIs curinga
  • Limite de tempo de execução do job de carregamento: 6 horas
  • Com exceção dos conjuntos de dados que estejam nos EUA, os dados de um bucket do Cloud Storage precisam ser carregados na mesma região do local do conjunto de dados. O bucket pode ser um bucket multirregional ou ou regional na mesma região do conjunto de dados. É possível carregar dados em um conjunto de dados dos EUA de qualquer região.

Para mais informações, consulte Introdução ao carregamento de dados no BigQuery.

Jobs de cópia

Veja a seguir os limites aplicados à cópia de tabelas no BigQuery. Os limites se aplicam a jobs criados automaticamente ao copiar dados usando a ferramenta de linha de comando bq ou o Console do Cloud. Eles também se aplicam aos jobs de cópia enviados de maneira programática usando o método de API jobs.insert do tipo cópia.

  • Jobs de cópia por tabela de destino/dia: 1.000 (incluindo falhas)
  • Jobs de cópia por projeto/dia: 100.000 (incluindo falhas)

Jobs de exportação

Veja a seguir os limites aplicados a jobs que exportam dados do BigQuery. Os limites a seguir se aplicam a jobs criados automaticamente ao exportar dados usando a ferramenta de linha de comando bq ou o Console do Cloud. Eles também se aplicam a jobs de exportação enviados de maneira programática com o método de API jobs.insert do tipo carregamento.

  • Exportações por dia: 100.000 exportações por projeto e até 50 TB por dia (o limite de dados de 50 TB é cumulativo entre todas as exportações)

    • Para exportar mais do que 50 TB de dados por dia, use a API BigQuery Storage ou a instrução EXPORT DATA.

  • URIs curinga: 500 URIs curinga por exportação

Limites do conjunto de dados

Os limites a seguir se aplicam a conjuntos de dados:

  • Número de conjuntos de dados por projeto: sem restrição

  • Número de tabelas por conjunto de dados: sem restrição
    Ao usar uma chamada de API, o desempenho da enumeração fica lento quando você se aproxima de 50.000 tabelas em um conjunto de dados. O Console do Cloud pode exibir até 50.000 tabelas para cada conjunto de dados.
  • Número máximo de visualizações autorizadas na lista de controle de acesso de um conjunto de dados: 2.500
    É possível criar uma visualização autorizada para restringir o acesso a seus dados de origem. A visualização autorizada é criada por meio de uma consulta SQL que exclui as colunas que você não quer que os usuários vejam ao consultar a visualização. Podem ser adicionadas até 2.500 visualizações autorizadas à lista de controle de acesso de um conjunto de dados.
  • Taxa máxima de operações de atualização de metadados do conjunto de dados: 5 operações a cada 10 segundos por conjunto de dados
    O limite de atualização de metadados de conjunto de dados inclui todas as operações de atualização de metadados realizadas com o Console do Cloud, usando a ferramenta de linha de comando bq ou chamando os métodos de API datasets.insert, datasets.patch ou datasets.update.
  • Tamanho máximo de uma descrição de conjunto de dados: 16.384 caracteres
    Ao adicionar uma descrição a um conjunto de dados, o texto pode ter no máximo 16.384 caracteres.

Limites de tabelas

Os limites a seguir se aplicam às tabelas do BigQuery.

Todas as tabelas

  • Tamanho máximo da descrição de uma coluna: 1.024 caracteres

Ao adicionar uma descrição a uma coluna, o texto pode ter no máximo 1.024 caracteres.

Tabelas padrão

  • Número máximo de operações de tabela por dia: 1.500

O limite é de 1.500 operações por tabela por dia, seja para anexar dados, seja para truncar uma tabela.

O número máximo de operações de tabela inclui o total combinado de todos os jobs de carregamento, de cópia e de consulta que substituem uma tabela de destino, são anexados a ela ou usam uma instrução DML INSERT, UPDATE, DELETE ou MERGE para gravar dados em uma tabela. As instruções DML são contabilizadas nessa cota, mas não são limitadas por ela. Em outras palavras, o número de operações diárias que são contabilizadas para a cota inclui instruções DML, mas esse tipo de comando não falhará por causa do limite.

Por exemplo, você atingirá a cota se executar 500 jobs de cópia que anexam dados a mytable e 1.000 jobs de consulta que anexam dados a mytable.

  • Taxa máxima de operações de atualização de metadados de tabela: 5 operações a cada 10 segundos por tabela

O limite inclui todas as operações de atualização de metadados realizadas com o Console do Cloud, a ferramenta de linha de comando bq ou as bibliotecas de cliente ou ao chamar os métodos de API tables.insert, tables.patch ou tables.update ou ao executar Declarações DDL ALTER TABLE. Esse limite também se aplica a saídas de jobs. Esse é um erro transitório que você pode tentar novamente com uma espera exponencial. Esse limite não se aplica a operações de DML.

  • Máximo de colunas em uma tabela, um resultado de consulta ou uma definição de visualização: 10.000

Tabelas particionadas

  • Número máximo de partições por tabela particionada: 4.000

  • Número máximo de partições modificadas por um único job: 4.000

Cada operação de job (consulta ou carregamento) pode afetar no máximo 4.000 partições. Qualquer job de consulta ou de carregamento que afete mais de 4.000 partições é rejeitado pelo BigQuery.

  • Número máximo de modificações de partições por tabela particionada por tempo de processamento: 5.000
  • Número máximo de modificações de partições por tabela particionada por coluna: 30.000

O limite é de 5.000 modificações de partições por dia em uma tabela particionada por tempo de processamento e de 30.000 modificações de partições em uma tabela particionada por coluna. Uma partição pode ser modificada com uma operação que anexa ou substitui dados na partição. As operações que modificam as partições incluem: um job de carregamento, uma consulta que grava os resultados em uma partição ou uma instrução DML (INSERT, DELETE, UPDATE ou MERGE) que modifica dados em uma partição.

Um único job pode afetar mais de uma partição. Por exemplo, uma instrução DML pode atualizar dados em várias partições (para tabelas de tempo de ingestão e particionadas). Jobs de consulta e jobs de carregamento também podem gravar em várias partições, mas apenas para tabelas particionadas. As instruções DML são contabilizadas nessa cota, mas não são limitadas por ela. Em outras palavras, o número de operações diárias que são contabilizadas para a cota inclui instruções DML, mas esse tipo de comando não falhará por causa do limite. O BigQuery usa o número de partições afetadas por um job ao determinar a quantidade da cota consumida pelo job. As inserções de streaming não afetam essa cota.

  • Taxa máxima de operações de partição: 50 operações de partição a cada 10 segundos

Tabelas externas

Os limites a seguir se aplicam a tabelas com dados armazenados no Cloud Storage em formato Parquet, ORC, Avro, CSV ou JSON.

  • Número máximo de URIs de origem por tabela externa: 10.000 URIs
  • Número máximo de arquivos por tabela externa: 10 milhões no total, incluindo todos os arquivos correspondentes a todos os URIs curinga
  • Tamanho máximo de dados armazenados no Cloud Storage por tabela externa em todos os arquivos de entrada: 600 TB

    Esse limite se aplica aos tamanhos dos arquivos, conforme armazenados no Cloud Storage. Esse tamanho não é o mesmo usado na fórmula de preço de consulta. Para tabelas particionadas externamente, o limite é aplicado depois da remoção de partições.

Limites de visualização

  • Número máximo de níveis de visualização aninhados: 16

O BigQuery é compatível com até 16 níveis de visualização aninhados. Se houver mais de 16 níveis, será retornado um erro INVALID_INPUT.

  • Tamanho máximo de consulta SQL padrão usada para definir uma visualização: 256 mil caracteres

Ao criar uma visualização, o texto da consulta SQL padrão pode ter no máximo 256 mil caracteres.

  • Número máximo de visualizações autorizadas na lista de controle de acesso de um conjunto de dados: 2.500

É possível criar uma visualização autorizada para restringir o acesso a seus dados de origem. Uma visualização autorizada é criada com uma consulta SQL que exclui as colunas que você não quer que os usuários vejam ao consultar a visualização. É possível adicionar até 2.500 visualizações autorizadas à lista de controle de acesso de um conjunto de dados.

Limites de UDF

Os limites a seguir se aplicam às funções definidas pelo usuário em consultas SQL:

  • Volume de dados de saída da UDF em JavaScript durante o processamento de uma única linha: aproximadamente 5 MB ou menos.
  • Limite de taxa simultânea para consultas de SQL legado que contêm UDFs: seis consultas simultâneas.

    • O limite de taxa simultânea para consultas de SQL legado que contêm UDFs inclui consultas interativas e em lote. Consultas interativas que contêm UDFs também são consideradas em relação ao limite de taxa simultânea para consultas interativas. Esse limite não se aplica a consultas de SQL padrão.

  • Número máximo de recursos de UDF em JavaScript, como blobs de código in-line ou arquivos externos em um job de consulta: 50
  • Tamanho máximo de cada blob de código in-line: 32 KB
  • Tamanho máximo de cada recurso de código externo: 1 MB

Os limites a seguir se aplicam a funções permanentes definidas pelo usuário.
  • Comprimento máximo de um nome de função: 256 caracteres
  • Número máximo de argumentos: 256
  • Comprimento máximo de um nome de argumento: 128 caracteres
  • Profundidade máxima de uma cadeia de referência de uma função definida pelo usuário: 16
  • Profundidade máxima de um argumento ou de uma resposta do tipo STRUCT: 15
  • Número máximo de campos em um argumento ou resposta do tipo STRUCT por UDF: 1.024
  • Número máximo de UDFs únicas e referências de tabela por consulta: 1.000 Após a expansão completa, cada UDF poderá consultar até 1.000 UDFs e tabelas únicas. Esse número é uma combinação desses dois elementos.
  • Número máximo de bibliotecas JavaScript na instrução CREATE FUNCTION: 50
  • Comprimento máximo de caminhos de bibliotecas JavaScript incluídos: 5.000 caracteres
  • Taxa máxima de atualização por UDF: cinco a cada 10 segundos Após a criação da função, é possível atualizar cada função até cinco vezes a cada 10 segundos.
  • Cada blob de código in-line está limitado ao tamanho máximo de 32 KB
  • Cada recurso de código JavaScript está limitado ao tamanho máximo de 1 MB

Instruções da linguagem de manipulação de dados

As instruções DML do BigQuery não têm limites de cota.

No entanto, as instruções DML são contabilizadas para o número máximo de operações de tabela e modificações de partição diárias. As instruções DML não falharão por causa desses limites.

Além disso, esse tipo de comando está sujeito à taxa máxima de operações de atualização de metadados de tabelas. Se você ultrapassar esse limite, tente realizar a operação novamente usando a espera exponencial entre as tentativas.

Inserções de streaming

Veja a seguir os limites aplicados a dados de streaming no BigQuery.

Se você não preencher o campo insertId ao inserir linhas, as cotas a seguir serão aplicadas. Para mais informações, consulte Como desativar a eliminação de duplicação por melhor esforço. Essa é a maneira recomendada de usar o BigQuery para conseguir limites de cota de ingestão de streaming maiores.

  • Máximo de bytes por segundo: 1 GB. Se você não preencher o campo insertId para cada linha inserida, o limite será de 1 GB por segundo por projeto. Esse limite é aplicado no nível do projeto, e não a tabelas individuais. Exceder essa quantidade causará o erro quotaExceeded.

Se você preencher o campo insertId ao inserir linhas, as cotas a seguir serão aplicadas.

  • Máximo de linhas por segundo por projeto nas multirregiões us e eu: 500.000
    Se você preencher o campo insertId para cada linha inserida, o limite será de 500.000 linhas por segundo nas multirregiões us e eu, por projeto. Essa cota é cumulativa dentro de uma determinada multirregião. Ou seja, a soma de linhas transmitidas por segundo para todas as tabelas em um determinado projeto dentro de uma multirregião está limitada a 500.000. Cada tabela tem um limite extra de 100.000 linhas por segundo.

    Ultrapassar o limite por projeto ou tabela causará erros de quotaExceeded.
  • Máximo de linhas por segundo em cada projeto em todos os outros locais: 100.000
    Se você preencher o campo insertId para cada linha inserida, o limite será de 100.000 linhas por segundo em todas as localizações, exceto nas multirregiões us e eu, por projeto ou tabela. Esse limite é cumulativo dentro de uma determinada região. Ou seja, a soma de linhas transmitidas por segundo para todas as tabelas em um determinado projeto dentro de uma região está limitada a 100.000.

    Exceder essa quantidade causará o erro quotaExceeded.
  • Máximo de linhas por segundo em cada tabela: 100.000
    Se você preencher o campo insertId para cada linha inserida, o limite será de 100.000 linhas por segundo em cada tabela.

    Exceder essa quantidade causará o erro quotaExceeded.
  • Máximo de bytes por segundo: 100 MB
    Se você preencher o campo insertId para cada linha inserida, o limite será de 100 MB por segundo em cada tabela.

    Exceder essa quantidade causará o erro quotaExceeded.

As cotas de streaming a seguir se aplicam ao campo insertId, mesmo que ele não seja preenchido:

  • Tamanho máximo da linha: 5 MB
    Exceder esse valor causará o erro invalid.
  • Limite de tamanho da solicitação HTTP: 10 MB (veja a observação)
    Exceder esse valor causará o erro invalid.
  • Máximo de linhas por solicitação: 10.000
    É recomendado o máximo de 500 linhas. Nas operações em lote, o desempenho e a capacidade podem aumentar, mas a latência por solicitação pode ser prejudicada. Com poucas linhas por solicitação, a ingestão pode ficar ineficiente por causa do excesso de recursos utilizados no processamento de cada solicitação. Com muitas, o rendimento da saída pode diminuir.

    É recomendado o máximo de 500 linhas por solicitação, mas os testes com dados representativos, como tamanhos de dados e de esquema, ajudam a determinar o tamanho ideal do lote.
  • Comprimento do campo insertId: 128
    Exceder esse valor causará o erro invalid.

Se você precisar de uma cota de streaming maior para o projeto, poderá desativar a eliminação de duplicação por melhor esforço. Para aumentos de cota além desses limites, envie uma solicitação no Console do Google Cloud. Você receberá uma resposta dentro de dois a três dias úteis.

Solicitações de API

Todas as solicitações de API

Os limites a seguir se aplicam a todas as solicitações da API BigQuery:

  • Solicitações de API por segundo, por usuário: 100
    Se você faz mais de 100 solicitações por segundo, pode haver uma limitação. Esse limite não se aplica a inserções de streaming.
  • Solicitações de API simultâneas, por usuário: 300
    Se você faz mais de 300 solicitações simultâneas por segundo, pode haver uma limitação. Esse limite não se aplica a inserções de streaming.

Solicitações tabledata.list

O método tabledata.list recupera dados da tabela de um conjunto de linhas especificado. Outras APIs, incluindo jobs.getQueryResults e resultados da busca de jobs.query e jobs.insert, também podem consumir a cota dessa API. Os limites a seguir se aplicam a solicitações tabledata.list:

  • Número máximo de consultas tabledata.list por projeto: 500/segundo
    Ao chamar tabledata.list, você pode enviar até 500 solicitações por segundo em cada projeto.
  • Máximo de bytes por segundo em cada projeto retornado por chamadas para tabledata.list: 60 MB/segundo
    Ao chamar tabledata.list, você pode retornar no máximo 60 MB por segundo dos dados de linhas da tabela por projeto. O limite se aplica ao projeto que contém a tabela que está sendo lida.
  • Máximo de linhas por segundo em cada projeto retornado por chamadas para tabledata.list: 150.000/segundo
    Ao chamar tabledata.list, você pode retornar no máximo 150.000 linhas de tabela por segundo em cada projeto. O limite se aplica ao projeto que contém a tabela que está sendo lida.

Solicitações tables.insert

O método tables.insert cria uma nova tabela vazia em um conjunto de dados. Os limites a seguir se aplicam a solicitações tables.insert:

  • Número máximo de solicitações por segundo em cada projeto: 10: ao chamar tables.insert, você pode criar no máximo 10 solicitações por segundo em cada projeto. Nesse limite estão incluídas instruções que criam tabelas, como a instrução DDL CREATE TABLE, e consultas que gravam resultados em tabelas de destino.

Solicitações projects.list

O método projects.list lista todos os projetos que você tem permissão para acessar. Os limites a seguir se aplicam a solicitações projects.list:

  • Número máximo de solicitações por segundo em cada projeto: 2: ao chamar projects.list, você pode criar no máximo duas solicitações por segundo em cada projeto.

Solicitações jobs.get

O método jobs.get retorna informações sobre um job específico. Os limites a seguir se aplicam a solicitações jobs.get:

  • Número máximo de solicitações por segundo em cada projeto: 1.000: ao chamar jobs.get, você pode criar no máximo 1.000 solicitações por segundo em cada projeto.

Solicitações jobs.query

O método jobs.query executa uma consulta SQL de forma síncrona e retorna os resultados se ela é concluída dentro de um determinado tempo limite.

  • Tamanho máximo da resposta: 10 MB: por padrão, não há uma contagem máxima do número de linhas de dados a serem retornadas por página de resultados. No entanto, é aplicado o limite de 10 MB no tamanho máximo da resposta. O número de linhas a serem retornadas pode ser alterado por meio do parâmetro maxResults.

Solicitações da API IAM

Os limites a seguir se aplicam ao uso da funcionalidade de gerenciamento de identidade e acesso no BigQuery para recuperar e definir as políticas do IAM, além de testar as permissões dele.

  • No nível do projeto do Google Cloud, existe um limite de 25 solicitações por segundo, por usuário.

  • No nível do projeto do Google Cloud, existe um limite de 50 solicitações por segundo.

Caso você precise de mais cotas do IAM para seu projeto, envie uma solicitação por meio do Console do Google Cloud. Você receberá uma resposta à sua solicitação dentro de dois a três dias úteis.

Solicitações da API BigQuery Storage

Os limites a seguir se aplicam a chamadas ReadRows que usam a API BigQuery Storage:

  • Chamadas ReadRows por minuto: 5.000: ao ler dados usando a API BigQuery Storage, o limite é de 5.000 chamadas ReadRows por minuto, por usuário e por projeto.

Os limites a seguir se aplicam a todas as outras chamadas de métodos que utilizam a API BigQuery Storage:

  • Chamadas à API por minuto: 1.000: o limite é de 1.000 chamadas da API BigQuery Storage por minuto, por usuário e por projeto.

Quando as cotas são restauradas?

As cotas diárias são reabastecidas em intervalos regulares ao longo do dia, refletindo a intenção de orientar comportamentos que limitem a taxa. A atualização intermitente também é feita para evitar interrupções longas quando a cota estiver esgotada. As cotas geralmente são renovadas em questão de minutos, em vez de restauradas de maneira integral uma vez ao dia.

Solução de problemas

Para ver informações sobre como solucionar erros relacionados aos limites de cota, consulte Como solucionar problemas de erros de cota no BigQuery.

Como limitar o uso de cotas

Para saber mais sobre como limitar o uso de um recurso específico, até o limite especificado pelo Google, consulte Como limitar o uso.