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