विश्लेषणात्मक बुनियादी ढांचे का विकास (जारी)

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

भाग 3. वर्तिका। बस फास्ट

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

शुरुआत करने के लिए, वर्टिका में कई स्पष्ट चीजें नहीं हैं। यह आश्चर्य के रूप में आ सकता है, लेकिन कई लोकप्रिय SQL डेटाबेस की तुलना में वर्टिका में, कोई नहीं है:

• संग्रहीत कार्यविधियाँ और गैर-नियतात्मक कार्य
• सख्त बाधाएं - यानी, आप उन रिकॉर्ड्स को जोड़ सकते हैं जो बाधाओं का उल्लंघन करते हैं
• स्तंभों को हटाने की क्षमता
• सूचकांक
• कैश

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

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

भौतिक डेटा संग्रहण को व्यवस्थित करने के कई तरीकों द्वारा विश्लेषणात्मक प्रश्नों का उच्च प्रदर्शन प्रदान किया जाता है:

• कॉलम-ओरिएंटेड डेटा स्टोरेज
• कुछ प्रकार के प्रश्नों के लिए कॉलम संग्रहण अनुकूलित है
• विभिन्न कार्यों के लिए कई भौतिक तालिका विचारों को अनुकूलित करने की क्षमता
• क्लस्टर रेखीय स्केलिंग, एमपीपी - बड़े पैमाने पर समानांतर प्रसंस्करण, अर्थात्, एक अनुरोध सभी क्लस्टर नोड्स और सभी प्रोसेसर के लिए एक साथ समानांतर किया जा सकता है

आइए हम इन तरीकों पर ध्यान दें और वे प्रदर्शन को और अधिक विस्तार से कैसे प्रभावित करते हैं।

कॉलम-ओरिएंटेड स्टोरेज

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

विशिष्ट स्तंभ एन्कोडिंग विधियाँ

वर्टिका में कॉलम कोडिंग का उपयोग दो उद्देश्यों के लिए किया जाता है:

• डिस्क पर डेटा के आकार को कम करना, जिससे रीड-राइट को गति मिलती है
• एक डिस्क पर डेटा रखना ताकि फ़िल्टरिंग, जॉइन, ग्रुपिंग, सॉर्टिंग और अन्य मानक संचालन करना सुविधाजनक हो

जैसा कि आपको याद है, वर्टिका में कोई इंडेक्स नहीं हैं। इसके बजाय, डिस्क पर डेटा स्वयं "स्टैक्ड" होता है ताकि इसे जल्दी से ढूंढा जा सके। स्टाइलिंग विधि को प्रक्षेपण कहा जाता है। यह एक संकेत है कि सभी कॉलम प्रक्षेपण में नहीं हो सकते हैं, लेकिन हम बाद में इस पर लौट आएंगे। एक त्वरित खोज ऑर्डर (ऑर्डर द्वारा) और आरएलई (रन लेंथ एन्कोडिंग, यानी एक पंक्ति में एक मूल्य के दोहराव की संख्या को एन्कोडिंग) द्वारा प्राप्त की जाती है। आदेश के साथ काम करने वाला RLE एक उदाहरण के साथ प्रदर्शित करना सबसे आसान है। कल्पना कीजिए कि एक टेबल है जिसमें event_date, राशि और अन्य 100 फ़ील्ड हैं। एक वर्ष में 365 दिन होते हैं। प्रत्येक दिन में 1 बिलियन प्रविष्टियाँ होती हैं। यदि एक विशिष्ट अनुरोध किसी अवधि (दिन, सप्ताह, आदि) के लिए धन की गणना करने के लिए है, तो हम event_date के लिए RLE एन्कोडिंग का उपयोग event_date द्वारा क्रमबद्ध करते हैं। यदि आप event_date द्वारा तालिका को सॉर्ट करते हैं, तो Event_date कॉलम में 1,000,000,000 समान मानों के ब्लॉक होंगे। RLE कोडिंग का मतलब है कि भौतिक रूप से प्रत्येक दिन के लिए event_date कॉलम के लिए डिस्क पर केवल पुनरावृत्ति की तारीख और संख्या (हमारे मामले में एक अरब) होगी। प्रति वर्ष इस तरह के 365 रिकॉर्ड हैं। एक डिस्क से उठना और एक को ढूंढना एक अलग विभाजन का मामला है। Event_date रिकॉर्ड में स्तंभ के बाकी हिस्सों के साथ एक पॉइंटर जैसा कुछ होता है। यही है, “select sum(amount) from t where event_date='2012-07-01'” करने के लिए, बस Event_date कॉलम पढ़ें, और फिर वांछित तिथि से संबंधित राशि का ब्लॉक या ब्लॉक। यह बहुत तेज है। यह स्पष्ट है कि RLE के साथ कई ऑर्डर किए गए कॉलम हो सकते हैं। और यह भी स्पष्ट है कि इस तरह की एक कोडिंग विधि उन स्तंभों के लिए सबसे उपयुक्त है जहां कई अद्वितीय मूल्य नहीं हैं। माप के लिए क्या विशिष्ट है।

सामान्य तौर पर, यह कुछ हद तक सूचकांक के समान होता है। हालाँकि, यह थोड़े अलग तरीके से काम करता है। कल्पना करें कि हमारे पास अभी भी कॉलम account_type (दो मान) और, कहते हैं, विभाग (पाँच मान) हैं। और उन्हें अक्सर खोज भी करनी पड़ती है। अनुक्रमित के मामले में, मुझे प्रत्येक मामले के लिए, अलग-अलग करना होगा। और वर्टिका में, एक प्रक्षेपण पर्याप्त है, जो उनमें से किसी भी संयोजन में सभी तीन स्तंभों को खोजने के लिए काम करेगा। उदाहरण के लिए, निम्न आदेश के साथ: account_type, विभाग, event_date द्वारा आदेश। RLE एन्कोडिंग वाले सभी कॉलम। ऐसा लगता है कि इस तरह से Event_date "ब्रेक" की खोज हो सकती है। Account_type, विभाग, event_date पर सूचकांक के साथ, यह ऐसा होगा। हालाँकि, वर्टिका के मामले में, Event_date के अनुरोध को पिछले उदाहरण की तुलना में केवल थोड़ा धीमा निष्पादित किया जाएगा ... एक Event_date ब्लॉक के बजाय, अब आपको उनमें से दस को पढ़ना होगा (2 account_type * 5 विभाग, प्रत्येक में "your" event_date ढूंढें, और संबंधित ब्लॉक पढ़ें। राशि। RLE के कारण event_date ब्लॉकों के छोटे आकार को देखते हुए, यह अंतर लगभग अदृश्य होगा।

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

खोज के अलावा, RLE एन्कोडिंग का उपयोग समूह में सॉर्टिंग को गति देने के लिए भी किया जाता है, क्योंकि डेटा पहले से ही इस तरह से व्यवस्थित होता है कि कभी-कभी इसे सॉर्ट करना आवश्यक नहीं होता है। जैसा कि एक खोज के मामले में, त्वरण (तथाकथित पाइपलाइड समूह) द्वारा भी होता है यदि समूह द्वारा प्रक्षेपण में पहली स्थिति में नहीं है।

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

कोडिंग के अलावा, वर्टिका डेटा के पारंपरिक विभाजन का भी समर्थन करता है, और, तदनुसार, विभाजन उन्मूलन या विभाजन छंटाई, जो कुछ मामलों में डिस्क से पढ़ने वाले डेटा की मात्रा को और कम कर सकता है।

विभिन्न कार्यों के लिए कई भौतिक तालिका विचारों को अनुकूलित करने की क्षमता

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

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

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

रैखिक स्केलिंग। एमपीपी

ऊर्ध्वाधर पैमाने लगभग मात्रा में रैखिक:

• सीडी
• कोर
• सर्वर

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

प्रदर्शन के अलावा, क्लस्टर आपको दोष सहिष्णुता को कॉन्फ़िगर करने की अनुमति देता है। इस स्थिति में, प्रत्येक डेटा ब्लॉक को क्लस्टर के विभिन्न नोड्स पर दो या अधिक उदाहरणों में संग्रहीत किया जाता है। दोहराव स्तर को K- सुरक्षा स्तर कहा जाता है। मानक स्तर 1 के साथ, क्लस्टर सबसे अच्छे मामले में एक (गारंटीकृत) से फर्श (एन / 1) नोड्स के नुकसान का अनुभव करता है। हालांकि, हमने पाया कि कुछ (सभी नहीं) प्रकार के अनुरोधों के लिए एक या एक से अधिक नोड्स के साथ क्लस्टर का प्रदर्शन (परिमाण के आदेशों) से काफी कम हो सकता है। वर्टिकोवेट्स ने पुष्टि की कि यह एक बग है और इसे ठीक किया जाएगा (पहले से ही वर्टिका 6), और हम अनुरोधों को बदलने में सक्षम थे ताकि इस समस्या में न पड़ें। वैसे, लोहे अक्सर टूट जाता है, और हमें बार-बार "लंगड़ा" क्लस्टर पर रहना पड़ता है।

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

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

ऊर्ध्वाधर विस्तार

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

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

• Google बिग क्वेरी - सबसे तेज़, क्वेरी में कुछ मिनट लगे। मुझे मना करना पड़ा, क्योंकि Google उनकी सेवा के लिए बहुत सारे पैसे चाहता था (यह प्रति अनुरोध कई सौ डॉलर निकला)। यहां हमने md5 विज़िटर पहचानकर्ता का उपयोग किया; अन्य मामलों में, एक 8-बाइट int। यानी जीबीक्यू और भी तेज हो सकता है। एक अलग समस्या डेटा लोडिंग है।
• वर्टिका अच्छे हार्डवेयर पर एक फ्री-स्टैंडिंग सर्वर (क्लस्टर नहीं) है, जो केवल इस कार्य के लिए उपयोग किया जाता था। अनुरोध को पूरा होने में लगभग 15 मिनट लगते हैं। यदि ऐसी आवश्यकता होती तो कार्य को काफी हद तक समानांतर किया जा सकता था। गति हमारे अनुकूल है।
• 1-थ्रेड प्लेन जावा। 2 घंटे एक रन और HashMap।
• Hadoop (क्लस्टर नहीं)। सुअर के लिए अनुरोध। माथे पर लगभग 8-10 घंटे। स्थानीय रूप से डेटा भंडारण और सभी कोर लोड करने के साथ - 2 घंटे (जो कि एकल-थ्रेडेड जावा एप्लिकेशन के तुलनीय है)। संभवतः, एक क्लस्टर के विस्तार से रैखिक में वृद्धि होगी या रैखिक में वृद्धि होगी। लेकिन वर्टिका के साथ अंतर अभी भी बहुत बड़ा है।

इस प्रयोग के परिणामस्वरूप, जो हमारे लिए काफी आकस्मिक है, हम आश्वस्त थे कि एकीकरण काम कर रहा था, और Hadoop, जैसा कि अपेक्षित था, धीमा था। सुअर / छत्ता पर सीधे प्रश्न लिखने का लाभ संदिग्ध है, और यह पूरी तरह से अनुपस्थित है जब एसक्यूएल के संदर्भ में एक ही कार्य को व्यक्त किया जा सकता है। शायद हमारे पास अभी भी ऐसे कार्य होंगे जहां एक पूर्ण-विकसित MapReduce की आवश्यकता होती है।

हडोप केवल वर्टिका की कार्यक्षमता को बढ़ाने का एकमात्र तरीका नहीं है। कार्यक्षेत्र आपको C ++ में UDF लिखने की अनुमति देता है, जिसमें इसके समग्र और विश्लेषणात्मक कार्य शामिल हैं, और नवीनतम संस्करण में यह R भाषा के साथ एकीकरण प्रदान करता है। हमने R से पहले (और यहां तक ​​कि J के साथ एक दिलचस्प अभ्यास के रूप में) को एकीकृत करने का प्रयास किया, इस पर समस्याओं को हल किया। SQL के संदर्भ में जटिल। इसके लिए, हमने ODBC या अपनी स्वयं की REST सेवा का उपयोग किया। अब यह एकीकरण और भी सरल हो गया है।

निष्कर्ष

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

लेकिन समय अभी भी खड़ा नहीं है, हम मल्टी-टियर डेटावेयरहाउस या इन-मेमोरी ओएलएपी जैसे कुछ होने की आवश्यकता के बारे में सोच रहे हैं। लेकिन अगले लेख में उस पर और अधिक।

PS 11 जुलाई, मैं मास्को में हमारी बैठक में वर्टिका के बारे में किसी भी प्रश्न का उत्तर दे सकता हूं: habrahabr.ru/events/836