Visão geral da coleta de lixo

Nesta página, descrevemos como a coleta de lixo funciona no Bigtable e abordamos os seguintes tópicos:

  • Tipos de coleta de lixo
  • Configurações padrão de coleta de lixo
  • Quando os dados são excluídos
  • 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 Bigtable. Uma política de coleta de lixo é um conjunto de regras que você cria para informar 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 excluídos, os dados aparecem nos resultados de leitura. É possível filtrar as leituras para excluir esses dados.

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

  • 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 o tamanho de uma linha exceda 100 MB. O limite é 256 MB. Se você não precisar manter dados antigos ou versões desatualizadas dos seus 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 qualificados para a coleta de lixo sejam excluídos. Esse processo costuma levar alguns dias, mas pode durar até uma semana.

É possível definir políticas de coleta de lixo de maneira programática ou com a CLI 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 então exclui os dados de acordo com as regras da política.

Timestamps

No Bigtable, a interseção de uma linha e uma coluna pode ter várias células, que contêm versões com carimbo de data/hora do valor dessa interseção. Cada célula tem um carimbo de data/hora. Um carimbo de data/hora é o número de microssegundos desde a época do Unix, 1970-01-01 00:00:00 UTC. Você pode usar carimbo de data/hora padrão ou defini-los ao enviar solicitações de gravação.

O carimbo de data/hora que você envia ao Bigtable precisa ser um valor em microssegundos com precisão de milissegundos no máximo. Um carimbo de data/hora com precisão de microssegundos, como 3023483279876543, é rejeitado. Neste exemplo, o valor aceitável do carimbo de data/hora é 3023483279876000.

A propriedade do carimbo de data/hora de uma célula pode ser um carimbo "real", que reflete 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, veja os casos de uso, que mostram também os riscos de usá-los:

Defina um carimbo de data/hora padrão ao enviar solicitações de gravação, a menos que você precise aceitar um caso de uso com carimbos de data/hora artificiais.

Tipos de coleta de lixo

Nesta seção, descrevemos os tipos de coleta de lixo disponíveis no 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 Bigtable analisa cada grupo de colunas durante a coleta de lixo e exclui 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, crie um grupo com essas duas colunas e defina 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. Neste 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 Bigtable examinar o grupo de colunas durante a coleta de lixo, se uma sexta célula tiver sido gravada na coluna de senha, a célula mais antiga será excluída para manter o número de células em cinco.

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

É possível usar uma combinação de regras de expiração e número de versão para coleta de lixo. Os tipos de combinações são interseção, união e aninhado. Para exemplos de configuração, consulte Coleta de lixo com base em vários critérios.

Intersecção

Uma política de coleta de lixo de interseção marca os dados para exclusão quando atende a todos os critérios em um determinado conjunto de regras. Por exemplo, pode ser útil excluir 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.

Union

Uma política de coleta de lixo de união marca os dados para exclusão quando atende a qualquer item em um determinado conjunto de regras. 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. Neste caso, a política de união é definida para um valor expirado ou um número de versões.

Aninhado

Uma política de coleta de lixo aninhadapossui uma combinação de regras de união e intersecção.

Configurações padrão para coleta de lixo

Não há TTL padrão para um grupo de colunas. O número de células retidas para uma coluna depende de como você cria o grupo de colunas em que a 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 célula mais recente de cada 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 Bigtable reterá um número infinito de células em cada coluna no grupo. Isso inclui grupos de colunas criados com gcloud e a CLI 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 excluídos

A coleta de lixo é um processo contínuo no qual o 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 excluídos, 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 como 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 sexto valor, sempre filtre tudo, exceto as cinco versões mais recentes.

O armazenamento de dados expirados será cobrado até que ocorra a compactação e os dados sejam excluídos.

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

Se quiser ter certeza de que os dados marcados para coleta de lixo serão excluídos, 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. 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.

Replicação e coleta de lixo

A replicação pode afetar a coleta de lixo de algumas maneiras.

Coleta de lixo baseada em versão e uso de CPU

Em uma instância que usa replicação, as exclusões de coletas de lixo baseadas em versão são replicadas para todos os clusters na instância da mesma forma que as solicitações de aplicativos são replicadas. Se você gravar rapidamente novas células que fazem com que células mais antigas sejam marcadas para exclusão, poderá haver aumento na utilização da CPU quando o Bigtable excluir as células desatualizadas e replicar essas exclusões para outros clusters na instância. Esteja preparado para esse aumento no uso da CPU se você adicionar um cluster a uma instância que contenha tabelas que usam a coleta de lixo baseada em versão.

A coleta de lixo baseada em idade, por outro lado, não aumenta o uso da CPU em instâncias replicadas.

Como alterar políticas de coleta de lixo com base em versão

É 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.

Mudanças nas políticas de coleta de lixo com base na idade

É possível aumentar ou diminuir o tempo de retenção especificado nas políticas de coleta de lixo, independentemente de a instância usar replicação ou não. Também é possível excluir uma política de coleta de lixo com base na idade.

Diminuir o tempo de retenção

Se você diminuir o tempo de retenção em uma política baseada em idade, pode levar até uma semana para que todos os clusters sincronizem e usem a nova política.

Como aumentar o tempo de retenção

Em uma tabela replicada, é possível aumentar o tempo de retenção de uma política de coleta de lixo em no máximo 90 dias.

Se você aumentar o período de armazenamento de um grupo de colunas, esteja ciente de que seus clusters podem ficar fora de sincronia por mais de uma semana. Para ver o motivo, considere um caso hipotético em que você tem uma tabela em uma instância de dois clusters e altera o período de armazenamento de um grupo de colunas de 30 para 50 dias:

  1. Uma solicitação de gravação da chave de linha ip#685 é enviada ao cluster A com um valor 2023-01-02 para a coluna click-through no grupo de colunas profile. Os dados são replicados para o cluster B.
  2. Trinta e um dias depois, a coleta de lixo ocorre no cluster A, e o valor na coluna click-through é reconhecido como expirado e excluído.
  3. Você altera a política de coleta de lixo para o grupo de colunas profile, aumentando o TTL de 30 para 50 dias.
  4. Um dia depois, a coleta de lixo é executada no cluster B. Como o TTL é de 50 dias, o valor 2023-01-02 é mantido.
  5. Os clusters agora estão fora de sincronia e permanecem por quase 20 dias até que o valor que existe no cluster B, mas não no cluster A, seja excluído.

A seguir