Vista geral da recolha de lixo

Esta página descreve como funciona a recolha de lixo no Bigtable e aborda os seguintes tópicos:

  • Tipos de recolha de lixo
  • Predefinições de recolha de lixo
  • Quando os dados são eliminados
  • Alterações às políticas de recolha de lixo para tabelas replicadas

Vista geral da recolha de lixo

A recolha de lixo é o processo automático e contínuo de remoção de dados expirados e obsoletos das tabelas do Bigtable. Uma política de recolha de lixo é um conjunto de regras que cria e que indicam quando os dados numa família de colunas específica deixam de ser necessários.

A recolha de lixo é um processo em segundo plano assíncrono incorporado. Pode demorar até uma semana antes de os dados elegíveis para a recolha de lixo serem efetivamente eliminados. A recolha de lixo ocorre num horário fixo que não varia com base na quantidade de dados que precisam de ser eliminados. Até os dados serem eliminados, estes aparecem nos resultados de leitura. Pode filtrar as suas leituras para excluir estes dados.

As vantagens das políticas de recolha de lixo incluem o seguinte:

  • Minimizar o tamanho das linhas: deve sempre impedir que as linhas aumentem indefinidamente. As linhas grandes afetam negativamente o desempenho. Idealmente, nunca deve permitir que uma linha cresça para além de 100 MB e o limite é de 256 MB. Se não precisar de manter dados antigos ou versões anteriores dos seus dados atuais, a utilização da recolha de lixo pode ajudar a minimizar o tamanho de cada linha.
  • Reduza os custos: a recolha de lixo garante que não paga para armazenar dados que já não são necessários nem usados. É-lhe cobrado o armazenamento de dados expirados ou obsoletos até que a compactação ocorra e os dados elegíveis para a recolha de lixo sejam eliminados. Normalmente, este processo demora alguns dias, mas pode demorar até uma semana.

Pode definir políticas de recolha de lixo de forma programática ou com a cbt CLI . As políticas de recolha de lixo são definidas ao nível da família de colunas.

Cada família de colunas numa tabela tem a sua própria política de recolha de lixo. O processo de recolha de lixo procura a política de recolha de lixo atual para cada família de colunas e, em seguida, elimina os dados de acordo com as regras na política.

Indicações de tempo

No Bigtable, a interseção de uma linha e uma coluna pode ter várias células, que contêm versões com data/hora do valor para essa interseção. Cada célula tem uma indicação de tempo. Uma indicação de tempo é o número de microssegundos desde o início da época Unix, 1970-01-01 00:00:00 UTC. Pode usar as datas/horas predefinidas ou defini-las quando envia pedidos de gravação.

Uma data/hora que envia para o Bigtable tem de ser um valor de microssegundos com, no máximo, uma precisão de milissegundos. Uma indicação de tempo com precisão de microssegundos, como 3023483279876543, é rejeitada. Neste exemplo, o valor de data/hora aceitável é 3023483279876000.

A propriedade de data/hora de uma célula pode ser uma data/hora "real", que reflete a hora real em que o valor da célula é escrito, ou pode ser uma data/hora "artificial". As datas/horas artificiais incluem números sequenciais, zeros ou valores formatados como datas/horas que não correspondem à hora real em que a célula foi escrita. Antes de usar indicações de tempo artificiais, reveja os exemplos de utilização das indicações de tempo artificiais, incluindo os riscos da sua utilização:

Certifique-se de que define uma data/hora predefinida quando envia pedidos de gravação, a menos que precise de suportar um exemplo de utilização com datas/horas artificiais.

Tipos de recolha de lixo

Esta secção descreve os tipos de recolha de lixo disponíveis no Bigtable. Pode encontrar exemplos de código para cada tipo de recolha de lixo em Configurar a recolha de lixo.

Valores de expiração (com base na idade)

Pode definir uma regra de recolha de lixo com base na data/hora de cada célula. Por exemplo, pode não querer manter células com datas/horas anteriores a 30 dias da data/hora atual. Com este tipo de regra de recolha de lixo, define o tempo de vida (TTL) dos dados. O Bigtable analisa cada família de colunas durante a recolha de lixo e elimina todas as células que tenham expirado.

Número de versões

Pode definir uma regra de recolha de lixo que indique explicitamente o número máximo de células a manter para todas as colunas numa família de colunas.

Por exemplo, se quiser manter apenas o nome de utilizador e o endereço de email mais recentes de um cliente, pode criar uma família de colunas que contenha essas duas colunas e definir o número máximo de valores como 1 para essa família de colunas.

Noutro caso, pode querer manter as últimas cinco versões do hash da palavra-passe de um utilizador para se certificar de que não reutiliza a palavra-passe. Por isso, definiria o número máximo de versões para a família de colunas que contém a coluna de palavra-passe para 5. Quando o Bigtable analisa a família de colunas durante a recolha de lixo, se uma sexta célula tiver sido escrita na coluna de palavra-passe, a célula mais antiga é eliminada para manter o número de células em cinco.

Combinações de regras de data de validade e número da versão

Pode usar uma combinação de regras de data de validade e número da versão para a recolha de lixo. Os tipos de combinações são interseção, união e aninhado. Para ver exemplos de configuração, consulte o artigo Recolha de lixo baseada em vários critérios.

Cruzamento

Uma política de recolha de lixo de interseção marca os dados para eliminação quando cumpre todos os critérios num determinado conjunto de regras. Por exemplo, pode querer eliminar perfis com mais de 30 dias, mas manter sempre, pelo menos, um para cada utilizador. Neste caso, a política de interseção para a família de colunas que contém a coluna de perfil consistiria numa regra para um valor com prazo de validade e numa regra para o número de versões.

Union

Uma política de recolha de lixo de união marca os dados para eliminação quando cumpre qualquer item num determinado conjunto de regras. Por exemplo, pode querer certificar-se de que retém um máximo de dois registos de visualização de páginas por utilizador, mas apenas se tiverem menos de 30 dias. Neste caso, a política de união está definida para um valor que expira ou um número de versões.

Aninhado

Uma política de recolha de lixo aninhada tem uma combinação de regras de união e interseção.

Predefinições para a recolha de lixo

Não existe um TTL predefinido para uma família de colunas. O número de células retidas para uma coluna depende de como cria a família de colunas em que a coluna se encontra, conforme explicado nas secções seguintes.

Política do HBase

Se criar a família de colunas com o cliente HBase para Java, o shell HBase ou outra ferramenta que use o cliente HBase para Java, o Bigtable retém apenas a célula mais recente em cada coluna na família de colunas, a menos que altere a regra. Esta predefinição é consistente com o HBase.

Todas as outras bibliotecas ou ferramentas de cliente

Se criar a família de colunas com qualquer outra biblioteca ou ferramenta de cliente, o Bigtable retém um número infinito de células em cada coluna na família de colunas. Isto inclui famílias de colunas criadas com o gcloud e a CLI cbt. Tem de alterar a política de recolha de lixo para a família de colunas se quiser limitar o número de versões.

Quando os dados são eliminados

A recolha de lixo é um processo contínuo no qual o Bigtable verifica as regras de cada família de colunas e elimina os dados expirados e obsoletos em conformidade. Em geral, pode demorar até uma semana a partir do momento em que os dados correspondem aos critérios nas regras para que os dados sejam efetivamente eliminados. Não pode alterar a hora da recolha de lixo.

Uma vez que a eliminação dos dados expirados pode demorar até uma semana, nunca deve confiar apenas nas políticas de recolha de lixo para garantir que os pedidos de leitura devolvem os dados selecionados. Aplique sempre um filtro aos seus pedidos de leitura que exclua os mesmos valores que as suas regras de recolha de lixo. Pode filtrar limitando o número de células por coluna ou especificando um intervalo de data/hora.

Por exemplo, suponha que a regra de recolha de lixo de uma família de colunas está definida para manter apenas as cinco versões mais recentes de um perfil e que já estão armazenadas cinco versões. Depois de escrever uma nova versão do perfil, a eliminação da célula mais antiga pode demorar até uma semana. Por conseguinte, para evitar a leitura do sexto valor, deve sempre filtrar tudo, exceto as cinco versões mais recentes.

É-lhe cobrado o armazenamento de dados expirados até ocorrer a compactação e os dados serem eliminados.

A recolha de lixo é retroativa: quando é definida uma nova política de recolha de lixo, esta é aplicada a todos os dados na tabela nos dias seguintes. Se a nova política for mais restritiva do que a política anterior, os dados antigos são eliminados à medida que o trabalho em segundo plano é realizado, incluindo os dados escritos antes da alteração da política.

Se quiser certificar-se de que os dados marcados para recolha de lixo estão a ser eliminados, pode consultar a sua tabela e comparar os dados com os resultados esperados. Também pode monitorizar o tamanho da tabela na Google Cloud consola. Uma tabela que nunca fica mais pequena pode refletir uma política de recolha de lixo que não está a funcionar como esperado, mas lembre-se de que a recolha de lixo é executada com um atraso.

Replicação e recolha de lixo

A replicação pode afetar a recolha de lixo de várias formas.

Recolha de lixo baseada na versão e utilização da CPU

Numa instância que usa a replicação, as eliminações da recolha de lixo baseada na versão são replicadas para todos os clusters na instância da mesma forma que os pedidos de aplicação são replicados. Se escrever rapidamente novas células que façam com que as células mais antigas sejam marcadas para eliminação, pode observar um aumento da utilização da CPU quando o Bigtable elimina as células obsoletas e replica essas eliminações para outros clusters na instância. Prepare-se para este aumento na utilização da CPU se adicionar um cluster a uma instância que contenha tabelas que usem a recolha de lixo baseada na versão.

Por outro lado, a recolha de lixo baseada na idade não aumenta a utilização da CPU em instâncias replicadas.

Alterar políticas de recolha de lixo baseadas em versões

Pode modificar o número máximo de versões de uma família de colunas numa tabela replicada. No entanto, se diminuir o número de versões de uma família de colunas, pode demorar até uma semana para que todos os clusters replicados reflitam o novo número inferior. Por isso, deve usar sempre filtros quando lê os dados.

Alterar políticas de recolha de lixo baseadas na idade

Pode aumentar ou diminuir o tempo de retenção especificado nas políticas de recolha de lixo, independentemente de a instância usar a replicação. Se a instância não usar a replicação, também pode eliminar uma política de recolha de lixo baseada na idade.

Diminuir o tempo de retenção

Se diminuir o tempo de retenção numa política baseada na idade, pode demorar até uma semana para que todos os clusters sejam sincronizados e usem a nova política.

Aumentar o tempo de retenção

Numa tabela replicada, pode aumentar o tempo de retenção de uma política de recolha de lixo por um máximo de 90 dias.

Se aumentar o período de retenção de uma família de colunas, tenha em atenção que os clusters podem ficar dessincronizados durante mais de uma semana. Para ver o motivo, considere um caso hipotético em que tem uma tabela numa instância de dois clusters e altera o período de retenção de uma família de colunas de 30 dias para 50 dias:

  1. É enviado um pedido de gravação para a chave da linha ip#685 para o cluster A com um valor de 2023-01-02 para a coluna click-through na família de colunas profile. Os dados são replicados para o cluster B.
  2. Trinta e um dias depois, a recolha de lixo ocorre no cluster A e o valor na coluna click-through é reconhecido como expirado e eliminado.
  3. Altera a política de recolha de lixo para a família de colunas profile, aumentando o TTL de 30 dias para 50 dias.
  4. Um dia depois, a recolha de lixo é executada no cluster B. Uma vez que o TTL é de 50 dias, o valor 2023-01-02 é retido.
  5. Os clusters estão agora dessincronizados e permanecem assim durante quase 20 dias, até que o valor que existe no cluster B, mas não no cluster A, seja finalmente eliminado.

O que se segue?