Coleta de lixo

Esta página descreve como a coleta de lixo funciona no Cloud Bigtable e abrange os seguintes tópicos:

  • Tipos de coleta de lixo
  • Configurações padrão de coleta de lixo
  • Quando os dados são removidos
  • Alterações nas políticas de coleta de lixo para tabelas replicadas

Visão geral da coleta de lixo

A coleta de lixo é o processo automático e contínuo de remover dados expirados e obsoletos das tabelas do Cloud Bigtable. Uma política de coleta de lixo é um conjunto de regras que você cria nesse estado quando os dados em um grupo de colunas específico não são mais necessários.

A coleta de lixo é um processo de segundo plano assíncrono interno. Pode levar até uma semana para que os dados qualificados para a coleta de lixo sejam realmente removidos. Esse processo ocorre em uma programação fixa que não varia com base em quantos dados precisam ser removidos. Até que sejam removidos, os dados aparecerão nos resultados de leitura. É possível filtrar as leituras para excluir esses dados.

Os benefícios das políticas de coleta de lixo incluem o seguinte:

  • Minimizar o tamanho das linhas: é sempre desejável evitar que as linhas cresçam indefinidamente. Linhas grandes afetam negativamente o desempenho. O ideal é nunca permitir que uma linha cresça além do tamanho de 100 MB. O limite é de 256 MB. Se não for necessário manter dados antigos ou versões antigas dos dados atuais, o uso da coleta de lixo poderá ajudar a minimizar o tamanho de cada linha.
  • Manter os custos baixos: a coleta de lixo garante que não seja necessário pagar para armazenar dados que não são mais necessários ou usados. O armazenamento de dados expirados ou obsoletos será cobrado até que ocorra a compactação e os dados coletados por coleta de lixo sejam removidos. Normalmente, esse processo leva alguns dias, mas pode levar até uma semana.

É possível definir políticas de coleta de lixo de maneira programática ou com a ferramenta cbt. Políticas de coleta de lixo são definidas no nível do grupo de colunas.

Cada grupo de colunas em uma tabela tem a própria política de coleta de lixo. Esse processo procura a política atual de coleta de lixo para cada grupo de colunas e, em seguida, remove os dados de acordo com as regras da política.

Carimbos de data/hora

No Cloud Bigtable, a interseção de uma linha e uma coluna pode ter várias células, que são versões diferentes do valor nessa interseção. Cada célula tem um carimbo de data/hora. A propriedade do carimbo de data/hora de uma célula pode ser um carimbo "real", refletindo o tempo real em que o valor da célula é gravado, ou um carimbo "artificial". Os carimbos de data/hora artificiais incluem números sequenciais, zeros ou valores formatados por carimbos de data/hora que não são o tempo real em que a célula foi gravada. Antes de usar carimbos de data/hora artificiais, consulte os casos de uso, que mostram também os riscos de usá-los:

Tipos de coleta de lixo

Esta seção descreve os tipos de coleta de lixo disponíveis no Cloud Bigtable. Veja exemplos de código para cada tipo de coleta de lixo em como configurar a coleta de lixo.

Valores de expiração (baseados em idade)

É possível definir uma regra de coleta de lixo com base no carimbo de data/hora de cada célula. Por exemplo, talvez você não queira manter nenhuma célula com carimbos de data/hora de mais de 30 dias antes da data e hora atuais. Com esse tipo de regra de coleta de lixo, você define o time to live (TTL) dos dados. O Cloud Bigtable analisa cada grupo de colunas durante a coleta de lixo e remove todas as células que expiraram.

Número de versões

É possível definir uma regra de coleta de lixo que declare explicitamente o número máximo de células a serem mantidas para todas as colunas de um grupo.

Por exemplo, se você quiser manter apenas o nome de usuário e o endereço de e-mail mais recentes de um cliente, poderá criar um grupo de colunas contendo essas duas colunas e definir o número máximo de valores como 1 para esse grupo.

Em outro caso, talvez você queira manter as últimas cinco versões do hash de senha de um usuário para garantir que a senha não seja reutilizada. Nesse caso, você definiria o número máximo de versões para o grupo de colunas contendo a coluna de senha como 5. Quando o Cloud Bigtable examinar o grupo de colunas durante a coleta de lixo, se uma 6ª célula tiver sido gravada na coluna de senha, a célula mais antiga será coletada como lixo para manter o número de versões em cinco.

Combinações de regras de expiração e número de versão

Dois tipos de políticas de coleta de lixo estão disponíveis para combinar esses tipos de regras: intersecção e união.

Intersecção

Uma política de coleta de lixo de intersecção removerá todos os dados correspondentes a todo um conjunto de regras específicas. Por exemplo, pode ser útil remover perfis com mais de 30 dias, mas sempre manter pelo menos um para cada usuário. Nesse caso, a política de intersecção para o grupo de colunas que contém a coluna de perfil consistiria em uma regra para um valor de expiração e uma regra para o número de versões.

União

Uma política de coleta de lixo de união removerá todos os dados correspondentes a qualquer conjunto de regras específicas. Por exemplo, pode ser útil manter no máximo dois registros de visualização de página por usuário, mas somente se eles tiverem menos de 30 dias. Nesse caso, a política de união seria definida para um valor expirado ou um número de versões.

Configurações padrão para coleta de lixo

Não há TTL padrão para um grupo de colunas. O número padrão de versões de uma coluna depende do modo de criação do grupo em que essa coluna está, conforme explicado nas seções a seguir.

Política do HBase

Se o grupo de colunas for criado com o cliente HBase para Java, o shell do HBase ou outra ferramenta que use o cliente HBase para Java, o Cloud Bigtable manterá apenas a versão mais recente de cada valor no grupo, a menos que a regra seja alterada. Essa configuração padrão é consistente com o HBase.

Todas as outras ferramentas ou bibliotecas de cliente

Se o grupo de colunas for criado com qualquer outra ferramenta ou biblioteca de cliente, o Cloud Bigtable reterá um número infinito de versões de cada valor. Isso inclui os grupos de colunas criados com a gcloud e a ferramenta cbt. Altere a política de coleta de lixo para o grupo de colunas se quiser limitar o número de versões.

Quando os dados são removidos

A coleta de lixo é um processo contínuo no qual o Cloud Bigtable verifica as regras de cada grupo de colunas e remove os dados expirados e obsoletos de acordo. Em geral, pode levar até uma semana a partir do momento em que os dados correspondem aos critérios nas regras para que eles sejam realmente removidos. Não é possível alterar o tempo de coleta de lixo.

Como pode levar até uma semana para que os dados sejam coletados como lixo, nunca confie somente nas políticas de coleta de lixo para garantir que as solicitações de leitura retornem os dados desejados. Sempre aplique, às solicitações de leitura, um filtro que exclua os mesmos valores das regras de coleta de lixo. É possível filtrar limitando o número de células por coluna ou especificando um intervalo de carimbo de data/hora.

Por exemplo, digamos que a regra de coleta de lixo de um grupo de colunas esteja definido para manter apenas as cinco versões mais recentes de um perfil e que cinco versões já estejam armazenadas. Após uma nova versão do perfil ser gravada, pode levar até uma semana para a célula mais antiga ser coletada como lixo. Portanto, para evitar a leitura do 6º valor, será sempre necessário filtrar tudo, exceto as cinco versões mais recentes.

O armazenamento de dados expirados será cobrado até que ocorra a compactação e os dados coletados por coleta de lixo sejam removidos.

A coleta de lixo é retroativa: quando uma nova política desse processo é definida, nos próximos dias ela é aplicada a todos os dados da tabela. Se a nova política for mais restritiva que a anterior, os dados antigos serão removidos conforme o trabalho em segundo plano ocorrer, afetando os dados que foram gravados antes da alteração da política.

Se quiser ter certeza de que os dados estão sendo coletados, consulte a tabela e compare os dados com os resultados esperados. Também é possível monitorar o tamanho da tabela no Console do Google Cloud Platform. Uma tabela que nunca fica menor pode refletir uma política de coleta de lixo que não está funcionando conforme o esperado. Lembre-se, entretanto, que a coleta de lixo é executada com um atraso.

Alterações nas políticas de coleta de lixo para tabelas replicadas

O Cloud Bigtable permitirá modificar ou excluir uma política para um grupo de colunas a qualquer momento, se a tabela estiver em uma instância de cluster único. Por outro lado, para proteger os dados, algumas restrições se aplicam a tabelas na instância replicada.

É possível modificar o número máximo de versões de um grupo de colunas em uma tabela replicada. No entanto, se o número de versões de um grupo de colunas for diminuído, poderá levar até uma semana para todos os clusters replicados refletirem o novo número mais baixo. Portanto, use sempre filtros ao ler os dados.

O Cloud Bigtable não permitirá que o TTL de um grupo de colunas em uma tabela replicada seja aumentado. Para entender o motivo, considere um caso em que você quer alterar o TTL do grupo de colunas de 30 para 60 dias. A coleta de lixo baseada em idade pode ser executada separadamente em cada cluster. Como resultado, no momento em que a política for alterada, a coleta de lixo poderá ter removido um valor de 31 dias em uma cópia de uma tabela, mas não em outra. Alterar a política de coleta de lixo nessa situação pode deixar as cópias fora de sincronia por quase um mês.

Pelo mesmo motivo, o Cloud Bigtable não permitirá a exclusão de uma política de coleta de lixo baseada em idade de um grupo de colunas em uma tabela replicada.

A seguir

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

Enviar comentários sobre…

Documentação do Cloud Bigtable