ქეშდეს ის მონაცემები, რომლებიც ძვირი აღმოსაჩენია, ხშირად იკითხება და იშვიათად იცვლება — სწორედ აქ იხდის ქეშირება ყველაზე მეტ ზიანს. TTL (დაცხოვრების დრო) არის ახლებურობას (როგორი მიმდინარე უნდა იყოს მონაცემი) და მოძველების ტოლერანტობას (რამდენად შეიძლება იყოს არასწორი და რამდენი ხანი) შორის კომპრომისი.
ხელოვნური ქეშის კანდიდატი კარგად აფასებს სამივე პირობებზე:
ნუ ქეშდეთ იაფი გამოთვლა, წერის მძიმე ან თითოეული მომხმარებლის საიდუმლო მონაცემი, რომელიც უნდა იყოს სრულიად ახალი (მაგ. ანგარიშის ნაშთი გარიგების მომენტში).
Staleness tolerance → TTL:
config / static reference data → long (hours to days)
product listings, article body → medium (minutes)
prices, stock, leaderboards → short (seconds)
must always be exact → don't cache, or use explicit invalidation
მონაცემების სისწორისთვის, რომელიც არაპროგნოზირებად იცვლება, აერთიანოთ TTL კონკრეტული უქმდებით: დაწერა-ჯერ ან წაშლა-დაწერისას, რათა ქეში გაუქმდეს მხოლოდ წყაროს ცვლილების მომენტში, ვიდრე ველის ვადის მოსვლას.
on update(record):
db.save(record)
cache.delete(key(record)) // invalidate now, don't serve stale until TTL
hit ratio = hits / (hits + misses)
high (>90%) → cache is doing its job
low → TTL too short, keys too granular, or data not cacheable
დაყურეთ ქეშის დაჯამების თანაფარდობას TTL-ის სამართავად: დაბალი თანაფარდობა მნიშვნელოვნად, რომ თითქმის არ ქეშდებით; მაღალი თანაფარდობა მოძველების კომპლეინებით ნიშნავს, რომ TTL-ები ძალიან გრძელია.
ნათელი გახდეს რა-რა უნდა ქეშდეს და TTL სწორი ყოფა ეფექტური ქეშირების ბირთვი. ქეშდეთ არასწორი რამ და დაამატებთ სირთულე სარგებელი გარეშე; დააყენოთ TTL-ები ძალიან გრძელი და მოცემული მოძველებული მონაცემი; ძალიან მოკლე და დაკარგავთ ქეშის სარგებელს. მოძველების ტოლერანტობის გამოყენება TTL-ების არჩევისთვის, კონკრეტული უქმების დამატება სისწორისთვის და დაჯამების თანაფარდობის დაკვირვება იძლევა თქვენ პრინციპიული, გაზომვადი ხერხი ქეშირებაზე.