architecture - रेडिस कब करें? MongoDB कब?




nosql redis (7)

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

मोंगो। आपने एक साइट लिखी है बिल्ली आपने कई और किसी भी भाषा में लिखा है। आपको एहसास है कि आपका अधिकांश समय एसक्यूएल क्लॉज को डूबने में लिख रहा है। आप एक डीबीए नहीं हैं, फिर भी आप बेवकूफ एसक्यूएल स्टेटमेंट लिख रहे हैं ... सिर्फ एक ही नहीं बल्कि हर जगह मजाक कर रहे हैं। "इसे चुनें, इसे चुनें"। लेकिन विशेष रूप से आप परेशान कहां क्लॉज याद करते हैं। जहां अंतिम नाम "थॉर्नटन" के समान होता है और फिल्म "खराब सांता" के बराबर होती है। Urgh। आप सोचते हैं, "उन डीबीए सिर्फ अपनी नौकरी क्यों नहीं करते हैं और मुझे कुछ संग्रहित प्रक्रियाएं देते हैं?" फिर आप मिडलनाम जैसे कुछ मामूली क्षेत्र को भूल जाते हैं और फिर आपको टेबल छोड़ना होगा, बड़े डेटा के सभी 10 जी निर्यात करना होगा और इस नए क्षेत्र के साथ एक और बनाना होगा, और डेटा आयात करना होगा - और यह अगले 14 दिनों के दौरान 10 बार चला जाता है अभिवादन, शीर्षक, और पते के साथ एक विदेशी कुंजी जोड़ने जैसे बकवास याद रखें। फिर आप पाते हैं कि अंतिम नाम अंतिम नाम होना चाहिए। लगभग एक दिन में बदल जाता है। फिर आप डारिट कहते हैं। मुझे एक वेब साइट / सिस्टम लिखना और लिखना है, इस डेटा मॉडल बी को कभी भी ध्यान न दें। तो आप गूगल करते हैं, "मुझे एसक्यूएल लिखने से नफरत है, कृपया कोई एसक्यूएल नहीं, इसे रोक दें" लेकिन पॉप 'नोस्कल' पॉप करें और फिर आप कुछ सामान पढ़ते हैं और यह कहता है कि यह बिना किसी स्कीमा के डेटा को डंप करता है। आपको याद है कि पिछले हफ्ते का फियास्को अधिक टेबल और मुस्कान छोड़ रहा है। फिर आप मोंगो चुनते हैं क्योंकि 'एयरबड' जैसे कुछ बड़े लोग उपयुक्त किराये की साइट का उपयोग करते हैं। मिठाई। कोई और डेटा मॉडल बदलता नहीं है क्योंकि आपके पास एक मॉडल है जिसे आप अभी बदलते रहते हैं।

मैं जो चाहता हूं वह रेडिस और मोंगोडीबी के बीच तुलना नहीं है। मुझे पता है कि वे अलग हैं; प्रदर्शन और एपीआई पूरी तरह से अलग है।

रेडिस बहुत तेज है, लेकिन एपीआई बहुत 'परमाणु' है। MongoDB अधिक संसाधन खाएगा, लेकिन एपीआई का उपयोग करना बहुत आसान है, और मैं इसके साथ बहुत खुश हूं।

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

तो आप दोनों के उपयोग के बारे में क्या सोचते हैं? रेडिस कब लेना है? MongoDB कब चुनना है?


उत्तर देने के लिए मुश्किल सवाल - अधिकांश तकनीकी समाधानों के साथ, यह वास्तव में आपकी स्थिति पर निर्भर करता है और चूंकि आपने उस समस्या का वर्णन नहीं किया है जिसे आप हल करने का प्रयास कर रहे हैं, कोई भी समाधान का प्रस्ताव कैसे दे सकता है?

आपको यह देखने के लिए दोनों की जांच करनी होगी कि उनमें से कौन आपकी आवश्यकताओं को संतुष्ट करता है।

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


मैं कहूंगा, यह आपकी तरह की देव टीम पर निर्भर करता है और आपके आवेदन की ज़रूरत है।

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

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

उदाहरण के लिए। रेडिस में एक कैश परत शायद बेहतर ढंग से लागू की जा सकती है। अधिक स्कीमा-सक्षम डेटा के लिए, मोंगोडीबी बेहतर है। [नोट: मोंगोडीबी और रेडिस दोनों तकनीकी रूप से स्कीमलेस हैं]

यदि आप मुझसे पूछते हैं, तो मेरी व्यक्तिगत पसंद ज्यादातर आवश्यकताओं के लिए रेडिस है।

आखिरकार, मुझे आशा है कि अब तक आपने http://antirez.com/post/MongoDB-and-Redis.html देखा है


मैंने अभी देखा है कि यह सवाल काफी पुराना है। फिर भी, मैं निम्नलिखित पहलुओं को जोड़ने के लायक मानता हूं:

  • यदि आप अभी तक नहीं जानते हैं कि आप अपने डेटा से कैसे पूछेंगे, तो MongoDB का उपयोग करें।

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

  • अपने मौजूदा एप्लिकेशन को तेज़ करने के लिए रेडिस का प्रयोग करें।

    रेडिस को एलआरयू कैश के रूप में आसानी से एकीकृत किया जा सकता है। रेडिस को एक स्टैंडअलोन डेटाबेस सिस्टम के रूप में उपयोग करना बहुत असामान्य है (कुछ लोग इसे "कुंजी-मूल्य" -स्टोर के रूप में संदर्भित करना पसंद करते हैं। क्रेगलिस्ट जैसी वेबसाइटें अपने प्राथमिक डेटाबेस के बगल में रेडिस का उपयोग करती हैं। एंटीरेज़ (रेडिस के डेवलपर) ने लैमरन्यूज़ का उपयोग करके प्रदर्शन किया कि रेडिस का स्टैंड स्टैंड डेटाबेस डेटाबेस के रूप में उपयोग करना संभव है।

  • रेडिस आपके डेटा के आधार पर कोई धारणा नहीं करता है।

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

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

  • कैशिंग

    MongoDB का उपयोग कर कैशिंग बस बहुत समझ में नहीं आता है। यह बहुत धीमा होगा।

  • यदि आपके पास अपने डीबी डिज़ाइन के बारे में सोचने के लिए पर्याप्त समय है।

    आप अपने दस्तावेज़ों में रेडिस में फेंक नहीं सकते हैं। आपको उस तरीके के बारे में सोचना होगा जिसमें आप अपना डेटा स्टोर करना और व्यवस्थित करना चाहते हैं। रेडिस में एक उदाहरण हैश। वे "पारंपरिक", नेस्टेड ऑब्जेक्ट्स से काफी अलग हैं, जिसका मतलब है कि आपको नेस्टेड दस्तावेज़ों को स्टोर करने के तरीके पर पुनर्विचार करना होगा। एक समाधान हैश के अंदर एक संदर्भ हैश के अंदर एक संदर्भ ( कुंजी की तरह कुछ : [दूसरे हैश की आईडी] )। एक और विचार इसे JSON के रूप में स्टोर करना होगा, जो कि * एसक्यूएल-पृष्ठभूमि वाले अधिकांश लोगों के प्रति प्रतिकूल लगता है।

  • यदि आपको वास्तव में उच्च प्रदर्शन की आवश्यकता है।

    प्रदर्शन रेडिस प्रदान करना लगभग असंभव है। कल्पना करें कि डेटाबेस आपके कैश जितना तेज़ है। रेडिस को वास्तविक डेटाबेस के रूप में उपयोग करने जैसा लगता है।

  • यदि आपको स्केलिंग के बारे में बहुत कुछ परवाह नहीं है।

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

MongoDB का उपयोग कब करें

  • प्रोटोटाइप, स्टार्टअप, हैकथॉन

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

  • जब आपको अपनी स्कीमा को जल्दी से बदलना होगा।

    क्योंकि कोई स्कीमा नहीं है! परंपरागत, संबंधपरक डीबीएमएस में तालिकाओं को बदलना दर्दनाक महंगा और धीमा है। MongoDB आपके अंतर्निहित डेटा पर बहुत सारी धारणाएं नहीं बनाकर इस समस्या को हल करता है। फिर भी, यह एक स्कीमा को परिभाषित करने के बिना आपको यथासंभव अनुकूलित करने का प्रयास करता है।

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

आगे की पढाई:


रेडिस मेमोरी डेटा स्टोर में एक है , जो डिस्क की स्थिति को जारी रख सकता है (पुनरारंभ करने के बाद पुनर्प्राप्ति को सक्षम करने के लिए)। हालांकि, इन-मेमोरी डेटा स्टोर होने का मतलब है कि डेटा स्टोर का आकार (एक नोड पर) सिस्टम पर कुल मेमोरी स्पेस (भौतिक RAM + स्वैप स्पेस) से अधिक नहीं हो सकता है। हकीकत में, यह बहुत कम होगा, क्योंकि रेडिस सिस्टम पर कई अन्य प्रक्रियाओं के साथ उस स्थान को साझा कर रहा है, और यदि यह सिस्टम मेमोरी स्पेस को समाप्त करता है तो यह ऑपरेटिंग सिस्टम द्वारा मार डाला जाएगा।

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

रेडिस और मोंगो दोनों को उच्च उपलब्धता, बैकअप और डेटास्टोर के समग्र आकार में वृद्धि के लिए क्लस्टर किया जा सकता है।


रेडिस और मोंगो डीबी दोनों गैर-रिलेशनल डेटाबेस हैं लेकिन वे विभिन्न श्रेणियों के हैं।

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

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


सभी उत्तरों (इस लेखन के समय) प्रत्येक Redis, MongoDB मानते हैं, और शायद एक एसक्यूएल आधारित रिलेशनल डेटाबेस अनिवार्य रूप से एक ही उपकरण हैं: "स्टोर डेटा"। वे डेटा मॉडल पर बिल्कुल विचार नहीं करते हैं।

मोंगो डीबी: कॉम्प्लेक्स डेटा

MongoDB एक दस्तावेज़ स्टोर है। एसक्यूएल-संचालित रिलेशनल डेटाबेस से तुलना करने के लिए: संबंधित डेटाबेस अनुक्रमित सीएसवी फाइलों को सरल बनाते हैं, प्रत्येक फ़ाइल एक टेबल होती है; दस्तावेज़ स्टोर अनुक्रमित JSON फ़ाइलों को सरल बनाते हैं, प्रत्येक फ़ाइल एक दस्तावेज़ होती है, जिसमें एकाधिक फ़ाइलों को एक साथ समूहीकृत किया जाता है।

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

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

उपरोक्त दस्तावेज़ में एक कुंजी है, PhoneNumber.Mobile 555 634-5789 , जिसका मूल्य 555 634-5789 । आप दस्तावेजों के संग्रह के माध्यम से खोज सकते हैं जहां कुंजी, PhoneNumber.Mobile , कुछ मूल्य है; वे अनुक्रमित हैं।

इसमें Accounts की एक श्रृंखला भी है जो एकाधिक अनुक्रमणिका रखती है। किसी दस्तावेज़ के लिए पूछना संभव है जहां Accounts में मूल्यों का कुछ सबसेट होता है, मूल्यों के कुछ सबसेट, या मूल्यों के कुछ सबसेट में से कुछ। इसका मतलब है कि आप Accounts = ["379-1111", "379-2574"] खोज सकते हैं और ऊपर नहीं ढूंढ सकते हैं; आप Accounts includes ["379-1111"] खोज कर सकते Accounts includes ["379-1111"] और उपर्युक्त दस्तावेज़ ढूंढें; और आप Accounts includes any of ["974-3785","414-6731"] लिए खोज सकते हैं Accounts includes any of ["974-3785","414-6731"] में से कोई भी शामिल है और ऊपर दिए गए और जो भी दस्तावेज़ में" 974-3785 "खाता है, यदि कोई हो।

दस्तावेज़ जितना गहरा हो उतना गहरा हो जाते हैं। PhoneNumber.Mobile एक सरणी, या यहां तक ​​कि एक उप-दस्तावेज़ ( PhoneNumber.Mobile.Work और PhoneNumber.Mobile.Personal ) पकड़ सकता है। यदि आपका डेटा अत्यधिक संरचित है, तो दस्तावेज़ संबंधित डेटाबेस से एक बड़ा कदम है।

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

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

रेडिस: कुंजी-मूल्य

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

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

user:Simon:lingots = NOTFOUND का सबसे स्पष्ट मामला लिखने पर अपडेट होता है: यदि आप user:Simon:lingots = NOTFOUND पढ़ते हैं user:Simon:lingots = NOTFOUND , आप SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon सकते हैं user:Simon:lingots = NOTFOUND SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon और स्टोर परिणाम, 100 , SET user:Simon:lingots = 100 रूप में SET user:Simon:lingots = 100 । फिर जब आप साइमन 5 लिंगों को पुरस्कार देते हैं, तो आप user:Simon:lingots = 100 पढ़ते हैं user:Simon:lingots = 100 , SET user:Simon:lingots = 105 , और UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = SimonUPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon । अब आपके पास 105 और आपके रेडिस में 105 है, और user:Simon:lingots प्राप्त कर सकते हैं user:Simon:lingots डेटाबेस user:Simon:lingots बिना user:Simon:lingots

दूसरा मामला निर्भर जानकारी अद्यतन कर रहा है। मान लें कि आप किसी पृष्ठ के भाग उत्पन्न करते हैं और उनके आउटपुट को कैश करते हैं। हेडर प्लेयर के अनुभव, स्तर और धन की राशि दिखाता है; प्लेयर के प्रोफाइल पेज में एक ब्लॉक है जो उनके आंकड़े दिखाता है; इत्यादि। खिलाड़ी को कुछ अनुभव मिलता है। खैर, अब आपके पास कई templates:Header:Simon , templates:StatsBox:Simon , templates:GrowthGraph:Simon , और आगे के क्षेत्र जहां आपने टेम्पलेट इंजन के माध्यम से आधा दर्जन डेटाबेस क्वेरीज़ के आउटपुट को कैश किया है। आम तौर पर, जब आप इन पृष्ठों को प्रदर्शित करते हैं, तो आप कहते हैं:

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

चूंकि आपने अभी GetStatsFromDatabase("Simon") के परिणामों को अपडेट किया है, इसलिए आपको templates:*:Simon ड्रॉप करना होगा templates:*:Simon आपके कुंजी-मूल्य कैश से बाहर है। जब आप इनमें से किसी भी टेम्पलेट को प्रस्तुत करने का प्रयास करते हैं, तो आपका एप्लिकेशन आपके डेटाबेस (PostgreSQL, MongoDB) से डेटा लाने और इसे आपके टेम्पलेट में डालने से दूर कर देगा; तो यह परिणाम रेडिस में संग्रहीत करेगा और उम्मीद है कि अगली बार यह आउटपुट के ब्लॉक को प्रदर्शित करने के लिए डेटाबेस क्वेरीज बनाने और टेम्पलेट्स को प्रस्तुत करने से परेशान नहीं होगा।

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

निष्कर्ष

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





redis