रेडिस के लिए 10 त्वरित टिप्स

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

<एच3>1. कुंजियों का उपयोग करना बंद करें *

ठीक है, तो शायद आप पर चिल्लाना इस लेख को शुरू करने का एक अच्छा तरीका नहीं है। लेकिन यह संभवतः सबसे महत्वपूर्ण बिंदु है। मैं अक्सर एक रेडिस इंस्टेंस को देखता हूं, एक त्वरित कमांडस्टैट खींचता हूं, और एक चमकदार कुंजी देखता हूं जो मुझे वापस घूर रहा है। सभी निष्पक्षता में, एक प्रोग्रामेटिक दृष्टिकोण से आने से यह समझ में आता है कि एक छद्म कोड है जो कुछ ऐसा करता है:

for key in 'keys *':
  doAllTheThings()

लेकिन जब आपके पास 13 मिलियन चाबियां हैं, तो चीजें धीमी होने वाली हैं। चूँकि KEYS O(n) है जहाँ n लौटाई गई कुंजियों की संख्या है, आपकी जटिलता dbsize से बंधी हुई है। साथ ही, इस पूरे ऑपरेशन के दौरान, आपके इंस्टेंस के खिलाफ और कुछ भी नहीं चलाया जा सकता है।

एक विकल्प के रूप में, स्कैन की जाँच करें जो आपको अच्छी तरह से… इसके बजाय वेतन वृद्धि में अपने डेटाबेस के माध्यम से स्कैन करने की अनुमति देता है। यह एक इंटरएटर पर काम करता है ताकि आप जैसे चाहें रुक सकते हैं और जा सकते हैं।

<एच3>2. पता लगाएं कि Redis क्या धीमा कर रहा है

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

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

यह आपको सभी कमांड का ब्रेकडाउन देता है, उन्हें कितनी बार चलाया गया है, इसे निष्पादित करने में लगने वाले माइक्रोसेकंड की संख्या (कुल और औसत प्रति कॉल)

इसे रीसेट करने के लिए बस CONFIG RESETSTAT चलाएं, और आपको एक नया स्लेट मिल गया है।

<एच3>3. रेडिस-बेंचमार्क को आधार रेखा के रूप में उपयोग करें, सुसमाचार सत्य का नहीं

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

हम किन क्लाइंट-साइड सीमाओं का सामना कर सकते थे?
क्या संस्करण बनाने में कोई अंतर था?
क्या परीक्षण किए जा रहे हैं जो आवेदन के प्रदर्शन के लिए प्रासंगिक हैं?

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

<एच3>4. हैश आपका सबसे अच्छा दोस्त है

रात के खाने के लिए हैश को आमंत्रित करें। वाइन और डाइन हैश। आपको आश्चर्य होगा कि अगर आप उन्हें मौका दें तो वे क्या खुशी ला सकते हैं। मैंने पहले भी इस तरह की कई प्रमुख संरचनाएं देखी हैं:

foo:first_name
foo:last_name
foo:address

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

127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379> HGET foo first_name
"Joe"

5. वह टीटीएल सेट करें!

जब भी संभव हो, समाप्त होने वाली चाबियों का लाभ उठाएं। एक आदर्श उदाहरण अस्थायी प्रमाणीकरण कुंजी की तरह कुछ संग्रहीत कर रहा है। जब आप प्रमाणीकरण कुंजी प्राप्त करते हैं—चलो OAUTH को एक उदाहरण के रूप में उपयोग करते हैं—तो आपको अक्सर एक समाप्ति समय दिया जाता है। जब आप कुंजी सेट करते हैं, तो इसे उसी समाप्ति के साथ सेट करें, और रेडिस आपके लिए साफ कर देगा! KEYS * को उन सभी कुंजियों के माध्यम से पुनरावृति करने की कोई आवश्यकता नहीं है, एह?

<एच3>6. उचित निष्कासन नीति चुनना

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

7. यदि आपका डेटा महत्वपूर्ण है, कोशिश करें/छोड़कर

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

8. एक बार बाढ़ न करें

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

9. अधिक कोर =अधिक बेहतर, है ना?!

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

<एच3>10. हा ऑल द थिंग्स!

रेडिस सेंटिनल अब बहुत अच्छी तरह से परीक्षण किया गया है, और कई उपयोगकर्ता इसे उत्पादन में चला रहे हैं (ऑब्जेक्ट रॉकेट शामिल है!) यदि आप अपने आवेदन के लिए रेडिस पर बहुत अधिक निर्भर हैं, तो आपको ऑनलाइन रखने के लिए एचए (उच्च उपलब्धता) समाधान पर विचार करने की आवश्यकता है। बेशक, अगर आप इन सबका प्रबंधन खुद नहीं करना चाहते हैं, तो ObjectRocket आपके उपभोग के लिए 24×7 समर्थन के साथ हमारे HA प्लेटफॉर्म की पेशकश करता है, इसे आजमाएं।