एक चीज जो अन्य डेटाबेस से परिचित उपयोगकर्ताओं को अक्सर भ्रमित करती है जब वे Redis की कोशिश करते हैं, वह है डेटाबेस में दृश्यता की कमी:इसमें टेबल या संग्रह का कोई सेट नहीं होता है। देखें, बस एक सादा, सपाट कुंजी स्थान जिसमें (संभावित रूप से) लाखों चाबियां हो सकती हैं। इस प्रमुख स्थान पर सस्ते में पुनरावृति करने की क्षमता इस प्रकार डेटाबेस सामग्री से खुद को परिचित करने के लिए बहुत महत्वपूर्ण हो जाती है।
Redis कुंजी स्थान पर पुनरावृति करने से अन्य महत्वपूर्ण उपयोग के मामले भी सामने आते हैं जो दिमाग में आते हैं:
- कचरा संग्रह या एक निश्चित पैटर्न से मेल खाने वाली कुंजी को साफ करना
- डेटा संचलन और स्कीमा बदल जाता है या एक निश्चित सेट कुंजियों को किसी अन्य डेटा संरचना में स्थानांतरित कर देता है
- डिबगिंग, डेटा सैंपलिंग, डेटा फिक्स या सभी कुंजियों को ढूंढना और ठीक करना जो हाल ही में हुए बदलाव से खराब हो गए थे
इस पोस्ट में, हम Redis में उपलब्ध विभिन्न प्रमुख स्पेस इटरेशन विकल्पों के बारे में गहराई से जानेंगे।
O(N) इटरेटर:KEYS
Redis KEYS कमांड डेटाबेस में सभी कुंजियाँ लौटाता है जो एक पैटर्न से मेल खाती हैं (या की-स्पेस की सभी कुंजियाँ)। हैश में संग्रहीत सभी क्षेत्रों को लाने के लिए समान आदेश HGETALL हैं और सभी SMEMBERS के सदस्यों को लाने के लिए हैं। रेडिस में कुंजियाँ स्वयं एक शब्दकोश (उर्फ एक हैश तालिका) में संग्रहीत की जाती हैं। KEYS कमांड इस डिक्शनरी पर पुनरावृति करके और पैटर्न से मेल खाने वाली हर चीज को सिंगल एरे रिप्लाई के रूप में भेजकर काम करता है। अन्य कमांड भी इसी तरह काम करते हैं।
इस तरह के ऑपरेशन का प्रदर्शन संग्रह के आकार यानी O(N) पर निर्भर करता है। इस प्रकार, बड़ी संख्या में कुंजियों के साथ उत्पादन वातावरण में KEYS के उपयोग को गंभीर रूप से हतोत्साहित किया जाता है। रेडिस सिंगल थ्रेडेड होने के कारण, इस पुनरावृत्ति के दौरान अवरुद्ध हो जाता है और इस प्रकार अन्य कार्यों को अवरुद्ध कर देता है। इस प्रकार, कुंजी का उपयोग केवल डिबगिंग और अन्य विशेष अवसरों के लिए किया जाना चाहिए जहां प्रदर्शन कोई चिंता का विषय नहीं है (जैसे जब डेटाबेस को डेटा फिक्स लागू करने के लिए ऑफ़लाइन लाया गया हो)। इस एल्गोरिथ्म के बारे में याद रखने वाली दूसरी महत्वपूर्ण बात यह है कि यह एक ही प्रतिक्रिया के रूप में सभी मिलान कुंजियों को एक साथ भेजता है। कुंजी स्थान छोटा होने पर यह अत्यंत सुविधाजनक हो सकता है, लेकिन एक बड़े कुंजी स्थान पर कई समस्याएँ पैदा करेगा। हालाँकि, KEYS अपने स्वयं के देव वातावरण में डेवलपर्स के बीच एक पसंदीदा कमांड है।
कुंजी कार्य में:
127.0.0.1:6379[1]> MSET one 1 two 2 three 3 four 4 OK # All the keys 127.0.0.1:6379[1]> keys * 1) "four" 2) "three" 3) "two" 4) "one" # keys that begin with the letter 't' 127.0.0.1:6379[1]> keys t* 1) "three" 2) "two" # keys that have a 'ee' in them 127.0.0.1:6379[1]> keys *ee* 1) "three"
कर्सर आधारित इटरेटर:स्कैन
SCAN और इसकी सहयोगी कमांड, SSCAN (सेट के लिए), HSCAN (हैश के लिए) और ZSCAN (सॉर्ट किए गए सेट के लिए) रेडिस डेटा संरचनाओं पर पुनरावृत्ति के लिए कर्सर आधारित दृष्टिकोण प्रदान करते हैं। वे 2.8.0 से Redis में उपलब्ध हैं।
कुंजी वृद्धिशील पुनरावृत्तियों में प्रत्येक पुनरावृत्ति के लिए निरंतर समय की गारंटी के साथ लौटाई जाती हैं। एक कर्सर (एक पूर्णांक यह मामला है) तब लौटाया जाता है जब पुनरावृत्तियों को प्रारंभ किया जाता है और एक अद्यतन कर्सर लौटाया जाता है और प्रत्येक पुनरावृत्ति होती है। एक पुनरावृत्ति चक्र तब शुरू होता है जब SCAN अनुरोध में कर्सर को 0 पर सेट किया जाता है, और सर्वर द्वारा लौटाए गए कर्सर के 0 होने पर समाप्त हो जाता है। Redis आर्किटेक्चर की बारीकियों और यहां कर्सर एल्गोरिथम कार्यान्वयन के कारण इस दृष्टिकोण की कुछ ख़ासियतें हैं:
- एक पूर्ण पुनरावृत्ति हमेशा उन सभी तत्वों को पुनः प्राप्त करती है जो संग्रह में मौजूद थे, एक पूर्ण पुनरावृत्ति के प्रारंभ से अंत तक।
- एक पूर्ण पुनरावृत्ति कभी भी किसी भी तत्व को वापस नहीं लौटाती है जो संग्रह में शुरू से अंत तक पूर्ण पुनरावृत्ति के अंत तक मौजूद नहीं था।
- किसी दिए गए तत्व को कई बार लौटाया जा सकता है। डुप्लिकेट तत्वों के मामले को संभालने के लिए आवेदन पर निर्भर है
- ऐसे तत्व जो एक पूर्ण पुनरावृत्ति के दौरान संग्रह में लगातार मौजूद नहीं थे, उन्हें वापस किया जा सकता है या नहीं:यह अपरिभाषित है।
- प्रत्येक गणना के दौरान लौटाए गए तत्वों की संख्या भिन्न होती है और 0 भी हो सकती है। हालाँकि, पुनरावृत्ति तब तक पूर्ण नहीं होती जब तक सर्वर 0 का कर्सर मान नहीं लौटाता।
- COUNT विकल्प का उपयोग प्रत्येक पुनरावृत्ति में लौटाए गए तत्वों की संख्या को सीमित करने के लिए किया जा सकता है। डिफ़ॉल्ट मान 10 है। हालांकि, इसे केवल एक सुझाव माना जाता है और सभी मामलों में लागू नहीं किया जाता है। प्रत्येक पुनरावृत्ति कॉल के दौरान COUNT मान बदला जा सकता है।
- MATCH विकल्प पैटर्न को निर्दिष्ट करने की अनुमति देता है जैसे कि KEYS कमांड अनुमति देता है।
- सर्वर साइड पर कर्सर कार्यान्वयन पूरी तरह से स्टेटलेस है। यह (संभावित) अनंत पुनरावृत्तियों को समानांतर में शुरू करने की अनुमति देता है। साथ ही, यह सुनिश्चित करने की कोई आवश्यकता नहीं है कि एक पुनरावृत्ति अंत तक जारी रहे और इसे कभी भी रोका जा सके।
अपनी ख़ासियतों के बावजूद, SCAN एक बहुत ही उपयोगी कमांड है और अधिकांश उपयोग के मामलों के लिए प्रमुख स्थान पुनरावृत्तियों को चुनने के लिए सही कमांड है।
स्कैन एक बहुत ही उपयोगी कमांड है और #RedisClick To Tweet में प्रमुख स्थान पुनरावृत्तियों को चुनने के लिए सही कमांड है।स्कैन इन एक्शन
127.0.0.1:6379[1]> flushdb OK 127.0.0.1:6379[1]> keys * (empty list or set) 127.0.0.1:6379[1]> debug populate 33 OK 127.0.0.1:6379[1]> scan 0 COUNT 5 1) "4" 2) 1) "key:1" 2) "key:9" 3) "key:13" 4) "key:29" 5) "key:23" 127.0.0.1:6379[1]> scan 4 1) "42" 2) 1) "key:24" 2) "key:28" 3) "key:18" 4) "key:16" 5) "key:12" 6) "key:2" 7) "key:6" 8) "key:31" 9) "key:27" 10) "key:19" 127.0.0.1:6379[1]> scan 42 1) "9" 2) 1) "key:3" 2) "key:4" 3) "key:20" 4) "key:8" 5) "key:32" 6) "key:5" 7) "key:26" 8) "key:10" 9) "key:21" 10) "key:14" 127.0.0.1:6379[1]> scan 9 COUNT 100 1) "0" 2) 1) "key:25" 2) "key:30" 3) "key:22" 4) "key:17" 5) "key:15" 6) "key:0" 7) "key:11" 8) "key:7"
अंडर द हुड
जिस एल्गोरिथम को स्कैन करने के लिए स्कैन (और उसकी बहन कमांड) का उपयोग करता है, वह एक पेचीदा है और कमांड की कुछ विशेषताओं की ओर ले जाता है जिसका हमने ऊपर वर्णन किया है। एंटीरेज़ ने अपने ब्लॉग पोस्ट में इसे उच्च स्तर पर वर्णित किया है और इसे कार्यान्वयन (फ़ंक्शन dictScan) के ऊपर टिप्पणियों में समझाया गया है (थोड़ा बेहतर)। इसका विस्तार से वर्णन करने से यह पोस्ट बहुत लंबी हो जाएगी इसलिए मैं इसके निहितार्थ को स्पष्ट करने के लिए पर्याप्त विवरण दूंगा।
- अधिकांश Redis डेटा संरचनाएं आंतरिक रूप से शब्दकोशों के रूप में दर्शायी जाती हैं (कम से कम आंशिक रूप से क्रमबद्ध सेट के मामले में)। उन्हें टकराव के लिए जंजीर के साथ दो आकार के हैश टेबल की शक्ति के रूप में लागू किया जाता है। यहां कर्सर आधारित पुनरावृत्त एल्गोरिथम लिखने की चुनौती सरलता (एपीआई के) और गति के रेडिस सिद्धांतों का त्याग किए बिना हैश के बढ़ने और सिकुड़ने से निपटने में सक्षम होना है।
- SCAN मूल रूप से प्रत्येक पुनरावृत्ति में हैश बकेट के एक समूह को स्कैन करता है और उनमें पैटर्न से मेल खाने वाले तत्वों को लौटाता है। चूंकि यह केवल बाल्टियों की एक निश्चित सूची को देखता है, इसलिए कुछ समय के पुनरावृत्तियों से कोई मान नहीं मिल सकता है।
- लौटाया गया कर्सर मूल रूप से हैश तालिका में एक ऑफसेट है जिसे पुनरावृत्त किया जा रहा है। यह हैश टेबल के गुणों के साथ-साथ ऑफसेट को बढ़ाते हुए ऑफसेट के उच्च स्तर के बिट्स के चतुर हेरफेर द्वारा हैश टेबल (यानी रीहैशिंग) के बढ़ने और सिकुड़ने से संबंधित है। इस दृष्टिकोण से निहितार्थ यह है कि पुनरावृत्ति के दौरान जोड़े गए नए तत्व वापस आ सकते हैं या नहीं भी हो सकते हैं। हालांकि, हैश टेबल के आकार में बदलाव पर कर्सर को फिर से शुरू करने की जरूरत नहीं होगी।
- किसी दिए गए बकेट को केवल एक बार देखा जाना चाहिए और उसकी सभी कुंजियों को एक ही बार में वापस कर दिया जाना चाहिए। यह फिर से सुनिश्चित करने के लिए है कि हैश आकार बदलना (यानी रीहैशिंग) पुनरावृत्ति प्रगति को जटिल नहीं करता है। हालांकि, इसके कारण COUNT तर्क सख्ती से लागू करने योग्य नहीं है।
- चूंकि उपरोक्त दृष्टिकोण सर्वर साइड पर पूरी तरह से स्टेटलेस है, इसका मूल रूप से तात्पर्य यह है कि पुनरावृत्तियों को रोका जा सकता है या बड़ी संख्या में पुनरावृत्तियों को बिना किसी मेमोरी उपयोग के समानांतर में शुरू किया जा सकता है।
सारांश
उच्च स्तर पर, Redis कुंजी स्थान पर पुनरावृति के लिए दो विकल्प उपलब्ध हैं:
- कुंजी का उपयोग तब करें जब प्रदर्शन कोई चिंता का विषय न हो या जब कुंजी स्थान उचित रूप से आकार में हो।
- हर समय स्कैन का उपयोग करें।
क्या आप जानते हैं कि अब हम Redis™* के लिए होस्टिंग का समर्थन करते हैं? अपने स्वयं के क्लाउड खाते की सुरक्षा में Redis™ के लिए पूरी तरह से प्रबंधित होस्टिंग प्राप्त करें, और अपने Redis™ परिनियोजन के लिए AWS/Azure क्रेडिट का लाभ उठाएं।
