How to choose between cache-aside, read-through, write-through, client-side, and distributed caching strategies जैसा कि हमने हाल ही में कहा है पोस्ट, हमें खुशी है कि Pekka Enberg ने लिखने का फैसला किया और हम इसके 3 अध्याय का समर्थन करने पर गर्व करते हैं। डेटा क्यों छिपाएं? लैटिनेशन के बारे में पूरी किताब Get the Latency Book Excerpt पीडीएफ Get the Latency Book Excerpt पीडीएफ Get the Latency Book Excerpt पीडीएफ इसके अलावा, पेकी ने सिर्फ उस पुस्तक से महत्वपूर्ण लेआउट्स साझा की (अब अनुरोध पर उपलब्ध है) Low Latency Apps के बारे में जानें चलते रहें हमारे पुस्तक का संक्षिप्त संस्करण Pekka के कैशिंग अध्याय से अधिक के साथ है. यह संपादक की अनुमति के साथ यहां पुनः प्रिंट किया गया है. लाटेंसी *मैं अपने एप्लिकेशन में कैशिंग जोड़ते समय, आपको पहले अपनी कैशिंग रणनीति पर विचार करना होगा, जो निर्धारित करता है कि कैश और आधारित बैकअप स्टोर, जैसे कि एक डेटाबेस या सेवा से पढ़ने और लिखने का तरीका कैसे होता है। दूसरे शब्दों में, जब आपकी एप्लिकेशन कैश से एक मूल्य देखती है, लेकिन मूल्य वहां नहीं है या समाप्त हो चुका है, तो कैशिंग रणनीति आदेश देती है कि यह आपकी एप्लिकेशन है या कैश जो बैकअप स्टोर से मूल्य प्राप्त करता है। Cache-Aside कैशिंग कैश-साइड कैशिंग शायद सबसे विशिष्ट कैशिंग रणनीति है जिसे आप सामना करेंगे. जब एक कैश हिट होता है, तो डेटा एक्सेस लाटेनेशन संचार लाटेनेशन द्वारा नियंत्रित होता है, जो आमतौर पर छोटा होता है, क्योंकि आप कैश सर्वर पर या यहां तक कि अपने एप्लिकेशन मेमोरी स्पेस में एक कैश प्राप्त कर सकते हैं। हालांकि, जब कैश मिस होता है, तो कैश-साइड कैशिंग के साथ, कैश एक निष्क्रिय स्टोर है जिसे एप्लिकेशन द्वारा अपडेट किया जाता है. अर्थात्, कैश बस एक मिस की रिपोर्ट करता है और एप्लिकेशन बैकअप स्टोर से डेटा प्राप्त करने और कैश को अपडेट करने के लिए जिम्मेदार है. चित्रा 1 कार्रवाई में कैश-साइड कैशिंग का एक उदाहरण दिखाता है. एक एप्लिकेशन एक कैश कुंजी द्वारा कैश से एक मूल्य को देखता है, जो डेटा निर्धारित करता है कि एप्लिकेशन रुचि रखता है. यदि कुंजी कैश में मौजूद है, तो कैश कुंजी से संबंधित मूल्य वापस देती है, जिसे एप्लिकेशन उपयोग कर सकता है. हालांकि, यदि कुंजी मौजूद नहीं है या कैश में समाप्त हो गया है, तो हमारे पास एक कैश मिस है, जिसे एप्लिकेशन को संभालना है. एप्लिकेशन बैकअप स्टोर से मूल्य की पूछताछ करता है और मूल्य को कैश में संग्रहीत करता है. मान लीजिए कि आप उपयोगकर्ता जानकारी कैश कर रहे हैं और खोज की कुंजी के रूप में उपयोगकर्ता आईडी का उपयोग कर रहे हैं. इस मामले में, एप्लिकेशन डेटाबेस से उपयोगकर्ता जानकारी को पढ़ने के लिए उपयोगकर्ता आईडी द्वारा एक पूछताछ चलाता है. डेटाबेस से लौटाया गया उपयोगकर्ता जानकारी फिर एक प्रारूप में परिवर्तित की जाती है जिसे आप कैश में संग्रहीत कर सकते हैं. फिर, कैश को कैश कुंजी के रूप में उपयोगकर्ता आईडी और मूल्य के रूप में जानकारी के साथ अद्यतन किया जाता है. उदाहरण के लिए, इस प्रकार की कैश करने का एक विशिष्ट तरीका यह है कि डेटाबेस से लौटाया गया उपयोगकर्ता जानकारी को JSON में परिवर्तित किया जाए और इसे कैश में संग्रहीत किया जाए. कैश-साइड कैशिंग लोकप्रिय है क्योंकि यह एक कैश सर्वर को सेट करना आसान है जैसे कि रेडीस और इसे डेटाबेस पूछताछ और सेवा प्रतिक्रियाओं को कैश करने के लिए उपयोग करना है. कैश-साइड कैशिंग के साथ, कैश सर्वर निष्क्रिय है और आपको यह जानने की आवश्यकता नहीं है कि आप किस डेटाबेस का उपयोग करते हैं या परिणाम कैश में कैप किए जाते हैं. यह आपकी एप्लिकेशन है जो सभी कैश प्रबंधन और डेटा परिवर्तन करता है. कई मामलों में, कैश-साइड कैशिंग अनुप्रयोग लाटेनता को कम करने का एक सरल और प्रभावी तरीका है. आप अपने आवेदन के पास कैश सर्वर में सबसे प्रासंगिक जानकारी रखकर डेटाबेस एक्सेस लाटेनता को छिपा सकते हैं. हालांकि, कैश-साइड कैशिंग भी समस्याग्रस्त हो सकती है यदि आपके पास डेटा स्थिरता या ताजापन आवश्यकताएं हैं. उदाहरण के लिए, यदि आपके पास कई समकक्ष पाठक हैं जो कैश में एक कुंजी की तलाश कर रहे हैं, तो आपको अपने आवेदन में समन्वय करना होगा कि आप समकक्ष कैश मिस कैसे संभालते हैं; अन्यथा, आप कई डेटाबेस एक्सेस और कैश अद्यतन के साथ समाप्त हो सकते हैं, जिसके परिणामस्वरूप बाद में कैश खोजें अलग-अलग मूल्यों को वापस कर सकती हैं। हालांकि, कैश-साइड कैशिंग के साथ, आप लेन-देन समर्थन खो देते हैं क्योंकि कैश और डेटाबेस एक-दूसरे को नहीं जानते हैं, और यह एप्लिकेशन की जिम्मेदारी है कि डेटा के लिए अद्यतनों को समन्वय करें. अंत में, कैश-साइड कैशिंग में महत्वपूर्ण शेव लेटेनशिप हो सकता है क्योंकि कुछ कैश खोजें कैश मिस पर डेटाबेस पढ़ने की लाटेनशिप का अनुभव करती हैं. यही है, हालांकि कैश हिट के मामले में, एक्सेस लाटेनशिप तेजी से होता है क्योंकि यह एक करीबी कैश सर्वर से आता है; कैश खोजें जो कैश मिस का अनुभव करती हैं, केवल डेटाबेस एक्सेस के रूप में तेजी से होती हैं. यही कारण है कि आपके डेट Caching के माध्यम से पढ़ना Read-through caching एक रणनीति है जहां, cache-side caching के विपरीत, cache एक सक्रिय घटक है जब cache miss होता है. जब cache miss होता है, तो एक read-through cache स्वचालित रूप से बैकअप स्टोर से कुंजी के लिए एक मूल्य को पढ़ने का प्रयास करता है. latency cache-side caching के समान है, हालांकि बैकअप स्टोर रिकॉर्डिंग latency बैकअप स्टोर से बैकअप स्टोर तक है, एप्लिकेशन से बैकअप स्टोर तक नहीं, जो आपके डिप्लोमा आर्किटेक्चर के आधार पर छोटा हो सकता है. चित्रा 2 एक कार्रवाई में एक पढ़ने के माध्यम से कैश का एक उदाहरण दिखाता है. एप्लिकेशन एक कुंजी पर एक कैश खोज करता है, और यदि एक कैश मिस होता है, तो कैश कुंजी के लिए मूल्य प्राप्त करने के लिए डेटाबेस में एक रीडिंग करता है. कैश फिर खुद को अपडेट करता है और एप्लिकेशन को मूल्य वापस करता है. एक एप्लिकेशन के दृष्टिकोण से, एक कैश मिस पारदर्शी है क्योंकि कैश हमेशा एक कुंजी वापस करता है यदि कोई मौजूद है, चाहे कोई कैश मिस हो या नहीं। Read-through कैशिंग को लागू करना अधिक जटिल है क्योंकि कैशिंग को बैकअप स्टोर को पढ़ने में सक्षम होना चाहिए, लेकिन इसे बैकअप के लिए डेटाबेस परिणामों को एक प्रारूप में परिवर्तित करने की भी आवश्यकता है. उदाहरण के लिए, यदि बैकअप स्टोर एक SQL डेटाबेस सर्वर है, तो आपको अपने डेटा मॉडल और प्रारूपों के बारे में अधिक जानने की आवश्यकता है क्योंकि कैशिंग आपके अनुप्रयोग तर्क के साथ अधिक जुड़ा हुआ है. हालांकि, चूंकि कैश अद्यतनों को समन्वय करता है और डेटाबेस को पढ़ने के माध्यम से कैशिंग के साथ पढ़ता है, इसलिए यह अनुप्रयोग को लेन-देन गारंटी दे सकता है और साथ-साथ कैश की कमी पर स्थिरता सुनिश्चित कर सकता है। बेशक, शेड लाटेनशिप का एक ही चेतावनी पढ़ने के माध्यम से कैश के लिए लागू होती है जैसा कि वे कैश-साइड कैश के लिए करते हैं. एक अपवाद: सक्रिय घटक के रूप में, पढ़ने के माध्यम से कैश, उदाहरण के लिए, अद्यतन पूर्व कैश के साथ लाटेनशिप को बेहतर ढंग से छिपा सकते हैं. यहां, कैश वैध रूप से मूल्य समाप्त होने से पहले कैश को अपडेट करता है - इसलिए जब कोई मूल्य कैश में है तो एप्लिकेशन से डेटाबेस एक्सेस लाटेनशिप को पूरी तरह से छिपाता है. Caching के माध्यम से लिखें cache-side और read-through caching cache-side caching के बारे में रणनीतियां हैं, लेकिन कभी-कभी आप भी चाहते हैं कि cache लिखने का समर्थन करे. ऐसे मामलों में, cache एक इंटरफ़ेस प्रदान करता है जो एक कुंजी के मूल्य को अपडेट करने के लिए अनुप्रयोग को कॉल कर सकता है. cache-side caching के मामले में, एप्लिकेशन एकमात्र है जो बैकअप स्टोर के साथ संवाद करता है और इसलिए cache को अपडेट करता है. हालांकि, read-through caching के साथ, लिखने के साथ निपटने के लिए दो विकल्प हैं: write-through और write-behind caching. लिखित-दर-सीखना एक रणनीति है जहां बैकअप स्टोर के लिए एक अद्यतन तुरंत प्रसारित होता है. जब भी एक कैश अद्यतन किया जाता है, तो कैश सिंक्रनाइज़ रूप से बैकअप स्टोर को कैश के साथ अद्यतन करता है. लिखित-दर-सीख की लिखित लाटेनता को बैकअप स्टोर के लिए लिखित लाटेनेशन द्वारा नियंत्रित किया जाता है, जो महत्वपूर्ण हो सकता है. चित्रा 3 में दिखाया गया है, एक एप्लिकेशन एक कुंजी और एक मूल्य जोड़ी के साथ कैश द्वारा प्रदान की गई इंटरफ़ेस का उपयोग करके एक कैश को अद्यतन करता है. कैश नए मूल्य के साथ अपनी स्थिति को अपडेट करता है, नए मूल्य के साथ डेटाबेस को अपडेट करता है और एप्लिकेशन को कैश अद्य Write-through कैशिंग का उद्देश्य कैशिंग और बैकअप स्टोरेज को सिंक्रनाइज़ करना है. हालांकि, गैर-ट्रांक्शन कैशिंग के लिए, कैशिंग और बैकअप स्टोरेज त्रुटियों की उपस्थिति में सिंक्रनाइज़ नहीं हो सकते हैं. उदाहरण के लिए, यदि लिखने के लिए कैशिंग सफल होता है, लेकिन बैकअप स्टोरेज को लिखने में विफलता होती है, तो दोनों सिंक्रनाइज़ नहीं हो जाएंगे. बेशक, एक लिखने के माध्यम से कैशिंग कुछ देर से व्यापार करके लेनदेन की गारंटी प्रदान कर सकता है ताकि यह सुनिश्चित किया जा सके कि कैशिंग और डेटाबेस दोनों अद्यतन हैं या नहीं। एक Reading-through Cache के रूप में, Write-through Caching का मानना है कि कैश डेटाबेस से कनेक्ट हो सकता है और एक कैश मूल्य को एक डेटाबेस पूछताछ में परिवर्तित कर सकता है. उदाहरण के लिए, यदि आप उपयोगकर्ता डेटा को कैश कर रहे हैं जहां उपयोगकर्ता आईडी कुंजी के रूप में कार्य करता है और एक JSON दस्तावेज़ मूल्य का प्रतिनिधित्व करता है, तो कैश को उपयोगकर्ता जानकारी के JSON प्रतिनिधित्व को एक डेटाबेस अद्यतन में बदलने में सक्षम होना चाहिए. लिखित कैशिंग के साथ, सबसे सरल समाधान अक्सर डेटाबेस में जेएसओएन को संग्रहीत करना है. लिखित कैशिंग का मुख्य नुकसान कैशिंग अद्यतनों से जुड़ा लाटेन है, जो मूल रूप से डेटाबेस कॉम लाटेन के बराबर है. यह महत्वपूर्ण हो सकता है. Caching के पीछे लिखने के पीछे की कैशिंग रणनीति तुरंत कैशिंग को अपडेट करती है, लिखने के माध्यम से कैशिंग के विपरीत, जो डेटाबेस अद्यतन को अपग्रेड करती है. दूसरे शब्दों में, लिखने के पीछे की कैशिंग के साथ, कैशिंग बैकअप स्टोर को अद्यतन करने से पहले कई अद्यतन स्वीकार कर सकती है, जैसा कि चित्र 4 में दिखाया गया है, जहां कैशिंग डेटाबेस को अद्यतन करने से पहले तीन कैशिंग अद्यतन स्वीकार करती है. एक लिखने के पीछे की कैश की लिखने की लंबी अवधि लिखने के पीछे की कैश की तुलना में कम है क्योंकि बैकअप स्टोर असंक्रोनिक रूप से अद्यतन किया जाता है. अर्थात्, कैश एप्लिकेशन के लिए लिखने को तुरंत पहचान सकता है, जिसके परिणामस्वरूप एक कम लंबी अवधि लिखना होता है, और फिर पृष्ठभूमि में बैकअप स्टोर अद्यतन करना होता है. हालांकि, लिखने के पीछे की कैश के नुकसान यह है कि आप लेनदेन समर्थन खो देते हैं क्योंकि कैश अब गारंटी नहीं दे सकता है कि कैश और डेटाबेस सिंक्रनाइज़ होते हैं. इसके अलावा, लिखने के पीछे की कैश अवधि को कम कर सकती है, जो गारंटी है कि आप डेटा नहीं खो देते हैं. यदि कै ग्राहक साइड कैशिंग एक क्लाइंट-साइड कैशिंग रणनीति का मतलब है कि आपके एप्लिकेशन के भीतर क्लाइंट परत पर कैशिंग है. हालांकि रेडीस जैसे कैशिंग सर्वर इन-मेमोरी कैशिंग का उपयोग करते हैं, एप्लिकेशन को रेडीस प्रोटोकॉल के माध्यम से कैशिंग तक पहुंचने के लिए नेटवर्क पर संचार करना होगा. यदि अनुप्रयोग एक डेटा सेंटर में चलने वाली सेवा है, तो कैश सर्वर कैश के लिए उत्कृष्ट है क्योंकि एक डेटा सेंटर के भीतर नेटवर्क दौर यात्रा तेजी से है, और कैश जटिलता कैश में है। क्लाइंट-साइड कैशिंग के साथ, पढ़ने के माध्यम से और लिखने के पीछे कैशिंग का संयोजन लेटेनियस के दृष्टिकोण से इष्टतम है क्योंकि दोनों पढ़ते और लिखते तेजी से हैं. बेशक, आपका क्लाइंट आमतौर पर डेटाबेस से सीधे कनेक्ट नहीं कर पाएगा, लेकिन इसके बजाय एक प्रॉक्सी या एक एपीआई सर्वर के माध्यम से डेटाबेस तक अप्रत्यक्ष रूप से पहुंचता है. क्लाइंट-साइड कैशिंग भी डेटाबेस पहुंच अप्रत्यक्ष परतों और लाटेनियस के कारण लेनदेन को गारंटी देना मुश्किल बनाता है. कई अनुप्रयोगों के लिए जिनके लिए कम लाटेनटी क्लाइंट-साइड कैशिंग की आवश्यकता होती है, पुनरावृत्ति के लिए स्थानीय-पहले दृष्टिकोण अधिक व्यावहारिक हो सकता है. लेकिन सरल पढ़ कैशिंग के लिए, क्लाइंट-साइड कैशिंग कम लाटेनता प्राप्त करने के लिए एक अच्छा समाधान हो सकता है. बेशक, क्लाइंट-साइड कैशिंग में भी एक समझौता है: यह एप्लिकेशन के मेमोरी खपत को बढ़ा सकता है क्योंकि आपको कैशिंग के लिए जगह की आवश्यकता होती है. वितरित Caching अब तक, हमने केवल कैशिंग के बारे में बात की है जैसे कि एक ही कैशिंग संस्करण मौजूद था. उदाहरण के लिए, आप PostgreSQL डेटाबेस से पूछताछ को कैशिंग करने के लिए एक एप्लिकेशन में कैशिंग या एक ही Redis सर्वर का उपयोग करते हैं. हालांकि, आपको अक्सर विभिन्न स्थानों पर भौगोलिक लाटेंशन को कम करने के लिए डेटा के कई प्रतियों की आवश्यकता होती है या आपके कार्य भार को समायोजित करने के लिए स्केल करें। इस तरह के वितरित कैशिंग के साथ, आपके पास कैशिंग के कई उदाहरण हैं जो स्वतंत्र रूप से या एक कैशिंग क्लस्टर में काम करते हैं। वितरित कैशिंग के साथ, आपके पास अनुप्रयोगों और विचारों के बारे में अध्याय 4 में चर्चा की गई कई समान जटिलताएं और विचार हैं और अध्याय 5 पार्टिशन के बारे में। वितरित कैशिंग के साथ, आप प्रत्येक उदाहरण पर सभी कैशिंग डेटा को फिट करना नहीं चाहते हैं, लेकिन इसके बजाय नोड्स के बीच विभाजित कैशिंग डेटा है। कुल मिलाकर, वितरित कैशिंग कैशिंग, विभाजन और पुनरावृत्ति के लाभों और समस्याओं का एक क्रॉससेक्शन है, इसलिए सावधान रहें यदि आप इसके साथ जा रहे हैं। *मैं पढ़ना जारी रखने के लिए, ScyllaDB से या . Download the 3-chapter लंबी अवधि मुफ्त Manning से पूरी किताब खरीदें Cynthia Dunlop के बारे में राय Cynthia ScyllaDB में सामग्री रणनीति के वरिष्ठ निदेशक है. वह 20 से अधिक वर्षों से सॉफ्टवेयर विकास और गुणवत्ता इंजीनियरिंग के बारे में लिख रहा है।
