Microsoft Research'ün yeni uzak önbellek depolama teknolojisi 'Garnet'
(github.com/microsoft)- Garnet, Microsoft Research tarafından geliştirilen bir uzak önbellek deposudur; RESP wire protokolünü temel aldığı için mevcut Redis istemcileri değişiklik yapılmadan kullanılabilir
- Çok sayıda istemci bağlantısı ve küçük batch'lerde, benzer açık kaynak önbellek depolarına kıyasla daha yüksek verim ve ölçeklenebilirlik sunar; Azure VM'de Accelerated Networking etkin olduğunda 99.9 persentil gecikme süresi çoğu zaman 300 mikrosaniyenin altındadır
- Modern .NET tabanlıdır, Linux ve Windows'ta çalışır; C# ile kullanıcı tanımlı işlemler, saklı yordamlar ve modüller oluşturulabilir, ayrıca Lua script desteği vardır
- Depolama katmanı Tsavorite; bellek, SSD ve bulut depolama katmanlaması, engellemeyen checkpoint, kurtarma, dayanıklılık için işlem günlüğü, çok anahtarlı transaction'lar ve cluster modunda sharding, replikasyon ve dinamik anahtar migrasyonunu destekler
- Yeni özellikler olarak Vector Sets Preview ve Range Index Preview eklendi; Garnet makalesinin VLDB 2026'da yayımlanması planlanıyor
Garnet'in sunduğu uzak önbellek deposu
- Garnet, Microsoft Research'ün yeni uzak önbellek deposudur
- RESP wire protokolünü başlangıç noktası olarak benimseyerek, farklı programlama dillerindeki mevcut Redis istemcilerinin değişiklik yapılmadan kullanılmasını sağlar
- Örneğin C# tarafında StackExchange.Redis kullanılabilir
- Çok sayıda istemci bağlantısı ve küçük batch'lerde, benzer açık kaynak önbellek depolarından daha iyi verim ve ölçeklenebilirlik sunarak büyük ölçekli uygulama ve hizmetlerde maliyet tasarrufuna katkı sağlayabilir
- Tipik Azure VM'lerde Accelerated Networking etkinleştirildiğinde, istemci tarafı 99.9 persentil gecikme süresi çoğu zaman 300 mikrosaniyenin altında görülür
- Modern .NET teknolojileri üzerine kuruludur ve çapraz platform, genişletilebilir ve modern bir mimariyi hedefler
- Yaygın senaryolardaki performanstan ödün vermeden geliştirmeyi ve evrimi kolaylaştıracak şekilde tasarlanmıştır
- .NET kütüphane ekosisteminden yararlanarak API kapsamını genişletir ve optimizasyon alanı bırakır
- Hem Linux hem de Windows üzerinde güncel düzeyde performans elde eder
- Tam yönetilen bir hizmet gerekiyorsa Azure Cosmos DB Garnet Cache, Garnet'i yüksek erişilebilirlik, performans garantisi ve altyapı yönetimi gerektirmeyen kurumsal bir önbellekleme çözümü olarak sunar
Son eklenen özellikler ve makale
- Vector Sets Preview, yaklaşık en yakın komşu aramasını sunar
- DiskANN algoritması ve Garnet'in Tsavorite depolama motorunu temel alır
- İlk sonuçlarda Garnet; QPS, p99 gecikme süresi ve recall bakımından önde sonuçlar göstermektedir
- Range Index Preview, Garnet anahtarları üzerinde ikincil aralık ve eşitlik indeksleri sunar
- Bf-Tree temel alınmıştır
- Garnet makalesinin VLDB 2026'da yayımlanması planlanıyor
- Makalenin adı Garnet: A Next-Generation Cache-Store for Accelerating Applications and Services
- PDF mevcut
API ve genişletme modeli
- Garnet çeşitli API'ler uygular
- Ham string'ler: get, set, anahtar sona erme
- Analitik işlemler: HyperLogLog, Bitmap
- Nesne işlemleri: sorted set, list vb.
- Çok anahtarlı transaction desteği sunar
- İstemci tarafı RESP transaction'ları
- C# tabanlı sunucu tarafı saklı yordamlar ve modüller
- Kullanıcılar hem ham string'ler hem de kullanıcı tanımlı nesne tipleri için kullanıcı tanımlı işlemler oluşturabilir
- C#'ın sunduğu kolaylık ve güvenlikle, özel genişletmeler geliştirme eşiğini düşürür
- Lua script de desteklenir
Ağ, güvenlik ve depolama katmanı
- Garnet hızlı ve tak-çıkar özellikli bir ağ katmanı kullanır
- Bu yapı, gelecekte kernel bypass stack kullanımı gibi genişletmeleri mümkün kılar
- Güvenli iletişim için .NET'in SslStream kütüphanesi üzerinden TLS desteği sunar
- Temel erişim denetimi sağlar
- Depolama katmanı Tsavorite, yüksek performans için tasarlanmıştır ve çeşitli veritabanı özellikleri içerir
- İş parçacığı ölçeklenebilirliği
- Bellek, SSD ve bulut depolamayı kapsayan katmanlı depolama
- Hızlı, engellemeyen checkpoint
- Kurtarma
- Dayanıklılık için işlem günlüğü
- Çok anahtarlı transaction'lar
- Daha iyi bellek yönetimi ve yeniden kullanım
Tasarım yapısı
- Garnet'in tasarımı; ağ paketlerinin alınmasından veritabanı işlemlerinin ayrıştırılması ve işlenmesine, oradan depolama etkileşimine kadar önbellek deposu yığınının tamamını yeniden tasarlar
- Ağ katmanı paylaşımlı bellek tasarımı temel alınarak oluşturulmuştur
- TLS işleme ve depolama etkileşimi, ağ IO tamamlanma iş parçacığında yürütülür
- Yaygın durumda iş parçacığı değiştirme maliyetinden kaçınılır
- Geleneksel shuffle tabanlı ağ tasarımlarında olduğu gibi veriyi sunucunun uygun shard'ına taşımak yerine, CPU cache tutarlılığı veriyi işleme mantığının bulunduğu tarafa getirir
- Depolama tasarımı, birleşik bir işlem günlüğüyle bağlanan iki Tsavorite key-value deposundan oluşur
- main store, ham string işlemleri için optimize edilmiştir ve garbage collection'dan kaçınmak için belleği dikkatle yönetir
- İsteğe bağlı object store, karmaşık nesneler ve kullanıcı tanımlı veri tipleri için optimize edilmiştir
- object store; Sorted Set, Set, Hash, List, Geo gibi tipleri içerir
- object store'daki veri tipleri mevcut uygulamada .NET kütüphane ekosisteminden yararlanır
- Nesneler, bellek heap'inde güncellemelerin verimli olduğu bir biçimde; diskte ise serialize edilmiş biçimde saklanır
- Gelecekte bakım kolaylığını artırmak için birleşik indeks ve günlük kullanımını değerlendirmeyi planlıyor
- Garnet'in ayırt edici yönlerinden biri, dar bel yapısındaki Tsavorite depolama API'sidir
- Bu API'nin üzerinde büyük, zengin ve genişletilebilir bir RESP API yüzeyi uygulanır
- Okuma, upsert, silme ve atomik read-modify-write işlemlerinden oluşur
- Asenkron callback'ler sayesinde, her işlem sırasında çeşitli noktalarda Garnet mantığının devreye girmesi sağlanabilir
- Ayrıştırma ve sorgu işleme konularını; eşzamanlılık, depolama katmanlaması ve checkpoint gibi depolama ayrıntılarından ayırır
- Çok anahtarlı transaction'lar için iki aşamalı kilitleme kullanılır
Cluster modu ve operasyonel kısıtlar
- Garnet, tek düğümlü çalışmanın yanı sıra cluster modunu da destekler
- Sharding ve replikasyon içeren dağıtımlar oluşturulup yönetilebilir
- Shard yeniden dengelemesi için verimli ve dinamik anahtar migrasyonu yöntemlerini destekler
- Kullanıcılar, standart Redis cluster komutlarıyla Garnet cluster'ı oluşturup yönetebilir
- Düğümler, cluster durumunu paylaşmak ve geliştirmek için gossip yürütür
- Garnet'in cluster modu tasarımı şu anda passive durumdadır
- Lider seçimi uygulamaz
- Kullanıcının sağladığı control plane tarafından yayımlanan cluster komutlarına yanıt verir
- İlgili ayrıntılar control plane dokümanında yer alır
Dokümantasyon ve lisans
- Daha fazla bilgi ve dokümantasyon için Garnet dokümantasyon sitesi ziyaret edilebilir
- Başlamak için getting started dokümanına bakılabilir
- Sürüm bilgileri releases bölümünde yer alır
- Proje MIT License ile sunulmaktadır
1 yorum
Hacker News yorumları
Benchmark performans grafiğine (https://microsoft.github.io/garnet/docs/benchmarking/results...) bakınca GET throughput değerinin Dragonfly’dan 10 kattan fazla yüksek olduğu görülüyor.
%50 gecikme süresi Dragonfly’dan biraz daha yüksek, ancak 99. yüzdelik dilim biraz daha düşük.
Hem Garnet hem de Dragonfly, throughput ve gecikme süresi açısından Redis’ten çok daha iyi; Redis’in ciddi performans optimizasyonuna ihtiyacı var gibi görünüyor.
Optimizasyonun gerçekten gerekli olup olmadığını bilmiyorum; burada zaten 3 alternatif var.
Yine de Garnet, hem düşük hem yüksek eşzamanlılıkta Redis’i geçen ilk alternatif olduğu için etkileyici ve bir an önce denemek istiyorum.
Dragonfly C++, Redis ise C ile yazılmış.
Garnet’in depolama katmanı Tsavorite, açık kaynak FASTER’dan çatallandı ve iş parçacığı ölçeklenebilirliği, katmanlı depolama (bellek, SSD, bulut depolama), hızlı ve bloklamayan checkpoint’ler, kurtarma, dayanıklılık için işlem günlüğü, çok anahtarlı transaction’lar, daha iyi bellek yönetimi ve yeniden kullanım gibi güçlü veritabanı özellikleri içeriyor.
https://www.microsoft.com/en-us/research/blog/introducing-ga...
O dönemde üzerinde çalıştığım yüksek performans gereksinimli kavram kanıtı projesinde kalıcılık kütüphanesi olarak oldukça umut verici görünüyordu.
Bu arada iki projeyi de aynı kişi yönetiyor gibi görünüyor [1].
[1]: https://github.com/badrishc
Microsoft ve .NET ekibinin doğrudan altyapıyı hack’ler gibi geliştirdiği projeler oldukça etkileyici.
Yarp, reverse proxy/API gateway/başka ne gerekiyorsa onu yapan bir araç; şimdi Garnet de bellek cache’i için geliyor.
İçeride büyük bir ihtiyaç var gibi, bunu paylaşma isteği de var gibi görünüyor.
Azure App Service’te bunun yerleşik olması güzel olurdu.
Sırf cache için illa uzak bir servis kullanmak zorunda kalmayalım diye.
Eskiden IIS’te ASP.NET uygulamaları için process dışı session state deposu kullanmak yaygındı.
Amaç, web uygulaması süreci yeniden başlasa bile kullanıcının oturumunu kaybedip en baştan giriş yapmak zorunda kalmamasıydı.
Elbette SQL Server gibi merkezi bir depoya da koyabilirsiniz, ama o zaman her web sayfası isteği işlenmeden önce session state’in yüklenmesini bekler.
Session state genellikle bir şekilde kilitlendiği için performans sorunları da çok olur.
Günümüzdeki yaygın çözüm, cache ve session state için Redis kullanmak; genel olarak idare eder şekilde çalışıyor.
Throughput yüksek, fakat Redis Azure’da ayrı bir kaynak ve saçma derecede pahalı.
Bu kadar basit bir şey için Oracle DB fiyatı ödemek istemiyorum; bağlantı yapılandırması da epey zahmetli.
Bu yazıda 300 mikrosaniye yanıt süresinden bahsediliyor, ama bölge yedekliliği tasarımında bunun pek anlamı yok; çünkü tüm Azure load balancer’ları rastgele bölge seçimi kullanıyor.
Rastgele bir bölgedeki web sunucusu seçiliyor, sonra yine rastgele bir bölgedeki cache sunucusuna bağlanıyor.
O sunucuda anahtar yoksa cache verisini almak için başka bir rastgele bölgeye daha gitmesi gerekebilir.
Trafik veri merkezleri arasında ping pong yapıyor; bu da 1–3 ms gecikme yaratıyor ve Garnet’in reklamı yapılan değerlerinden 10 kata kadar yavaş oluyor.
İdeal senaryo, Microsoft Service Fabric’in reliable collections[1] gibi bir şey.
Her host node üzerinde yerel olarak çalışır ve diğer iki node’a replike eder.
Web uygulaması cache değerini her zaman aynı fiziksel host’tan okuyabilir.
Bazı durumlarda gecikme süresi tek haneli mikrosaniyelere kadar düşer; ne kadar iyi optimize edilmiş olursa olsun, basit load balancing kullanan harici bir servis bundan binlerce kat yavaştır.
Redis’ten %30 daha hızlı olanı değil, 3.000 kat hızlı olanı istiyorum.
[1] https://learn.microsoft.com/en-us/azure/service-fabric/servi...
Servisleri her zaman yerel servise gidecek şekilde ya da başka routing topolojileriyle yapılandırabilirsiniz.
DNS veya uygulama cache’i için çok iyi.
Gecikme süresi ve throughput benchmark değerleri oldukça etkileyici olan bir Redis alternatifi.
Azure dışı bir stack’te gerçek production’da nasıl görüneceğini merak ediyorum.
xstream desteğine dair bir işaret göremiyorum.
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).Bu kısmı pek anlayamadım.
Neden komutu içeride bir transaction’a sarıp atomik hale getirmiyorlar?
Başka hangi atomiklik tuzakları olduğunu da merak ediyorum.
MSETatomikliğine ihtiyaç duymayan herkes için de performans maliyeti doğar ve o transaction’ı kapatmanın yolu kalmaz.Öte yandan Redis’in drop-in alternatifi olmayı hedefliyorsa, Redis atomiklik garantisi verdiği için bu sorun olur.
En azından drop-in replacement tasarım hedefiyse, uyumluluk ile performans arasında seçim yaptıran bir ayar seçeneği olabilir.
Kesinlikle etkileyici.
Microsoft Research zaman zaman harika projeler çıkarıyor; araştırma-geliştirme yaparken bunun için para almak eğlenceli olmalı.
Büyük şirketlerin tüm sektöre faydası olan daha fazla Ar-Ge tarzı proje yapmasını isterdim.
Hashicorp satılıksa, iyi bir şirketin satın almasını umarım.
Microsoft Windows Server’da WSL2’ye bağımlı kalmadan doğrudan Redis uyumlu sunucu çalıştırması gerekenler için çok iyi haber.
Eskiden bir Redis port’u[1] vardı ama artık arşivlenmiş durumda; bellek kullanımı sorunları vardı (bildiğim kadarıyla ağırlıklı olarak memory-mapped file’lardan dolayı) ve artık desteklenmiyor.
C# ile yazılmış olması da kişisel olarak epey ilgimi çekiyor.
Ana dilim C# olduğu için zaman ayırıp kodu kurcalamak istiyorum.
[1]: https://github.com/microsoftarchive/redis
Bunun gerçek production ortamında nerelerde kullanıldığını görmek isterdim.
“Binlerce unit test ve Microsoft’un 1st-party ekipleriyle Garnet’i yıllarca production’da dağıtıp çalıştırdıktan sonra, artık yayımlama zamanının geldiğini hissettik” denilen bir bölüm var.
https://microsoft.github.io/garnet/blog
Buradaki yorumlara bakınca artık kimse memcached kullanmıyor gibi görünüyor.
LRU cache istiyordum ama birden çok seçenek vardı ve açıklamaları iyi değildi; neden sürekli öğeleri evict ettiğini anlayamamıştım.
Redis’e geçince yapılandırması kolaydı ve beklediğim gibi çalıştı.