यदि आप एक बैकएंड डेवलपर हैं, तो जब भी आपको अपने वेब एप्लिकेशन को गति देने की आवश्यकता हो, कैशिंग एक आसान समाधान है। हालांकि, कैशिंग के बारे में बहुत कुछ है जो आपके वेब एप्लिकेशन के लिए सही कैशिंग रणनीति तय करते समय गायब हो जाता है। इसलिए, इस लेख में, हम उपलब्ध विभिन्न कैशिंग रणनीतियों पर चर्चा करेंगे और अपने उपयोग के मामले के लिए सही कैसे चुनें।
सरल शब्दों में, कैशिंग एक बफरिंग तकनीक है जहां हम अक्सर एक्सेस किए गए डेटा को अस्थायी मेमोरी या स्पेस में स्टोर करते हैं ताकि इसे आसानी से उपलब्ध कराया जा सके और हमारे एप्लिकेशन, सर्वर या डेटाबेस के लिए वर्कलोड को कम किया जा सके। इसे उपयोग के मामले के आधार पर वेब एप्लिकेशन में विभिन्न स्तरों पर लागू किया जा सकता है।
वेब एप्लिकेशन में विभिन्न स्तरों पर कैशिंग होती है जैसे कि निम्न:
एक सीडीएन का उपयोग भौगोलिक रूप से वितरित सर्वरों में स्थिर संपत्तियों (जैसे चित्र, वीडियो या वेबपेज) को कैश करने के लिए किया जाता है ताकि यह कैश का उपयोग करके अंतिम उपयोगकर्ता को सामग्री को तेजी से भेज सके।
एक सीडीएन को एक किराने की दुकान श्रृंखला के रूप में मानें: सैकड़ों किलोमीटर की यात्रा करने के बजाय जहां भोजन उगाया जाता है, खरीदार अपने स्थानीय किराना स्टोर पर जाते हैं, जिसे अभी भी कुछ यात्रा की आवश्यकता होती है, लेकिन यह काफी करीब है। किराने की खरीदारी में दिनों के बजाय मिनट लगते हैं क्योंकि किराने की दुकानें दूर के खेतों से भोजन का स्टॉक करती हैं। इसी तरह, सीडीएन इंटरनेट पर दिखाई देने वाली सामग्री को 'स्टॉक' करता है, जिससे वेबपेज काफी तेजी से लोड होते हैं।
जब कोई उपयोगकर्ता किसी वेबसाइट से किसी सामग्री का अनुरोध करने के लिए सीडीएन का उपयोग करता है, तो सीडीएन मूल सर्वर से सामग्री प्राप्त करता है और भविष्य के अनुरोधों के लिए सामग्री की एक प्रति रखता है। कैश्ड सामग्री को सीडीएन कैश में तब तक रखा जाता है जब तक उपयोगकर्ता इसे एक्सेस करना जारी रखते हैं।
डेटाबेस कैशिंग किसी भी डेटाबेस द्वारा उपयोग किए जाने वाले देशी स्मार्ट कैशिंग एल्गोरिदम को पढ़ने और लिखने को अनुकूलित करने के लिए संदर्भित करता है। इस मामले में, कैश डेटाबेस, एप्लिकेशन, या एक स्टैंडअलोन परत के रूप में कई क्षेत्रों में रह सकता है।
डेटाबेस कैशिंग का उपयोग सभी प्रकार के डेटा स्टोर के साथ किया जा सकता है, जिसमें NoSQL डेटाबेस के साथ-साथ रिलेशनल डेटाबेस जैसे SQL सर्वर - MySQL या MariaDB, आदि शामिल हैं। यह कई डेटा प्लेटफ़ॉर्म जैसे AWS और Microsoft Azure के साथ भी अच्छा काम करता है।
ब्राउज़र या क्लाइंट कैश एक्सपायरी हेडर के आधार पर स्टैटिक एसेट्स को स्टोर करते हैं। HTTP कैश हेडर निर्दिष्ट करते हैं कि ब्राउज़र अनुरोधित वेब सामग्री के लिए बाद में कैश प्रतिक्रियाओं को कब तक पूरा कर सकता है। साथ ही, ब्राउज़र अनावश्यक डेटा कॉल से बचने के लिए GET अनुरोधों की प्रतिक्रिया को कैश कर सकते हैं।
सर्वर कैशिंग सबसे अधिक ज्ञात और उपयोग किया जाने वाला कैशिंग तंत्र है जहां डेटा को सर्वर एप्लिकेशन में कैश किया जाता है। यहां चीजें व्यवसाय की जरूरतों पर बहुत निर्भर करती हैं, यह कम समवर्ती उपयोगकर्ताओं वाले अनुप्रयोगों के लिए अत्यधिक अनुकूलित है।
सर्वर-साइड वेब कैशिंग में अक्सर वेब सर्वर से वेब प्रतिक्रियाओं को पकड़ने के लिए वेब प्रॉक्सी का उपयोग करना शामिल होता है, जिसके सामने यह रहता है, उनके लोड और विलंबता को काफी कम करता है। ये कैश साइट व्यवस्थापकों द्वारा कार्यान्वित किए जाते हैं और ब्राउज़र और मूल सर्वर के बीच एक मध्यवर्ती एजेंट के रूप में कार्य करते हैं।
सर्वर-साइड कैशिंग का एक अन्य रूप मेमकैच्ड और रेडिस जैसे की-वैल्यू स्टोर्स का उपयोग करना है। इसके विपरीत, रिवर्स प्रॉक्सी के लिए, जो केवल एक विशिष्ट HTTP अनुरोध के लिए HTTP प्रतिक्रिया को कैश करता है, एप्लिकेशन डेवलपर द्वारा आवश्यक किसी भी वेब सामग्री को कुंजी/मूल्य ऑब्जेक्ट स्टोरेज का उपयोग करके कैश किया जा सकता है। वेब सामग्री अक्सर एक एप्लिकेशन कोड या एक एप्लिकेशन फ्रेमवर्क का उपयोग करके प्राप्त की जाती है जो इन-मेमोरी डेटा स्टोरेज का फायदा उठा सकती है।
ऑनलाइन कैशिंग के लिए कुंजी/मूल्य स्टोर को नियोजित करने का एक अन्य लाभ यह है कि उनका उपयोग अक्सर वेब सत्र और अन्य कैश्ड सामग्री को स्टोर करने के लिए किया जाता है। यह विभिन्न अनुप्रयोग स्थितियों के लिए एक एकीकृत समाधान देता है।
कैशिंग के कई लाभ हैं जिनका उल्लेख नीचे किया गया है:
जैसा कि हमने पहले चर्चा की थी, कैशे एक उच्च गति डेटा भंडारण परत है जो डेटा के एक सबसेट को संग्रहीत करता है जिसे अक्सर एक्सेस किया जाता है और आमतौर पर क्षणिक होता है, ताकि भविष्य के अनुरोधों को मूल भंडारण स्थान तक पहुंचने की तुलना में तेजी से परोसा जा सके। इस प्रकार, कैशिंग पहले से एक्सेस किए गए या गणना किए गए डेटा के कुशल पुन: उपयोग की अनुमति देता है। इसलिए, डेटा के पढ़ने/लिखने के संचालन में बड़ी मात्रा में कमी आती है और एप्लिकेशन के समग्र प्रदर्शन को बेहतर बनाने में मदद मिलती है।
एक एकल कैश इंस्टेंस प्रति सेकंड सैकड़ों हजारों इनपुट/आउटपुट संचालन प्रदान कर सकता है, इस प्रकार आवश्यक डेटाबेस इंस्टेंस की संख्या को कम करके कुल लागत को कम कर देता है। इसलिए, लागत बचत महत्वपूर्ण हो सकती है यदि भंडारण शुल्क प्रति थ्रूपुट हो।
कैशिंग बैकएंड सर्वर पर लोड को प्रभावी ढंग से कम कर सकता है और बैकएंड डेटाबेस से इन-मेमोरी कैशिंग लेयर पर रीड लोड के विशिष्ट भागों को पुनर्निर्देशित करके इसे धीमे प्रदर्शन से बचा सकता है। यह ट्रैफिक ओवरलोड या स्पाइक के समय सिस्टम को क्रैश होने से बचा सकता है।
आधुनिक अनुप्रयोगों के साथ एक आम चुनौती है जब अनुप्रयोग उपयोग में स्पाइक्स से निपटने की बात आती है। उदाहरण के लिए - दुनिया भर में तकनीकी कार्यक्रम, क्रिकेट मैच या चुनाव के दिन, या ईकामर्स वेबसाइट पर उत्सव की बिक्री आदि के दौरान सोशल मीडिया एप्लिकेशन पर स्पाइक। एप्लिकेशन पर लोड बढ़ने से डेटा प्राप्त करने में विलंब हो सकता है, इस प्रकार प्रदर्शन बना सकता है साथ ही उपयोगकर्ता अनुभव अप्रत्याशित। हालांकि, उच्च थ्रूपुट इन-मेमोरी कैश का उपयोग करके, हम इस समस्या को काफी हद तक कम कर सकते हैं।
डेटा का एक छोटा उपसमुच्चय, जैसे कि एक सेलिब्रिटी प्रोफ़ाइल या लोकप्रिय उत्पाद, कई अनुप्रयोगों में शेष की तुलना में अधिक बार पुनर्प्राप्त होने की संभावना है। यह आपके डेटाबेस में हॉटस्पॉट का कारण बन सकता है और सबसे अधिक उपयोग किए जाने वाले डेटा के लिए थ्रूपुट आवश्यकताओं के आधार पर डेटाबेस संसाधनों के अधिक प्रावधान की आवश्यकता हो सकती है। मेमोरी में सामान्य कुंजियों को संग्रहीत करने से सबसे अधिक बार उपयोग किए जाने वाले डेटा के लिए तेज़ और अनुमानित प्रदर्शन प्रदान करते हुए अधिक प्रावधान की आवश्यकता कम हो जाती है।
विलंबता को कम करने के अलावा, इन-मेमोरी सिस्टम समान डिस्क-आधारित डेटाबेस की तुलना में काफी अधिक अनुरोध दर प्रदान करते हैं। एक एकल वितरित साइड-कैश मशीन प्रति सेकंड सैकड़ों हजारों अनुरोधों को पूरा कर सकती है।
कैशिंग के लाभों पर चर्चा करने के बाद, आइए कुछ वास्तविक दुनिया के उपयोग के मामलों के साथ कैशिंग रणनीतियों में गोता लगाएँ। इस लेख में, हम मुख्य रूप से सर्वर-साइड कैशिंग रणनीतियों पर ध्यान केंद्रित करेंगे।
इस कैशिंग रणनीति में, कैश को तार्किक रूप से अलग रखा जाता है और एप्लिकेशन सीधे डेटाबेस या कैश के साथ संचार करता है ताकि यह पता चल सके कि अनुरोधित जानकारी मौजूद है या नहीं। सबसे पहले एप्लिकेशन कैश के साथ जांचता है, यदि जानकारी मिलती है, तो यह डेटा को पढ़ता है और लौटाता है, और इसे कैश हिट के रूप में जाना जाता है अन्यथा यदि जानकारी नहीं मिलती है, तो इसे कैश मिस के रूप में जाना जाता है, इस मामले में, एप्लिकेशन जानकारी को पढ़ने के लिए डेटाबेस से पूछताछ करता है और क्लाइंट को अनुरोधित डेटा लौटाता है, और फिर इसे भविष्य में उपयोग के लिए कैश में भी संग्रहीत करता है।
यह उन उपयोग के मामलों में अनिवार्य रूप से फायदेमंद है जो पढ़े-लिखे हैं। इसलिए, यदि कैश सर्वर डाउन है, तो सिस्टम डेटाबेस के साथ सीधे संचार करके ठीक से काम करेगा, लेकिन पीक लोड या स्पाइक्स के मामले में यह एक दीर्घकालिक या भरोसेमंद समाधान नहीं है जो अचानक हो सकता है।
सबसे आम लेखन रणनीति सीधे डेटाबेस में लिखना है, हालांकि, इससे बार-बार लिखने के मामले में डेटा असंगति हो सकती है। इस स्थिति से निपटने के लिए, डेवलपर्स अक्सर टीटीएल (टाइम टू लाइव) के साथ कैश का उपयोग करते हैं और इसकी समय सीमा समाप्त होने तक सेवा जारी रखते हैं।
यहां टीटीएल के साथ और उसके बिना कैश का त्वरित अवलोकन दिया गया है और उनका उपयोग कब करना है:
जब डेटा बार-बार अपडेट हो रहा होता है, तो TTL वाला कैश सबसे अधिक उपयोग किया जाने वाला कैश होता है। ऐसे मामलों में, आप चाहते हैं कि कैश नियमित अंतराल में समाप्त हो जाए, इसलिए, आप एक समय सीमा के साथ कैश का उपयोग कर सकते हैं और समय अंतराल बीत जाने के बाद कैश स्वचालित रूप से हटा दिया जाएगा।
उदाहरण के लिए - सर्वर सत्र या खेल स्कोरकार्ड।
टीटीएल के बिना कैश का उपयोग उन कैशिंग जरूरतों के लिए किया जाता है जिन्हें बार-बार अपडेट करने की आवश्यकता नहीं होती है, उदाहरण के लिए, पाठ्यक्रम प्रदान करने वाली वेबसाइट पर सामग्री। इस मामले में, सामग्री को बार-बार अपडेट या प्रकाशित किया जाएगा, और इसलिए बिना किसी समय सीमा के कैश करना बहुत आसान है।
जैसा कि नाम से पता चलता है, इस रणनीति में, किसी भी नई जानकारी को मुख्य मेमोरी/डेटाबेस से पहले कैश में लिखा जाता है। इस मामले में, कैश तार्किक रूप से एप्लिकेशन और डेटाबेस के बीच है। इसलिए, यदि कोई ग्राहक किसी जानकारी का अनुरोध करता है, तो एप्लिकेशन को जानकारी की उपलब्धता के लिए कैश से जांच करने की आवश्यकता नहीं है क्योंकि कैश में पहले से ही जानकारी है, और इस प्रकार, इसे सीधे कैश से पुनर्प्राप्त किया जाता है और क्लाइंट को परोसा जाता है।
हालाँकि, यह एक लेखन ऑपरेशन की विलंबता को बढ़ाता है। लेकिन अगर रीड-थ्रू कैश नामक एक अन्य कैशिंग रणनीति के साथ जोड़ा जाता है, तो हम डेटा की स्थिरता सुनिश्चित कर सकते हैं।
इस कैशिंग रणनीति में, कैश डेटाबेस के अनुरूप बैठता है जैसे कि किसी भी समय कैश मिस (डेटा कैश में नहीं पाया जाता है), लापता डेटा डेटाबेस से पॉप्युलेट हो जाता है और क्लाइंट को वापस कर दिया जाता है।
जैसा कि आपने अनुमान लगाया होगा, यह तैयार-भारी अनुप्रयोगों के लिए सबसे अच्छा काम करता है जैसे कि एक ही जानकारी का बार-बार अनुरोध किया जाता है। उदाहरण के लिए, एक समाचार वेबसाइट एक ही दिन के लिए एक ही कहानी परोस रही होगी।
इस रणनीति का नकारात्मक पक्ष यह है कि यदि पहली बार डेटा का अनुरोध किया जाता है, तो यह हमेशा कैश मिस होता है, और इस तरह यह सामान्य अनुरोध से धीमा हो जाएगा।
इस कैशिंग रणनीति में, जब भी कोई लेखन ऑपरेशन होता है, तो एप्लिकेशन कैश को जानकारी लिखता है जो तुरंत परिवर्तनों को स्वीकार करता है और कुछ देरी के बाद, यह डेटा को डेटाबेस में वापस लिखता है। इसे राइट-बैक कैशिंग रणनीति के रूप में भी जाना जाता है।
यह उन अनुप्रयोगों के लिए एक अच्छी कैशिंग रणनीति है जो अनुप्रयोग के लेखन प्रदर्शन में सुधार के लिए लेखन कार्यों पर भारी हैं। यह मध्यम डेटाबेस डाउनटाइम और उदाहरणों में होने वाली विफलताओं को समायोजित करने में भी मदद कर सकता है।
रीड-थ्रू कैश के साथ जोड़े जाने पर भी यह अच्छी तरह से काम कर सकता है। इसके अलावा, यदि बैचिंग समर्थित है, तो यह डेटाबेस पर लेखन कार्यभार को और कम कर सकता है। हालाँकि, नकारात्मक पक्ष यह है कि यदि कैश विफल हो जाता है, तो डेटा हमेशा के लिए खो सकता है। अधिकांश रिलेशनल डेटाबेस में, राइट-बैक कैशिंग तंत्र डिफ़ॉल्ट रूप से सक्षम होता है।
इस मामले में, डेटा सीधे डेटाबेस में लिखा जाता है और केवल पढ़ा गया डेटा कैश में संग्रहीत होता है।
इसे रीड-थ्रू कैश के साथ जोड़ा जा सकता है और उन स्थितियों में एक अच्छा विकल्प हो सकता है जहां डेटा एक बार लिखा जाता है और केवल कुछ ही बार पढ़ा जाता है। उदाहरण के लिए, जब रीयल-टाइम लॉग या चैट की आवश्यकता होती है।
इस लेख में, हमने चर्चा की कि कैशिंग क्या है और किसी एप्लिकेशन में कैशिंग के विभिन्न स्तर, और हमें इसकी आवश्यकता क्यों है। फिर, हमने सर्वर-साइड कैशिंग के लिए विभिन्न कैशिंग रणनीतियों पर भी चर्चा की। हालांकि, यह आवश्यक नहीं है कि इन कैशिंग रणनीतियों में से कोई भी आपके व्यावहारिक उपयोग के मामलों को पूरा कर सके, लेकिन सर्वोत्तम परिणामों के लिए इन रणनीतियों के संयोजन के लिए जाने की हमेशा अनुशंसा की जाती है।
इसके लिए नए डेवलपर के लिए, इसे कुछ परीक्षण और त्रुटि की आवश्यकता हो सकती है, या हम कह सकते हैं, व्यावहारिक अर्थों में अवधारणा की अधिक गहन समझ हासिल करने के लिए हिट या मिस कर सकते हैं और किसी विशेष उपयोग के मामले के लिए सर्वोत्तम समाधान के साथ आ सकते हैं।
इस लेख के लिए बस इतना ही, मुझे आशा है कि आपको यह मददगार लगा होगा। मुझे बताएं कि आप क्या सोचते हैं। आप मेरे साथ यहां जुड़ सकते हैं:
पढ़ते रहिये!