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

डेटाबेस कैश का उपयोग करने का विचार अनुत्पादक लग सकता है। फिर भी, रेल्स में सॉलिड कैश जैसे धीमे डेटाबेस-समर्थित कैश का उपयोग करना counterintuitively एक एप्लिकेशन को तेज कर सकता है क्योंकि सस्ता स्टोरेज हमें अधिक चीजों को लंबी अवधि के लिए कैश करने की अनुमति देता है। रेल्स 7.1 में, सॉलिड कैश पेश किया गया था, जिससे डेटाबेस-समर्थित एप्लिकेशन कैश एक रेल्स एप्लिकेशन के लिए एक सुविधाजनक विकल्प बन गया!
रेल्स कैश कैसे काम करता है
रूबी ऑन रेल्स में कैशिंग एप्लिकेशन प्रदर्शन को अनुकूलित करने का एक महत्वपूर्ण हिस्सा है। डेवलपर्स प्रदर्शन बढ़ाने के लिए कई प्रकार के कैशिंग का उपयोग कर सकते हैं: पेज कैशिंग, एक्शन कैशिंग, फ्रैगमेंट कैशिंग, लो-लेवल कैशिंग, SQL कैशिंग, और बहुत कुछ। इस लेख में, हम ज्यादातर लो-लेवल कैशिंग पर चर्चा करेंगे, क्योंकि यह सीधा है और कॉन्फ़िगरेबल cache_store के साथ संगत है।
ActiveSupport, रेल्स फ्रेमवर्क का एक बड़ा हिस्सा, हमें cache_store के माध्यम से कैश के साथ बातचीत और कॉन्फ़िगर करने की अनुमति देता है। config/environments/ में, विभिन्न कॉन्फ़िगरेशन के साथ प्रत्येक एनवायरनमेंट नाम की फाइलें होती हैं, जिसमें cache_store का विकल्प शामिल है।
cache_store मान सेट करना
Redis एक अविश्वसनीय रूप से लोकप्रिय कैश स्टोर है और उद्योग में व्यापक रूप से अपनाया गया है। यदि कोई एप्लिकेशन प्रोडक्शन में कैशिंग के लिए Redis का उपयोग कर रहा है, तो आपको config/environments/production.rb में रूबी की निम्नलिखित लाइन दिखाई देगी:
config.cache_store = :redis_cache_store
Redis का उपयोग इसलिए किया जाता है क्योंकि यह एक मेमोरी कैश है, और मेमोरी में पारंपरिक रूप से डिस्क एक्सेस या डेटाबेस क्वेरी की तुलना में बहुत तेज रीड एक्सेस समय होता है।
रेल्स में डेटाबेस क्वेरी कैशिंग
आप एक महंगी डेटाबेस क्वेरी के परिणाम को स्टोर करने के लिए लो-लेवल कैशिंग का उपयोग कर सकते हैं जो डेटा लौटाता है जो अक्सर नहीं बदलता। यह ऐसा कुछ दिख सकता है:
Rails.cache.fetch("courses", expires_in: 12.hours) do Courses.all end
यदि आप Redis को कैश स्टोर के रूप में उपयोग कर रहे हैं, तो यह कोड पहले यह देखने के लिए जांच करेगा कि क्या कुंजी "courses" में पिछले 12 घंटों से कोई मान है। यदि हां, तो यह कोड ब्लॉक को निष्पादित किए बिना केवल उस मान को वापस कर देगा। यदि कैश में वह मान नहीं है, तो इसे "कैश मिस" कहा जाता है। एक कैश मिस इंटरप्रेटर को ब्लॉक निष्पादित करने, परिणाम को कैश में स्टोर करने, और फिर परिणाम वापस करने का कारण बनेगा।
रेल्स सॉलिड कैश क्या है?
ऊपर बताए गए कैशिंग पैटर्न प्रदर्शन लाभ प्रदान करता है क्योंकि मेमोरी एक्सेस, उदाहरण के लिए, API कॉल और डेटाबेस क्वेरी की तुलना में तेज है। हालांकि, मेमोरी महंगी है, और इसलिए सीमित है। क्योंकि मेमोरी सीमित है, हमें कैश में क्या स्टोर करते हैं और कितने समय के लिए इसे कम से कम करना होगा। आप मेमोरी में अपने कैश से बाहर निकलने के बिना अनिश्चित काल के लिए सब कुछ कैश नहीं कर सकते। कैशिंग से प्रदर्शन लाभ सभी ट्रेडऑफ के बारे में है। आप कुछ चीजों को कुछ समय के लिए कैश करते हैं ताकि आपको समय-गहन कार्यों को दोहराना न पड़े।
रेल्स 7.1 रिलीज सॉलिड कैश के साथ आई, ActiveRecord::Cache::Store के लिए एक विकल्प जो कैश स्टोर के लिए SQL डेटाबेस का उपयोग करता है। कैश से प्रत्येक रीड धीमा है, लेकिन प्रौद्योगिकी में प्रगति और कई डेटाबेस में अंतर्निहित मेमोरी कैश दोनों के लिए धन्यवाद, अंतर अभी भी फायदेमंद है।
कैश स्टोर के रूप में SQL डेटाबेस का उपयोग करने से आपको बहुत कम लागत पर कई गुना अधिक स्टोरेज मिलता है, जिससे आपका एप्लिकेशन लंबे समय तक अधिक डेटा कैश कर सकता है। Basecamp टीम ने एक लेख लिखा कि कैसे इसने उनके एप्लिकेशन को गति दी, जो counterintuitive लग सकता है।
आपको सॉलिड कैश कब उपयोग करना चाहिए?
जबकि Redis जैसे मेमोरी कैश आमतौर पर कैश से तेज रीड प्रदान करते हैं, सॉलिड कैश कई परिदृश्यों में उन विकल्पों का एक अच्छा विकल्प प्रस्तुत करता है।
यदि आपके एप्लिकेशन को बड़ी मात्रा में डेटा कैश करने की आवश्यकता है, तो इसे मेमोरी में स्टोर करना निषेधात्मक रूप से महंगा हो सकता है। सॉलिड कैश लागत के एक अंश पर बहुत बड़े कैश आकार की अनुमति देता है।
यदि आपका एप्लिकेशन कैश रिट्रीवल समय में कुछ मिलीसेकंड की संभावित वृद्धि के प्रति अत्यधिक संवेदनशील नहीं है, तो सॉलिड कैश प्रदर्शन और लागत के बीच एक उत्कृष्ट संतुलन प्रदान करता है। यदि आप संभावित विलंबता वृद्धि को सहन कर सकते हैं, तो सॉलिड कैश एक अच्छा समाधान है।
अलग से, उन सेटअप में जहां एक अलग Redis इंस्टेंस का प्रबंधन अव्यावहारिक है, सॉलिड कैश Redis का समर्थन करने की आवश्यकता के बिना कैशिंग को आपके मौजूदा डेटाबेस द्वारा नियंत्रित करने की अनुमति देकर डिप्लॉयमेंट को सरल बनाता है।
सॉलिड कैश की स्थापना
सॉलिड कैश रीडमी में इसे रेल्स एप्लिकेशन में पेश करने पर उपयोगी निर्देश हैं। पहले, अपने Gemfile में जेम जोड़ें:
gem "solid_cache"
अगला, Bundler के साथ इंस्टॉल करें:
bundle install
अगला, एक माइग्रेशन जोड़ें ताकि आपका डेटाबेस सॉलिड कैश के साथ काम करे। निम्नलिखित चलाएं:
bin/rails solid_cache:install:migrations
अंत में, जनरेटेड माइग्रेशन चलाएं:
bin/rails db:migrate
रेल्स ऐप में सॉलिड कैश लागू करना
मौजूदा कैश के लिए सॉलिड कैश की अदला-बदली आमतौर पर सीधी होती है। अपने एनवायरनमेंट कॉन्फ़िग में, जैसे config/environments/production.rb, cache_store सेटिंग को निम्नलिखित में बदलें:
config.cache_store = :solid_cache_store
सॉलिड कैश को अपने कैश स्टोर के रूप में उपयोग करना शुरू करने के लिए केवल यही आवश्यक है! यह अन्य सभी ActiveSupport::Cache::Store कॉन्फ़िगरेशन विकल्पों का समर्थन करता है, साथ ही डेटाबेस शार्डिंग या अन्य विशिष्ट आवश्यकताओं का समर्थन करने के लिए अतिरिक्त विकल्प भी।
आपको ध्यान देना चाहिए कि यह केवल प्रोडक्शन में कैश स्टोर को बदलता है, इसलिए यदि आप अन्य एनवायरनमेंट में परीक्षण करेंगे, तो आप वहां भी मान बदलना चाहेंगे।
क्या आप रेल्स में सॉलिड कैश पर स्विच करेंगे?
रेल्स 7.1 में सॉलिड कैश की शुरूआत रेल्स कैशिंग रणनीतियों की दुनिया में एक महत्वपूर्ण विकास था। यह समाधान एप्लिकेशन प्रदर्शन अनुकूलन पर एक नया दृष्टिकोण प्रदान करता है, Redis जैसे मेमोरी-आधारित कैश के लिए पारंपरिक प्राथमिकता को चुनौती देता है।
कैशिंग के लिए SQL डेटाबेस का लाभ उठाकर, सॉलिड कैश एप्लिकेशन को मेमोरी स्टोरेज की लागत और क्षमता द्वारा लगाई गई सीमाओं को पार करते हुए, विस्तारित अवधि के लिए अधिक मात्रा में डेटा स्टोर करने में सक्षम बनाता है। यह दृष्टिकोण न केवल प्रभावी ढंग से कैश की जा सकने वाली मात्रा को बढ़ाता है बल्कि संभावित रूप से और भी अधिक प्रदर्शन लाभ प्रदान करने की क्षमता रखता है।
कहा जा रहा है, स्विच करने का निर्णय आपके एप्लिकेशन की विशिष्ट आवश्यकताओं पर निर्भर करता है। यदि आपका एप्लिकेशन हाई-स्पीड कैशिंग से काफी लाभान्वित होता है और आपके पास Redis का समर्थन करने के लिए इंफ्रास्ट्रक्चर है, तो आपको सॉलिड कैश की आवश्यकता नहीं हो सकती है। हालांकि, यदि आप अपने स्टैक में एक और सर्विस जोड़े बिना बड़ी मात्रा में डेटा कैश करने का लागत-प्रभावी तरीका ढूंढ रहे हैं, तो सॉलिड कैश तलाशने लायक हो सकता है। भले ही आप सिर्फ Redis का समर्थन करने से बचना चाहते हों, सॉलिड कैश आपके ऐप के लिए पर्याप्त से अधिक अच्छा हो सकता है।
यदि आपने इस लेख का आनंद लिया, तो हनीबैजर न्यूज़लेटर के लिए साइन अप करें ताकि इस तरह के अधिक रूबी और रेल्स लेख आपके इनबॉक्स में प्राप्त हों।