<पी> कैशिंग की अवधारणा कंप्यूटर विज्ञान में एक महत्वपूर्ण है और वेब ऐप्स के निर्माण के लिए सीधे प्रासंगिक है। उच्च स्तर पर, कैशिंग इस तथ्य का लाभ उठाती है कि मेमोरी लुकअप डेटाबेस क्वेरीज़ की तुलना में तेज़ और कम गणना-गहन है। यदि आपके पास एक डेटाबेस क्वेरी है जो बार-बार की जा सकती है, तो परिणाम को कैश में कैश करने से निष्पादन का प्रवाह तेज हो जाता है। रेल एप्लिकेशन कोई अपवाद नहीं हैं क्योंकि वे अक्सर डेटा को कैश करने और एप्लिकेशन के प्रदर्शन को बेहतर बनाने के लिए रेडिस जैसे मेमोरी-आधारित कैश का उपयोग करते हैं। <पी> 
<पी> डेटाबेस कैश का उपयोग करने का विचार अनुत्पादक लग सकता है। फिर भी, रेल्स में सॉलिड कैश जैसे धीमे डेटाबेस-समर्थित कैश का उपयोग करने से किसी एप्लिकेशन की गति तेज हो सकती है क्योंकि सस्ता स्टोरेज हमें लंबी अवधि के लिए अधिक चीजों को कैश करने की अनुमति देता है। रेल्स 7.1 में, सॉलिड कैश पेश किया गया, जिससे डेटाबेस-समर्थित एप्लिकेशन कैश रेल एप्लिकेशन के लिए एक सुविधाजनक विकल्प बन गया! रेल कैश कैसे काम करता है
<पी> रूबी ऑन रेल्स में कैशिंग एप्लिकेशन प्रदर्शन को अनुकूलित करने का एक महत्वपूर्ण हिस्सा है। प्रदर्शन को बेहतर बनाने के लिए डेवलपर्स कई प्रकार के कैशिंग का उपयोग कर सकते हैं:पेज कैशिंग, एक्शन कैशिंग, फ्रैगमेंट कैशिंग, लो-लेवल कैशिंग, एसक्यूएल कैशिंग और बहुत कुछ। इस लेख में, हम अधिकतर निम्न-स्तरीय कैशिंग पर चर्चा करेंगे, क्योंकि यह सीधा और कॉन्फ़िगर करने योग्य cache_store के साथ संगत है। . <पी> ActiveSupport, रेल्स फ्रेमवर्क का एक बड़ा हिस्सा है, जो हमें cache_store के माध्यम से कैश के साथ इंटरैक्ट करने और कॉन्फ़िगर करने की अनुमति देता है। . config/environments/ में , कैश_स्टोर की पसंद सहित विभिन्न कॉन्फ़िगरेशन में प्रत्येक पर्यावरण नाम वाली फ़ाइलें हैं। कैश_स्टोर मान सेट करना
<पी> रेडिस एक अविश्वसनीय रूप से लोकप्रिय कैश स्टोर है और इसे पूरे उद्योग में व्यापक रूप से अपनाया गया है। यदि कोई एप्लिकेशन उत्पादन में कैशिंग के लिए रेडिस का उपयोग कर रहा है, तो आपको config/environments/production.rb में रूबी की निम्न पंक्ति दिखाई देगी : config.cache_store = :redis_cache_store
<पी> रेडिस का उपयोग इसलिए किया जाता है क्योंकि यह एक मेमोरी कैश है, और मेमोरी में पारंपरिक रूप से डिस्क एक्सेस या डेटाबेस क्वेरी की तुलना में पढ़ने का एक्सेस समय बहुत तेज होता है। रेल में डेटाबेस क्वेरी को कैश करना
<पी> हो सकता है कि आप एक महंगी डेटाबेस क्वेरी के परिणाम को संग्रहीत करने के लिए निम्न-स्तरीय कैशिंग का उपयोग कर रहे हों जो ऐसा डेटा लौटाता है जो अक्सर बदलता नहीं है। यह कुछ इस तरह दिख सकता है: Rails.cache.fetch("courses", expires_in: 12.hours) do
Courses.all
end
<पी> यदि आप कैश स्टोर के रूप में रेडिस का उपयोग कर रहे हैं, तो यह कोड पहले यह देखेगा कि कुंजी "पाठ्यक्रम" का पिछले 12 घंटों से कोई मूल्य है या नहीं। यदि ऐसा होता है, तो यह कोड ब्लॉक निष्पादित किए बिना बस वह मान लौटा देगा। यदि कैश में वह मान नहीं है, तो इसे "कैश मिस" कहा जाता है। कैश मिस होने के कारण दुभाषिया ब्लॉक को निष्पादित करेगा, परिणाम को कैश में संग्रहीत करेगा और फिर परिणाम लौटाएगा। रेल सॉलिड कैश क्या है?
<पी> ऊपर हमने जिस कैशिंग पैटर्न का अवलोकन किया, वह प्रदर्शन लाभ प्रदान करता है क्योंकि मेमोरी एक्सेस, उदाहरण के लिए, एपीआई कॉल और डेटाबेस क्वेरीज़ की तुलना में तेज़ है। हालाँकि,मेमोरी महंगी हैं , और इसलिए सीमित है। क्योंकि मेमोरी सीमित है, हमें कैश में क्या और कितनी देर तक स्टोर करना है, इसे कम करना होगा। आप अनिश्चित काल तक हर चीज़ को कैश नहीं कर सकते क्योंकि आपके कैश में मेमोरी जल्दी ही ख़त्म हो जाएगी। कैशिंग से प्रदर्शन लाभ पूरी तरह से ट्रेडऑफ़ के बारे में है। आप कुछ चीज़ों को कुछ समय के लिए कैश कर देते हैं ताकि आपको समय-गहन कार्यों को दोहराना न पड़े। <पी> रेल्स 7.1 रिलीज़ सॉलिड कैश के साथ आया, जो ActiveRecord::Cache::Store के लिए एक विकल्प है जो कैश स्टोर के लिए SQL डेटाबेस का उपयोग करता है। कैश से प्रत्येक रीड धीमा है, लेकिन प्रौद्योगिकी में प्रगति और कई डेटाबेस में अंतर्निहित मेमोरी कैश दोनों के लिए धन्यवाद, अंतर अभी भी फायदेमंद है। <पी> कैश स्टोर के रूप में SQL डेटाबेस का उपयोग करने से आपको कम लागत पर कई गुना अधिक स्टोरेज मिलता है, जिससे आपका एप्लिकेशन लंबी अवधि के लिए और भी अधिक डेटा कैश कर सकता है। बेसकैंप टीम ने इस बारे में एक लेख लिखा कि इससे उनके आवेदन में कितनी तेजी आई, जो उल्टा लग सकता है। आपको सॉलिड कैश का उपयोग कब करना चाहिए?
<पी> जबकि रेडिस जैसे मेमोरी कैश आमतौर पर कैश से तेजी से पढ़ने की पेशकश करते हैं, सॉलिड कैश कई परिदृश्यों में उन विकल्पों के लिए एक अच्छा विकल्प प्रस्तुत करता है। <पी> यदि आपके एप्लिकेशन को बड़ी मात्रा में डेटा को कैशिंग करने की आवश्यकता है, तो इसे मेमोरी में संग्रहीत करना अत्यधिक महंगा हो सकता है। सॉलिड कैश लागत के एक अंश पर बहुत बड़े कैश आकार की अनुमति देता है। <पी> यदि आपका एप्लिकेशन अतिरिक्त कैश पुनर्प्राप्ति समय के कुछ मिलीसेकंड के प्रति अत्यधिक संवेदनशील नहीं है, तो सॉलिड कैश प्रदर्शन और लागत के बीच एक उत्कृष्ट संतुलन प्रदान करता है। यदि आप विलंबता में संभावित वृद्धि को पचा सकते हैं, तो सॉलिड कैश एक अच्छा समाधान है। <पी> अलग से, उन सेटअपों में जहां एक अलग रेडिस इंस्टेंस को प्रबंधित करना अव्यावहारिक है, सॉलिड कैश रेडिस का समर्थन करने की आवश्यकता के बिना आपके मौजूदा डेटाबेस द्वारा कैशिंग को प्रबंधित करने की अनुमति देकर तैनाती को सरल बनाता है। सॉलिड कैश की स्थापना
<पी> सॉलिड कैश रीडमी के पास इसे रेल एप्लिकेशन में पेश करने के लिए उपयोगी निर्देश हैं। सबसे पहले, रत्न को अपने Gemfile में जोड़ें: gem "solid_cache"
<पी> इसके बाद, इसे बंडलर के साथ इंस्टॉल करें: 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 में सॉलिड कैश की शुरूआत ने रेल्स कैशिंग रणनीतियों की दुनिया में एक महत्वपूर्ण विकास को चिह्नित किया। यह समाधान रेडिस जैसे मेमोरी-आधारित कैश के लिए पारंपरिक प्राथमिकता को चुनौती देते हुए, एप्लिकेशन प्रदर्शन अनुकूलन पर एक नया दृष्टिकोण प्रदान करता है। <पी> कैशिंग के लिए SQL डेटाबेस का लाभ उठाकर, सॉलिड कैश अनुप्रयोगों को विस्तारित अवधि के लिए अधिक मात्रा में डेटा संग्रहीत करने में सक्षम बनाता है, जिससे मेमोरी स्टोरेज की लागत और क्षमता द्वारा लगाई गई सीमाओं पर काबू पा लिया जाता है। यह दृष्टिकोण न केवल प्रभावी रूप से कैश की जा सकने वाली चीज़ों की मात्रा को विस्तृत करता है, बल्कि इससे भी अधिक प्रदर्शन लाभ प्रदान करने की क्षमता रखता है। <पी> जैसा कि कहा गया है, स्विच करने का निर्णय आपके एप्लिकेशन की विशिष्ट आवश्यकताओं पर निर्भर करता है। यदि आपका एप्लिकेशन हाई-स्पीड कैशिंग से महत्वपूर्ण रूप से लाभान्वित होता है और आपके पास रेडिस का समर्थन करने के लिए बुनियादी ढांचा है, तो आपको सॉलिड कैश की आवश्यकता नहीं होगी। हालाँकि, यदि आप अपने स्टैक में कोई अन्य सेवा जोड़े बिना बड़ी मात्रा में डेटा को कैश करने का लागत प्रभावी तरीका ढूंढ रहे हैं, तो सॉलिड कैश तलाशने लायक हो सकता है। भले ही आप रेडिस का समर्थन करने से बचना चाहते हों, सॉलिड कैश आपके ऐप के लिए काफी अच्छा हो सकता है। <पी> यदि आपने इस लेख का आनंद लिया है, तो अपने इनबॉक्स में इस तरह के और अधिक रूबी और रेल्स लेख प्राप्त करने के लिए हनीबेजर न्यूज़लेटर के लिए साइन अप करें।
