एचपी वर्टिका, रूसी संघ में पहली बार शुरू की गई परियोजना, वास्तविक संचालन का डेढ़ साल का अनुभव है

एक परिचय के रूप में

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

जिनके लिए यह उपयोगी होगा

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

एक पैराग्राफ में कि हमने कैसे चुना

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

वेरिका एक वास्तुकार के दृष्टिकोण से कैसा दिखता है

वर्टिका में डेटा वेयरहाउस के लिए आर्किटेक्ट सबसे महत्वपूर्ण व्यक्ति है। सबसे पहले, डेटा वेयरहाउस के कामकाज की सफलता और उत्पादकता इस पर निर्भर करती है। आर्किटेक्ट के दो जटिल कार्य हैं: वर्टिका क्लस्टर की तकनीकी भराई का चयन करना और डेटाबेस के भौतिक मॉडल को सही ढंग से डिजाइन करना।

तकनीकी वास्तुकला से क्या प्रभावित होता है

मैं अपनी व्यक्तिगत भावनाओं को देता हूं क्योंकि मेरी आलोचना कम हो जाती है:

1. एक एमपीपी सर्वर के रूप में, सबसे पहले वर्टिका को नेटवर्क वास्तुकला के लिए सख्त आवश्यकताएं हैं। यदि आपके पास क्लस्टर में 3 सर्वर और 3 टीबी का आधार है, तो उनके और उपयोगकर्ताओं के बीच डेटा विनिमय विशेष रूप से नेटवर्क लागतों में ध्यान देने योग्य नहीं है। यदि आपके पास 6 सर्वर और 30 टेराबाइट डेटा का डेटाबेस है, तो चरम भार पर नेटवर्क पूरे क्लस्टर ऑपरेशन का सबसे कमजोर बिंदु बन सकता है। और कल्पना करें कि आपके पास 100 सर्वर और 1 से अधिक पेटाबाइट का डेटाबेस है? डरावना? :)
2. क्लस्टर सर्वरों के स्थानीय डिस्क पर उचित रूप से इकट्ठे हुए सरणियाँ प्रदर्शन, भंडारण की मात्रा और लोहे की लागत के बीच सफल संतुलन की गारंटी देते हैं। सस्ते धीमी डिस्क पर RAID RAID, लेकिन एक बड़ी मात्रा के साथ? सस्ता और हंसमुख, लेकिन धीरे-धीरे। तेजी से डिस्क पर सब कुछ इकट्ठा किया, लेकिन कम मात्रा के साथ? डेटाबेस के लिए महंगी, तेज, लेकिन पर्याप्त जगह नहीं है, फिर भी आपको सर्वर को क्लस्टर से कनेक्ट करना होगा। हम वर्टिका में फ्लेक्स तकनीक पर प्रलेखन पढ़ते हैं, क्लस्टर सर्वरों पर तेज और धीमी डिस्क लटकाते हैं, फिल्टर और रिटर्न डेटा के रूप में प्रश्नों में उनकी भागीदारी द्वारा टेबल कॉलम (अनुमान) के भंडारण को वितरित करते हैं? अच्छा किया, काम के लिए इष्टतम क्लस्टर मिला। यदि आप सर्वर में स्थानीय फास्ट डिस्क जोड़ते हैं और वहां वर्टिका टेम्प स्पेस को बाहर निकालते हैं, तो सब कुछ सुपर लगेगा।
3. यह रहस्य खुला है: इसमें कभी भी बहुत अधिक मेमोरी नहीं होती है और यह बड़ी मात्रा में रैम के साथ एक सर्वर खरीदने के लिए सस्ता होता है, ताकि इसे बाद में मौजूदा सर्वर तक पहुंचाया जा सके। यह याद रखने योग्य है कि अरबों डेटा रिकॉर्ड के लिए विश्लेषणात्मक प्रश्न बहुत सारी मेमोरी चाहते हैं, कोई भी रद्द भौतिकी नहीं है। आसानी से एक विश्लेषक का एक सत्र 20 गीगाबाइट तक मेमोरी खा सकता है। अपने विश्लेषकों की गणना करें, उन भारी अनुरोधों की गणना करें जिन्हें आपका ईएलटी पूरा करेगा और घबराना शुरू नहीं करेगा और मेमोरी की टेराबाइट खरीदने के बारे में सोचें। वर्टिका संसाधन पूल के साथ संसाधन उपयोग भार को सफलतापूर्वक संतुलित कर सकता है। क्लस्टर में सर्वर की संख्या से विभाजित डेटा भंडारण की अनुमानित मात्रा के आधार पर, अनुमानित लोड को ध्यान में रखते हुए, आप क्लस्टर सर्वर पर रैम आकार का सुनहरा मतलब चुन सकते हैं और संसाधन पूल के बीच अंतर करके चोटी के भार से सुरक्षित हो सकते हैं।
4. सिबेस आईक्यू के बाद वर्टिका में मुझे हमेशा आश्चर्य होता है कि इसका सीपीयू लोड कितना कम है। यदि भारी प्रश्नों के निष्पादन के दौरान आईक्यू, सभी प्रोसेसर पूर्णकालिक रूप से काम कर रहे हैं, तो वर्टिका के साथ समान शर्तों के तहत वे ऐसे दिखते हैं जैसे वे साइबेस की पृष्ठभूमि के खिलाफ छुट्टी पर आराम कर रहे हैं। इसके अलावा, दोनों सर्वर स्तंभ-उन्मुख हैं, दोनों डेटाबेस में संग्रहीत होने पर सभी डेटा को संपीड़ित करते हैं। चमत्कार, और केवल वह, लेकिन तथ्य यह है कि वर्टिका सबसे महत्वपूर्ण स्थान नहीं है, हालांकि मुझे आशा है कि आप इसे इस तथ्य के लिए एक गाइड के रूप में नहीं लेते हैं कि 2 कोर पर्याप्त हैं। कोई चमत्कार नहीं है: जैसा कि कहीं और है, चल रहे प्रश्नों को कोर लेते हैं, एक भारी क्वेरी अपने निष्पादन को कई थ्रेड्स में समानांतर कर सकती है और कई कोर ले सकती है। इसलिए, हम अपेक्षित लोड पर ध्यान केंद्रित करते हुए क्लस्टर सर्वर कोर की संख्या का चयन करते हैं।

भौतिक डेटाबेस मॉडल से क्या प्रभावित होता है

महत्वपूर्णता के स्तर को नीचे रखना मुश्किल है, सब कुछ महत्वपूर्ण है, इसलिए सूची गिने नहीं है:

• सिबेस आईक्यू की पृष्ठभूमि के खिलाफ, वर्टिका आश्चर्यजनक रूप से प्रभावी रूप से बड़े टेबल के जॉय के साथ काम करता है, लेकिन फिर भी स्तंभ-उन्मुख डीबीएमएस मूल रूप से अतिरिक्त कनेक्शन से छुटकारा पाने और डेटा योजनाओं को सरल बनाने के लिए उन्मुख थे। जहां भी संभव हो, डेटा का उपयोग वशीकरण करें। यह डेटा संग्रहीत करने की लागत में वृद्धि नहीं करता है, लेकिन यह क्वेरी के निष्पादन को गति देता है और यहां तक ​​कि उनके लेखन को सरल बनाता है, क्वेरी से अनावश्यक तालिकाओं को हटा देता है। यहाँ नकारात्मक पक्ष यह है कि तालिकाओं में अपसामान्य डेटा लाइसेंस में जगह लेता है। लेकिन, यदि आप तार्किक रूप से सोचते हैं, तो माल के नाम और कीमत के तथ्य तालिका में आउटपुट औसतन प्रति रिकॉर्ड 30 बाइट लेगा, अर्थात तथ्यों में एक बिलियन रिकॉर्ड के परिणामस्वरूप 30 जीबी लाइसेंस प्राप्त होगा। भगवान जानते हैं कि बाइट्स को कितना बचाना है।
• मुझे लगता है कि डेटा स्कीमा डिज़ाइन करते समय विभाजन तालिका सबसे महत्वपूर्ण नहीं थी - वर्टिका के पुराने संस्करणों पर ऐसा ही था। लेकिन अब वर्टिका के नए संस्करणों को देखते हुए, मैंने ऐसा सोचना बंद कर दिया। विभाजन आपको तालिका डेटा को तार्किक कंटेनरों में विभाजित करने की अनुमति देता है जो डेटा को संग्रहीत और एक्सेस करने के लिए वर्टिका के साथ हेरफेर करना आसान है। वर्टिका डेवलपर्स का निर्णय कठोर है: विभाजन की कई चाबियाँ नहीं होनी चाहिए और कुछ नहीं होनी चाहिए। पहले मामले में, विभाजन कंटेनरों के बादलों को संशोधित करके अनुरोधों का प्रदर्शन करते समय वर्टिका बन्द हो जाती है। दूसरे मामले में, वर्टिका डिस्क पर सैकड़ों गीगाबाइट आकार के कंटेनरों को विलय करने और पढ़ने में बहुत समय बिताएगा। इसके अलावा, विभाजन की योजना बनाते समय, यह याद रखने योग्य है कि वर्टिका जल्दी और कुशलतापूर्वक हटा सकता है, साथ ही विभाजन कुंजियों द्वारा कंटेनरों को अन्य तालिकाओं में स्थानांतरित कर सकता है और आपको इसका उपयोग करने की आवश्यकता है। इस सब से निष्कर्ष सरल है: तार्किक संकेतों के अनुसार कंटेनर न बनाएं, जैसे कि शहर या ग्राहक। अपने आप से पूछें: क्या आपके पास शहर या क्लाइंट के बारे में सभी तथ्यों से संग्रह तालिका को हटाने या स्थानांतरित करने का कोई कारण होगा? लेकिन पिछली तालिका, दिन, सप्ताह या महीने के लिए जानकारी को हटाना या स्थानांतरित करना तथ्य तालिका को विभाजित करने के लिए तारीख के बारे में सोचने का एक अच्छा कारण है। उन लोगों के लिए जो अपनी कंपनी के भविष्य और डेटा वेयरहाउस के लंबे खुशहाल जीवन में विश्वास करते हैं और इस बात से सहमत नहीं हैं कि डेटा को हमेशा के लिए संग्रहीत करने की आवश्यकता नहीं है, वर्टिका में एक अद्भुत MERGE_PARTITIONS फ़ंक्शन है। यह आपको विभाजन कुंजियों के निर्दिष्ट अंतराल को एक कंटेनर में जोड़ने और एक उचित सीमा के भीतर तालिका में विभाजन कुंजियों की संख्या रखने की अनुमति देता है। मैं माप के बारे में आशा करता हूं, और इसलिए यह स्पष्ट है: विभाजन निश्चित रूप से वहां आवश्यक नहीं हैं।
• कोई भी MPP सर्वर, चाहे वर्टिका, Hadoop या कैसेंड्रा, क्लस्टर सर्वरों में समान रूप से वितरित डेटा को प्यार करता है। कोई भी कार उत्साही इस बात की पुष्टि करेगा कि ड्राइविंग करते समय खराब संतुलन तुरंत महसूस होता है। एमपीपी यहां अपवाद नहीं है - यदि आप शहर द्वारा डेटा भंडारण के विभाजन के रूप में विभाजन को निर्दिष्ट करते हैं, तो क्लस्टर के एक सर्वर पर आपके पास 15 मिलियन मॉस्को, और अन्य 40 हजार यूरीपिन्स्क होंगे। मुझे लगता है कि यह पहले से ही स्पष्ट है कि कौन सा सर्वर अनुरोधों पर काम करेगा, जबकि बाकी क्लस्टर सर्वर केवल निष्क्रिय होंगे और अपना काम पूरा करने के लिए "मॉस्को" सर्वर की प्रतीक्षा करेंगे। यदि विभाजन स्पष्ट रूप से इंगित नहीं किया गया है, तो वर्टिका बस डिफ़ॉल्ट रूप से सभी तालिका क्षेत्रों के हैश द्वारा खंडों। यह क्लस्टर सर्वरों के बीच डेटा का एक समान वितरण देता है, लेकिन कई बार ऐसा होता है जब आप इसे मैन्युअल रूप से कर सकते हैं। यह कुछ क्षेत्रों के लिए डेटा ग्रुपिंग अनुरोधों में लगातार उपयोग के मामलों में समझ में आ सकता है, बशर्ते कि इन ग्रुपिंग फ़ील्ड के रिकॉर्ड हमेशा लगभग समान रूप से वितरित किए जाते हैं। उदाहरण के लिए, हमारे पास प्रत्येक दिन के लिए प्रत्येक शहर के समान बिक्री तथ्यों के बारे में है। बेशक, मॉस्को में यह प्रति दिन हजारों रिकॉर्ड होगा, और उरीउपिन्स्क में यह सिर्फ एक दर्जन बिक्री देगा। चूंकि रूस के कई शहर हैं और एक वर्ष भी हैं, जब बिक्री के दिन और शहर के तथ्य के आधार पर तथ्य तालिका के विभाजन का निर्धारण किया जाता है, उसी मॉस्को के रिकॉर्ड समान रूप से दिनों तक क्लस्टर सर्वर के बीच फिट होंगे, और Uryninskinsk ऐसी तालिका में डेटा के वितरण को संतुलित करने में सिर्फ एक सांख्यिकीय त्रुटि होगी। , क्लस्टर सर्वरों के बीच बिछाने भी। विभाजन के इस आदेश के साथ हमें क्या मिलेगा? दिन और शहर के हिसाब से समूहीकरण के साथ एक क्वेरी सभी क्षेत्रों के विभाजन की तुलना में अधिक बेहतर तरीके से काम करेगी। यह प्रत्येक सर्वर के लिए शहर और दिन के आंकड़ों को एकत्र करने और सर्वर आरंभकर्ता को अंतिम परिणाम हस्तांतरित करने के लिए पर्याप्त होगा, जो सत्र का परिणाम लौटाएगा। अन्यथा, सर्वर में से प्रत्येक डेटा उठाएगा, आंशिक रूप से इसे एकत्रित करेगा और आगे के एकत्रीकरण के लिए इसे सर्जक को स्थानांतरित कर देगा। मोमबत्ती के लायक ऐसा खेल कब है? मेरी राय केवल तभी है जब डेटा के लिए अनुरोध होंगे, जिसमें हजारों शहरों में बिक्री की बड़ी अवधि है। यही है, इस उदाहरण में, यह स्पष्ट रूप से इस तरह के विभाजन को करने के लायक नहीं है, और यह बिक्री तालिका में डेटा के सामान्य समान विभाजन को करने के लिए पर्याप्त है। लेकिन जैसा कि वे कहते हैं, वह सिर्फ दिखाने के लिए एक उदाहरण है, और ऐसा नहीं है। माप के विभाजन के साथ, सब कुछ सरल भी है - उचित संख्या में रिकॉर्ड के साथ माप के लिए, सर्वर पर सभी प्रतियों का दर्पण भंडारण करना आसान है, बाकी के लिए, यहां तक ​​कि नोड्स के बीच डेटा का वितरण भी। यहां यह याद रखने योग्य है कि माप को प्रतिबिंबित करते समय, तथ्य तालिका को माप से जोड़ने पर क्लस्टर में प्रत्येक सर्वर की लागत केवल आपकी मेमोरी में माप रिकॉर्ड की एक प्रति प्राप्त करने और कनेक्शन शुरू करने के लिए जाएगी। अन्यथा, आपको प्रत्येक सर्वर से माप के टुकड़े प्राप्त करने होंगे और फिर उन्हें कनेक्ट करना होगा। यहां, दर्पण के लिए नेटवर्क का खर्च सिद्धांत के अनुसार कम है - हर किसी को प्राप्त होता है, हर किसी से प्राप्त होता है।
• मार्केटर्स के साथ वर्टिका की एक ताकत यह है कि वर्टिका का कोई इंडेक्स नहीं है। यह सही है, कोई अनुक्रमणिका नहीं हैं, लेकिन डेटा संग्रहण के लिए एक सॉर्टिंग और एन्कोडिंग प्रारूप है। वास्तव में, यह सीधे तौर पर इन बातों पर निर्भर करता है कि आपकी तालिका या उसका प्रक्षेपण विभिन्न प्रश्नों को पूरा करने के लिए कैसे तैयार होगा और क्वेरी निष्पादन योजना बनाते समय क्वेरी ऑप्टिमाइज़र द्वारा कौन सा अनुमान सबसे अधिक पसंद किया जाएगा। ईमानदारी से, अनुमानों को बेहतर कोड और सॉर्ट करने के तरीके की सभी बारीकियों का वर्णन वूडू के विषय पर एक बड़े शोध प्रबंध को आकर्षित करता है। इसलिए, मैं खुद को सिफारिशों में सरल डिजाइन नियमों तक सीमित करूंगा:
  1. स्तंभ मानों को संग्रहीत करने के लिए एक विधि चुनते समय, वर्टिका अपने डेटा प्रकार पर स्वचालित रूप से ध्यान केंद्रित करता है। चूंकि किसी भी एल्गोरिथ्म द्वारा यह अनुमान लगाना असंभव है कि BIGINT किसी मामले में एक तथ्य मूल्य है, लेकिन कुछ आयाम पहचानकर्ता में, तालिकाओं का वर्णन करते समय फ़िल्टरिंग और एकत्रीकरण के लिए उपयोग किए जाने वाले फ़ील्ड के हिस्से के ENCODING संकेत को अनदेखा करना सार्थक नहीं है। तथ्य नहीं है, लेकिन आयामों का मूल्य है। इस कॉलम विकल्प के सही विवरण के साथ, वर्टिका को स्टोर करना और उन पर डेटा खोजना आसान होगा, और अधिक कुशल प्रश्नों का निर्माण करते समय ऑप्टिमाइज़र को ध्यान में रखा जाना चाहिए। इसके अलावा, ग्रुपिंग के बारे में मत भूलना, अगर ऐसे फ़ील्ड हैं जो हमेशा अनुरोध में एक साथ लौटे और संसाधित किए जाते हैं, तो उनके भंडारण को एक स्थान पर संयोजित करने का एक अच्छा कारण है, पढ़ने और रिकॉर्ड इकट्ठा करने की लागत को कम करना।
  2. जब एक टेबल या प्रोजेक्शन को छाँटना असाइन करें, तो याद रखें कि सभी मामलों के लिए, सॉर्टिंग स्टॉक नहीं करेगा और आप अनुमानों से सुरक्षित नहीं होंगे। इसलिए, तालिका के लिए, हम सबसे अक्सर निष्पादित प्रश्नों के दृष्टिकोण से छंटनी का चयन करते हैं, और शेष मामलों के लिए हम पहले से ही अनुमान लगाते हैं।
  3. फ़ील्ड चुनते और क्रमबद्ध करते समय, हम लगभग निम्नलिखित नियमों पर ध्यान केंद्रित करते हैं: छंटाई की शुरुआत में, हम उन कॉलमों को डालते हैं जिन्हें सबसे अधिक बार समानता के प्रश्नों के लिए खोजा जाता है और जो अद्वितीय लोगों की पहचान करने के लिए सबसे उपयुक्त होते हैं, फिर छंटाई के बीच में उन खेतों को डालना अच्छा होता है जो कनेक्शन या खोज में उपयोग किए जाते हैं सूची ऑपरेटर में। आखिरी काम करने के लिए उन क्षेत्रों को रखा जाता है जिनके साथ तुलनात्मक संचालन होता है। हमारी लंबी-पीड़ित बिक्री तालिका के मामले में, छंटाई के दृष्टिकोण से, खेतों के निम्नलिखित क्रम को रखना सबसे अधिक फायदेमंद होगा: क्षेत्र, ग्राहक, Sales_Date। यह सॉर्टिंग क्रम उन सभी क्वेरीज़ को कवर करता है जिनमें दिनांक अवधि के निर्दिष्ट खंड में क्षेत्र और / या क्लाइंट द्वारा एक फ़िल्टर होता है। यदि ये क्वेरी ORDER BY में सॉर्ट फ़ील्ड का उपयोग करते हैं, तो वर्टिका क्वेरी को निष्पादित करना और भी आसान है।
  4. चूंकि आप अभी भी पूरी तरह से आश्वस्त नहीं हो सकते हैं कि एन्कोडिंग और सॉर्टिंग, और विभाजन, सबसे इष्टतम होगा, आप हमेशा एक नाइट की चाल बना सकते हैं। अर्थात्: स्पष्ट रूप से विभाजन और छँटाई को निर्दिष्ट किए बिना वर्टिका पर एक प्रोटोटाइप तालिका तैनात करें, इसे एक निश्चित मात्रा में डेटा के साथ भरें, इस तालिका में अधिक विशिष्ट प्रश्न लिखें और डेटाबेस डिज़ाइनर के माध्यम से वर्टिका एडमिनटूल उपयोगिताओं को चलाएं। डिजाइनर प्रश्नों का विश्लेषण करेंगे, तालिका के लिए आवश्यक अनुमानों को एन्कोडिंग और डेटा को उनके दृष्टिकोण से इष्टतम के साथ सॉर्ट करेंगे। फिर इस तालिका पर प्रश्नों को चलाना संभव होगा, उनकी क्वेरी योजनाओं को देखें, मूल्यांकन करें कि प्रस्तावित अनुमान कितने प्रभावी हैं और बनाई गई परियोजनाओं में प्रस्तावित छंटाई, विभाजन और क्षेत्र कोडिंग पर ध्यान केंद्रित करते हुए एक कार्यपत्रक बनाते हैं। ठीक है, और यदि आवश्यक हो, तो तुरंत उन प्रश्नों के लिए अतिरिक्त अनुमान बनाएं जो तालिका की छंटाई द्वारा कवर नहीं किए गए हैं और जो डिजाइनर वर्टिका द्वारा प्रस्तावित किए गए थे।

ETL / ELT डेवलपर के नजरिए से वर्टिका कैसा दिखता है

ETL लॉजिक डेवलपर आसानी से और आराम से रहता है: वर्टिका में सभी मानक डेटा एक्सेस ड्राइवर (ODBC, JDBC, .NET, पायथन) हैं। COPY कमांड की फ्लैट फ़ाइलों को डाउनलोड करने वाले बैच के लिए देशी मालिकाना टूल का एक प्रभावशाली सेट भी है। उन्हें आपके स्वयं के पार्सर, फिल्टर और सत्यापनकर्ताओं के साथ विस्तारित किया जा सकता है। फ़ाइलों को क्लस्टर सर्वर से स्वयं और स्थानीय रूप से COPY LOCAL का उपयोग कर काम करने वाली मशीनों से दोनों डाउनलोड किया जा सकता है। वर्टिका JDBC ड्राइवर JDBC तैयार स्टेटमेंट के जरिए बैच इंसर्ट का समर्थन करते हैं, स्वचालित रूप से पेस्ट वैल्यू पैकेट को COPY बैच इंसर्ट में परिवर्तित करते हैं। यह रिकॉर्ड डालने की एक उच्च गति देता है। मरहम में एकमात्र मक्खी यह है कि बैच डाउनलोड के विस्तार के कार्य केवल सी में लिखे जा सकते हैं, जो तुरंत विकास को जटिल बनाता है। नवीनतम अफवाहों को देखते हुए, वर्टिका आत्मविश्वास से जावा दुनिया के साथ एकीकरण की ओर बढ़ रहा है (जाहिर है, Hadoop के करीब), इसलिए निकट भविष्य में यह काफी संभव है कि ऐसी चीजों को जावा में लिखा और प्लग किया जा सके। बड़े पैमाने पर डेटा की समानांतर लोडिंग की उत्पादकता और दक्षता के मुद्दों पर छूते हुए, वर्टिका अपनी वास्तुकला के साथ पूरी तरह से उन्हें खत्म कर लेता है। ETL डेवलपर को वास्तविक समय लोडिंग और लोड संतुलन की बारीकियों के किसी विशेष ज्ञान की आवश्यकता नहीं होती है।

ईएलटी लॉजिक डेवलपर के दृष्टिकोण से, वर्टिका के लिए केवल दो शिकायतें हैं: संग्रहीत कार्यविधि भाषा के लिए कोई समर्थन नहीं है और अभिव्यक्ति के रूप में या सी भाषा में आदिम के अलावा अपने स्वयं के कार्यों को लिखने का कोई तरीका नहीं है। अंतिम वर्टिका टीम जावा में कार्यों के लिए समर्थन के रूप में जल्द ही इसे ठीक करने का वादा करती है, लेकिन किसी ने संग्रहीत प्रक्रियाओं के साथ कुछ भी वादा नहीं किया है। इसलिए आपको अपने ईटीएल टूल्स का उपयोग करके ईएलटी लॉजिक को स्टोर और एक्जिक्यूट करना होगा। बाकी के लिए, वर्टिका पूरी तरह से सबसे अधिक मांग वाले स्क्रिप्ट डेवलपर को पूरी तरह से संतुष्ट करता है: एएनएसआई एसक्यूएल मानक के लिए पूर्ण समर्थन, अन्य डेटा सर्वरों से परिचित कई कार्य, डेटा प्रकारों के साथ सरल कार्य और उनकी कमी, मध्यवर्ती परिणामों को संग्रहीत करने के लिए स्थानीय और वैश्विक सत्र के लिए समर्थन, एक ऑपरेटर की उपस्थिति। MERGE, बड़े डेटा सरणियों पर तेज़ UPDATE और DELETE के लिए समर्थन, समय अंतराल (TIME EVENT), समय कनेक्शन (TIME JOIN) का समर्थन करके OLAP कार्यक्षमता का विस्तार और बहुत कुछ ।यह सब स्टेजिंग एरिया से विंडो डिस्प्ले एरिया में डेटा के ट्रांसफॉर्मेशन और फिलिंग पर कॉम्प्लेक्स क्वेश्चन लिखना, एग्रीगेट और केपीआई को कैलकुलेट करना और वेयरहाउस में डेटा कैलकुलेट करने के लिए अन्य काम करना आसान बनाता है। जैसा कि अभ्यास से पता चला है, जो डेवलपर्स ओरेकल, एमएसएससी या साइबेस आईक्यू डीबीएमएस को जानते हैं, वे जटिल प्रश्नों के स्तर पर वर्टिका के साथ एक सामान्य भाषा पाते हैं। ओरेकल डेवलपर्स के लिए, संग्रहीत प्रक्रियाओं और कर्सर के लिए भाषा की कमी संभवतः डेटा गणना तर्क विकसित करने के दृष्टिकोण के लिए अपने प्रतिमान को बदलने के लिए एक अतिरिक्त प्रोत्साहन है। शायद यह एक कारण है कि वर्टिका डेवलपर्स संग्रहीत प्रक्रियाओं का समर्थन करने के मुद्दे से दूर जा रहे हैं, आईएमएचओ को डर हो सकता है कि कर्सर प्रदर्शन (बेशक एक मजाक, लेकिन कुछ सच्चाई के साथ) को मार देंगे।

बीआई डेवलपर दृष्टिकोण से वर्टिका कैसा दिखता है

बीआई समाधानों के विकासकर्ता के दृष्टिकोण से, वर्टिका में स्पष्ट रूप से पैरामीटरकृत विचारों के कुछ एनालॉग की संभावना का अभाव है, उदाहरण के लिए, MSSQL में साइबेस आईक्यू में टेबल फ़ंक्शन या संग्रहीत कार्यविधियाँ। BI के लिए जटिल प्रश्नों को विकसित करते समय, अक्सर दिए गए मापदंडों के डेटा को फ़िल्टर करके, सब-वे के अंदर कहीं और उपयोग किया जाता है। और शीर्ष पर, पहले से ही उपश्रेणियों के परिणामों पर, डेटा एकत्र किया जाता है। वर्टिका में प्रश्नों को बनाने में असमर्थता, जैसे कि मापदंडों के साथ सहेजे गए प्रश्न, बीआई डेवलपर्स को विभिन्न ब्रह्मांडों, अर्क और अन्य चीजों के बीच जटिल प्रश्नों को कॉपी करने के लिए मजबूर करते हैं जो किसी के पास बीआई उपकरण में हैं। अन्यथा, ईएलटी डेवलपर्स के मामले में, वर्टिका पूरी तरह से किसी भी जटिलता के विश्लेषणात्मक प्रश्नों की पूरी श्रृंखला को कवर करता है। यही है, यह एसक्यूएल प्रश्नों में कोई प्रतिबंध नहीं है,कार्यों और एक्सटेंशनों के लिए समर्थन है OLAP, के साथ, टाइम सीरीज़, टाइम जॉइन, ईवेंट सीरीज़, जियो-डेटा, आईपी एड्रेसिंग, यूआरएल, आदि के साथ काम करना। वर्टिका रिपॉजिटरी मेटाडेटा स्वयं बीआई में उल्लेखनीय रूप से दिखाई देता है और सभी प्रमुख बीआई उत्पादों के लिए वर्टिका के साथ कोई कठिनाई नहीं है। यहां उन लोगों के लिए यह सार्थक है, जो वर्टिका + झांकी के रूप में इस तरह के अद्भुत संयोजन पर ध्यान देने के लिए बीआई के साथ वर्टिका की बातचीत में रुचि रखते हैं। साथ में, ये दोनों उत्पाद वास्तविक समय में सीधे शक्तिशाली विश्लेषिकी प्रदान करते हैं। मैं कहूंगा कि हमारी कंपनी में झांकी को सराहा गया था। मेरा मानना ​​है कि बीआई डेवलपर्स के लिए मुख्य मुद्दे, अर्थात् तदर्थ अनुरोधों और कार्यक्षमता सीमाओं के प्रदर्शन, वर्टिका में बस अनुपस्थित हैं, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।EVENT SERIES, जियो-डेटा, आईपी एड्रेसिंग, यूआरएल, आदि के साथ काम करते हैं। वर्टिका रिपॉजिटरी मेटाडेटा स्वयं बीआई में उल्लेखनीय रूप से दिखाई देता है और सभी प्रमुख बीआई उत्पादों के लिए वर्टिका के साथ कोई कठिनाई नहीं है। यहां उन लोगों के लिए यह सार्थक है, जो वर्टिका + झांकी के रूप में इस तरह के अद्भुत संयोजन पर ध्यान देने के लिए बीआई के साथ वर्टिका की बातचीत में रुचि रखते हैं। साथ में, ये दोनों उत्पाद वास्तविक समय में सीधे शक्तिशाली विश्लेषिकी प्रदान करते हैं। मैं कहूंगा कि हमारी कंपनी में झांकी को सराहा गया था। मेरा मानना ​​है कि बीआई डेवलपर्स के लिए मुख्य मुद्दे, अर्थात् तदर्थ अनुरोधों और कार्यक्षमता सीमाओं के प्रदर्शन, वर्टिका में बस अनुपस्थित हैं, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।EVENT SERIES, जियो-डेटा, आईपी एड्रेसिंग, यूआरएल, आदि के साथ काम करते हैं। वर्टिका रिपॉजिटरी मेटाडेटा स्वयं बीआई में उल्लेखनीय रूप से दिखाई देता है और सभी प्रमुख बीआई उत्पादों के लिए वर्टिका के साथ कोई कठिनाई नहीं है। यहां उन लोगों के लिए यह सार्थक है, जो वर्टिका + झांकी के रूप में इस तरह के अद्भुत संयोजन पर ध्यान देने के लिए बीआई के साथ वर्टिका की बातचीत में रुचि रखते हैं। साथ में, ये दोनों उत्पाद वास्तविक समय में सीधे शक्तिशाली विश्लेषिकी प्रदान करते हैं। मैं कहूंगा कि हमारी कंपनी में झांकी को सराहा गया था। मेरा मानना ​​है कि बीआई डेवलपर्स के लिए मुख्य मुद्दे, अर्थात् तदर्थ अनुरोधों और कार्यक्षमता सीमाओं के प्रदर्शन, वर्टिका में बस अनुपस्थित हैं, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।वर्टिका रिपॉजिटरी मेटाडेटा स्वयं बीआई में उल्लेखनीय रूप से दिखाई देता है और सभी प्रमुख बीआई उत्पादों के लिए वर्टिका के साथ कोई कठिनाई नहीं है। यहां उन लोगों के लिए यह सार्थक है, जो वर्टिका + झांकी के रूप में इस तरह के अद्भुत संयोजन पर ध्यान देने के लिए बीआई के साथ वर्टिका की बातचीत में रुचि रखते हैं। साथ में, ये दोनों उत्पाद वास्तविक समय में सीधे शक्तिशाली विश्लेषिकी प्रदान करते हैं। मैं कहूंगा कि हमारी कंपनी में झांकी को सराहा गया था। मेरा मानना ​​है कि बीआई डेवलपर्स के लिए मुख्य मुद्दे, अर्थात् तदर्थ अनुरोधों और कार्यक्षमता सीमाओं के प्रदर्शन, वर्टिका में बस अनुपस्थित हैं, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।वर्टिका रिपॉजिटरी मेटाडेटा स्वयं बीआई में उल्लेखनीय रूप से दिखाई देता है और सभी प्रमुख बीआई उत्पादों के लिए वर्टिका के साथ कोई कठिनाई नहीं है। यहां उन लोगों के लिए यह सार्थक है जो वर्टिका + झांकी जैसे अद्भुत संयोजन पर ध्यान देने के लिए बीआई के साथ वर्टिका की बातचीत में रुचि रखते हैं। साथ में, ये दोनों उत्पाद वास्तविक समय में सीधे शक्तिशाली विश्लेषिकी प्रदान करते हैं। मैं कहूंगा कि हमारी कंपनी में झांकी को सराहा गया था। मेरा मानना ​​है कि बीआई डेवलपर्स के लिए मुख्य मुद्दे, अर्थात् तदर्थ अनुरोधों और कार्यक्षमता सीमाओं के प्रदर्शन, वर्टिका में बस अनुपस्थित हैं, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।यहां उन लोगों के लिए यह सार्थक है, जो वर्टिका + झांकी के रूप में इस तरह के अद्भुत संयोजन पर ध्यान देने के लिए बीआई के साथ वर्टिका की बातचीत में रुचि रखते हैं। साथ में, ये दोनों उत्पाद वास्तविक समय में सीधे शक्तिशाली विश्लेषिकी प्रदान करते हैं। मैं कहूंगा कि हमारी कंपनी में झांकी को सराहा गया था। मेरा मानना ​​है कि बीआई डेवलपर्स के लिए मुख्य मुद्दे, अर्थात् तदर्थ अनुरोधों और कार्यक्षमता सीमाओं के प्रदर्शन, वर्टिका में बस अनुपस्थित हैं, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।यहां उन लोगों के लिए यह सार्थक है जो वर्टिका + झांकी जैसे अद्भुत संयोजन पर ध्यान देने के लिए बीआई के साथ वर्टिका की बातचीत में रुचि रखते हैं। साथ में, ये दोनों उत्पाद वास्तविक समय में सीधे शक्तिशाली विश्लेषिकी प्रदान करते हैं। मैं कहूंगा कि हमारी कंपनी में झांकी को सराहा गया था। मेरा मानना ​​है कि बीआई डेवलपर्स के लिए मुख्य मुद्दे, अर्थात् तदर्थ अनुरोधों और कार्यक्षमता सीमाओं के प्रदर्शन, वर्टिका में बस अनुपस्थित हैं, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।अर्थात्, तदर्थ अनुरोधों और कार्यक्षमता की सीमाओं का प्रदर्शन, वर्टिका बस उपलब्ध नहीं है, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।अर्थात्, तदर्थ अनुरोधों और कार्यक्षमता की सीमाओं का प्रदर्शन, वर्टिका बस उपलब्ध नहीं है, जो बीआई समाधानों के विकास की गति और गुणवत्ता को सकारात्मक रूप से प्रभावित करता है।

एक व्यवस्थापक दृष्टिकोण से वर्टिका कैसा दिखता है

वर्टिका का प्रशासन सशर्त रूप से अशक्त माना जा सकता है। इसका मतलब यह नहीं है कि वर्टिका को प्रशासन की आवश्यकता नहीं है। यह समझा जाता है कि वर्टिका का प्रशासन कभी-कभी आवश्यक होता है। इसके अलावा, एक समर्पित पूर्णकालिक स्थायी इकाई के बजाय, एक वास्तुकार, ईटीएल या बीआई डेवलपर द्वारा दूरस्थ सर्वर प्रशासन या प्रशासन काफी संभव है। स्वयं सर्वर प्रशासन को कई श्रेणियों में विभाजित किया जा सकता है:

• भूमिकाओं और उपयोगकर्ताओं को प्रबंधित करें। मानक प्रक्रिया भूमिकाओं द्वारा उनके वितरण के उपयोगकर्ता डेटाबेस में विवरण और डेटाबेस ऑब्जेक्ट्स के लिए भूमिका की पहुंच का वर्णन है। काम अक्सर नहीं होता है, यह उपयोगकर्ताओं और भूमिकाओं को जोड़ने के रूप में किया जाता है।
• . , Vertica. Vertica . , , , , , , , . . , . -, , . , .
• . , , , . , . , , 3 3 , , .
• . , Vertica , , . , , . , , , Vertica . , — Vertica . - , RAM, RAID . , , . .
• . Vertica, Vertica 10 , Vertica. , Linux .
• . , , . Database Designer Vertica adminTools . , . — . Vertica , . , . , , , . , , .

नेतृत्व के मामले में वर्टिका कैसा दिखता है

शुरू करने के लिए, मैं कुछ ऐसा सूची दूंगा जिसके बारे में हमारे प्रबंधन को कभी भी सिरदर्द नहीं हुआ:

1. विश्लेषण के लिए नए डेटा स्रोतों को जल्दी से जोड़ना आवश्यक है: नई योजनाएं और तालिकाओं को जोड़ा जाता है, डेटा लोडर उनमें बनाए जाते हैं, काम पारदर्शी और समझ में आता है।
2. डेटा वेयरहाउस के उपयोगकर्ताओं से बढ़े हुए भार को ध्यान में रखते हुए उत्पादकता बढ़ाना आवश्यक है: उपयोगकर्ता अनुरोधों का विश्लेषण किया जाता है, यदि आवश्यक हो, तो नए अनुमानों को जोड़ा जाता है जो उनके काम में तेजी लाते हैं। लोड में कई वृद्धि के मामले में, नए सर्वर खरीदे जाते हैं और क्लस्टर से जुड़े होते हैं।
3. , BI: Vertica ANSI SQL .
4. : .
5. लाइसेंस के उन्नयन के लिए संसाधनों की आवश्यकता होती है: प्रदर्शन या डेटा भंडारण क्षेत्र बढ़ाने के लिए नए सर्वर खरीदते समय और उन्हें क्लस्टर से जोड़ने पर, यह डाउनलोड करने के लिए अनुमत प्रारंभिक मात्रा में डेटा के लिए लाइसेंस को प्रभावित नहीं करता है। इसके अलावा, लाइसेंस प्रश्नों के निष्पादन में तेजी लाने के लिए अतिरिक्त संरचनाओं (अनुमानों) के निर्माण को प्रभावित नहीं करता है। इस प्रकार, लाइसेंस नवीनीकरण की आवश्यकता तभी होती है जब स्रोत डेटा की मात्रा लाइसेंस की खरीद के लिए नियोजित मात्रा तक पहुंच गई हो और अंतरिक्ष को खाली करने के लिए अप्रचलित संग्रह डेटा को हटाने का कोई तरीका नहीं है। हम अभी तक इस बिंदु तक नहीं पहुंचे हैं, लेकिन संग्रहीत पुराने डेटा को संग्रहीत करने का सवाल पहले से कहीं अधिक प्रासंगिक है - डेटा कंपनी की बढ़ती भूख के कारण हमारी योजना के मुकाबले बहुत अधिक निकला।

हमारा प्रबंधन हमेशा क्या पसंद करता है:

1. कार्यों को जल्दी से सेट करें और तेजी से परिणाम प्राप्त करें।
2. किसी भी समय, किसी भी परिस्थिति में किसी भी अवधि के लिए जल्दी से विश्लेषणात्मक रिपोर्ट प्राप्त करें।
3. वास्तविक समय में हमारी कंपनी में चल रही प्रक्रियाओं की स्थिति देखें।
4. वर्टिका के बारे में कोई शिकायत न सुनें या संकेत दें कि कार्य किसी कारणवश वर्टिका के लिए पूरा नहीं हुआ है।

हमारा प्रबंधन हमेशा क्या पसंद नहीं करता है:

1. मूल्य। गुणवत्ता और गति के लिए, अफसोस, आपको भुगतान करना होगा। वर्टिका एक स्वतंत्र नहीं है और सबसे सस्ता समाधान नहीं है, इसलिए प्रबंधन को पैसा खर्च करने के लिए एक नैतिक इच्छा की आवश्यकता है, यह उसी समय साकार होता है कि वे इससे क्या प्राप्त करेंगे।

इंटीग्रेटर के दृष्टिकोण से वर्टिका कैसा दिखता है

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

सारांश

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

सामान्य तौर पर, "बड़ा" सर्वर का एक संक्षिप्त दौरा समाप्त हो गया है, आपके ध्यान के लिए धन्यवाद।
निष्ठा से, DWH वास्तुकार Konstantinov Aleksey

PS कृपया, जब इस लेख में सामग्री का उपयोग कर रहे हैं, तो इस लेख को देखें Habr या मेरे ब्लॉग को वर्टिका पर रूसी जानकारी में मेरे कॉपीराइट की रक्षा करने में मदद करने के लिए;)