Redis 8.10: quando Compact Hash realmente economiza memória

Bloco central de dados conectado a vários registros menores sobre fundo azul

O Redis 8.10 apresentou Compact Hash como uma nova codificação para conjuntos grandes de hashes que compartilham os mesmos campos. A promessa chama atenção: até 50% menos memória. O número é real nos testes da Redis, mas não descreve qualquer hash. O formato é ótimo para dados tabulares e repetitivos; fora desse desenho, pode não ser a escolha certa.

O que fica compacto

Imagine milhões de perfis com campos name, email, plan e created_at. Na representação tradicional, os nomes desses campos aparecem repetidamente. Compact Hash compartilha metadados estruturais entre hashes compatíveis e reduz essa duplicação.

A semântica dos comandos continua sendo a de hash. Aplicações seguem usando operações conhecidas, enquanto o Redis escolhe a codificação interna. Isso torna a otimização menos invasiva do que mudar o modelo inteiro para strings serializadas ou outro banco.

O encaixe ideal — e o anti-padrão

  • Bom candidato: muitos hashes, conjuntos de campos estáveis e semelhantes, valores pequenos ou médios.
  • Mau candidato: cada hash tem nomes de campos únicos, estrutura muda o tempo inteiro ou um único hash concentra um volume gigantesco de campos.

Campos opcionais não inviabilizam automaticamente o formato, mas quanto menos a coleção compartilha uma forma comum, menor tende a ser o benefício. Medir a distribuição real das chaves é mais útil que extrapolar o melhor resultado do benchmark.

HIMPORT prepara a carga

O novo comando HIMPORT permite preparar e carregar hashes compactos em volume. A Redis reporta até duas vezes mais throughput de carga, além de ganhos de até 104% em HSET para hashes largos recém-criados. Esses números dependem do formato e da carga; trate-os como teto observado, não como previsão do seu cluster.

# Antes de migrar, inventarie a forma dos hashes
redis-cli --scan --pattern 'user:*' | head

# Compare memória em amostras representativas
MEMORY USAGE user:1001
MEMORY USAGE user:1002

A conversão automática de hashes existentes vem desativada por padrão. Isso é saudável: mudar representação pode afetar uso de memória durante a transição e latência de comandos. Prepare um subconjunto, meça e só então amplie.

Conversão não é uma porta giratória

Uma vez que o hash entra na codificação compacta, ele permanece compacto. Essa característica exige cuidado com estruturas que começam uniformes e depois recebem campos dinâmicos. A aplicação pode continuar funcionando, mas a vantagem de memória e desempenho que justificou a migração pode diminuir.

Além dos hashes

O Redis 8.10 também trouxe backup incremental, extensões JSONPath e novos comandos como LMOVEM, BLMOVEM, SUNIONCARD e SDIFFCARD. Streams ganharam limites por contagem e tamanho, e os benchmarks oficiais apontam até 28% de ganho em XREADGROUP e 26% menos memória em streams profundos.

São melhorias relevantes, mas Compact Hash é a que pode mudar diretamente a conta de infraestrutura de aplicações com milhões de objetos semelhantes. Justamente por isso merece experimento controlado, não um toggle global.

Um plano de adoção seguro

  • Agrupe chaves por padrão e levante quantidade de campos, nomes e tamanhos.
  • Escolha uma família homogênea e compare memória, latência e tempo de carga.
  • Teste alterações futuras do schema, não apenas o retrato atual.
  • Monitore p95/p99 e memória durante a migração.
  • Mantenha backup e procedimento de restauração compatíveis com a nova versão.

Compact Hash não torna modelagem irrelevante; ele recompensa uma modelagem previsível. Se seus hashes se parecem com linhas de uma tabela, há uma boa hipótese para testar. Se cada chave é uma criatura diferente, a economia anunciada provavelmente mora em outro dataset.

Fontes