सिद्धान्त र वास्तविक अनुप्रयोगहरूमा ClickHouse प्रयोग गर्ने अभ्यास। अलेक्जेन्डर Zaitsev (2018)

यस तथ्यको बावजुद अब लगभग सबै ठाउँमा धेरै डाटा छ, विश्लेषणात्मक डाटाबेसहरू अझै पनि धेरै विदेशी छन्। तिनीहरू नराम्रो रूपमा परिचित छन् र तिनीहरूलाई प्रभावकारी रूपमा प्रयोग गर्न सक्षम छन्। धेरैले MySQL वा PostgreSQL को साथ "क्याक्टस खाने" जारी राख्छन्, जुन अन्य परिदृश्यहरूको लागि डिजाइन गरिएको हो, NoSQL बाट पीडित हुन्छ, वा व्यावसायिक समाधानहरूको लागि अधिक भुक्तानी हुन्छ। ClickHouse ले खेलका नियमहरू परिवर्तन गर्छ र विश्लेषणात्मक DBMS को संसारमा प्रवेश गर्नको लागि थ्रेसहोल्डलाई उल्लेखनीय रूपमा कम गर्छ।

BackEnd Conf 2018 बाट रिपोर्ट र यो वक्ता को अनुमति संग प्रकाशित छ।

म को हुँ र म किन क्लिकहाउसको बारेमा कुरा गर्दैछु? म LifeStreet मा एक विकास निर्देशक हुँ, जसले ClickHouse प्रयोग गर्दछ। साथै, म Altinity को संस्थापक हुँ। यो Yandex साझेदार हो जसले ClickHouse लाई बढावा दिन्छ र Yandex लाई ClickHouse लाई अझ सफल बनाउन मद्दत गर्दछ। क्लिकहाउसको बारेमा ज्ञान साझा गर्न पनि तयार छ।

र म Petya Zaitsev को भाइ होइन। मलाई प्रायः यसबारे सोधिन्छ। होइन, हामी दाजुभाइ होइनौं।

"सबैलाई थाहा छ" त्यो क्लिकहाउस:

• धेरै छिटो,
• धेरै सहज
• Yandex मा प्रयोग गरिन्छ।

अलि कम थाहा छ कुन कम्पनीहरूमा र यसलाई कसरी प्रयोग गरिन्छ।

म तपाईलाई बताउनेछु किन, कहाँ र कसरी क्लिकहाउस प्रयोग गरिन्छ, Yandex बाहेक।

म तपाईंलाई विभिन्न कम्पनीहरूमा क्लिकहाउसको मद्दतले कसरी विशिष्ट कार्यहरू समाधान गरिन्छ, तपाईंले आफ्नो कार्यहरूका लागि कुन क्लिकहाउस उपकरणहरू प्रयोग गर्न सक्नुहुन्छ, र ती विभिन्न कम्पनीहरूमा कसरी प्रयोग गरिन्थ्यो भन्ने कुरा बताउनेछु।

मैले विभिन्न कोणबाट क्लिकहाउस देखाउने तीनवटा उदाहरणहरू उठाएँ। मलाई लाग्छ यो रोचक हुनेछ।

पहिलो प्रश्न हो: "हामीलाई किन क्लिकहाउस चाहिन्छ?"। यो एकदम स्पष्ट प्रश्न जस्तो देखिन्छ, तर यसको एक भन्दा बढी जवाफहरू छन्।

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

क्लिकहाउसमा यी समस्याहरू छैनन्।

क्लिकहाउस अहिले कहाँ प्रयोग गरिन्छ? Yandex को अतिरिक्त, ClickHouse विभिन्न व्यवसाय र कम्पनीहरु को एक गुच्छा मा प्रयोग गरिन्छ।

• सबैभन्दा पहिले, यो वेब अनुप्रयोग एनालिटिक्स हो, अर्थात् यो Yandex बाट आएको प्रयोग केस हो।
• धेरै AdTech कम्पनीहरूले ClickHouse प्रयोग गर्छन्।
• विभिन्न स्रोतहरूबाट लेनदेन लगहरू विश्लेषण गर्न आवश्यक धेरै कम्पनीहरू।
• धेरै कम्पनीहरूले सुरक्षा लगहरू निगरानी गर्न क्लिकहाउस प्रयोग गर्छन्। तिनीहरूले तिनीहरूलाई क्लिकहाउसमा अपलोड गर्छन्, रिपोर्टहरू बनाउँछन्, र उनीहरूलाई आवश्यक परिणामहरू प्राप्त गर्छन्।
• कम्पनीहरूले यसलाई वित्तीय विश्लेषणमा प्रयोग गर्न थालेका छन्, अर्थात् बिस्तारै ठूला व्यवसायहरू पनि क्लिकहाउसमा आउँदैछन्।
• क्लाउडफ्लेयर। यदि कसैले क्लिकहाउस पछ्याउँछ भने, उसले सायद यो कम्पनीको नाम सुनेको छ। यो समुदायबाट आवश्यक योगदानकर्ताहरू मध्ये एक हो। र तिनीहरूसँग धेरै गम्भीर क्लिकहाउस स्थापना छ। उदाहरणका लागि, तिनीहरूले क्लिकहाउसको लागि काफ्का इन्जिन बनाए।
• दूरसञ्चार कम्पनीहरूले प्रयोग गर्न थाले। धेरै कम्पनीहरूले क्लिकहाउसलाई अवधारणामा प्रमाणको रूपमा वा पहिले नै उत्पादनमा प्रयोग गर्छन्।
• एउटा कम्पनीले उत्पादन प्रक्रियाहरू निगरानी गर्न क्लिकहाउस प्रयोग गर्दछ। तिनीहरू माइक्रोसर्किटहरू परीक्षण गर्छन्, प्यारामिटरहरूको गुच्छा लेख्छन्, त्यहाँ लगभग 2 विशेषताहरू छन्। र त्यसपछि तिनीहरू विश्लेषण गर्छन् कि खेल राम्रो वा खराब छ।
• ब्लकचेन एनालिटिक्स। Bloxy.info जस्ता रूसी कम्पनी छ। यो ethereum नेटवर्क को एक विश्लेषण छ। तिनीहरूले यो क्लिकहाउसमा पनि गरे।

र साइज फरक पर्दैन। त्यहाँ धेरै कम्पनीहरू छन् जसले एउटा सानो सर्भर प्रयोग गर्दछ। र उहाँले तिनीहरूलाई आफ्नो समस्या समाधान गर्न अनुमति दिनुहुन्छ। र अझ धेरै कम्पनीहरूले धेरै सर्भरहरू वा दर्जनौं सर्भरहरूको ठूलो क्लस्टरहरू प्रयोग गर्छन्।

र यदि तपाइँ रेकर्डहरू हेर्नुहुन्छ, त्यसपछि:

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

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

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

म यो सब किन भन्दैछु? देखाउनको लागि कि क्लिकहाउस ठूलो डेटा विश्लेषणको लागि मानक समाधान बनिरहेको छ र पहिले नै धेरै ठाउँहरूमा प्रयोग भएको छ। यदि तपाइँ यसलाई प्रयोग गर्नुहुन्छ भने, तपाइँ सही प्रवृतिमा हुनुहुन्छ। यदि तपाइँ यसलाई अझै प्रयोग गरिरहनु भएको छैन भने, तपाइँ डराउन सक्नुहुन्न कि तपाइँ एक्लै छोडिनेछ र कसैले तपाइँलाई मद्दत गर्दैन, किनकि धेरैले पहिले नै यो गरिसकेका छन्।

यी धेरै कम्पनीहरूमा वास्तविक क्लिकहाउस प्रयोगका उदाहरणहरू हुन्।

• पहिलो उदाहरण एउटा विज्ञापन नेटवर्क हो: Vertica बाट ClickHouse मा माइग्रेसन। र मलाई केहि कम्पनीहरू थाहा छ जुन Vertica बाट ट्रान्जिसन भएका छन् वा संक्रमणको प्रक्रियामा छन्।
• दोस्रो उदाहरण ClickHouse मा लेनदेन भण्डारण छ। यो antipatterns मा निर्मित एक उदाहरण हो। विकासकर्ताहरूको सल्लाहमा क्लिकहाउसमा गर्न नहुने सबै कुरा यहाँ गरिन्छ। र यो यति प्रभावकारी रूपमा गरिएको छ कि यसले काम गर्दछ। र यसले सामान्य लेनदेन समाधान भन्दा धेरै राम्रो काम गर्दछ।
• तेस्रो उदाहरण ClickHouse मा कम्प्युटिङ वितरित छ। क्लिकहाउसलाई हडूप इकोसिस्टममा कसरी एकीकृत गर्न सकिन्छ भन्ने प्रश्न थियो। म एउटा उदाहरण देखाउनेछु कि कसरी कम्पनीले क्लिकहाउसमा नक्सा कम कन्टेनर जस्तै केहि गर्यो, डाटा स्थानीयकरण को ट्रयाक राख्दै, आदि, धेरै गैर-तुच्छ कार्य गणना गर्न।

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

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

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

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

कहाँ जाने? र एक लामो समय को लागी यो सबै स्पष्ट थिएन कि कहाँ जाने, किनभने एकातिर त्यहाँ व्यावसायिक डाटाबेसहरू छन्, तिनीहरूले राम्रोसँग काम गरिरहेको देखिन्छ। कतिपयले लगभग Vertica जस्तै काम गर्छन्, केही खराब। तर ती सबै महँगो छन्, केही सस्तो र राम्रो पाउन सकिँदैन।

अर्कोतर्फ, त्यहाँ खुला स्रोत समाधानहरू छन्, जुन धेरै संख्यामा छैनन्, अर्थात् विश्लेषणका लागि, तिनीहरू औंलाहरूमा गन्न सकिन्छ। र तिनीहरू नि: शुल्क वा सस्तो, तर ढिलो छन्। र तिनीहरू प्रायः आवश्यक र उपयोगी कार्यक्षमताको कमी हुन्छन्।

र त्यहाँ व्यापारिक डेटाबेसमा रहेको राम्रो र खुला स्रोतमा भएका सबै नि: शुल्कहरू संयोजन गर्न केही थिएन।

त्यहाँ केहि थिएन जब सम्म, अप्रत्याशित रूपमा, Yandex ले ClickHouse बाहिर निकाल्यो, टोपीबाट जादूगर जस्तै, खरगोश जस्तै। र यो एक अप्रत्याशित निर्णय थियो, तिनीहरू अझै पनि प्रश्न सोध्छन्: "किन?", तर तैपनि।

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

म धेरै अल्छी थिएन र अर्को दिन Yandex परीक्षणहरू हेरे। यो त्यहाँ उस्तै छ: ClickHouse Vertica भन्दा दोब्बर छिटो छ, त्यसैले तिनीहरू प्राय: यसको बारेमा कुरा गर्छन्।

तर यदि त्यहाँ प्रश्नहरूमा सामेल छन् भने, त्यसपछि सबै कुरा धेरै स्पष्ट रूपमा बाहिर जान्छ। र ClickHouse Vertica भन्दा दोब्बर ढिलो हुन सक्छ। र यदि तपाईंले अनुरोधलाई थोरै सच्याउनुभयो र यसलाई पुन: लेख्नुभयो भने, तिनीहरू लगभग बराबर छन्। खराब छैन। र नि: शुल्क।

र परीक्षण परिणामहरू प्राप्त गरेपछि, र यसलाई विभिन्न कोणबाट हेर्दै, LifeStreet क्लिकहाउसमा गयो।

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

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

परिणामहरू हुन्:

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

अब म यस उदाहरणमा व्यावहारिक कुराहरूमा फर्कन्छु।

• पहिलो प्रभावकारी योजना हो। धेरै स्कीमा मा निर्भर गर्दछ।
• दोस्रो कुशल SQL जेनेरेशन हो।

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

र अक्सर यो तारा-योजना को रूप मा मोडेल गरिएको छ, जब त्यहाँ एक केन्द्रीय तथ्य र यस तथ्य को विशेषताहरु छेउमा, किरणहरु संग।

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

तर क्लिकहाउसमा यसले राम्रोसँग काम गर्दैन। त्यहाँ दुई कारणहरू छन्:

• पहिलो हो किनभने ClickHouse सँग धेरै राम्रो जोइनहरू छैनन्, अर्थात् त्यहाँ जोडिएका छन्, तर तिनीहरू खराब छन्। खराब हुँदा।
• दोस्रो हो कि तालिकाहरू अद्यावधिक गरिएको छैन। सामान्यतया यी प्लेटहरूमा, जुन तारा-सर्किटको वरिपरि छन्, केहि परिवर्तन गर्न आवश्यक छ। उदाहरणका लागि, ग्राहकको नाम, कम्पनीको नाम, आदि। र यसले काम गर्दैन।

र त्यहाँ क्लिकहाउस मा यो बाहिर एक तरिका छ। दुई पनि:

• पहिलो शब्दकोषको प्रयोग हो। बाह्य शब्दकोश भनेको 99% लाई तारा-स्कीमा, अपडेटहरू र यस्तै अन्य समस्याहरू समाधान गर्न मद्दत गर्दछ।
• दोस्रो arrays को प्रयोग हो। एरेहरूले जोड्ने र सामान्यीकरणको साथ समस्याहरूबाट छुटकारा पाउन मद्दत गर्दछ।

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

• तपाईलाई पनि सामेल हुन आवश्यक छैन।
• यो एक कम्प्याक्ट 1 देखि धेरै प्रतिनिधित्व हो।
• र मेरो विचारमा, arrays geeks को लागी बनाइन्छ। यी lambda प्रकार्यहरू र यस्तै छन्।

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

विशिष्ट उदाहरणहरू जसले एरेहरू समाधान गर्न मद्दत गर्दछ। यी उदाहरणहरू सरल र पर्याप्त स्पष्ट छन्:

• ट्यागहरू द्वारा खोज्नुहोस्। यदि तपाईंसँग त्यहाँ ह्यासट्यागहरू छन् र ह्यासट्यागद्वारा केही पोष्टहरू फेला पार्न चाहनुहुन्छ भने।
• कुञ्जी-मान जोडीहरू द्वारा खोज्नुहोस्। त्यहाँ मूल्य संग केहि विशेषताहरु पनि छन्।
• तपाईंले अरू कुनै कुरामा अनुवाद गर्न आवश्यक पर्ने कुञ्जीहरूको सूचीहरू भण्डारण गर्दै।

यी सबै कार्यहरू arrays बिना हल गर्न सकिन्छ। ट्यागहरू केही लाइनमा राख्न सकिन्छ र नियमित अभिव्यक्ति वा छुट्टै तालिकामा चयन गर्न सकिन्छ, तर त्यसपछि तपाईंले जोड्नु पर्छ।

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

नेस्टेड संरचना उत्तम नाम नहुन सक्छ। यी दुई एरेहरू हुन् जसमा नाम र केही सम्बन्धित विशेषताहरू छन्।

र यो ट्याग द्वारा खोजी गर्न धेरै सजिलो छ। एक समारोह छ has, जसले array मा एक तत्व समावेश छ भनेर जाँच गर्दछ। सबैजना, हाम्रो सम्मेलनसँग सम्बन्धित सबै प्रविष्टिहरू फेला पारे।

Subid द्वारा खोजी अलि बढी जटिल छ। हामीले पहिले कुञ्जीको अनुक्रमणिका फेला पार्न आवश्यक छ, र त्यसपछि यो अनुक्रमणिकाको साथ तत्व लिनुहोस् र यो मान हामीलाई चाहिने कुरा हो भनेर जाँच गर्नुहोस्। यद्यपि, यो धेरै सरल र कम्प्याक्ट छ।

तपाईले लेख्न चाहनु भएको रेगुलर एक्सप्रेशनलाई यदि तपाईले सबैलाई एउटै लाइनमा राख्नुभयो भने, यो पहिलो, अनाड़ी हुनेछ। र, दोस्रो, यसले दुई एरे भन्दा धेरै लामो काम गर्यो।

अर्को उदाहरण। तपाईंसँग एउटा एरे छ जहाँ तपाईंले आईडी भण्डार गर्नुहुन्छ। र तपाइँ तिनीहरूलाई नामहरूमा अनुवाद गर्न सक्नुहुन्छ। समारोह arrayMap। यो एक सामान्य lambda प्रकार्य हो। तपाईंले त्यहाँ लाम्ब्डा अभिव्यक्तिहरू पास गर्नुहुन्छ। र उनले शब्दकोशबाट प्रत्येक आईडीको लागि नामको मूल्य निकाल्छिन्।

खोजी पनि त्यस्तै तरिकाले गर्न सकिन्छ। एक predicate प्रकार्य पास हुन्छ कि तत्वहरू के मेल खान्छ जाँच गर्दछ।

यी चीजहरूले सर्किटलाई धेरै सरल बनाउँदछ र समस्याहरूको गुच्छा समाधान गर्दछ।

तर अर्को समस्या हामीले सामना गरिरहेका छौं, र जुन म उल्लेख गर्न चाहन्छु, कुशल प्रश्नहरू हो।

• ClickHouse सँग क्वेरी प्लानर छैन। बिल्कुल होइन।
• यद्यपि, जटिल प्रश्नहरू अझै योजनाबद्ध हुन आवश्यक छ। कुन अवस्थामा?
• यदि क्वेरीमा धेरै जोडहरू छन् भने, तपाईंले तिनीहरूलाई उप-चयनहरूमा लपेट्नुहोस्। र उनीहरूलाई कार्यान्वयन गर्ने क्रम महत्त्वपूर्ण छ।
• र दोस्रो - यदि अनुरोध वितरित छ। किनभने वितरित क्वेरीमा, केवल भित्री उपचयनलाई वितरण गरी कार्यान्वयन गरिन्छ, र अरू सबै एक सर्भरमा पठाइन्छ जुन तपाईंले जडान गर्नुभयो र त्यहाँ कार्यान्वयन गर्नुभयो। तसर्थ, यदि तपाईंले धेरै जोडिहरू (जोइन) संग प्रश्नहरू वितरण गर्नुभएको छ भने, तपाईंले अर्डर छनौट गर्न आवश्यक छ।

र सरल अवस्थाहरूमा पनि, कहिलेकाहीँ यो अनुसूचकको काम गर्न र प्रश्नहरू थोरै पुन: लेख्न आवश्यक छ।

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

पुन:लेखन फिल्टर संग एक समान उदाहरण। यहाँ रूसको लागि अनुरोध छ। यो ५ सेकेन्डसम्म चल्छ। यदि हामीले यसलाई यसरी पुन: लेख्यौं कि हामी फेरि स्ट्रिङ होइन, तर रूससँग सम्बन्धित ती कुञ्जीहरूको सेटसँग संख्याहरू तुलना गर्छौं भने, यो धेरै छिटो हुनेछ।

यस्ता धेरै चालहरू छन्। र तिनीहरूले तपाईंलाई महत्त्वपूर्ण रूपमा प्रश्नहरूको गति बढाउन अनुमति दिन्छ जुन तपाईं सोच्नुहुन्छ कि पहिले नै छिटो चलिरहेको छ, वा, यसको विपरीत, बिस्तारै चलिरहेको छ। तिनीहरूलाई अझ छिटो बनाउन सकिन्छ।

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

त्यहाँ अन्य प्रविधिहरू छन्, र मैले प्रदर्शन गरेको मात्र होइन। र ती सबैले कहिलेकाहीँ महत्त्वपूर्ण रूपमा प्रश्नहरूको कार्यान्वयनलाई गति दिन सक्छन्।

अर्को उदाहरणमा जाऔं। अमेरिकाबाट कम्पनी एक्स। उनी के गर्दैछिन्?

त्यहाँ एउटा कार्य थियो:

• विज्ञापन लेनदेनको अफलाइन लिङ्किङ।
• विभिन्न बाध्यकारी मोडेल मोडेलिङ।

परिदृश्य के हो?

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

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

यो समस्या समाधान गर्नको लागि, तपाईंले वेबसाइटमा हुने घटनाहरूलाई सही तरिकामा जडान गर्न आवश्यक छ, त्यो हो, तिनीहरू बीच कुनै न कुनै रूपमा जडान निर्माण गर्नुहोस्। त्यसपछि तिनीहरूलाई DWH मा विश्लेषणको लागि पठाइन्छ। र यस विश्लेषणको आधारमा, कसले र कुन विज्ञापनहरू देखाउने मोडेलहरू निर्माण गर्नुहोस्।

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

त्यहाँ धेरै बाध्यकारी मोडेलहरू छन्।

सबैभन्दा लोकप्रिय निम्न हुन्:

• अन्तिम अन्तरक्रिया, जहाँ अन्तरक्रिया या त क्लिक वा छाप हो।
• पहिलो अन्तरक्रिया, अर्थात् पहिलो कुरा जसले व्यक्तिलाई साइटमा ल्यायो।
• रैखिक संयोजन - सबै समान रूपमा।
• क्षीणता।
• र यस्तै।

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

र यदि यो भाग्यशाली छ कि अनुरोधमा लेनदेन आईडी छ भने, यो सजिलो छ। तर सामान्यतया भाग्य छैन। त्यसकारण, अन्तिम लेनदेन वा अन्तिम क्लिकको साथ लेनदेन पत्ता लगाउन आवश्यक थियो।

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

र जब तिनीहरू प्रदर्शनमा लेनदेन लिङ्क गर्न चाहन्थे, यो तुरुन्तै रमाइलो भएन। र किन? यो देख्न सकिन्छ कि 30 गुणा बढी घटनाहरू भण्डारण गर्न आवश्यक छ। र, तदनुसार, तपाईंलाई 30 गुणा बढी सर्भरहरू चाहिन्छ। र यो बाहिर जान्छ कि यो खगोलीय आकृति को केहि प्रकार हो। रनटाइममा उल्लेखनीय रूपमा कम सर्भरहरू छन् भन्ने तथ्यको बावजुद लिङ्किङ गर्नको लागि 500 ​​सर्भरहरू राख्नको लागि, यो केहि प्रकारको गलत आंकडा हो। अनि के गर्ने भनेर सोच्न थाले ।

र हामी क्लिकहाउस गयौं। र यसलाई क्लिकहाउसमा कसरी गर्ने? पहिलो नजर मा, यो विरोधी ढाँचा को एक सेट जस्तो देखिन्छ।

• लेनदेन बढ्दै जान्छ, हामी यसमा थप घटनाहरू जोड्छौं, अर्थात् यो परिवर्तनीय छ, र क्लिकहाउसले परिवर्तनीय वस्तुहरूसँग धेरै राम्रोसँग काम गर्दैन।
• जब कुनै आगन्तुक हामीकहाँ आउँछन्, हामीले उसको लेनदेन कुञ्जीद्वारा, उसको भ्रमण आईडीद्वारा निकाल्नुपर्छ। यो पनि एउटा बिन्दु प्रश्न हो, तिनीहरूले क्लिकहाउसमा त्यसो गर्दैनन्। सामान्यतया ClickHouse मा ठूला ... स्क्यानहरू छन्, तर यहाँ हामीले केही रेकर्डहरू प्राप्त गर्न आवश्यक छ। पनि एक antipattern।
• थप रूपमा, लेनदेन json मा थियो, तर तिनीहरू यसलाई पुन: लेख्न चाहँदैनन्, त्यसैले तिनीहरू एक असंरचित तरिकामा json भण्डारण गर्न चाहन्थे, र आवश्यक भएमा, यसबाट केही निकाल्नुहोस्। र यो पनि एक antipattern छ।

त्यो हो, antipatterns को एक सेट।

तर तैपनि यो धेरै राम्रो काम गर्ने प्रणाली बनाउन बाहिर निस्कियो।

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

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

यदि तपाइँ क्लिकहाउस भित्र हेर्नुहुन्छ भने, त्यहाँ केवल 3 मुख्य तालिकाहरू छन् जुन यो सबै सेवा गर्दछ।

पहिलो तालिका जसमा लगहरू अपलोड गरिएका छन्, र लगहरू लगभग प्रशोधन नगरी अपलोड गरिएका छन्।

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

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

पहिलो महत्त्वपूर्ण कुरा क्लिकहाउसमा json बाट स्तम्भहरू र फिल्डहरू बाहिर निकाल्ने क्षमता हो। त्यो हो, क्लिकहाउससँग json सँग काम गर्ने केही विधिहरू छन्। तिनीहरू धेरै, धेरै आदिम छन्।

visitParamExtractInt ले तपाईंलाई json बाट विशेषताहरू निकाल्न अनुमति दिन्छ, अर्थात् पहिलो हिट कार्यहरू। र यस तरिकाले तपाईले लेनदेन आईडी निकाल्न सक्नुहुन्छ वा आईडी भ्रमण गर्न सक्नुहुन्छ। यो समय।

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

यस अवस्थामा, भौतिक दृश्य कच्चा पङ्क्तिहरूको लागि हो। र व्यावहारिक रूपमा कच्चा लगहरू भएको पहिलो तालिका भर्खरै प्रयोग गरिएको छ। अनि उसले के गर्छ? पहिले, यसले क्रमबद्ध परिवर्तन गर्दछ, अर्थात् क्रमबद्ध अब भ्रमण आईडी द्वारा जान्छ, किनकि हामीले एक विशेष व्यक्तिको लागि उसको लेनदेन तुरुन्तै बाहिर निकाल्न आवश्यक छ।

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

स्न्यापसटले केही अन्य रोचक क्लिकहाउस सुविधाहरू पनि प्रयोग गर्दछ।

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

• बाइन्डिङ रनटाइम बाट "decoupled" छ।
• प्रति महिना 3 बिलियन लेनदेनहरू भण्डारण र प्रशोधन गरिन्छ। यो क्यासान्ड्रामा भन्दा बढि परिमाणको अर्डर हो, अर्थात् सामान्य लेनदेन प्रणालीमा।
• 2x5 ClickHouse सर्भरहरूको क्लस्टर। 5 सर्भरहरू र प्रत्येक सर्भरको प्रतिकृति छ। यो क्लिक आधारित एट्रिब्युसन गर्नको लागि क्यासान्ड्रामा भएको भन्दा पनि कम छ, र यहाँ हामीसँग छाप आधारित छ। अर्थात् सर्भरको संख्या ३० गुणाले बढाउनुको सट्टा घटाउन सफल भयो ।

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

र कार्य थियो:

• करिब ५ हजार कित्ता रहेको छ ।
• प्रत्येक १०० मिलिसेकेन्डमा उद्धरणहरू ज्ञात छन्।
• 10 वर्ष भन्दा बढी डाटा संकलन गरिएको छ। स्पष्ट रूपमा, केहि कम्पनीहरु को लागी अधिक को लागी, केहि को लागी कम।
• कुलमा लगभग 100 बिलियन पङ्क्तिहरू छन्।

र यो परिवर्तन को सम्बन्ध गणना गर्न आवश्यक थियो।

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

यी पारस्परिक परिवर्तनहरू विश्लेषण, एक वित्तीय बजार मा भविष्यवाणी गर्न सक्नुहुन्छ।

तर काम गाह्रो छ। यसका लागि के भइरहेको छ ? हामीसँग 100 बिलियन रेकर्डहरू छन्: समय, स्टक, र मूल्य। हामीले मूल्य एल्गोरिथ्मबाट चलिरहेको भिन्नताको पहिलो 100 बिलियन गुणा गणना गर्न आवश्यक छ। RunningDifference ClickHouse मा एक प्रकार्य हो जसले क्रमशः दुई स्ट्रिङहरू बीचको भिन्नता गणना गर्दछ।

र त्यस पछि, तपाईंले सहसम्बन्ध गणना गर्न आवश्यक छ, र प्रत्येक जोडीको लागि सहसम्बन्ध गणना गरिनु पर्छ। 5 शेयरहरूको लागि, जोडीहरू 000 मिलियन छन्। र यो धेरै छ, अर्थात् 12,5 पटक यो यस्तो सहसंबंध प्रकार्य गणना गर्न आवश्यक छ।

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

यो कम्तिमा कुनै न कुनै रूपमा समय हुनु आवश्यक थियो, किनकि क्लिकहाउस आउनु अघि यी सबै धेरै, धेरै बिस्तारै काम गर्थे।

तिनीहरूले यसलाई हडूपमा, स्पार्कमा, ग्रीनप्लममा गणना गर्ने प्रयास गरे। र यो सबै धेरै ढिलो वा महँगो थियो। त्यो हो, यो कुनै पनि हिसाब गर्न सम्भव थियो, तर त्यसपछि यो महँगो थियो।

र त्यसपछि क्लिकहाउस आयो र चीजहरू धेरै राम्रो भयो।

म तपाईंलाई सम्झाउँछु कि हामीसँग डाटा लोकलिटीमा समस्या छ, किनभने सहसंबंधहरू स्थानीयकरण गर्न सकिँदैन। हामी केहि डाटा एक सर्भरमा राख्न सक्दैनौं, केहि अर्कोमा र गणना गर्न, हामीसँग सबै डाटा सबै ठाउँमा हुनुपर्छ।

तिनीहरूले के गरे? प्रारम्भमा, डाटा स्थानीयकृत छ। प्रत्येक सर्भरले सेयरको निश्चित सेटको मूल्य निर्धारणमा डाटा भण्डारण गर्दछ। र तिनीहरू ओभरल्याप गर्दैनन्। तसर्थ, समानान्तर र स्वतन्त्र रूपमा logReturn गणना गर्न सम्भव छ, यो सबै समानान्तर र वितरणमा अहिले सम्म हुन्छ।

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

त्यस पछि, यो नक्कल गर्न सकिन्छ। अक्षर "r" को अर्थ हो कि हामीले यो डेटा दोहोर्यायौं। त्यो हो, हामीसँग सबै तीन सर्भरहरूमा समान डेटा छ - यी arrays हुन्।

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

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

अवधारणाको प्रमाणमा, कार्य सबटास्क थियो, अर्थात्, कम डाटा लिइएको थियो। र केवल तीन सर्भरहरू।

यी पहिलो दुई चरणहरू: Log_return गणना गर्न र arrays मा लपेटन करिब एक घण्टा लाग्यो।

र सहसंबंध को गणना लगभग 50 घण्टा छ। तर ५० घन्टा पुग्दैन, किनकि उनीहरू हप्तासम्म काम गर्थे। यो एक ठूलो सफलता थियो। र यदि तपाइँ गणना गर्नुहुन्छ भने, त्यसपछि प्रति सेकेन्ड 50 पटक सबै कुरा यस क्लस्टरमा गणना गरिएको थियो।

तर सबैभन्दा महत्त्वपूर्ण कुरा यो हो कि यो प्रणाली व्यावहारिक रूपमा बाधाहरू बिना छ, अर्थात्, यो लगभग रैखिक मापन गर्दछ। र तिनीहरूले यसलाई जाँच गरे। यसलाई सफलतापूर्वक मापन गरियो।

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

र यो छोटो भाषणलाई संक्षेपमा, हामी भन्न सक्छौं कि ClickHouse ले अब व्यापारिक डाटाबेस र खुला स्रोत डाटाबेस दुवैको क्षेत्रलाई दृढतापूर्वक कब्जा गरेको छ, अर्थात् विशेष गरी विश्लेषणका लागि। उहाँ यस परिदृश्यमा पूर्ण रूपमा फिट हुनुहुन्छ। र अझ के छ, यसले बिस्तारै अरूलाई भीड गर्न थाल्छ, किनकि जब तपाईंसँग ClickHouse हुन्छ, तपाईंलाई InfiniDB आवश्यक पर्दैन। Vertika चाँडै आवश्यक नहुन सक्छ यदि तिनीहरूले सामान्य SQL समर्थन गर्छन्। मजा लिनुहोस्!

-रिपोर्ट को लागी धन्यवाद! निकै रोमान्चक! के त्यहाँ Apache Phoenix सँग कुनै तुलना थियो?

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

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

• Спасибо

  • शुभ दिउँसो म पहिले नै यस विषयमा धेरै चासो राखेको छु, किनकि मसँग एक विश्लेषणात्मक उपप्रणाली छ। तर जब मैले क्लिकहाउसलाई हेर्छु, मलाई लाग्छ कि क्लिकहाउस घटना विश्लेषणको लागि धेरै उपयुक्त छ, परिवर्तनीय। र यदि मलाई ठूला टेबलहरूको गुच्छाको साथ धेरै व्यापार डेटा विश्लेषण गर्न आवश्यक छ भने, क्लिकहाउस, जहाँसम्म मैले बुझेको छु, मेरो लागि धेरै उपयुक्त छैन? विशेष गरी यदि तिनीहरू परिवर्तन हुन्छन्। के यो सहि छ वा यसको खण्डन गर्न सक्ने उदाहरणहरू छन्?

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

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

निस्सन्देह, यो एक धेरै विशिष्ट कार्यको लागि ClickHouse को प्रयोग हो। यो अधिक परम्परागत रूपमा Hadoop भित्र हल गर्न सकिन्छ। Hadoop को लागी, यो एक आदर्श कार्य हो। तर Hadoop मा यो धेरै ढिलो छ। र मेरो लक्ष्य प्रदर्शन गर्नु हो कि ClickHouse ले कार्यहरू समाधान गर्न सक्छ जुन सामान्यतया पूर्ण रूपमा फरक माध्यमबाट हल गरिन्छ, तर एकै समयमा यो धेरै कुशलतापूर्वक गर्नुहोस्। यो एक विशेष कार्यको लागि अनुकूल छ। यो स्पष्ट छ कि यदि त्यहाँ समान चीजको साथ समस्या छ भने, त्यसलाई समान रूपमा समाधान गर्न सकिन्छ।

यो स्पष्ट छ। तपाईंले भन्नुभयो कि 50 घण्टा प्रक्रिया भयो। यो सुरुदेखि नै हो, तपाईंले डाटा कहिले लोड गर्नुभयो वा नतिजा प्राप्त गर्नुभयो?

हो हो।

धेरै धेरै धन्यवाद।

यो 3 सर्भर क्लस्टरमा छ।

अभिवादन! रिपोर्ट को लागी धन्यवाद! सबै धेरै रोचक छ। म कार्यक्षमताको बारेमा थोरै सोध्ने छैन, तर स्थिरताको सर्तमा क्लिकहाउसको प्रयोगको बारेमा। त्यो हो, के तपाईसँग कुनै छ, तपाईले पुनर्स्थापना गर्नुपर्‍यो? यस अवस्थामा क्लिकहाउसले कसरी व्यवहार गर्छ? र के यो भयो कि तपाईसँग प्रतिकृति पनि थियो? उदाहरणका लागि, हामीले ClickHouse मा समस्याको सामना गर्यौं जब यो अझै यसको सीमाबाट बाहिर जान्छ र खस्छ।

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

नमस्ते! तपाईले भन्नुभयो कि तपाईले डाटा स्कीमामा तुरुन्तै सोच्न आवश्यक छ। के भयो भने? मेरो डाटा खन्याउँदै र खन्याइरहेछ। छ महिना बित्यो, र म बुझ्छु कि यो यसरी बाँच्न असम्भव छ, मैले डाटा पुन: अपलोड गर्न र तिनीहरूसँग केहि गर्न आवश्यक छ।

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

Спасибо।

स्रोत: www.habr.com