Garnet, a nova tecnologia de cache remoto da Microsoft Research
(github.com/microsoft)- Garnet é um armazenamento de cache remoto criado pela Microsoft Research, baseado no protocolo wire RESP, permitindo usar clientes Redis existentes sem modificações
- Com muitas conexões de clientes e lotes pequenos, oferece maior throughput e escalabilidade do que armazenamentos de cache open source comparáveis; em VMs do Azure com Accelerated Networking habilitado, a latência no percentil 99,9 frequentemente fica abaixo de 300 microssegundos
- Baseado no .NET moderno, roda em Linux e Windows; permite criar operações personalizadas, stored procedures e módulos em C#, além de oferecer suporte a scripts Lua
- A camada de armazenamento Tsavorite oferece suporte a armazenamento em camadas com memória, SSD e armazenamento em nuvem; checkpoints não bloqueantes, recuperação, log de operações para durabilidade, transações multi-chave, sharding e replicação no modo cluster, além de migração dinâmica de chaves
- Entre os novos recursos estão Vector Sets Preview e Range Index Preview, e o artigo sobre o Garnet está previsto para publicação na VLDB 2026
O armazenamento de cache remoto oferecido pelo Garnet
- Garnet é o novo armazenamento de cache remoto da Microsoft Research
- Ele adota o protocolo wire RESP como ponto de partida, permitindo usar clientes Redis existentes em várias linguagens de programação sem modificações
- Por exemplo, é possível usar o StackExchange.Redis em C#
- Com muitas conexões de clientes e lotes pequenos, oferece throughput e escalabilidade melhores do que armazenamentos de cache open source comparáveis, o que pode levar a redução de custos em apps e serviços de grande escala
- Em VMs comuns do Azure com Accelerated Networking habilitado, a latência do cliente no percentil 99,9 frequentemente fica abaixo de 300 microssegundos
- É baseado em tecnologias .NET modernas e busca uma arquitetura multiplataforma, extensível e moderna
- Foi projetado para facilitar o desenvolvimento e a evolução sem sacrificar o desempenho nos casos comuns
- Aproveita o ecossistema de bibliotecas .NET para ampliar a superfície de APIs e manter espaço para otimizações
- Alcança desempenho de nível moderno tanto no Linux quanto no Windows
- Para quem precisa de um serviço totalmente gerenciado, o Azure Cosmos DB Garnet Cache oferece o Garnet como uma solução de cache empresarial com alta disponibilidade, garantias de desempenho e sem gerenciamento de infraestrutura
Recursos adicionados recentemente e artigo
- Vector Sets Preview oferece busca aproximada de vizinhos mais próximos
- É baseado no algoritmo DiskANN e no mecanismo de armazenamento Tsavorite do Garnet
- Nos resultados iniciais, o Garnet apresentou resultados superiores em QPS, latência p99 e recall
- Range Index Preview oferece índices secundários de intervalo e igualdade sobre chaves do Garnet
- É baseado no Bf-Tree
- O artigo sobre o Garnet está previsto para publicação na VLDB 2026
- O título do artigo é Garnet: A Next-Generation Cache-Store for Accelerating Applications and Services
- Um PDF está disponível
API e modelo de extensão
- O Garnet implementa várias APIs
- Strings brutas: get, set, expiração de chaves
- Operações analíticas: HyperLogLog, Bitmap
- Operações com objetos: sorted set, list etc.
- Oferece suporte a transações multi-chave
- Transações RESP no lado do cliente
- Stored procedures e módulos no lado do servidor baseados em C#
- Usuários podem criar operações personalizadas tanto para strings brutas quanto para tipos de objetos definidos pelo usuário
- Aproveita a conveniência e a segurança do C# para reduzir a barreira de entrada no desenvolvimento de extensões customizadas
- Também oferece suporte a scripts Lua
Rede, segurança e camada de armazenamento
- O Garnet usa uma camada de rede rápida e plugável
- Isso permite futuras extensões, como o uso de stacks com kernel bypass
- Para comunicação segura, oferece suporte a TLS usando a biblioteca SslStream do .NET
- Oferece controle de acesso básico
- A camada de armazenamento, Tsavorite, foi projetada para alto desempenho e inclui vários recursos de banco de dados
- Escalabilidade por threads
- Armazenamento em camadas, incluindo memória, SSD e armazenamento em nuvem
- Checkpoints rápidos e não bloqueantes
- Recuperação
- Log de operações para durabilidade
- Transações multi-chave
- Melhor gerenciamento e reutilização de memória
Arquitetura de design
- O design do Garnet redesenha toda a stack de armazenamento de cache, desde o recebimento de pacotes de rede até o parsing e processamento de operações de banco de dados e a interação com o armazenamento
- A camada de rede é baseada em um design de memória compartilhada
- O processamento de TLS e a interação com o armazenamento são executados nas threads de conclusão de I/O de rede
- Nos casos comuns, evita o overhead de troca de threads
- Em vez de mover dados para o shard apropriado do servidor, como em designs de rede tradicionais baseados em shuffle, deixa que a coerência de cache da CPU traga os dados para a lógica de processamento
- O design de armazenamento é composto por dois armazenamentos chave-valor Tsavorite vinculados por um log de operações unificado
- O main store é otimizado para operações com strings brutas e gerencia a memória cuidadosamente para evitar garbage collection
- O object store opcional é otimizado para objetos complexos e tipos de dados definidos pelo usuário
- O object store inclui tipos como Sorted Set, Set, Hash, List e Geo
- Os tipos de dados do object store aproveitam, na implementação atual, o ecossistema de bibliotecas .NET
- Objetos são armazenados em um formato eficiente para atualizações no heap de memória e em formato serializado no disco
- Para facilitar a manutenção futura, há planos de avaliar o uso de um índice e log unificados
- O diferencial do Garnet é a API de armazenamento Tsavorite em formato de cintura estreita
- Sobre essa API, ele implementa uma superfície de API RESP grande, rica e extensível
- Ela consiste em leituras, upserts, exclusões e operações atômicas de read-modify-write
- Callbacks assíncronos permitem que a lógica do Garnet intervenha em vários pontos durante cada operação
- Separa as preocupações de parsing e processamento de consultas dos detalhes de armazenamento, como concorrência, camadas de armazenamento e checkpoints
- Transações multi-chave usam bloqueio em duas fases
Modo cluster e restrições operacionais
- Além da execução em nó único, o Garnet oferece suporte ao modo cluster
- Permite criar e gerenciar deployments com sharding e replicação
- Oferece suporte a um método eficiente e dinâmico de migração de chaves para rebalanceamento de shards
- Usuários podem criar e gerenciar clusters Garnet usando comandos padrão de cluster do Redis
- Os nós executam gossip para compartilhar e evoluir o estado do cluster
- O design atual do modo cluster do Garnet é passivo
- Não implementa eleição de líder
- Responde a comandos de cluster emitidos por um control plane fornecido pelo usuário
- Mais detalhes estão na documentação do control plane
Documentação e licença
- Mais informações e documentação estão disponíveis no site de documentação do Garnet
- Para começar, consulte a documentação de getting started
- As notas de release estão na seção releases
- O projeto é disponibilizado sob a MIT License
1 comentários
Opiniões no Hacker News
Olhando o gráfico de desempenho do benchmark (https://microsoft.github.io/garnet/docs/benchmarking/results...), o throughput de GET é mais de 10 vezes maior que o do Dragonfly.
A latência de 50% é um pouco maior que a do Dragonfly, mas o percentil 99 é um pouco menor.
Tanto Garnet quanto Dragonfly têm throughput e latência muito melhores que o Redis, então parece que o Redis precisa de uma otimização de desempenho considerável.
Não sei se otimização é realmente necessária, e aqui já existem 3 alternativas.
Mas o Garnet é impressionante por ser a primeira alternativa que supera o Redis tanto em baixa quanto em alta concorrência, e estou ansioso para testá-lo.
Dragonfly é em C++, Redis é escrito em C.
Tsavorite, a camada de armazenamento do Garnet, derivou do FASTER, open source, e inclui recursos fortes de banco de dados como escalabilidade por threads, armazenamento em camadas (memória, SSD, armazenamento em nuvem), checkpoints rápidos e não bloqueantes, recuperação, logs de operações para durabilidade, transações multichave e melhor gerenciamento e reutilização de memória.
https://www.microsoft.com/en-us/research/blog/introducing-ga...
Na época, achei bastante promissora como biblioteca de persistência em um projeto de prova de conceito com requisitos de alto desempenho em que eu estava trabalhando.
A propósito, os dois projetos parecem ser liderados pela mesma pessoa [1].
[1]: https://github.com/badrishc
Os projetos que a Microsoft e a equipe do .NET fazem diretamente, quase como se estivessem hackeando a infraestrutura, são bem impressionantes.
Yarp é uma ferramenta para proxy reverso/API gateway/ou qualquer outra coisa necessária, e agora o Garnet é para cache em memória.
Parece haver uma demanda interna enorme e também disposição para compartilhar isso.
Seria bom ter algo assim integrado ao Azure App Service.
Para não ser obrigado a usar um serviço remoto só por causa de caching.
Antigamente, no IIS, era comum usar um armazenamento de estado de sessão fora do processo para apps ASP.NET.
A ideia era evitar que o usuário perdesse a sessão e tivesse que fazer login do zero quando o processo do web app reiniciasse.
Claro que também dava para colocar isso em um armazenamento central como o SQL Server, mas aí toda requisição de página web tinha que esperar o carregamento do estado de sessão antes de ser processada.
Como o estado de sessão normalmente fica bloqueado de alguma forma, isso também traz muitos problemas de desempenho.
A solução comum hoje é usar Redis para cache e estado de sessão, e em geral funciona razoavelmente bem.
O throughput é alto, mas o Redis é um recurso separado no Azure e é absurdamente caro.
Não quero pagar preço de Oracle DB por algo tão simples, e configurar as conexões também é bem trabalhoso.
O texto fala em tempo de resposta de 300 microssegundos, mas isso não significa muito em um desenho com redundância de zona, porque todos os balanceadores de carga do Azure usam seleção aleatória de zona.
Um servidor web em uma zona aleatória é escolhido, e então ele se conecta a um servidor de cache em outra zona aleatória.
Se aquele servidor não tiver a chave, talvez ainda precise ir a outra zona aleatória para buscar os dados em cache.
O tráfego fica pingue-pongueando entre datacenters, gerando 1–3 ms de latência e ficando até 10 vezes mais lento que os números anunciados do Garnet.
O cenário ideal seria algo como as reliable collections[1] do Microsoft Service Fabric.
Elas rodam localmente em cada nó host e replicam para outros dois nós.
O web app sempre consegue ler valores de cache no mesmo host físico.
Em alguns casos, a latência cai para microssegundos de um dígito, e qualquer serviço externo, por mais bem otimizado que seja, fica milhares de vezes mais lento com um balanceamento de carga simples.
Não quero algo 30% mais rápido que o Redis; quero algo 3.000 vezes mais rápido.
[1] https://learn.microsoft.com/en-us/azure/service-fabric/servi...
Você pode configurar o serviço para sempre ir para o serviço local, ou também para outras topologias de roteamento.
É ótimo para DNS ou cache de aplicação.
É uma alternativa ao Redis com números de benchmark de latência e throughput bem impressionantes.
Fico curioso para saber como seria em produção de verdade em uma stack que não seja Azure.
Não vi indicação de suporte a xstream.
Garnet being multi-threaded, MSET is not atomic. For an atomic version of MSET, you would need to express it as a transaction (stored procedure).Não entendi bem essa parte.
Por que não envolver internamente em uma transação e tornar o comando atômico?
Também fico curioso para saber que outras armadilhas de atomicidade existem.
MSET, e não haveria como desligar essa transação.Por outro lado, se o objetivo é ser uma substituição drop-in do Redis, isso é um problema, porque o Redis garante atomicidade.
Pelo menos se substituição drop-in for um objetivo de design, talvez pudesse haver uma opção de configuração para escolher entre compatibilidade e desempenho.
Definitivamente impressionante.
A Microsoft Research às vezes lança projetos incríveis, e deve ser divertido ser pago para fazer pesquisa e desenvolvimento.
Gostaria que grandes empresas fizessem mais projetos de P&D que ajudam a indústria inteira.
Se a Hashicorp está à venda, espero que uma boa empresa a compre.
Para quem precisa rodar diretamente um servidor compatível com Redis no Microsoft Windows Server sem depender do WSL2, esta é uma ótima notícia.
Antes havia um port do Redis[1], mas agora está arquivado, tinha problemas de uso de memória (até onde sei, principalmente por causa de arquivos mapeados em memória) e não é mais suportado.
O fato de ser escrito em C# também é bem interessante para mim pessoalmente.
Como C# é minha linguagem principal, quero arrumar tempo para fuçar o código.
[1]: https://github.com/microsoftarchive/redis
Quero ver onde isso está sendo usado em ambientes de produção reais.
Há uma parte que diz: “Depois de milhares de testes unitários e de implantar o Garnet em produção por vários anos com equipes 1st-party da Microsoft, sentimos que era hora de torná-lo público”.
https://microsoft.github.io/garnet/blog
Pelos comentários aqui, parece que agora ninguém mais usa memcached.
Eu queria um cache LRU, mas havia várias opções e a explicação não era boa, então não conseguia entender por que ele continuava expulsando itens.
Ao trocar para Redis, a configuração ficou fácil e funcionou como esperado.