Redis प्रदर्शन को अधिकतम करना: विशेषज्ञ अंतर्दृष्टि और सर्वोत्तम प्रथाएं

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

प्रदर्शन मेट्रिक्स - क्या लेटेंसी किंग है?

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

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

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

कमांड लेटेंसी

बेशक, Redis भी नहीं है। हालांकि यहां अंतर यह है कि फ़िल्टरिंग लॉजिक, सॉर्टिंग, और कुछ भी जिसे आप एक सिंगल Redis कमांड या अधिकतम कुछ कमांड में निष्पादित नहीं कर सकते, को रखकर, आप DB को लॉजिक - और इस प्रकार "प्रोसेस करने के लिए चीजें" के साथ लोड नहीं कर रहे हैं। Redis को "डेटा स्टोर" के रूप में उपयोग किया जाना चाहिए, न कि पारंपरिक "डेटाबेस सर्वर" के रूप में। यह "Redis को धीमा न करें" का पहला पहलू है जिसे आपको समझने की आवश्यकता है। यह बताने की आवश्यकता नहीं होनी चाहिए कि एक बार जब आप Lua स्क्रिप्टिंग के रास्ते पर चलना शुरू करते हैं, तो आप नेट लोअर प्रदर्शन का जोखिम उठाते हैं। आप इसे डेवलपमेंट में नहीं देख सकते जब आपका ट्रैफिक कम से मध्यम होता है। हालांकि, जब आप बड़े पैमाने पर पहुंचते हैं तो आप इसे देखेंगे। और तब तक लॉजिक अक्सर पहले से ही बेक्ड इन होता है और एप्लिकेशन कोड में स्थानांतरित करने के लिए भारी मात्रा में तकनीकी ऋण बन जाता है। हम सभी जानते हैं कि तकनीकी ऋण को साफ करने के लिए अक्सर कितनी प्राथमिकता दी जाती है।

यह कहना नहीं है कि Lua स्क्रिप्टिंग की कोई जगह नहीं है। इसका सीधा सा मतलब है कि इसकी अत्यधिक जांच की जानी चाहिए। इस बात पर एक अच्छा नियम है कि Lua स्क्रिप्ट कब प्रदर्शन हानि है या नहीं, इसकी तुलना उस अतिरिक्त राउंड ट्रिप की लागत से करें जिसे आपको निष्पादित करना होगा यदि आप उस लॉजिक को क्लाइंट-साइड संभालते हैं। यह, हालांकि, यह नहीं है कि आपका क्लाइंट कोड इसे कितने समय में कर सकता है। इसे इस तरह से देखें: यदि आप अपने राउंड ट्रिप लागत को 2ms तक कम करते हैं, लेकिन स्क्रिप्ट निष्पादन समय में 3ms जोड़ते हैं तो आप गलत दिशा में गए।

यहां हमें सिंगल-थ्रेडेड सर्वर की प्रकृति के बारे में गहराई से जागरूक होने की आवश्यकता है। वह 3ms स्क्रिप्ट संभावित रूप से सैकड़ों (या हजारों) कमांड को ब्लॉक कर रही है जब यह निष्पादित होती है। यदि आप उन्हें (पुल) -> (लॉजिक) -> (पुल) अनुक्रम में विभाजित करते हैं तो सर्वर "लॉजिक" चरणों के दौरान अतिरिक्त अनुरोधों को प्रोसेस करने में सक्षम होता है। लॉजिक को क्लाइंट कोड में रखकर आप मल्टी-क्लाइंट आधारित सिस्टम के लिए अंतर्निहित समवर्ती को संरक्षित करते हैं। यदि आपको ट्रांजैक्शन या Lua स्क्रिप्टिंग की आवश्यकता है तो निश्चित रूप से उनका उपयोग करें। लेकिन उनका उपयोग न करें क्योंकि वे आपके कोड को "आसान" लगते हैं। हमेशा समवर्ती प्रदर्शन हिट के बारे में जागरूक रहें, इसे मापें, और चुनाव को सचेत रूप से करें।

यह हमें "Redis को धीमा न करें" के दूसरे नियम की ओर ले जाता है: स्क्रिप्ट्स के माध्यम से सर्वर लॉजिक से बचकर समवर्ती को संरक्षित करें। एक साइड लाभ Redis क्लस्टर सेटअप में माइग्रेट करने की क्षमता है बिना अपने Lua स्क्रिप्ट्स को रीराइट या डंप किए जो कई कुंजियों पर काम करते हैं।

Redis को धीमा करने के अन्य तरीके

Redis सर्वर चलाने के कुछ सिस्टम-लेवल, या ऑपरेशनल, पहलू हैं जो Redis को धीमा कर सकते हैं। I/O संसाधन सीमाओं का उपयोग करने वाले किसी भी सर्वर की तरह Redis को धीमा कर सकते हैं। उदाहरण के लिए, यदि आपको 8GB नेटवर्क बैंडविड्थ की आवश्यकता है, लेकिन 1GB है, तो यह आपके लिए "धीमा" होगा। यदि आपकी डेमॉन प्रक्रिया आपके द्वारा आवश्यक समवर्ती कनेक्शन से कम ओपन सॉकेट्स तक सीमित है तो समय कनेक्शन बंद होने की प्रतीक्षा में व्यतीत होगा बजाय कमांड निष्पादित करने के।

शायद दो सबसे आम ऑपरेशनल विकल्प जो Redis को धीमा करते हैं वे हैं 1) इसे वर्चुअल मशीन पर रखना - विशेष रूप से Xen हाइपरवाइजर आधारित एक और 2) भारी डिस्क पर्सिस्टेंस।

पहला मानक Redis साहित्य में काफी अच्छी तरह से संबोधित है: इसे Xen हाइपरवाइजर VM पर न रखें। दूसरा, पर्सिस्टेंस, ऐसा प्रतीत होता है लेकिन मेरी राय में यह पर्याप्त नहीं है।

बेशक, मानक सिफारिशें हैं: एक स्थानीय फास्ट डिस्क का उपयोग करें, सुनिश्चित करें कि पर्सिस्ट करते समय CoW डांस को संभालने के लिए आपके पास पर्याप्त मेमोरी है - यहां तक कि केवल स्लेव्स पर पर्सिस्टेंस चलाना। ये वास्तव में आपकी कमांड लेटेंसी के माध्यम से प्रभाव डाल सकते हैं। जो गायब है वह यह है कि यह कैसे ठीक से निर्धारित किया जाए कि वे हैं या नहीं।

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

पर्सिस्टेंस लेटेंसी

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

RDB अंतिम आएगा मुख्य रूप से क्योंकि इसमें N परिवर्तनों पर T सेकंड का एक अंतर्निहित विलंब है। तो, यह मानते हुए कि आपके पास उस न्यूनतम अवधि में पर्याप्त परिवर्तन हैं (सबसे छोटी डिफ़ॉल्ट विंडो 60 सेकंड है) आपकी पर्सिस्टेंस देरी अंतराल T + RDB को डिस्क पर लिखने का समय है। यदि उस मेमोरी को डिस्क पर डंप करने में डिफ़ॉल्ट 60 सेकंड अंतराल के साथ 30 सेकंड लगते हैं तो आपकी "पर्सिस्टेंस लेटेंसी" (60+30) 90 सेकंड होगी।

हालांकि, यह सवाल उठाता है कि क्या यह पर्सिस्टेंस लेटेंसी एक समस्या है। इस प्रश्न के दो पहलू हैं: 1) क्या यह आपकी व्यावसायिक आवश्यकताओं के लिए पर्याप्त है? और 2) क्या यह आपके Redis को धीमा करता है?

पहला प्रश्न वह है जिसका मैं एक सामान्य उत्तर नहीं दे सकता जो सभी का उत्तर दे। हालांकि, मैं कह सकता हूं कि यदि आपकी पर्सिस्टेंस लेटेंसी के लिए आवश्यकताएं उपरोक्त सूत्र से पता चलने वाले की तुलना में सख्त हैं तो आपको मिलने वाले उत्तर "स्लेव और/या AOF का उपयोग करें" की ओर रुझान करने की संभावना है, RDB के बजाय। यह मानता है कि आप उस प्लेटफॉर्म पर स्पष्ट गलतियां नहीं कर रहे हैं जिस पर आप Redis चलाते हैं। जो हमें दूसरे पहलू पर लाता है: क्या यह Redis को धीमा करता है?

कुछ के लिए "RDB फाइल को सेव करने में कितना समय लगता है" सवाल उनके दिमाग में सर्वोपरि हो जाता है। मेरे विचार में, यह एक गलती है। क्या यह मायने रखता है कि इसमें कितना समय लगता है? इस सवाल का जवाब है "क्या सेव Redis को धीमा करता है"। यदि नहीं, तो आपको परवाह नहीं करनी चाहिए कि इसमें 1 सेकंड लगता है या 1 घंटा। उदाहरण के लिए, सर्वर A पर विचार करें जिसे RDB सेव करने में 1000 सेकंड लगते हैं। सेव न करते समय आंतरिक कमांड लेटेंसी रेंज 30-100 माइक्रोसेकंड है। सेव के दौरान यह लेटेंसी अभी भी 30-100 माइक्रोसेकंड रेंज में है। इस मामले में, यह धारणा के तहत इस RDB सेव समय को कम करने पर काम करना समय से पहले अनुकूलन होगा कि आपके पास खराब Redis प्रदर्शन है।

हालांकि सर्वर B केवल 10 सेकंड लेता है, लेकिन कमांड लेटेंसी 30-100us से 130-250us तक कूद जाती है। अब आपके पास इस बात से चिंतित होने का कारण है कि RDB फाइल को उत्पन्न करने में कितना समय लगता है क्योंकि सेव Redis को धीमा कर रहा है और आप इसे कम से कम करना चाहते हैं। यदि इसका मतलब तेज डिस्क है, तो कम से कम अब आपके पास उन्हें उचित ठहराने का कारण है - यह मानते हुए कि लगभग 100-150 माइक्रोसेकंड की वृद्धि आपके एप्लिकेशन के लिए प्रदर्शन चिंता का कारण बनती है। यदि ऐसा नहीं होता है, तो आप समय से पहले अनुकूलन पर वापस आ गए हैं।

अब, उस लेटेंसी को कैसे मापा जाए, मैं इस पोस्ट के भाग दो में अधिक विवरण में जाऊंगा क्योंकि यह पहले ही काफी लंबा हो चुका है।