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.

