चाहे आप रेडिस के लिए नए हों या आपको केवल उपलब्ध सुविधाओं के पुनश्चर्या की आवश्यकता हो, यह मार्गदर्शिका आपको रेडिस द्वारा प्रदान की जाने वाली सभी डेटा संरचनाओं को समझने में मदद कर सकती है।
सही संरचना चुनें
रेडिस डेटा संरचनाएं सरल हैं - उनमें से कोई भी उस समस्या के लिए एकदम सही मिलान होने की संभावना नहीं है जिसे आप हल करने का प्रयास कर रहे हैं। लेकिन अगर आप अपने डेटा के लिए सही प्रारंभिक संरचना चुनते हैं, तो रेडिस कमांड आपको जो चाहिए उसे प्राप्त करने के कुशल तरीकों की ओर मार्गदर्शन कर सकते हैं। कई रेडिस कमांड में एक उपसर्ग होता है जो उस प्रकार की अंतर्निहित डेटा संरचना को इंगित करता है जिसके साथ वे काम करने के लिए हैं।
सामान्य-उद्देश्य डेटा संरचनाएं
| उपसर्ग | उपयोग | चेतावनी और सामान्य दुरूपयोग | |
|---|---|---|---|
| हैश | एच | वस्तु भंडारण; कुछ भी जिसके लिए आप किसी शब्दकोश वस्तु का उपयोग करेंगे | रेडिस की तरह ही, हैश के साथ उपयोगकर्ताओं का सामना करने वाली सबसे बड़ी समस्याओं में से एक प्रमुख लेखांकन है। सुनिश्चित करें कि आपके पास यह सुनिश्चित करने के लिए एक प्रणाली है कि आप अपने हैश को उन चाबियों और मूल्यों से नहीं भरते हैं जिनकी आपको आवश्यकता नहीं है। |
| सूची | एल | कतार, स्टैक और चक्रीय सूचियां | बड़ी सूचियों पर रैंडम एक्सेस करने का प्रयास न करें, और कतारों के बैकअप के बारे में सावधान रहें। |
| सेट | एस | टैगिंग सिस्टम, समय-श्रृंखला डेटा के लिए बकेट | चौराहों और संघों का उपयोग सावधानी से किया जाना चाहिए - अपने सेट छोटे रखें। सेट अद्वितीय गिनने का सबसे अच्छा तरीका नहीं है। इसके बजाय हाइपरलॉग लॉग का उपयोग करें! |
| सॉर्ट किया गया सेट | <थ>जेडस्कोरबोर्ड, शब्दावली खोज, रैंडम-एक्सेस सूचियां | Zsets सबसे बहुमुखी संरचनाओं में से एक है, और सबसे महंगी में से एक भी है। अपने बड़े ओ पर कड़ी नजर रखें! यदि आप स्वतः पूर्ण के लिए क्रमबद्ध सेट का उपयोग कर रहे हैं, तो आप ZRANGEBYLEX की जांच कर सकते हैं, जो शब्दावली खोज को संभालता है (लेकिन UTF-8 से सावधान रहें!) | |
| स्ट्रीम | एक्स | समय श्रृंखला, कतार, संदेश वितरण | स्ट्रीम को कैप करने में विफल होना आम बात है, वे कभी-कभी वितरित मैसेजिंग सिस्टम (विशेष रूप से अपाचे काफ्का) की क्षमताओं के साथ भ्रमित हो जाते हैं। |
| स्ट्रिंग | (कोई नहीं) | साधारण कैश, काउंटर, बिट हेरफेर | अत्यधिक बड़े मूल्यों के बारे में सावधान रहें, जिनकी GETting या SETting कुछ नेटवर्क और Redis क्लाइंट्स में हार्ड-टू-फाइंड विफलताओं का परिचय दे सकती है। लॉकिंग सिस्टम बनाने के लिए SETNX का उपयोग करके खुद को चोट पहुंचाना आसान है। |
विशिष्ट डेटा संरचनाएं
रेडिस विशेष प्रकार के विशेष मामलों में हेरफेर करने के लिए कई संचालन प्रदान करता है, जबकि "अंडर-द-हुड" प्रकार उपरोक्त सामान्य प्रयोजन डेटा प्रकारों में से एक है:
| उपसर्ग | अंतर्निहित प्रकार | उपयोग | चेतावनी और सामान्य दुरूपयोग | |
|---|---|---|---|---|
| बिटमैप | <थ>बिटस्ट्रिंग | एनालिटिक्स के लिए अंतरिक्ष-कुशल फ़्लैग्स | क्षमताओं के बारे में भ्रम, या बिटमैप-आधारित प्रणाली में लेखांकन की जटिलताओं का ट्रैक खोना। | |
| काउंटर | <थ>आईएनसीआर, डीईसीआरस्ट्रिंग | अंतरिक्ष-कुशल विश्लेषण | 64-बिट हस्ताक्षरित सीमा का अतिप्रवाह एक त्रुटि लौटाएगा | |
| जियोहाश | भू | सॉर्ट किया गया सेट | स्टोर लोकेटर, आस-पास के उपयोगकर्ताओं को ढूंढना | लंबी दूरी की गणना, कहीं भी विशेष अनुमानों या परिष्कृत भौगोलिक कार्यों की आवश्यकता होती है। |
| हाइपरलॉग लॉग | <थ>पीएफस्ट्रिंग | एनालिटिक्स के लिए विशिष्टताओं की गणना करना | कई HLL को एक साथ मिलाना महंगा पड़ सकता है। सुनिश्चित करें कि आपने PFMERGE में निर्दिष्ट किए गए मापदंडों की संख्या को सीमित रखा है। | |
| पब/उप | पब, सब, पीएसयूबी | (कोई नहीं) | क्षणिक संदेश गुजर रहा है | बिना स्थायित्व के सरल, तेज़ संदेश-पासिंग। अधिकांश उपयोग के मामलों के लिए स्ट्रीम प्रकार एक बेहतर विकल्प है। |
अपने बिग ओ का उपयोग करें
डेटा संरचना के एक्सेस पैटर्न का दुरुपयोग करना एक शब्दकोश का दुरुपयोग करने जैसा है:किसी शब्द को देखने के लिए हर पृष्ठ पर पलटें नहीं! प्रत्येक रेडिस कमांड की समय जटिलता redis.io पर प्रलेखित है।
बिग ओ "सीमित व्यवहार" को व्यक्त करने का एक तरीका है कि कुछ कैसे प्रदर्शन करेगा। इसके बारे में सोचने का एक सरल तरीका यह है कि सिस्टम में डेटा की मात्रा बढ़ने पर ऑपरेशन कैसा प्रदर्शन करेगा। यदि कोई ऑपरेशन O (1) है, तो उसे पूरा होने में निश्चित समय लगेगा, चाहे कितना भी डेटा शामिल हो। एक ऑपरेशन जो O(n) है, डेटा के साथ रैखिक रूप से स्केल होगा, और जो O(n²) है, वह डेटा की मात्रा बढ़ने पर तेजी से धीमा हो जाता है।
अधिक गहन उपचार के लिए, नमूना कोड और ग्राफ़ के साथ बड़े O का यह आसान परिचय देखें।
अच्छे सिस्टम डिज़ाइन में बुनियादी एल्गोरिथम विश्लेषण की तुलना में अधिक समय लगता है, लेकिन समय-समय पर बुनियादी बातों पर ध्यान देना और अपने ऐप में डेटा एक्सेस की कुल जटिलता के बारे में सोचना सार्थक है।
ऑपरेशंस को छोटा रखें
रेडिस सिंगल-थ्रेडेड है, जिसके बारे में तर्क करना आसान है, लेकिन यह केवल मल्टीथ्रेडेड डेटा एक्सेस से परिचित लोगों के लिए कुछ आश्चर्य भी पैदा कर सकता है। रेडिस में लंबे समय तक चलने वाले ऑपरेशन अन्य डेटाबेस की तुलना में अधिक खतरनाक होते हैं:चूंकि रेडिस केवल एक ही काम करता है समय, लंबे समय तक चलने वाले संचालन सिस्टम-व्यापी बैकअप का कारण बन सकते हैं।
डेटा एक्सेस ऑपरेशंस को बहुत बारीक रखना रेडिस के साथ अच्छे प्रदर्शन की कुंजी है। रेडिस में 100,000 ओ (1) संचालन एक 100,000-तत्व संग्रह पर 1 ओ (एन) संचालन के लिए बेहतर हो सकता है, भले ही आप नेटवर्क और प्रोटोकॉल पार्सिंग के कारण दंड का भुगतान कर रहे हों।
आप अपने सिस्टम में दर्द-बिंदुओं का पता कैसे लगा सकते हैं? SLOOWLOG की नियमित रूप से जाँच करें (या यदि आप एक RedisGreen ग्राहक हैं, तो बस अपने डैशबोर्ड पर "धीमी क्वेरीज़" टैब देखें)। एक एकल ऑपरेशन जितना लंबा चलता है, उतना ही धीमा वह सब कुछ करता है जो आपका सिस्टम करने की कोशिश कर रहा है, इसलिए इसे छोटा रखें!