Redis 8.12: como bitmaps esparsos reduzem memória em dados grandes

O que é Redis 8.12 e roaring bitmap

O Redis é um armazenamento de dados em memória usado como cache, banco de dados e camada de mensageria. A versão 8.12-rc1 apareceu entre os assuntos técnicos do dia por trazer uma implementação de roaring bitmap para representar conjuntos de valores com muitos espaços vazios.

Um bitmap tradicional trata cada posição como um bit. Isso funciona bem quando os identificadores estão próximos e a faixa de valores é conhecida. O problema aparece quando existem poucos valores ativos espalhados por um universo enorme.

O roaring bitmap divide o universo em blocos e escolhe uma representação adequada para cada bloco. Blocos esparsos podem guardar listas compactas, enquanto blocos densos usam uma forma mais eficiente para consultas. O ganho depende do padrão real dos dados.

Como funciona

Imagine uma aplicação que registra quais usuários abriram uma campanha. Se os IDs vão de 1 a 10 milhões, mas somente alguns milhares aparecem, um bitmap simples precisa considerar toda a faixa.

As operações comuns continuam sendo operações de conjunto: adicionar, remover, testar pertencimento e calcular unia£o ou interseção. A implementação escolhe internamente a forma de armazenamento conforme a quantidade de valores em cada bloco.

O desenho favorece consultas como usuários presentes em duas campanhas ou itens que aparecem em um grupo, mas não em outro. O resultado precisa ser medido com dados representativos.

Principais recursos

O primeiro recurso importante é a representação adaptativa. Em vez de usar o mesmo formato para todos os blocos, a estrutura pode manter valores compactados quando há poucos elementos e uma forma densa quando o bloco fica cheio.

O segundo é o foco em operações de conjunto. Interseção, unia£o e diferença são úteis em segmentação, análise de eventos, controle de acesso e filtros de recomendação.

O terceiro é manter o estado próximo da aplicação que já usa Redis. Isso pode simplificar a arquitetura, mas não elimina a necessidade de observar memória, latência, persistência e compatibilidade.

• Conjuntos esparsos com muitos IDs e poucos valores ativos.
• Consultas de pertencimento.
• Operações de grupo sem transportar todos os IDs para a aplicação.

Como começar: instalação ou acesso passo a passo

Comece lendo a documentação oficial da versão e confirme se o recurso está disponível na distribuição que você pretende usar. Como a referência do tema é uma versão candidata, não trate uma release candidate como escolha automática para produção.

Monte um ambiente de teste com dados sinta©ticos e dados anonimizados do seu caso real. Registre memória, tempo de inserção, tempo das consultas e comportamento durante reinicializações.

Compare a nova estrutura com a solução atual. Uma migração segura precisa de caminho de volta, validação dos resultados e monitoramento.

Docker run --name redis-lab -p 6379:6379 redis:latest
redis-cli PING

Exemplo prático

Considere uma plataforma que precisa saber quais usuários participaram de cada experimento. A aplicação recebe IDs numa©ricos e consulta interseções para descobrir quem participou de duas variações.

O exemplo abaixo é um roteiro conceitual de benchmark. Os comandos exatos disponíveis para roaring bitmap dependem da versão e da integração utilizada, então confirme a sintaxe na documentação oficial.

O resultado útil não é apenas o menor número de bytes. Compare também pertencimento, interseção e o custo de reconstruir os dados após uma restauração.

redis-cli INFO memory
redis-cli MEMORY USAGE experimento:controle
redis-cli MEMORY USAGE experimento:teste

Comparação com alternativas

O bitmap tradicional é simples e eficiente quando os valores ficam concentrados em uma faixa conhecida. Ele costuma ser uma boa escolha para flags, dias de atividade e índices densos.

Um conjunto comum do Redis é mais flexível para valores não numa©ricos e para operações conhecidas pelos clientes. Em contrapartida, pode consumir mais memória com milhões de elementos.

Estruturas RoaringBitmap na aplicação ou índices especializados em um banco analítico podem oferecer mais controle, mas aumentam a complexidade operacional.

• Bitmap tradicional: faixa numa©rica densa e operações simples.
• Set: flexibilidade e integração conhecida no Redis.
• Roaring bitmap: valores numa©ricos esparsos e operações de conjunto.
• Banco analítico: históricos e agregações complexas.

Pontos positivos e limitações

A principal vantagem é evitar o custo de representar milhões de posições vazias. Isso pode aumentar a densidade de dados úteis na memória.

Outra vantagem é o modelo mental de operações de conjunto, que combina com segmentação e filtros. Quando o padrão é previsível, a equipe consegue criar métricas para acompanhar o benefício.

A limitação é que uma versão candidata pode mudar antes da versão final. Também é necessário confirmar suporte no cliente, na persistência e nas ferramentas de backup.

Casos de uso reais

Em campanhas de marketing, um conjunto esparso pode representar usuários expostos a uma mensagem. A interseção entre campanhas ajuda a identificar sobreposição sem transferir todos os IDs para o código.

Em sistemas de autorização, a estrutura pode representar grupos numa©ricos ou recursos atribua­dos a uma conta. Compactação não substitui controle de acesso.

Em observabilidade, bitmaps podem marcar a presença de eventos por usuário, dispositivo ou intervalo. Limite a retenção e observe o crescimento das chaves.

Em recomendação, a comparação de conjuntos pode eliminar itens já vistos ou encontrar grupos semelhantes. Faça testes com a distribuição real.

Dicas e boas práticas

Defina limites de retenção e alertas de memória antes do rollout. Uma estrutura eficiente não impede o crescimento ilimitado de chaves.

Documente a origem dos IDs, a janela de validade e a regra usada para inserir ou remover valores.

Vale a pena?

Roaring bitmap faz sentido para equipes que lidam com conjuntos numa©ricos esparsos e precisam executar operações de conjunto com frequência.

Não é uma escolha automática para caches pequenos, dados não numa©ricos ou sistemas que precisam de consultas analíticas completas. Nesses casos, uma estrutura tradicional pode ser mais simples.

O próximo passo é testar cargas esparsas, médias e densas. Compare memória, latência, recuperação e operação antes de decidir pela produção.