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 linhas 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 com a execução de consultas interativas e a jobs enviados de modo programático com as chamadas do método jobs.query e do tipo de consulta jobs.insert.

Consultas com resultados que são retornados do cache de consulta e consultas de simulação não são consideradas nesse limite. Para especificar uma consulta de simulação, basta usar o sinalizador --dry_run ou definir a propriedade dryRun em um job de consulta.

  • Limite de taxa simultânea para consultas que contêm funções definidas pelo usuário (UDFs, na sigla em inglês): 6 consultas simultâneas

O limite de taxa simultânea para consultas que contêm UDFs inclui consultas interativas e em lote. Consultas interativas que contêm UDFs são consideradas em relação ao limite de taxa simultânea para consultas interativas.

  • 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

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 substituição executadas por uma consulta usando a UI da Web do BigQuery, a ferramenta de linha de comando bq ou chamando os métodos da API jobs.query e de tipo de consulta jobs.insert.

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

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

  • Comprimento máximo de consulta não resolvida: 256 KB

  • Tamanho máximo da consulta resolvida: 12 MB

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

  • Tamanho máximo de resposta: 128 MB compactado1

1 Os tamanhos variam de acordo com as taxas de compactação dos dados. O tamanho real da resposta pode ser significativamente maior que 128 MB.

O tamanho máximo da resposta é ilimitado ao gravar grandes resultados de consulta 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 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 você esteja usando todos os 2.000 slots.

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

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

Carregar jobs

Os limites a seguir se aplicam a jobs criados automaticamente ao carregar dados usando a ferramenta de linha de comando ou a interface da Web do BigQuery. Eles também se aplicam a jobs de carregamento enviados de modo programático usando o método de API de tipo de carregamento jobs.insert.

Os limites a seguir se aplicam quando você carrega dados no BigQuery.

  • Jobs de carregamento por tabela por dia: 1.000 (incluindo falhas)
  • Jobs de carregamento por projeto por dia: 50.000 (incluindo falhas)
  • Não é possível aumentar o limite de 1.000 jobs de carregamento por tabela por dia.
  • Limites de tamanho de linha e célula:
    Formato de dados Limite máximo
    CSV 10 MB (tamanho da linha e célula)
    JSON 10 MB (tamanho da linha)
    Avro 16 MB (tamanho do bloco)
  • 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 carregado: 15 TB em todos os arquivos de entrada para CSV, JSON e Avro
  • 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: 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. Você pode 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 ou a interface da Web do BigQuery. Eles também se aplicam a jobs de cópia enviados de método programático usando o método API de tipo de cópia jobs.insert.

  • Jobs de cópia por tabela de destino por dia: 1.000 (incluindo falhas)
  • Jobs de cópia por projeto por dia: 10.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 ou a interface da Web do BigQuery. Eles também se aplicam a jobs de exportação enviados de modo programático usando o método de API de tipo de carregamento jobs.insert.

  • Exportações por dia: 50.000 exportações por projeto e até 10 TB por dia (o limite de dados de 10 TB é cumulativo em todas as exportações)
  • 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. No entanto, à medida que esse número se aproxima dos milhares em um projeto, o desempenho da IU da Web começa a se degradar e a listagem de conjuntos de dados fica mais lenta.
  • Número de tabelas por conjunto de dados: sem restrição
    O número de tabelas por conjunto de dados também é irrestrito. No entanto, à medida que você se aproxima de 50.000 tabelas ou mais em um conjunto de dados, a enumeração delas fica mais lenta. Isso acontece se você usa uma chamada de API, a interface do usuário da Web ou a metatabela __TABLES_SUMMARY__. Para melhorar o desempenho da IU, você pode usar 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 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: 1.000
    Você pode criar 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 exibição. Você pode adicionar até 1.000 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: 1 operação a cada 2 segundos por conjunto de dados
    O limite inclui todas as operações de atualização de metadados realizadas usando a IU da Web do BigQuery, a ferramenta de linha de comando bq ou chamando os métodos da API datasets.insert, datasets.patch ou datasets.update.

Limites da tabela

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

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 declaração DML INSERT para gravar dados em uma tabela.

O número máximo de operações inclui o total combinado de todos os jobs de carregamento, jobs de cópia, e jobs de consulta que substituem ou anexam a uma tabela de destino ou que usam uma declaraçã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: 1 operação a cada 2 segundos por tabela

O limite de atualização de metadados da tabela inclui todas as operações de atualização de metadados realizadas usando a UI da Web do BigQuery, a ferramenta de linha de comando bq ou chamando os métodos da API tables.insert, tables.patch ou tables.update. Esse limite também se aplica a resultados de jobs.

Tabelas particionadas

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

  • 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 Google BigQuery.

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

Você pode fazer até 5.000 modificações de partição 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 declaraçã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 Google 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

Declarações de linguagem de manipulação de dados (DML, na sigla em inglês)

Os limites a seguir se aplicam a declarações DML.

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

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

Declarações DML são mais limitadas que declarações SELECT (SQL), porque é necessária uma quantidade de recursos significativamente maior para o processamento delas.

Inserções de streaming

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

  • 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 segundo: 100.000 linhas por segundo, por projeto. Quando esse valor é excedido, ocorre o erro quotaExceeded. O número máximo de linhas por segundo por tabela também é de 100.000. Você pode usar toda essa cota em uma tabela ou pode dividir essa cota entre várias tabelas em um projeto.
  • Máximo de linhas por solicitação: 10.000 linhas por solicitação. Recomendamos 500 linhas, no máximo. Nas operações em lote, o desempenho e a capacidade podem aumentar, mas às custas de latência por solicitação. O processamento pode ficar ineficiente com poucas linhas por solicitação, além da sobrecarga de cada solicitação. A capacidade pode diminuir com muitas linhas por solicitação. Recomendamos o uso de aproximadamente 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.
  • Bytes máximos por segundo: 100 MB por segundo, por tabela. Exceder essa quantidade causará o erro quotaExceeded.

Se você precisar de mais cotas de dados de streaming para seu projeto, envie uma solicitação na página do Console do Google Cloud Platform. Você pode definir uma cota personalizada para dados de streaming em incrementos de 50.000 linhas. Normalmente, você receberá uma resposta dentro de dois a três dias úteis.

Solicitações da API

Todas as solicitações da 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:

  • Máximo de bytes por segundo por projeto retornado por chamadas para tabledata.list: 60 MB/segundo
    Quando você chama tabledata.list, pode retornar no máximo 60 MB por segundo dos dados de linha 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: 60 MB/segundo
    Quando você chama tabledata.list, pode retornar no máximo 150.000 linhas de tabela por segundo por projeto. O limite se aplica ao projeto que contém a tabela 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
    Quando você chama 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 nas tabelas de destino.

Solicitações projects.list

O método projects.list lista todos os projetos a que você recebeu acesso. Os limites a seguir se aplicam a solicitações projects.list:

  • Número máximo de solicitações por segundo por projeto: 2
    Quando você chama projects.list, é possível criar no máximo 2 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
    Quando você chama jobs.get, é possível criar no máximo 1.000 solicitações por segundo 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 está 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 resolver problemas para receber uma lista completa de códigos de erros e etapas para solução de problemas.

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

Enviar comentários sobre…