बड़े पैमाने पर समानांतर डेटाबेस ग्रीनप्लम - एक छोटा शैक्षिक कार्यक्रम

Hadoop और Greenplum के लिए तैयार सास लेने का अवसर है। और अगर खड़प एक जानी-मानी चीज़ है, तो ग्रीनप्लम (यह एरेनाडाटाबीडी उत्पाद का आधार है, जिस पर बाद में चर्चा की जाएगी) दिलचस्प है, लेकिन पहले से ही "कान से कम" है।

अरेंडाटा डीबी एक वितरित डीबीएमएस है जो ओपन सोर्स ग्रीनप्लम पर आधारित है। अन्य MPP (समानांतर डेटा प्रोसेसिंग) समाधानों की तरह, व्यापक समानांतर प्रणालियों के लिए, क्लाउड आर्किटेक्चर इष्टतम से बहुत दूर है। यह प्रदर्शन को 30% तक कम कर सकता है (आमतौर पर कम)। लेकिन, फिर भी, इस समस्या को समतल किया जा सकता है (जिसकी चर्चा नीचे की जाएगी)। इसके अलावा, यह क्लाउड से ऐसी सेवा खरीदने के लायक है, अक्सर यह आपके अपने क्लस्टर की तैनाती की तुलना में सुविधाजनक और लाभदायक है।

गाइड में ऑन-प्रिमाइसेस को स्पष्ट रूप से इंगित किया गया है, लेकिन अब कई लोगों को बादल की सुविधा के पैमाने का एहसास होता है। हर कोई समझता है कि प्रदर्शन में किसी प्रकार की गिरावट होगी, लेकिन यह अभी भी इतनी सुपर सुविधा और गति है कि पहले से ही परियोजनाएं हैं जहां कुछ परिकल्पनाओं जैसे परीक्षण पर यह बलिदान किया जाता है।

यदि आपके पास 1 से अधिक टीबी का डेटा वेयरहाउस है और ट्रांजेक्शन सिस्टम आपकी लोड प्रोफाइल नहीं है, तो नीचे एक कहानी है कि विकल्प के रूप में क्या किया जा सकता है। 1 टीबी क्यों? इस मात्रा से शुरू करते हुए, MPP का उपयोग प्रदर्शन / लागत अनुपात के मामले में क्लासिक DBMS के साथ तुलना में अधिक कुशल है।

कब करें इस्तेमाल?

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

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

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

कुछ लोग क्यों कोशिश कर रहे हैं?

किसी भी MPP DBMS को बहुत अधिक क्षमता की आवश्यकता होती है। वह बहुत सारा लोहा है। वास्तव में, लोग प्रवेश मूल्य के कारण केवल अवधारणा के प्रमाण के स्तर पर प्रयास करने से डरते हैं। वे शारीरिक रूप से ऐसा नहीं कर सकते। हमारे सास के मुख्य विचारों में से एक आपको लोहे के क्लस्टर खरीदने के बिना यह सब खेलने का अवसर देना है।

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

एमपीपी पर सबसे अच्छी बात क्या है?

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

क्लाउड समाधान के बारे में कुछ और शब्द

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

पहला खराब नेटवर्क प्रदर्शन है। चूंकि यह सब एक आभासी वातावरण में बादल में हो रहा है, इसलिए एक हाइपरवाइज़र पर कई मशीनें हो सकती हैं। वर्चुअल मशीनें अलग-अलग हाइपरविजर में बिखरी जा सकती हैं। इसके अलावा, कुछ क्षणों में वे अलग-अलग डेटा केंद्रों में बिखरे हुए हो सकते हैं, पर्यवेक्षक उन पर लगभग स्पिन कर सकते हैं। और इसकी वजह से नेटवर्क को काफी नुकसान होता है। एक तालिका में एक अरब रिकॉर्ड संसाधित करते समय, मान लें कि 10 सर्वर हैं, और यह सभी सर्वरों के बीच इस डेटा को चलाता है। एक उप-प्रजाति अंदर काम करती है, और एक सर्वर के अंदर भी ऐसी कई उप-प्रजातियाँ काम करती हैं। 10-20 हो सकते हैं, और अब वे सभी अनुरोध के निष्पादन के दौरान नेटवर्क पर डेटा ड्राइव करना शुरू करते हैं। नेटवर्क सर्दियों की फसलों की तरह गिर रहा है। इससे क्या निष्कर्ष निकाला जा सकता है? उच्च बैंडविड्थ वाले क्लाउड का उपयोग करें, जैसे कि CROC Cloud, जो Infiniband पर 56 GB देता है।

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

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

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

और इसकी अपनी वास्तुकला के कारण, क्लाउड में ग्रीनप्लम Redshift, BigQuery और स्नोफ्लेक की तुलना में दक्षता में बेहतर प्रदर्शन करता है।

परिनियोजन कैसा दिखता है:


इस तरह:





वास्तुकला "सांस लेने योग्य" है, अर्थात, आप कॉन्फ़िगरेशन में एक साधारण कारक को जल्दी से तैनात कर सकते हैं। एक उदाहरण के रूप में, दोपहर में हमारे पास पाँच सीपीयू होते हैं, और शाम को हमारे पास 1,000 हैंडलर बढ़ते हैं, और दस सीपीयू काम करते हैं। इस मामले में, आपको डेटा को संतुलित करने की आवश्यकता नहीं है, क्योंकि वे एक ही स्टोर के अंदर झूठ बोलते हैं। एक एक्सटेंशन बॉक्स से बाहर उपलब्ध है, त्वरित संपीड़न को अभी भी थोड़ा पूरा करने की आवश्यकता है।



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

हमने पहले आंतरिक परियोजनाओं पर इस तरह के दृष्टिकोण की सुविधा को समझा, और फिर ग्राहकों को सास प्रदान करना शुरू किया। एस 3 के साथ हमारा गहरा एकीकरण है - यह आपको ग्रीनप्लम को कंप्यूटिंग और स्टोरेज के लिए अलग-अलग परतों के साथ एक प्रणाली के रूप में उपयोग करने की अनुमति देता है, या बैकअप के लिए एस 3 का उपयोग करता है, और ग्रीनप्लम क्लाउड में क्यूसीडी के रूप में उपयोग किया जाता है। CROC API और ADCM API का उपयोग करके एंटरप्राइज़ के लिए वातावरण का एक लचीला परिनियोजन है।