Caching என்றால் என்ன? App builders-க்கான எளிய விளக்கம்
Caching என்பது பெறுவதற்கு மெதுவான அல்லது செலவான ஒன்றின் தயார் நகலை வைத்திருப்பது; அதனால் அடுத்த கோரிக்கைக்கு அந்த நகலிலிருந்து விரைவாகப் பதில் சொல்ல முடியும். சேமித்த நகலுக்கு cache என்று பெயர். உங்கள் browser படங்களைச் cache செய்வதால் இரண்டாவது முறை வருகையில் தளம் வேகமாக ஏற்றப்படுகிறது; ஒரு server மெதுவான database query-இன் முடிவைச் cache செய்வதால், ஒவ்வொரு பார்வையாளருக்கும் அதை மீண்டும் ஓட்டத் தேவையில்லை.
Caching ஆப்களை வேகமாகவும் இயக்குவதற்கு மலிவாகவும் ஆக்குகிறது. அதன் ஒரே பெரிய விலை: ஒரு நகல் பழையதாகிவிடலாம்.
AI மூலம் உருவாக்கும்போது caching ஏன் முக்கியம்
AI-யால் உருவாக்கப்பட்ட ஆப்களில் caching மூன்று வழிகளில் வரும்:
- “ஆப்பைப் புதுப்பித்தேன், ஆனால் இன்னும் பழைய பதிப்பு தெரிகிறது.” இதுதான் மிகப் பொதுவான caching சம்பவம்; பெரும்பாலும் இது தீங்கற்றது — உங்கள் browser அல்லது ஒரு CDN சேமித்த நகலைக் காட்டுகிறது.
- வேகம். ஒவ்வொரு பார்வையாளருக்கும் ஒரே கணக்கீடுகளை மறுபடி செய்வதால் ஒரு பக்கம் மெதுவாக இருந்தால், அதன் முடிவை cache செய்வது உடனடியாக உணர வைக்கும்.
- செலவு. பல AI builders மற்றும் hosts compute, database நேரம் மற்றும் வெளிப்புற API அழைப்புகளுக்குக் கட்டணம் வசூலிக்கின்றனர். ஆயிரம் பார்வையாளர்கள் ஒரே செலவான கோரிக்கையைத் தூண்டினால், caching மூலம் ஒரு முறை மட்டும் பணம் செலுத்தலாம்.
அடிப்படைகளை அறிந்திருந்தால், எங்கே caching உதவும் என்று கேட்கவும், ஏதாவது தவறாகத் தோன்றும்போது அதுவே காரணமா என்று கண்டறியவும் முடியும்.
ஒரு அன்றாட உவமை
பரபரப்பான ஒரு காப்பி கடையின் சமையலறையை நினையுங்கள்.
ஒவ்வொரு காலையும், ஒவ்வொரு காபியும் ஆர்டர் செய்யப்படும்போது புதிய பீன்ஸிலிருந்து காய்ச்சலாம். அது மெதுவானது. அதற்குப் பதிலாக, சூடான தட்டில் ஒரு பாத்திரம் filter காபியைத் தயாராக வைத்திருக்கிறார்கள். பெரும்பாலான வாடிக்கையாளர்கள் சில நொடிகளில் ஒரு கோப்பை பெறுகிறார்கள் — அது cache hit. பாத்திரம் தீர்ந்ததும், யாரோ புதிதாக காய்ச்சுகிறார்கள் — அது cache miss.
ஆனால் நீண்ட நேரம் வைத்திருந்த காபி பழையதாகிவிடும், அதனால் கடைக்கு ஒரு விதி: 30 நிமிடத்துக்கு மேல் பழைய எந்தப் பாத்திரத்தையும் தூக்கி எறியுங்கள். அந்த விதியே cache-இன் காலாவதி நேரம். யாரும் நாள் முழுவதும் ஒரே பாத்திரத்தை வைத்திருக்க மாட்டார்கள்; யாருடைய தனிப்பட்ட ஆர்டரையும் (பால் குறைவாக, மூன்று சர்க்கரை) முன்கூட்டியே காய்ச்ச மாட்டார்கள் — சில விஷயங்களை எந்த விதத்திலும் cache செய்யக்கூடாது.
Caches எங்கே வாழ்கின்றன
ஒரு பக்கம் ஏற்றப்படும்போது பல caches வழியாகச் செல்லலாம், பயனருக்கு அருகில் இருந்து தொலைவு வரை:
| Cache | எங்கே இருக்கிறது | பொதுவாக என்ன சேமிக்கிறது | எடுத்துக்காட்டு |
|---|---|---|---|
| Browser cache | பார்வையாளரின் சாதனத்தில் | படங்கள், stylesheets, scripts, fonts | இரண்டாவது பக்கத்தில் உங்கள் logo உடனடியாக ஏற்றப்படும் |
| CDN cache | பார்வையாளர்களுக்கு அருகில் உலகெங்கும் உள்ள servers | நிலையான கோப்புகள், சில சமயம் முழுப் பக்கங்கள் | டோக்கியோவில் உள்ள ஒரு பார்வையாளர் உங்கள் origin-க்குப் பதிலாக அருகிலுள்ள server-இலிருந்து கோப்புகளைப் பெறுவார் |
| Application cache | உங்கள் server-இலோ அதன் அருகிலோ, பெரும்பாலும் memory அல்லது Redis-இல் | மெதுவான queries அல்லது வெளிப்புற API அழைப்புகளின் முடிவுகள் | இன்றைய exchange rates, ஒரு மணி நேரத்திற்கு ஒரு முறை பெறப்பட்டது |
| Database cache | Database-க்கு உள்ளே | அண்மையில் பயன்படுத்தப்பட்ட தரவு மற்றும் query plans | பிரபலமான rows வேகமான memory-யில் இருக்கும் |
CDN (content delivery network) என்பது உங்கள் தளத்தின் கோப்புகளுக்கான உலகளாவிய caches வலைப்பின்னல்.
ஒரு cache எதை வைத்திருக்க வேண்டும் என்று எப்படித் தீர்மானிக்கிறது
ஒவ்வொரு cache-உம் இதே கேள்விகளுக்குப் பதிலளிக்க வேண்டும்:
- எதை cache செய்யலாம்? பொதுவான, பகிரப்பட்ட தரவு (ஒரு தயாரிப்புப் படம், ஒரு blog பதிவு) — ஆம். தனிப்பட்ட தரவு (பயனரின் கணக்குப் பக்கம், அவர்களின் செய்திகள்) — பகிரப்பட்ட cache-இல் ஒருபோதும் இல்லை.
- எவ்வளவு நேரம்? இதுவே TTL (time to live). ஒரு logo-வை ஒரு வருடம் cache செய்யலாம்; ஒரு stock நிலையை 30 வினாடிகள் மட்டும்.
- எப்படிப் புதுப்பிக்கப்படுகிறது? ஒன்று, நகல் காலாவதியாகி மீண்டும் பெறப்படுகிறது; அல்லது தரவு மாறும்போது ஆப் வேண்டுமென்றே அதை நீக்குகிறது — இதற்கு invalidation என்று பெயர்.
வலைத்தளங்களுக்கு, ஒவ்வொரு கோப்பையும் browsers மற்றும் CDNs எப்படி cache செய்ய வேண்டும் என்பதை server Cache-Control header மூலம் சொல்கிறது. உதாரணமாக Cache-Control: max-age=3600 என்றால் “இந்த நகலை ஒரு மணி நேரம் மீண்டும் பயன்படுத்தலாம்” என்று பொருள்.
நவீன build tools நிலையான கோப்புகளுக்கான கடினமான பகுதியை cache busting மூலம் கையாளுகின்றன: ஒவ்வொரு முறை கோப்பு மாறும்போதும், அதற்கு app.3f9a2c.js போல கைரேகையுடன் புதிய பெயர் கிடைக்கும். புதிய பதிப்புக்கு வேறு பெயர் இருப்பதால், browsers பழைய பெயரை நீண்ட நேரம் cache செய்யலாம்.
ஒரு செயல்முறை எடுத்துக்காட்டு: ஒரு தயாரிப்புப் பட்டியல்
உங்களிடம் ஒரு சிறிய ஆன்லைன் கடை உள்ளது. முகப்புப் பக்கம் database-இலிருந்து 50 தயாரிப்புகளின் விலைகளையும் stock நிலைகளையும், அத்துடன் எல்லா orders-ஐயும் சரிபார்க்கும் மெதுவான கணக்கீட்டின் “trending” பட்டியலையும் காட்டுகிறது.
- படங்களும் scripts-உம் browser மற்றும் CDN-ஆல் நீண்ட நேரத்திற்கு cache செய்யப்படுகின்றன. ஒவ்வொரு புதிய build-உம் மாறிய கோப்புகளுக்குப் புதிய பெயர்களைத் தருகிறது, அதனால் புதுப்பிப்புகள் இன்னும் தோன்றும்.
- Trending பட்டியல் ஒவ்வொரு 10 நிமிடத்திற்கும் ஒரு முறை கணக்கிடப்பட்டு ஒரு application cache-இல் வைக்கப்படுகிறது. அந்த 10 நிமிடங்களில் ஒவ்வொரு பார்வையாளரும் சேமித்த முடிவை உடனே பெறுகிறார்.
- விலைகள் குறுகிய நேரத்திற்கு cache செய்யப்படுகின்றன, நீங்கள் ஒரு தயாரிப்பைத் திருத்தும்போதெல்லாம் cache அழிக்கப்படுகிறது; அதனால் வாடிக்கையாளர்கள் பழைய விலையை நீண்ட நேரம் பார்ப்பதில்லை.
- Checkout-இல் stock ஒருபோதும் cache செய்யப்படுவதில்லை. ஒருவர் “Buy” அழுத்தும்போது, ஆப் உண்மையான database-ஐச் சரிபார்க்கிறது; அதனால் சற்று முன்பு விற்றுத்தீர்ந்த பொருளை விற்க முடியாது.
- Cart மற்றும் கணக்குப் பக்கங்கள் பகிரப்பட்ட caches-இல் ஒருபோதும் சேமிக்கப்படுவதில்லை, ஏனெனில் அவை தனிப்பட்டவை.
விளைவு: முகப்புப் பக்கம் வேகமாக இருக்கும், database மிகக் குறைந்த வேலை செய்யும், பணம் அல்லது தனியுரிமை சம்பந்தப்பட்ட எதுவும் ஒருபோதும் பழையதாக இருக்காது.
முக்கிய சொற்கள்
| சொல் | பொருள் |
|---|---|
| Cache hit / miss | தரவு cache-இல் கிடைத்தது / மூலத்திலிருந்து பெற வேண்டியிருந்தது. |
| TTL (time to live) | சேமித்த நகல் எவ்வளவு நேரம் புதியதாகக் கருதப்படும். |
| Stale data | பழையதாகிவிட்ட cache நகல். |
| Invalidation | மூலம் மாறியதால் சேமித்த நகலை வேண்டுமென்றே நீக்குதல். |
| Cache busting | கோப்பு மாறும்போது அதன் பெயரையோ URL-ஐயோ மாற்றி, caches புதிய பதிப்பைப் பெறச் செய்தல். |
| Cache-Control | Browsers மற்றும் CDNs ஒரு பதிலை எப்படி cache செய்ய வேண்டும் என்று சொல்லும் HTTP header. |
| Hard refresh | Browser தனது cache-ஐப் புறக்கணிக்கச் சொல்லி பக்கத்தை மீண்டும் ஏற்றுதல். |
| Redis | பிரபலமான memory தரவு store; பெரும்பாலும் application cache-ஆகப் பயன்படுகிறது. |
பொதுவான தவறான புரிதல்கள்
- “Caching எப்போதும் நல்லது.” தவறானதை cache செய்தால் உண்மையான பிழைகள் வரும்: பழைய விலைகள், புதிய பதிவுகள் காணாமல் போவது, அல்லது மோசமான நிலையில் ஒரு பயனரின் தனிப்பட்ட பக்கம் இன்னொருவருக்குக் காட்டப்படுவது. திட்டமிட்டு cache செய்யுங்கள்.
- “பழைய பதிப்பு தெரிந்தால், என் புதுப்பிப்பு தோல்வியடைந்தது.” பொதுவாக அப்படியல்ல. ஏதாவது உடைந்துவிட்டது என்று நினைப்பதற்கு முன் hard refresh (Ctrl+Shift+R, அல்லது Mac-இல் Cmd+Shift+R) அல்லது private window முயற்சியுங்கள்.
- “Caching ஒரு மெதுவான ஆப்பைச் சரிசெய்யும்.” அது மீண்டும் மீண்டும் வரும் கோரிக்கைகளின் மெதுவான தன்மையை மறைக்கிறது. முதல் கோரிக்கை இன்னும் மெதுவாகவே இருக்கும்; அடிப்படைச் சிக்கல் database index இல்லாததாக இருந்தால், அதையும் சரிசெய்யுங்கள்.
- “எல்லாவற்றையும் முடிந்தவரை நீண்ட நேரம் cache செய்ய வேண்டும்.” மாறும்போது புதிய பெயர் பெறும் கோப்புகளுக்கு நீண்ட cache நேரம் பொருந்தும். HTML பக்கங்களுக்கும் தரவுக்கும் குறுகிய நேரமே பாதுகாப்பானது.
- “என் cache-ஐ அழித்தால் அனைவருக்கும் சரியாகிவிடும்.” அது உங்கள் browser-ஐ மட்டுமே அழிக்கிறது. பார்வையாளர்களின் மற்றும் CDN caches-இன் நகல்கள் இன்னும் அப்படியே இருக்கும்.
உங்கள் AI builder-இடம் கேட்க வேண்டியவை
- “இந்த ஆப்பின் எந்தப் பகுதிகள் மெதுவாக உள்ளன, எவை பாதுகாப்பாக cache செய்யலாம்?”
- “[trending பட்டியல் / API முடிவை] [N] நிமிடங்களுக்கு cache செய், அடிப்படைத் தரவு மாறும்போது அதை அழி.”
- “தனிப்பட்ட அல்லது கணக்குத் தரவு உள்ள எந்தப் பக்கத்தையும் CDN அல்லது பகிரப்பட்ட cache சேமிக்க முடியாதபடி உறுதிசெய்.”
- “நிலையான, கைரேகை கொண்ட கோப்புகளுக்கு நீண்ட cache நேரங்களையும், HTML-க்கு குறுகிய நேரங்களையும் அமை.”
- “[வெளிப்புற API]-இலிருந்து வரும் பதில்களை cache செய், ஒவ்வொரு பக்க ஏற்றத்திலும் அதை அழைக்காதபடி — அந்தத் தரவு எவ்வளவு பழையதாகலாம் என்றும் சொல்.”
- “வெளியிட்ட பிறகு பழைய பதிப்பு தெரிகிறது. அது என் browser cache-ஆ, அல்லது எதுவோ deploy ஆகவில்லையா?”
Mythex-இல் Caching
Mythex ஆப்பை வெளியிட்ட பிறகு, CDN caches சிறிது நேரம் பின்தங்கலாம் என்றும், பொது URL-ஐ hard refresh செய்தால் புதிய பதிப்பு தெரியும் என்றும் docs குறிப்பிடுகின்றன — How to publish பார்க்கவும். Hosting limits பக்கம் நிலையான assets-ஐ cache செய்ய பரிந்துரைக்கிறது; ஏனெனில் hosting, database நேரம், bandwidth ஆகியவற்றுக்கு உங்கள் credit balance-இலிருந்து பணம் செலுத்தப்படுகிறது. அதற்கு அப்பால் — query முடிவுகளையோ API பதில்களையோ cache செய்வது — அதை உங்கள் ஆப்பில் கட்டமைக்கும்படி agent-இடம் கேட்க வேண்டும்.
தொடர்புடைய வாசிப்புகள்: CDN என்றால் என்ன, உங்கள் இணையதளத்தை வேகமாக்குவது எப்படி மற்றும் rate limiting என்றால் என்ன.
கேள்விகள்
எளிய சொற்களில் caching என்றால் என்ன?
Caching என்பது பெறுவதற்கு மெதுவான அல்லது விலை உயர்ந்த ஒன்றின் நகலைச் சேமித்து வைப்பது; அடுத்த முறை தேவைப்படும்போது அந்தச் சேமித்த நகலிலிருந்து விரைவாக வழங்கலாம். Browsers, CDNs, servers, databases அனைத்தும் ஆப்களை வேகமாகவும் இயக்குவதற்கு மலிவாகவும் ஆக்க caches-ஐப் பயன்படுத்துகின்றன.
இணையதளத்தைப் புதுப்பித்த பிறகும் ஏன் பழைய பதிப்பு தெரிகிறது?
உங்கள் browser அல்லது ஒரு CDN பழைய கோப்புகளின் சேமித்த நகலை வழங்கிக்கொண்டிருக்கலாம். Hard refresh (Windows-இல் Ctrl+Shift+R, Mac-இல் Cmd+Shift+R) பொதுவாக அதைச் சரிசெய்யும். பார்வையாளர்களுக்கு, நன்கு கட்டமைக்கப்பட்ட தளங்கள் புதுப்பிக்கப்பட்ட கோப்புகளுக்கு புதிய பெயர்களைத் தருகின்றன, அதனால் caches தானாகவே புதிய பதிப்பைப் பெறும்.
Cache-ஐ அழிப்பது என்ன செய்கிறது?
Browser cache-ஐ அழிப்பது, browser சேமித்த கோப்புகள் மற்றும் பக்கங்களின் நகல்களை நீக்குகிறது, அதனால் அடுத்த முறை எல்லாவற்றையும் புதிதாகப் பதிவிறக்கும். உடைந்தோ பழையதாகவோ தெரியும் பக்கங்களைச் சரிசெய்யலாம்; அதன் பின் முதல் முறை பக்கங்கள் சற்று மெதுவாக ஏற்றப்படும்.
Caching பிரச்சனைகளை ஏற்படுத்தலாமா?
ஆம். முக்கிய ஆபத்து பழைய தரவைப் பரிமாறுவது — பழைய விலை, காலாவதியான stock நிலை — அல்லது அதைவிட மோசமாக, ஒரு பயனரின் தனிப்பட்ட பக்கத்தை வேறொருவருக்குக் காட்டுவது. நல்ல caching விதிகள் எதை cache செய்யலாம், எவ்வளவு நேரம், மற்றும் பகிரப்பட்ட caches-இல் தனிப்பட்ட தரவை ஒருபோதும் cache செய்யக்கூடாது என்பதைத் தீர்மானிக்கும்.