Valkey 9.1: when the field TTL increases memory usage

O que é Valkey 9.1 e o TTL por campo

Valkey é um armazenamento de dados em memória, de código aberto e orientado a chave e valor. Ele atende casos como cache, sessões, filas leves e contadores, com comandos simples e baixa latência.

O projeto é mantido pela comunidade no ecossistema da Linux Foundation. A versão 9.1 chama atenção porque inclui recursos recentes de expiração em campos de hashes, uma necessidade comum em sessões, estados temporários e dados parcialmente válidos.

Antes desse recurso, o comando EXPIRE era aplicado à chave inteira. Com HEXPIRE, um campo específico pode desaparecer no prazo definido sem remover os demais campos do hash. O ganho é de precisão, mas cada expiração também exige metadados para ser acompanhada.

Como funciona

Um hash agrupa vários campos sob uma única chave. Em uma sessão, por exemplo, usuário, status e ultimo_acesso podem viver em sessão:42. O comando EXPIRE controla a vida de toda essa chave.

HEXPIRE muda o nível da regra: ele recebe a chave, o tempo em segundos e os campos que devem expirar. O servidor passa a controlar o prazo de cada campo indicado, enquanto os outros continuam disponíveis.

HTTL permite consultar o tempo restante de campos específicos. A diferença parece pequena no código, mas altera o modelo de armazenamento: além dos valores do hash, o Valkey precisa manter informações de expiração associadas aos campos.

HSET sessão:42 usuário 123 status pendente ultimo_acesso agora
HEXPIRE sessão:42 900 FIELDS 1 status
HTTL sessão:42 FIELDS 3 usuário status ultimo_acesso

Principais recursos

A expiração por campo resolve situações em que os dados de uma mesma entidade não vencem juntos. Um token pode durar quinze minutos, enquanto o identificador da sessão permanece disponível para uma rotina de limpeza.

Os comandos relacionados permitem consultar, remover e ajustar prazos com mais controle. Opções como NX, XX, GT e LT ajudam a impedir que uma atualização substitua uma política de expiração por engano.

O recurso também combina com o modelo conhecido de hashes e não exige que a aplicação crie uma chave independente para cada atributo temporário. Ainda assim, essa conveniência precisa ser comparada ao custo de memória e à complexidade operacional.

• HEXPIRE: define prazo em segundos para campos existentes de um hash.
• HPEXPIRE: aplica a mesma ideia usando milissegundos.
• HTTL e HPTTL: consultam o tempo restante em segundos ou milissegundos.
• HDEL: remove campos quando a aplicação não precisa esperar o vencimento.

Como começar: instalação e acesso

Para experimentar o recurso, use uma versão do Valkey que ofereça HEXPIRE. A documentação oficial registra o comando a partir da versão 9.0. Por isso, a imagem 9.1 é adequada para o laboratório deste artigo.

O caminho mais curto é iniciar o servidor em um contêiner e abrir o cliente de linha de comando. Em produção, troque o armazenamento efémero por volume persistente e defina autenticação, rede restrita e política de backup conforme o uso.

Depois de conectar, faça um teste pequeno com poucos campos. Observe o resultado de HTTL antes de colocar o padrão em uma carga real, porque a medição de memória depende da quantidade de campos, do tamanho dos valores e da distribuição dos prazos.

Docker run --name valkey -p 6379:6379 -d valkey/valkey:9.1
valkey-cli
PING
HSET teste:1 campo valor
HEXPIRE teste:1 60 FIELDS 1 campo
HTTL teste:1 FIELDS 1 campo

Exemplo prático

Imagine uma sessão que reúne o usuário autenticado, um código temporário e o estado de uma etapa. O código deve sumir em quinze minutos, mas o restante da sessão pode seguir disponível para auditoria ou renovação.

Com uma chave única, a aplicação grava os três campos e aplica o prazo somente ao código. A consulta seguinte mostra o tempo restante do campo temporário e um valor diferente para os campos sem expiração.

Quando o prazo termina, o campo expira automaticamente. A aplicação ainda deve tratar a ausência do campo como um estado normal, porque uma leitura depois do vencimento não deve ser confundida com falha de conexão ou perda de toda a sessão.

HSET sessão:42 usuário 123 código 847291 status aguardando
HEXPIRE sessão:42 900 FIELDS 1 código
HTTL sessão:42 FIELDS 3 usuário código status
HGET sessão:42 código
HGET sessão:42 usuário

Comparação com alternativas

EXPIRE na chave inteira é a opção mais simples quando todos os campos compartilham o mesmo ciclo de vida. Ela reduz a quantidade de decisões na aplicação e mantém o modelo de expiração fácil de explicar.

Chaves separadas com TTL próprio oferecem isolamento claro. Em troca, aumentam o número de chaves, podem exigir mais operações de leitura e mudam a forma de agrupar ou invalidar uma entidade.

HEXPIRE fica no meio desses modelos: preserva o agrupamento do hash, mas adiciona controle por campo. O ponto forte aparece quando os dados precisam ser lidos juntos e vencem em momentos diferentes, desde que o custo extra seja medido.

• Use EXPIRE: quando todos os campos vencem juntos.
• Use HEXPIRE: quando o hash é útil e apenas alguns campos têm prazo próprio.
• Use chaves separadas: quando isolamento, escala independente ou remoção simples pesam mais que o agrupamento.

Pontos positivos e limitações

O principal benefício é representar a regra de validade perto do dado. Isso reduz temporizadores mantidos pela aplicação e evita que um processo separado tenha de varrer o hash apenas para remover campos vencidos.

A limitação central é o custo de bookkeeping. Um alerta recente sobre Valkey 9.1 mostrou que um padrão específico de TTL em campos pode chegar a aproximadamente três vezes o consumo de memória de um hash equivalente sem esse controle. Esse número não é uma regra universal.

O resultado varia conforme o número de campos, o tamanho dos valores, a quantidade de prazos e o padrão de acesso. Também é preciso confirmar a versão do servidor, porque clientes ou ambientes antigos podem não reconhecer os comandos novos.

• Positivo: expiração granular sem espalhar todos os atributos em chaves diferentes.
• Positivo: consulta explícita do prazo restante por campo.
• Limitação: mais metadados e maior consumo potencial de memória.
• Limitação: migração e compatibilidade precisam ser testadas por versão.

Casos de uso reais

Em uma API de autenticação, um hash pode guardar o identificador da sessão e um desafio de uso único. O desafio expira rapidamente, enquanto a sessão mantém informações necessárias para encerrar o acesso corretamente.

Em um sistema de rate limit, contadores de janelas diferentes podem compartilhar uma chave lógica. Cada campo pode ter um prazo próprio, mas a equipe deve comparar o custo com uma estrutura de chaves separadas.

Em um pipeline de processamento, o estado permanente de uma tarefa pode viver junto com um sinal temporário de bloqueio. Quando o bloqueio vence, o estado principal continua disponível para a próxima etapa.

• Desenvolvedor de APIs: separa tokens temporários de dados duráveis da sessão.
• Equipe de plataforma: testa políticas de cache sem criar chaves demais.
• Time de dados: mantém atributos de uma entidade agrupados enquanto mede o custo do TTL.
• Estudante de bancos: aprende na prática a diferença entre validade da chave e validade do campo.

Dicas e boas práticas

A primeira boa prática é medir antes de adotar. Faça um teste com dados semelhantes aos da produção e compare o uso de memória com EXPIRE, HEXPIRE e chaves separadas.

A segunda é tratar a expiração como parte do contrato da aplicação. Leituras devem aceitar que um campo esteja ausente, e métricas devem distinguir ausência esperada de erro no servidor.

A terceira é fixar a versão do servidor e validar os comandos no ambiente de homologação. Uma atualização de cliente não adiciona o comando ao servidor, e um servidor antigo pode falhar antes mesmo de executar a lógica de negócio.

Vale a pena?

HEXPIRE vale a pena quando os campos de um hash precisam permanecer agrupados, mas têm prazos realmente diferentes. Ele deixa a regra de expiração explícita e pode simplificar rotinas de limpeza.

Não é a escolha automática para qualquer cache. Se todos os dados vencem juntos, EXPIRE tende a ser mais simples. Se cada parte precisa de escala ou ciclo de vida independente, chaves separadas podem facilitar a operação.

O próximo passo é montar um benchmark pequeno com a carga real da aplicação. Compare latência, memória, número de chaves e comportamento depois do vencimento antes de promover o desenho para produção.