रेडिस पर मेमकैच्ड के लिए उपयोग-मामले के रूप में आज मैं मुख्य कारण देख रहा हूं कि बेहतर मेमोरी दक्षता आपको सादे के साथ प्राप्त करने में सक्षम होना चाहिए HTML टुकड़े कैशिंग (या समान अनुप्रयोग)। यदि आपको अपनी वस्तुओं के विभिन्न क्षेत्रों को अलग-अलग मेमकैच्ड कुंजियों में संग्रहीत करने की आवश्यकता है, तो रेडिस हैश अधिक मेमोरी कुशल होने जा रहा है, लेकिन जब आपके पास बड़ी संख्या में कुंजी -> simple_string जोड़े हैं, तो memcached आपको प्रति आइटम अधिक आइटम देने में सक्षम होना चाहिए। मेगाबाइट।
अन्य बातें जो memcached के बारे में अच्छी बातें हैं:
- यह कोड का एक बहुत ही सरल टुकड़ा है, इसलिए यदि आपको इसके द्वारा प्रदान की जाने वाली कार्यक्षमता की आवश्यकता है, तो यह एक उचित विकल्प है जो मुझे लगता है, लेकिन मैंने इसे उत्पादन में कभी भी उपयोग नहीं किया।
- यह मल्टी-थ्रेडेड है, इसलिए यदि आपको सिंगल-बॉक्स सेटअप में स्केल करने की आवश्यकता है, तो यह एक अच्छी बात है और आपको केवल एक इंस्टेंस के साथ बात करने की आवश्यकता है।
मेरा मानना है कि कैश के रूप में रेडिस अधिक से अधिक समझ में आता है क्योंकि लोग बुद्धिमान कैशिंग की ओर बढ़ते हैं या जब वे रेडिस डेटा संरचनाओं के माध्यम से कैश्ड डेटा की संरचना को संरक्षित करने का प्रयास करते हैं।
Redis LRU और memcached LRU के बीच तुलना।
मेमकैच्ड और रेडिस दोनों वास्तविक एलआरयू निष्कासन नहीं करते हैं, लेकिन केवल उसी का अनुमान लगाते हैं।
Memcache निष्कासन प्रति-आकार वर्ग है और इसके स्लैब आवंटनकर्ता के कार्यान्वयन विवरण पर निर्भर करता है। उदाहरण के लिए यदि आप एक आइटम जोड़ना चाहते हैं जो किसी दिए गए आकार वर्ग में फिट बैठता है, तो memcached उस वर्ग में समाप्त हो चुकी/हाल ही में उपयोग नहीं की गई वस्तुओं को हटाने का प्रयास करेगा, इसके बजाय वस्तु क्या है, यह समझने के लिए वैश्विक प्रयास करने की कोशिश करेगा, भले ही इसकी size, जो सबसे अच्छा उम्मीदवार है।
इसके बजाय रेडिस एक उम्मीदवार के रूप में एक अच्छी वस्तु चुनने की कोशिश करता है जब maxmemory आकार वर्ग की परवाह किए बिना सभी वस्तुओं को देखते हुए, सीमा तक पहुँच जाती है, लेकिन केवल लगभग अच्छी वस्तु प्रदान करने में सक्षम है, न कि सर्वश्रेष्ठ वस्तु अधिक निष्क्रिय समय के साथ।
जिस तरह से रेडिस ऐसा करता है वह कुछ वस्तुओं का नमूना लेता है, जो सबसे लंबे समय तक निष्क्रिय (एक्सेस नहीं) होता है। चूंकि रेडिस 3.0 (वर्तमान में बीटा में) एल्गोरिथम में सुधार किया गया था और बेदखली में एक अच्छे उम्मीदवार पूल भी लेता है, इसलिए सन्निकटन में सुधार हुआ था। Redis दस्तावेज़ीकरण में आप विवरण और ग्राफ़ के विवरण के साथ पा सकते हैं कि यह कैसे काम करता है।
क्यों memcached में साधारण स्ट्रिंग -> स्ट्रिंग मैप के लिए Redis की तुलना में बेहतर मेमोरी फ़ुटप्रिंट है।
रेडिस सॉफ्टवेयर का एक अधिक जटिल टुकड़ा है, इसलिए रेडिस में मूल्यों को उच्च स्तरीय प्रोग्रामिंग भाषा में वस्तुओं के समान तरीके से संग्रहीत किया जाता है:उनके पास स्मृति प्रबंधन के लिए संबंधित प्रकार, एन्कोडिंग, संदर्भ गणना है। यह रेडिस की आंतरिक संरचना को अच्छा और प्रबंधनीय बनाता है, लेकिन मेम्केड की तुलना में एक ओवरहेड है जो केवल स्ट्रिंग्स से संबंधित है।
जब Redis अधिक मेमोरी कुशल होने लगे
रेडिस एक विशेष मेमोरी सेविंग तरीके से छोटे कुल डेटा प्रकारों को स्टोर करने में सक्षम है। उदाहरण के लिए, किसी वस्तु का प्रतिनिधित्व करने वाला एक छोटा रेडिस हैश आंतरिक रूप से हैश तालिका के साथ नहीं, बल्कि एक बाइनरी अद्वितीय ब्लॉब के रूप में संग्रहीत किया जाता है। इसलिए प्रति ऑब्जेक्ट एकाधिक फ़ील्ड को हैश में सेट करना एन से अलग की गई कुंजियों को मेम्केड में संग्रहीत करने से अधिक कुशल है।
वास्तव में, आप किसी ऑब्जेक्ट को एक JSON (या बाइनरी-एन्कोडेड) ब्लॉब के रूप में मेमकैच्ड में स्टोर कर सकते हैं, लेकिन रेडिस के विपरीत, यह आपको स्वतंत्र फ़ील्ड लाने या अपडेट करने की अनुमति नहीं देगा।
बुद्धिमान कैशिंग के संदर्भ में Redis का लाभ।
रेडिस डेटा संरचनाओं के कारण, कैश के अमान्य होने पर वस्तुओं को नष्ट करने के मेमकैच्ड के साथ उपयोग किया जाने वाला सामान्य पैटर्न, बाद में डीबी से इसे फिर से बनाने के लिए, रेडिस का उपयोग करने का एक आदिम तरीका है।
उदाहरण के लिए, कल्पना करें कि साइट के "नवीनतम" खंड को पॉप्युलेट करने के लिए आपको हैकर समाचार में पोस्ट की गई नवीनतम एन समाचार को कैश करने की आवश्यकता है। रेडिस के साथ आप जो करते हैं वह नवीनतम समाचार डालने के साथ एक सूची (एम आइटम तक सीमित) लेना है। यदि आप अपने डेटा के लिए किसी अन्य स्टोर का उपयोग करते हैं, और Redis को कैश के रूप में उपयोग करते हैं, तो आप दोनों को पॉप्युलेट करने के लिए क्या करते हैं विचार (रेडिस और डीबी) जब कोई नया आइटम पोस्ट किया जाता है। कोई कैश अमान्य नहीं है।
हालांकि एप्लिकेशन में हमेशा तर्क हो सकते हैं ताकि यदि रेडिस सूची खाली पाई जाए, उदाहरण के लिए स्टार्टअप के बाद, प्रारंभिक दृश्य डीबी से फिर से बनाया जा सकता है।
बुद्धिमान कैशिंग का उपयोग करके मेमकैच की तुलना में रेडिस के साथ अधिक कुशल तरीके से कैशिंग करना संभव है, लेकिन सभी समस्याएं इस पैटर्न के लिए उपयुक्त नहीं हैं। उदाहरण के लिए HTML फ़्रैगमेंट कैशिंग इस तकनीक से लाभान्वित नहीं हो सकता है।
