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.
- Limite de taxa simultânea para consultas interativas: 100 consultas simultâneas
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)
- URIs curinga: 500 URIs curinga por exportação
Para exportar mais do que 50 TB de dados por dia, use a
API BigQuery Storage ou a
instrução
EXPORT DATA
.
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 APIdatasets.insert
,datasets.patch
oudatasets.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.
- 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
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.
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 erroquotaExceeded
.
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
eeu
: 500.000 - Se você preencher o campo
insertId
para cada linha inserida, o limite será de 500.000 linhas por segundo nas multirregiõesus
eeu
, 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 dequotaExceeded
.
- Máximo de linhas por segundo por projeto nas multirregiões
- 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õesus
eeu
, 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 erroquotaExceeded
.
- 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 erroquotaExceeded
.
- 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 erroquotaExceeded
.
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
.
- Comprimento do campo
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.
- Número máximo de consultas
- 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 bytes por segundo em cada projeto retornado por chamadas para
- 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.
- Máximo de linhas por segundo em cada projeto retornado por chamadas para
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 DDLCREATE 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 chamadasReadRows
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.