Cotas e limites

Neste documento, listamos as quotas e os quotas que se aplicam ao Bigtable .

Uma cota restringe quanto de um determinado recurso compartilhado do Google Cloud o projeto do Google Cloud pode usar, incluindo hardware, software e componentes de rede. Dessa forma, as cotas fazem parte de um sistema que:

• monitora o uso ou o consumo de produtos e serviços do Google Cloud;
• restringe o consumo desses recursos por motivos, que garantem imparcialidade e reduzem picos de uso;
• mantém as configurações que aplicam automaticamente restrições prescritas;
• fornece um meio de solicitar ou faz alterações na cota.

Na maioria dos casos, quando uma cota é excedida, o sistema bloqueia imediatamente o acesso ao recurso relevante do Google. Além disso, a tarefa que você está tentando executar falha. Na maioria dos casos, as cotas se aplicam a todos os projetos do Google Cloud. Além disso, elas são compartilhadas entre todos os aplicativos e endereços IP que usam esse projeto.

Para aumentar ou diminuir a maioria das cotas, use o console do Google Cloud. Para mais informações, consulte Solicitar uma cota maior.

Também há limites nos recursos do Bigtable. Esses limites não estão relacionados ao sistema de cotas. Não é possível mudar os limites, a menos que seja indicado o contrário.

Observação :quando você envia 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 de operações de administrador, exceto onde 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 deve aumentar com o aumento do uso. 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 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 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 tabela	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 da tabela	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 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	Exclui 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	Acessa e lista backups.	Por dia em cada projeto: 864.000 ops
Método RestoreTable	Restaura o 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 de HDD e até o número padrão de nós de 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 poderá 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.

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.

Backups

• Número máximo de backups que podem ser criados: 150 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

Aumento de dados

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

Tamanho dos dados nas tabelas

Limites recomendados

Projete seu esquema para manter o tamanho dos dados dentro 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 o 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.