Quotas e limites

Este documento lista as quotas e os limites do sistema que se aplicam ao Bigtable.

• As quotas têm valores predefinidos, mas normalmente pode pedir ajustes.
• Os limites do sistema são valores fixos que não podem ser alterados.

Google Cloud usa quotas para ajudar a garantir a equidade e reduzir os picos na utilização e disponibilidade de recursos. Uma quota restringe a quantidade de um Google Cloud recurso que o seu Google Cloud projeto pode usar. As quotas aplicam-se a uma variedade de tipos de recursos, incluindo componentes de hardware, software e rede. Por exemplo, as quotas podem restringir o número de chamadas API para um serviço, o número de balanceadores de carga usados em simultâneo pelo seu projeto ou o número de projetos que pode criar. As quotas protegem a comunidade de Google Cloud utilizadores, impedindo a sobrecarga dos serviços. As quotas também ajudam a gerir os seus próprios Google Cloud recursos.

O sistema de quotas da nuvem faz o seguinte:

• Monitoriza o seu consumo de Google Cloud produtos e serviços
• Restringe o seu consumo desses recursos
• Oferece uma forma de pedir alterações ao valor da quota e automatizar os ajustes de quotas

Na maioria dos casos, quando tenta consumir mais de um recurso do que a respetiva quota permite, o sistema bloqueia o acesso ao recurso e a tarefa que está a tentar realizar falha.

Geralmente, as quotas aplicam-se ao nível do Google Cloud projeto A sua utilização de um recurso num projeto não afeta a sua quota disponível noutro projeto. Num Google Cloud projeto, as quotas são partilhadas por todas as aplicações e endereços IP.

Para mais informações, consulte a vista geral das quotas da nuvem.

Para ajustar a maioria das quotas, use a Google Cloud consola. Para mais informações, consulte o artigo Peça um ajuste da quota.

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

Nota: quando envia várias operações num único lote, cada operação no lote conta para a quota ou o limite.

Quotas

Esta secção descreve as quotas predefinidas que se aplicam a toda a sua utilização do Bigtable.

Quotas de operações de administrador

As seguintes quotas afetam o número de operações administrativas do Bigtable (chamadas para a API Admin) que pode realizar num determinado período.

Em geral, não pode pedir um aumento das quotas de operações de administrador, exceto quando indicado. Por vezes, são concedidas exceções quando é apresentada uma forte justificação. No entanto, o número de chamadas que a sua aplicação faz à API Admin não deve aumentar quando a utilização aumenta. Se isto ocorrer, é frequentemente um sinal de que o código da sua aplicação está a fazer chamadas desnecessárias para a API admin e deve alterar a sua aplicação em vez de pedir um aumento da quota de operações de administrador.

As quotas diárias são repostas à meia-noite (hora do Pacífico).

Nome	Descrição	Quota predefinida
Instâncias e clusters
Pedidos de leitura de instâncias e clusters	Ler a configuração de uma instância ou um cluster (por exemplo, o nome da instância ou o número de nós num cluster) ou ler uma lista de instâncias	Por dia por projeto: 864 000 operações (média de 10 operações/segundo) Por minuto por utilizador: 1000 operações
Pedidos de escrita de instâncias e clusters	Alterar a configuração de uma instância ou um cluster (por exemplo, o nome da instância ou o número de nós num cluster) ou criar uma nova instância	Por dia, por projeto: 500 operações Por minuto por utilizador: 100 operações
Perfis de aplicações
Pedidos de leitura do perfil da app	Ler a configuração de um perfil de app	Por minuto por projeto: 5000 operações Por minuto por utilizador: 1000 operações
Pedidos de gravação do perfil da app	Alterar a configuração de um perfil de app	Por minuto por projeto: 500 operações Por minuto por utilizador: 100 operações
Tabelas
Pedidos de leitura de administrador da tabela	Ler a configuração de uma tabela (por exemplo, detalhes sobre as respetivas famílias de colunas) ou ler uma lista de tabelas	Por dia por projeto: 864 000 operações (média de 10 operações/segundo) Por minuto por utilizador: 1000 operações
Pedidos de gravação de administrador de tabelas	Alterar a configuração de uma tabela (por exemplo, as definições de recolha de lixo para uma família de colunas)	Por dia por projeto: 5000 operações Por minuto por utilizador: 100 operações
DropRowRange método	Eliminar um intervalo de linhas de uma tabela numa única operação.	Por dia por projeto: 5000 operações Por minuto por utilizador: 100 operações
Cópias de segurança
Operações de cópia de segurança	Criar, atualizar e eliminar uma cópia de segurança.	Por dia por projeto: 1000 operações Por minuto por utilizador: 10 operações^1
Pedidos de obtenção de cópias de segurança	Obter e listar cópias de segurança.	Por dia por projeto: 864 000 operações
RestoreTable método	Restaurar uma cópia de segurança para uma nova tabela.	Por dia por projeto: 5000 operações Por minuto por utilizador: 100 operações
Gestão de identidade e acesso
Pedidos de obtenção de ACLs detalhadas	Ler informações sobre a política IAM de uma instância do Bigtable ou testar as autorizações IAM de uma instância.	Por dia por projeto: 864 000 operações (média de 10 operações/segundo) Por minuto por utilizador: 1000 operações
Pedidos de definição de ACL detalhada	Alterar a política IAM para uma instância do Bigtable.	Por dia por projeto: 864 000 operações (média de 10 operações/segundo) Por minuto por utilizador: 1000 operações
Elegível para aumento do limite de quotas.

Quotas de nós

Um Google Cloud projeto contém instâncias do Bigtable Google Cloud , que são contentores para clusters. Um cluster representa o serviço Bigtable real em execução numa única zona. Os clusters contêm nós, que são recursos de computação que permitem ao Bigtable gerir os seus dados.

O número predefinido de nós que pode aprovisionar por zona em cada projeto depende da região. Pode aprovisionar até ao número predefinido de nós de HDD e até ao número predefinido de nós de SSD por zona num projeto.

As quotas de nós predefinidas 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
Todas as outras localizações do Bigtable	30	30

Se ativar o redimensionamento automático para um cluster, o número máximo de nós configurado conta para este limite, mesmo que o cluster não seja dimensionado para esse número de nós. Se precisar de aprovisionar mais nós do que os limites predefinidos, pode pedir um aumento.

Quotas e disponibilidade de nós

A quota de nós é o número máximo de nós que pode aprovisionar por zona em cada projeto. As quotas não garantem que consegue sempre adicionar nós a um cluster. Se uma zona estiver sem nós, pode não conseguir adicionar nós a um cluster nessa zona, mesmo que tenha quota restante no seu projeto.

Por exemplo, se tentar adicionar 10 nós de SSD a um cluster que já tenha 20 nós, mas a zona estiver sem nós, não pode adicionar esses 10 nós, mesmo que a quota de nós para nós de SSD nessa região seja de 30.

Nestes casos, tentamos aumentar os recursos dos nós de uma zona e, em seguida, conceder os seus pedidos depois de esses recursos estarem disponíveis, sem garantia de tempo nem de conclusão.

Os nós que aprovisionou têm sempre a garantia de disponibilidade.

Quotas do aumento de dados

As seguintes quotas de unidade de processamento do servidor (SPU) aplicam-se por projeto e por 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
Todas as outras localizações do Bigtable	30 000

Para mais informações sobre o Aumento de dados, consulte a vista geral do Aumento de dados.

Veja informações sobre quotas

Para encontrar o número de nós SSD e HDD que o seu Google Cloud projeto já tem em cada zona, use o Google Cloud console. No painel de navegação do lado esquerdo, posicione o cursor do rato sobre IAM e administrador, clique em Quotas e, de seguida, use o menu pendente Serviço para selecionar o serviço da API Bigtable Admin.

A página apresenta linhas que mostram as quotas para cada combinação de serviço, tipo de nó e localização. Procure as linhas com a legenda Nós SSD por zona ou Nós HDD por zona. A coluna Limite mostra o número máximo de nós permitidos para o tipo de nó e a localização indicados, e a coluna Utilização atual mostra o número de nós existentes atualmente. A diferença entre esses dois números é o número de nós que pode adicionar sem pedir mais.

Peça um aumento da quota de nós

Para garantir que tem tempo suficiente para processar o seu pedido, planeie sempre com antecedência e peça recursos adicionais alguns dias antes de poder precisar deles. Não é garantido que os pedidos de aumentos da quota de nós sejam concedidos. Para mais informações, consulte o artigo Trabalhar com quotas.

Tem de ter, pelo menos, autorizações ao nível do editor no projeto que contém a instância para a qual está a pedir um aumento da quota de nós.

Não existe qualquer custo para pedir um aumento da quota de nós. Os seus custos aumentam apenas se usar mais recursos.

1. Aceda à página Quotas.

   Aceda à página Quotas

2. Na página Quotas, selecione as quotas que quer alterar.
3. Clique no botão Editar quotas na parte superior da página.
4. No painel do lado direito, escreva o seu nome, email e número de telefone e, de seguida, clique em Seguinte.
5. Introduza o novo limite de quota pedido e, de seguida, clique em Seguinte.
6. Envie o seu pedido.

Limites

Esta secção descreve os limites que se aplicam à sua utilização do Bigtable. Os limites estão integrados no serviço e não podem ser alterados.

Perfis de apps por instância

O número máximo de perfis de aplicações que cada instância pode ter é 2000.

Vistas autorizadas

• Vistas autorizadas por instância do Bigtable: até 10 000
• Prefixos de qualificadores de colunas por vista autorizada: 10

Cópias de segurança

• Número máximo de cópias de segurança padrão que podem ser criadas: 150 por tabela por cluster
• Número máximo de cópias de segurança a quente que podem ser criadas: 10 por tabela por cluster
• Período de retenção mínimo de uma cópia de segurança: 6 horas após a hora de criação inicial
• Período de retenção máximo de uma cópia de segurança: 90 dias após a data de criação inicial

Aumento de dados

Um cluster não pode receber mais de 1000 pedidos de leitura de Data Boost por segundo.

Tamanho dos dados nas tabelas

Limites recomendados

Conceba o seu esquema para manter o tamanho dos seus dados abaixo destes limites recomendados.

• Famílias de colunas por tabela: 100
• Um qualificador de coluna único: 16 KB
• Um único valor numa célula de tabela: 10 MB
• Todos os valores numa única linha: 100 MB

Limites rígidos

Além disso, tem de garantir que os seus dados se enquadram nestes limites rígidos:

• Uma chave de linha única: 4 KB
• Um único valor numa célula de tabela: 100 MB
• Todos os valores numa única linha: 256 MB
• Uma única mutação: 200 MB

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

Limites de operação

Quando envia várias mutações para o Bigtable como um único lote, aplicam-se os seguintes limites:

• 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 pode incluir mais de 100 000 mutações no lote.

Regiões por instância

Uma instância do Bigtable pode ter clusters em até 8 regiões onde o Bigtable está disponível. Pode criar um cluster em cada zona numa região. Para ver uma lista das zonas disponíveis, consulte o artigo Localizações do Bigtable.

Filtros de linhas

Um filtro de linhas não pode exceder 20 KB. Se receber uma mensagem de erro, deve remodelar ou encurtar o filtro.

Armazenamento por nó

Se um cluster não tiver nós suficientes, com base na respetiva carga de trabalho atual e na quantidade de dados que armazena, o Bigtable não terá recursos de CPU suficientes para gerir todas as tabelas que estão associadas ao cluster. O Bigtable também não vai poder realizar tarefas de manutenção essenciais em segundo plano. Como resultado, o cluster pode não conseguir processar pedidos recebidos e a latência aumenta. Consulte o artigo Compromissos entre a utilização do armazenamento e o desempenho para ver mais detalhes.

Para evitar estes problemas, monitorize a utilização do armazenamento dos seus clusters para se certificar de que têm nós suficientes para suportar a quantidade de dados no cluster, com base nos seguintes limites:

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

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

Importante: se algum cluster numa instância exceder o limite rígido da quantidade de armazenamento por nó, as escritas em todos os clusters nessa instância falham até adicionar nós a cada cluster que esteja acima do limite. Além disso, se tentar remover nós de um cluster e a alteração fizer com que o cluster exceda o limite rígido de armazenamento, o Bigtable nega o pedido.

Como prática recomendada, adicione nós suficientes ao cluster para usar apenas 70% destes limites, o que ajuda a acomodar picos súbitos na utilização do armazenamento. Por exemplo, se estiver a armazenar 50 TB de dados num cluster que usa armazenamento SSD, deve aprovisionar, pelo menos, 15 nós, que processam até 75 TB de dados. Se não estiver a adicionar quantidades significativas de dados ao cluster, pode exceder esta recomendação e armazenar até 100% do limite.

Tabelas por instância

O Bigtable suporta um máximo de 1000 tabelas em cada instância. As vistas materializadas contam para o número de tabelas.

Limites de comprimento de IDs

Seguem-se os comprimentos mínimo e máximo dos IDs (número de carateres) suportados pelo Bigtable.

• Perfil da app: 1 a 50
• authorized view: 1-50
• Alternativo: 1-50
• Cluster: 6-30
• Família de colunas: 1 a 64
• Instância: 6-33
• Tabela: 1-50
• Ver: 1-128

Visualizações lógicas por instância

O Bigtable suporta um máximo de 1000 vistas lógicas em cada instância.

Políticas de utilização

A utilização deste serviço tem de cumprir os Termos de Utilização, bem como a Política de Privacidade da Google.