चाहे आप Redis में नए हों या आपको बस उपलब्ध विशेषताओं का एक रिफ्रेशर चाहिए, यह गाइड आपको Redis द्वारा प्रदान किए जाने वाले सभी डेटा स्ट्रक्चर्स को समझने में मदद कर सकता है।
सही स्ट्रक्चर चुनें
Redis डेटा स्ट्रक्चर्स सरल हैं - उनमें से कोई भी आपके द्वारा हल की जा रही समस्या के लिए एक परफेक्ट मैच होने की संभावना नहीं है। लेकिन यदि आप अपने डेटा के लिए सही प्रारंभिक स्ट्रक्चर चुनते हैं, तो Redis कमांड्स आपको कुशल तरीकों से जो आपको चाहिए उसे प्राप्त करने की दिशा में मार्गदर्शन कर सकते हैं। कई Redis कमांड्स का एक प्रीफिक्स होता है जो उस अंडरलाइंग डेटा स्ट्रक्चर के प्रकार को इंगित करता है जिसके साथ वे काम करने के लिए बने हैं।
जनरल-पर्पस डेटा स्ट्रक्चर्स
| प्रीफिक्स | उपयोग | चेतावनियां और सामान्य दुरुपयोग | |
|---|---|---|---|
| Hash | H | ऑब्जेक्ट स्टोरेज; कुछ भी जिसके लिए आप एक डिक्शनरी ऑब्जेक्ट का उपयोग करेंगे | Redis की तरह ही, हैश के साथ उपयोगकर्ताओं द्वारा सामना की जाने वाली सबसे बड़ी समस्याओं में से एक की अकाउंटिंग है। सुनिश्चित करें कि आपके पास एक सिस्टम है ताकि आप अपने हैश को उन कीज़ और वैल्यूज़ से न भरें जिनकी आपको आवश्यकता नहीं है। |
| List | L | क्यू, स्टैक और साइक्लिकल लिस्ट्स | बड़े लिस्ट पर रैंडम एक्सेस करने की कोशिश न करें, और क्यू के बैकअप होने के बारे में सावधान रहें। |
| Set | S | टैगिंग सिस्टम, टाइम-सीरीज़ डेटा के लिए बकेट्स | इंटरसेक्शन और यूनियन का उपयोग सावधानी से करें - अपने सेट्स को छोटा रखें। सेट यूनिक्स गिनने का सबसे अच्छा तरीका नहीं है। इसके बजाय HyperLogLog का उपयोग करें! |
| Sorted Set | Z | स्कोरबोर्ड, लेक्सिकोग्राफिकल सर्च, रैंडम-एक्सेस लिस्ट्स | Zsets सबसे बहुमुखी स्ट्रक्चर्स में से एक हैं, और सबसे महंगे भी। अपने बिग O पर कड़ी नज़र रखें! यदि आप ऑटोकंप्लीट के लिए सॉर्टेड सेट्स का उपयोग कर रहे हैं, तो आप ZRANGEBYLEX की जांच कर सकते हैं, जो लेक्सिकोग्राफिकल सर्च को हैंडल करता है (लेकिन UTF-8 के साथ सावधान रहें!) |
| Stream | X | टाइम सीरीज़, क्यू, मैसेज डिस्ट्रीब्यूशन | |
| String | (कोई नहीं) | सिंपल कैश, काउंटर, बिट मैनिपुलेशन | बेहद बड़े वैल्यूज़ के बारे में सावधान रहें, जिनके GETting या SETting से कुछ नेटवर्क और Redis क्लाइंट्स में हार्ड-टू-फाइंड विफलताएं आ सकती हैं। SETNX का उपयोग करके लॉकिंग सिस्टम बनाना आसान है जिससे आप खुद को नुकसान पहुंचा सकते हैं। |
विशेष डेटा स्ट्रक्चर्स
Redis विशेष मामलों में हेरफेर करने के लिए कई ऑपरेशन्स प्रदान करता है, जबकि "अंडर-द-हूड" प्रकार उपरोक्त जनरल पर्पस डेटा प्रकारों में से एक है:
| प्रीफिक्स | अंडरलाइंग प्रकार | उपयोग | चेतावनियां और सामान्य दुरुपयोग | |
|---|---|---|---|---|
| Bitmap | BIT | String | एनालिटिक्स के लिए स्पेस-एफिशिएंट फ्लैग्स | क्षमताओं के बारे में भ्रम, या बिटमैप-आधारित सिस्टम में अकाउंटिंग की जटिलताओं का ट्रैक खोना। |
| Counter | INCR, DECR | String | एनालिटिक्स के लिए स्पेस-एफिशिएंट | 64-बिट साइन्ड रेंज का ओवरफ्लो एरर लौटाएगा |
| Geohash | GEO | Sorted Set | लोकेटर स्टोर करें, आस-पास के उपयोगकर्ता खोजें | लंबी दूरी की गणना, कहीं भी जहां विशेष प्रोजेक्शन या परिष्कृत भौगोलिक फंक्शन्स की आवश्यकता हो। |
| HyperLogLog | PF | String | एनालिटिक्स के लिए यूनिक गिनना | कई HLLs को एक साथ मर्ज करना महंगा हो सकता है। PFMERGE में आपके द्वारा निर्दिष्ट पैरामीटर्स की संख्या पर एक कैप रखना सुनिश्चित करें। |
| Pub/Sub | PUB, SUB, PSUB | (कोई नहीं) | एफेमेरल मैसेज पासिंग | सिंपल, फास्ट मैसेज-पासिंग बिना ड्यूरेबिलिटी के। Stream प्रकार अधिकांश उपयोग के मामलों के लिए बेहतर विकल्प है। |
अपने बिग O का उपयोग करें
डेटा स्ट्रक्चर के एक्सेस पैटर्न का दुरुपयोग करना डिक्शनरी का दुरुपयोग करने जैसा है: एक शब्द को देखने के लिए हर पेज को न पलटें! हर Redis कमांड की टाइम कॉम्प्लेक्सिटी redis.io पर डॉक्यूमेंटेड है।
बिग O किसी चीज़ के प्रदर्शन के लिए "सीमित व्यवहार" को व्यक्त करने का एक तरीका है। इसके बारे में सोचने का एक सरल तरीका यह है कि ऑपरेशन कैसे प्रदर्शन करेगा जैसे-जैसे सिस्टम में डेटा की मात्रा बढ़ती है। यदि कोई ऑपरेशन O(1) है, तो इसे पूरा करने में एक निश्चित समय लगेगा, चाहे कितना भी डेटा शामिल हो। एक ऑपरेशन जो O(n) है, डेटा के साथ रैखिक रूप से स्केल करेगा, और एक जो O(n²) है, डेटा की मात्रा बढ़ने पर तेजी से धीमा हो जाएगा।
नमूना कोड और ग्राफ़ के साथ बिग O के आसान परिचय के लिए, इसे देखें।
अच्छा सिस्टम डिज़ाइन बेसिक एल्गोरिदम विश्लेषण से अधिक लेता है, लेकिन समय-समय पर बेसिक्स पर ब्रश करना सार्थक है, और अपने ऐप में डेटा एक्सेस की कुल कॉम्प्लेक्सिटी के बारे में सोचें।
ऑपरेशन्स को छोटा रखें
Redis सिंगल-थ्रेडेड है, जो इसके बारे में तर्क करना आसान बनाता है लेकिन उन लोगों को भी आश्चर्यचकित कर सकता है जो केवल मल्टीथ्रेडेड डेटा एक्सेस से परिचित हैं। लंबे समय तक चलने वाले ऑपरेशन्स Redis में अन्य डेटाबेस की तुलना में अधिक खतरनाक हैं: चूंकि Redis एक समय में केवल एक चीज़ करता है, लंबे समय तक चलने वाले ऑपरेशन्स सिस्टम-वाइड बैकअप का कारण बन सकते हैं।
डेटा एक्सेस ऑपरेशन्स को बहुत बारीक रखना Redis के साथ अच्छे प्रदर्शन की कुंजी है। Redis में 100,000 O(1) ऑपरेशन्स एक 100,000-एलिमेंट कलेक्शन पर 1 O(N) ऑपरेशन से बेहतर हो सकते हैं, भले ही आप नेटवर्क और प्रोटोकॉल पार्सिंग के कारण पेनल्टी का भुगतान करेंगे।
आप अपने सिस्टम में दर्द बिंदुओं का पता कैसे लगा सकते हैं? नियमित रूप से SLOWLOG जांचें (या यदि आप RedisGreen ग्राहक हैं, तो बस अपने डैशबोर्ड पर "Slow Queries" टैब देखें)। एक सिंगल ऑपरेशन जितना अधिक समय तक चलता है, उतना ही यह आपके सिस्टम द्वारा की जा रही हर चीज़ को धीमा कर देता है, इसलिए इसे छोटा रखें!
