सभी जानते हैं कि कैशिंग क्या है और इसकी आवश्यकता क्यों है। उपस्थिति बढ़ रही है, डेटाबेस पर भार बढ़ रहा है, और हम कैश से डेटा भेजने का निर्णय लेते हैं। एक आदर्श दुनिया में, संभवत: इसके लिए यह सेटिंग में USE_CACHE = True को सेटिंग में जोड़ने के लिए पर्याप्त होगा, लेकिन जब तक यह समय नहीं आ जाता, तब तक यह थोड़ा अधिक शरीर की गतिविधियों को ले जाएगा।

जब हम Django में कैश का उपयोग करने जा रहे हैं, तो हमें एक विकल्प बनाने की जरूरत है: एक तैयार समाधान लें जो पर्दे के पीछे सब कुछ करेगा, या हमारे अपने को लागू करेगा। कई अन्य स्थितियों के विपरीत, यह विकल्प यहां इतना स्पष्ट नहीं है, क्योंकि मौजूदा तैयार समाधानों में बहुत सारे प्रतिबंध और संभावित असुविधाएं हैं।

सबसे पहले, हम जल्दी से तैयार समाधानों को देखेंगे, और फिर हम यह पता लगाएंगे कि अपने दम पर कैशिंग को कैसे लागू किया जाए।

तैयार समाधान

हम djangopackages.com पर जाते हैं और देखते हैं कि हमें क्या खुशी मिलती है ।

जॉनी कैश

Mancatch Django क्वेरीज़ ताकि सभी ORM अनुरोध स्वचालित रूप से कैश हो जाएं। स्थापना यथासंभव सरल है: settings.py में कुछ नई लाइनें, अन्यथा सब कुछ समान रहता है, क्वेरी सिंटैक्स नहीं बदलता है। डेटा हमेशा के लिए कैश किया जाता है, परिवर्तनों पर अमान्य है।

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

Django कैश मशीन

ORM अनुरोध भी कैश किए गए हैं। केवल क्वेरीज़ को कैश किया जाता है, .get() जैसे अनुरोधों को कैश नहीं किया जाता है। इसके अलावा .values() और .values_list() । उपयोग के लिए, आपको मॉडल में एक मिश्रण और एक प्रबंधक जोड़ने की आवश्यकता है।

विकलांगता को यथोचित रूप से देखने की कोशिश करना। एक वस्तु को बदलते समय, केवल उन कैशे तत्वों को, जिसमें यह ऑब्जेक्ट शामिल है, को अमान्य कर दिया जाएगा ( ForeignKey और ManyToMany जैसे संबंधों को ध्यान में रखते हुए)।

Django-cachebot

स्वचालित रूप से सभी .get() अनुरोधों को कैश करता है। क्वेरी को कैश करने के लिए, आपको cache() विधि को कॉल करना होगा। अपने प्रबंधक का उपयोग करता है।

अक्षमता लगभग Django कैश मशीन के समान है। ManyToMany परिवर्तन द्वारा अक्षम नहीं किया गया।

कुल मिलाकर

Django कैश मशीन और Django-cachebot स्वीकार्य कार्य को हल करता है, जॉनी कैश विकलांगता में बहुत अंधाधुंध है, मैं इसकी सिफारिश नहीं करूंगा।

ऐसा लगता है कि आप ले सकते हैं और उपयोग कर सकते हैं, लेकिन कुछ चीजें हैं जिन्हें आपको याद रखने की आवश्यकता है।

• वस्तुतः विकलांगता पर कोई नियंत्रण नहीं है। बहुत बार इसकी जरूरत पड़ सकती है। उदाहरण के लिए, आपके पास लेखों (या किसी अन्य सामग्री) के साथ एक साइट है। लेखों की एक सूची के साथ एक पृष्ठ है, केवल शीर्ष लेख हैं, प्रत्येक लेख के लिए पृष्ठ हैं। क्या लेख सूची कैश को अमान्य करना आवश्यक है यदि कुछ लेख का पाठ बदलता है (शीर्षक समान रहता है)? बिल्कुल नहीं। लेकिन थर्ड-पार्टी एप्लिकेशन की तरह कुछ को समझाना बहुत मुश्किल है।
• लगभग सभी ऐप्स की कुछ सीमाएँ होती हैं। कोई व्यक्ति कैश एकत्रीकरण नहीं करता है, कोई कॉल .get() कॉल करता है, कोई कुछ मामलों में अमान्य नहीं करता है। यदि आपके पास अपने प्रोजेक्ट में ऐसी चीजें हैं, तो शायद तैयार समाधान का उपयोग करना सबसे अच्छा विकल्प नहीं है, क्योंकि आपको अभी भी बहुत कुछ खुद (या अपने आप) लिखना होगा।

यदि ऐसी चीजें आपको परेशान नहीं करती हैं, तो टर्नकी समाधान आपके लिए हैं। यदि किसी कारण से, आप अपने आप को कैशिंग लागू करना चाहते हैं, तो आगे बढ़ें।

खुद कर लो

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

हमें डेटा मिलता है

यहाँ सब कुछ सरल और स्पष्ट है:

  cached = cache.get('my_key') if cached is not None: return cached result = make_heavy_query() cache.set('my_key', result) return result 

प्रश्न : डेटा को हमेशा के लिए कैसे स्टोर करें (अनंत टाइमआउट)? ए : एक बैकएंड का उपयोग करता है जो इस का समर्थन करता है, उदा

प्रश्न : क्या होगा अगर मैं कैश में None स्टोर None करना चाहता? ए : प्रलेखन पढ़ें और पता लगाएं कि आप किसी के बजाय किसी भी मूल्य का उपयोग कर सकते हैं:

  cached = cache.get('my_key', -1) if cached != -1: # ... 

कैश से जुड़े कोड को कहां रखें?

मुख्य बात यह है कि इसे एक स्थान पर रखना है, न कि इसे पूरे प्रोजेक्ट में फैलाना है। मेरी (और केवल मेरी) राय में, सबसे उपयुक्त स्थान संगत मॉडल का प्रबंधक है। आप MyModel.objects को ओवरराइड कर सकते हैं, आप अन्य प्रकार के MyModel.cached को जोड़ सकते हैं।

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

  class Article(models.Model): # ... def get_tags(self): return Article.cached.tags_for_instance(self.id) 

डाटा कैसे स्टोर करें?

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

यदि आपको क्वेरी को कैश करना है, तो पहले इसे सूची में लाना बेहतर है। यह भी कैश किया जा सकता है, लेकिन यह Django के संस्करणों के बीच संगतता मुद्दों से प्रभावित हो सकता है।

यदि वस्तुओं की सूची अपेक्षाकृत छोटी है और शायद ही कभी बदलती है (उदाहरण के लिए, शहरों, संकायों, आदि की सूची) और तत्वों का क्रम महत्वपूर्ण नहीं है, तो आप इसे एक शब्दकोश के रूप में, इस रूप में संग्रहीत कर सकते हैं:

 dict((x.id, x) for x in MyModel.objects.all()) 

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

कभी-कभी यह समझ में नहीं आता है कि वस्तुओं की सूची नहीं, बल्कि केवल पहचानकर्ताओं की एक सूची है, लेकिन वस्तुओं को अपने कैश को दूसरे get_many अनुरोध के साथ प्राप्त करना है। प्लस: अमान्यकरण की आवश्यकता केवल तब होती है जब सूची आइटम की संरचना बदल जाती है, अर्थात कम बार। कम: कभी-कभी प्लस से कोई लाभ नहीं होता है। यहाँ, शायद, एक उदाहरण की आवश्यकता है। मान लीजिए हमारे पास "10 हाल के लेख" की एक सूची है। यदि आप केवल आईडी स्टोर करते हैं, तो आपको इस सूची को अमान्य करने की आवश्यकता है यदि साइट पर एक नया लेख जोड़ा जाता है या इस सूची से कुछ लेख हटा दिया जाता है। यदि आप वस्तुओं की पूरी सूची रखते हैं, तो आपको लेख में किसी भी बदलाव को अमान्य करने की आवश्यकता है (उदाहरण के लिए, एक टाइपो को सही किया गया था)। दूसरी ओर, यदि लेखों को बार-बार जोड़ा जाता है, तो यहां कोई लाभ नहीं होगा, इसलिए यह विधि हर जगह काम नहीं करेगी।

नाम कैसे रखें?

यदि हम साइट के लिए कुछ अनूठा संग्रहित करते हैं, उदाहरण के लिए, लेखों की एक सूची, तो हम आपकी पसंद के अनुसार कुंजी को नाम दे सकते हैं। उदाहरण के लिए, 'articles' । आपको हर बार, केवल एक बार एक अनोखा उपसर्ग जोड़ने की आवश्यकता नहीं है।

यदि कुंजी नाम ऑब्जेक्ट पर निर्भर करता है, तो आपको स्ट्रिंग प्रारूपण का उपयोग करने की आवश्यकता है। अक्सर ऐसा करते हैं: 'article::%d' । सब कुछ ठीक है, लेकिन बेहतर है: 'article::%(id)d' । पहले मामले में, "किसी तरह का पूरा", दूसरे में - एक पहचान। या 'tags_for::%d' और 'tags_for::%(article_id)d' । यदि यह वाक्यविन्यास आपको अजीब लगता है, तो यह निश्चित है ।

रद्द करना

विकलांगता संकेतों के साथ सबसे अच्छा किया जाता है। सिग्नल कोड को कहीं भी संग्रहीत किया जा सकता है, मुझे इसके लिए @staticmethod का मॉडल वर्ग पसंद है। विकलांगता अक्सर बहुत प्रभावी नहीं होती है। यहाँ एक विशिष्ट उदाहरण है:

  @receiver(post_save, sender=Article) @receiver(pre_delete, sender=Article) def invalidate(instance, **kwargs): cache.delete('article::%(id)d' % {'id': instance.id}) 

आखिरकार, आप बेहतर हो सकते हैं!

  @receiver(post_save, sender=Article) def on_change(instance, **kwargs): cache.set('article::%(id)d' % {'id': instance.id}, instance) @receiver(pre_delete, sender=Article) def on_delete(instance, **kwargs): cache.delete('article::%(id)d' % {'id': instance.id}) 

जब एक नए के साथ प्रतिस्थापित किया जा सकता है तो एक मूल्य क्यों हटाएं? हम क्वेरी को डेटाबेस में सहेजते हैं और डॉगपाइल प्रभाव के खिलाफ बीमा करते हैं। बेशक, अब आपको दो हैंडलर चाहिए: ऑब्जेक्ट को संशोधित करने और इसे हटाने के लिए। जब भी संभव हो ऐसा करना बेहतर है।

विकलांगता कईTMMany

प्रत्येक ManyToManyField को एक अतिरिक्त ManyToManyField लटका दिया जाना चाहिए। कुछ इस तरह:

  @receiver(m2m_changed, sender=Article.tags.through) def on_tags_changed(instance, **kwargs): # do update / invalidation 

कैशिंग ModelChoiceField और ModelMultipleChoiceField

Django के पास इन क्षेत्रों के लिए विकल्पों को कैश करने की कोई अंतर्निहित क्षमता नहीं है। तो, इस क्षेत्र के प्रत्येक प्रतिपादन डेटाबेस के लिए एक अनुरोध के लिए नेतृत्व करेंगे। आप मैन्युअल रूप से उन्हें ChoiceField और ChoiceField साथ बदल सकते हैं MultipleChoiceField क्रमशः (कुछ तर्क जोड़ सकते हैं), या आप मेरे छोटे अनुप्रयोग का उपयोग कर सकते हैं। Django 1.2-1.4 पर ठीक काम करता है। मैं यहां क्रूस पर नहीं चढ़ूंगा, सब कुछ लिंक पर वर्णित है।

कभी भी कैश की दृढ़ता पर भरोसा न करें!

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

  mylist = cache.get('mylist') mylist.append(value) cache.set('mylist', mylist) 

यह ऑपरेशन परमाणु नहीं है, अर्थात, इस बात की कोई गारंटी नहीं है कि दो ग्राहक एक ही समय में सूची नहीं बदलेंगे। और जब ऐसा होता है, तो आप एक रात की नींद बिताएंगे और पता लगाएंगे कि क्या मामला है और आपके पास गलत डेटा क्यों है। तो यह बेहतर है नहीं बेशक, आप उन कार्यों का उपयोग कर सकते हैं, जिनकी cache.incr() बैकएंड द्वारा गारंटी दी जाती है, उदाहरण के लिए, cache.incr() / cache.decr() लिए।

निष्कर्ष

यदि उपरोक्त में कुछ इष्टतम या गलत नहीं है, तो टिप्पणियों में लिखें, मैं लेख को सही करूंगा। वह अधिक उपयोगी हो जाएगा, और उसके पाठकों - खुश। आपका धन्यवाद