वास्तविक अनुप्रयोगांमध्ये क्लिकहाऊस वापरण्याचा सिद्धांत आणि सराव. अलेक्झांडर झैत्सेव्ह (२०१८)

आता जवळजवळ सर्वत्र भरपूर डेटा आहे हे असूनही, विश्लेषणात्मक डेटाबेस अजूनही बरेच विदेशी आहेत. ते खराब ज्ञात आहेत आणि त्यांचा प्रभावीपणे वापर करण्यास सक्षम आहेत. बरेचजण MySQL किंवा PostgreSQL सह "कॅक्टस खाणे" सुरू ठेवतात, जे इतर परिस्थितींसाठी डिझाइन केलेले आहेत, NoSQL सह त्रास सहन करतात किंवा व्यावसायिक उपायांसाठी जास्त पैसे देतात. क्लिकहाऊस गेमचे नियम बदलते आणि विश्लेषणात्मक DBMS च्या जगात प्रवेश करण्यासाठी थ्रेशोल्ड लक्षणीयरीत्या कमी करते.

बॅकएंड कॉन्फ 2018 कडून अहवाल आणि तो स्पीकरच्या परवानगीने प्रकाशित केला जातो.

मी कोण आहे आणि मी क्लिकहाऊसबद्दल का बोलत आहे? मी लाइफस्ट्रीटचा विकास संचालक आहे, जो क्लिकहाऊस वापरतो. तसेच, मी Altinity चा संस्थापक आहे. हा Yandex भागीदार आहे जो ClickHouse ला प्रोत्साहन देतो आणि Yandex ला ClickHouse ला अधिक यशस्वी करण्यात मदत करतो. क्लिकहाऊसबद्दलचे ज्ञान सामायिक करण्यासाठी देखील तयार आहे.

आणि मी पेट्या जैत्सेव्हचा भाऊ नाही. याबाबत मला अनेकदा विचारले जाते. नाही, आम्ही भाऊ नाही.

क्लिकहाऊस "प्रत्येकाला माहित आहे":

• अतिशय जलद,
• खूप आरामदायक
• Yandex मध्ये वापरले.

ते कोणत्या कंपन्यांमध्ये आणि कसे वापरले जाते हे थोडेसे कमी आहे.

यॅन्डेक्स व्यतिरिक्त क्लिकहाऊस का, कुठे आणि कसे वापरले जाते ते मी तुम्हाला सांगेन.

वेगवेगळ्या कंपन्यांमध्ये क्लिकहाऊस वापरून विशिष्ट कार्ये कशी सोडवली जातात, तुम्ही तुमच्या कामांसाठी कोणती क्लिकहाऊस टूल्स वापरू शकता आणि ती वेगवेगळ्या कंपन्यांमध्ये कशी वापरली गेली हे मी तुम्हाला सांगेन.

मी वेगवेगळ्या कोनातून क्लिकहाऊस दर्शवणारी तीन उदाहरणे उचलली. मला वाटते की ते मनोरंजक असेल.

पहिला प्रश्न आहे: “आम्हाला क्लिकहाऊसची गरज का आहे?”. हा एक स्पष्ट प्रश्न आहे असे दिसते, परंतु त्याची एकापेक्षा जास्त उत्तरे आहेत.

• पहिले उत्तर कामगिरीसाठी आहे. क्लिकहाऊस खूप वेगवान आहे. क्लिकहाऊसवरील विश्लेषण देखील खूप वेगवान आहे. हे बर्‍याचदा वापरले जाऊ शकते जेथे दुसरे काहीतरी खूप मंद किंवा खूप वाईट आहे.
• दुसरे उत्तर म्हणजे खर्च. आणि सर्व प्रथम, स्केलिंगची किंमत. उदाहरणार्थ, व्हर्टिका हा एक उत्तम डेटाबेस आहे. तुमच्याकडे भरपूर टेराबाइट डेटा नसल्यास हे खूप चांगले कार्य करते. परंतु जेव्हा शेकडो टेराबाइट्स किंवा पेटाबाइट्सचा विचार केला जातो तेव्हा परवाना आणि समर्थनाची किंमत बर्‍यापैकी लक्षणीय प्रमाणात जाते. आणि ते महाग आहे. आणि क्लिकहाऊस विनामूल्य आहे.
• तिसरे उत्तर म्हणजे ऑपरेटिंग कॉस्ट. हा थोडा वेगळा दृष्टिकोन आहे. RedShift एक उत्तम अॅनालॉग आहे. RedShift वर, तुम्ही खूप लवकर निर्णय घेऊ शकता. हे चांगले कार्य करेल, परंतु त्याच वेळी, दर तासाला, दररोज आणि दर महिन्याला, तुम्ही Amazon ला खूप महागडे पैसे द्याल, कारण ही एक लक्षणीय महाग सेवा आहे. Google BigQuery देखील. जर एखाद्याने ते वापरले असेल तर त्याला माहित आहे की तेथे तुम्ही अनेक विनंत्या चालवू शकता आणि अचानक शेकडो डॉलर्सचे बिल मिळवू शकता.

क्लिकहाऊसमध्ये या समस्या नाहीत.

क्लिकहाऊस आता कुठे वापरले जाते? Yandex व्यतिरिक्त, ClickHouse विविध व्यवसाय आणि कंपन्यांच्या समूहामध्ये वापरले जाते.

• सर्व प्रथम, हे वेब ऍप्लिकेशन विश्लेषण आहे, म्हणजे हे Yandex कडून आलेले एक वापर प्रकरण आहे.
• अनेक AdTech कंपन्या ClickHouse वापरतात.
• अनेक कंपन्या ज्यांना विविध स्त्रोतांकडून व्यवहार नोंदींचे विश्लेषण करणे आवश्यक आहे.
• अनेक कंपन्या सुरक्षा नोंदींचे निरीक्षण करण्यासाठी क्लिकहाऊस वापरतात. ते क्लिकहाऊसवर अपलोड करतात, अहवाल तयार करतात आणि त्यांना आवश्यक परिणाम मिळवतात.
• कंपन्या त्याचा आर्थिक विश्लेषणात वापर करू लागल्या आहेत, म्हणजेच हळूहळू मोठे व्यवसाय देखील क्लिकहाऊसकडे येत आहेत.
• ढगफुटी जर कोणी क्लिकहाऊसचे अनुसरण करत असेल तर त्यांनी या कंपनीचे नाव ऐकले असेल. हे समाजातील आवश्यक योगदानांपैकी एक आहे. आणि त्यांच्याकडे एक अतिशय गंभीर क्लिकहाऊस स्थापना आहे. उदाहरणार्थ, त्यांनी क्लिकहाऊससाठी काफ्का इंजिन बनवले.
• दूरसंचार कंपन्या वापरू लागल्या. अनेक कंपन्या क्लिकहाऊस एकतर संकल्पनेचा पुरावा म्हणून वापरतात किंवा आधीच उत्पादनात आहेत.
• एक कंपनी उत्पादन प्रक्रियांचे निरीक्षण करण्यासाठी क्लिकहाऊस वापरते. ते मायक्रोसर्किट्सची चाचणी करतात, पॅरामीटर्सचा एक समूह लिहून देतात, सुमारे 2 वैशिष्ट्ये आहेत. आणि मग ते खेळ चांगला की वाईट याचे विश्लेषण करतात.
• ब्लॉकचेन विश्लेषण. Bloxy.info सारखी रशियन कंपनी आहे. हे इथरियम नेटवर्कचे विश्लेषण आहे. त्यांनी हे क्लिकहाऊसवरही केले.

आणि आकार काही फरक पडत नाही. एक लहान सर्व्हर वापरणाऱ्या अनेक कंपन्या आहेत. आणि तो त्यांना त्यांच्या समस्या सोडवण्यास परवानगी देतो. आणि आणखी कंपन्या अनेक सर्व्हर किंवा डझनभर सर्व्हरचे मोठे क्लस्टर वापरतात.

आणि जर तुम्ही नोंदी पाहिल्या तर:

• Yandex: 500+ सर्व्हर, ते तेथे दररोज 25 अब्ज रेकॉर्ड संग्रहित करतात.
• लाइफस्ट्रीट: 60 सर्व्हर, दररोज अंदाजे 75 अब्ज रेकॉर्ड. Yandex पेक्षा कमी सर्व्हर, अधिक रेकॉर्ड आहेत.
• CloudFlare: 36 सर्व्हर, ते दररोज 200 अब्ज रेकॉर्ड वाचवतात. त्यांच्याकडे अगदी कमी सर्व्हर आहेत आणि त्याहून अधिक डेटा संग्रहित करतात.
• ब्लूमबर्ग: 102 सर्व्हर, दररोज सुमारे एक ट्रिलियन नोंदी. रेकॉर्ड धारक.

भौगोलिकदृष्ट्या, हे देखील बरेच आहे. हा नकाशा येथे क्लिकहाऊस जगात कुठे वापरला जात आहे याचा हीटमॅप दाखवतो. रशिया, चीन, अमेरिका येथे स्पष्टपणे उभे आहेत. काही युरोपियन देश आहेत. आणि 4 क्लस्टर आहेत.

हे तुलनात्मक विश्लेषण आहे, निरपेक्ष आकडे पाहण्याची गरज नाही. हे अभ्यागतांचे विश्लेषण आहे जे अल्टिनिटी वेबसाइटवर इंग्रजी भाषेतील साहित्य वाचतात, कारण तेथे रशियन भाषिक नाहीत. आणि रशिया, युक्रेन, बेलारूस, म्हणजे समुदायाचा रशियन भाषिक भाग, हे सर्वाधिक असंख्य वापरकर्ते आहेत. त्यानंतर अमेरिका आणि कॅनडा येतो. चीन खूप पकड घेत आहे. सहा महिन्यांपूर्वी तेथे चीन जवळजवळ नव्हताच, आता चीनने युरोपला मागे टाकले आहे आणि वाढत आहे. जुना युरोप देखील मागे नाही, आणि क्लिकहाऊसच्या वापरामध्ये आघाडीवर आहे, विचित्रपणे, फ्रान्स.

मी हे सर्व का सांगत आहे? क्लिकहाऊस हे मोठ्या डेटा विश्लेषणासाठी एक मानक उपाय बनत आहे आणि आधीच बर्‍याच ठिकाणी वापरले जात आहे हे दर्शविण्यासाठी. तुम्ही ते वापरत असल्यास, तुम्ही योग्य ट्रेंडमध्ये आहात. आपण अद्याप ते वापरत नसल्यास, आपण घाबरू शकत नाही की आपल्याला एकटे सोडले जाईल आणि कोणीही आपल्याला मदत करणार नाही, कारण बरेच जण आधीच हे करत आहेत.

ही अनेक कंपन्यांमधील वास्तविक क्लिकहाऊस वापराची उदाहरणे आहेत.

• पहिले उदाहरण जाहिरात नेटवर्क आहे: व्हर्टिका ते क्लिकहाऊस स्थलांतर. आणि मला अशा काही कंपन्या माहित आहेत ज्यांनी व्हर्टिकामधून संक्रमण केले आहे किंवा संक्रमण प्रक्रियेत आहे.
• दुसरे उदाहरण क्लिकहाऊसवरील व्यवहार संचयन आहे. हे अँटीपॅटर्नवर तयार केलेले उदाहरण आहे. विकसकांच्या सल्ल्यानुसार क्लिकहाऊसमध्ये करू नये अशा सर्व गोष्टी येथे केल्या आहेत. आणि ते इतके प्रभावीपणे केले आहे की ते कार्य करते. आणि हे ठराविक व्यवहाराच्या सोल्यूशनपेक्षा बरेच चांगले कार्य करते.
• तिसरे उदाहरण क्लिकहाऊसवर वितरित संगणन आहे. क्लिकहाऊस हडूप इकोसिस्टममध्ये कसे समाकलित केले जाऊ शकते याबद्दल एक प्रश्न होता. अगदी क्षुल्लक कामाची गणना करण्यासाठी एका कंपनीने क्लिकहाऊसवरील नकाशा कमी कंटेनर, डेटा लोकॅलायझेशनचा मागोवा ठेवणे इत्यादी गोष्टी कशा केल्या याचे उदाहरण मी दाखवीन.

• लाइफस्ट्रीट ही एक अॅड टेक कंपनी आहे ज्यात जाहिरात नेटवर्कसह येणारे सर्व तंत्रज्ञान आहे.
• ती जाहिरात ऑप्टिमायझेशन, प्रोग्रामेटिक बिडिंगमध्ये गुंतलेली आहे.
• भरपूर डेटा: दररोज सुमारे 10 अब्ज इव्हेंट. त्याच वेळी, तेथील घटनांना अनेक उप-इव्हेंटमध्ये विभागले जाऊ शकते.
• या डेटाचे बरेच क्लायंट आहेत आणि हे केवळ लोकच नाहीत तर बरेच काही - हे विविध अल्गोरिदम आहेत जे प्रोग्रामेटिक बिडिंगमध्ये गुंतलेले आहेत.

कंपनी एक लांब आणि काटेरी मार्ग आला आहे. आणि मी हायलोडवर याबद्दल बोललो. प्रथम, लाइफस्ट्रीट MySQL वरून (Oracle येथे एक लहान स्टॉपसह) व्हर्टिका येथे गेले. आणि आपण याबद्दल एक कथा शोधू शकता.

आणि सर्वकाही खूप चांगले होते, परंतु हे त्वरीत स्पष्ट झाले की डेटा वाढत आहे आणि व्हर्टिका महाग आहे. त्यामुळे विविध पर्याय शोधण्यात आले. त्यापैकी काही येथे सूचीबद्ध आहेत. आणि खरं तर, आम्ही 13व्या ते 16व्या वर्षापर्यंत बाजारात उपलब्ध असलेल्या आणि कार्यक्षमतेच्या दृष्टीने अंदाजे योग्य असलेल्या जवळजवळ सर्व डेटाबेसच्या संकल्पनेचा पुरावा किंवा काहीवेळा कार्यप्रदर्शन चाचणी केली. आणि मी हायलोडवर त्यापैकी काहींबद्दल बोललो.

कार्य प्रथम स्थानावर व्हर्टिका वरून स्थलांतर करणे होते, कारण डेटा वाढला. आणि वर्षानुवर्षे ते झपाट्याने वाढले. मग ते शेल्फवर गेले, परंतु तरीही. आणि या वाढीचा अंदाज लावताना, डेटाच्या प्रमाणासाठी व्यवसाय आवश्यकता ज्यावर काही प्रकारचे विश्लेषण करणे आवश्यक आहे, हे स्पष्ट होते की पेटाबाइट्सवर लवकरच चर्चा केली जाईल. आणि पेटाबाइट्ससाठी पैसे देणे आधीच खूप महाग आहे, म्हणून आम्ही कुठे जायचे याचा पर्याय शोधत होतो.

कुठे जायचे आहे? आणि कोठे जायचे हे बर्याच काळापासून स्पष्ट नव्हते, कारण एकीकडे व्यावसायिक डेटाबेस आहेत, ते चांगले कार्य करतात असे दिसते. काही जवळपास तसेच व्हर्टिकाप्रमाणेच काम करतात, काही वाईट. परंतु ते सर्व महाग आहेत, स्वस्त आणि चांगले काहीही सापडले नाही.

दुसरीकडे, ओपन सोर्स सोल्यूशन्स आहेत, जे फारसे असंख्य नाहीत, म्हणजेच विश्लेषणासाठी, ते बोटांवर मोजता येतील. आणि ते विनामूल्य किंवा स्वस्त आहेत, परंतु हळू आहेत. आणि त्यांच्याकडे अनेकदा आवश्यक आणि उपयुक्त कार्यक्षमतेचा अभाव असतो.

आणि व्यावसायिक डेटाबेसमध्ये असलेल्या चांगल्या गोष्टी आणि मुक्त स्त्रोतांमध्ये असलेले सर्व विनामूल्य एकत्र करण्यासाठी काहीही नव्हते.

अनपेक्षितपणे, यांडेक्सने हॅटमधून जादूगार, सशासारखे क्लिकहाऊस बाहेर काढले तोपर्यंत काहीही नव्हते. आणि हा एक अनपेक्षित निर्णय होता, ते अजूनही प्रश्न विचारतात: “का?”, पण तरीही.

आणि लगेचच 2016 च्या उन्हाळ्यात, आम्ही क्लिकहाऊस काय आहे ते पाहू लागलो. आणि असे दिसून आले की कधीकधी ते व्हर्टिकापेक्षा वेगवान असू शकते. आम्ही वेगवेगळ्या विनंत्यांवर वेगवेगळ्या परिस्थितींची चाचणी घेतली. आणि जर क्वेरीमध्ये फक्त एक टेबल वापरला असेल, म्हणजे कोणत्याही जोडणीशिवाय (सामील व्हा), तर क्लिकहाऊस व्हर्टिकापेक्षा दुप्पट वेगवान होते.

मी खूप आळशी नव्हतो आणि दुसऱ्या दिवशी यांडेक्स चाचण्या पाहिल्या. तिथेही तेच आहे: क्लिकहाऊस व्हर्टिकापेक्षा दुप्पट वेगवान आहे, म्हणून ते बर्याचदा याबद्दल बोलतात.

परंतु जर प्रश्नांमध्ये सामील झाले असतील तर सर्व काही अगदी अस्पष्टपणे बाहेर वळते. आणि क्लिकहाऊस व्हर्टिकापेक्षा दुप्पट हळू असू शकते. आणि जर तुम्ही विनंती थोडीशी दुरुस्त केली आणि ती पुन्हा लिहिली तर ते अंदाजे समान आहेत. वाईट नाही. आणि मोफत.

आणि चाचणीचे निकाल मिळाल्यानंतर, आणि वेगवेगळ्या कोनातून त्याकडे पाहत, LifeStreet क्लिकहाऊसवर गेली.

हे 16 वे वर्ष आहे, मी तुम्हाला आठवण करून देतो. हे उंदरांबद्दल चेष्टेसारखे होते जे रडले आणि स्वतःला टोचले, परंतु निवडुंग खात राहिले. आणि याचे तपशीलवार वर्णन केले आहे, याबद्दल एक व्हिडिओ आहे इ.

म्हणून, मी याबद्दल तपशीलवार बोलणार नाही, मी फक्त परिणाम आणि काही मनोरंजक गोष्टींबद्दल बोलेन ज्याबद्दल मी तेव्हा बोललो नाही.

परिणाम आहेत:

• यशस्वी स्थलांतर आणि एक वर्षाहून अधिक काळ सिस्टम आधीच उत्पादनात कार्यरत आहे.
• उत्पादकता आणि लवचिकता वाढली आहे. 10 अब्ज रेकॉर्डपैकी जे आम्ही दररोज आणि नंतर थोड्या काळासाठी साठवू शकतो, लाइफस्ट्रीट आता दररोज 75 अब्ज रेकॉर्ड संग्रहित करते आणि हे 3 महिने किंवा त्याहून अधिक काळ करू शकते. आपण शिखरावर मोजल्यास, हे प्रति सेकंद एक दशलक्ष घटनांपर्यंत आहे. या प्रणालीमध्ये दररोज दहा लाखाहून अधिक SQL क्वेरी येतात, बहुतेक वेगवेगळ्या रोबोट्सकडून.
• Vertica पेक्षा ClickHouse साठी जास्त सर्व्हर वापरले गेले होते हे असूनही, ते हार्डवेअरवर देखील जतन केले गेले, कारण Vertica मध्ये महागड्या SAS डिस्क वापरल्या गेल्या. क्लिकहाऊसने SATA वापरले. आणि का? कारण Vertica मध्ये insert synchronous आहे. आणि सिंक्रोनाइझेशनसाठी आवश्यक आहे की डिस्क्स खूप कमी होत नाहीत आणि नेटवर्क खूप कमी होत नाही, म्हणजेच एक महाग ऑपरेशन. आणि ClickHouse मध्ये insert asynchronous आहे. शिवाय, तुम्ही नेहमी सर्व काही स्थानिक पातळीवर लिहू शकता, यासाठी कोणतेही अतिरिक्त खर्च नाहीत, त्यामुळे धीमे ड्राइव्हवरही, व्हर्टिकापेक्षा क्लिकहाऊसमध्ये डेटा अधिक वेगाने टाकला जाऊ शकतो. आणि वाचन सारखेच आहे. SATA वर वाचणे, जर ते RAID मध्ये असतील तर हे सर्व पुरेसे जलद आहे.
• परवान्याद्वारे मर्यादित नाही, म्हणजे 3 सर्व्हरमध्ये 60 पेटाबाइट डेटा (20 सर्व्हर एक प्रतिकृती आहे) आणि तथ्ये आणि एकत्रीकरणामध्ये 6 ट्रिलियन रेकॉर्ड. व्हर्टिका येथे असे काहीही परवडणारे नाही.

मी आता या उदाहरणातील व्यावहारिक गोष्टींकडे वळतो.

• पहिली कार्यक्षम योजना आहे. स्कीमावर बरेच काही अवलंबून असते.
• दुसरी कार्यक्षम SQL जनरेशन आहे.

ठराविक OLAP क्वेरी ही निवड आहे. काही स्तंभ समूहानुसार जातात, काही स्तंभ एकत्रित फंक्शन्सवर जातात. तेथे आहे, ज्याला क्यूबचा तुकडा म्हणून दर्शविले जाऊ शकते. संपूर्ण गटाचा प्रक्षेपण म्हणून विचार केला जाऊ शकतो. आणि म्हणूनच याला मल्टीव्हेरिएट डेटा विश्लेषण म्हणतात.

आणि बहुतेकदा हे तारा-योजनेच्या रूपात तयार केले जाते, जेव्हा किरणांच्या बाजूने या वस्तुस्थितीची मध्यवर्ती वस्तुस्थिती आणि वैशिष्ट्ये असतात.

आणि भौतिक रचनेच्या दृष्टीने, ते टेबलवर कसे बसते, ते सहसा सामान्यीकृत प्रतिनिधित्व करतात. तुम्ही डिनॉर्मलाइझ करू शकता, परंतु ते डिस्कवर महाग आहे आणि क्वेरीवर फारसे कार्यक्षम नाही. म्हणून, ते सहसा सामान्यीकृत प्रतिनिधित्व करतात, म्हणजे तथ्य सारणी आणि अनेक, अनेक आयाम सारण्या.

परंतु क्लिकहाऊसमध्ये ते चांगले कार्य करत नाही. दोन कारणे आहेत:

• पहिले कारण क्लिकहाऊसमध्ये फार चांगले जॉइन्स नाहीत, म्हणजे जॉइन्स आहेत, पण ते खराब आहेत. वाईट असताना.
• दुसरे म्हणजे टेबल अपडेट केलेले नाहीत. सहसा या प्लेट्समध्ये, जे स्टार-सर्किटच्या आसपास असतात, काहीतरी बदलणे आवश्यक आहे. उदाहरणार्थ, ग्राहकाचे नाव, कंपनीचे नाव इ. आणि ते काम करत नाही.

आणि क्लिकहाऊसमध्ये यातून बाहेर पडण्याचा एक मार्ग आहे. अगदी दोन:

• प्रथम शब्दकोषांचा वापर आहे. एक्सटर्नल डिक्शनरी म्हणजे 99% तारा-स्कीमा, अद्यतने इत्यादीसह समस्या सोडविण्यास मदत करते.
• दुसरे म्हणजे अॅरेचा वापर. अॅरे जॉइन्स आणि सामान्यीकरणातील समस्यांपासून मुक्त होण्यास मदत करतात.

• सामील होण्याची गरज नाही.
• अपग्रेड करण्यायोग्य. मार्च 2018 पासून, अंशतः डिक्शनरी अपडेट करण्याची एक अदस्तांकित संधी उपलब्ध झाली आहे (तुम्हाला हे दस्तऐवजात सापडणार नाही), म्हणजे बदललेल्या नोंदी. व्यावहारिकदृष्ट्या, ते टेबलसारखे आहे.
• नेहमी मेमरीमध्ये असते, त्यामुळे डिक्शनरीमध्ये सामील होते जे डिस्कवर असलेलं टेबल असेल आणि ते कॅशेमध्ये आहे हे अजून खरं नाही, बहुधा नाही.

• तुम्हाला सामील होण्याचीही गरज नाही.
• हे कॉम्पॅक्ट 1-टू-मनी प्रतिनिधित्व आहे.
• आणि माझ्या मते, अॅरे गीक्ससाठी बनवले जातात. ही लॅम्बडा फंक्शन्स वगैरे आहेत.

हे लाल शब्दांसाठी नाही. ही एक अतिशय शक्तिशाली कार्यक्षमता आहे जी तुम्हाला बर्‍याच गोष्टी अगदी सोप्या आणि मोहक पद्धतीने करण्याची परवानगी देते.

अॅरे सोडवण्यास मदत करणारी ठराविक उदाहरणे. ही उदाहरणे सोपी आणि पुरेशी स्पष्ट आहेत:

• टॅगद्वारे शोधा. तुमच्याकडे हॅशटॅग असल्यास आणि हॅशटॅगद्वारे काही पोस्ट शोधू इच्छित असल्यास.
• की-व्हॅल्यू जोड्यांनुसार शोधा. मूल्यासह काही गुणधर्म देखील आहेत.
• तुम्हाला दुसर्‍या कशात तरी अनुवादित करण्‍याची आवश्‍यकता असलेल्या कीजच्‍या सूची संचयित करणे.

ही सर्व कार्ये अॅरेशिवाय सोडवता येतात. टॅग्ज काही ओळीत ठेवता येतात आणि रेग्युलर एक्सप्रेशनसह किंवा वेगळ्या टेबलमध्ये निवडले जाऊ शकतात, परंतु नंतर तुम्हाला जोडणे आवश्यक आहे.

आणि क्लिकहाऊसमध्ये, तुम्हाला काहीही करण्याची गरज नाही, हॅशटॅगसाठी स्ट्रिंग अॅरेचे वर्णन करणे किंवा की-व्हॅल्यू सिस्टमसाठी नेस्टेड रचना करणे पुरेसे आहे.

नेस्टेड स्ट्रक्चर हे सर्वोत्तम नाव असू शकत नाही. हे दोन अ‍ॅरे आहेत ज्यांचा नावात एक समान भाग आहे आणि काही संबंधित वैशिष्ट्ये आहेत.

आणि टॅगद्वारे शोधणे खूप सोपे आहे. एक कार्य आहे has, जे अ‍ॅरेमध्ये घटक असल्याचे तपासते. प्रत्येकाला, आमच्या कॉन्फरन्सशी संबंधित सर्व नोंदी सापडल्या.

subid द्वारे शोधणे थोडे अधिक क्लिष्ट आहे. आपण प्रथम कीची अनुक्रमणिका शोधणे आवश्यक आहे, आणि नंतर या निर्देशांकासह घटक घ्या आणि हे मूल्य आपल्याला आवश्यक आहे हे तपासा. तथापि, ते अतिशय सोपे आणि संक्षिप्त आहे.

जर तुम्ही हे सर्व एका ओळीत ठेवले तर तुम्हाला लिहायला आवडेल असा रेग्युलर एक्स्प्रेशन, प्रथमतः अनाड़ी असेल. आणि, दुसरे म्हणजे, ते दोन अॅरेपेक्षा जास्त काळ काम करते.

दुसरे उदाहरण. तुमच्याकडे एक अॅरे आहे जिथे तुम्ही आयडी स्टोअर करता. आणि तुम्ही त्यांचे नावांमध्ये भाषांतर करू शकता. कार्य arrayMap. हे एक सामान्य लॅम्बडा फंक्शन आहे. तुम्ही तिथे लॅम्बडा एक्सप्रेशन पास करता. आणि ती डिक्शनरीमधून प्रत्येक आयडीसाठी नावाची किंमत काढते.

शोध त्याच प्रकारे करता येतो. एक predicate फंक्शन पास केले जाते जे घटक काय जुळतात ते तपासते.

या गोष्टी सर्किटला मोठ्या प्रमाणात सुलभ करतात आणि अनेक समस्यांचे निराकरण करतात.

परंतु पुढील समस्या ज्याचा आपण सामना करत आहोत, आणि ज्याचा मी उल्लेख करू इच्छितो, ती कार्यक्षम क्वेरी आहे.

• ClickHouse मध्ये क्वेरी प्लॅनर नाही. अजिबात नाही.
• तरीही, जटिल प्रश्नांचे नियोजन करणे आवश्यक आहे. कोणत्या प्रकरणांमध्ये?
• क्वेरीमध्‍ये एकाधिक सामील असल्‍यास, तुम्ही ते उपनिवडकांमध्ये गुंडाळा. आणि ज्या क्रमाने त्यांना अंमलात आणले जाते ते महत्त्वाचे आहे.
• आणि दुसरा - जर विनंती वितरित केली गेली असेल तर. कारण वितरीत केलेल्या क्वेरीमध्ये, फक्त सर्वात आतील उपनिवड वितरीत केली जाते आणि बाकी सर्व काही तुम्ही कनेक्ट केलेल्या आणि तेथे कार्यान्वित केलेल्या सर्व्हरला पाठवले जाते. म्हणून, जर तुम्ही अनेक जोड्यांसह (सामील व्हा) क्वेरी वितरित केल्या असतील, तर तुम्हाला ऑर्डर निवडण्याची आवश्यकता आहे.

आणि अगदी सोप्या प्रकरणांमध्ये, कधीकधी शेड्यूलरचे कार्य करणे आणि प्रश्न थोडेसे पुन्हा लिहिणे देखील आवश्यक असते.

येथे एक उदाहरण आहे. डाव्या बाजूला एक क्वेरी आहे जी शीर्ष 5 देश दर्शवते. आणि माझ्या मते 2,5 सेकंद लागतात. आणि उजव्या बाजूला, समान क्वेरी, परंतु थोडेसे पुन्हा लिहिलेले. स्ट्रिंगद्वारे गटबद्ध करण्याऐवजी, आम्ही की (इंट) द्वारे गटबद्ध करू लागलो. आणि ते अधिक वेगवान आहे. आणि मग आम्ही परिणामाशी एक शब्दकोश जोडला. 2,5 सेकंदांऐवजी, विनंतीला 1,5 सेकंद लागतात. हे चांगले आहे.

पुनर्लेखन फिल्टरसह एक समान उदाहरण. येथे रशियासाठी एक विनंती आहे. हे 5 सेकंद चालते. जर आपण ते अशा प्रकारे पुन्हा लिहिले की आपण पुन्हा स्ट्रिंगची नव्हे तर रशियाशी संबंधित कीच्या काही संचासह संख्यांची तुलना केली तर ते अधिक वेगवान होईल.

अशा अनेक युक्त्या आहेत. आणि ते तुम्हाला अशा प्रश्नांची गती वाढवण्याची परवानगी देतात ज्या तुम्हाला वाटते की आधीच वेगाने धावत आहेत, किंवा उलट, हळू चालत आहेत. ते आणखी जलद केले जाऊ शकतात.

• वितरित मोडमध्ये जास्तीत जास्त काम.
• किमान प्रकारांनुसार क्रमवारी लावणे, जसे मी ints द्वारे केले.
• जर तेथे कोणतेही जोडणे (सामील होणे), शब्दकोष असतील, तर शेवटचा उपाय म्हणून ते करणे चांगले आहे, जेव्हा तुमच्याकडे आधीच डेटा किमान अंशतः गटबद्ध असेल, तेव्हा जॉइन ऑपरेशन किंवा डिक्शनरी कॉल कमी वेळा कॉल केला जाईल आणि ते जलद होईल.
• फिल्टर बदलत आहे.

इतर तंत्रे आहेत, आणि फक्त तीच नाहीत जी मी दाखवली आहेत. आणि ते सर्व काहीवेळा प्रश्नांच्या अंमलबजावणीला लक्षणीय गती देऊ शकतात.

पुढच्या उदाहरणाकडे वळू. यूएसए पासून कंपनी एक्स. ती काय करत आहे?

एक कार्य होते:

• जाहिरात व्यवहारांची ऑफलाइन लिंकिंग.
• विविध बंधनकारक मॉडेलचे मॉडेलिंग.

परिस्थिती काय आहे?

एक सामान्य अभ्यागत साइटवर येतो, उदाहरणार्थ, वेगवेगळ्या जाहिरातींमधून महिन्यातून 20 वेळा, किंवा तसाच कधी कधी कोणत्याही जाहिरातीशिवाय येतो, कारण त्याला ही साइट आठवते. काही उत्पादने पाहतो, टोपलीत ठेवतो, टोपलीतून बाहेर काढतो. आणि, शेवटी, काहीतरी विकत घेते.

वाजवी प्रश्न: "आवश्यक असल्यास, जाहिरातीसाठी कोणी पैसे द्यावे?" आणि "कोणत्या जाहिरातींचा त्याच्यावर प्रभाव पडला, जर असेल तर?". म्हणजेच, त्याने खरेदी का केली आणि या व्यक्तीसारख्या लोकांना देखील खरेदी कशी करावी?

या समस्येचे निराकरण करण्यासाठी, आपल्याला वेबसाइटवर घडणार्‍या घटनांना योग्य मार्गाने कनेक्ट करणे आवश्यक आहे, म्हणजे, त्यांच्यामध्ये कसा तरी संबंध तयार करणे आवश्यक आहे. मग ते DWH कडे विश्लेषणासाठी पाठवले जातात. आणि या विश्लेषणाच्या आधारे, कोणाला आणि कोणत्या जाहिराती दाखवायच्या याचे मॉडेल तयार करा.

जाहिरात व्यवहार हा संबंधित वापरकर्ता इव्हेंटचा संच असतो जो जाहिरात दाखवण्यापासून सुरू होतो, नंतर काहीतरी घडते, नंतर कदाचित खरेदी होते आणि नंतर खरेदीमध्ये खरेदी असू शकते. उदाहरणार्थ, जर हे मोबाइल अॅप्लिकेशन किंवा मोबाइल गेम असेल, तर सहसा अॅप्लिकेशनची स्थापना विनामूल्य केली जाते आणि जर तेथे काही केले गेले असेल तर त्यासाठी पैसे आवश्यक असू शकतात. आणि एखादी व्यक्ती अनुप्रयोगात जितका अधिक खर्च करेल तितकेच ते अधिक मौल्यवान आहे. परंतु यासाठी आपल्याला सर्वकाही कनेक्ट करण्याची आवश्यकता आहे.

अनेक बंधनकारक मॉडेल आहेत.

सर्वात लोकप्रिय आहेत:

• अंतिम परस्परसंवाद, जिथे परस्परसंवाद एकतर क्लिक किंवा छाप असतो.
• प्रथम परस्परसंवाद, म्हणजे पहिली गोष्ट जी एखाद्या व्यक्तीस साइटवर आणते.
• रेखीय संयोजन - सर्व समान.
• क्षीणता.
• वगैरे.

आणि हे सर्व प्रथम स्थानावर कसे कार्य केले? रनटाइम आणि कॅसँड्रा होती. कॅसॅन्ड्राचा वापर व्यवहार संचयन म्हणून केला जात होता, म्हणजे सर्व संबंधित व्यवहार त्यात साठवले गेले होते. आणि जेव्हा रनटाइममध्ये काही कार्यक्रम येतो, उदाहरणार्थ, काही पृष्ठ किंवा दुसरे काहीतरी दर्शवितो, तेव्हा कॅसॅंड्राला विनंती केली गेली - अशी व्यक्ती आहे की नाही. मग त्याच्याशी संबंधित असलेले व्यवहार मिळाले. आणि जोडणी झाली.

आणि विनंतीला ट्रान्झॅक्शन आयडी असणे भाग्यवान असेल तर ते सोपे आहे. पण सहसा नशीब नसते. त्यामुळे शेवटचा व्यवहार किंवा शेवटच्या क्लिकने झालेला व्यवहार इत्यादी शोधणे आवश्यक होते.

आणि जोपर्यंत बंधन शेवटच्या क्लिकपर्यंत होते तोपर्यंत हे सर्व खूप चांगले कार्य करते. कारण, जर आपण एका महिन्यासाठी विंडो सेट केली तर दररोज 10 दशलक्ष क्लिक्स, दरमहा 300 दशलक्ष क्लिक होतात. आणि कॅसॅन्ड्रामध्ये जलद धावण्यासाठी ते सर्व मेमरीमध्ये असणे आवश्यक आहे, कारण रनटाइमला त्वरित प्रतिसाद देणे आवश्यक आहे, यासाठी सुमारे 10-15 सर्व्हर लागले.

आणि जेव्हा त्यांना व्यवहाराचा डिस्प्लेशी दुवा साधायचा होता, तेव्हा ते लगेचच इतके मजेदार नव्हते. आणि का? हे पाहिले जाऊ शकते की 30 पट अधिक घटना संग्रहित करणे आवश्यक आहे. आणि, त्यानुसार, आपल्याला 30 पट अधिक सर्व्हरची आवश्यकता आहे. आणि असे दिसून आले की ही एक प्रकारची खगोलीय आकृती आहे. रनटाइममध्ये लक्षणीयरीत्या कमी सर्व्हर असूनही, लिंकिंग करण्यासाठी 500 पर्यंत सर्व्हर ठेवणे, ही एक प्रकारची चुकीची आकृती आहे. आणि काय करावे ते विचार करू लागले.

आणि आम्ही क्लिकहाऊसला गेलो. आणि क्लिकहाऊसवर ते कसे करायचे? पहिल्या दृष्टीक्षेपात, असे दिसते की हा विरोधी नमुन्यांचा संच आहे.

• व्यवहार वाढत जातो, आम्ही त्यात अधिकाधिक इव्हेंट्स जोडतो, म्हणजे ते बदलण्यायोग्य आहे आणि क्लिकहाऊस परिवर्तनीय वस्तूंसह फार चांगले कार्य करत नाही.
• जेव्हा एखादा अभ्यागत आमच्याकडे येतो, तेव्हा आम्हाला त्याचे व्यवहार त्याच्या व्हिजिट आयडीद्वारे कळवावे लागतात. ही देखील एक पॉइंट क्वेरी आहे, ते क्लिकहाऊसमध्ये असे करत नाहीत. सहसा क्लिकहाऊसमध्ये मोठे …स्कॅन असतात, परंतु येथे आम्हाला काही रेकॉर्ड मिळणे आवश्यक आहे. तसेच अँटीपॅटर्न.
• याव्यतिरिक्त, व्यवहार json मध्ये होता, परंतु त्यांना ते पुन्हा लिहायचे नव्हते, म्हणून त्यांना json एक असंरचित मार्गाने संग्रहित करायचे होते आणि आवश्यक असल्यास, त्यातून काहीतरी बाहेर काढायचे होते. आणि हे देखील एक अँटीपॅटर्न आहे.

म्हणजेच अँटीपॅटर्नचा संच.

परंतु असे असले तरी ती एक प्रणाली बनवण्यास निघाली ज्याने खूप चांगले कार्य केले.

काय केले होते? क्लिकहाऊस दिसू लागले, ज्यामध्ये नोंदी फेकल्या गेल्या, रेकॉर्डमध्ये विभागल्या गेल्या. ClickHouse कडून लॉग प्राप्त केलेली एक विशेषता सेवा दिसली. त्यानंतर, प्रत्येक एंट्रीसाठी, व्हिजिट आयडीद्वारे, मला असे व्यवहार मिळाले ज्यावर कदाचित अद्याप प्रक्रिया झाली नसेल आणि अधिक स्नॅपशॉट्स, म्हणजे आधीपासून जोडलेले व्यवहार, म्हणजे मागील कामाचा परिणाम. मी त्यांच्यामधून आधीच तर्क तयार केला आहे, योग्य व्यवहार निवडला आहे, नवीन कार्यक्रम जोडले आहेत. पुन्हा लॉग इन केले. लॉग क्लिकहाऊसवर परत गेला, म्हणजे ही एक सतत चक्रीय प्रणाली आहे. आणि त्याशिवाय, मी डीडब्ल्यूएचमध्ये त्याचे विश्लेषण करण्यासाठी गेलो होतो.

हे या स्वरूपात होते की ते फार चांगले कार्य करत नव्हते. आणि क्लिकहाऊससाठी हे सोपे करण्यासाठी, जेव्हा व्हिजिट आयडीद्वारे विनंती आली तेव्हा त्यांनी या विनंत्या 1-000 व्हिजिट आयडीच्या ब्लॉकमध्ये गटबद्ध केल्या आणि 2-000 लोकांसाठी सर्व व्यवहार बाहेर काढले. आणि मग हे सर्व कार्य केले.

तुम्ही क्लिकहाऊसमध्ये पाहिल्यास, फक्त 3 मुख्य टेबल्स आहेत जे हे सर्व देतात.

प्रथम सारणी ज्यामध्ये लॉग अपलोड केले जातात आणि लॉग जवळजवळ प्रक्रिया न करता अपलोड केले जातात.

दुसरा टेबल. भौतिक दृश्याद्वारे, या नोंदींमधून, ज्या घटनांना अद्याप श्रेय दिले गेले नाही, म्हणजेच असंबंधित घटना, चावल्या गेल्या. आणि भौतिक दृश्याद्वारे, स्नॅपशॉट तयार करण्यासाठी या लॉगमधून व्यवहार बाहेर काढले गेले. म्हणजेच, एका विशेष भौतिक दृश्याने स्नॅपशॉट तयार केला, म्हणजे व्यवहाराची शेवटची संचित स्थिती.

येथे SQL मध्ये लिहिलेला मजकूर आहे. त्यातील काही महत्त्वाच्या गोष्टींवर मी भाष्य करू इच्छितो.

पहिली महत्त्वाची गोष्ट म्हणजे क्लिकहाऊसमधील json मधून स्तंभ आणि फील्ड काढण्याची क्षमता. म्हणजेच क्लिकहाऊसमध्ये json सोबत काम करण्याच्या काही पद्धती आहेत. ते खूप, अतिशय आदिम आहेत.

visitParamExtractInt तुम्हाला json मधून विशेषता काढण्याची परवानगी देते, म्हणजे प्रथम हिट कार्य करते. आणि अशा प्रकारे तुम्ही ट्रान्झॅक्शन आयडी किंवा भेट आयडी काढू शकता. यावेळी डॉ.

दुसरे म्हणजे, येथे एक अवघड भौतिक क्षेत्र वापरले आहे. याचा अर्थ काय? याचा अर्थ असा की तुम्ही ते टेबलमध्ये घालू शकत नाही, म्हणजे ते घातलेले नाही, ते समाविष्ट केल्यावर मोजले जाते आणि संग्रहित केले जाते. पेस्ट करताना, क्लिकहाऊस तुमच्यासाठी काम करते. आणि तुम्हाला नंतर जे आवश्यक आहे ते आधीच json मधून बाहेर काढले आहे.

या प्रकरणात, भौतिकीकृत दृश्य कच्च्या पंक्तींसाठी आहे. आणि व्यावहारिकदृष्ट्या कच्च्या नोंदी असलेली पहिली सारणी नुकतीच वापरली जाते. आणि तो काय करतो? प्रथम, ते क्रमवारी बदलते, म्हणजे आता क्रमवारी लावणे व्हिजिट आयडीद्वारे जाते, कारण आम्हाला एखाद्या विशिष्ट व्यक्तीसाठी त्याचे व्यवहार त्वरित बाहेर काढणे आवश्यक आहे.

दुसरी महत्त्वाची गोष्ट म्हणजे index_granularity. जर तुम्ही MergeTree पाहिले असेल, तर ते सहसा 8 बाय डीफॉल्ट index_granularity असते. हे काय आहे? हे इंडेक्स स्पार्सनेस पॅरामीटर आहे. क्लिकहाऊसमध्ये अनुक्रमणिका विरळ आहे, ती प्रत्येक एंट्री कधीही अनुक्रमित करत नाही. हे प्रत्येक 192 8 ला असे करते. आणि जेव्हा भरपूर डेटाची गणना करणे आवश्यक असते तेव्हा हे चांगले असते, परंतु थोडेसे असल्यास ते वाईट असते, कारण मोठ्या ओव्हरहेड असतात. आणि जर आपण इंडेक्स ग्रॅन्युलॅरिटी कमी केली तर आपण ओव्हरहेड कमी करतो. ते एकापर्यंत कमी केले जाऊ शकत नाही, कारण पुरेशी मेमरी असू शकत नाही. निर्देशांक नेहमी मेमरीमध्ये संग्रहित केला जातो.

स्नॅपशॉट काही इतर मनोरंजक क्लिकहाऊस वैशिष्ट्ये देखील वापरतो.

प्रथम, ते AggregatingMergeTree आहे. आणि AggregatingMergeTree argMax स्टोअर करते, म्हणजेच ही शेवटच्या टाइमस्टॅम्पशी संबंधित व्यवहाराची स्थिती आहे. दिलेल्या अभ्यागतासाठी सर्व वेळ व्यवहार व्युत्पन्न केले जातात. आणि या व्यवहाराच्या अगदी शेवटच्या स्थितीत, आम्ही एक कार्यक्रम जोडला आणि आमच्याकडे एक नवीन राज्य आहे. तो पुन्हा क्लिकहाऊसला धडकला. आणि या मटेरियलाइज्ड व्ह्यूमध्ये आर्गमॅक्स द्वारे, आपण नेहमी वर्तमान स्थिती मिळवू शकतो.

• रनटाइम पासून बंधन "डीकपल्ड" आहे.
• दरमहा 3 अब्ज पर्यंत व्यवहार संग्रहित आणि प्रक्रिया केली जातात. हा क्रम कॅसॅंड्रामध्ये होता त्यापेक्षा जास्त प्रमाणात आहे, म्हणजे सामान्य व्यवहार प्रणालीमध्ये.
• 2x5 क्लिकहाऊस सर्व्हरचा क्लस्टर. 5 सर्व्हर आणि प्रत्येक सर्व्हरची प्रतिकृती आहे. क्लिक बेस्ड अॅट्रिब्युशन करण्यासाठी कॅसॅंड्राच्या तुलनेत हे अगदी कमी आहे आणि इथे आमच्याकडे इंप्रेशन आधारित आहे. म्हणजेच, सर्व्हरची संख्या 30 पट वाढवण्याऐवजी, ते कमी करण्यात यशस्वी झाले.

आणि शेवटचे उदाहरण म्हणजे वित्तीय कंपनी Y, ज्याने स्टॉकच्या किमतीतील बदलांच्या परस्परसंबंधांचे विश्लेषण केले.

आणि कार्य होते:

• अंदाजे 5 शेअर्स आहेत.
• दर 100 मिलीसेकंदांना कोट ओळखले जातात.
• डेटा 10 वर्षांमध्ये जमा केला गेला आहे. वरवर पाहता, काही कंपन्यांसाठी अधिक, काहींसाठी कमी.
• एकूण अंदाजे 100 अब्ज पंक्ती आहेत.

आणि बदलांच्या सहसंबंधाची गणना करणे आवश्यक होते.

येथे दोन स्टॉक आणि त्यांचे कोट आहेत. जर एक वर गेला आणि दुसरा वर गेला, तर हा एक सकारात्मक सहसंबंध आहे, म्हणजे एक वर जातो आणि दुसरा वर जातो. जर एक वर गेला, जसे आलेखाच्या शेवटी, आणि दुसरा खाली गेला, तर हा एक नकारात्मक सहसंबंध आहे, म्हणजे जेव्हा एक वर येतो तेव्हा दुसरा पडतो.

या परस्पर बदलांचे विश्लेषण करून आर्थिक बाजारपेठेतील अंदाज बांधता येतात.

पण काम अवघड आहे. यासाठी काय केले जात आहे? आमच्याकडे 100 अब्ज रेकॉर्ड आहेत: वेळ, स्टॉक आणि किंमत. आम्हाला किंमत अल्गोरिदममधील रनिंग डिफरन्सच्या 100 अब्ज पटीने प्रथम गणना करणे आवश्यक आहे. RunningDifference हे ClickHouse मधील एक फंक्शन आहे जे अनुक्रमे दोन स्ट्रिंगमधील फरकाची गणना करते.

आणि त्यानंतर, आपल्याला सहसंबंधाची गणना करणे आवश्यक आहे आणि प्रत्येक जोडीसाठी परस्परसंबंधाची गणना करणे आवश्यक आहे. 5 शेअर्ससाठी, जोड्या 000 दशलक्ष आहेत. आणि हे खूप आहे, म्हणजे 12,5 पट फक्त अशा परस्परसंबंध कार्याची गणना करणे आवश्यक आहे.

आणि जर कोणी विसरला असेल तर ͞x आणि ͞y हे चेकमेट आहे. नमुना अपेक्षा. म्हणजेच, केवळ मूळ आणि बेरीज मोजणे आवश्यक नाही, तर या बेरजेच्या आत आणखी एक बेरीज देखील आवश्यक आहे. गणनाचा एक समूह 12,5 दशलक्ष वेळा करणे आवश्यक आहे, आणि अगदी तासांनुसार गटबद्ध करणे आवश्यक आहे. आमच्याकडेही बरेच तास आहेत. आणि तुम्हाला ते 60 सेकंदात करावे लागेल. हा विनोद आहे.

कमीतकमी कसा तरी वेळ मिळणे आवश्यक होते, कारण क्लिकहाऊस येण्यापूर्वी हे सर्व खूप हळू चालले होते.

त्यांनी हडूपवर, स्पार्कवर, ग्रीनप्लमवर त्याची गणना करण्याचा प्रयत्न केला. आणि हे सर्व खूप मंद किंवा महाग होते. म्हणजेच, कसे तरी गणना करणे शक्य होते, परंतु नंतर ते महाग होते.

आणि मग क्लिकहाऊस आले आणि गोष्टी खूप चांगल्या झाल्या.

मी तुम्हाला आठवण करून देतो की आम्हाला डेटा लोकॅलिटीमध्ये समस्या आहे, कारण सहसंबंध स्थानिकीकृत केले जाऊ शकत नाहीत. आम्ही काही डेटा एका सर्व्हरवर ठेवू शकत नाही, काही दुसर्‍यावर आणि गणना करू शकत नाही, आमच्याकडे सर्वत्र सर्व डेटा असणे आवश्यक आहे.

त्यांनी काय केले? सुरुवातीला, डेटा स्थानिकीकृत आहे. प्रत्येक सर्व्हर शेअर्सच्या विशिष्ट सेटच्या किंमतीवर डेटा संग्रहित करतो. आणि ते ओव्हरलॅप होत नाहीत. म्हणून, समांतर आणि स्वतंत्रपणे लॉगरिटर्नची गणना करणे शक्य आहे, हे सर्व आतापर्यंत समांतर आणि वितरित केले जाते.

मग आम्ही अभिव्यक्ती न गमावता हा डेटा कमी करण्याचा निर्णय घेतला. अॅरे वापरणे कमी करा, म्हणजे प्रत्येक कालावधीसाठी, स्टॉकची अॅरे आणि किमतींची अॅरे बनवा. म्हणून, ते खूपच कमी डेटा जागा घेते. आणि त्यांच्यासोबत काम करणे थोडे सोपे आहे. ही जवळजवळ समांतर क्रिया आहेत, म्हणजे आम्ही अर्धवट समांतर वाचतो आणि नंतर सर्व्हरवर लिहितो.

त्यानंतर, त्याची प्रतिकृती तयार केली जाऊ शकते. "r" अक्षराचा अर्थ असा आहे की आम्ही या डेटाची प्रतिकृती तयार केली आहे. म्हणजेच, आमच्याकडे तिन्ही सर्व्हरवर समान डेटा आहे - हे अॅरे आहेत.

आणि मग 12,5 दशलक्ष सहसंबंधांच्या या संचाच्या एका विशेष स्क्रिप्टसह ज्याची गणना करणे आवश्यक आहे, आपण पॅकेजेस बनवू शकता. म्हणजेच, 2 जोड्यांसह 500 कार्ये. आणि हे कार्य एका विशिष्ट क्लिकहाऊस सर्व्हरवर मोजले जाणार आहे. त्याच्याकडे सर्व डेटा आहे, कारण डेटा सारखाच आहे आणि तो अनुक्रमे त्यांची गणना करू शकतो.

पुन्हा एकदा, हे असे दिसते. प्रथम, आमच्याकडे या संरचनेतील सर्व डेटा आहे: वेळ, शेअर्स, किंमत. मग आम्ही logReturn ची गणना केली, म्हणजे समान संरचनेचा डेटा, परंतु आमच्याकडे आधीपासूनच logReturn आहे. मग ते पुन्हा केले गेले, म्हणजे आम्हाला स्टॉक आणि किमतींसाठी वेळ आणि ग्रुप अॅरे मिळाला. स्प्लिकेटेड. आणि त्यानंतर, आम्ही कार्यांचा एक समूह तयार केला आणि त्यांना क्लिकहाऊसला दिले जेणेकरून ते त्यांची गणना करेल. आणि ते कार्य करते.

संकल्पनेच्या पुराव्यावर, कार्य एक सबटास्क होते, म्हणजे, कमी डेटा घेण्यात आला होता. आणि फक्त तीन सर्व्हर.

पहिले दोन टप्पे: लॉग_रिटर्नची गणना करणे आणि अॅरेमध्ये गुंडाळण्यासाठी सुमारे एक तास लागला.

आणि सहसंबंधाची गणना सुमारे 50 तास आहे. पण 50 तास पुरेसे नाहीत, कारण ते आठवडे काम करायचे. हे एक मोठे यश होते. आणि जर आपण मोजले तर या क्लस्टरवर प्रति सेकंद 70 वेळा सर्वकाही मोजले गेले.

परंतु सर्वात महत्वाची गोष्ट अशी आहे की ही प्रणाली व्यावहारिकदृष्ट्या अडथळ्यांशिवाय आहे, म्हणजेच ती जवळजवळ रेषीयपणे मोजते. आणि त्यांनी ते तपासले. ते यशस्वीरित्या वाढवले.

• योग्य योजना ही अर्धी लढाई आहे. आणि योग्य योजना म्हणजे सर्व आवश्यक क्लिकहाऊस तंत्रज्ञानाचा वापर.
• Summing/AggregatingMergeTrees ही अशी तंत्रज्ञाने आहेत जी तुम्हाला राज्य स्नॅपशॉटला एक विशेष केस म्हणून एकत्रित करण्यास किंवा विचारात घेण्याची परवानगी देतात. आणि हे बर्‍याच गोष्टी मोठ्या प्रमाणात सुलभ करते.
• मटेरिअलाइज्ड व्ह्यू तुम्हाला एक इंडेक्स मर्यादा बायपास करण्याची परवानगी देतात. कदाचित मी ते अगदी स्पष्टपणे सांगितले नाही, परंतु जेव्हा आम्ही लॉग लोड केले तेव्हा कच्चे लॉग टेबलमध्ये एका अनुक्रमणिकेसह होते आणि विशेषता लॉग टेबलमध्ये होते, म्हणजे समान डेटा, फक्त फिल्टर केलेला, परंतु अनुक्रमणिका पूर्णपणे भिन्न होती. हे समान डेटा असल्याचे दिसते, परंतु भिन्न क्रमवारी. आणि मटेरिअलाइज्ड व्ह्यूज तुम्हाला, तुम्हाला गरज असल्यास, अशा क्लिकहाऊस मर्यादेला बायपास करण्याची परवानगी देते.
• पॉइंट क्वेरीसाठी इंडेक्स ग्रॅन्युलॅरिटी कमी करा.
• आणि डेटा हुशारीने वितरित करा, शक्य तितक्या सर्व्हरमध्ये डेटा स्थानिकीकरण करण्याचा प्रयत्न करा. आणि हे सुनिश्चित करण्याचा प्रयत्न करा की विनंत्या देखील शक्य तितक्या शक्य तितक्या स्थानिकीकरण वापरतात.

आणि या छोट्या भाषणाचा सारांश देताना, आम्ही असे म्हणू शकतो की क्लिकहाऊसने आता व्यावसायिक डेटाबेस आणि ओपन सोर्स डेटाबेस या दोन्ही क्षेत्रांवर कब्जा केला आहे, म्हणजे विशेषतः विश्लेषणासाठी. तो या लँडस्केपमध्ये उत्तम प्रकारे बसतो. आणि इतकेच काय, ते हळूहळू इतरांची गर्दी करू लागते, कारण जेव्हा तुमच्याकडे क्लिकहाऊस असते तेव्हा तुम्हाला InfiniDB ची गरज नसते. जर त्यांनी सामान्य SQL समर्थन केले तर Vertika ची लवकरच गरज भासणार नाही. आनंद घ्या!

-अहवालाबद्दल धन्यवाद! अतिशय मनोरंजक! Apache Phoenix शी काही तुलना होती का?

नाही, मी कोणाची तुलना ऐकली नाही. आम्ही आणि Yandex वेगवेगळ्या डेटाबेससह क्लिकहाऊसच्या सर्व तुलनांचा मागोवा ठेवण्याचा प्रयत्न करतो. कारण जर अचानक क्लिकहाऊसपेक्षा काहीतरी वेगवान असल्याचे दिसून आले तर लेशा मिलोविडोव्ह रात्री झोपू शकत नाही आणि त्वरीत वेग वाढवू लागतो. मी अशी तुलना ऐकली नाही.

• (अलेक्सी मिलोविडोव्ह) Apache Phoenix हे Hbase द्वारे समर्थित SQL इंजिन आहे. Hbase मुख्यत: मुख्य-मूल्य कामाच्या परिस्थितीसाठी आहे. तेथे, प्रत्येक ओळीत, अनियंत्रित नावांसह स्तंभांची अनियंत्रित संख्या असू शकते. हे Hbase, Cassandra सारख्या प्रणालींबद्दल सांगितले जाऊ शकते. आणि हे तंतोतंत भारी विश्लेषणात्मक प्रश्न आहेत जे त्यांच्यासाठी सामान्यपणे कार्य करणार नाहीत. किंवा तुम्‍हाला ClickHouse चा अनुभव नसेल तर ते चांगले काम करतील असे तुम्हाला वाटेल.

• Спасибо

  • शुभ दुपार मला या विषयात आधीच रस आहे, कारण माझ्याकडे विश्लेषणात्मक उपप्रणाली आहे. परंतु जेव्हा मी क्लिकहाऊस पाहतो तेव्हा मला असे वाटते की क्लिकहाऊस इव्हेंट विश्लेषणासाठी अतिशय योग्य आहे, बदल करण्यायोग्य आहे. आणि जर मला मोठ्या सारण्यांच्या समूहासह बर्‍याच व्यवसाय डेटाचे विश्लेषण करण्याची आवश्यकता असेल, तर क्लिकहाऊस, माझ्या समजल्यानुसार, माझ्यासाठी फारसे योग्य नाही? विशेषतः जर ते बदलले तर. हे बरोबर आहे की याचे खंडन करणारी काही उदाहरणे आहेत?

  • हे बरोबर आहे. आणि हे बहुतेक विशेष विश्लेषणात्मक डेटाबेसच्या बाबतीत खरे आहे. ते एक किंवा अधिक मोठ्या टेबल्स आहेत जे बदलण्यायोग्य आहेत आणि बर्याच लहान टेबल्ससाठी जे हळूहळू बदलतात या वस्तुस्थितीसाठी तयार केले आहेत. म्हणजेच, क्लिकहाऊस हे ओरॅकलसारखे नाही, जिथे तुम्ही सर्व काही टाकू शकता आणि काही अतिशय जटिल प्रश्न तयार करू शकता. क्लिकहाऊस प्रभावीपणे वापरण्यासाठी, तुम्हाला क्लिकहाऊसमध्ये उत्तम प्रकारे कार्य करेल अशा पद्धतीने योजना तयार करणे आवश्यक आहे. म्हणजेच, जास्त सामान्यीकरण टाळा, शब्दकोश वापरा, कमी लांब दुवे बनवण्याचा प्रयत्न करा. आणि जर योजना अशा प्रकारे तयार केली गेली असेल, तर समान व्यवसाय कार्ये पारंपारिक रिलेशनल डेटाबेसपेक्षा क्लिकहाऊसवर अधिक कार्यक्षमतेने सोडविली जाऊ शकतात.

अहवालाबद्दल धन्यवाद! मला नवीनतम आर्थिक प्रकरणाबद्दल एक प्रश्न आहे. त्यांच्याकडे विश्लेषण होते. ते वर आणि खाली कसे जातात याची तुलना करणे आवश्यक होते. आणि मला समजले आहे की तुम्ही विशेषतः या विश्लेषणासाठी सिस्टम तयार केली आहे? उद्या, उदाहरणार्थ, त्यांना या डेटावर आणखी काही अहवाल हवा असल्यास, त्यांना योजना पुन्हा तयार करून डेटा अपलोड करण्याची आवश्यकता आहे का? म्हणजेच विनंती मिळवण्यासाठी काही प्रकारचे प्रीप्रोसेसिंग करायचे?

अर्थात, एका विशिष्ट कार्यासाठी हा क्लिकहाऊसचा वापर आहे. हे अधिक पारंपारिकपणे हडूपमध्ये सोडवले जाऊ शकते. हडूपसाठी, हे एक आदर्श कार्य आहे. पण हडूपवर ते खूप मंद आहे. आणि माझे उद्दिष्ट हे दाखवून देणे आहे की क्लिकहाऊस अशी कार्ये सोडवू शकते जी सहसा पूर्णपणे भिन्न मार्गांनी सोडवली जातात, परंतु त्याच वेळी ते अधिक कार्यक्षमतेने करतात. हे एका विशिष्ट कार्यासाठी तयार केले आहे. हे स्पष्ट आहे की जर समान काहीतरी समस्या असेल तर ते त्याच प्रकारे सोडवले जाऊ शकते.

हे स्पष्ट आहे. तुम्ही म्हणालात की 50 तासांची प्रक्रिया झाली. हे अगदी सुरुवातीपासूनच आहे, तुम्ही डेटा कधी लोड केला किंवा परिणाम प्राप्त केले?

होय होय.

ठीक आहे, खूप खूप धन्यवाद.

हे 3 सर्व्हर क्लस्टरवर आहे.

शुभेच्छा! अहवालाबद्दल धन्यवाद! सर्व काही खूप मनोरंजक आहे. मी कार्यक्षमतेबद्दल थोडेसे विचारणार नाही, परंतु स्थिरतेच्या दृष्टीने क्लिकहाऊसच्या वापराबद्दल. म्हणजेच, तुमच्याकडे काही होते का, तुम्हाला पुनर्संचयित करावे लागले? या प्रकरणात क्लिकहाऊस कसे वागते? आणि असे घडले की तुमच्याकडे प्रतिकृती देखील होती? उदाहरणार्थ, आम्हाला क्लिकहाऊसमध्ये समस्या आली जेव्हा ते अजूनही त्याच्या मर्यादेच्या बाहेर जाते आणि घसरते.

अर्थात, कोणत्याही आदर्श प्रणाली नाहीत. आणि क्लिकहाऊसच्या स्वतःच्या समस्या आहेत. परंतु आपण Yandex.Metrica बद्दल ऐकले आहे का बर्याच काळापासून काम करत नाही? कदाचित नाही. हे क्लिकहाऊसवर 2012-2013 पासून विश्वसनीयपणे काम करत आहे. मी माझ्या अनुभवाबद्दलही असेच म्हणू शकतो. आम्हाला कधीही पूर्ण अपयश आले नाही. काही अर्धवट गोष्टी घडू शकतात, परंतु व्यवसायावर गंभीरपणे परिणाम करण्यासाठी त्या कधीच गंभीर नव्हत्या. असे कधी झाले नाही. क्लिकहाऊस बरेच विश्वासार्ह आहे आणि यादृच्छिकपणे क्रॅश होत नाही. तुम्हाला त्याची काळजी करण्याची गरज नाही. ती काही कच्ची गोष्ट नाही. हे अनेक कंपन्यांनी सिद्ध केले आहे.

नमस्कार! तुम्ही म्हणालात की तुम्हाला डेटा स्कीमावर लगेच विचार करण्याची गरज आहे. असे झाले तर? माझा डेटा ओतत आहे आणि ओतत आहे. सहा महिने निघून गेले, आणि मला समजले की असे जगणे अशक्य आहे, मला डेटा पुन्हा अपलोड करणे आणि त्यांच्यासह काहीतरी करणे आवश्यक आहे.

हे अर्थातच तुमच्या सिस्टमवर अवलंबून आहे. अक्षरशः कोणत्याही थांबाशिवाय हे करण्याचे अनेक मार्ग आहेत. उदाहरणार्थ, तुम्ही एक मटेरिअलाइज्ड व्ह्यू तयार करू शकता ज्यामध्ये वेगळे डेटा स्ट्रक्चर बनवायचे असेल तर ते अद्वितीयपणे मॅप केले जाऊ शकते. म्हणजेच, जर ते क्लिकहाऊस वापरून मॅपिंग करण्यास परवानगी देते, म्हणजे काही गोष्टी काढणे, प्राथमिक की बदलणे, विभाजन बदलणे, तर तुम्ही मटेरियलाइज्ड व्ह्यू बनवू शकता. तुमचा जुना डेटा तिथे ओव्हरराइट करा, नवीन आपोआप लिहिला जाईल. आणि मग फक्त मटेरियलाइज्ड व्ह्यू वापरण्यासाठी स्विच करा, नंतर रेकॉर्ड स्विच करा आणि जुने टेबल मारून टाका. ही साधारणपणे नॉन-स्टॉप पद्धत आहे.

Спасибо.

स्त्रोत: www.habr.com