Karar: Hangi önbellek stratejisi?
Önbellek (cache), sık okunan veriyi veritabanının önünde hızlı bir katmanda (ör. Redis) tutarak gecikmeyi ve DB yükünü düşürür. Ama her veri cache'e uygun değildir ve yanlış geçersiz kılma (invalidation) bayat/yanlış veri riski doğurur. Bu ağaç; önce cache'e gerçekten gerek olup olmadığını, sonra okuma/yazma desenine göre cache-aside, read-through, write-through ve write-behind arasında seçim yapmayı ve stampede'i önlemeyi ele alır.
İş yükün nasıl: okuma mı ağır basıyor, yazma mı?
Önbellek en çok, aynı verinin defalarca okunduğu (okuma ağırlıklı) ve verinin sık değişmediği durumlarda kazandırır. Önce genel deseni belirle: veri çok okunup az mı değişiyor, sürekli mi güncelleniyor, yoksa cache eklemeye değip değmeyeceğinden emin değil misin?
- Okuma çok ağır, veri görece nadir değişiyor
- Yazma da yoğun; yazılan veri hemen/çok okunuyor
- Emin değilim; cache'e gerçekten gerek var mı?
Cache doldurma sorumluluğu kimde olsun?
Okuma ağırlıklı senaryoda temel seçim, cache'i kimin dolduracağıdır. Uygulaman cache'i açıkça yönetip DB'ye kendisi mi düşsün (esneklik yüksek), yoksa cache katmanı 'ıska' (miss) durumunda arkadaki DB'den veriyi kendisi mi çekip şeffaf biçimde döndürsün?
- Uygulama açıkça yönetsin; esneklik ve kontrol isterim
- Cache katmanı ıska anında DB'den kendisi çeksin (şeffaf)
Yazmada tutarlılık mı, yazma hızı mı öncelik?
Yazma yoğunsa, yazılan verinin cache ile DB arasında ne kadar tutarlı olacağına karar vermelisin. Her yazma anında cache ve DB birlikte güncellenip tutarlılık mı garanti edilsin (biraz daha yavaş yazma), yoksa önce cache'e yazıp DB'ye eşzamansız (arka planda) mı işlensin (çok hızlı yazma ama kayıp riski)?
- Tutarlılık önemli; okumalar hep güncel olmalı
- Yazma hızı kritik; kısa gecikmeli tutarlılık ve kayıp riski kabul
Öneri: Şimdilik cache ekleme
Cache bedava değildir: bir tutarlılık problemi (bayat veri), ek altyapı ve geçersiz kılma karmaşıklığı getirir. Sorgu zaten hızlıysa veya veri her istekte değişiyorsa cache fayda değil sadece hata yüzeyi ekler.
Öneri: Cache-aside (lazy loading)
Cache-aside'da uygulama önce cache'e bakar; veri yoksa (miss) DB'den okur, cache'e yazar ve döndürür. En yaygın ve esnek desendir; cache yalnızca gerçekten istenen veriyle dolar.
Öneri: Read-through cache
Read-through'da uygulama yalnızca cache ile konuşur; ıska durumunda veriyi DB'den çekip dolduran taraf cache katmanının kendisidir (bir sağlayıcı/loader üzerinden). Uygulama kodu sadeleşir, doldurma mantığı tek yerde toplanır.
Öneri: Write-through cache
Write-through'da her yazma hem cache'e hem DB'ye (senkron) yapılır; ikisi birlikte güncellenir. Böylece cache asla DB'nin gerisinde kalmaz ve okumalar hep güncel veriyi görür.
Öneri: Write-behind (write-back) cache
Write-behind'de yazma önce cache'e yapılır ve kullanıcıya hemen dönülür; DB'ye yazma arka planda, eşzamansız (toplu/gecikmeli) gerçekleşir. Yazma hızı en yüksektir ama kalıcılık ve tutarlılık riski taşır.