Cotas e limites

Este documento lista as cotas e os limites do sistema que se aplicam ao Bigtable. As cotas especificam a quantidade de um recurso compartilhado e contável que pode ser usado e são definidas por serviços do Google Cloud, como o Bigtable. Os limites do sistema são valores fixos que não podem ser alterados.

O Google Cloud usa cotas para garantir a imparcialidade e reduzir picos no uso e na disponibilidade de recursos. Uma cota restringe quanto de um recurso do Google Cloud o projeto do Google Cloud pode usar. As cotas se aplicam a vários tipos de recursos, incluindo hardware, software e componentes de rede. Por exemplo, as cotas podem restringir o número de chamadas de API para um serviço, o número de balanceadores de carga usados simultaneamente pelo projeto ou o número de projetos que podem ser criados. As cotas protegem a comunidade de usuários do Google Cloud, impedindo a sobrecarga de serviços. As cotas também ajudam você a gerenciar seus próprios recursos do Google Cloud.

O sistema de cotas do Cloud faz o seguinte:

• Monitora o consumo de produtos e serviços do Google Cloud.
• Restringe o consumo desses recursos.
• Fornece um meio de solicitar mudanças no valor da cota

Na maioria dos casos, quando você tenta consumir mais de um recurso do que a cota permite, o sistema bloqueia o acesso ao recurso e a tarefa que você está tentando executar falha.

As cotas geralmente se aplicam ao projeto do nível Google Cloud. O uso de um recurso em um projeto não afeta a cota disponível em outro. Em um projeto do Google Cloud, as cotas são compartilhadas entre todos os aplicativos e endereços IP.

Para ajustar a maioria das cotas, use o console do Google Cloud. Para mais informações, consulte Solicitar um ajuste de cota.

Também há limites de sistema nos recursos do Bigtable. Não é possível alterar os limites.

Observação: ao enviar várias operações em um único lote, cada uma delas é contabilizada na cota ou no limite.

Cotas

Veja nesta seção as cotas padrão que se aplicam a todo o uso do Bigtable.

Cotas de operação de administrador

As cotas a seguir afetam o número de operações administrativas do Bigtable que são chamadas para a API Admin e podem ser realizadas em um determinado período.

Em geral, não é possível solicitar um aumento nas cotas da operação de administrador, exceto quando indicado. Às vezes, são concedidas exceções quando é fornecida uma justificativa forte. No entanto, o número de chamadas que o aplicativo faz para a API Admin não aumenta quando o uso aumenta. Caso isso ocorra, geralmente é um sinal de que o código do aplicativo faz chamadas desnecessárias para a API Admin. É necessário alterar o aplicativo em vez de solicitar um aumento na cota de operação do administrador.

As cotas diárias são redefinidas à meia-noite, horário do Pacífico.

Nome	Descrição	Cota padrão
Instâncias e clusters
Solicitações de leitura em instâncias e clusters	Leitura da configuração de uma instância ou cluster, como o nome da instância ou o número de nós em um cluster, ou a leitura de uma lista de instâncias	Por dia em cada projeto: 864.000 ops (média de 10 ops/segundo) Por minuto por usuário: 1.000 ops
Solicitações de gravação em instâncias e clusters	Alteração da configuração de uma instância ou cluster, como o nome da instância ou o número de nós em um cluster, ou a criação de uma nova instância	Por dia em cada projeto: 500 ops Por minuto por usuário: 100 ops
Perfis de aplicativos
Solicitações de leitura de perfis de aplicativos	Leitura da configuração de um perfil de aplicativo	Por minuto em cada projeto: 5.000 ops Por minuto por usuário: 1.000 ops
Solicitações de gravação de perfis de aplicativos	Alteração da configuração de um perfil de aplicativo	Por minuto em cada projeto: 500 ops Por minuto por usuário: 100 ops
Tabelas
Solicitações de leitura de administradores de tabelas	Leitura da configuração de uma tabela (por exemplo, detalhes sobre os grupos de colunas), ou a leitura de uma lista de tabelas	Por dia em cada projeto: 864.000 ops (média de 10 ops/segundo) Por minuto por usuário: 1.000 ops
Solicitações de gravação de administrador da tabela	Alteração da configuração de uma tabela, como as configurações da coleta de lixo de um grupo de colunas	Por dia em cada projeto: 5.000 ops Por minuto por usuário: 100 ops
Método DropRowRange	Exclusão de um intervalo de linhas de uma tabela em uma única operação	Por dia em cada projeto: 5.000 ops Por minuto por usuário: 100 ops
Backups
Operações de backup	Criação, atualização e exclusão de um backup.	Por dia em cada projeto: 1.000 ops Por minuto por usuário: 10 ops^1
Solicitações de recuperação de backup	Acesso e lista de backups.	Por dia em cada projeto: 864.000 ops
Método RestoreTable	Restauração do backup para uma nova tabela.	Por dia em cada projeto: 5.000 ops Por minuto por usuário: 100 ops
Identity and Access Management
Solicitações get refinadas da ACL	Leitura de informações sobre a política do IAM para uma instância do Bigtable ou teste das permissões do IAM para uma instância.	Por dia em cada projeto: 864.000 ops (média de 10 ops/segundo) Por minuto por usuário: 1.000 ops
Solicitações set refinadas da ACL	Alteração da política do IAM para uma instância do Bigtable.	Por dia em cada projeto: 864.000 ops (média de 10 ops/segundo) Por minuto por usuário: 1.000 ops
Qualificado para aumento do limite de cota.

Cotas de nós

Um projeto do Google Cloud contém instâncias do Bigtable, que são contêineres para clusters. Um cluster representa o serviço do Bigtable que está efetivamente sendo executado em uma única zona. Os clusters contêm nós, que são recursos computacionais que possibilitam o gerenciamento dos dados pelo Bigtable.

O número padrão de nós que é possível provisionar por zona em cada projeto depende da região. É possível provisionar até o número padrão de nós HDD e até o número padrão de nós SSD por zona em um projeto.

As cotas de nó padrão são as seguintes:

Região	SSD	HDD
asia-east1	100	100
europe-west1	200	200
us-central1	200	200
us-east1	50	50
us-east4	50	50
us-west1	100	100
Todos os outros locais do Bigtable	30	30

Se você ativar o escalonamento automático de um cluster, o número máximo de nós configurado será contabilizado nesse limite, mesmo que o cluster não esteja dimensionado para esse número de nós. Se for necessário provisionar mais nós além do limite padrão, é possível pedir um aumento.

Cotas e disponibilidade de nós

A cota de nós é o número máximo de nós que você pode provisionar por zona em cada projeto. As cotas não garantem que você sempre consiga adicionar nós a um cluster. Se uma zona estiver sem nós, talvez não seja possível adicionar nós a um cluster nessa zona, mesmo que você tenha cota restante no projeto.

Por exemplo, se você tentar adicionar 10 nós de SSD a um cluster que já tem 20 nós, mas a zona estiver sem nós, não será possível adicionar esses 10 nós, mesmo que a cota de nós para Os nós SSD nessa região são 30.

Nessas situações, tentamos aumentar os recursos dos nós de uma zona e conceder solicitações quando esses recursos estiverem disponíveis, sem garantia de tempo e conclusão.

Os nós provisionados têm sempre garantia de disponibilidade.

Cotas do Data Boost

As cotas de unidade de processamento do servidor (SPU) a seguir se aplicam a cada projeto e região.

Região	SPUs
asia-east1	100.000
europe-west1	200.000
us-central1	200.000
us-east1	100.000
us-east4	100.000
us-west1	100.000
Todos os outros locais do Bigtable	30.000

Para mais informações sobre o Data Boost, consulte a Visão geral do Data Boost.

Ver informações sobre cotas

Use o Console do Google Cloud para descobrir o número de nós de SSD e HDD que o projeto do GCP já tem em cada zona. No painel de navegação à esquerda, passe o cursor sobre IAM e administrador, clique em Cotas e use o menu suspenso Serviço para selecionar o serviço da API Bigtable Admin.

A página exibe linhas que mostram cotas para cada combinação de serviço, tipo de nó e local. Procure as linhas com a legenda nós de SSD por zona ou nós de HDD por zona. A coluna Limite mostra o número máximo de nós permitidos para o tipo de nó e local fornecidos, e a coluna Uso atual mostra o número de nós que existem atualmente. A diferença entre esses dois números é o número de nós que é possível adicionar sem mais solicitações.

Solicitar um aumento de cota de nós

Para garantir que haja tempo suficiente para processar sua solicitação, sempre planeje com antecedência e solicite mais recursos alguns dias antes que você precise deles. Não há garantia de que as solicitações para aumentos de cota de nós sejam concedidas. Para mais informações, consulte Como trabalhar com cotas.

É necessário ter no mínimo permissões no nível do editor no projeto que contém a instância para a qual você quer solicitar um aumento de cota.

Não há custo para solicitar um aumento de cota. Seus custos aumentam apenas se você usar mais recursos.

1. Acesse a página Cotas.

   Acessar a página "Cotas"

2. Na página Cotas, selecione as opções que você quer alterar.
3. Clique no botão Editar cotas na parte superior da página.
4. No painel à direita, digite seu nome, e-mail e número de telefone e, em seguida, clique em Próximo.
5. Insira o número esperado para o novo limite de cotas e, em seguida, clique em Próximo.
6. Envie a solicitação.

Limites

Veja nesta seção os limites que se aplicam ao uso do Bigtable. Os limites são incorporados no serviço e não podem ser alterados.

Perfis de aplicativos por instância

O número máximo de perfis de aplicativos permitido para cada instância é 2.000.

Visualizações autorizadas

• Visualizações autorizadas por instância do Bigtable: até 10.000
• Prefixos de qualificadores de coluna por visualização autorizada: 10

Backups

• Número máximo de backups padrão que podem ser criados: 150 por tabela em cada cluster
• Número máximo de backups quentes que podem ser criados: 10 por tabela em cada cluster
• Período de retenção mínimo de um backup: seis horas após o tempo de criação inicial
• Período máximo de retenção de um backup: 90 dias após a data de criação inicial

Data Boost

Um perfil do app Data Boost não pode enviar mais de mil solicitações de leitura por segundo.

Tamanho dos dados nas tabelas

Limites recomendados

Projetar seu esquema para manter o tamanho dos dados abaixo dos limites recomendados.

• Grupos de colunas por tabela: 100
• Um qualificador único de coluna: 16 KB
• Um valor único em uma célula da tabela: 10 MB
• Todos os valores em uma única linha: 100 MB

Limites rígidos

Além disso, você precisa garantir que seus dados se encaixem nesses limites absolutos:

• Uma única chave de linha: 4 KB
• Um valor único em uma célula da tabela: 100 MB
• Todos os valores em uma única linha: 256 MB

Esses limites de tamanho são medidos em kilobytes (KB) binários, em que 1 KB corresponde a 2¹⁰ bytes, e megabytes (MB) binários, em que 1 MB corresponde a 2²⁰ bytes. Essas unidades de medida também são conhecidas como kibibytes (KiB) e mebibytes (MiB).

Limites de operação

Quando você envia várias mutações ao Bigtable como um único lote, os seguintes limites se aplicam:

• Um lote de mutações condicionais, que chamam CheckAndMutate, pode incluir até 100.000 mutações verdadeiras e até 100.000 mutações falsas no lote.

• Em lotes de todos os outros tipos de mutações, não é possível incluir mais de 100.000 mutações nesse lote.

Regiões por instância

Uma instância do Bigtable pode ter clusters em até 8 regiões em que o Bigtable está disponível. É possível criar um cluster em cada zona de uma região. Para uma lista de zonas disponíveis, consulte Locais do Bigtable.

Filtros de linha

Um filtro de linha não pode exceder 20 KB. Se você receber uma mensagem de erro, altere ou diminua seu filtro.

Armazenamento por nó

Se um cluster não tiver nós suficientes (com base na carga de trabalho atual e na quantidade de dados armazenados), o Bigtable não terá recursos de CPU suficientes para gerenciar todos os blocos associados ao cluster. O Bigtable também não conseguirá realizar as tarefas essenciais de manutenção em segundo plano. Consequentemente, pode ser que o cluster não consiga processar solicitações de entrada, e isso fará a latência aumentar. Para saber mais, consulte Vantagens e desvantagens entre o uso do armazenamento e o desempenho.

Para evitar que esses problemas ocorram, monitore a utilização do armazenamento dos seus clusters. Assim, você terá certeza de que tem nós suficientes para a quantidade de dados em um cluster, com base nos limites a seguir.

• Clusters em SSD: 5 TB por nó
• Clusters em HDD: 16 TB por nó

Esses valores são medidos em terabytes (TB) binários, em que 1 TB corresponde a 2⁴⁰ bytes. Essa unidade de medida também é conhecida como tebibyte (TiB).

Importante: se algum cluster em uma instância exceder o limite absoluto na quantidade de armazenamento por nó, ocorrerá uma falha nas gravações em todos os clusters dessa instância até que você adicione nós em cada cluster que esteja acima do limite. Além disso, se você tentar remover nós de um cluster e essa alteração fizer com que o cluster exceda o limite absoluto de armazenamento, o Bigtable recusará a solicitação.

Recomendamos incluir uma quantidade de nós ao cluster que seja suficiente para que você esteja usando apenas 70% dos limites. Isso ajuda a absorver picos repentinos no uso do armazenamento. Por exemplo, se você armazena 50 TB de dados em um cluster que usa o armazenamento SSD, provisione pelo menos 15 nós, que poderão processar até 75 TB de dados. Caso você não adicione uma quantidade significativa de dados ao cluster, ignore esta recomendação e use até 100% do limite no armazenamento.

Tabelas por instância

O Bigtable suporta no máximo 1.000 tabelas em cada instância.

Limites de tamanho do ID

Veja a seguir os comprimentos mínimo e máximo de ID (número de caracteres) compatíveis com o Bigtable.

• Perfil do app: 1-50
• Backup: 1-50
• Cluster: 6-30
• Grupo de colunas: 1-64
• Instância: 6-33
• Tabela: 1-50
• visualização autorizada: 1 a 50

Políticas de uso

O uso deste serviço precisa atender aos Termos de Serviço e à Política de Privacidade do Google.