रेडिस: हल्का सेब

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

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

कुंजी मूल्य है

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

काउंटरों

कार्य - कुछ संस्थाएं हैं, उदाहरण के लिए, पोस्ट जिनके लिए आपको विचारों की संख्या प्रदर्शित करने की आवश्यकता है। समाधान सरल है - जब किसी पोस्ट को देखते हैं तो हम निष्पादित करते हैं

INCR post:<id> 

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

आप एक साथ कई पाने के लिए काउंटर मान प्राप्त करने के लिए GET का उपयोग कर सकते हैं, और MGET का उपयोग कर सकते हैं। पोस्ट की सूची प्रदर्शित करते समय उत्तरार्द्ध सुविधाजनक है।

सबसे ऊपर

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

 ZINCRBY post 1 <id> 

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

10 सबसे लोकप्रिय पोस्ट की आईडी पाने के लिए, बस करें:

 ZREVRANGE post 0 9 WITHSCORES 

यदि हमें विचारों की संख्या की आवश्यकता नहीं है, तो आप WITHSCORES छोड़ सकते हैं।

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

 my $x = X / 100; my %posts = ZRANGE post 0 -1 WITHSCORES; while (my ($id, $score) = each %posts) { ZINCRBY post -$score*$x $id; } 

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

साइट पर आगंतुकों की सूची

यह पारंपरिक तरीकों से लागू करने के लिए काफी परेशानी भरा काम हो सकता है। मूली के साथ - आसान। किसी तरह से, हम उपयोगकर्ता के लिए इसकी आईडी को परिभाषित करते हैं, यह वास्तव में संबंधित तालिका, सत्र आईडी या आईपी + उपयोगकर्ता आईडी से आईडी हो सकता है। एक हिट के साथ, अंतिम कॉल के समय को बचाएं:

 ZADD guys_online <unix_timestamp> <user_id> 

क्योंकि यह अभी भी बहुत कुछ है, यद्यपि आदेश दिया गया है, उसी आईडी के साथ guys_online में पिछला रिकॉर्ड बदला जाएगा और अंतिम हिट का केवल एक user_id रिकॉर्ड - टाइमस्टैम्प होगा। ऑनलाइन (अंतिम 15 मिनट में) लोगों की संख्या प्राप्त करने के लिए:

 ZCOUNT guys_online <unix_timestamp-15*60> +inf 

अपनी सूची प्राप्त करने के लिए बस ZCOUNT के बजाय ZRANGEBYSCORE का उपयोग करें। बेशक, बहुत से लोग_ऑनलाइन धीरे-धीरे दबेंगे, इसलिए हम इसे ताज में रख देंगे

 ZREMRANGEBYSCORE guys_online -inf <unix_timestamp-15*60> 

घटना विकलांग कैश

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

एक और तरीका है। कैश में कुछ बचत करते समय, अमान्य जोड़ें:

 SET <cache_key> <data> SADD <event_name1> <cache_key> # cache_key    event_name1 SADD <event_name2> <cache_key> # … event_name2 

जब Event_name इवेंट होता है, तो हम सभी निर्भर कैश कुंजियों और उन्हें इंगित करने वाले अमान्य सूचक को मिटा देते हैं:

 my @cache_keys = SMEMBERS <event_name>; DEL @cache_keys <event_name> 

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

आगे क्या है?

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