कैशिंग क्या है?

Question

मैं लगातार व्यक्ति के बारे में सुन रहा हूं वाई प्रदर्शन प्रदर्शन एक्स था जिसे उन्होंने कैशिंग के माध्यम से हल किया था।

या, अपने प्रोग्राम कोड में x, y, z कैसे कर रहे हैं, आपकी कैशिंग क्षमता को नुकसान पहुंचा सकता है।

यहां तक ​​कि नवीनतम पॉडकास्ट में से एक में, जेफ एटवुड इस बारे में वार्ता करता है कि वे त्वरित पुनर्प्राप्ति के लिए कुछ मूल्यों को कैसे कैश करते हैं।

"कैश" और "कैशिंग" शब्दों में कुछ अस्पष्टता प्रतीत होती है और इसने मुझे विभिन्न मामलों में इसका अर्थ भ्रमित करने के लिए प्रेरित किया है। चाहे आप एप्लिकेशन या डेटाबेस कैशिंग, सीपीयू, आदि का जिक्र कर रहे हों और इसका क्या अर्थ है।

कैशिंग क्या है और विभिन्न प्रकार क्या हैं?

संदर्भ से मैं इसके बारे में जान सकता, मुख्य स्मृति में एक बार लिया गया मान संग्रहीत और इसे करने के लिए पहुँच अप quicklook है। हालांकि, यह वास्तव में क्या है?

यह शब्द बहुत अलग अर्थों (सीपीयू, डेटाबेस, एप्लिकेशन इत्यादि) के साथ कई अलग-अलग संदर्भों में उपयोग किया जाता है और मैं वास्तव में इसे साफ़ करने के लिए देख रहा हूं।

क्या आपके अनुप्रयोगों में कैशिंग आपके डेटाबेस कैशिंग बनाम कैशिंग के बीच एक अंतर है?

जब कोई कहता है कि वे कोड का एक टुकड़ा कि कैशिंग चोट होता है और उसके बाद वे उसे ठीक किया, यह सुधार उनके अनुप्रयोग की गति पाया, वे बारे में बात कर रहे हैं?

क्या प्रोग्राम का कैशिंग कुछ है जो स्वचालित रूप से किया जाता है? कैसे आप अपने प्रोग्राम में मानों को कैश करने की अनुमति देते हैं? मैंने अक्सर पर उपयोगकर्ताओं को पढ़ा है कि यह साइट कहती है कि उन्होंने अपने आवेदन में मूल्य कैश किया है, मैं यहां बैठता हूं और आश्चर्य करता हूं कि उनका क्या मतलब है।

इसके अलावा, वास्तव में इसका क्या अर्थ है जब कोई डेटाबेस कैशिंग के बारे में बात करता है? क्या यह बस एक सुविधा है जो वे अपने डेटाबेस में चालू करते हैं? आपको स्पष्ट रूप से मूल्यों को कैश करना होगा या डेटाबेस को चुनने के लिए कौन से कैश हैं?

प्रदर्शन में सुधार के लिए मैं खुद को कैशिंग आइटम कैसे शुरू करूं?

तुम मुझे कैसे मैं अपने अनुप्रयोगों में कैशिंग मूल्यों शुरू कर सकते हैं के कुछ उदाहरण दे सकते हैं? या फिर, यह कुछ ऐसा है जो हुड के तहत पहले से ही किया गया है और मुझे बस "कैशिंग" की अनुमति देने के लिए एक विशेष तरीके से अपना कोड लिखना है?

डेटाबेस कैशिंग के बारे में क्या, मैं इसे कैसे शुरू करूं? मैंने memcache जैसी चीजों के बारे में सुना है। क्या इस प्रकार की उपयोगिता डेटाबेस में कैश करने के लिए आवश्यक है?

मैं अनुप्रयोग बनाम डेटाबेस में कैशिंग के बीच एक अच्छा भेद पाने के लिए देख रहा हूं, उनका उपयोग कैसे किया जाता है और यह दोनों मामलों में कैसे लागू किया जाता है।

Answer 1

कैशिंग बस में डेटा भंडारण और एक उच्च प्रदर्शन की दुकान (आमतौर पर स्मृति) या तो स्पष्ट या परोक्ष से डेटा प्राप्त करने का अभ्यास है।

मुझे समझाएं। मेमोरी एक फ़ाइल से अधिक तेज़ है, एक दूरस्थ यूआरएल (आमतौर पर), डेटाबेस या आपकी पसंद की किसी अन्य बाहरी स्टोर की जानकारी। तो यदि उन बाहरी संसाधनों में से एक का उपयोग करने का कार्य महत्वपूर्ण है तो आप प्रदर्शन बढ़ाने के लिए कैशिंग से लाभ उठा सकते हैं।

Knuth ने एक बार कहा था कि समयपूर्व अनुकूलन सभी बुराइयों की जड़ है। खैर, जहां तक ​​मेरा संबंध है, समय से पहले कैचिंग सभी सिरदर्द की जड़ है। एक समस्या हल न करें जब तक कि आप में कोई समस्या न हो। आपके द्वारा किए गए हर निर्णय की लागत उस लागत पर होती है जिसे आप अभी लागू करने के लिए भुगतान करेंगे और बाद में इसे बदलने के लिए फिर से भुगतान करेंगे ताकि आप एक विकृति बनाने और अपने सिस्टम को बेहतर तरीके से बदल सकें।

तो पहले पहचानें कि आपको वास्तव में कोई समस्या है और यह है।प्रोफाइलिंग, लॉगिंग और प्रदर्शन परीक्षण के अन्य रूप आपको यहां मदद करेंगे। मैं इस बात पर जोर नहीं दे सकता कि यह कदम कितना महत्वपूर्ण है। मैंने कई बार लोगों को "ऑप्टिमाइज़" देखा है जो कोई समस्या नहीं है, यह चौंकाने वाला है।

ठीक है, तो आपके पास एक प्रदर्शन समस्या है। मान लें कि आपके पृष्ठ एक क्वेरी चला रहे हैं जो लंबे समय तक लेता है। यदि यह पढ़ा गया है तो आपके पास कई विकल्प हैं:

• क्वेरी को एक अलग प्रक्रिया के रूप में चलाएं और परिणाम को कैश में रखें। सभी पेज बस कैश तक पहुंचते हैं। आप कैश किए गए संस्करण को जितनी बार उचित हो सकते हैं (एक दिन में, सप्ताह में एक बार, प्रत्येक 5 सेकंड में, जो भी उपयुक्त हो);
• अपने दृढ़ता प्रदाता, ओआरएम या जो कुछ भी के माध्यम से पारदर्शी रूप से कैश करें। बेशक यह इस बात पर निर्भर करता है कि आप किस तकनीक का उपयोग कर रहे हैं। उदाहरण के लिए हाइबरनेट और इबैटिस समर्थन क्वेरी परिणाम कैशिंग;
• यदि आपके परिणाम कैश में नहीं हैं (या यह "पुराना" है, जिसका अर्थ यह है कि इसकी गणना "आयु" से अधिक पहले की जाती है) और इसे कैश में डाल दें। इसमें समेकन समस्याएं होती हैं यदि दो (या अधिक) अलग प्रक्रियाएं सभी निर्णय लेती हैं कि उन्हें परिणाम अपडेट करने की आवश्यकता है ताकि आप एक ही समय में एक ही (महंगी) क्वेरी को आठ बार चला सकें। आप इसे कैश लॉक कर सकते हैं लेकिन यह एक और प्रदर्शन समस्या पैदा करता है। आप अपनी भाषा में समवर्ती तरीकों पर भी वापस आ सकते हैं (जैसे जावा 5 समवर्ती एपीआई)।

यदि यह एक अद्यतन (या अपडेट जगह अपने पढ़ने कैश में दिखाई देने की जरूरत है कि लेने के लिए) तो यह थोड़ा और अधिक जटिल है, क्योंकि यह कोई अच्छी बात है डेटाबेस ऐसे में कैश में एक पुराने मूल्य और एक नए मूल्य होने कि फिर आप अपने पृष्ठों को डेटा के असंगत दृश्य के साथ प्रदान करते हैं। लेकिन व्यापक रूप से यह कहकर चार दृष्टिकोण हैं:

• कैश अपडेट करें और फिर प्रासंगिक स्टोर को अपडेट करने के अनुरोध को कतार दें;
• कैशिंग के माध्यम से लिखें: कैश प्रदाता अद्यतन को जारी रखने के लिए एक तंत्र प्रदान कर सकता है और कॉलर को तब तक अवरुद्ध कर सकता है जब तक कि परिवर्तन नहीं किया जाता है; और
• लिखने के पीछे कैशिंग: लिखने के माध्यम से कैशिंग के रूप में, लेकिन यह कॉलर को अवरुद्ध नहीं करता है। अद्यतन असीमित और अलग होता है; और
• सेवा मॉडल के रूप में दृढ़ता: यह मानता है कि आपकी कैशिंग तंत्र किसी प्रकार की अवलोकनता (यानी कैश ईवेंट श्रोताओं) का समर्थन करता है। असल में एक पूरी तरह से अलग प्रक्रिया - कॉलर के लिए अज्ञात - कैश अपडेट के लिए सुनता है और उन्हें आवश्यकतानुसार जारी रखता है।

आपके द्वारा चुने गए उपर्युक्त तरीकों में से कौन आपकी आवश्यकताओं पर निर्भर करेगा, आप कौन सी तकनीकों का उपयोग कर रहे हैं और अन्य कारकों का पूरा मेजबान (उदाहरण के लिए क्लस्टरिंग और फेलओवर समर्थन आवश्यक है?)।

इससे अधिक विशिष्ट होना मुश्किल है और आपको जानने के बिना क्या करना है, इस बारे में अधिक जानकारी देना चाहिए (जैसे कि आपको कोई समस्या है या नहीं)।

Answer 2

कैशिंग एक लंबे या सीपीयू गहन एल्गोरिदम का परिणाम ले रहा है और उत्तर को सहेज रहा है ताकि आपको फिर से एल्गोरिदम चलाने की आवश्यकता न हो, तो आप केवल परिणाम का पुन: उपयोग करें।

Answer 3

यह कल्पना करना संभवतः आसान है - और यही कारण है कि लोग इसे बंद करने की कोशिश कर रहे हैं।

यह सिर्फ तुम्हारी याद में हर बार मान संग्रहीत करने के बजाय उनके लिए डेटाबेस के लिए वापस जाने के लिए मायने रखता है।

ऐसा करने के कई तरीके हैं, लेकिन अवधारणा स्वयं ही तुच्छ है।

संपादित करें: यह भी किसी भी स्तर पर किया जा सकता है - कुछ भी एक लंबे समय कहीं कैश हो सकता है कि आप करने के लिए और अधिक तेजी से प्राप्त कर सकते हैं लेता है।

डेटाबेस में

Answer 4

कैशिंग आम तौर पर एक समारोह डेटाबेस है और यह डेटाबेस द्वारा स्वचालित रूप से किया जाता है। अनुप्रयोगों में कैशिंग एक मंच से दूसरे में भिन्न होने जा रही है।

एक वस्तु कैश एक तंत्र है कि आप ताकि आप डेटा पुनः प्राप्त और उन्हें फिर से बनाना लागत का भुगतान करने की जरूरत नहीं है स्मृति में आमतौर पर इस्तेमाल किया वस्तुओं डाल करने के लिए उपयोग कर सकते हैं। यह आम तौर पर कोड के माध्यम से प्रबंधित होता है और आप किस कैशिंग समाधान का उपयोग कर रहे हैं उस पर भिन्न होता है।

कैश समाधान है कि कई सर्वरों पर सेवाओं को सेट करना आप एक तरह के कैश खेत देने के लिए शामिल वहाँ वितरित कर रहे हैं। यह स्केलेबिलिटी और रिडंडेंसी प्रदान करता है। ग्राहक नेटवर्क पर कैश की गई जानकारी का अनुरोध कर सकते हैं। फिर यह आपके कोड में एक मैन्युअल प्रक्रिया है। एक वितरित कैश प्रदाता का एक उदाहरण memcached है:

http://www.danga.com/memcached/

कैशिंग का एक विशेष प्रकार का एक उदाहरण asp.net कैशिंग होगा। Asp.net कई प्रकार के कैश का समर्थन करता है। पारंपरिक ऑब्जेक्ट कैश है (जिसका उपयोग सभी प्रकार के .NET ऐप्स में किया जा सकता है, केवल वेबसाइटों पर नहीं)। कैशिंग सुविधाएं भी हैं जो आपको अपने आउटपुट को स्वचालित रूप से कैश करने के लिए पृष्ठों और उपयोगकर्ता नियंत्रणों को कॉन्फ़िगर करने की अनुमति देती हैं। यह डेटा कैश नहीं करता है, यह अंतिम परिणाम (पृष्ठ का HTML) कैश करता है और जब उपयोगकर्ता पिछले पृष्ठ के समान क्वेरी स्ट्रिंग पैरा के साथ उसी पृष्ठ का अनुरोध करता है तो उस पर कार्य करता है।

Answer 5

दो अर्थ हैं जिन्हें मैं जानता हूं।

---

एक आवेदन कैशिंग है। यह तब होता है, यदि डेटा कहीं से (जैसे नेटवर्क से) धीमा हो जाता है या गणना करने में धीमा होता है, तो एप्लिकेशन डेटा की एक प्रति कैश करता है (ताकि उसे फिर से प्राप्त करने या पुन: गणना करने की आवश्यकता न हो: पहले से ही कैश किया गया)। कैश को कार्यान्वित करने में थोड़ा अतिरिक्त एप्लिकेशन सॉफ़्टवेयर (कैश का उपयोग करने के लिए तर्क) और अतिरिक्त मेमोरी (जिसमें कैश किए गए डेटा को स्टोर करने के लिए) लगता है।

"कैशिंग" है कि इस्तेमाल किया जा रहा तुम यहाँ के हवाले कर रहे हैं के रूप में:

संदर्भ से मैं इसके बारे में जान सकता, मुख्य स्मृति में एक बार लिया गया मान संग्रहीत और उस तक पहुँच अप quicklook है।

---

एक और सीपीयू कैशिंग, जो this Wikipedia article में वर्णन किया गया है। सीपीयू कैशिंग स्वचालित रूप से होता है। यदि आप स्मृति की एक छोटी राशि से बहुत कुछ पढ़ते हैं, तो सीपीयू अपने कैश से पढ़ने वाले अधिकांश को कर सकता है। ओटीओएच अगर आप बड़ी मात्रा में मेमोरी से पढ़ते हैं, तो यह कैश में फिट नहीं हो सकता है और सीपीयू को धीमे स्मृति के साथ काम करने में अधिक समय व्यतीत करना चाहिए।

है कि जैसा कि आप यहाँ के हवाले कर रहे हैं "कैशिंग" इस्तेमाल किया जा रहा:

कोई यह बताता है जब कि वे कोड का एक टुकड़ा है कि कैशिंग चोट होता पाया जाता है और उसके बाद वे उसे ठीक किया, यह उनकी एप्लिकेशन की गति में सुधार , वे किस बारे में बात कर रहे हैं?

इसका मतलब है कि उन्हें कम Cache misses का कारण बनने के लिए उनके कोड को पुनर्व्यवस्थित करने का एक तरीका मिला।

---

डेटाबेस कैशिंग का सवाल है, मैं नहीं जानता।

Answer 6

कैशिंग आवश्यक रूप से केवल 'पुनर्प्राप्त' मूल्यों पर लागू नहीं होती है, लेकिन आप जिस समय से इसे पुन: सम्मिलित करते हैं, उसे कम करके आप समय बचा सकते हैं। दिमाग में आने वाला एक साधारण उदाहरण fibonacci sequence की गणना कर रहा है। सबसे सरल पुनरावर्ती कार्यान्वयन इस तरह दिखता है (छद्म-कोड में):

function f(n) 
    if n < 2 then 
     return n; 
    return f(n - 1) + f(n - 2) 

यह पहले से ही ज्ञात मानों recalculating को रोकने के लिए कैशिंग के साथ सुधार किया जा सकता:

fib_cache = {} 

function f(n) 
    if n < 2 then 
     return n; 
    if fib_cache.contains(n) then 
     return fib_cache[n] 
    fib_cache[n] = f(n - 1) + f(n - 2) 
    return fib_cache[n] 

Answer 7

कैश अवधारणा एक ओवरलोड अवधि यहाँ है। मैं डेटाबेस कैशिंग के नट्स और बोल्ट से परिचित नहीं हूं।

आवेदनों में इस शब्द के दो उपयोग हैं।

जब कोई कहता है कि वे कोड का एक टुकड़ा कि कैशिंग चोट होता पाया जाता है और उसके बाद वे उसे ठीक किया, यह सुधार उनके अनुप्रयोग की गति, वे क्या कर रहे हैं के बारे में बात?

इस मामले में वे सीपीयू कैश का संदर्भ दे रहे हैं।

सीपीयू कैश ऑन-सीपीयू मेमोरी है जो रैम की तुलना में बहुत तेज़ है, लेकिन इसमें यादृच्छिक पहुंच नहीं है। सीपीयू कैश में लोड करने का फैसला करता है जो थोड़ा जटिल हो सकता है। बहुत सारे विवरणों के लिए Ulrich Dreppers What every programmer should know about memory देखें।

सीपीयू कैश के बारे में सावधान रहना चीजों को बहुत अच्छी तरह से बढ़ा सकता है - आपको भौतिक स्मृति में एक दूसरे के सापेक्ष चीजों को रखने के लिए और जब उन्हें उपयोग होने की संभावना है, तो थोड़ा और ध्यान देना होगा।

एक उदाहरण (संभवतः रखरखाव के लिए एक विरोधी पैटर्न) यह है कि आपके पास संरचनाओं की एक श्रृंखला है और आप संरचना के सदस्यों पर बहुत अधिक लूपिंग करते हैं, जिन्हें आप बेहतर संरचना के साथ सेवा कर सकते हैं जहां फ़ील्ड हैं सभी सरणी यदि आप जिस डेटा को लूपिंग कर रहे हैं वह स्मृति में संगत है, तो आपके पास कैश को परेशान करने में एक बेहतर मौका है।

सभी प्रकार की चीजें आपके कैश उपयोग की दक्षता को प्रभावित कर सकती हैं - कैश, आकार और डेटा संरचनाओं के संरेखण और एक्सेस पैटर्न के संरेखण के लिए शाखा पूर्वानुमान, स्थानीय चरों को कहां और कब घोषित किया जा रहा है ढेर।

एप्लिकेशन प्रोग्रामिंग के लिए शब्द का अन्य सामान्य उपयोग memoization नामक किसी चीज़ द्वारा किया जा सकता है। उस विकिपीडिया पेज पर फैक्टोरियल उदाहरण चीजों को बेहतर तरीके से बताता है जो मैंने किया होगा।

Answer 8

कुछ समस्याएं हैं।

वन, ग्रैन्युलरिटी है। आपके आवेदन में डेटाबेस के ऊपर और ऊपर कैशिंग के बहुत अच्छे स्तर हो सकते हैं। उदाहरण के लिए, डेटाबेस डेटा के पृष्ठों को कैश करने की संभावना है, जरूरी नहीं कि विशिष्ट पंक्तियां हों।

एक और बात यह है कि एप्लिकेशन अपने "मूल" प्रारूप में डेटा स्टोर कर सकता है, जबकि डीबी स्पष्ट रूप से केवल अपने आंतरिक प्रारूप में कैश करता है।

सरल उदाहरण।

कहें कि आपके पास डेटाबेस में उपयोगकर्ता है, जो कॉलम से बना है: USERID, FIRSTNAME, LASTNAME। बहुत आसान।

आप अपने आवेदन में उपयोगकर्ता, USERID=123 लोड करना चाहते हैं। क्या कदम शामिल हैं?

1. डेटाबेस कॉल
2. अनुरोध (SELECT * FROM USER WHERE USERID = ?)
3. अनुरोध योजना पार्स जारी
4. डिस्क
5. स्ट्रीमिंग से डेटा ला (यानी कैसे प्रणाली डेटा लाने जा रहा है) डेटाबेस से डेटा
6. डाटाबेस डेटा को एप्लिकेशन डेटा में कनवर्ट करना (यानी USERID एक पूर्णांक में, कहें, स्ट्रिंग्स के नाम।

डेटाबेस कैश, संभावित रूप से कैश चरण 2 और 3 (यह एक कथन कैश है, इसलिए यह क्वेरी को पार्स या प्रतिलिपि नहीं करेगा), और वास्तविक डिस्क ब्लॉक को कैश करेगा।

तो, यहां कुंजी है। आपका उपयोगकर्ता, USER ID 123, नाम JESSE JAMES। आप देख सकते हैं कि यह बहुत अधिक डेटा नहीं है। लेकिन डेटाबेस डिस्क ब्लॉक कैशिंग है। आपके पास इंडेक्स ब्लॉक है (123 इसके साथ), फिर डेटा ब्लॉक (वास्तविक डेटा के साथ, और उस अन्य पंक्तियों के साथ जो अन्य ब्लॉक पंक्तियों पर फिट है)। तो नाममात्र रूप से, कहें, डेटा के 60-70 बाइट्स में वास्तव में डीबी पर कैशिंग और डेटा प्रभाव होता है, शायद, 4 के -16 के (ब्लॉक आकार पर निर्भर करता है)।

उज्ज्वल पक्ष? यदि आपको पास की दूसरी पंक्ति की आवश्यकता है (USER ID = 124 कहें), तो इंडेक्स उच्च हैं और डेटा पहले ही कैश किए गए हैं।

लेकिन उस कैशिंग के साथ भी, आपको अभी भी तार पर डेटा को स्थानांतरित करने के लिए लागत का भुगतान करना होगा (और यह तब तक तार पर है जब तक आप स्थानीय डीबी का उपयोग नहीं कर रहे हों, तब वह लूपबैक हो), और आप " unmarshalling "डेटा। यही है, इसे डेटाबेस बिट्स से भाषा बिट्स में, एप्लिकेशन बिट्स में परिवर्तित करना।

अब, एप्लिकेशन को USER ID 123 प्राप्त करने के बाद, यह एक लंबे समय तक रहने वाले हैश मानचित्र में मूल्य रखता है।

यदि एप्लिकेशन इसे फिर से चाहता है, तो यह स्थानीय मानचित्र, एप्लिकेशन कैश में देखेगा, और लुकअप, वायर ट्रांसपोर्ट और मार्शलिंग लागतों को बचाएगा।

एप्लिकेशन कैशिंग का अंधेरा पक्ष सिंक्रनाइज़ेशन है। अगर कोई UPDATE USER SET LASTNAME="SMITH" WHERE USERID=123 में आता है और करता है, तो आपका एप्लिकेशन "उसे नहीं जानता" है, और इस प्रकार कैश गंदा है।

तो, उस संबंध को डीबी के साथ समन्वयित रखने के लिए उस संबंध को संभालने में विवरणों का एक समूह है।

डाटाबेस कैश का बहुत अधिक डेटा डेटा के "हॉट" सेट पर बड़े प्रश्नों के लिए बहुत अच्छा है। आपके पास जितनी अधिक मेमोरी है, उतना ही "गर्म" डेटा हो सकता है। बिंदु पर यदि आप रैम में पूरे डीबी को कैश कर सकते हैं, तो आप डिस्क से डेटा को रैम बफर में ले जाने के लिए I/O (कम से कम पढ़ने के लिए) देरी को खत्म कर देते हैं। लेकिन आपके पास अभी भी परिवहन और मार्शलिंग लागत है।

एप्लिकेशन अधिक चुनिंदा हो सकता है, जैसे डेटा के अधिक सीमित सबसेट कैश करना (डीबी केवल कैश ब्लॉक), और एप्लिकेशन को "करीब" डेटा रखने से बेहतर प्रदर्शन होता है।

नीचे की ओर यह है कि एप्लिकेशन में सब कुछ कैश नहीं किया गया है। डेटाबेस एप्लिकेशन की तुलना में डेटा को अधिक कुशलतापूर्वक स्टोर करने के लिए जाता है। आपके ऐप कैश किए गए डेटा के विरुद्ध आपको "क्वेरी" भाषा भी नहीं है। अधिकांश लोग आसानी से एक साधारण कुंजी के माध्यम से कैश करते हैं और वहां से जाते हैं। USER ID 123 ढूंढना आसान है, "सभी उपयोगकर्ता नाम जेएसईई" के लिए कठिन है।

डाटाबेस कैशिंग "मुक्त" हो जाती है, आप एक बफर संख्या सेट करते हैं और डीबीएमएस बाकी को संभालता है। कम प्रभाव, कुल I/O और डिस्क देरी को कम करता है।

एप्लिकेशन कैशिंग, अच्छी तरह से, एप्लिकेशन विशिष्ट है।

यह अलग "स्थैतिक" डेटा के लिए बहुत अच्छी तरह से काम करता है। यह बहुत आसान है। स्टार्टअप पर लुकअप टेबल में सामान का एक गुच्छा लोड करें और यदि वे बदलते हैं तो ऐप को पुनरारंभ करें। ऐसा करना आसान है।

के बाद उस जटिलता आप "गंदे" तर्क में जोड़ने के रूप में वृद्धि करने के लिए शुरू होता है, आदि

क्या यह सब, करने के लिए नीचे आता है यद्यपि, कि जब तक आप एक डेटा API है, तब तक आप संवर्द्धित कैश कर सकते है।

तो, जब तक आप डीबी को मारने के बजाय हर जगह getUser(123) पर कॉल करते हैं, तो आप बाद में वापस आ सकते हैं और getUser पर कैशिंग जोड़ सकते हैं जो आपके कोड को प्रभावित किए बिना।

तो, मैं हमेशा उस कोड के किसी भी प्रकार में डेटा एक्सेस लेयर का सुझाव देता हूं, ताकि उस अबास्ट्रक्शन और अवरोध परत को थोड़ा सा प्रदान किया जा सके।

Answer 9

आप वेब अनुप्रयोगों के संदर्भ में कैशिंग के बारे में अधिकतर पढ़ेंगे। वेब की प्रकृति के कारण, कैशिंग एक बड़ा प्रदर्शन अंतर कर सकती है।

निम्नलिखित पर विचार करें:

एक वेब पेज के अनुरोध वेब सर्वर है, जो आवेदन सर्वर है, जो कुछ कोड है कि पेज है, जो गतिशील रूप से करने के लिए डेटाबेस के लिए चालू करने के लिए की जरूरत है renders कार्यान्वित करने के बारे में अनुरोध गुजरता है करने के लिए हो जाता है डेटा पुनः प्राप्त करो।

यह मॉडल अच्छी तरह से स्केल नहीं करता है, क्योंकि पृष्ठ के अनुरोधों की संख्या बढ़ जाती है, सर्वर को प्रत्येक अनुरोध के लिए बार-बार वही करना पड़ता है।

यदि वेब सर्वर, एप्लिकेशन सर्वर और डेटाबेस विभिन्न हार्डवेयर पर हैं और एक-दूसरे के साथ नेटवर्क पर संवाद करते हैं तो यह एक और समस्या हो जाती है।

यदि आपके पास इस पृष्ठ पर क्लिक करने वाले उपयोगकर्ताओं की बड़ी संख्या है, तो यह हर अनुरोध के लिए डेटाबेस के माध्यम से सभी तरह से नहीं जाने का एहसास है। इसके बजाय, आप विभिन्न स्तरों पर कैशिंग का सहारा लेते हैं।

ResultSet कैश

ResultSet कैशिंग आवेदन में क्वेरी के साथ एक डेटाबेस क्वेरी के परिणामों के भंडारण है। हर बार एक वेब पेज एक क्वेरी उत्पन्न करता है, एप्लिकेशन जांचता है कि परिणाम पहले ही कैश किए गए हैं या नहीं, और यदि वे हैं, तो उन्हें बजाय इन-मेमोरी डेटा सेट से खींचता है। एप्लिकेशन को अभी भी पृष्ठ प्रस्तुत करना है।

घटक कैश

एक वेब पेज विभिन्न घटकों के शामिल है - pagelets, या जो भी आप उन्हें फोन कर सकते हैं। एक घटक कैशिंग रणनीति को पता होना चाहिए कि घटक का अनुरोध करने के लिए किन पैरामीटर का उपयोग किया गया था। उदाहरण के लिए, साइट पर एक छोटी "नवीनतम समाचार" बार उपयोगकर्ता के भौगोलिक स्थान या स्थानीय समाचार दिखाने के लिए प्राथमिकता का उपयोग करती है। नतीजतन, यदि किसी स्थान के लिए समाचार कैश किया गया है, तो घटक को प्रस्तुत करने की आवश्यकता नहीं है और इसे कैश से खींचा जा सकता है।

पृष्ठ कैश संपूर्ण पृष्ठों कैशिंग के लिए

एक रणनीति क्वेरी स्ट्रिंग और/या शीर्ष लेख पैरामीटर पूरी तरह से renderered एचटीएमएल के साथ स्टोर करने के लिए है। फ़ाइल सिस्टम इसके लिए पर्याप्त तेज़ है - वेब सर्वर के लिए फ़ाइल को पढ़ने के लिए एप्लिकेशन सर्वर पर कॉल करने के बजाय फ़ाइल को पढ़ने के लिए यह अभी भी कम महंगा है। इस मामले में, प्रत्येक उपयोगकर्ता जो एक ही क्वेरी स्ट्रिंग भेजता है उसे उसी कैश की गई सामग्री मिल जाएगी।

बुद्धिमानी से इन कैशिंग रणनीतियों को जोड़ना बड़ी संख्या में समवर्ती उपयोगकर्ताओं के लिए वास्तव में स्केलेबल वेब ऐप्स बनाने का एकमात्र तरीका है। जैसा कि आप आसानी से देख सकते हैं, यहां संभावित जोखिम यह है कि यदि कैश में सामग्री का एक टुकड़ा इसकी कुंजी द्वारा विशिष्ट रूप से पहचाना नहीं जा सकता है, तो लोग गलत सामग्री देखना शुरू कर देंगे। यह बहुत जटिल हो सकता है, खासकर जब उपयोगकर्ताओं के सत्र होते हैं और सुरक्षा संदर्भ होता है।