“मूल रूप से मार्च 2015 में ObjectRocket.com/blog पर प्रकाशित हुआ”
Redis® एक शानदार टूल है, और तकनीकी समुदाय इसे पसंद करता है! यह एंटीरेज़्टो से एक उद्योग-मानक इन-मेमोरी डेटा स्टोरेज होने के नाते एक छोटी व्यक्तिगत परियोजना होने से एक लंबा सफर तय कर चुका है। इसके साथ रेडिस का ठीक से उपयोग करने के लिए सर्वोत्तम प्रथाओं का एक सेट आता है। इस लेख में, हम रेडिस का सही तरीके से उपयोग करने के दस त्वरित सुझावों का पता लगाते हैं।
1. कुंजियों का उपयोग बंद करें
ठीक है, तो शायद आप पर चिल्लाना इस लेख को शुरू करने का एक अच्छा तरीका नहीं है। लेकिन यह संभवतः सबसे महत्वपूर्ण बिंदु है। बहुत बार, मैं एक Redis को देखता हूं उदाहरण के लिए, एक त्वरित commandstats खींचे , और एक आकर्षक कुंजी देखें ठीक पीछे मुझे घूर रहा है। सभी निष्पक्षता में, प्रोग्राम के दृष्टिकोण से आने पर, इस तरह के स्यूडोकोड का होना समझ में आता है:
for key in 'keys *':
doAllTheThings()
लेकिन जब आपके पास 13 मिलियन चाबियां हैं, तो चीजें धीमी होने वाली हैं। चूंकि कुंजी है O(n) जहां n लौटाई गई चाबियों की संख्या है, आपकी जटिलता डेटाबेस आकार से बंधी है। साथ ही, इस पूरे ऑपरेशन के दौरान, आप अपने उदाहरण के विरुद्ध कुछ और नहीं चला सकते।
एक विकल्प के रूप में, स्कैन देखें, जो आपको इसके बजाय वेतन वृद्धि में अपने डेटाबेस के माध्यम से स्कैन करने की अनुमति देता है। यह एक पुनरावर्तक पर संचालित होता है ताकि आप जैसे चाहें रुक सकते हैं और जा सकते हैं।
2. पता लगाएं कि Redis को क्या धीमा कर रहा है
चूंकि Redis में लॉग का सबसे अधिक वर्बोज़ नहीं है, इसलिए आपके उदाहरण के अंदर वास्तव में क्या चल रहा है, इसे ट्रैक करना अक्सर कठिन होता है। सौभाग्य से Redis आपको commandstat प्रदान करता है उपयोगिता आपको निम्नलिखित उदाहरण के समान विवरण दिखाने के लिए:
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. रेडिस-बेंचमार्क को आधार रेखा के रूप में उपयोग करें, न कि सुसमाचार सत्य के रूप में
रेडिस के निर्माता सल्वाटोर ने रेखांकित किया कि:"रेडिस का परीक्षण करने के लिए GET/SET यह देखने के लिए फेरारी का परीक्षण करने जैसा है कि बारिश होने पर दर्पण को साफ करना कितना अच्छा है।" बहुत बार, लोग मेरे पास यह सोचकर आते हैं कि उनके रेडिस-बेंचमार्क परिणाम इष्टतम से कम क्यों हैं। लेकिन हमें कई अलग-अलग कारकों को ध्यान में रखना होगा, जैसे:
- क्लाइंट-साइड सीमाएं
- संस्करण में अंतर
- चल रहे परीक्षण
रेडिस-बेंचमार्क आपके redis-server . को सुनिश्चित करने के लिए एक शानदार आधार रेखा प्रदान करता है सामान्य रूप से व्यवहार कर रहा है, लेकिन इसे कभी भी सही नहीं माना जाना चाहिए लोड परीक्षण . लोड परीक्षणों को यह प्रतिबिंबित करने की आवश्यकता है कि आपका एप्लिकेशन किसी ऐसे वातावरण में कैसे व्यवहार करता है जो उत्पादन के जितना करीब हो सके।
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 . का उपयोग करके प्रमाणीकरण कुंजी प्राप्त करते हैं उदाहरण के तौर पर, आपको अक्सर समाप्ति समय मिलता है। जब आप कुंजी सेट करते हैं, तो इसे उसी समाप्ति के साथ सेट करें, और रेडिस आपके लिए साफ़ करता है! कुंजी . की और आवश्यकता नहीं है उन सभी कुंजियों के माध्यम से पुनरावृति करने के लिए।
6. उचित निष्कासन नीति चुनना
जब हम चाबियों की सफाई के विषय पर होते हैं, तो आइए बेदखली पर ध्यान दें। जब आपका रेडिस इंस्टेंस भर जाता है, तो रेडिस कुंजी को बेदखल करने का प्रयास करता है। आपके उपयोग के मामले के आधार पर, हम अत्यधिक अनुशंसा करते हैं volatile-lru -यह मानते हुए कि आपके पास एक्सपायरी कीज़ हैं। यदि आप acache जैसा कुछ चलाते हैं और आपके पास समाप्ति सेट नहीं है, तो आप allkeys-lru पर विचार कर सकते हैं . हम अनुशंसा करते हैं कि आप यहां उपलब्ध विकल्पों की जांच करें।
7. यदि आपका डेटा महत्वपूर्ण है, तो कोशिश करें/छोड़कर . करें
यदि डेटा को आपके रेडिस इंस्टेंस में बनाना बिल्कुल महत्वपूर्ण है, तो मैं अत्यधिक try/except डालने की सलाह देता हूं . क्योंकि अधिकांश लोग Redis क्लाइंट को आग लगाने और भूलने . के लिए कॉन्फ़िगर करते हैं , आपको हमेशा इसकी योजना बनानी चाहिए जब कोई कुंजी वास्तव में डेटाबेस में नहीं आती है। यह आपके रेडिस कॉल में जो जटिलता जोड़ती है वह इस मामले में कुछ भी नहीं है, और आप यह सुनिश्चित कर सकते हैं कि आपका महत्वपूर्ण डेटा इसे वहीं बनाता है जहां उसे होना चाहिए।
8. एक बार में बाढ़ न आएं
जब भी संभव हो, कई रेडिस उदाहरणों के बीच कार्यभार को विभाजित करें। रेडिस क्लस्टर संस्करण 3.0.0 के रूप में उपलब्ध है।Redis क्लस्टर आपको प्रमुख श्रेणियों के आधार पर दिए गए प्राइमरी और सेकेंडरी के सेट के बीच की चाबियों को अलग करने में सक्षम बनाता है। आप यहां रेडिस क्लस्टर के पीछे के जादू का पूर्ण विराम पा सकते हैं। और यदि आप एक ट्यूटोरियल की तलाश में हैं, तो आगे न देखें। आप इसे यहां देख सकते हैं। यदि क्लस्टरिंग एक विकल्प नहीं है, तो कई उदाहरणों के बीच अपनी कुंजियों को नाम बदलने और वितरित करने पर विचार करें। आप Theredis.io वेबसाइट पर अपने डेटा को विभाजित करने पर एक अद्भुत लेखन पा सकते हैं।
9. अधिक कोर =बेहतर प्रदर्शन, है ना?!
गलत। रेडिस एक सिंगल-थ्रेडेड प्रक्रिया है और यदि आपके पास दृढ़ता सक्षम है, तो अधिक से अधिक दो कोर का उपभोग करेगा। जब तक आप एक ही होस्ट पर कई इंस्टेंस चलाने की योजना नहीं बनाते-उम्मीद है कि केवल देव परीक्षण के लिए, उस स्थिति में-आपको रेडिस इंस्टेंस के लिए दो से अधिक कोर की आवश्यकता नहीं होनी चाहिए।
10. हा सब कुछ!
रेडिस सेंटिनल अब बहुत अच्छी तरह से परीक्षण किया गया है, और कई उपयोगकर्ताओं के पास यह उत्पादन में चल रहा है (रैकस्पेस ऑब्जेक्ट रॉकेट शामिल है)। यदि आप अपने आवेदन के लिए रेडिस पर बहुत अधिक भरोसा करते हैं, तो आपको ऑनलाइन रखने के लिए एक उच्च उपलब्धता (एचए) समाधान पर विचार करने की आवश्यकता है। बेशक, यदि आप उन सभी को स्वयं प्रबंधित नहीं करना चाहते हैं, तो Rackspace ObjectRocket 24×7 समर्थन के साथ हमारे HA प्लेटफॉर्म की पेशकश करता है। इसे आज़माएं।
रैकस्पेस डीबीए सेवाओं के बारे में अधिक जानें।
कोई टिप्पणी करने या प्रश्न पूछने के लिए प्रतिक्रिया टैब का उपयोग करें। आप विक्रय चैट . पर भी क्लिक कर सकते हैं अभी चैट करने और बातचीत शुरू करने के लिए।
रैकस्पेस क्लाउड सेवा की शर्तें देखने के लिए यहां क्लिक करें।