Visão geral de time to live (TTL)

O time to live (TTL) permite definir políticas para excluir dados periodicamente das tabelas do Spanner. Remoção de dados desnecessários:

  • Diminui os custos de armazenamento e backup.
  • Reduz o número de linhas que o banco de dados precisa verificar para algumas consultas, potencialmente aumentando o desempenho da consulta.
  • Ajuda a cumprir as regulamentações ou diretrizes do setor que limitam o tempo de retenção em determinados tipos de dados.

O TTL é ideal para atividades de limpeza regulares. Ele é executado continuamente em segundo plano, excluindo periodicamente dados qualificados em lotes. Normalmente, os dados são excluídos em até 72 horas após a data de validade. Cada exclusão requer uma replicação de chave primária nas réplicas do banco de dados, o que gera custos de replicação. Para mais informações, consulte Preços da replicação de dados. O TTL não invalida imediatamente os dados nem os oculta das consultas quando eles se tornam qualificados para exclusão. O TTL também não verifica os dados durante a inserção. Portanto, ele não impede a inserção de uma linha com um carimbo de data/hora expirado.

O TTL foi projetado para minimizar o impacto em outras atividades do banco de dados. Paraleliza o trabalho com mais eficiência do que as consultas do usuário final e inclui lógica de repetição para garantir a limpeza de ponta a ponta.

Outro processo de compactação em segundo plano recupera armazenamento de linhas excluídas, normalmente em até sete dias.

Como funciona o TTL?

É possível definir o TTL nas tabelas do Spanner definindo uma política de exclusão de linhas no esquema do banco de dados, o que permite que o Spanner exclua periodicamente dados desnecessários. Cada tabela pode ter sua própria política. Só é possível especificar uma política de TTL por tabela. Você configura o TTL de forma diferente para bancos de dados com dialeto GoogleSQL e PostgreSQL.

TTL com o GoogleSQL

Com o GoogleSQL, você define uma política de exclusão de linha especificando um carimbo de data/hora e um intervalo para determinar quando uma linha está qualificada para exclusão. Por exemplo, a data da última atualização mais 30 dias.

Um processo do sistema em segundo plano verifica diariamente as linhas qualificadas. Ele carrega em paralelo as exclusões reais em lotes executados perto de onde os dados são armazenados internamente. Cada lote é executado na própria transação em um carimbo de data/hora consistente. Assim, as linhas em um determinado lote, com todos os índices e filhos intercalados, têm a garantia de serem excluídas atomicamente. No entanto, as exclusões em lotes acontecem em transações diferentes.

Como esse é um processo assíncrono em segundo plano, há um atraso entre a qualificação e a exclusão. Normalmente, o atraso é inferior a 72 horas. Como resultado, as linhas podem permanecer na sua tabela por até três dias após a expiração do TTL. Por exemplo, uma tabela com uma política de exclusão de linha que exclui linhas com mais de quatro dias pode incluir linhas de até sete dias, além de linhas mais antigas e não selecionáveis.

Para instruções detalhadas sobre como criar uma política de exclusão de linha do GoogleSQL, consulte Criar uma política de TTL.

TTL com PostgreSQL

Com o PostgreSQL, um proprietário de banco de dados pode usar uma cláusula TTL INTERVAL na instrução CREATE TABLE ou ALTER TABLE para definir uma política de exclusão de linha.

Para definir uma política de exclusão de linha em uma tabela do PostgreSQL, ela precisa ter uma coluna com o tipo de dados TIMESTAMPTZ. A cláusula TTL INTERVAL usa essa coluna para definir uma especificação de intervalo para quando uma linha está qualificada para exclusão.

A cláusula precisa ser avaliada como um número inteiro de dias. Por exemplo, '3 DAYS' é permitido, assim como '4 DAYS 2 MINUTES - 2 MINUTES', mas '4 DAYS 3 MINUTES' não é permitido e um erro é retornado. Não é possível usar números negativos.

A coleta de lixo do TTL exclui linhas qualificadas continuamente e em segundo plano. Como esse é um processo assíncrono em segundo plano, há um atraso entre a qualificação e a exclusão. A tabela pode conter linhas qualificadas para exclusão de TTL, mas o TTL ainda não foi concluído. Normalmente, o atraso é inferior a 72 horas.

Para instruções sobre como criar uma política de exclusão de linha do PostgreSQL, consulte Criar uma política de TTL.

Backups e TTL

Restaurar um backup

Quando você restaura um banco de dados de um backup, todas as políticas de exclusão de linha configuradas no banco de dados de origem são descartadas automaticamente. Isso impede que o Spanner exclua dados expirados assim que o backup é restaurado. Portanto, será necessário reconfigurar o TTL manualmente.

Consistência de dados

Um backup é um snapshot consistente dos seus dados em um determinado momento (version_time). O backup pode conter linhas que podem estar qualificadas para exclusão de TTL, mas o TTL ainda não foi concluído. Da mesma forma, os jobs de exportação do Dataflow leem a tabela inteira em um carimbo de data/hora fixo.

Auditoria

O TTL oferece suporte à auditoria de exclusões por meio de fluxos de alterações. Os registros de dados de fluxos de mudança que rastreiam as mudanças de TTL em um banco de dados têm o campo transaction_tag definido como RowDeletionPolicy e o campo is_system_transaction definido como true. Os leitores de fluxos de mudanças podem filtrar todos os registros de TTL ou todos os registros, exceto os de TTL, dependendo do caso de uso. Confira um exemplo de como usar o Beam para filtrar por tags de transação.

A seguir