Expiração automática de dados com expireAfterSeconds

Os dados de séries temporais quase sempre têm valor limitado — leituras de sensores de 5 anos atrás raramente orientam decisões atuais. Reter dados obsoletos desperdiça armazenamento, torna os backups mais lentos e aumenta o tamanho dos índices. A opção expireAfterSeconds do MongoDB permite declarar um período de retenção no momento da criação da coleção, para que o banco de dados faça a limpeza automaticamente, sem tarefas cron nem rotinas de exclusão no nível da aplicação.

Transmita expireAfterSeconds como uma opção de nível superior, ao lado do objeto timeseries, ao chamar db.createCollection(). O valor é um número inteiro que representa a quantidade de segundos de retenção dos dados. Documentos cujo valor de timeField seja anterior a agora − expireAfterSeconds tornam-se elegíveis para exclusão pela thread de segundo plano do TTL.

A thread de TTL do MongoDB é executada aproximadamente a cada 60 segundos. Para coleções de séries temporais, ela exclui documentos de bucket inteiros, em vez de medições individuais. Um bucket só é excluído quando todas as medições que ele contém são mais antigas que o limite de expiração. Isso torna a exclusão por TTL altamente eficiente — remover um documento de bucket exclui centenas de medições em uma única operação.

Você pode modificar o período de retenção de uma coleção de séries temporais existente a qualquer momento usando o comando collMod — sem exigir indisponibilidade. Aumentar o valor mantém os dados por mais tempo; diminuí-lo faz com que dados anteriormente não expirados se tornem elegíveis para exclusão na próxima execução do TTL. A alteração entra em vigor em aproximadamente 60 segundos.

As coleções comuns do MongoDB usam um índice TTL (um índice especial de campo único em um campo de data com um atributo expireAfterSeconds) para expirar documentos individuais. As coleções de séries temporais usam um mecanismo diferente — elas expiram documentos de bucket inteiros, em vez de documentos de medição individuais. Isso significa que não é possível criar um índice TTL separado em uma coleção de séries temporais; a expiração é gerenciada exclusivamente pela opção expireAfterSeconds no nível da coleção.

Inspecione a política de retenção atual executando db.getCollectionInfos() e examinando o campo options.expireAfterSeconds. Você também pode verificar db.sensorReadings.stats(), que informa a configuração de TTL em sua saída. Isso é útil durante auditorias para confirmar que as coleções de produção estão configuradas com o período de retenção correto.

Um padrão comum em produção é a retenção em camadas: dados brutos de alta frequência são armazenados em uma coleção de séries temporais com TTL curto (por exemplo, 7 dias), enquanto um trabalho de pipeline de agregação é executado todas as noites para calcular resumos por hora e gravá-los em uma segunda coleção com TTL mais longo (por exemplo, 2 anos). Isso equilibra os custos de armazenamento com a necessidade de analisar tendências históricas.

A thread de segundo plano do TTL é ativada a cada 60 segundos, portanto a expiração não é instantânea — os dados podem permanecer por até 60 segundos além do limite. Em clusters do Atlas sob carga intensa, as exclusões por TTL podem sofrer atrasos adicionais. Para requisitos de conformidade que exijam a exclusão exata em um segundo específico, scripts de exclusão manual ou Atlas Triggers agendados oferecem um controle mais determinístico do que o TTL.

Se precisar remover imediatamente um bloco de medições — por exemplo, para eliminar os dados de um sensor com defeito — use deleteMany() com um filtro nos campos timeField e metaField. As coleções de séries temporais permitem exclusões por intervalo de tempo e valor de metaField desde o MongoDB 5.1. Filtros complexos em campos de medição nas exclusões têm suporte a partir do MongoDB 6.0.

O MongoDB expõe métricas de exclusão por TTL no status do servidor, na seção metrics.ttl. O contador deletedDocuments registra quantos documentos (documentos de bucket, no caso de séries temporais) a thread de TTL excluiu desde que o processo mongod foi iniciado. Monitorar esse contador ajuda a confirmar que o TTL está realmente sendo executado e excluindo os dados conforme esperado em produção.

Ao planejar a retenção, considere três fatores: requisitos de conformidade (algumas regulamentações exigem a retenção de dados por anos), necessidades analíticas (até que ponto no passado suas consultas analisam os dados?) e orçamento de armazenamento (quanto custa manter N dias de dados?). Modele o crescimento do armazenamento estimando o volume diário de documentos × o tamanho médio dos documentos e, em seguida, defina expireAfterSeconds para equilibrar as três restrições.

Nesta lição, você aprendeu que: expireAfterSeconds é definido no nível da coleção (não por meio de um índice) e controla quando buckets inteiros são eliminados, collMod permite atualizar o período de retenção de uma coleção ativa sem indisponibilidade, e a retenção em camadas — TTL curto para dados brutos e TTL longo para resumos pré-agregados — é a prática recomendada em produção para armazenar séries temporais com boa relação custo-benefício. A seguir, abordaremos os mecanismos de autenticação no MongoDB.