कैश अमान्य होने पर

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

पूर्णता और अतिरेक

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

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

घटना अमान्य

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

हम घटनाओं का उपयोग करेंगे - मॉडल को बचाने / हटाने के लिए ORM घटनाओं को उत्पन्न करेगा, और कुछ को कैशिंग करते समय, हम तुरंत हैंडलर को उसी घटना पर लटकाएंगे जो इसे कैश से निकालता है। सब कुछ ठीक है, हालांकि, बड़ी संख्या में समान हैंडलर लिखना थकाऊ है, साथ ही आवेदन तर्क एक मोटे सुअर की तरह कैशिंग / अमान्य तर्क के साथ अतिरंजित है।

ORM अनुरोधों का स्वचालित अमान्यकरण

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

एक छोटा सा उदाहरण। मान लें कि हम एक अनुरोध निष्पादित करते हैं:

select * from post where category_id =2 and published


और इसे कैश करें। जाहिर है, हमें किसी पोस्ट को जोड़ने / अपडेट / डिलीट करते समय, उस स्थिति को रीसेट करने / अपडेट करने की आवश्यकता होती है, जब हालत category_id=2 and published=true अपने पुराने या नए संस्करण के लिए पूरी होती है। कुछ समय बाद, प्रत्येक मॉडल के लिए इनवैलिड की सूची बनाई जाती है, जिनमें से प्रत्येक अनुरोधों की एक सूची संग्रहीत करता है जिसे रीसेट किया जाना चाहिए:

post:
category_id =2 and published = true :
select * from post where category_id =2 and published
select count ( * ) from post where category_id =2 and published
select * from post where category_id =2 and published limit 20
category_id =3 and published = true :
select * from post where category_id =3 and published limit 20 offset 20
category_id =3 and published = false :
select count ( * ) from post where category_id =3 and not published
foo:
a =1 or b =10 :
or_sql
a in ( 2 , 3 ) and b =10 :
in_sql
a >1 and b =10 :
gt_sql


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

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

जाहिर है, यह किसी भी तरह से समूह और आवश्यक है विकलांग लोगों को उनके पूर्ण सत्यापन के बिना। ध्यान दें कि जब स्थितियां केवल मूल्यों में भिन्न होती हैं। उदाहरण के लिए, पोस्ट मॉडल में सभी अक्षम लोगों के पास सभी प्रकार की श्रेणी_आईडी = है? और प्रकाशित =? .. विकलांग लोगों को योजनाओं के अनुसार समूह से जोड़ें:

post:
category_id =? and published =? :
2 , true :
select * from post where category_id =2 and published
select count ( * ) from post where category_id =2 and published
select * from post where category_id =2 and published limit 20
3 , true :
select * from post where category_id =3 and published limit 20 offset 20
3 , false :
select count ( * ) from post where category_id =3 and not published
foo:
a =? or b =? :
1 , 10 :
or_sql
a in ? and b =? :
( 2 , 3 ), 10 :
in_sql
a > ? and b =? :
1 , 10 :
gt_sql


हालत पर ध्यान दें category_id =? और प्रकाशित = ?, जोड़ा पोस्ट के क्षेत्रों के मूल्यों को जानने के बाद, हम लेबल में ""? यदि वस्तु:

{id : 42 , title : "…" , content : "…" , category_id : 2 , published : true }


, तो परिवार से एकमात्र उपयुक्त अमान्य श्रेणी_आईडी = 2 और प्रकाशित = सत्य होगा, और इसलिए आपको इसके अनुरूप 3 कैश कुंजी को मिटाने की आवश्यकता है। यानी शर्तों की एक सुसंगत जांच की आवश्यकता नहीं है, हम तुरंत योजना और ऑब्जेक्ट के डेटा के अनुसार आवश्यक अमान्य प्राप्त करते हैं।

हालांकि, अधिक कठिन परिस्थितियों के साथ क्या करना है? कुछ मामलों में, कुछ किया जा सकता है: या दो अमान्य में विभाजित, में तैनात या। अन्य मामलों में, या तो आपको चीजों को जटिल करना होगा, या ऐसी शर्तों को त्यागकर अमान्य निरर्थक बनाना होगा। इन परिवर्तनों के बाद foo के लिए विकलांगता क्या होगी:

foo:
a = ? :
1 : or_sql
b = ? :
10 : or_sql, gt_sql
a = ? and b = ? :
2 , 10 : in_sql
3 , 10 : in_sql


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

मैं फू के लिए अमान्य प्रक्रिया का एक उदाहरण दूंगा। मान लीजिए हमने डेटाबेस से ऑब्जेक्ट {id : 42 , a : 1 , b : 10 }
अनुरोध किया है {id : 42 , a : 1 , b : 10 }
2 के मान को बदल दिया और वापस लिख दिया। अद्यतन करते समय, अमान्य प्रक्रिया को ऑब्जेक्ट की पुरानी और नई स्थिति दोनों के लिए चलाया जाना चाहिए। तो, पुराने राज्य के लिए अमान्य: a =1 , b =10 , a =1 and b =10 , संबंधित कुंजियाँ or_sql और gt_sql (अंतिम अमान्य अनुपस्थित है, खाली माना जा सकता है)। नए राज्य के लिए, हमें अमान्य a =2 , b =10 , a =2 and b =10 मिलते हैं, जो in_sql कुंजी जोड़ता है। परिणामस्वरूप, सभी 3 अनुरोध मिट जाते हैं।

कार्यान्वयन

मैंने भाषा और मंच से खुद को अलग करने की यथासंभव कोशिश की, हालाँकि, एक भरी हुई परियोजना में काम करने और काम करने की प्रणाली भी मौजूद है। इसके बारे में अधिक जानकारी और अगले लेख में सामान्य रूप से कार्यान्वयन के गुर।