बेंचमार्किंग MongoDB - ड्राइविंग NoSQL प्रदर्शन

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

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

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

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

बेंचमार्किंग MongoDB में विचार

1. उन कार्यभार का चयन करें जो आज के आधुनिक अनुप्रयोगों का एक विशिष्ट प्रतिनिधित्व हैं। आधुनिक अनुप्रयोग हर दिन अधिक जटिल होते जा रहे हैं और इसे डेटा संरचनाओं में स्थानांतरित किया जाता है। कहने का तात्पर्य यह है कि समय के साथ डेटा प्रस्तुति भी बदल गई है उदाहरण के लिए वस्तुओं और सरणियों के लिए सरल क्षेत्रों को संग्रहीत करना। इस डेटा के साथ डिफ़ॉल्ट या उप-मानक डेटाबेस कॉन्फ़िगरेशन के साथ काम करना बहुत आसान नहीं है क्योंकि यह खराब विलंबता और जटिल डेटा से जुड़े खराब थ्रूपुट संचालन जैसे मुद्दों तक बढ़ सकता है। बेंचमार्क चलाते समय आपको डेटा का उपयोग करना चाहिए जो आपके आवेदन की स्पष्ट प्रस्तुति है।
2. लिखने पर दोबारा जांच करें। हमेशा सुनिश्चित करें कि सभी डेटा लेखन इस तरह से किए गए थे जिससे कोई डेटा हानि न हो। यह सुनिश्चित करने के लिए डेटा अखंडता में सुधार करना है कि डेटा सुसंगत है और विशेष रूप से उत्पादन वातावरण में सबसे अधिक लागू होता है।
3. ऐसे डेटा वॉल्यूम को नियोजित करें जो "बड़े डेटा" डेटासेट का प्रतिनिधित्व करते हैं जो निश्चित रूप से एक व्यक्तिगत नोड के लिए रैम क्षमता से अधिक होगा। जब परीक्षण कार्यभार बड़ा होता है, तो यह आपके डेटाबेस के प्रदर्शन की भविष्य की अपेक्षाओं का अनुमान लगाने में आपकी मदद करेगा, इसलिए कुछ क्षमता नियोजन जल्दी शुरू करें।

पद्धति

हमारे बेंचमार्क परीक्षण में कुछ बड़े स्थान डेटा शामिल होंगे जिन्हें यहां से डाउनलोड किया जा सकता है और हम अपने डेटा में हेरफेर करने और हमें आवश्यक जानकारी एकत्र करने के लिए Robo3t सॉफ़्टवेयर का उपयोग करेंगे। फ़ाइल में 500 से अधिक दस्तावेज़ हैं जो हमारे परीक्षण के लिए पर्याप्त हैं। हम एक Ubuntu Linux 12.04 Intel Xeon-SandyBridge E3-1270-Quadcore 3.4GHz समर्पित सर्वर पर 32GB RAM, वेस्टर्न डिजिटल WD Caviar RE4 1TB कताई डिस्क और स्मार्ट XceedIOPS 256GB SSD पर MongoDB संस्करण 4.0 का उपयोग कर रहे हैं। हमने पहले 500 दस्तावेज़ सम्मिलित किए।

हमने नीचे इन्सर्ट कमांड चलाई

db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:0})
db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:1})

चिंता लिखें

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

हमारे परीक्षण में, लिखने की चिंता कम पर सेट हुई जिसके परिणामस्वरूप क्वेरी को न्यूनतम 0.013ms और अधिकतम 0.017ms में निष्पादित किया गया। इस मामले में, लेखन की मूल पावती अक्षम है लेकिन कोई भी सॉकेट अपवादों और किसी भी नेटवर्क त्रुटि के बारे में जानकारी प्राप्त कर सकता है जो ट्रिगर हो सकती है।

जब लेखन चिंता अधिक होती है, तो निष्पादन समय 0.027ms मिनट और अधिकतम 0.031ms होने के साथ लौटने में लगभग दोगुना समय लगता है। इस मामले में पावती की गारंटी है लेकिन 100% नहीं यह डिस्क जर्नल तक पहुंच गया है। इस मामले में, 100ms विंडो के कारण लिखने के नुकसान की संभावना 50% है, जहां जर्नल को डिस्क पर फ्लश नहीं किया जा सकता है।

जर्नलिंग

यह विफलता की स्थिति में स्थायित्व प्रदान करके कोई डेटा हानि सुनिश्चित करने की तकनीक है। यह ऑन-डिस्क जर्नल फ़ाइलों में राइट-फ़ॉरवर्ड लॉगिंग के माध्यम से प्राप्त किया जाता है। यह सबसे अधिक कुशल होता है जब लेखन चिंता उच्च होती है।

एक कताई डिस्क के लिए, जर्नलिंग सक्षम होने के साथ निष्पादन समय थोड़ा अधिक है, उदाहरण के लिए हमारे परीक्षण में यह उपरोक्त समान ऑपरेशन के लिए लगभग 0.251ms था।

हालांकि एसएसडी के लिए निष्पादन समय उसी कमांड के लिए थोड़ा कम है। हमारे परीक्षण में, यह लगभग 0.207ms था लेकिन डेटा की प्रकृति के आधार पर कभी-कभी यह कताई डिस्क से 3 गुना तेज हो सकता है।

जब जर्नलिंग को सक्षम किया जाता है, तो यह पुष्टि करता है कि जर्नल को लिखा गया है और इसलिए डेटा स्थायित्व सुनिश्चित करता है। नतीजतन, राइट ऑपरेशन एक मोंगॉड शटडाउन से बचेगा और यह सुनिश्चित करता है कि राइट ऑपरेशन टिकाऊ है।

एक उच्च थ्रूपुट ऑपरेशन के लिए, आप w =0 सेट करके आधा बार क्वेरी कर सकते हैं। अन्यथा, यदि आपको यह सुनिश्चित करने की आवश्यकता है कि डेटा रिकॉर्ड किया गया है या विफलता के बाद बैक-टू-लाइफ के मामले में होगा, तो आपको w=1 सेट करने की आवश्यकता है।

प्रतिकृति

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

प्रतिकृति एक विलंबता झटके के साथ आती है जैसे कि निष्पादन समय बढ़ाया जाएगा। उपरोक्त सरल क्वेरी के लिए यदि w=3, तो औसत निष्पादन समय बढ़कर 270ms हो जाता है। इसके लिए एक प्रेरक कारक नेटवर्क विलंबता से प्रभावित नोड्स के बीच प्रतिक्रिया समय की सीमा, 3 नोड्स के बीच संचार ओवरहेड और भीड़भाड़ है। इसके अलावा, सभी तीन नोड परिणाम लौटने से पहले एक दूसरे के समाप्त होने की प्रतीक्षा करते हैं। उत्पादन परिनियोजन में, इसलिए यदि आप प्रदर्शन में सुधार करना चाहते हैं तो आपको इतने सारे नोड्स को शामिल करने की आवश्यकता नहीं होगी। MongoDB यह चुनने के लिए ज़िम्मेदार है कि कौन से नोड्स को स्वीकार किया जाना है जब तक कि टैग का उपयोग करके कॉन्फ़िगरेशन फ़ाइल में कोई विनिर्देश न हो।

स्पिनिंग डिस्क बनाम सॉलिड स्टेट डिस्क

जैसा कि ऊपर उल्लेख किया गया है, एसएसडी डिस्क शामिल डेटा के आधार पर कताई डिस्क की तुलना में काफी तेज है। कभी-कभी यह 3 गुना तेज हो सकता है इसलिए जरूरत पड़ने पर भुगतान करने योग्य है। हालांकि, विशेष रूप से विशाल डेटा के साथ काम करते समय एसएसडी का उपयोग करना अधिक महंगा होगा। MongoDB को योग्यता मिली है कि यह निर्देशिकाओं में डेटाबेस को संग्रहीत करने का समर्थन करता है जिसे माउंट किया जा सकता है इसलिए SSD का उपयोग करने का मौका मिलता है। SSD का उपयोग करना और जर्नलिंग को सक्षम करना एक बेहतरीन अनुकूलन है।

निष्कर्ष

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