एनालिटिकल इन्फ्रास्ट्रक्चर इवोल्यूशन

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

भाग 1. इतिहास, सिद्धांत और व्यवहार का एक सा

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

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

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

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

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

dim_geo

• geo_key
• शहर
• राज्य
• देश

डेटा सामान्यीकरण के दृष्टिकोण से, यह बुरा है, क्योंकि एक ही राज्य और देश कई बार दोहराए जाते हैं। लेकिन विश्लेषणात्मक मॉडल के दृष्टिकोण से, इसके विपरीत, यह सुविधाजनक और कुशल है, क्योंकि आपको अतिरिक्त जोड़ बनाने की आवश्यकता नहीं है।

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

select date(event_date), sum(impressions) from fact_table join dim_geo using (geo_key) where country = 'RU' group by 1; 

इस अनुरोध में क्या महत्वपूर्ण है? जो लोग निष्पादन योजनाओं को पढ़ना जानते हैं, वे तुरंत अनुमान लगा लेंगे कि इस मामले में रूस के लिए जियो_की द्वारा एक बड़ी इंडेक्स रेंज स्कैन होगी यदि फैक्ट_टेबल में जियो_की द्वारा इंडेक्स है, और पूर्ण स्कैन नहीं है तो। फिर दिनांक (घटना_डेट) के अनुसार क्रमबद्ध करें। यदि तालिका में सैकड़ों लाखों या अरबों पंक्तियाँ हैं, तो ऐसी क्वेरी MySQL में तेज़ होने की संभावना नहीं है।

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

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

TokuDB का दूसरा प्रमुख लाभ क्लस्टर अनुक्रमित है। लब्बोलुआब यह है कि पूरे रिकॉर्ड को सूचकांक के साथ संग्रहीत किया जाता है। यह विशेष रूप से विरल इंडेक्स पर प्रश्नों के लिए प्रश्नों की गति को महत्वपूर्ण रूप से प्रभावित करता है, क्योंकि अन्यथा सूचकांक पहले डेटा से लिंक प्राप्त करता है, और उसके बाद ही डेटा को पढ़ा जाता है। MySQL में, MyISAM के लिए, इंडेक्स और डेटा को हमेशा अलग-अलग संग्रहीत किया जाता है, जबकि InnoDB के लिए, डेटा को प्राथमिक कुंजी द्वारा सॉर्ट किया जाता है, और शेष इंडेक्स अलग-अलग होते हैं। विश्लेषणात्मक समस्याओं के लिए, एक सूचकांक आमतौर पर पर्याप्त नहीं होता है।

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

इसलिए, 2009 के अंत में हमारा बुनियादी ढांचा TokuDB के साथ MySQL है, जो प्रति दिन लगभग 150-200 मिलियन तथ्यों को लोड करता है। तथ्यों को लंबे समय तक संग्रहीत नहीं किया जाता है, लेकिन विभिन्न ग्रैन्युलैरिटी की दो इकाइयों के एक दर्जन में लोड होने पर एकत्र किया जाता है। कुछ इकाइयां "शाश्वत" हैं, अन्य केवल कुछ दिनों या हफ्तों के लिए डेटा संग्रहीत करते हैं। इसमें अधिक समय लग सकता है, लेकिन हम TokuDB के लिए एक मुफ्त लाइसेंस द्वारा सीमित हैं, इसलिए इकाइयों का आकार 50GB से अधिक नहीं है। हमारे पास रिजर्व के लिए या विशिष्ट कार्यों के लिए कई और कम समान प्रणालियां हैं। मुख्य ग्राहक इंटरफ़ेस MicroStrategy है, लेकिन हमने पहले ही हमारे लिए नई स्काला भाषा में विश्लेषणात्मक प्रश्नों के प्रदर्शन के लिए एक सार्वभौमिक सेवा के पहले संस्करणों को विकसित करके हमारे समाधान के लिए संक्रमण प्रक्रिया शुरू कर दी है। हमारे पास प्रदर्शन और मापनीयता दोनों की समस्याएं हैं, जो अभी तक हिट नहीं हुई हैं, लेकिन पहले से ही काट रही हैं। हम MySQL को कॉन्फ़िगर करने और "सही" तरीके से इसके लिए एप्लिकेशन डिजाइन करने में वास्तविक पेशेवर बन गए हैं। लेकिन इतना ही काफी नहीं है।

भाग 2. एक विशेष विश्लेषणात्मक डेटाबेस चुनना

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

कल्पना कीजिए कि एक fact_table में 100 कॉलम हैं। यह एक बहुत ही यथार्थवादी आंकड़ा है, उदाहरण के लिए, हमारे पास अब अधिक है। क्वेरी केवल तीन कॉलम - 'Event_date', 'इंप्रेशन' और 'geo_key' का उपयोग करती है - लेकिन एक पारंपरिक डेटाबेस में, डेटा को लाइन द्वारा संग्रहीत किया जाता है। क्वेरी को पूरा करने के लिए कितने स्तंभों की आवश्यकता है, इसके बावजूद डिस्क से सब कुछ पढ़ा जाएगा, जो उन तालिकाओं के लिए बहुत अक्षम है जहां कई कॉलम हैं। यह अप्रिय प्रभाव बहुत पहले देखा गया था, और पहला डेटाबेस जिसने स्तंभ-उन्मुख आंतरिक भंडारण संरचना का उपयोग किया था, वह Sybase SybaseIQ का एक उप-उत्पाद था, जिसे 90 के दशक के मध्य में विकसित किया गया था। जहां तक ​​मैं समझता हूं, उसे उचित मान्यता नहीं मिली। लेकिन 2000 के दशक के मध्य में, यह सवाल फिर से लौट आया, और कुख्यात माइकल स्टोनब्रेकर सी-स्टोर अनुसंधान परियोजना के साथ एक अग्रणी के रूप में आगे आए, जो बाद में वर्टिका वाणिज्यिक मंच के लिए आधार बन गया। मुझे 2008 के मध्य में CITForum के अनुवादित लेख से C-Store के बारे में पता चला और यह एक महत्वपूर्ण मोड़ था।

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

2009 के अंत में केवल कुछ वाणिज्यिक डेटाबेस थे जो स्तंभ-उन्मुख डेटा भंडारण की पेशकश करते थे:

• वर्टिका
• GreenPlum
• InfoBright
• ParAccel
• InfiniDB
• ओरेकल (एक्सडाटा)

वे तत्परता और पहुंच के विभिन्न स्तरों पर थे, लेकिन हमने ओरेकल को छोड़कर उन सभी को आजमाया। परीक्षण के लिए, हमने एक तालिका तैयार की जिसमें 25 कॉलम और 12 बिलियन पंक्तियाँ थीं। आठ परीक्षण प्रश्नों ने प्रदर्शन के विभिन्न पहलुओं को मापा; उन सभी में, कुछ - समूहीकरण और उपश्रेणियों में योग और फ़िल्टरिंग था। MySQL c TokuDB ने एक संदर्भ प्रणाली के रूप में काम किया। ऐसे मामलों में जहां डेटाबेस ने क्लस्टर में सर्वर जोड़कर स्केलिंग की अनुमति दी, हमने परीक्षण किया कि इससे प्रदर्शन में कितना सुधार होता है।

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

इसके बारे में और अगले लेख में वर्टिका की विशेषताओं के बारे में।