Após três anos de desenvolvimento desde sua última mudança de versão principal, o banco de dados em memória Dragonfly alcançou a versão 2.0. A atualização marca um ponto de maturidade focado em prontidão para produção, trazendo suporte ao formato RDB do Valkey 9, novos comandos de geolocalização e uma reformulação profunda no gerenciamento de recursos para diminuir o consumo de memória sob estresse.
O que isso muda na prática
Para administradores de sistemas e engenheiros de confiabilidade que utilizam a ferramenta como alternativa ao Redis, a versão 2.0 entrega eficiência silenciosa. A equipe de desenvolvimento priorizou melhorias estruturais para que o banco de dados consuma menos RAM por conexão, lide melhor com a fragmentação de páginas e evite travamentos completos quando cargas de trabalho pesadas ou malformadas atingem o servidor. O resultado imediato é uma infraestrutura mais estável e previsível em cenários de alta concorrência.
Compatibilidade com Valkey e novos comandos
O alinhamento com o ecossistema de dados moderno é um dos pilares do lançamento. O Dragonfly 2.0 passa a carregar RDBs do Valkey 9, suportando nativamente hashes que contêm campos persistentes misturados com campos que possuem tempo de expiração. Essa adição simplifica processos de migração para equipes que já começaram a adotar o fork comunitário criado após as mudanças de licença do Redis.
A camada de comandos foi expandida com a chegada do GEOSEARCHSTORE. Administradores agora podem realizar consultas espaciais complexas, seja por raio ou por área delimitada, armazenando os resultados com suporte a ordenação, imposição de listas de controle de acesso (ACL) e journaling.
Eficiência de rede e desfragmentação
O custo computacional de manter o servidor operando caiu. A contabilidade de memória das conexões passou a operar em tempo constante, mudando sua complexidade de O(n) para O(1).
Para evitar desperdício de RAM, os buffers de entrada dos clientes agora encolhem automaticamente quando detectam baixo uso, e o limite máximo padrão desses buffers foi reduzido de 64 KiB para 32 KiB. Outro problema clássico de inchaço de memória foi resolvido no serializador do RDB: objetos massivos não prendem mais a memória de forma definitiva. Após o descarregamento, a capacidade retida é limitada a 4 MiB, evitando que um pico de uso de 512 MiB mantenha essa mesma quantidade bloqueada no sistema.
A versão também introduz o comando MEMORY DEFRAGMENT-SEGMENTS, que foca na recuperação de páginas de tabela com baixa densidade de dados, acompanhado por limites rigorosos que impedem o processo de desfragmentação em segundo plano de consumir mais do que aproximadamente 1% de um núcleo de processamento.
Endurecimento e segurança no RESTORE
Com mais de 50 correções de bugs, a confiabilidade de migração de dados e segurança de rede recebeu atenção especial. O comando RESTORE foi blindado contra payloads maliciosos ou corrompidos. Ele agora rejeita ativamente hashes com campos duplicados e cargas cujo comprimento declarado seja maior do que os dados reais da entrada, prevenindo ataques que buscam causar esgotamento de memória remoto (OOM) no servidor alvo.
Melhorias adicionais garantem que as respostas do protocolo RESP3 possuam a forma correta para listas e fluxos bloqueados, e evitam comportamentos indefinidos no armazenamento em camadas e durante a exclusão de fluxos ativos no XREADGROUP.
