वास्तविक अनुप्रयोगों में क्लिकहाउस का उपयोग करने का सिद्धांत और अभ्यास। अलेक्जेंडर ज़ैतसेव (2018)

इस तथ्य के बावजूद कि अब लगभग हर जगह बहुत अधिक डेटा है, विश्लेषणात्मक डेटाबेस अभी भी काफी विदेशी हैं। वे कम ज्ञात हैं और इससे भी बदतर प्रभावी ढंग से उनका उपयोग करने में सक्षम हैं। कई लोग MySQL या PostgreSQL के साथ "कैक्टस खाना" जारी रखते हैं, जो अन्य परिदृश्यों के लिए डिज़ाइन किए गए हैं, NoSQL से पीड़ित हैं, या व्यावसायिक समाधानों के लिए अधिक भुगतान करते हैं। क्लिकहाउस खेल के नियमों को बदलता है और विश्लेषणात्मक डीबीएमएस की दुनिया में प्रवेश करने की सीमा को काफी कम करता है।

बैकएंड कॉन्फ 2018 से रिपोर्ट और इसे स्पीकर की अनुमति से प्रकाशित किया गया है।

मैं कौन हूँ और मैं क्लिकहाउस के बारे में क्यों बात कर रहा हूँ? मैं LifeStreet में विकास निदेशक हूं, जो ClickHouse का उपयोग करता है। साथ ही, मैं अल्टिनिटी का संस्थापक हूं। यह एक यैंडेक्स पार्टनर है जो क्लिकहाउस को बढ़ावा देता है और यैंडेक्स को क्लिकहाउस को और अधिक सफल बनाने में मदद करता है। क्लिकहाउस के बारे में जानकारी साझा करने के लिए भी तैयार।

और मैं पेट्या जैतसेव का भाई नहीं हूं। मुझसे अक्सर इस बारे में पूछा जाता है। नहीं, हम भाई नहीं हैं।

“हर कोई जानता है” कि क्लिकहाउस:

• बहुत तेज,
• बहुत ही आरामदायक
• यैंडेक्स में उपयोग किया जाता है।

थोड़ा कम पता है कि किन कंपनियों में और इसका इस्तेमाल कैसे किया जाता है।

मैं आपको बताऊंगा कि यैंडेक्स को छोड़कर क्लिकहाउस का उपयोग क्यों, कहां और कैसे किया जाता है।

मैं आपको बताऊंगा कि विभिन्न कंपनियों में क्लिकहाउस की मदद से विशिष्ट कार्यों को कैसे हल किया जाता है, आप अपने कार्यों के लिए कौन से क्लिकहाउस टूल का उपयोग कर सकते हैं और विभिन्न कंपनियों में उनका उपयोग कैसे किया जाता है।

मैंने तीन उदाहरण चुने जो क्लिकहाउस को विभिन्न कोणों से दिखाते हैं। मुझे लगता है कि यह दिलचस्प होगा.

पहला सवाल है: "हमें क्लिकहाउस की आवश्यकता क्यों है?"। यह एक स्पष्ट प्रश्न प्रतीत होता है, लेकिन इसके एक से अधिक उत्तर हैं।

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

क्लिकहाउस में ये समस्याएँ नहीं हैं।

क्लिकहाउस का उपयोग अब कहां किया जाता है? Yandex के अलावा, ClickHouse का उपयोग विभिन्न व्यवसायों और कंपनियों के एक समूह में किया जाता है।

• सबसे पहले, यह वेब एप्लिकेशन एनालिटिक्स है, यानी यह एक ऐसा उपयोग मामला है जो यैंडेक्स से आया है।
• कई एडटेक कंपनियां क्लिकहाउस का इस्तेमाल करती हैं।
• कई कंपनियां जिन्हें विभिन्न स्रोतों से लेन-देन लॉग का विश्लेषण करने की आवश्यकता होती है।
• सुरक्षा लॉग की निगरानी के लिए कई कंपनियां क्लिकहाउस का उपयोग करती हैं। वे उन्हें क्लिकहाउस पर अपलोड करते हैं, रिपोर्ट बनाते हैं, और वे परिणाम प्राप्त करते हैं जिनकी उन्हें आवश्यकता होती है।
• कंपनियां इसे वित्तीय विश्लेषण में इस्तेमाल करना शुरू कर रही हैं, यानी धीरे-धीरे बड़े बिजनेस भी क्लिकहाउस की तरफ आ रहे हैं।
• amazon. अगर कोई ClickHouse को फॉलो करता है तो उसने शायद इस कंपनी का नाम सुना होगा। यह समुदाय के आवश्यक योगदानकर्ताओं में से एक है। और उनके पास बहुत गंभीर क्लिकहाउस इंस्टॉलेशन है। उदाहरण के लिए, उन्होंने क्लिकहाउस के लिए काफ्का इंजन बनाया।
• दूरसंचार कंपनियों ने उपयोग करना शुरू कर दिया। कई कंपनियां क्लिकहाउस का उपयोग या तो अवधारणा के प्रमाण के रूप में करती हैं या पहले से ही उत्पादन में हैं।
• एक कंपनी उत्पादन प्रक्रियाओं की निगरानी के लिए क्लिकहाउस का उपयोग करती है। वे microcircuits का परीक्षण करते हैं, मापदंडों का एक गुच्छा लिखते हैं, लगभग 2 विशेषताएँ हैं। और फिर वे विश्लेषण करते हैं कि खेल अच्छा है या बुरा।
• ब्लॉकचेन एनालिटिक्स। ऐसी एक रूसी कंपनी है, जैसे कि Bloxy.info। यह एथेरियम नेटवर्क का विश्लेषण है। उन्होंने क्लिकहाउस पर भी ऐसा किया।

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

और अगर रिकॉर्ड्स पर नजर डालें तो:

• यांडेक्स: 500+ सर्वर, वे वहां एक दिन में 25 बिलियन रिकॉर्ड स्टोर करते हैं।
• LifeStreet: 60 सर्वर, प्रति दिन लगभग 75 बिलियन रिकॉर्ड। यैंडेक्स की तुलना में कम सर्वर, अधिक रिकॉर्ड हैं।
• CloudFlare: 36 सर्वर, वे प्रतिदिन 200 बिलियन रिकॉर्ड सहेजते हैं। उनके पास और भी कम सर्वर हैं और और भी अधिक डेटा स्टोर करते हैं।
• ब्लूमबर्ग: 102 सर्वर, प्रति दिन लगभग एक ट्रिलियन प्रविष्टियाँ। कीर्तिमानधारी।

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

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

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

ये कई कंपनियों में वास्तविक क्लिकहाउस उपयोग के उदाहरण हैं।

• पहला उदाहरण एक विज्ञापन नेटवर्क है: वर्टिका से क्लिकहाउस में माइग्रेशन। और मैं कुछ ऐसी कंपनियों को जानता हूं जो वर्टिका से परिवर्तित हो चुकी हैं या परिवर्तन की प्रक्रिया में हैं।
• दूसरा उदाहरण क्लिकहाउस पर ट्रांजैक्शनल स्टोरेज है। यह एंटीपैटर्न पर निर्मित एक उदाहरण है। डेवलपर्स की सलाह पर क्लिकहाउस में जो कुछ भी नहीं किया जाना चाहिए वह यहां किया जाता है। और यह इतनी प्रभावी ढंग से किया जाता है कि यह काम करता है। और यह ठेठ लेनदेन संबंधी समाधान से काफी बेहतर काम करता है।
• तीसरा उदाहरण क्लिकहाउस पर वितरित कंप्यूटिंग है। क्लिकहाउस को Hadoop पारिस्थितिकी तंत्र में कैसे एकीकृत किया जा सकता है, इस बारे में एक प्रश्न था। मैं एक उदाहरण दिखाऊंगा कि कैसे एक कंपनी ने एक बहुत ही गैर-तुच्छ कार्य की गणना करने के लिए, क्लिकहाउस पर मानचित्र को कम करने वाले कंटेनर के समान कुछ किया, डेटा स्थानीयकरण आदि का ट्रैक रखा।

• LifeStreet एक Ad Tech कंपनी है जिसके पास एक विज्ञापन नेटवर्क के साथ आने वाली सभी तकनीकें हैं।
• वह विज्ञापन अनुकूलन, प्रोग्रामेटिक बिडिंग में लगी हुई है।
• बहुत सारा डेटा: प्रति दिन लगभग 10 अरब घटनाएं। इसी समय, वहाँ की घटनाओं को कई उप-घटनाओं में विभाजित किया जा सकता है।
• इस डेटा के कई ग्राहक हैं, और ये केवल लोग नहीं हैं, और भी बहुत कुछ हैं - ये विभिन्न एल्गोरिदम हैं जो प्रोग्रामेटिक बिडिंग में लगे हुए हैं।

कंपनी एक लंबा और कांटेदार रास्ता तय कर चुकी है। और मैंने इसके बारे में हाईलोड पर बात की। सबसे पहले, LifeStreet MySQL (Oracle पर एक छोटे स्टॉप के साथ) से Vertica में चला गया। और आप इसके बारे में एक कहानी पा सकते हैं।

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

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

कहाँ जाए? और लंबे समय तक यह बिल्कुल स्पष्ट नहीं था कि कहां जाना है, क्योंकि एक ओर वाणिज्यिक डेटाबेस हैं, ऐसा लगता है कि वे अच्छी तरह से काम करते हैं। कुछ लगभग वर्टिका की तरह ही काम करते हैं, कुछ बदतर। लेकिन वे सभी महंगे हैं, कुछ भी सस्ता और बेहतर नहीं मिला।

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

और वाणिज्यिक डेटाबेस में जो अच्छा है उसे गठबंधन करने के लिए कुछ भी नहीं था और जो भी मुक्त है वह खुले स्रोत में है।

कुछ भी नहीं था जब तक, अप्रत्याशित रूप से, यांडेक्स ने क्लिकहाउस को टोपी से एक जादूगर की तरह, एक खरगोश की तरह बाहर निकाला। और यह एक अप्रत्याशित निर्णय था, वे अभी भी सवाल पूछते हैं: "क्यों?", लेकिन फिर भी।

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

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

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

और परीक्षण के परिणाम प्राप्त करने के बाद, और इसे विभिन्न कोणों से देखते हुए, LifeStreet ClickHouse में गया।

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

इसलिए, मैं इसके बारे में विस्तार से बात नहीं करूंगा, मैं केवल परिणामों और कुछ दिलचस्प चीजों के बारे में बात करूंगा, जिनके बारे में मैंने तब बात नहीं की थी।

परिणाम हैं:

• सफल प्रवासन और एक वर्ष से अधिक प्रणाली पहले से ही उत्पादन में काम कर रही है।
• उत्पादकता और लचीलापन बढ़ा है। 10 बिलियन रिकॉर्ड में से जिसे हम प्रति दिन स्टोर कर सकते थे और फिर थोड़े समय के लिए, LifeStreet अब प्रति दिन 75 बिलियन रिकॉर्ड स्टोर करता है और यह 3 महीने या उससे अधिक समय तक कर सकता है। यदि आप चोटी पर गिनते हैं, तो यह प्रति सेकंड दस लाख घटनाओं तक है। इस प्रणाली में एक दिन में एक लाख से अधिक SQL प्रश्न आते हैं, ज्यादातर विभिन्न रोबोटों से।
• इस तथ्य के बावजूद कि वर्टिका की तुलना में क्लिकहाउस के लिए अधिक सर्वरों का उपयोग किया गया था, उन्होंने हार्डवेयर पर भी बचत की, क्योंकि वर्टिका में महंगे एसएएस डिस्क का उपयोग किया गया था। क्लिकहाउस ने सैटा का इस्तेमाल किया। और क्यों? क्योंकि वर्टिका में सम्मिलन तुल्यकालिक है। और तुल्यकालन के लिए आवश्यक है कि डिस्क बहुत अधिक धीमा न हो, और यह भी कि नेटवर्क बहुत अधिक धीमा न हो, जो कि एक महंगा ऑपरेशन है। और ClickHouse में इन्सर्ट एसिंक्रोनस है। इसके अलावा, आप हमेशा सब कुछ स्थानीय रूप से लिख सकते हैं, इसके लिए कोई अतिरिक्त लागत नहीं है, इसलिए धीमी ड्राइव पर भी वर्टिका की तुलना में डेटा को क्लिकहाउस में बहुत तेजी से डाला जा सकता है। और पढ़ना उसी के बारे में है। SATA पर पढ़ना, अगर वे RAID में हैं, तो यह सब काफी तेज है।
• लाइसेंस द्वारा सीमित नहीं, यानी 3 सर्वरों में 60 पेटाबाइट डेटा (20 सर्वर एक प्रतिकृति है) और तथ्यों और एकत्रीकरण में 6 ट्रिलियन रिकॉर्ड। वर्टिका में ऐसा कुछ भी नहीं दिया जा सकता था।

अब मैं इस उदाहरण में व्यावहारिक बातों की ओर मुड़ता हूं।

• पहली एक कुशल योजना है। बहुत कुछ स्कीमा पर निर्भर करता है।
• दूसरा कुशल एसक्यूएल पीढ़ी है।

एक विशिष्ट OLAP क्वेरी एक चयन है। कुछ कॉलम समूह में जाते हैं, कुछ कॉलम कुल कार्यों में जाते हैं। वहाँ है जहाँ, जिसे घन के एक टुकड़े के रूप में दर्शाया जा सकता है। द्वारा पूरे समूह को एक प्रक्षेपण के रूप में सोचा जा सकता है। और इसीलिए इसे बहुभिन्नरूपी डेटा विश्लेषण कहा जाता है।

और अक्सर इसे एक स्टार-स्कीम के रूप में तैयार किया जाता है, जब किरणों के साथ-साथ इस तथ्य का एक केंद्रीय तथ्य और विशेषताएं होती हैं।

और भौतिक डिजाइन के संदर्भ में, यह कैसे मेज पर फिट बैठता है, वे आमतौर पर सामान्यीकृत प्रतिनिधित्व करते हैं। आप असामान्य कर सकते हैं, लेकिन यह डिस्क पर महंगा है और प्रश्नों पर बहुत कुशल नहीं है। इसलिए, वे आम तौर पर सामान्यीकृत प्रतिनिधित्व करते हैं, यानी एक तथ्य तालिका और कई, कई आयाम तालिकाएं।

लेकिन यह क्लिकहाउस में अच्छा काम नहीं करता है। इसके दो कारण हैं:

• पहला कारण यह है कि क्लिकहाउस में बहुत अच्छे जॉइन नहीं होते हैं, यानी जॉइन होते हैं, लेकिन वे खराब होते हैं। जबकि खराब।
• दूसरा यह है कि टेबल अपडेट नहीं होते हैं। आमतौर पर इन प्लेटों में, जो स्टार-सर्किट के आसपास होती हैं, कुछ बदलने की जरूरत होती है। उदाहरण के लिए, ग्राहक का नाम, कंपनी का नाम, आदि। और यह काम नहीं करता।

और इसका एक तरीका ClickHouse में है। यहां तक ​​कि दो:

• पहला शब्दकोशों का उपयोग है। बाहरी शब्दकोश वह है जो 99% समस्या को स्टार-स्कीमा, अपडेट और अन्य के साथ हल करने में मदद करता है।
• दूसरा सरणियों का उपयोग है। Arrays सामान्यीकरण के साथ जुड़ने और समस्याओं से छुटकारा पाने में भी मदद करता है।

• शामिल होने की आवश्यकता नहीं है।
• अपग्रेड करने योग्य। मार्च 2018 के बाद से, शब्दकोशों को आंशिक रूप से अपडेट करने के लिए एक गैर-दस्तावेजी अवसर सामने आया है (आपको यह दस्तावेज में नहीं मिलेगा), यानी वे प्रविष्टियां जो बदल गई हैं। व्यावहारिक रूप से, यह एक टेबल की तरह है।
• हमेशा मेमोरी में, इसलिए एक डिक्शनरी के साथ तेजी से काम करता है अगर यह डिस्क पर एक टेबल थी और यह अभी तक एक तथ्य नहीं है कि यह कैश में है, सबसे अधिक संभावना नहीं है।

• आपको जुड़ने की भी आवश्यकता नहीं है।
• यह एक कॉम्पैक्ट 1-टू-मैनी प्रतिनिधित्व है।
• और मेरी राय में, गीक्स के लिए सरणियाँ बनाई जाती हैं। ये लैम्ब्डा फंक्शन वगैरह हैं।

यह लाल शब्दों के लिए नहीं है। यह एक बहुत शक्तिशाली कार्यक्षमता है जो आपको बहुत ही सरल और सुरुचिपूर्ण तरीके से कई काम करने की अनुमति देती है।

विशिष्ट उदाहरण जो सरणियों को हल करने में मदद करते हैं। ये उदाहरण काफी सरल और स्पष्ट हैं:

• टैग द्वारा खोजें। अगर आपके पास वहां हैशटैग है और हैशटैग द्वारा कुछ पोस्ट ढूंढना चाहते हैं।
• की-वैल्यू पेयर द्वारा खोजें। मूल्य के साथ कुछ विशेषताएँ भी हैं।
• उन चाबियों की सूचियां संग्रहीत करना जिन्हें आपको किसी और चीज़ में अनुवाद करने की आवश्यकता है।

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

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

हो सकता है कि नेस्टेड संरचना सबसे अच्छा नाम न हो। ये दो सरणियाँ हैं जिनके नाम में एक सामान्य भाग और कुछ संबंधित विशेषताएँ हैं।

और टैग द्वारा खोजना बहुत आसान है। एक समारोह करो has, जो जाँचता है कि सरणी में एक तत्व है। सभी को, हमारे सम्मेलन से संबंधित सभी प्रविष्टियाँ मिलीं।

सबिड द्वारा खोजना थोड़ा अधिक जटिल है। हमें पहले कुंजी के सूचकांक को खोजने की जरूरत है, और फिर इस सूचकांक के साथ तत्व लें और जांचें कि यह मान वह है जो हमें चाहिए। हालांकि, यह बहुत ही सरल और कॉम्पैक्ट है।

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

एक और उदाहरण। आपके पास एक सरणी है जहां आप आईडी स्टोर करते हैं। और आप उन्हें नामों में अनुवादित कर सकते हैं। समारोह arrayMap. यह एक विशिष्ट लैम्ब्डा फ़ंक्शन है। आप वहां लैम्ब्डा एक्सप्रेशन पास करते हैं। और वह शब्दकोश से प्रत्येक आईडी के लिए नाम का मान निकालती है।

खोज उसी तरह की जा सकती है। एक प्रेडिकेट फ़ंक्शन पारित किया जाता है जो जांचता है कि तत्व क्या मेल खाते हैं।

ये चीजें सर्किट को बहुत सरल करती हैं और समस्याओं का एक समूह हल करती हैं।

लेकिन अगली समस्या जिसका हम सामना कर रहे हैं, और जिसका मैं उल्लेख करना चाहूँगा, कुशल क्वेरीज़ है।

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

और सरल मामलों में भी, कभी-कभी अनुसूचक का काम करना और प्रश्नों को थोड़ा फिर से लिखना भी आवश्यक होता है।

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

पुनर्लेखन फिल्टर के साथ एक समान उदाहरण। यहाँ रूस के लिए एक अनुरोध है। यह 5 सेकंड तक चलता है। यदि हम इसे इस तरह से फिर से लिखते हैं कि हम फिर से एक तार की तुलना नहीं करते हैं, लेकिन उन कुंजियों के कुछ सेट के साथ संख्याएँ जो रूस से संबंधित हैं, तो यह बहुत तेज़ होगा।

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

• वितरित मोड में अधिकतम काम।
• न्यूनतम प्रकारों के आधार पर छाँटना, जैसा कि मैंने ints द्वारा किया था।
• यदि कोई जॉइन (जॉइन), डिक्शनरी हैं, तो उन्हें अंतिम उपाय के रूप में करना बेहतर है, जब आपके पास पहले से ही कम से कम आंशिक रूप से समूहीकृत डेटा है, तो जॉइन ऑपरेशन या डिक्शनरी कॉल को कम बार कॉल किया जाएगा और यह तेज़ होगा .
• फ़िल्टर बदलना.

अन्य तकनीकें भी हैं, और न केवल वे जो मैंने प्रदर्शित की हैं। और वे सभी कभी-कभी प्रश्नों के निष्पादन में काफी तेजी ला सकते हैं।

चलिए अगले उदाहरण पर चलते हैं। यूएसए से कंपनी एक्स। वह क्या कर रही है?

एक कार्य था:

• विज्ञापन लेनदेन की ऑफ़लाइन लिंकिंग।
• विभिन्न बाध्यकारी मॉडल मॉडलिंग।

परिदृश्य क्या है?

एक साधारण आगंतुक साइट पर आता है, उदाहरण के लिए, महीने में 20 बार विभिन्न विज्ञापनों से, या ऐसे ही कभी-कभी बिना किसी विज्ञापन के आता है, क्योंकि वह इस साइट को याद रखता है। कुछ उत्पादों को देखता है, उन्हें टोकरी में रखता है, उन्हें टोकरी से बाहर निकालता है। और, अंत में, कुछ खरीदता है।

उचित प्रश्न: "यदि आवश्यक हो तो विज्ञापन के लिए किसे भुगतान करना चाहिए?" और "क्या विज्ञापन ने उसे प्रभावित किया, यदि कोई हो?"। यानी उसने खरीदारी क्यों की और इस व्यक्ति जैसे लोगों को भी खरीदने के लिए कैसे राजी किया जाए?

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

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

कई बाध्यकारी मॉडल हैं।

सबसे लोकप्रिय हैं:

• अंतिम इंटरेक्शन, जहां इंटरेक्शन या तो एक क्लिक या एक इंप्रेशन है।
• पहला इंटरेक्शन, यानी पहली चीज जो किसी व्यक्ति को साइट पर लाती है।
• रैखिक संयोजन - सभी समान रूप से।
• क्षीणन।
• और इसी तरह।

और यह सब पहली जगह कैसे काम करता था? रनटाइम और कैसेंड्रा था। कैसेंड्रा का उपयोग लेनदेन भंडारण के रूप में किया जाता था, अर्थात इसमें सभी संबंधित लेनदेन संग्रहीत किए जाते थे। और जब Runtime में कोई इवेंट आता है जैसे कोई पेज या कुछ और दिखा रहा हो तो Cassandra से Request की गई - ऐसा कोई शख्स है या नहीं. फिर उससे संबंधित लेन-देन प्राप्त किए गए। और कनेक्शन हो गया।

और अगर यह भाग्यशाली है कि अनुरोध में लेनदेन आईडी है, तो यह आसान है। लेकिन आमतौर पर कोई किस्मत नहीं। इसलिए, अंतिम लेन-देन या अंतिम क्लिक वाले लेन-देन आदि का पता लगाना आवश्यक था।

और यह सब बहुत अच्छी तरह से काम करता था जब तक कि अंतिम क्लिक के लिए बाध्यकारी था। क्योंकि अगर हम एक महीने के लिए एक विंडो सेट करते हैं, तो कहते हैं, प्रति दिन 10 मिलियन क्लिक, प्रति माह 300 मिलियन क्लिक होते हैं। और चूंकि कैसंड्रा में इसे तेजी से चलाने के लिए स्मृति में होना चाहिए, क्योंकि रनटाइम को जल्दी से प्रतिक्रिया देने की जरूरत है, इसमें लगभग 10-15 सर्वर लगे।

और जब वे लेन-देन को डिस्प्ले से जोड़ना चाहते थे, तो यह तुरंत इतना मज़ेदार नहीं निकला। और क्यों? यह देखा जा सकता है कि 30 गुना अधिक घटनाओं को संग्रहित करने की आवश्यकता है। और, तदनुसार, आपको 30 गुना अधिक सर्वरों की आवश्यकता है। और यह पता चला कि यह किसी प्रकार की खगोलीय आकृति है। लिंकिंग करने के लिए 500 सर्वर तक रखने के लिए, इस तथ्य के बावजूद कि रनटाइम में काफी कम सर्वर हैं, तो यह किसी प्रकार का गलत आंकड़ा है। और वे सोचने लगे कि क्या किया जाए।

और हम क्लिकहाउस गए। और इसे क्लिकहाउस पर कैसे करें? पहली नज़र में ऐसा लगता है कि यह विरोधी पैटर्न का एक सेट है।

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

यानी एंटीपैटर्न का एक सेट।

लेकिन फिर भी यह एक ऐसी प्रणाली बनाने के लिए निकला जो बहुत अच्छी तरह से काम करती थी।

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

यह इस रूप में था कि यह बहुत अच्छा काम नहीं करता था। और क्लिकहाउस के लिए इसे आसान बनाने के लिए, जब विज़िट आईडी द्वारा अनुरोध किया गया था, तो उन्होंने इन अनुरोधों को 1-000 विज़िट आईडी के ब्लॉक में समूहित किया और 2-000 लोगों के लिए सभी लेनदेन निकाले। और फिर यह सब काम कर गया।

अगर आप क्लिकहाउस के अंदर देखें, तो यहां केवल 3 मुख्य टेबल हैं जो यह सब सर्व करती हैं।

पहली तालिका जिसमें लॉग अपलोड किए जाते हैं, और लॉग लगभग बिना प्रसंस्करण के अपलोड किए जाते हैं।

दूसरी तालिका। भौतिक दृष्टि से, इन लॉग से, जिन घटनाओं को अभी तक श्रेय नहीं दिया गया है, यानी, असंबंधित वाले, काट दिए गए थे। और भौतिक दृश्य के माध्यम से, स्नैपशॉट बनाने के लिए लेन-देन को इन लॉग से बाहर निकाला गया। अर्थात्, एक विशेष भौतिक दृश्य ने एक स्नैपशॉट बनाया, अर्थात् लेन-देन की अंतिम संचित स्थिति।

यहाँ SQL में लिखा गया टेक्स्ट है। मैं इसमें कुछ महत्वपूर्ण बातों पर टिप्पणी करना चाहूंगा।

पहली महत्वपूर्ण बात क्लिकहाउस में json से कॉलम और फ़ील्ड्स को बाहर निकालने की क्षमता है। यानी क्लिकहाउस के पास जोंस के साथ काम करने के कुछ तरीके हैं। वे बहुत ही आदिम हैं।

visitParamExtractInt आपको json से विशेषताएँ निकालने की अनुमति देता है, यानी पहली हिट काम करती है। और इस तरह आप ट्रांजैक्शन आईडी निकाल सकते हैं या आईडी पर जा सकते हैं। इस समय।

दूसरे, यहाँ एक पेचीदा भौतिक क्षेत्र का उपयोग किया जाता है। इसका मतलब क्या है? इसका अर्थ है कि आप इसे तालिका में सम्मिलित नहीं कर सकते हैं, अर्थात यह सम्मिलित नहीं है, इसकी गणना की जाती है और सम्मिलन पर संग्रहीत की जाती है। पेस्ट करते समय, क्लिकहाउस आपके लिए काम करता है। और आपको बाद में जो चाहिए वह पहले ही json से बाहर हो चुका है।

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

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

स्नैपशॉट कुछ अन्य दिलचस्प क्लिकहाउस सुविधाओं का भी उपयोग करता है।

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

• बाइंडिंग रनटाइम से "डिकूपल्ड" है।
• प्रति माह 3 बिलियन लेनदेन तक संग्रहीत और संसाधित किए जाते हैं। यह कैसंड्रा की तुलना में अधिक परिमाण का एक क्रम है, अर्थात एक विशिष्ट लेन-देन प्रणाली में।
• 2x5 क्लिकहाउस सर्वरों का समूह। 5 सर्वर और प्रत्येक सर्वर की एक प्रतिकृति है। क्लिक आधारित एट्रिब्यूशन करने के लिए यह कैसंड्रा की तुलना में और भी कम है, और यहां हमारे पास इंप्रेशन आधारित है। यानी सर्वर की संख्या को 30 गुना बढ़ाने के बजाय कम करने में कामयाब रहे।

और अंतिम उदाहरण वित्तीय कंपनी Y है, जिसने स्टॉक की कीमतों में परिवर्तन के सहसंबंधों का विश्लेषण किया।

और कार्य था:

• लगभग 5 शेयर हैं।
• उद्धरण हर 100 मिलीसेकंड ज्ञात हैं।
• डेटा 10 वर्षों में जमा किया गया है। जाहिर है, कुछ कंपनियों के लिए अधिक, कुछ के लिए कम।
• कुल मिलाकर लगभग 100 बिलियन पंक्तियाँ हैं।

और परिवर्तनों के सहसंबंध की गणना करना आवश्यक था।

यहां दो स्टॉक और उनके उद्धरण हैं। यदि एक ऊपर जाता है और दूसरा ऊपर जाता है, तो यह एक सकारात्मक सहसंबंध है, अर्थात एक ऊपर जाता है और दूसरा ऊपर जाता है। यदि एक ऊपर जाता है, जैसा कि ग्राफ के अंत में है, और दूसरा नीचे जाता है, तो यह एक नकारात्मक सहसंबंध है, यानी जब एक ऊपर उठता है, तो दूसरा गिर जाता है।

इन पारस्परिक परिवर्तनों का विश्लेषण करके, वित्तीय बाजार में भविष्यवाणियां की जा सकती हैं।

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

और उसके बाद, आपको सहसंबंध की गणना करने की आवश्यकता है, और प्रत्येक जोड़ी के लिए सहसंबंध की गणना की जानी चाहिए। 5 शेयरों के लिए जोड़े 000 मिलियन हैं। और यह बहुत कुछ है, यानी 12,5 बार इस तरह के सहसंबंध समारोह की गणना करना आवश्यक है।

और अगर कोई भूल गया, तो ͞x और ͞y एक चेकमेट है। नमूना अपेक्षा। यही है, न केवल जड़ों और राशियों की गणना करना आवश्यक है, बल्कि इन राशियों के अंदर एक और राशि भी है। गणनाओं का एक समूह 12,5 मिलियन बार करने की आवश्यकता है, और यहां तक ​​कि घंटों के आधार पर समूहीकृत किया जाना चाहिए। हमारे पास भी बहुत घंटे हैं। और आपको इसे 60 सेकंड में करना है। यह एक मज़ाक है।

कम से कम किसी तरह समय मिलना जरूरी था, क्योंकि क्लिकहाउस के आने से पहले यह सब बहुत धीरे-धीरे काम करता था।

उन्होंने इसकी गणना Hadoop, Spark, Greenplum पर करने की कोशिश की। और यह सब बहुत धीमा या खर्चीला था। यानी किसी तरह गणना करना संभव था, लेकिन तब यह महंगा था।

और फिर क्लिकहाउस साथ आया और चीजें काफी बेहतर हो गईं।

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

वो क्या करते थे? प्रारंभ में, डेटा स्थानीयकृत है। प्रत्येक सर्वर शेयरों के एक निश्चित सेट के मूल्य निर्धारण पर डेटा संग्रहीत करता है। और वे ओवरलैप नहीं करते। इसलिए, समानांतर और स्वतंत्र रूप से लॉगरिटर्न की गणना करना संभव है, यह सब अब तक समानांतर और वितरित में होता है।

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

इसके बाद इसे दोहराया जा सकता है। "आर" अक्षर का अर्थ है कि हमने इस डेटा को दोहराया है। यही है, हमारे पास तीनों सर्वरों पर समान डेटा है - ये सरणियाँ हैं।

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

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

कांसेप्ट के प्रूफ पर टास्क एक सबटास्क था यानी कम डेटा लिया गया। और केवल तीन सर्वर।

ये पहले दो चरण: Log_return की गणना और सरणियों में लपेटने में लगभग एक घंटा लगा।

और सहसंबंध की गणना लगभग 50 घंटे है। लेकिन 50 घंटे काफी नहीं हैं, क्योंकि उन्हें हफ्तों तक काम करना पड़ता था। यह एक बड़ी सफलता थी। और अगर आप गिनें, तो 70 बार प्रति सेकंड इस क्लस्टर पर सब कुछ गिना जाता था।

लेकिन सबसे महत्वपूर्ण बात यह है कि यह प्रणाली व्यावहारिक रूप से बाधाओं के बिना है, यानी यह लगभग रैखिक रूप से मापती है। और उन्होंने इसकी जाँच की। इसे सफलतापूर्वक बढ़ाया।

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

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

-रिपोर्ट के लिए धन्यवाद! बहुत ही रोचक! क्या अपाचे फीनिक्स के साथ कोई तुलना थी?

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

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

• धन्यवाद

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

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

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

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

यह स्पष्ट है। आपने कहा कि 50 घंटे संसाधित किए गए थे। क्या यह शुरुआत से ही है, आपने डेटा कब लोड किया या परिणाम प्राप्त किया?

हाँ, हाँ।

ठीक बहुत - बहुत धन्यवाद।

यह 3 सर्वर क्लस्टर पर है।

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

बेशक, कोई आदर्श प्रणाली नहीं हैं। और ClickHouse की भी अपनी समस्याएँ हैं। लेकिन क्या आपने Yandex.Metrica के लंबे समय से काम नहीं करने के बारे में सुना है? शायद नहीं। यह क्लिकहाउस पर 2012-2013 से मज़बूती से काम कर रहा है। मैं अपने अनुभव के बारे में भी यही कह सकता हूं। हमें कभी भी पूर्ण असफलता नहीं मिली है। कुछ आंशिक चीजें हो सकती हैं, लेकिन वे इतनी गंभीर नहीं थीं कि वे व्यवसाय को गंभीरता से प्रभावित कर सकें। ऐसा कभी न हुआ था। क्लिकहाउस काफी विश्वसनीय है और बेतरतीब ढंग से क्रैश नहीं होता है। आपको इसकी चिंता करने की जरूरत नहीं है। यह कोई कच्ची बात नहीं है। यह कई कंपनियों द्वारा सिद्ध किया गया है।

नमस्ते! आपने कहा था कि आपको तुरंत डेटा स्कीमा पर विचार करने की आवश्यकता है। क्या हुआ अगर हुआ? मेरा डेटा बरस रहा है और बरस रहा है। छह महीने बीत जाते हैं, और मैं समझता हूं कि इस तरह जीना असंभव है, मुझे डेटा फिर से अपलोड करने और उनके साथ कुछ करने की जरूरत है।

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

धन्यवाद.

स्रोत: www.habr.com