डेटाबेस प्रश्न:भूसे के ढेर में सुई कैसे खोजें?

बड़े डेटा के लिए पोस्टर चाइल्ड परिदृश्य - आपको एक छोटे से डेटा को निकालने के लिए बड़ी मात्रा में डेटा को छानने की आवश्यकता है " जानकारी का डला ”। साथ ही, इसे यथासंभव कम से कम समय में करने की आवश्यकता है, आपका व्यवसाय इस पर निर्भर करता है। ऐतिहासिक रूप से, पारंपरिक रिलेशनल डेटाबेस मैनेजमेंट सिस्टम (RDBMS) तकनीक का उपयोग करते हुए, इस तरह के परिदृश्य के लिए एक बड़ी टीम और समय और धन के निवेश की आवश्यकता होती है। अधिकांश पारंपरिक RDBMS का एकमात्र पैमाना लंबवत है, इसलिए आपको अपने टर्नअराउंड समय को कम करने के लिए बड़ी और बड़ी मशीनें खरीदते रहना होगा। सार्वजनिक क्लाउड और मोंगोडीबी जैसे नोएसक्यूएल डेटाबेस के आगमन ने इस परिदृश्य के बारे में टीमों के सोचने के तरीके को पूरी तरह से बाधित कर दिया है।

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

• कुल डेटा लगभग 100GB था।
• डेटा सुरक्षा कोई समस्या नहीं थी क्योंकि डेटा की मास्टर कॉपी कहीं और रहती थी।
• क्वेरी स्पीड बेहद महत्वपूर्ण थी। लक्ष्य 10-15 मिनट के भीतर पूरी क्वेरी को चलाने में सक्षम होना था।
• सिस्टम को केवल तभी चालू होना चाहिए जब क्वेरी चल रही हो (लागत कम करें)।

आखिरी आवश्यकता के कारण, पूरे सिस्टम को एक सार्वजनिक क्लाउड पर चलाना समझ में आया। डेटा को अपडेट करने और क्वेरी चलाने के लिए मशीनें हर हफ्ते केवल कुछ घंटों के लिए चालू होती हैं। ग्राहक पहले से ही Amazon EC2 के साथ सहज था, इसलिए AWS में सिस्टम को प्रोटोटाइप करने का निर्णय लिया गया।

इस लक्ष्य को प्राप्त करने के लिए सबसे अच्छा कॉन्फ़िगरेशन एक "शार्डेड" MongoDB परिनियोजन था। यहां वह कॉन्फ़िगरेशन है जिस पर हमने समझौता किया है:

• 3 शार्प - प्रत्येक शार्क में 30 जीबी रैम के साथ एक स्टैंडअलोन इंस्टेंस (r3.xlarge) होता है
• 1 कॉन्फ़िगरेशन सर्वर
• 15 जीबी रैम के साथ 1 शार्प राउटर (एम3.एक्सलार्ज)

हमारी पसंद के बारे में कुछ बातें:

• स्टैंडअलोन बनाम रेप्लिका सेट

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

• 3 कॉन्फ़िग सर्वर बनाम 1 कॉन्फ़िग सर्वर

  ऊपर के रूप में कारण हूँ। डेटा सुरक्षा कोई महत्वपूर्ण मुद्दा नहीं है। एक विशिष्ट उत्पादन वातावरण में हम तीन कॉन्फिग सर्वर के साथ जाते।

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

यह काफी नाटकीय बदलाव है कि टीमें पिछले एक दशक में इस परिदृश्य को कैसे संभाल रही हैं। इसलिए, यदि आप "भूसे के ढेर में सुई ढूंढ़ रहे हैं" व्यवसाय में हैं, तो Cloud + NoSQL के बारे में सोचें!

हमेशा की तरह, यदि आपके कोई प्रश्न हैं, तो आप [email protected] पर हमसे संपर्क कर सकते हैं।