मेमकेड बनाम रेडिस?


1466

हम कैशिंग के लिए रेडिस सर्वर के साथ एक रूबी वेब-ऐप का उपयोग कर रहे हैं । क्या इसके स्थान पर मेमकेच का परीक्षण करने का कोई बिंदु है ?

क्या हमें बेहतर प्रदर्शन देगा? Redis और Memcached के बीच कोई पेशेवरों या विपक्ष?

घ्यान देने योग्य बातें:

  • पढ़ें / गति लिखें।
  • स्मृति उपयोग।
  • डिस्क I / O डंपिंग।
  • स्केलिंग।

38
नीचे दी गई टिप्पणियों के अलावा एक और विश्लेषण: Google ट्रेंड्स: रेडिस बनाम
मेमकाटेड

3
एक टिप्पणी जो एक उत्तर को वारंट नहीं करती है: यदि आप इन दो प्रणालियों (जैसे हिरोको एडोन) के लिए क्लाउड-आधारित सेवाओं को देख रहे हैं, तो कभी-कभी जो भी कारण से प्रति MB बहुत अधिक सस्ती होती हैं।
बेन रॉबर्ट्स

जवाबों:


2102

सारांश (TL, DR)

3 जून, 2017 को अपडेट किया गया

रेडिस अधिक शक्तिशाली है, अधिक लोकप्रिय है, और मेम्केड की तुलना में बेहतर समर्थित है। मेमकेच्ड केवल उन चीजों का एक छोटा सा हिस्सा कर सकता है जो रेडिस कर सकते हैं। जहां उनकी विशेषताएं ओवरलैप होती हैं, वहां भी रेडिस बेहतर है।

कुछ भी नया करने के लिए, Redis का उपयोग करें।

मेमकेच्ड बनाम रेडिस: डायरेक्ट कम्पेरिजन

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

घ्यान देने योग्य बातें

जब एक ही चीज़ के लिए उपयोग किया जाता है, तो यहां बताया गया है कि वे मूल प्रश्न के "पॉइंट टू विवेचन" का उपयोग कैसे करते हैं:

  • पढ़ें / लिखने की गति : दोनों बहुत तेज हैं। बेंचमार्क वर्कलोड, संस्करण और कई अन्य कारकों से भिन्न होता है, लेकिन आम तौर पर रेडिस को तेज या लगभग उपवास के रूप में दिखाया जाता है। मैं रेडिस की सलाह देता हूं, लेकिन इसलिए नहीं कि मेमकेड धीमा है। यह।
  • मेमोरी का उपयोग : रेडिस बेहतर है।
    • memcached: आप कैश आकार निर्दिष्ट करते हैं और जैसा कि आप आइटम सम्मिलित करते हैं डेमॉन जल्दी से इस आकार से थोड़ा अधिक बढ़ता है। वहाँ वास्तव में किसी भी जगह को पुनः प्राप्त करने का एक तरीका नहीं है, फिर से शुरू करने की कमी। आपकी सभी चाबियां समाप्त हो सकती हैं, आप डेटाबेस को फ्लश कर सकते हैं, और यह अभी भी रैम के पूर्ण चंक का उपयोग करेगा जिसे आपने इसे कॉन्फ़िगर किया था।
    • redis: अधिकतम आकार सेट करना आपके ऊपर है। रेडिस कभी भी इसका उपयोग करने से ज्यादा नहीं करेगा और आपको मेमोरी वापस दे देगा।
    • मैंने दोनों में यादृच्छिक वाक्यों के 100,000 ~ 2KB तार (~ 200MB) संग्रहीत किए। मेम्केड रैम का उपयोग ~ 225MB तक बढ़ गया। Redis RAM का उपयोग ~ 228MB हो गया। दोनों को फ्लश करने के बाद, रेडिस को ~ 29MB पर गिरा दिया गया और मेमक्श्ड ~ 225MB पर रुका रहा। वे समान रूप से कुशल हैं कि वे डेटा को कैसे स्टोर करते हैं, लेकिन केवल एक ही इसे पुनः प्राप्त करने में सक्षम है।
  • डिस्क I / O डंपिंग : रेडिस के लिए एक स्पष्ट जीत क्योंकि यह डिफ़ॉल्ट रूप से ऐसा करता है और इसमें बहुत ही टिकाऊ दृढ़ता है। 3 पार्टी उपकरण के बिना डिस्क को डंप करने के लिए मेमकेच्ड का कोई तंत्र नहीं है।
  • स्केलिंग : कैश के रूप में आपको एक से अधिक उदाहरण की आवश्यकता होने से पहले दोनों आपको टन के हेडरूम देते हैं। Redis में टूल शामिल हैं जो आपको उस पार जाने में मदद करते हैं जबकि मेमेकैक्ड नहीं है।

memcached

मेमकाटेड एक सरल अस्थिर कैश सर्वर है। यह आपको कुंजी / मूल्य जोड़े को संग्रहीत करने की अनुमति देता है जहां मूल्य 1MB तक एक स्ट्रिंग होने तक सीमित है।

यह इस पर अच्छा है, लेकिन यह सब करता है। आप अत्यधिक उच्च गति पर, अक्सर उपलब्ध नेटवर्क या यहां तक ​​कि मेमोरी बैंडविड्थ के द्वारा उन मूल्यों तक पहुँच सकते हैं।

जब आप पुनः आरंभ करते हैं तो आपका डेटा समाप्त हो जाता है। यह कैश के लिए ठीक है। आपको वहां कुछ भी महत्वपूर्ण स्टोर नहीं करना चाहिए।

यदि आपको उच्च प्रदर्शन या उच्च उपलब्धता की आवश्यकता है तो तीसरे पक्ष के उपकरण, उत्पाद और सेवाएं उपलब्ध हैं।

redis

रेडिस वही काम कर सकते हैं जो मेमेकैट्स कैन कर सकते हैं, और उन्हें बेहतर कर सकते हैं।

Redis कैश के रूप में भी कार्य कर सकता है । यह कुंजी / मूल्य जोड़े को भी स्टोर कर सकता है। रेडिस में वे 512MB तक के हो सकते हैं।

आप दृढ़ता को बंद कर सकते हैं और यह खुशी से आपके डेटा को पुनरारंभ पर भी खो देगा। यदि आप चाहते हैं कि आपका कैश पुनः आरंभ हो तो यह आपको ऐसा करने देता है। वास्तव में, यह डिफ़ॉल्ट है।

यह सुपर फास्ट भी है, अक्सर नेटवर्क या मेमोरी बैंडविड्थ द्वारा सीमित होता है।

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

द रेडिस सुपरसेट

रेडिस कैश से अधिक है। यह एक इन-मेमोरी डेटा स्ट्रक्चर सर्वर है। नीचे आपको उन चीजों का त्वरित अवलोकन मिलेगा जो रेडिस एक साधारण कुंजी / मूल्य कैश से परे कर सकते हैं जैसे कि मेम्केड। रेडिस की अधिकांश विशेषताएं ऐसी चीजें हैं जो मेमस्कैक्ड नहीं कर सकती हैं।

प्रलेखन

रेडिस मेमकेड की तुलना में बेहतर प्रलेखित है। जबकि यह व्यक्तिपरक हो सकता है, यह हर समय अधिक से अधिक सच लगता है।

redis.io एक शानदार आसानी से नेविगेट किया गया संसाधन है। यह आपको ब्राउज़र में रेडिस की कोशिश करने देता है और यहां तक ​​कि डॉक्स में प्रत्येक कमांड के साथ लाइव इंटरएक्टिव उदाहरण भी देता है।

अब मेम के रूप में रेडिस के लिए कई स्टैकओवरफ्लो परिणाम के रूप में 2x हैं। 2x के रूप में कई Google परिणाम। अधिक भाषाओं में अधिक सुलभ उदाहरण। अधिक सक्रिय विकास। अधिक सक्रिय ग्राहक विकास। इन मापों का व्यक्तिगत रूप से बहुत अधिक मतलब नहीं हो सकता है, लेकिन संयोजन में वे एक स्पष्ट तस्वीर चित्रित करते हैं जो रेडिस के लिए समर्थन और प्रलेखन अधिक और बहुत अधिक अप-टू-डेट है।

हठ

डिफ़ॉल्ट रूप से रेडिस स्नैपशॉटिंग नामक एक तंत्र का उपयोग करके आपके डेटा को डिस्क में बनाए रखता है। यदि आपके पास पर्याप्त रैम उपलब्ध है तो यह आपके सभी डेटा को डिस्क में लगभग कोई प्रदर्शन गिरावट के साथ लिखने में सक्षम है। यह लगभग मुफ्त है!

स्नैपशॉट मोड में एक मौका है कि अचानक दुर्घटना के कारण कम मात्रा में डेटा खो सकता है। यदि आपको पूरी तरह से सुनिश्चित करने की आवश्यकता है कि कोई भी डेटा कभी नहीं खो जाए, तो चिंता न करें, एआईओएफ के साथ भी आपकी पीठ में लाल रंग है। इस दृढ़ता मोड में डेटा को डिस्क में सिंक किया जा सकता है जैसा कि लिखा गया है। हालांकि यह आपकी डिस्क को लिखने के लिए तेजी से अधिकतम थ्रूपुट को कम कर सकता है, लेकिन फिर भी काफी तेज होना चाहिए।

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

कई डेटा प्रकार

Memcached स्ट्रिंग्स तक सीमित है, लेकिन Redis एक डेटा संरचना सर्वर है जो कई अलग-अलग डेटा प्रकारों की सेवा कर सकता है। यह उन आदेशों को भी प्रदान करता है जिन्हें आपको उन डेटा प्रकारों का अधिकतम उपयोग करने की आवश्यकता होती है।

स्ट्रिंग्स ( कमांड्स )

सरल पाठ या बाइनरी मान जो कि आकार में 512MB तक हो सकते हैं। यह एकमात्र डेटा प्रकार रेडिस और मेमकाटेड शेयर है, हालांकि मेमकाटेड तार 1 एमबी तक सीमित हैं।

Redis आपको बिटवाइट ऑपरेशंस, बिट-लेवल मैनिपुलेशन, फ्लोटिंग पॉइंट इंक्रीमेंट / डिक्रीमेंट सपोर्ट, रेंज क्वेरीज़ और मल्टी-की ऑपरेशंस के लिए कमांड देकर इस डेटाटाइप का लाभ उठाने के लिए अधिक टूल देता है। Memcached उस में से किसी का समर्थन नहीं करता है।

स्ट्रिंग्स सभी प्रकार के उपयोग मामलों के लिए उपयोगी होते हैं, यही वजह है कि मेमकाटेड इस डेटा प्रकार के साथ काफी उपयोगी है।

Hashes ( आदेश )

हाशियाँ कुंजी मूल्य स्टोर के भीतर एक कुंजी मूल्य स्टोर की तरह होती हैं। वे स्ट्रिंग फ़ील्ड और स्ट्रिंग मानों के बीच मैप करते हैं। फ़ील्ड-> हैश का उपयोग करने वाले मानचित्र, कुंजी के मूल्य से थोड़े अधिक स्पेस वाले होते हैं-> नियमित स्ट्रिंग्स का उपयोग करते हुए मूल्य मैप।

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

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

सूचियाँ ( आदेश )

रेडिस सूचियों को स्ट्रिंग्स के संग्रह का आदेश दिया जाता है। सूची के ऊपर या नीचे (उर्फ: बाएं या दाएं) से मान डालने, पढ़ने या हटाने के लिए उन्हें अनुकूलित किया जाता है।

Redis , लीवरेजिंग सूचियों के लिए कई कमांड प्रदान करता है, जिसमें पुश / पॉप आइटम, सूचियों के बीच पुश / पॉप, ट्रंक सूची, प्रदर्शन क्वेरीज़ आदि का आदेश शामिल है।

सूचियाँ महान टिकाऊ, परमाणु, कतार बनाती हैं। ये नौकरी की कतार, लॉग, बफ़र और कई अन्य उपयोग के मामलों के लिए बहुत अच्छा काम करते हैं।

समूह ( आदेश )

सेट अनूठे मूल्यों के अनियंत्रित संग्रह हैं। यदि आप सेट में कोई मान रखते हैं, तो वे आपको जल्दी से जांच करने के लिए अनुकूलित करते हैं, जल्दी से मान जोड़ें / निकालें, और अन्य सेटों के साथ ओवरलैप को मापने के लिए।

ये एक्सेस कंट्रोल लिस्ट, यूनीक विजिटर ट्रैकर्स और कई अन्य चीजों जैसी चीजों के लिए बेहतरीन हैं। अधिकांश प्रोग्रामिंग भाषाओं में कुछ समान है (आमतौर पर एक सेट कहा जाता है)। यह ऐसा ही है, केवल वितरित।

रेडिस सेट का प्रबंधन करने के लिए कई कमांड प्रदान करता है। स्पष्ट रूप से सेट को जोड़ना, हटाना और जांचना जैसे लोग मौजूद हैं। तो एक यादृच्छिक आइटम को पढ़ने / पढ़ने और अन्य सेटों के साथ यूनियनों और चौराहों के लिए आदेश जैसी कम स्पष्ट आज्ञाएं हैं।

सॉर्ट किए गए सेट ( आदेश )

सॉर्ट किए गए सेट भी अनूठे मूल्यों के संग्रह हैं। जैसा कि नाम से ही स्पष्ट है, ये आदेश दिए गए हैं। उन्हें एक अंक द्वारा आदेश दिया जाता है, फिर लेक्सोग्राफिक रूप से।

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

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

एक ही स्कोर के साथ मूल्यों को संग्रहीत करने से उन्हें शाब्दिक रूप से आदेश दिया जाता है (वर्णानुक्रम में सोचें)। यह ऑटो-पूर्ण सुविधाओं जैसी चीजों के लिए उपयोगी हो सकता है।

सॉर्ट किए गए सेट कमांड में से कई सेट के लिए कमांड के समान हैं, कभी-कभी एक अतिरिक्त स्कोर पैरामीटर के साथ। इसमें स्कोर को प्रबंधित करने और स्कोर द्वारा क्वेरी करने के आदेश भी शामिल हैं।

भू

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

रेडिस में तकनीकी रूप से भौगोलिक डेटा को सॉर्ट किए गए सेट के भीतर संग्रहीत किया जाता है, इसलिए यह वास्तव में अलग डेटा प्रकार नहीं है। यह सॉर्ट किए गए सेट के शीर्ष पर अधिक विस्तार है।

बिटमैप और हाइपरलॉग

जियो की तरह, ये पूरी तरह से अलग डेटा प्रकार नहीं हैं। ये कमांड हैं जो आपको स्ट्रिंग डेटा का इलाज करने की अनुमति देते हैं जैसे कि यह एक बिटमैप या हाइपरलॉग है।

बिटमैप्स वे बिट-लेवल ऑपरेटर्स हैं जिनका मैंने उल्लेख किया Stringsहै। यह डेटा प्रकार रेडिट की हाल की सहयोगी कला परियोजना: आर / प्लेस के लिए बुनियादी निर्माण खंड था ।

हाइपरलॉगॉग आपको चौंकाने वाली सटीकता के साथ लगभग असीमित अद्वितीय मूल्यों को गिनने के लिए अंतरिक्ष की एक बहुत ही कम मात्रा का उपयोग करने की अनुमति देता है। केवल ~ 16KB का उपयोग करके आप अपनी साइट पर अद्वितीय आगंतुकों की संख्या की गणना कर सकते हैं, भले ही वह संख्या लाखों में हो।

लेन-देन और परमाणु

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

जबकि रिलेशनल डेटाबेस में लेनदेन के रूप में नहीं काफी एक ही है, यह भी Redis है लेनदेन है कि उपयोग "आशावादी लॉक" ( वॉच / बहु / EXEC )।

पाइपलाइनिंग

रेडिस एक सुविधा प्रदान करता है जिसे ' पाइपलाइनिंग ' कहा जाता है । यदि आपके पास कई रेडिस कमांड हैं जिन्हें आप निष्पादित करना चाहते हैं, तो आप उन्हें एक-बार-बार के बजाय एक बार में सभी को फिर से भेजने के लिए पाइपलाइनिंग का उपयोग कर सकते हैं।

आम तौर पर जब आप किसी कमांड को या तो रेडिस या मेमकेच करते हैं, तो प्रत्येक कमांड एक अलग अनुरोध / प्रतिक्रिया चक्र होता है। पाइपलाइनिंग के साथ, रेडिस कई कमांड्स को बफर कर सकता है और एक ही रिप्लाई में आपके सभी कमांड्स के सभी जवाबों के साथ एक साथ उन सभी को निष्पादित कर सकता है।

यह आपको थोक आयात या अन्य कार्यों में बहुत अधिक थ्रूपुट प्राप्त करने की अनुमति दे सकता है जिसमें बहुत सारी कमांड शामिल हैं।

पब / उप

रेडिस के पास पब / उप कार्यक्षमता के लिए समर्पित कमांड हैं , जिससे रेडिस को उच्च गति संदेश प्रसारक के रूप में कार्य करने की अनुमति मिलती है। यह एक एकल ग्राहक को एक चैनल से जुड़े कई अन्य ग्राहकों को संदेश प्रकाशित करने की अनुमति देता है।

Redis पब / उप के साथ-साथ लगभग किसी भी उपकरण को करता है। रैबिटएमक्यू जैसे समर्पित मैसेज ब्रोकरों को कुछ क्षेत्रों में फायदे हो सकते हैं, लेकिन यह तथ्य कि एक ही सर्वर आपको लगातार टिकाऊ कतारें और अन्य डेटा संरचनाएं दे सकता है, जो आपके पब / उप वर्कलोड की जरूरत है, रेडिस अक्सर सबसे अच्छा और सबसे सरल उपकरण साबित होगा काम के लिए।

लुआ स्क्रिप्टिंग

आप लुआ लिपियों के बारे में सोच सकते हैं जैसे कि रेडिस की अपनी SQL या संग्रहीत कार्यविधियाँ। यह कम और अधिक दोनों है, लेकिन सादृश्य ज्यादातर काम करता है।

हो सकता है कि आपके पास जटिल गणनाएं हों जो आप प्रदर्शन करना चाहते हैं। हो सकता है कि आप अपने लेन-देन को वापस नहीं ले सकते हैं और गारंटी देता है कि जटिल प्रक्रिया के हर चरण में परमाणु रूप से होगा। इन समस्याओं और कई और अधिक को लुआ स्क्रिप्टिंग के साथ हल किया जा सकता है।

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

स्केलिंग

जैसा कि ऊपर बताया गया है, रेडिस में क्लस्टरिंग के लिए समर्थन शामिल है और इसे अपने स्वयं के उच्च उपलब्धता टूल के साथ बंडल किया जाता है redis-sentinel

निष्कर्ष

बिना किसी हिचकिचाहट के मैं किसी भी नई परियोजनाओं या मौजूदा परियोजनाओं के लिए मेमिसैक किए जाने की सिफारिश करूंगा, जो पहले से ही मेमकेड का उपयोग नहीं करते हैं।

ऊपर की तरह लग सकता है जैसे मुझे मेमस्कैल्ड पसंद नहीं है। इसके विपरीत: यह एक शक्तिशाली, सरल, स्थिर, परिपक्व और कठोर उपकरण है। यहां तक ​​कि कुछ उपयोग के मामले भी हैं जहां यह रेडिस से थोड़ा तेज है। मुझे मेम से प्यार हो गया। मुझे नहीं लगता कि यह भविष्य के विकास के लिए बहुत मायने रखता है।

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

केवल एक ही परिदृश्य है जहाँ मेमेकैट्स अधिक समझ में आता है: जहां मेमकाटेड पहले से ही कैश के रूप में उपयोग में है। यदि आप पहले से ही मेमस्कैच के साथ कैशिंग कर रहे हैं, तो इसका उपयोग करते रहें, यदि यह आपकी आवश्यकताओं को पूरा करता है। यह संभवतः रेडिस पर जाने के प्रयास के लायक नहीं है और यदि आप केवल कैशिंग के लिए रेडिस का उपयोग करने जा रहे हैं तो यह आपके समय के लायक होने के लिए पर्याप्त लाभ प्रदान नहीं कर सकता है। यदि मेमकाटेड आपकी आवश्यकताओं को पूरा नहीं कर रहा है, तो आपको संभवतः रेडिस पर जाना चाहिए। यह सच है कि क्या आपको मेम्केड से परे स्केल करने की आवश्यकता है या आपको अतिरिक्त कार्यक्षमता की आवश्यकता है।


11
मेमकास्ट एक तरह से सर्वर में मौजूद है जो क्लस्टरिंग प्रदान करता है? मैंने हमेशा पुस्तकालयों का उपयोग किया है जो हैशिंग एल्गोरिदम या एक मापांक का उपयोग करके मेमकाटेड सर्वरों के एक पूल को वितरित करता है। रेडिस के लिए भी यही कहा जाता है। मैं ज्यादातर पायथन का उपयोग करता हूं और काफी कुछ मॉड्यूल प्रतीत होते हैं जो कनेक्शन पूल को संभालने के लिए मेमस्कैल्ड लाइब्रेरी पर भरोसा नहीं करते हैं।
4

2
"आशावादी लॉकिंग (वॉट / मल्टी / एक्सईसी) के साथ लेनदेन" - रेडिस का कोई सही लेनदेन नहीं है। यानी अगर [मल्टी, cmd1, cmd2, cmd3 (अपवाद), निष्पादित करें] तो cmd1 और cmd2 निष्पादित किया जाएगा।
ओलेग

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

3
@ शियरियर आप सही हैं। अद्यतित उत्तर को दर्शाने के लिए कि मेमक्लेश्ड क्लस्टर "सपोर्ट" अतिरिक्त टूल द्वारा सक्षम है। बेहतर है कि शोध किया जाना चाहिए।
कार्ल ज़ुल्फ

3
कैसे couchbase सर्वर के साथ क्लस्टरिंग के बारे में? (याद किया गया संगत)
केन लियू

142

रेडिस का उपयोग करें यदि

  1. आपको कैश में आइटमों को हटाने / चयन करने की आवश्यकता है। (आपको इसकी आवश्यकता है)

  2. आपको किसी विशेष प्रकार की कुंजियों को क्वेरी करने की क्षमता की आवश्यकता होती है। eq। 'ब्लॉग 1: पोस्ट: *', 'ब्लॉग 2: श्रेणियां: एक्सयज: पोस्ट: *'। अरे हां! यह बहुत महत्वपूर्ण है। कुछ प्रकार के कैश्ड आइटम को चुनिंदा रूप से अमान्य करने के लिए इसका उपयोग करें। आप इसका उपयोग फ़्रेग्म कैश, पेज कैश, किसी दिए गए प्रकार के केवल AR ऑब्जेक्ट्स आदि को अमान्य करने के लिए कर सकते हैं।

  3. दृढ़ता (आपको इसकी भी आवश्यकता होगी, जब तक कि आप अपने कैश के साथ हर पुनरारंभ के बाद गर्म होने के लिए ठीक नहीं हैं। शायद ही कभी वस्तुओं के लिए बहुत आवश्यक है जो शायद ही कभी बदलते हैं)

मेमकेड का प्रयोग करें यदि

  1. मेमकेडेड आपको हेडेड देता है!
  2. umm ... क्लस्टरिंग? हुंह। यदि आप उस दूर जाने वाले हैं, तो टुकड़े और एआर ऑब्जेक्ट को कैशिंग के लिए वार्निश और रेडिस का उपयोग करें।

मेरे अनुभव से मुझे मेम्केड की तुलना में रेडिस के साथ बहुत बेहतर स्थिरता मिली है


7
रेडिस प्रलेखन का कहना है कि पैटर्न का उपयोग करने के लिए एक टेबल स्कैन की आवश्यकता होती है। ब्लॉग 1: पोस्ट: * ओ (एन) टेबल स्कैन की आवश्यकता हो सकती है। बेशक, यह अभी भी डेटा आकार के डेटा सेट पर तेज़ है, क्योंकि रेडिस तेज़ है। परीक्षण या व्यवस्थापक के लिए यह ठीक होना चाहिए।
y:४४

182
हेडेड एक मजाक है, है ना? :-) मैं सिर झुकाए जाने के लिए तैयार था, लेकिन कुछ भी उचित नहीं मिला। (मैं
मेम्केड

11
@pellucide की तुलना में उसी कारण से मतदान किया गया । रेडिस, मेम्केच्ड से बेहतर हो सकता है, लेकिन मेम्कैच्ड उपयोग करने के लिए तुच्छ है। मुझे इसके साथ कभी कोई समस्या नहीं थी और इसे कॉन्फ़िगर करना तुच्छ है।
डिएगो जैंसिक जूल

5
मेरा दिन बनाने के लिए @KajMagnus धन्यवाद। संभवतः मेरा पूरा सप्ताह
alex

@DiegoJancic Redis उपयोग करने के लिए सबसे आसान तकनीकों में से एक है। बिना किसी पूर्व रेडिस ज्ञान के मुझे बादल में एक पैकेज मैनेजर का उपयोग करके उबंटू पर इसे स्थापित करने और सरल प्रश्न बनाने के लिए सिर्फ 20 मिनट लगे। 4 घंटे बाद मैं Lua स्क्रिप्ट का उपयोग करके बैच आवेषण के साथ और अधिक जटिल परिदृश्यों को POC कर सकता था और प्रदर्शन को बेहतर बनाने के लिए सही (NIO) जावा लाइब्रेरी का चयन कर सकता था। मैं रेडिस की तुलना में अधिक अनुकूल और सरल कुछ भी कल्पना नहीं कर सकता।
लूज ऑन

105

मेमकाटेड बहुस्तरीय और तेज है।

रेडिस में बहुत सारी विशेषताएं हैं और यह बहुत तेज़ है, लेकिन पूरी तरह से एक कोर तक सीमित है क्योंकि यह एक इवेंट लूप पर आधारित है।

हम दोनों का उपयोग करते हैं। मेमकाटेड का उपयोग कैशिंग ऑब्जेक्ट के लिए किया जाता है, मुख्य रूप से डेटाबेस पर रीड लोड को कम करता है। रेडिस को सॉर्ट किए गए सेट जैसी चीजों के लिए उपयोग किया जाता है जो समय-श्रृंखला डेटा को रोल करने के लिए आसान होते हैं।


2
उच्च-ट्रैफ़िक साइटें जो भारी मात्रा में निवेशित हैं और "उपयोगकर्ता प्रोफ़ाइल" पर db की अड़चनें हैं, जैसे गैर-संबंधपरक डेटा को सामान्य मोंगो,

2
@siliconrockstar - बहुत यकीन है कि रेडिस 3 अभी भी सिंगल कोर है; कम से कम AWS रेडिस (जो 3.2.6 या 3.2.10 का उपयोग करता है) को उस समय ध्यान में रखने की चेतावनी देता है जब उदाहरण के लिए EngineCpuUtilization Metrics
dwanderson

1
ऐसा लगता है कि आप सही हैं, मुझे लगता है कि जब मैंने वह टिप्पणी की थी तो मैं इसे अधूरे स्रोतों पर आधारित कर रहा था। हटा दी गई टिप्पणी।
सिलिकॉनक्रॉस्टर

लेकिन आप अभी भी Redis
Imaskar

2
Redis दक्षता पर बेहद केंद्रित है - इसलिए आपको अपने आप से यह पूछने की आवश्यकता है कि स्मार्ट डेवलपर्स का एक समूह इसे एकल पिरोए रखने के लिए क्यों चुना? रेडिस डॉक्स से "यह बहुत बार नहीं है कि सीपीयू रेडिस के साथ आपकी अड़चन बन जाता है, जैसा कि आमतौर पर रेडिस या तो मेमोरी या नेटवर्क बाउंड होता है"। यदि आप एक ग्रुण सर्वर का उपयोग करना चाहते थे जो सीपीयू बाध्य था, तो आपके पास संभवतः कई उपयोगकर्ता हैं और वैसे भी कई अनावश्यक सर्वर होने चाहिए। यदि आप एक सर्वर पर कई सीपीयू अधिकतम करना चाहते हैं, तो विभाजन का उपयोग करें। पढ़ें: redis.io/topics/…
रॉबोकैट

91

यह पहले से ही स्वीकृत उत्तर के लिए एक टिप्पणी के रूप में पोस्ट करने के लिए बहुत लंबा है, इसलिए मैंने इसे एक अलग उत्तर के रूप में रखा

एक बात पर भी विचार करें कि क्या आप अपने कैश इंस्टेंसेस पर हार्ड अपर मेमोरी लिमिट होने की उम्मीद करते हैं।

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

डिफ़ॉल्ट रूप से रेडिस जेमालॉक मेमोरी एलोकेटर का उपयोग करता है , जो मेमोरी-कॉम्पैक्ट और फास्ट दोनों के लिए अपनी पूरी कोशिश करता है, लेकिन यह एक सामान्य उद्देश्य मेमोरी एलोकेटर है और यह बहुत अधिक आवंटन और ऑब्जेक्ट को उच्च दर पर प्रस्तुत करने के साथ नहीं रख सकता है। इस वजह से, कुछ लोड पैटर्न पर रेडिस प्रक्रिया स्पष्ट रूप से आंतरिक विखंडन के कारण मेमोरी को लीक कर सकती है। उदाहरण के लिए, यदि आपके पास 7 जीबी रैम वाला सर्वर है और आप गैर-लगातार LRU कैश के रूप में रेडिस का उपयोग करना चाहते हैं, तो आप उस रेडिस प्रक्रिया को पा सकते हैंmaxmemory समय के 5Gb पर सेट के अधिक से अधिक मेमोरी का उपयोग करेगी, अंततः कुल रैम सीमा तक स्मृति के हत्यारे का हस्तक्षेप।

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

उस के साथ, कहा, अभी भी वातावरण में एक मजबूत स्थिति है, जहां स्मृति उपयोग को लागू किया जाना है और / या पूर्वसूचक होना चाहिए। हमने नवीनतम स्थिर रेडिस (2.8.19) को ड्रॉप-इन गैर-निरंतर LRU-आधारित मेमकेच्ड प्रतिस्थापन के रूप में 10-15k op / s के कार्यभार में उपयोग करने की कोशिश की है, और यह मेमोरी A LOT लीक हुई है; उसी कार्यभार की वजह से अमेजन के ElastiCache रेडिस इंस्टेंस में एक ही दिन में दुर्घटना हो गई थी।


2
से redis.io/topics/faq : Redis में निर्मित, स्मृति के उपयोग करने के लिए एक अधिकतम सीमा निर्धारित करने की कॉन्फ़िग फ़ाइल में maxmemory विकल्प का उपयोग कर स्मृति Redis उपयोग कर सकते हैं की एक सीमा डाल करने के लिए उपयोगकर्ता की अनुमति के सुरक्षा गया है। यदि यह सीमा समाप्त हो गई है तो Redis कमांड लिखने के लिए एक त्रुटि के साथ उत्तर देना शुरू कर देगा (लेकिन रीड-ओनली कमांड्स को स्वीकार करना जारी रखेगा), या जब आप Redis का उपयोग कर रहे हैं तो अधिकतम मेमोरी लिमिट तक पहुंचने पर आप इसे कुंजियों को निकालने के लिए कॉन्फ़िगर कर सकते हैं। कैशिंग के लिए। यदि आपके पास एलआरयू कैश के रूप में रेडिस का उपयोग करने की योजना है, तो हमारे पास दस्तावेज हैं। लिंक
स्टीफन नॉच

8
@StefanNch रेडिस का maxmemoryविकल्प आंतरिक मेमोरी विखंडन के लिए जिम्मेदार नहीं है। कृपया विवरण के लिए मेरी टिप्पणी ऊपर देखें - मैंने जो समस्याएं बताई हैं, उन्हें "लिरिस के रूप में LRU कैश" पृष्ठ में वर्णित परिदृश्य के तहत देखा गया था जिसमें मेमोरी सीमित विकल्प सक्षम थे। दूसरी तरफ, मेमरेक्टेड, मेमोरी विखंडन की समस्या से बचने के लिए अलग-अलग दृष्टिकोण का उपयोग करता है, इसलिए इसकी मेमोरी सीमा बहुत अधिक "कठिन" है।
artyom

46

मेमकेच एक साधारण कुंजी / मान स्टोर होने में अच्छा है और कुंजी => STRING करने में अच्छा है। यह सत्र भंडारण के लिए वास्तव में अच्छा बनाता है।

Redis कुंजी => SOME_OBJECT करने में अच्छा है।

यह वास्तव में इस बात पर निर्भर करता है कि आप वहां क्या करने जा रहे हैं। मेरी समझ यह है कि प्रदर्शन के मामले में वे बहुत सुंदर हैं।

किसी भी उद्देश्य बेंचमार्क को खोजने के लिए भी अच्छी किस्मत, अगर आप कुछ मिल जाए तो कृपया उन्हें मेरा रास्ता भेजें।


2
IMO Redis Hash डेटा प्रकार सत्र चर को स्टोर करने के लिए बहुत अधिक समझ में आता है क्योंकि उन्हें एक मेमॉन्डेड स्ट्रिंग में सीरियल करना है।
कार्ल जुलाफ

6
यदि आप उपयोगकर्ता अनुभव की परवाह करते हैं, तो अपने सत्रों को कैश में न डालें। dormando.livejournal.com/495593.html
sleblanc

4
@sebleblanc यह सैद्धांतिक रूप से रेडिस के साथ एक मुद्दा नहीं होना चाहिए, क्योंकि डिस्क दृढ़ता भी है।
19

2
@sebleblanc memcache सत्र भंडारण में अभी भी अच्छा है जिसे आप इसे खराब तरीके से लागू करते हैं या नहीं। हाँ बेदखली एक समस्या है, लेकिन वैसे भी अकल्पनीय नहीं है, लेकिन अगर आप बेदखली के बारे में चिंता नहीं करते हैं, तो यह याद रखने की समस्या नहीं है। अधिकांश मेमाचे सत्र समाधान कुकीज़ का उपयोग एक बैकअप के रूप में मेरा मानना ​​है।
एरिक पीटरसन

11
"अपने सत्रों को कैश में न डालें" भ्रामक है। आपका क्या मतलब है "न केवल अपने सत्रों को कैश में संग्रहीत करें"। जो कोई भी केवल मेकचे में महत्वपूर्ण डेटा संग्रहीत करता है, उसे तुरंत निकाल दिया जाना चाहिए।
जैकब

37

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

और कोई भी बेंचमार्क लिंक चीजों को थोड़ा सा भ्रमित किए बिना पूरा नहीं होता है, इसलिए डॉरमंडो के LiveJournal और Antirez Weblog में कुछ परस्पर विरोधी बेंचमार्क देखें

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


9
Redis बनाम Memcached बेंचमार्क बीमार कल्पना की है। oldblog.antirez.com/post/redis-memcached-benchmark.html
ऐप वर्क

28
आप crass के बारे में मजाक नहीं कर रहे थे।
ओसोडो

1
2010 से अधिक, पुराना ब्लॉग
सिद्धार्थ

24

मुझे कैशिंग प्रॉक्सी में एक साथ मेमकेच्ड और रेडिस दोनों का उपयोग करने का अवसर मिला, जिस पर मैंने काम किया है, मैं आपको साझा करता हूं कि वास्तव में मैंने कहां उपयोग किया है और उसी के पीछे क्या कारण है ...।

रेडिस>

1) क्लस्टर पर, कैश सामग्री को अनुक्रमित करने के लिए उपयोग किया जाता है। रेडिस क्लस्टर्स में फैले मेरे पास अरबों से अधिक कीज़ हैं, रेडिस प्रतिक्रिया समय काफी कम और स्थिर है।

2) मूल रूप से, यह एक कुंजी / मूल्य की दुकान है, इसलिए जहां कभी भी आपके आवेदन में आपके पास कुछ समान है, एक बहुत परेशान करने के साथ लाल रंग का उपयोग कर सकता है।

3) रेडिस दृढ़ता, असफलता और बैकअप (एओएफ) आपके काम को आसान बना देगा।

मेमेक>

1) हाँ, एक अनुकूलित मेमोरी जिसे कैश के रूप में उपयोग किया जा सकता है। मैंने इसे 1 एमबी से कम आकार के साथ बहुत बार (50 हिट्स / सेकंड के साथ) एक्सेस करने वाली कैश सामग्री के भंडारण के लिए इस्तेमाल किया।

2) मैंने 16 जीबी में से केवल 2 जीबी को मेमेकटेड के लिए आवंटित किया, वह भी तब जब मेरा एकल सामग्री का आकार> 1 एमबी था।

3) जैसा कि सामग्री सीमा के पास बढ़ती है, कभी-कभी मैंने आँकड़ों में उच्च प्रतिक्रिया समय देखा है (रेडिस के साथ मामला नहीं)।

यदि आप समग्र अनुभव के लिए पूछते हैं रेडिस बहुत हरा है क्योंकि यह कॉन्फ़िगर करना आसान है, स्थिर मजबूत विशेषताओं के साथ बहुत लचीला है।

इसके अलावा, इस लिंक पर एक बेंचमार्किंग परिणाम उपलब्ध है , नीचे से कुछ हिगलाइट हैं,

यहां छवि विवरण दर्ज करें

यहां छवि विवरण दर्ज करें

उम्मीद है की यह मदद करेगा!!


14

परीक्षा। कुछ सरल बेंचमार्क चलाएं। लंबे समय तक मैंने खुद को एक पुराना स्कूल राइनो माना क्योंकि मैंने ज्यादातर कंसीलर का इस्तेमाल किया और रेडिस को नया बच्चा माना।

मेरी वर्तमान कंपनी के साथ Redis को मुख्य कैश के रूप में उपयोग किया गया था। जब मैंने कुछ प्रदर्शन आँकड़े खोद लिए और बस परीक्षण शुरू कर दिया, तो प्रदर्शन के मामले में रेडिस, MySQL की तुलना में तुलनात्मक या न्यूनतम रूप से धीमा था

मेमकाटेड, हालांकि सरलीकृत है, रेडिस को पूरी तरह से पानी से बाहर निकाल दिया । यह बहुत बेहतर है:

  • बड़े मूल्यों के लिए (स्लैब के आकार में आवश्यक परिवर्तन, लेकिन काम किया)
  • कई समवर्ती अनुरोधों के लिए

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

कुछ बेंचमार्किंग से पता चला कि रेडिस, हमारे मामले में, बहुत खराब प्रदर्शन करता है। यह मेरा मानना ​​है कि कई चर के साथ करना है:

  • जिस प्रकार का हार्डवेयर आप Redis चलाते हैं
  • आपके द्वारा संग्रहीत डेटा के प्रकार
  • सेट और सेट की राशि
  • आपका ऐप कितना समवर्ती है
  • क्या आपको डेटा संरचना भंडारण की आवश्यकता है

व्यक्तिगत रूप से, मैं उस दृश्य को साझा नहीं करता हूं जिसमें Redis लेखकों की सहमति और मल्टीथ्रेडिंग है।


कृपया समझाएँ "MySQL की तुलना में धीमी गति से।"
अनिरुद्ध गुप्ता

ट्रूट को बताया जाए कि मेरे पास यह बेंचमार्क डेटा नहीं है, लेकिन उस विशेष मामले को पढ़ने / लिखने के लिए बहुत कुछ था
20'18

13

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

कुछ ऐप जो मैंने काम किए हैं, दोनों को यह स्पष्ट करने के लिए कि हम डेटा को कैसे व्यवहार करने का इरादा रखते हैं - मेमकेच में सामान, हम उन मामलों को संभालने के लिए कोड लिखते हैं जहां यह नहीं है - रेडिस में सामान, हम इस पर भरोसा करते हैं ।

इसके अलावा Redis को आमतौर पर ज्यादातर उपयोग के मामलों के लिए बेहतर माना जाता है जो अधिक सुविधा संपन्न और इस प्रकार लचीले होते हैं।


10

यह गलत नहीं होगा, अगर हम कहें कि रेडिस (कैश + डेटा संरचना) का संयोजन है, जबकि मेमेकैट्स केवल कैश है।


1
यह अच्छा जवाब है - लारवेल कैश के रूप में और डेटा भंडारण तंत्र के रूप में रेडिस का उपयोग कर रहा है
मिरोस्लाव ट्रिनीक

8

Redis-2.2.2 और मेमेकैक्ड के खिलाफ 100k अद्वितीय कुंजी और मान प्राप्त करने के लिए एक बहुत ही सरल परीक्षण। दोनों लिनक्स वीएम (सेंटोस) पर चल रहे हैं और मेरा क्लाइंट कोड (नीचे चिपकाया गया) विंडोज़ डेस्कटॉप पर चलता है।

Redis

  • 100000 मान स्टोर करने के लिए लिया गया समय = 18954ms है

  • 100000 मान लोड करने के लिए लिया गया समय = 18328ms है

memcached

  • 100000 मान स्टोर करने के लिए लिया गया समय = 797ms है

  • 100000 मान प्राप्त करने के लिए लिया गया समय = 38984ms है


Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

6
चूंकि आपने स्पष्ट रूप से माप के लिए जावा का उपयोग किया था .... क्या आपने अपने परीक्षण मामलों को "गर्म" किया था? यह इतने कम समय को मापने के लिए आवश्यक है ... कि जेआईटी ने गर्म स्थानों को संकलित किया।
क्लजक

7

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


6

शेष सबसे बड़ा कारण विशेषज्ञता है।

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

यदि आप उस विशेष परिदृश्य से बचने के लिए केवल LRU उदाहरण के रूप में उपयोग किए जाने के लिए एक समर्पित Redis उदाहरण को सेटअप करने जा रहे हैं तो वास्तव में Memcached पर Redis का उपयोग करने के लिए कोई सम्मोहक कारण नहीं है।

यदि आपको एक विश्वसनीय "कभी भी नीचे नहीं जाता है" LRU कैश की आवश्यकता है ... मेमेकैड बिल फिट होगा क्योंकि यह डिजाइन द्वारा मेमोरी से बाहर चलाने के लिए असंभव है और विशेषज्ञ कार्यक्षमता डेवलपर्स को इसे ऐसा बनाने की कोशिश करने से रोकती है जिससे यह खतरे में पड़ सकता है। सरोकारों का सरल जुदाई।


6

यदि आप प्रदर्शन में रुचि रखते हैं तो मेमैकैड तेजी से होगा, सिर्फ इसलिए कि रेडिस में नेटवर्किंग (टीसीपी कॉल) शामिल है। साथ ही आंतरिक रूप से मेमेचे भी तेज है।

रेडिस में और अधिक विशेषताएं हैं क्योंकि यह अन्य उत्तरों द्वारा उल्लिखित था।


6

हमने रेडिस को काम में हमारी परियोजना के लिए लोड-टेकऑफ़ माना। हमने सोचा कि nginxबुलाया में एक मॉड्यूल का उपयोग करकेHttpRedis2Module या कुछ इसी तरह के हमारे पास भयानक गति होगी लेकिन एबी-परीक्षण के साथ परीक्षण करते समय हम गलत साबित होते हैं।

हो सकता है कि मॉड्यूल खराब था या हमारा लेआउट था, लेकिन यह एक बहुत ही सरल कार्य था और php के साथ डेटा लेना और फिर इसे MongoDB में सामान करना और भी तेज़ था। हम APC का उपयोग कैशिंग-सिस्टम के रूप में और उस php और MongoDB के साथ कर रहे हैं। यह तब बहुत तेज थाnginx Redis मॉड्यूल था।

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


दिलचस्प जवाब है, लेकिन यकीन नहीं है कि यह मदद करता है ओपी
स्कॉट Schulthess

Redis में सम्मिलित करना और इसे कैश के रूप में उपयोग करना APC + PHP + MongoDB का उपयोग करने की तुलना में धीमा था। लेकिन सिर्फ रेडिस के लिए सम्मिलन MongoDB में सीधे डालने की तुलना में बहुत धीमा था। एपीसी के बिना मुझे लगता है कि वे बहुत समान हैं।
सुश्री 01

2
यह इसलिए क्योंकि मोंगो आपको कोई गारंटी नहीं देता है कि आपने जो डाला है वह कभी डिस्क पर लिखा जाएगा ...
डेमियन

21
लेकिन यह webscale है, जब आप लिखते हैं तो मोंगोडेब आपके चारों ओर हलकों में चलेगा। आजकल मैं केवल / dev / null को लिखता हूं क्योंकि यह सबसे तेज है।
सुश्री 01

1

रेडिस बेहतर है।

पेशेवरों के Redisहैं,

  1. इसमें बहुत सारे डेटा स्टोरेज विकल्प हैं जैसे कि स्ट्रिंग, सेट, सॉर्ट किए गए सेट, हैश, बिटमैप
  2. रिकॉर्ड की डिस्क दृढ़ता
  3. संग्रहीत कार्यविधि ( LUAस्क्रिप्टिंग) समर्थन
  4. PUB / SUB का उपयोग करके एक संदेश ब्रोकर के रूप में कार्य कर सकता है

जबकि Memcacheइन-मेमोरी की-वैल्यू कैश टाइप सिस्टम है।

  1. सूचियों जैसे विभिन्न डेटा प्रकारों के लिए कोई समर्थन नहीं, रेडिस के रूप में सेट करता है।
  2. Memcache के प्रमुख कॉन्क में कोई डिस्क दृढ़ता नहीं है।

0

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


0

यहाँ अमेज़न द्वारा प्रदान किया गया वास्तव में बहुत अच्छा लेख / अंतर है

रेडिस एक स्पष्ट विजेता है जो मेम्केड के साथ तुलना करता है।

मेमकेच्ड के लिए केवल एक प्लस पॉइंट मल्टीथ्रेडेड और फास्ट है। Redis में बहुत सारी खूबियाँ हैं और यह बहुत तेज़ है, लेकिन एक कोर तक सीमित है।

रेडिस के बारे में शानदार बातें, जो मेमकेड में समर्थित नहीं हैं

  • स्नैपशॉट - उपयोगकर्ता रेडिस कैश का एक स्नैपशॉट ले सकता है और किसी भी समय द्वितीयक भंडारण पर बना रह सकता है।
  • कई डेटा संरचनाओं के लिए इनबिल्ट सपोर्ट जैसे सेट, मैप, सॉर्टसेट, लिस्ट, बिटमैप आदि।
  • लालियों में लुआ स्क्रिप्टिंग के लिए समर्थन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.