Cotas e limites

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.

Descrevemos nas listas a seguir os limites atuais de taxas e cotas do sistema.

Jobs de consulta

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

As consultas com resultados do cache de consulta e as de simulação não são contabilizadas. Para especificar uma consulta de simulação, basta usar a sinalização --dry_run ou definir 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

Só é possível fazer quatro consultas simultâneas em uma fonte de dados externa do Cloud Bigtable.

  • Limite de taxa simultânea para consultas de SQL legado com funções definidas pelo usuário (UDFs, na sigla em inglês): 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 SQL padrão.

  • 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.000 atualizações por tabela por dia

As tabelas de destino em um job de consulta estão sujeitas ao limite de 1.000 atualizações por tabela por dia. As atualizações da tabela de destino incluem operações de anexação e de substituição executadas por uma consulta que usa o Console, a versão clássica da IU da Web do BigQuery, a ferramenta de linha de comando bq ou a chamada do método de API jobs.query e do método jobs.insert do tipo consulta.

  • Limite de tempo de execução de consulta: 6 horas

Não é possível alterar esse limite.

  • 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

1 Os 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

2 O limite máximo de tamanho da linha é aproximado, porque ele tem como base a 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

O número padrão de slots para consultas sob demanda é compartilhado entre todas as consultas em um único projeto. Como regra geral, se você está processando menos de 100 GB de consultas de uma só vez, é improvável que esteja usando todos os 2.000 slots.

Para verificar quantos slots você está usando, consulte Monitoramento do BigQuery com o Stackdriver. Se você precisar de mais de 2.000 slots, entre em contato com seu representante de vendas para conferir se o modelo de preço fixo atende às suas necessidades.

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

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

Jobs de carregamento

Os limites a seguir se aplicam a jobs criados automaticamente ao carregar dados usando a ferramenta de linha de comando, o Console do GCP ou a versão clássica da IU da Web do BigQuery. Eles também se aplicam a jobs de carregamento enviados de maneira programática por meio do método da API jobs.insert do tipo carregamento.

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

  • Jobs de carregamento por tabela por dia: 1.000 (incluindo falhas)
  • Jobs de carregamento por projeto por dia: 100.000 (incluindo falhas)
  • Não é possível aumentar o limite de 1.000 jobs de carregamento por tabela por dia.
  • 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
    Avro Arquivos Avro compactados não são compatíveis, mas os blocos de dados compactados são. O BigQuery aceita os codecs DEFLATE e Snappy. 5 TB (1 MB para o cabeçalho do arquivo)
  • 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 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 com base nos EUA, os dados de um intervalo do Cloud Storage precisam ser carregados na mesma região do local do conjunto de dados. O intervalo pode ser um intervalo multirregional ou regional na mesma região do conjunto de dados. É possível carregar dados em um conjunto de dados com base nos 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, o Console ou a versão clássica da IU da Web do BigQuery. Eles também se aplicam a jobs de cópia enviados de maneira programática por meio do 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 por dia: 100.000 (incluindo falhas)

Jobs de exportação

Os limites a seguir se aplicam 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, o Console ou a versão clássica da IU da Web do BigQuery. Eles também se aplicam a jobs de exportação enviados de maneira programática por meio do método de API jobs.insert do tipo carregamento.

  • Exportações por dia: 100.000 exportações por projeto e até 10 TB por dia (o limite de dados de 10 TB é cumulativo entre todas as exportações)
  • Para exportar mais do que 10 TB de dados por dia, use a API BigQuery Storage.

  • 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
    O número de conjuntos de dados por projeto não está sujeito a uma cota. Entretanto, à medida que você abordar milhares de conjuntos de dados em um projeto, o desempenho da IU da Web clássica começará a ser prejudicado, e a listagem dos conjuntos de dados se tornará mais lenta.
  • Número de tabelas por conjunto de dados: sem restrição
    À medida que você se aproxima de 50.000 tabelas ou mais em um conjunto de dados, a enumeração delas fica mais lenta. O desempenho de enumeração é prejudicado se você usa uma chamada de API ou a IU da Web clássica do BigQuery. Atualmente, a IU da Web do BigQuery no Console do GCP permite exibir apenas 50.000 tabelas por conjunto de dados. Para melhorar o desempenho da IU da Web clássica do BigQuery, use o parâmetro ?minimal para limitar o número de tabelas exibidas a 30.000 por projeto. Adicione o parâmetro ao URL da IU da Web clássica do BigQuery no seguinte formato: https://bigquery.cloud.google.com/queries/[PROJECT_NAME]?minimal.
  • Número máximo de visualizações autorizadas na lista de controle de acesso de um conjunto de dados: 2.500
    Crie uma visualização autorizada para restringir o acesso aos 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.
  • 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 inclui todas as operações de atualização de metadados do conjunto de dados realizadas por meio do Console, da versão clássica da IU da Web do BigQuery, da ferramenta de linha de comando bq ou da chamada dos métodos de API datasets.insert, datasets.patch e 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 tabela

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

Todas as tabelas

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

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

Tabelas padrão

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

O limite é de 1.000 operações por tabela por dia, seja para anexar dados a uma tabela, substituir uma tabela ou usar uma instrução DML INSERT para gravar dados em 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 para gravar dados em uma tabela.

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

  • 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 da tabela realizadas por meio do Console do GCP, da versão clássica da IU da Web do BigQuery, da ferramenta de linha de comando bq, das bibliotecas de cliente ou da chamada dos métodos de API tables.insert, tables.patch e tables.update. Esse limite também se aplica a resultados de jobs.

  • Máximo de colunas em uma tabela, resultado de consulta ou 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: 2.000

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

  • Número máximo de modificações de partição diárias por tabela: 5.000

Faça até 5.000 modificações de partições por dia em uma tabela particionada. Uma partição pode ser modificada com uma operação que acrescenta 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. 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

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 aos seus dados de origem. É criada uma visualização autorizada 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 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 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 SQL padrão.

  • Número máximo de recursos de UDF em JavaScript, como blobs de código inline 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 às funções definidas pelo usuário permanentes.
  • 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 a um tamanho máximo de 32 KB.
  • Cada recurso de código JavaScript está limitado a um tamanho máximo de 1 MB.
  • As operações Bitwise em JavaScript lidam apenas com os 32 bits mais significativos.

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

Os limites a seguir se aplicam a instruções da linguagem de manipulação de dados (DML, na sigla em inglês):

  • Número máximo de instruções INSERT, UPDATE, DELETE e MERGE combinadas por dia por tabela: 1.000

Uma instrução MERGE é contada como uma única instrução DML, mesmo que contenha várias cláusulas INSERT, UPDATE ou DELETE.

Inserções de streaming

Os seguintes limites se aplicam a dados de streaming no BigQuery:

Se você não preencher o campo insertId ao inserir linhas:

No momento, essas cotas se aplicam apenas ao local multirregional US, e será preciso preencher o formulário de inscrição do BigQuery Streaming V2 Beta para usá-las.

  • Máximo de linhas por segundo: 1.000.000
    Se você não preencher o campo insertId para cada linha inserida, o limite será de 1.000.000 de linhas por segundo por projeto. Essa cota é cumulativa. É possível usar toda essa cota em uma tabela ou usá-la para fazer streaming de dados a várias tabelas em um projeto.

    Exceder essa quantidade causará o erro quotaExceeded.
  • 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, não a tabelas individuais.

    Exceder essa quantidade causará o erro quotaExceeded.

Se você preencher o campo insertId ao inserir linhas:

  • Máximo de linhas por segundo: 100.000
    Se você preencher o campo insertId para cada linha inserida, o limite será de 100.000 linhas por segundo por projeto ou tabela. Essa cota é cumulativa. É possível usar toda essa cota em uma tabela ou usá-la para fazer streaming de dados a várias tabelas em um projeto.

    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 por tabela.

    Exceder essa quantidade causará o erro quotaExceeded.

As seguintes cotas de streaming se aplicam ao campo insertId, mesmo que não o preencha:

  • Tamanho máximo da linha: 1 MB
    Exceder esse valor causará o erro invalid.
  • Limite de tamanho de solicitação HTTP: 10 MB
    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 esquema e tamanhos dos dados) ajudam você a determinar o tamanho ideal do lote.
  • Comprimento do campo insertId: 128
    Exceder esse valor causará o erro invalid.

Se precisar de mais cotas de streaming para o projeto, envie uma solicitação por meio do Console do Google Cloud Platform. É possível definir uma cota personalizada para dados de streaming em incrementos de 50.000 linhas. Você receberá uma resposta à sua solicitação 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 do 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 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. 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, é possível enviar até 500 solicitações por segundo, por projeto.
  • Máximo de bytes por segundo por projeto retornado por chamadas para tabledata.list: 60 MB/segundo
    Ao chamar tabledata.list, retorne 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 lida.
  • Máximo de linhas por segundo por projeto retornado por chamadas para tabledata.list: 150.000/segundo
    Ao chamar tabledata.list, retorne no máximo 150.000 linhas de tabela por segundo por 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 por projeto: 10 Ao chamar tables.insert, é possível criar no máximo 10 solicitações por segundo por projeto. Esse limite inclui 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 por projeto: 2 Ao chamar projects.list, é possível criar no máximo duas solicitações por segundo por 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 por projeto: 1.000 Ao chamar jobs.get, é possível criar no máximo 1.000 solicitações por segundo por projeto.

Solicitações jobs.query

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

  • 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. Para alterar o número de linhas a serem retornadas, use o parâmetro maxResults.

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 todos os métodos da API BigQuery Storage:

  • Chamada da 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. Normalmente, mais cota é disponibilizada em minutos em vez de um reabastecimento global uma vez por dia.

Códigos de erro

Os erros de cota e limite retornam um código de resposta HTTP 403 ou 400. Consulte Como solucionar erros para ver uma lista completa de códigos de erro e etapas de solução de problemas.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

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