Cache Policyleri ve Caching Stratejileri
CACHING STRATEJILERI
Caching temel itibariyle dataları ram üzerinde tutup ana data storage’a gitmek yerine dataları ramden almaya dayalı bir konsepttir. Yani uygulama ile storage arasına yüksek hızlı bir buffer koymak gibi düşünülebilir. Caching stratejilerine geçmeden önce cache hit ve cache miss kavramlarını açıklamakta fayda var. Uygulama bir datayı data storage’a gitmeden direkt cache’te bulup oradan alıyorsa bu cache hit olarak adlandırılır. Eğer cache’te ilgili datayı bulamayıp storage’a gidip oradan çekip cache’e koyuyorsa da bu cache miss olarak adlandırılır. Cache storage’ının efektif ve performanslı olabilmesi için cache hit’in yüksek olması gerekir. Bu hit ratio’da farklı parametrelere bağlı olmakla beraber genel olarak data access patterni ile doğrudan ilişkilidir. Bu access patternin değişmesi hit ratioyu düşürür.
Bir cache miss gerçekleştiğinde data ana data storage’dan iki şekilde fetch edilebilir.
- Object not found alındıktan sonra uygulama gidip ana sourcetan datayı çeker ve cache’a koyar
- Cache uygulama ve storage arasında inline olarak davranır ve uygulama adına gidip datayı alıp cache’e koyar.
“Caching ile ilgili temel bilgilere bu yazımdan da ulaşabilirsiniz”
1.Cache Policyleri
1.1 Eviction Policy
Cache storage’ların da belirli kapasiteleri olduğu için cache dolduğunda bazı dataların cache üzerinden silinmesi gerekir. Bu da belirlenen cache eviction (invalidation) policylerine göre olur. Bunun için de farklı yaklaşımlar mevcut.
- LRU – Least Recently Used : Cache’e yeni gelen data en uzun süre önce kullanılmış olan ile değiştirilir.
- LFU – Least Frequently Used : Cache’e yeni gelen data kullanım oranı en düşük data ile replace edilir.
- MRU – Most Recently Used : cac
- FIFO – First in First Out : Cache’e yeni gelen data en eski data ile değiştirilir.
1.2 Expiration Policy
Cache objelerinin cache storage dolmasa bile bir süre sonra silinmesi de gerekir. Bu süre o cache objesinin Time To Live (TTL)’i kadardır. TTL’i dolan obje cache’ten düşer. Bu duruma da cache expiration denir ve yeni bir access isteği geldiğinde datayı tekrar cache’e alarak günceller. Bu TTL ne kadar uzun olursa aynı access pattern üzerinde hit ratio artar ancak data tutarlılığının azalma olasılığı da düşer çünkü ana storage’daki data güncellense dahi cache storage’ın bundan haberi olmayabilir.
Doğru şekilde yapıldığı takdirde, caching reponse time’ını ve database’deki yükü azaltır ve uygulamayı belli bir maliyetten kurtarır. Cachelemenin farklı stratejileri olmakla birlikte doğru olanı seçmek büyük bir fark ortaya koyabilir. Doğru caching stratejisi ise ihtiyaçlarınıza ve data access patterninize bağlıdır. Farklı caching stratejileri olmakla birlikte en popülerleri aşağıdaki caching stratejileridir.
Cache-Aside
- Uygulama önce cache’i kontrol eder.
- Eğer data cache’te bulunursa, bu cache hit’tir ve data cache’ten okunur ve kullanıcıya geri döner.
- Eğer data cachte yoksa bu cache miss’tir. Bu durumda uygulama biraz fazla iş yapmak durumunda kalır. Data’yı okumak için database’e gider. Datayı client’e döner ve datayı cache’e sonraki okumalar için cache hit için yerleştirir.
Kullanım Durumları, Fayda ve Zararları
Cache aside genel amaçlı uygulamalarda kullanılmakta olup read-heavy workload’lar için uygundur. Genel olarak memcache ve redis kullanılır. Cache aside kullanılan sistemler cache çökmelerine de dayanıklıdır. Eğer cache cluster’ı çökerse, sistem direkt olarak database’e bağlanıp operasyonlarını devam ettirebilir. Ancak en kötü senaryoda cache peak noktasında çökerse response time çok fazla gecikmeye başlar ve database de çalışmayı durdurur.
Cache aside kullanıldıgında en yaygın write strategysi database’e direkt olarak yazmaktır. Bu yapıldığında cache ve database arasında inconsistent bir durum olabilir. Bunu handle edebilmek için genellikle developerlar TTL (time to live) kullanır ve cachelenmiş data TTL expire oluncaya kadar hizmet eder. Eğer data güncelliği garanti edilmeliyse, developerlar cache entirisini invalidate edebilir ya da farklı stratejiler kullanabilir.
Read-Though
Read though stratejisi de cache aside gibi datayi lazily şekilde yükler yani sadece ilk sefere mahsus databaseden okur. Cache-aside’da, uygulama datayı databaseten alıp, cache’e doldurmakla sorumludur. Read-thoughda application ve database arasında durur ve genelde library ve stand-alone cache providerlar tarafından desteklenen bir özelliktir. Yine cache-aside’tan farklı olarak, cacheteki data model databasedekinden farklı olamaz.
Kullanım Durumları, Fayda ve Zararları
Read-though caches read-heavy yükler için idealdir yani aynı datanın tekrar tekrar request edileceği uygulamalar için, örneğin haber bülteni. Read Though’nın dezavantajı ise data ilk request edildiğinde her zaman cache miss olacaktır. Yine cache-aside gibi, cachelenmiş data ve databasein inconsistent olma ihtimali vardır. Çözüm ise write stratejileridir.
Write-Thought sync
Write-Though sync stratejisinde, uygulama ana data storage ile muhattap değildir ve herhangi bir write isteği önce cache’e ve akabinde database’e yapılır. Database’de de write işlemi başarılı gerçekleştiğinde uygulama başarılı response’su alır.
Kullanım Durumları, Fayda ve Zararları
Write-though sisteme extra write latencysi katar çünkü data önce cache’e yazılır sonrasında ana database’e yazılır. Böylece hem read-though cache’in yararlarını kazanıp hem de consistency garantisi sağlamış oluruz. Bu sayede cache invalidation tekniklerini de düşünmek zorunda kalmayız.
DynamoDB accelerator (DAX) read-though/write-though cache’in güzel bir örneğidir. DynamoDB ve uygulama arasında durur. DynamoDB’ye yapılan write ve read’lar DAX tarafından yapılır.
Write-Back
Bu yaklaşımda datalar direkt olarak cache’e yazılır bir süre sonra database’e yazılır.
Kullanım Durumları, Fayda ve Zararları
Write back cache write performansını arttırır ve write yükü ağır olan uygulamalar için idealdir. Read-Thought ile kombinlendiğinde, most recently updated and accessed data daima cache’te olacak şekilde mixed workloadlarda çalışır.
Faydalı Linkler
