कॅश डेटा जो उत्पादन करण्यास महाग, वारंवार वाचला जातो, आणि क्वचितच बदलतो — हेच असे आहे जिथे कॅशिंग सर्वाधिक फायदेशीर ठरते. TTL (time to live) हा ताजेपण (डेटा किती वर्तमान असणे आवश्यक आहे) आणि जुरड़पणा सहनशीलता (हे किती काळ चूक असू शकते) यांच्यातील एक व्यापार-बंद आहे.
एक चांगला कॅश उमेदवार तिन्ही गोष्टींमध्ये उच्च स्कोर करतो:
स्वस्त-संगणना, लेखन-भारी, किंवा प्रति-वापरकर्ता-गुप्त डेटा कॅश करू नका ज्यांची ताजेपण अचूक असणे आवश्यक आहे (उदा. व्यवहाराच्या क्षणी खाते शिल्लक).
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 ला स्पष्ट अमान्यकरण सह एकत्र करा: write-through किंवा delete-on-write जेणेकरून कॅश एक्सपायरीच्या प्रतीक्षेऐवजी स्रोत बदलल्या क्षणी बाहेर काढला जाईल.
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
कॅश हिट अनुपात पाहा TTLs ट्यून करण्यासाठी: कमी अनुपात म्हणजे आप मूलतः कॅश करत नाही; जुरड़पणा तक्रारींसह उच्च अनुपात म्हणजे TTLs खूप लांब आहेत.
कॅश करायचे काय आणि TTL हे बरोबर मिळवणे प्रभावी कॅशिंगचे मुख्य आहे. चूक गोष्टी कॅश करा आणि तुम्ही कोणत्याही लाभासाठी जटिलता जोडता; TTLs खूप लांब सेट करा आणि तुम्ही जुरड़ डेटा सेवा करता; खूप लहान आणि तुम्ही फायदा गमावता. जुरड़पणा सहनशीलता वापरून TTLs निवडणे, शुद्धतेसाठी स्पष्ट अमान्यकरण जोडणे, आणि हिट अनुपात पाहणे तुम्हाला कॅश करण्याचा एक तत्त्वज्ञान, मापन करण्यायोग्य मार्ग देते.