Caching အခြေခံသဘောတရား

နားလည်ထားရမယ့် အချက်

Caching ဆိုတာ database query ရှုပ်ထွေးတာ၊ computation တစ်ခု၊ rendered page တစ်ခုလိုမျိုး ထပ်ခါထပ်ခါ လုပ်ရင် ကုန်ကျစရိတ်များတဲ့ အလုပ်တွေရှိလို့ လိုအပ်တာပါ — ရလဒ်တူတူကို မကြာခင်ထပ်လိုအပ်ရင် ရှေ့ကနေပြန်လုပ်ခြင်းက underlying system ပေါ်မှာ အချိန်နဲ့ load ဖြုန်းတီးနေတာပါ။ Cache တစ်ခုက ဒီရလဒ်ကို မြန်တဲ့နေရာတစ်ခု (usually memory) မှာ သိမ်းထားပြီး နောက်တစ်ကြိမ် အလားတူ request အတွက် ချက်ချင်း ဖြေပေးနိုင်ပါတယ်။ အသုံးအများဆုံး pattern ကတော့ cache-aside ပါ — application က cache ကို အရင်စစ်ပြီး cache hit ဖြစ်ရင် သိမ်းထားတဲ့ value ကို ချက်ချင်း ပြန်ပေးပါတယ်; cache miss ဖြစ်ရင်တော့ real source (database) ဆီ ပြန်သွားပြီး fresh value ကို fetch လုပ်ပြီး cache ထဲ populate လုပ်ပြီးမှ return ပြန်ပေးပါတယ် — ဒါကြောင့် ပထမဆုံး request တစ်ခုတည်းသာ full cost ကို ပေးဆောင်ရတာပါ။ Write-through ကတော့ data ကို fresh ဖြစ်စေဖို့ alternative pattern ပါ — write တွေက cache နဲ့ source ကို တစ်ပြိုင်နက်တည်း သွားပြီး cache ဟာ ဘယ်တော့မှ နောက်ကျမနေပါဘူး။ ဒီနှစ်ခုစလုံးရဲ့ fundamental risk ကတော့ staleness ပါ — underlying data ပြောင်းလဲသွားပေမယ့် cache ကို မပြောတာဆိုရင် cache က ခေတ်နောက်ကျနေတဲ့ value ကို ယုံကြည်စိတ်ချစွာ ဆက်ပေးနေပါလိမ့်မယ်၊ response နှေးတာနဲ့ မတူဘဲ stale response တစ်ခုက မှန်ကန်ပုံပေါ်နေရင်းနဲ့ တကယ်တော့ မှားနေတာဖြစ်ပါတယ် — ဒါကြောင့် cache invalidation ကို ယူဆထားတာမျိုးမဟုတ်ဘဲ deliberate ကိုင်တွယ်ရမှာပါ။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Tutorial Platform ဟာ ထင်ရှားတဲ့ နေရာတွေမှာ caching ရဲ့ အကျိုးကို ရရှိနေပြီး ဖြစ်ပါတယ် — lesson တစ်ခုရဲ့ content ဟာ ရှားရှားပါးပါးပဲ ပြောင်းလဲတတ်လို့ page view တိုင်းမှာ database query လုပ်မယ့်အစား rendered lesson ကို cache-aside သုံးပြီး cache ထားနိုင်ပါတယ် — cache စစ်ပြီး miss ဖြစ်မှသာ database ကို hit လုပ်ပါ။ ဒါပေမယ့် author တစ်ယောက်က lesson ကို edit လုပ်ရင် stale cache ကြောင့် learner တွေ old wording ကိုပဲ ဆက်ပြီး endless ဖတ်နေနိုင်ပါတယ်၊ ဒါကြောင့် platform က TTL တစ်ခု ဒါမှမဟုတ် publish လုပ်ချိန် explicit invalidation တစ်ခု လိုအပ်ပြီး reader တွေ ခဏနေရင် (ဒါမှမဟုတ် ချက်ချင်း) update ကို မြင်ရအောင် လုပ်ပေးရပါတယ်။ ဒီ freshness versus ထပ်ခါထပ်ခါ ကုန်ကျတဲ့အလုပ် trade-off ဟာ search-suggest result, trending-lesson ranking, request တစ်ခုချင်းစီအတွက် ပြန်တွက်ချင်စိတ်မရှိတဲ့ data တခြားတွေမှာလည်း ထပ်ကြုံရပါတယ်။

• Caching ဟာ database query ဒါမှမဟုတ် computation လို ကုန်ကျစရိတ်များတဲ့ အလုပ်ကို ထပ်မလုပ်ဘဲ ရလဒ်ကို မြန်တဲ့နေရာမှာ သိမ်းထားပြီး ပြန်သုံးတာဖြစ်တယ်။
• Cache-aside ဟာ cache ကို အရင်စစ်ပြီး miss ဖြစ်မှသာ source ဆီ ပြန်သွားကာ cache ထဲ populate လုပ်တာဖြစ်ပြီး write-through ကတော့ write တိုင်းမှာ cache နဲ့ source ကို တစ်ပြိုင်နက် update လုပ်တာဖြစ်တယ်။
• Invalidation (TTL ဒါမှမဟုတ် explicit) ကို deliberate မကိုင်တွယ်ရင် cache က stale ဖြစ်ပြီး မှားယွင်းတဲ့ data ကို ယုံကြည်စိတ်ချစွာ ဆက်ပေးနိုင်တယ် — stale response ဟာ မှန်ကန်ပုံပေါ်နေရင်းနဲ့ တကယ်တော့ မှားနေတာပါ။

အတူတူ စမ်းရေးကြည့်မယ်

Request for lesson "intro-to-arrays"
            |
            v
     +--------------+
     | Check cache  |
     +--------------+
        |         |
      HIT        MISS
        |         |
        v         v
  +-----------+  +------------------+
  | Return    |  | Query database    |
  | cached    |  +------------------+
  | value     |         |
  | (fast)    |         v
  +-----------+  +------------------+
                 | Populate cache    |
                 +------------------+
                         |
                         v
                 +------------------+
                 | Return value      |
                 | (slower, once)    |
                 +------------------+

Diagram က cache-aside flow ကို ပြသပြီး cache hit ဟာ ချက်ချင်းဖြစ်ကြောင်း၊ cache miss ကတော့ database query, cache populate ပြီးမှ return ဖြစ်ကြောင်း ပြသပါတယ်။

Wikipedia — Cache (computing) — System Design