Eğer ki bir view yerine bir veritabanı sorgusunu önbellekte tutmak istiyorsanız low-level caching tam size göre. Örnek senaryomuzda bir e-ticaret sitesinin anasayfası ile uğraştığımızı düşünürsek. Anasayfada muhtemelen çok fazla sorgu olması gerekmekte. Hepsiburada.com’dan örnek verecek olursak, anasayfada şöyle içerikler mevcut:

  1. Öne Çıkan Ürünler
  2. İndirimli Ürünler
  3. Çok Satanlar
  4. Kargo Bedavalar
  5. Bugün Teslimat
  6. Günün Fırsatları
  7. Slayt Verileri

Bonus olarak:

  1. Header Kategorileri
  2. Footer Kategorileri, özel sayfalar vs.

Bunların tamamının ayrı sorgularla gerçekleştiğini düşünelim. Buna göre bir kullanıcı sayfayı açtığı anda toplam 9 farklı veritabanı sorgusu çalışacak. Şimdi gelelim cache mevzusuna.

Low-level caching bize şöyle bir güzellik sağlıyor: herhangi bir kişi sayfayı açtığında veritabanı sorgusu yapılıp önbelleğe alınıyor ve daha sonra sayfayı yenilediğinde veya başka bir kişi sayfayı ziyaret ettiğinde veritabanı sorgusu yerine onun sonuçları önbellekten getiriliyor. Ne zamana kadar? Bizim başta belirlediğimiz cache tutulma süresine kadar veya biz temizleyene kadar.

Burada yapılan işlem eğer cache_taimlayici_isim isminde önbellekte bir veri varsa onu return et, yoksa veritabanı sorgusunu cache_tanimlayici_isim olarak önbelleğe al ve sonucu return et. O halde anasayfa şöyle bir şey olacak:

Örnek olması açısından 3 tanesini oluşturdum. Genel olarak bu şekilde sorguları önbelleğe alabiliriz. Peki ya herhangi birinde değişiklik olduğunda ne olacak?

Bu şekilde de önbellek temizlemesi yapabiliyoruz. Slide modelini örnek verecek olursak; Slide modelinde herhangi bir değişiklik olduğunda home_slide_data cacheini temizlemek istiyorsam eğer

Çok kullanışlı bir yöntem olduğunu söylemem gerek. Size şuan üzerinde çalıştığım bir projeden örnek göstereyim. Normalde anasayfa açıldığındaki log çıktısı aşağıdaki şekilde

 

Low-level cache sonrası ise şöyle