Redis'e ihtiyacınız olmayabilir

• Redis, teknoloji sektöründe en olumlu itibarlardan birine sahip teknolojilerden biri
  • Son derece iyi tasarlanmış, harika bir teknoloji ve kendi başına kusurlu değil; ancak her zaman gerekli olmayabilir
• 10+ yıl boyunca 3 şirkette aynı örüntüyü gördüm:
  • Bir sorun ortaya çıktı ve Redis uygun görünüyordu, fakat gerçekte durumu iyileştirmedi ya da temel sorunu çözmedi
  • Sadece karmaşıklık uğruna daha fazla karmaşıklık ekledi

İlk vaka: Tantan'daki deneyim

• Tantan, Çin'in en büyük ikinci flört uygulaması ve PostgreSQL tabanlı 50~100 yüksek performanslı veritabanı sunucusu işletiyor
• Her sunucu kullanıcı ID'sine göre shard ediliyor; belirli bir kullanıcının verileri yalnızca tek bir sunucuda tutuluyor
• Sorun durumu
  • 'Swipe' sayısını saklama ve hızlıca güncelleme gereksinimi ortaya çıktı
  • Başta bunu Redis'te saklamanın uygun olacağı düşünüldü
  • Yalnızca birkaç yüksek performanslı Redis sunucusunun yeterli olacağı varsayılarak kurulum yapıldı
• Yeniden değerlendirme ve çözüm
  • Ekip içinde Redis yerine doğrudan PostgreSQL'e yazma seçeneği tartışıldı
  • PostgreSQL sunucularındaki yük zaten yüksek olduğundan ek yükün ihmal edilebilir düzeyde olacağı öngörüldü
  • PostgreSQL'e yazıldıktan sonra da performans düşüşü olmadı ve Redis'e gerek kalmadı

İkinci vaka: Bannerflow'daki deneyim

• Arka plan
  • Bannerflow, reklam oluşturma ve yayınlama platformu
  • Yeni bir mikroserviste Facebook gibi sosyal ağlarda reklam yayınlamayı desteklemek için Redis kullanma kararı alındı
• Sorun durumu
  • Tantan'a kıyasla yükün belirgin biçimde daha düşük olduğu bir ortamda Redis'e gerçekten ihtiyaç olup olmadığı belirsizdi
  • İlk geliştirici ayrıldıktan sonra Redis'in neden eklendiğini net biçimde açıklayabilecek kimse kalmadı
• Sonuç
  • Yük düşük olduğu için Redis aslında gereksizdi
  • Uzun vadede Redis'i kaldırmanın en iyi seçenek olduğu sonucuna varıldı

Üçüncü vaka: MAJORITY'deki deneyim

• Arka plan
  • MAJORITY, harici API çağrılarının sonuçlarını cache'lemek için Redis kullanan bir fintech şirketi
  • Redis, konum sorgulama verilerini cache'leyerek işlem hızını artırmak ve maliyeti düşürmek için devreye alındı
• Sorun durumu
  • Aynı veriler DB'de (Azure SQL) de tutuluyordu
  • Redis çağrıları yerine DB çağrıları kullanılsa bile yük artışının neredeyse hiç olmayacağı öngörülüyordu
  • Kilit (lock) işlemleri gerektiği için Redis'i kullanmaya devam etmeyi düşündüler, ancak Azure SQL bunu yeterince karşılayabiliyordu
• Sonuç
  • Redis kullanımının gereksiz olduğu sonucuna varıldı
  • Redis yerine Azure SQL kullanmaya geçiş planı yapıldı

Sonuç

• Üç vakanın tamamı farklı alanlarda, teknoloji yığınlarında ve yük koşullarında yaşandı
• Ortak nokta, gereksiz Redis kullanımıydı
• Redis kullanmadan önce gerçek ihtiyaç ve performans faydaları yeterince değerlendirilmeli
• Dan McKinley'nin 'Choose Boring Technology' konuşması tavsiye edilir

[iolothebard]

Redis kullanıp kullanmamanızdan bağımsız olarak, domain ile persistence arasına bir cache katmanı yerleştirmek (varsayılan uygulaması bypass olsa bile) hiç de aşırı mühendislik değildir. Logging, fake data, debugging, profiling ve belki gerçekten caching bile…

[nodelay]

+1 Ben de katılıyorum. Sadece bir katman daha eklemek bile alan yaratıyor ve pek çok şeyi çözebileceğiniz bir alan açıyor.

[galadbran]

Redis’te bir sorun var demekten ziyade, yalnızca veritabanı yeterliyken neden ek bir bileşen getirip yönetim yükünü artırayım bakış açısı gibi görünüyor.
Biraz kısa anlatıyor, bu yüzden bunu daha çok böyle bir bakış açısını da düşünmek gerektiği şeklinde almak iyi olabilir.
Uygulama mantığını basit tutarken Redis cache eklemenin daha iyi bir seçim olabileceği durumlar da var,
dolayısıyla duruma göre seçim yapmak gerekecek.

[zinisuni]

Başlığa kandım. Haha, katılıyorum~~

[GN⁺]

Hacker News görüşleri

• 2015'te Uber'de çalışırken, posta kodu tabanlı coğrafi bölümlendirmeyi altıgen tabanlı bir yaklaşıma geçirmek istemişlerdi

  • Şehirleri onlarca posta koduna bölmek yerine, yüz binlerce altıgene bölüp dinamik bölgeler oluşturma yöntemiydi
  • İlk lansman Phoenix'te yapıldı ve ekip, talep bazlı fiyatlandırma sistemini ölçeklemek için sabahladı
  • Küresel lansman gecikti
  • Redis'i seven çok sayıda mühendis vardı
  • Fiyatlandırma servisi Redis tabanlıydı ve milyonlarca isteği işliyordu
  • Maliyeti yüksekti ve ölçeklenebilirlik sorunları da vardı
  • Algoritma iyileştirilerek tek bir makinede birden fazla şehrin dinamik bölgeleri hesaplanabildi
  • Isaac adlı bir mühendis bunu hafta sonunda uygulayıp dağıttı

• Redis'in aşırı kullanımı üzerine bir tartışma vardı

  • Redis harika ama kullanıldığında ağ gecikmesi ve serileştirme ek yükü oluşuyor
  • Veri zaten bölümlenmişse, sıradan bir hash map daha iyi olabilir
  • Java'da ConcurrentHashMap, Guava Caches ve Caffeine Caches gibi seçenekler var
  • Yerel önbellekleme uygulaması, ağı kullanmaktan neredeyse her zaman daha hızlıdır
  • Redis aşırı kullanılma eğiliminde

• Redis kullanım kültürü, popülerliğine kıyasla yeterince gelişmedi

  • Redis çeşitli veri yapıları destekliyor ve şirket kültürü olgunlaştıkça daha fazla kalıp öğrenilebiliyor
  • Redis için bir pattern derlemesinin olmaması üzücü

• Mesele Redis'e karşı Redis olmaması değil, iyi serileştirilemeyen verilerle çalışma meselesi

  • Sayaçlar, haber akışları, sohbet mesajları gibi şeylerde Redis daha verimli olabilir
  • Çoğu durumda MySQL de fazlasıyla yeterli olabilir

• Yazılım geliştirme çoğu zaman başkalarının yöntemlerini tekrarlama eğiliminde

  • Memcached ile başlayıp Redis'e evrildi
  • Veritabanının karmaşıklığından kaçınmak için cache kullanma eğilimi var
  • Veritabanları hâlâ karmaşık ve zor

• Redis, üretim ortamına hazır tek "data structure server"

  • Aynı servise birden fazla instance eriştiğinde kullanışlıdır

• Cache'e ihtiyacınız olmayabilir

  • Cache eklemeden mimariyi iyileştirmeye odaklanılan deneyimler vardı

• Redis'in API'si harika ama operasyonel riskleri var

  • Cache olarak iyi ama production veri deposu olarak güvenilir değil

• Redis kullanımını önermeme eğilimi şaşırtıcı

  • Redis hâlâ harika veri yapıları ve performans sunuyor

• Redis geçici cache olarak iyi ama transaction veya dağıtık veri deposu olarak yetersiz

  • Dağıtık kilit problemleri hakkında öğrenilmesi gerekenler var