Valkey 1. yılında: Topluluk çatalı Redis’i nasıl geride bıraktı

 (gomomento.com)
8 puan yazan GN⁺ 2025-06-01 | 4 yorum | WhatsApp'ta paylaş
  • Redis Inc kaynak kapatma kararıyla (SSPL’ye geçiş) topluluğun güvenini sarsmış olsa da, geliştirici topluluğu Valkey çatalı etrafında birleşerek canlı bir yenilik ve katkı süreci oluşturdu
  • Redis 8.0 yeniden açık kaynağa döndü ve kurucusu Antirez yeni özellikler ve optimizasyonlara katkı sağlamak üzere geri geldi; böylece her iki tarafta da hızlı bir gelişim yaşanıyor
  • Son benchmark sonuçlarına göre Valkey 8.1.1, 8vCPU ortamında SET performansında Redis 8.0’a göre %37 daha yüksek sonuç verirken p99 gecikmesi de daha kısa ölçüldü (GET performansında da %16 üstün)
  • IO thread’leri / çekirdek pinning gibi pratik tuning yöntemleriyle Valkey, çok iş parçacıklı ortamlarda 3 katın üzerinde throughput artışı ve minimum gecikme elde etti
  • Gerçek kullanım ortamına daha yakın benchmark ve tuning bilgileri de paylaşılıyor; benchmark sonuçlarını yorumlarken dikkat edilmesi gereken noktalar ve bunların gerçek operasyon ortamında nasıl uygulanacağı da anlatılıyor

Redis’in kaynak kapatması ve Valkey’in ortaya çıkışı

  • 1 yıl önce Redis Inc (eski adıyla Garantia Data), açık kaynak lisans değişikliği (SSPL’nin benimsenmesi) nedeniyle toplulukla güven ilişkisini zedeledi
  • Buna çözüm olarak doğan açık çatal Valkey, dağıtık sistemler, önbellekleme ve gerçek zamanlı veri işleme gibi alanlarda yaygın kullanılan bir teknoloji varlığı hâline geldi
  • Redis tarafı da sonrasında Antirez’in (kurucu) geri dönüşü, performans / özellik iyileştirmeleri ve Redis 8.0’ın yeniden açık kaynağa dönmesiyle güveni yeniden kazanmaya çalıştı

Valkey 8.1 vs Redis 8.0: Performans karşılaştırması

  • Aynı 8vCPU AWS c8g.2xl instance’ı, 1KB öğe / 3M keyspace / 500 connection koşullarında SET benchmark’ı
    • Valkey 8.1.1: 999.8K RPS (p99 0.8ms)
    • Redis 8.0: 729.4K RPS (p99 0.99ms)
    • Valkey, SET’te %37, GET’te %16 daha yüksek; SET p99’da %30, GET p99’da %60 daha hızlı
  • 6 IO thread kullanıldığında Valkey, 239K → 678K RPS (2.8 kat↑), p99 1.68ms → 0.93ms (%44↓)
  • Redis de IO thread’leriyle 235K → 563K RPS, p99 1.35ms → 0.84ms (%40↓)

Çok iş parçacıklılık / çekirdek tuning etkisi

  • IO thread’leri 3 veya daha fazla olduğunda etki belirginleşiyor ve Valkey, 4 thread sonrasında Redis ile farkı daha da açıyor
  • IRQ (interrupt) çekirdekleri 2 ile sınırlandırıldıktan sonra Redis / Valkey’nin kalan 6 çekirdeğe sabitlenmesi (pinning) ek performans artışı sağlıyor
    • Valkey: 832K → 999.8K RPS (çekirdek / IRQ pinning, CPU’nun %80 kullanımı)
    • IRQ ile uygulama çekirdeklerini ayırmak, cache verimliliğini ve tail latency’yi iyileştiriyor
    • Docker’da cpuset-cpus, --io-threads gibi ayarların kullanımına dair örnekler veriliyor

Benchmark’ı yeniden üretme ve pratik ipuçları

  • En güncel AWS Graviton4 (c8g.2xlarge) instance’ları ve cluster placement group kullanımı
  • Çekirdek pinning / IRQ ayrımı / connection sayısı ayarı (400–500 aralığı) ile en yüksek performansın elde edilmesi
  • Keyspace / öğe boyutu için de tuning gerekli; küçük değerler / küçük keyspace, L3 cache isabet oranını artırıyor
  • valkey-benchmark veya rpc-perf (gerçek kullanıma daha yakın Rust tabanlı araç) gibi çok iş parçacıklı benchmark araçlarının aktif kullanımı öneriliyor 
    docker run --network="host" --rm --cpuset-cpus="2-7" \  
valkey/valkey:8.0.1 valkey-benchmark \  
-h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
-r 3000000 --threads 6 -d 1024

Performans ölçümünün sınırları ve dikkat edilmesi gerekenler

  • Benchmark sonuçları gerçek operasyon ortamından farklı olabilir

    • Gerçek workload; SET:GET karışımı, yük dalgalanması, TPS hedefi, ağ gecikmesi gibi birleşik etkenler içerir
    • Connection sayısı aniden arttığında kuyruk gecikmesi ve throughput düşüşü ile tail latency artışı da gözlemlenebilir
    • Kullanılan benchmark aracı / seçenekler ve ağ topolojisine göre sonuçlar büyük ölçüde değişebilir

Başlıca büyüme süreci ve topluluk gelişimi

Valkey projesi son 1 yılda birçok açıdan hızlı bir gelişim gösterdi

  • GitHub gibi platformlarda çok sayıda geliştirici ve şirketin iş birliğiyle özellik eklemeleri, hata düzeltmeleri ve güvenlik iyileştirmeleri yapıldı
  • Dokümantasyon ve kullanıcı desteğine de önem verilerek yeni kullanıcılar için giriş bariyeri düşürüldü
  • Proje yönetiminde şeffaf karar alma ve topluluk oylamaları öne çıkarıldı

Sektörel ve teknik değer

Valkey şu güçlü yönlere sahip

  • Lisans kısıtları olmadan herkes tarafından kullanılabildiği için bulut hizmet sağlayıcıları ve büyük ölçekli web hizmeti şirketleri için çekici bir seçenek
  • Redis ile yüksek uyumluluk sunduğundan migration da kolay
  • Topluluk odaklı geliştirildiği için farklı ihtiyaçlar daha iyi yansıtılabiliyor ve hızlı, sürekli güncellemeler mümkün oluyor

Sonuç ve çıkarımlar

  • Valkey, Redis çatalı olduktan yalnızca 1 yıl sonra teknoloji / performans / topluluk açısından Redis’i aşan sonuçlar gösterdi
  • IO thread’leri, çekirdek / IRQ ayrımı ve connection ayarı gibi pratik tuning yöntemleri ile araçlar kritik önemde
  • Performans kendiliğinden gelmez; sistem / workload / altyapıya uygun sürekli optimizasyon şarttır
  • Gerçek servis ortamında yalnızca benchmark sayılarına güvenmek yerine, farklı senaryoların doğrudan test edildiği pratik bir yaklaşım gerekir

İlgili okumalar

4 yorum

 
ethanhur 2025-06-02

Redis birçok yanlış karar vermiş olsa da, işi yapanın başkası, parayı alanınsa eğitmen olduğu bu tablo gerçekten üzücü.
 
kgcrom 2025-06-02

Facebook'taki "Redis User Group"ta paylaşılan,
Valkey 8'de hangi iyileştirmelerin yapıldığını özetleyen bir materyal.
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

Yukarıdaki içerikle birlikte bakarsanız anlamanıza yardımcı olabilir.
 
ndrgrd 2025-06-01

Aslında Valkey'nin yaptığı bir şeyden çok... karşı tarafın kendi kendine çökmesiyle ilgili...
 
GN⁺ 2025-06-01
Hacker News yorumu
  • ValKey'in I/O threading alanında harika ilerlemeler kaydetmesinden memnunum, son dönemde en ilgi çekici değişiklikleri de uygulamaya almaya başladılar; ValKey katkıcılarına büyük teşekkürler. Ama bu yazının biraz yanıltıcı olma eğiliminde olduğunu düşünüyorum. Aslında Redis'te shared nothing mimarisi çok önemli bir felsefeydi ve 2020'de I/O threading'i bizzat ben ekledim. Shared nothing yaklaşımını bozmadan, event loop'tan dönerken write(2)/read(2) syscall'larının oldukça yavaş olabildiğini dikkate alıp, tam o anda zero contention durumunda yalnızca I/O'yu N adet thread'e paralel işlettikten sonra hemen yeniden single-thread yapısına dönen bir tasarım getirdim. ValKey ekibinin bu sistemi daha da geliştirmiş olmasına minnettarım. Bu sistem zaten uzun süredir çalışıyordu ve gerçekte değişmemiş şeyleri medyanın abartma eğilimi beni rahatsız ediyor. Bu özellikler pratikte çoğu sıradan Redis kullanıcısından çok kurumsal kullanıcıların ya da bulut sağlayıcılarının (Amazon, Google vb.) ilgisini çekiyor. Aşırı yük veya aynı anda çok sayıda kullanıcıyı yönetmek zorunda kalınan durumlar yoksa, çoğu zaman Redis'in CPU kullanımı düşük olduğu için bunu etkinleştirmeye gerek olmuyor. Son dönemde Redis'te vector set data type geliştirirken threading'i varsayılan hale getiriyoruz ve VADD ile vector set yazımları da threaded şekilde yapılabiliyor. HNSW gibi veri yapıları, Redis tarihinde ilk kez çok büyük sabit zaman maliyetleri getirdiği için tasarım alanı da değişiyor. Geçmişte modüller için thread desteğini de zaten uygulamıştım. Thread kullanıp kullanmamak bağlama göre verilen bir karardır.
    • Nüanslı bakış açısı tık getirmiyor demek istiyor
    • Bu tür eleştiri yazılarının her ay HN ana sayfasına çıktığı hissine kapılıyorum; hep antirez'i desteklemek istemişimdir. Teknik özüne katılıyorum ama bu tür eleştirilerin çoğu zaman somut içerikten çok büyük başarı elde etmiş birine saldırmaya yönelik klasik tall poppy syndrome ile ilgili olduğunu düşünüyorum. Başkalarının tepkilerini kontrol edemeyeceğinize göre, bu tür eleştirileri başarılarınızın dolaylı bir kabulü olarak görmek daha sağlıklı olabilir; LinkedIn'de bağlantıda olmayı da takdir ediyorum Tall poppy syndrome'a bakın
  • antirez'in Redis'i yeniden açık kaynağa döndüreceğini açıkladığını hatırlıyorum ilgili yazı Eskiden Node.js, Io.js fork krizi yüzünden neredeyse çökecekti ama topluluk toparladı. Redis için de böyle bir toparlanma mümkün mü merak ediyorum. Eskiden Redis'i sık kullanırdım ama son birkaç yıldır topluluk tarafını çok takip etmiyorum
    • Son kontrol ettiğimde Redis hâlâ CLA (Contributor License Agreement) istiyordu. Bu da istedikleri anda kaynağı yeniden kapatma konusunda tekel niteliğinde hakları olduğu anlamına geliyor. Katkıcıların böyle bir maddeyi kabul etmesi gerekiyorsa, aynı şeyi tekrar yapmayacaklarına güvenmek için bir neden yok
    • Redis AGPL ile, Valkey ise BSD lisansı ile dağıtılıyor (BSD, Redis'in önceki lisansıydı). İkisi de resmî açık kaynak lisansları ama BSD çok daha serbest
    • Açıkçası kullanıcıların %99'u kimin sahip olduğuna aldırmıyor; ücretsiz key-value store düzgün çalışsın yeter. İş tarafında Redis'in ilginç bir konumu var: çok fazla özellik sunuyor ama gerçek kullanıcılar bunun yalnızca %5'ini kullanıyor, Sentinel/Streams gibi karmaşık özelliklerle de ilgilenmiyor. Ücretlendirme devreye girdiğinde kullanıcıların seçenekleri "hiç kullanmamak", "rakibe geçmek", "yalnızca gerçekten gereken özellikleri kendin geliştirmek", "son açık kaynak sürümü fork edip kendin bakımını yaparak maliyeti düşürmek" gibi şeyler oluyor. PostgreSQL'e kıyasla Redis'in basit versiyonunu (hash map + ağ arayüzü) kendin yazmak daha kolay; bu yüzden birçok işletme için fork etmek ya da kendin yapmak daha iyi bir tercih
    • Bence de artık çok geç. Redis'in ani politika değişimi yüzünden benim gözümde Redis artık güvenilmez; bundan sonra varsayılan tercihim Valkey. Bir kez kandıktan sonra ikinci kez güvenmem
    • Redis'in yaptıklarından sonra ona nasıl güvenilebilir sorusunu gündeme getiriyor
  • Valkey'in dağıtımların varsayılan paket yöneticilerine girmesi gerektiğini düşünüyorum. Mesela GitHub Action runner üzerinde kurmak istediğinizde her seferinde anahtar eklemek ve dağıtımı güncellemek can sıkıcı
    • Hangi dağıtımda olmadığını merak ediyorum. repology verilerine göre nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL vb. içinde zaten var. Yalnız Debian'da 13 veya 12+backports'tan itibaren mevcut
    • Bu arada Arch Linux'ta Valkey zaten Redis'in yerini aldı
    • CI'da container image'ı çeker çekmez ilk işiniz bir şeyler kurmaksa, doğrudan kendi image'ınızı oluşturmak daha iyi olabilir
  • Bu değişimin yaşanması ve Valkey'in istikrarlı biçimde iyi gitmesi beni çok sevindiriyor. Umarım Redis yakında ortadan kaybolur
    • Açık kaynağın tekelci şirketler için olduğu yönünde alaycı bir ton; AWS gibi hyperscaler'ların Redis üzerinden yüz milyonlarca dolar kazandığı ama gerçek geliştiricilerle katkıcıların bundan fayda görmediği hayal kırıklığını dile getiriyor. Bu yüzden veritabanı girişimlerinin en baştan fair source ile başlaması gerektiği söyleniyor; yani kodu herkes özgürce kullanabilsin ama AWS ya da Google bunu managed service olarak sunacaksa ücret ödesin. Başlangıçta aşırı permissive lisansla çıkan Redis ve Elasticsearch için ise artık geri dönüşün zor olduğu söyleniyor
  • Son dönemde dotnet projelerinin sıkça ticarileştiğini görüyorum. Bu tür değişiklikler geliştiricilere adeta bir rug pull gibi geliyor. Bu atmosfer, başka açık kaynak dotnet kütüphanelerinin yayılmasını da olumsuz etkileyebilir
    • .NET tarafında bu ticarileşme eğilimi yeni değil; zaten freeware/open-core ile iş modeli hep iç içeydi deniyor
  • Geçen yıldan beri Valkey'i duyuyordum, hâlâ iyi gidiyor olmasına sevindim
  • Valkey'in kendi istemci kütüphanelerini sunup sunmadığını merak ediyorum. Şu anda GCP ortamında hem MemoryStore hem de doğrudan yönettiğimiz kurulumlarda Redis/Redis Cluster kullanıyoruz. Resmî C kütüphanesi Redis Cluster+TLS için hayal kırıklığı yaratmıştı; bu yüzden gayriresmî bir istemci olan hiredis-cluster'ı kullanmak zorunda kalıyoruz (https://github.com/Nordix/hiredis-cluster). GCP'nin Memorystore hizmetinden de pek memnun değilim. Scylla'ya geçmeyi düşünüyorum
    • hiredis ile hiredis-cluster'ı birleştiren libvalkey adlı resmî bir fork var; mevcut hiredis/hiredis-cluster bakımcıları tarafından yönetiliyor libvalkey'e bakın
  • Redis politika değiştirmişken, Valkey ile Redis'in konuşup yeniden birleşmesi mümkün mü diye merak ediyorum
    • Lisans eski haline dönmedi, AGPL'ye taşındı; yani gerçek bir U dönüşü yok diye işaret ediliyor
  • Beklenen GPL kaynaklı FUD'a karşı mükemmel bir açıklama yazısı paylaşılmış ilgili yazı
    • Gönderide copyleft lisansların daha özgür olduğu iddiası bana biraz fazla kolaycı geliyor. Yükümlülük arttıkça özgürlük de azalır; bu yüzden hangi yaklaşımın daha "özgür" olduğu tartışması daha derin bir konu bence
  • Onlarca uygulamada Redis kullanıyorum. AWS'nin Valkey'i indirimli sunması üzerine iki ay önce denedim ve performans farkı da hissetmedim. Ama Valkey bir anda tamamen yanıt vermemeye başladı; AWS tarafında hâlâ çalışıyor görünüyordu ama bağlantı tamamen kesilmişti. 12 saatten uzun süre düzelmedi ve sonra yine tekrarlandı. AWS iki hafta boyunca araştırdı ama nedeni bulamadı. Bu yüzden artık Valkey'i mission-critical ortamlarda kullanmak benim için zor. Sonrasında aynı iş yüküyle Redis'e geri döndüm ve sorun yaşamadım
    • Bunun AWS kaynaklı bir sorun olabileceğini düşünüyorum. Biz de production RDS postgres cluster'da benzer bir şey yaşadık. Ağ yanıt vermeyi kesti; AWS enterprise support aldık ama sonunda yedekten kurtarıp yeni bir cluster'ı kendimiz oluşturduk, yaklaşık 4 saat sürdü. O günden sonra AWS'nin encapsulated servislerinden kaçınıp normal EC2 üzerinde replication, snapshot ve S3 replikasyonu ile devam ettik
    • Bunun AWS operasyonlarıyla ilgili olma ihtimali var; Redis'i doğrudan çalıştırdım ama sorun Valkey'in kendisi olmayabilir
    • Neden doğrudan kendi Valkey instance'ınızı çalıştırmıyorsunuz diye soruluyor
    • Hangi instance tipini kullandığınızı merak ediyorum, referans olması açısından soruyorum