प्रगत वापरकर्त्यांसाठी प्रश्न आणि उत्तरांमध्ये क्लिक हाऊस

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

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

सावधगिरी बाळगा, कट अंतर्गत भरपूर मजकूर आहे. आम्हाला आशा आहे की प्रश्नांसह सामग्री तुम्हाला नेव्हिगेट करण्यात मदत करेल.

सामग्री

• क्लिकहाऊस सतत अद्यतनित केले जाते, परंतु आमचा डेटा नाही. त्याचे काय करायचे?
• ClickHouse मधील डेटाचा बॅकअप घेण्यासाठी सध्याच्या सर्वोत्तम पद्धती कोणत्या आहेत?
• शाफ्टमध्ये प्रतिकृतींचे नियंत्रित अंतर आयोजित करणे शक्य होईल का?
• जर टेबलची रचना बदलली असेल तर?
• डेटा रीशार्डिंगमध्ये सध्याच्या सर्वोत्तम पद्धती कोणत्या आहेत?
• ClickHouse मध्ये clickhouse-copier उपयुक्तता आहे. तुम्ही आम्हाला तिच्याबद्दल सांगू शकाल का?
• तुमच्याकडे रीशार्डिंग नावाची पायलट गोष्ट होती. तिच्याबरोबर काय?
• स्लो डिस्कवर हलवण्यापूर्वी डेटाचे सर्व भाग एकत्र विलीन करणे शक्य आहे का?
• आगाऊ सुसंगतता तपासण्याचा कोणताही मार्ग नसल्यास क्लिकहाऊसच्या नवीन आवृत्त्यांमध्ये स्थलांतर कसे करावे?
• किल क्वेरीने क्वेरी नष्ट करणे अपेक्षित आहे, परंतु तसे होत नाही. का?
• वाचन लोड अंतर्गत प्रतिसाद वेळ कसा मोजायचा?
• क्लिकहाऊसमध्ये मी काय बदल करू शकतो जेणेकरून अधिक डेटा कॅशेमध्ये असेल?
• मी RAM मध्ये स्टोरेजसाठी स्टोरेज_कॉन्फिगरेशन कसे कॉन्फिगर करू शकतो?
• लो कार्डिनॅलिटी किती अद्वितीय मूल्यांपर्यंत प्रभावी आहे?
• पाच अब्ज पंक्ती असलेले सारणी पूर्ण-मजकूर शोधण्याच्या सर्वोत्तम पद्धती कोणत्या आहेत?
• मोठ्या संख्येने वापरकर्त्यांसाठी क्लिकहाऊसमध्ये प्रवेश व्यवस्थापित करण्याचा सर्वोत्तम मार्ग कोणता आहे?
• दहा क्लायंटना एका क्वेरीचे निकाल देणे शक्य आहे का?
• असिंक्रोनस ऑपरेशन्स आणि मटेरियलाइज्ड व्ह्यूजबद्दल काय?
• क्लिकहाऊसमध्ये बरेच लॉग आहेत. कोणत्याही क्षणी सर्व्हरवर जे काही घडत आहे ते मी कसे पाहू शकतो?
• सर्व्हर OOM मध्ये क्रॅश होऊ नये म्हणून विलीनीकरणावर कसा प्रभाव टाकायचा?
• क्लिकहाऊससाठी गोलंग ड्रायव्हरचा विकास कसा होईल?
• आळशी_लोड सेटिंग सक्षम करून रीबूट केल्यानंतर बाह्य शब्दकोश लोड होत नाही. काय करायचं?
• सिस्टीम रीलोड डिक्शनरी अनेक शब्दकोशांपैकी एकही डिक्शनरी लोड करत नाही या वस्तुस्थितीचे काय करावे जर त्यापैकी किमान एक त्रुटीसह अयशस्वी झाला?
• क्लिकहाऊस कॉन्फिगरमध्ये तपशील कॉन्फिगर करण्याचा मार्ग आहे, परंतु त्रुटी असल्यास ते प्रदर्शित करू नका?
• बोनस: संमेलनांमधून झूम पार्श्वभूमी

तुम्हाला मजकूर वाचायचा नसेल, तर तुम्ही संमेलनांचे रेकॉर्डिंग पाहू शकता आमच्या YouTube चॅनेलवर. टाइमकोड व्हिडिओखाली पहिल्या कमेंटमध्ये आहेत.

क्लिकहाऊस सतत अद्यतनित केले जाते, परंतु आमचा डेटा नाही. त्याचे काय करायचे?

ClickHouse सतत अपडेट केले जाते, आणि आमचा डेटा, जो अंतिम प्रक्रियेसाठी ऑप्टिमाइझ केला गेला होता, तो अपडेट केला जात नाही आणि तो बॅकअप कॉपीमध्ये आहे.

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

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

ClickHouse मधील डेटाचा बॅकअप घेण्यासाठी सध्याच्या सर्वोत्तम पद्धती कोणत्या आहेत?

आमच्याकडे अंतिम ऑपरेशन्स ऑप्टिमाइझ करणे, टेराबाइट्सचा एक मोठा डेटाबेस आणि गेल्या तीन दिवसांपासून अद्ययावत केलेला डेटा आहे हे लक्षात घेऊन बॅकअप कसा बनवायचा, आणि नंतर त्यांच्यासाठी कोणतीही प्रक्रिया होणार नाही?

आम्ही आमचे स्वतःचे निराकरण करू शकतो आणि बॅशवर लिहू शकतो: या बॅकअप प्रती अशा आणि अशा प्रकारे गोळा करू. कदाचित काहीही कुबडण्याची गरज नाही, आणि सायकलचा शोध फार पूर्वी लागला होता?

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

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

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

जर डेटासह सारणी फक्त काही गीगाबाइट्स घेते, तर बॅकअप खालीलप्रमाणे केले जाऊ शकते:

1. टेबल व्याख्या जतन करा म्हणजे मेटाडेटा − तयार टेबल दाखवा.
2. क्लिकहाऊस क्लायंट वापरून डंप बनवा - निवडा * टेबल पासून फाईलला. डीफॉल्टनुसार, तुम्हाला टॅबसेपरेटेड फॉरमॅटमध्ये फाइल प्राप्त होईल. तुम्हाला ते अधिक कार्यक्षमतेने हवे असल्यास, तुम्ही ते मूळ स्वरूपात करू शकता.

जर डेटाचे प्रमाण मोठे असेल तर बॅकअपला जास्त वेळ आणि भरपूर जागा लागेल. याला लॉजिकल बॅकअप म्हणतात; ते क्लिकहाऊस डेटा फॉरमॅटशी जोडलेले नाही. तसे असल्यास, शेवटचा उपाय म्हणून तुम्ही बॅकअप घेऊ शकता आणि पुनर्संचयित करण्यासाठी MySQL वर अपलोड करू शकता.

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

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

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

काहीवेळा तुम्हाला आणखी थंड हवे असते - तुमच्याकडे प्रत्येक सर्व्हरवर दहापट किंवा शेकडो टेराबाइट्स आणि शेकडो सर्व्हर असतात. येथे एक उपाय आहे जो मी माझ्या सहकाऱ्यांकडून Yandex.Metrica मधून उचलला आहे. मी प्रत्येकाला याची शिफारस करणार नाही - ते वाचा आणि ते योग्य आहे की नाही हे स्वतःच ठरवा.

प्रथम आपल्याला मोठ्या डिस्क शेल्फसह अनेक सर्व्हर तयार करण्याची आवश्यकता आहे. पुढे, या सर्व्हरवर अनेक क्लिकहाऊस सर्व्हर स्थापित करा आणि त्यांना कॉन्फिगर करा जेणेकरून ते समान शार्ड्ससाठी दुसरी प्रतिकृती म्हणून कार्य करतील. आणि नंतर या सर्व्हरवर फाइल सिस्टम किंवा काही साधन वापरा जे तुम्हाला स्नॅपशॉट तयार करण्यास अनुमती देते. येथे दोन पर्याय आहेत. पहिला पर्याय LVM स्नॅपशॉट्स आहे, दुसरा पर्याय Linux वर ZFS आहे.

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

शाफ्टमध्ये प्रतिकृतींचे नियंत्रित अंतर आयोजित करणे शक्य होईल का?

या वर्षी तुम्ही क्लिकहाऊस येथे शाफ्ट बनवण्याचा विचार करत आहात. त्यांच्यामध्ये प्रतिकृतींचा नियंत्रित अंतर आयोजित करणे शक्य होईल का? आम्ही बदल आणि इतर बदलांसह नकारात्मक परिस्थितींपासून स्वतःचे संरक्षण करण्यासाठी याचा वापर करू इच्छितो.

बदलांसाठी काही प्रकारचे रोल बॅक करणे शक्य आहे का? उदाहरणार्थ, विद्यमान शाफ्टमध्ये, ते घ्या आणि म्हणा की या क्षणापर्यंत बदल लागू करा आणि या क्षणापासून बदल लागू करणे थांबवायचे?

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

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

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

प्रथम, नॉन-ब्लॉकिंग ऑपरेशन सुनिश्चित करण्यासाठी, त्यांचा वापर करणार्‍या निवडक क्वेरी आहेत तोपर्यंत ते संग्रहित केले जातील. जुन्या भागांमधून निवडक क्वेरी सहजपणे वाचल्या जातात.

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

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

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

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

जर टेबलची रचना बदलली असेल तर?

जुन्या योजनेसह तयार केलेला बॅकअप कसा पुनर्संचयित करायचा? आणि दुसरा प्रश्न स्नॅपशॉट्स आणि फाइल सिस्टम टूल्सच्या बाबतीत आहे. Linux LVM वर ZFS ऐवजी Btrfs इथे चांगले आहे का?

आपण केले तर विभाजन संलग्न करा वेगळ्या संरचनेसह विभाजने, नंतर क्लिकहाऊस तुम्हाला सांगेल की हे शक्य नाही. हा उपाय आहे. पहिले म्हणजे जुन्या स्ट्रक्चरसह MergeTree प्रकाराचे तात्पुरते टेबल तयार करणे, तिथे अटॅच वापरून डेटा संलग्न करणे आणि बदल क्वेरी करणे. त्यानंतर तुम्ही हा डेटा कॉपी किंवा ट्रान्सफर करू शकता आणि पुन्हा संलग्न करू शकता किंवा विनंती वापरू शकता टेबल हलवा विभाजन बदला.

आता दुसरा प्रश्न Btrfs वापरता येईल का. सुरुवातीला, तुमच्याकडे LVM असल्यास, LVM स्नॅपशॉट्स पुरेसे आहेत, आणि फाइल सिस्टम ext4 असू शकते, काही फरक पडत नाही. Btrts सह, सर्वकाही ते वापरण्याच्या तुमच्या अनुभवावर अवलंबून आहे. ही एक परिपक्व फाइल प्रणाली आहे, परंतु एखाद्या विशिष्ट परिस्थितीत व्यवहारात गोष्टी कशा चालतील याबद्दल अजूनही काही शंका आहेत. तुमच्या उत्पादनात Btrfs असल्याशिवाय मी हे वापरण्याची शिफारस करणार नाही.

डेटा रीशार्डिंगमध्ये सध्याच्या सर्वोत्तम पद्धती कोणत्या आहेत?

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

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

हे करता येण्याचा पहिला मार्ग म्हणजे विनंती वापरून विभाजनांचा भाग नवीन सर्व्हरवर कॉपी करणे alter table fetch partition. उदाहरणार्थ, तुमच्याकडे महिन्यानुसार विभाजने होती आणि तुम्ही 2017 चा पहिला महिना घ्या आणि नवीन सर्व्हरवर कॉपी करा, त्यानंतर तिसऱ्या महिन्याची कॉपी इतर नवीन सर्व्हरवर करा. आणि ते कमी-जास्त होईपर्यंत तुम्ही हे करा.

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

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

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

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

तर ही पद्धत क्रमांक एक आहे. आणि मी तुमच्या उत्तराची वाट पाहत आहे, पद्धत योग्य आहे की नाही, किंवा पुढे जाऊया.

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

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

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

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

तुमच्या प्रश्नाचे उत्तर देण्यासाठी माझ्याकडे आणखी काही मुद्दे आहेत. त्यापैकी एक म्हणजे सुरुवातीला शार्डिंग योजना कशी बनवायची, जेणेकरून री-शार्डिंगमुळे कमी त्रास होईल. हे नेहमीच शक्य नसते.

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

हे शक्य आहे की यापैकी सर्वात मोठी वाढ तिसऱ्या कारणाशी संबंधित आहे - मॉनिटरिंगच्या वापरामध्ये वाढ. आणि या प्रकरणात, लोडचे स्वरूप पाहण्यासारखे आहे, निवडण्यासाठी मुख्य विनंत्या काय आहेत. मूलभूत निवडक क्वेरी बहुधा मेट्रिक्सच्या काही उपसंचावर आधारित असतील.

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

व्लादिमीर कोलोबाएव: वस्तुस्थिती अशी आहे की आम्ही बर्‍याचदा ऐतिहासिक डेटाला आवाहन करतो, कारण आम्ही वर्तमान परिस्थितीची वास्तविक वेळेत ऐतिहासिक परिस्थितीशी तुलना करतो. आणि आमच्यासाठी मोठ्या प्रमाणात डेटामध्ये द्रुत प्रवेश असणे महत्वाचे आहे आणि क्लिकहाऊस यासह उत्कृष्ट कार्य करते.

तुम्ही अगदी बरोबर आहात, आम्ही कोणत्याही मॉनिटरिंग सिस्टमप्रमाणे शेवटच्या दिवसातील बहुतेक वाचन विनंत्या अनुभवतो. परंतु त्याच वेळी, ऐतिहासिक डेटावरील भार देखील खूप मोठा आहे. हे मूलत: एका अलर्टिंग सिस्टममधून आहे जे प्रत्येक तीस सेकंदांच्या आसपास जाते आणि क्लिकहाऊसला म्हणते: “मला गेल्या सहा आठवड्यांचा डेटा द्या. आता त्यांच्याकडून मला एक प्रकारची हलती सरासरी तयार करा आणि वर्तमान मूल्याची ऐतिहासिक मूल्याशी तुलना करूया. ”

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

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

Yandex.Metrica इव्हेंटसह एक मुख्य क्लस्टर आहे. इव्हेंट म्हणजे पृष्ठ दृश्ये, क्लिक आणि रूपांतरणे. बहुतेक विनंत्या विशिष्ट वेबसाइटवर जातात. आपण Yandex.Metrica सेवा उघडता, आपल्याकडे एक वेबसाइट आहे - avito.ru, अहवालावर जा आणि आपल्या वेबसाइटसाठी विनंती केली जाते.

परंतु इतर विनंत्या आहेत - विश्लेषणात्मक आणि जागतिक - ज्या अंतर्गत विश्लेषकांनी केल्या आहेत. फक्त बाबतीत, मी लक्षात घेईन की अंतर्गत विश्लेषक फक्त Yandex सेवांसाठी विनंत्या करतात. परंतु तरीही, यांडेक्स सेवा देखील सर्व डेटाचा महत्त्वपूर्ण हिस्सा व्यापतात. या विनंत्या विशिष्ट काउंटरसाठी नसून व्यापक फिल्टरिंगसाठी आहेत.

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

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

एक पर्याय आहे जो डायमेट्रिकली उलट आहे. कल्पना करा की आम्ही सर्व साइटवर डेटा शार्ड करतो आणि एका साइटची विनंती एका शार्डवर जाते. आता क्लस्टर प्रति सेकंद दहा हजार विनंत्या हाताळण्यास सक्षम असेल, परंतु एका शार्डवर कोणतीही विनंती खूप हळू काम करेल. हे यापुढे बँडविड्थच्या बाबतीत मोजले जाणार नाही. विशेषतः जर ही साइट avito.ru असेल तर. अविटो ही रुनेटमधील सर्वाधिक भेट दिलेल्या साइट्सपैकी एक आहे असे म्हटल्यास मी रहस्य उघड करणार नाही. आणि त्यावर एका शार्डवर प्रक्रिया करणे म्हणजे वेडेपणा होईल.

म्हणून, शार्डिंग योजना अधिक धूर्त पद्धतीने तयार केली गेली आहे. संपूर्ण क्लस्टर अनेक क्लस्टरमध्ये विभागलेला आहे, ज्याला आपण स्तर म्हणतो. प्रत्येक क्लस्टरमध्ये दहा ते अनेक डझन शार्ड्स असतात. असे एकूण एकोणतीस क्लस्टर्स आहेत.

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

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

पण ही योजना आम्ही सोडली असे मी म्हटले नाही तर माझी कथा अपूर्ण राहील. नवीन स्कीममध्ये, आम्ही सर्वकाही बदलले आणि क्लिकहाउस-कॉपीअर वापरून सर्व डेटा कॉपी केला.

नवीन योजनेत, सर्व साइट्स मोठ्या आणि लहान अशा दोन श्रेणींमध्ये विभागल्या आहेत. थ्रेशोल्ड कसा निवडला गेला हे मला माहित नाही, परंतु परिणाम असा आहे की मोठ्या साइट एका क्लस्टरवर रेकॉर्ड केल्या जातात, जिथे प्रत्येकी तीन प्रतिकृती असलेले 120 शार्ड्स आहेत - म्हणजे 360 सर्व्हर. आणि शार्डिंग योजना अशी आहे की कोणतीही विनंती एकाच वेळी सर्व शार्ड्सकडे जाते. आपण आता Yandex.Metrica मध्ये avito.ru साठी कोणतेही अहवाल पृष्ठ उघडल्यास, विनंती 120 सर्व्हरवर जाईल. RuNet मध्ये काही मोठ्या साइट्स आहेत. आणि विनंत्या प्रति सेकंद एक हजार नसून शंभरपेक्षा कमी आहेत. हे सर्व शांतपणे वितरित टेबलद्वारे चघळले जाते, जे प्रत्येकजण 120 सर्व्हरसह प्रक्रिया करतो.

आणि दुसरा क्लस्टर लहान साइट्ससाठी आहे. येथे साइट आयडीवर आधारित शार्डिंग योजना आहे आणि प्रत्येक विनंती अगदी एका शार्डवर जाते.

ClickHouse मध्ये clickhouse-copier उपयुक्तता आहे. तुम्ही आम्हाला तिच्याबद्दल सांगू शकाल का?

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

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

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

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

तुमच्याकडे रीशार्डिंग नावाची पायलट गोष्ट होती. तिच्याबरोबर काय?

2017 मध्ये, तुमच्याकडे रीशार्डिंग नावाची पायलट गोष्ट होती. ClickHouse मध्ये देखील एक पर्याय आहे. जसे मला समजले, ते बंद झाले नाही. हे का घडले ते तुम्ही मला सांगू शकता का? ते खूप समर्पक असल्याचे दिसते.

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

स्लो डिस्कवर हलवण्यापूर्वी डेटाचे सर्व भाग एकत्र विलीन करणे शक्य आहे का?

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

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

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

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

आगाऊ सुसंगतता तपासण्याचा कोणताही मार्ग नसल्यास क्लिकहाऊसच्या नवीन आवृत्त्यांमध्ये स्थलांतर कसे करावे?

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

येथे अनेक "सुवर्ण" नियम आहेत. पहिला - चेंजलॉग वाचा. हे मोठे आहे, परंतु मागे विसंगत बदलांबद्दल वेगळे परिच्छेद आहेत. या बिंदूंना लाल ध्वज मानू नका. या सहसा किरकोळ विसंगती असतात ज्या काही एज फंक्शनॅलिटीशी संबंधित असतात ज्या तुम्ही बहुधा वापरत नाही.

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

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

20.3.4 आवृत्ती आहे. 20 क्रमांक उत्पादनाचे वर्ष दर्शवितो - 2020. आत काय आहे या दृष्टिकोनातून, हे काही फरक पडत नाही, म्हणून आम्ही याकडे लक्ष देणार नाही. पुढे 20.3 आहे. आम्ही दुसरी संख्या वाढवतो - या प्रकरणात 3 - प्रत्येक वेळी आम्ही काही नवीन कार्यक्षमतेसह प्रकाशन सोडतो. जर आम्हाला क्लिकहाऊसमध्ये कोणतेही वैशिष्ट्य जोडायचे असेल तर आम्हाला ही संख्या वाढवणे आवश्यक आहे. म्हणजेच, आवृत्ती 20.4 मध्ये क्लिकहाऊस आणखी चांगले कार्य करेल. तिसरा अंक 20.3.4 आहे. येथे 4 पॅच रिलीझची संख्या आहे ज्यामध्ये आम्ही नवीन वैशिष्ट्ये जोडली नाहीत, परंतु काही दोष निश्चित केले आहेत. आणि 4 म्हणजे आम्ही ते चार वेळा केले.

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

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

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

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

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

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

अलेक्सी मिलोविडोव्ह: Yandex.Metrica मधील आमच्या मित्रांचे चाचणी वातावरण कसे आहे ते मी तुम्हाला सांगेन. एका क्लस्टरमध्ये 600-विचित्र सर्व्हर होते, दुसर्‍यामध्ये 360 होते आणि तिसरे आणि अनेक क्लस्टर आहेत. त्यापैकी एकासाठी चाचणी वातावरण फक्त दोन प्रतिकृती असलेले दोन शार्ड्स आहे. दोन तुकडे का? जेणेकरून तुम्ही एकटे नसाल. आणि प्रतिकृतीही असाव्यात. फक्त एक विशिष्ट किमान रक्कम जी तुम्हाला परवडेल.

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

मी तुम्हाला एक उदाहरण देतो. आम्ही ClickHouse ची नवीन आवृत्ती स्थापित करण्याचा निर्णय घेतला. हे चाचणी वातावरणावर पोस्ट केले गेले आहे, स्वयंचलित चाचण्या Yandex.Metrica मध्येच पूर्ण झाल्या आहेत, जे संपूर्ण पाइपलाइन चालवत असलेल्या जुन्या आवृत्ती आणि नवीन आवृत्तीवरील डेटाची तुलना करतात. आणि अर्थातच, आमच्या सीआयच्या हिरव्या चाचण्या. अन्यथा आम्ही ही आवृत्ती प्रस्तावित देखील केली नसती.

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

मग नवीन आवृत्ती स्थापित करण्यासाठी सहकार्यांना पटवणे कठीण होते. मी म्हणतो: "ठीक आहे, रोल आउट करा. आपली बोटे ओलांडून ठेवा, सर्वकाही कार्य करेल. आता आलेखांवर भार वाढला आहे, परंतु सर्व काही ठीक आहे. तेथे लटकव." सर्वसाधारणपणे, आम्ही हे केले आणि तेच - आवृत्ती उत्पादन साइटवर पोस्ट केली गेली. परंतु जवळजवळ प्रत्येक लेआउटमध्ये समान समस्या उद्भवतात.

किल क्वेरीने क्वेरी नष्ट करणे अपेक्षित आहे, परंतु तसे होत नाही. का?

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

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

आता एक ऐवजी विचित्र उत्तर असेल. मुद्दा असा आहे की किल क्वेरीने क्वेरी नष्ट होत नाहीत.

किल क्वेरी "मला ही क्वेरी मारून टाकायची आहे" नावाचा एक छोटा बॉक्स चेक करतो. आणि प्रत्येक ब्लॉकवर प्रक्रिया करताना विनंती स्वतः या ध्वजाकडे पाहते. ते सेट केले असल्यास, विनंती कार्य करणे थांबवते. असे दिसून आले की विनंती कोणीही मारत नाही, त्याने स्वतः सर्वकाही तपासले पाहिजे आणि थांबले पाहिजे. आणि हे सर्व प्रकरणांमध्ये कार्य केले पाहिजे जेथे विनंती डेटाच्या ब्लॉक्सवर प्रक्रिया करण्याच्या स्थितीत आहे. ते डेटाच्या पुढील ब्लॉकवर प्रक्रिया करेल, ध्वज तपासेल आणि थांबेल.

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

वाचन लोड अंतर्गत प्रतिसाद वेळ कसा मोजायचा?

एक टेबल आहे ज्यामध्ये आयटमद्वारे एकत्रित संग्रहित केले जातात - विविध काउंटर. पंक्तींची संख्या अंदाजे शंभर दशलक्ष आहे. तुम्ही 1K आयटमवर 1K RPS टाकल्यास अंदाजे प्रतिसाद वेळेवर मोजणे शक्य आहे का?

संदर्भानुसार, आम्ही वाचन लोडबद्दल बोलत आहोत, कारण लिहिण्यात कोणतीही अडचण नाही - अगदी हजार, अगदी शंभर हजार आणि कधीकधी अनेक दशलक्ष पंक्ती घातल्या जाऊ शकतात.

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

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

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

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

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

किरील श्वाकोव्ह: तेथे सामान्य खाती असल्यास मी सल्ला देईन. जेव्हा क्लिकहाऊसमध्ये काही प्रकारचे काउंटर संग्रहित केले जाते तेव्हा ही एक मानक परिस्थिती आहे. माझ्याकडे एक वापरकर्ता आहे, तो अशा आणि अशा देशाचा आहे, कुठल्यातरी तिसऱ्या फील्डचा आहे आणि मला हळूहळू काहीतरी वाढवायचे आहे. MySQL घ्या, एक युनिक की बनवा - MySQL मध्ये ती डुप्लिकेट की आहे आणि PostgreSQL मध्ये ती विरोधाभास आहे - आणि एक प्लस चिन्ह जोडा. हे जास्त चांगले काम करेल.

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

क्लिकहाऊसमध्ये मी काय बदल करू शकतो जेणेकरून अधिक डेटा कॅशेमध्ये असेल?

चला एका परिस्थितीची कल्पना करूया - सर्व्हरमध्ये 256 GB RAM आहे, दैनंदिन दिनचर्यामध्ये क्लिकहाऊस अंदाजे 60-80 GB घेते, शिखरावर - 130 पर्यंत. काय सक्षम केले जाऊ शकते आणि ट्वीक केले जाऊ शकते जेणेकरून अधिक डेटा कॅशेमध्ये असेल आणि त्यानुसार, डिस्कवर कमी ट्रिप आहेत?

सामान्यतः, ऑपरेटिंग सिस्टमचे पृष्ठ कॅशे या कार्यासाठी चांगले कार्य करते. जर तुम्ही फक्त वरचे पान उघडले तर तिथे कॅशे केलेले किंवा फ्री पहा - ते किती कॅशे केलेले आहे हे देखील सांगते - तर तुमच्या लक्षात येईल की सर्व फ्री मेमरी कॅशेसाठी वापरली जाते. आणि हा डेटा, जेव्हा वाचला जातो तेव्हा डिस्कवरून नव्हे तर RAM वरून वाचला जाईल. त्याच वेळी, मी असे म्हणू शकतो की कॅशे प्रभावीपणे वापरला जातो कारण तो कॅशे केलेला संकुचित डेटा आहे.

तथापि, तुम्हाला काही सोप्या क्वेरी आणखी वेगवान करायच्या असल्यास, डिकंप्रेस्ड डेटामध्ये ClickHouse मध्ये कॅशे सक्षम करण्याचा पर्याय आहे. असे म्हणतात असंपीडित कॅशे. config.xml कॉन्फिगरेशन फाइलमध्ये, तुम्हाला आवश्यक असलेल्या मूल्यावर असंपीडित कॅशे आकार सेट करा - मी विनामूल्य RAM च्या अर्ध्यापेक्षा जास्त नसण्याची शिफारस करतो, कारण उर्वरित पृष्ठ कॅशेच्या खाली जाईल.

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

मी RAM मध्ये स्टोरेजसाठी स्टोरेज_कॉन्फिगरेशन कसे कॉन्फिगर करू शकतो?

नवीन क्लिकहाऊस डॉक्युमेंटेशनमध्ये मी संबंधित विभाग वाचला डेटा स्टोरेजसह. वर्णनात वेगवान SSD सह उदाहरण आहे.

मला आश्चर्य वाटते की व्हॉल्यूम हॉट मेमरीसह ते कसे कॉन्फिगर केले जाऊ शकते. आणि आणखी एक प्रश्न. या डेटा संस्थेसह सिलेक्ट कसे कार्य करते, ते संपूर्ण संच वाचेल की फक्त डिस्कवर आहे आणि हा डेटा मेमरीमध्ये संकुचित आहे का? आणि अशा डेटा संस्थेसह प्रीव्हेअर विभाग कसे कार्य करते?

ही सेटिंग डेटा भागांच्या संचयनावर परिणाम करते आणि त्यांचे स्वरूप कोणत्याही प्रकारे बदलत नाही.
चला जवळून बघूया.

तुम्ही RAM मध्ये डेटा स्टोरेज कॉन्फिगर करू शकता. डिस्कसाठी कॉन्फिगर केलेले सर्व त्याचा मार्ग आहे. तुम्ही tmpfs विभाजन तयार करा जे फाइल प्रणालीमधील काही मार्गावर आरोहित आहे. आपण हा मार्ग सर्वात लोकप्रिय विभाजनासाठी डेटा संचयित करण्याचा मार्ग म्हणून निर्दिष्ट केला आहे, डेटाचे तुकडे येणे सुरू होईल आणि तेथे लिहिले जाईल, सर्वकाही ठीक आहे.

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

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

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

लो कार्डिनॅलिटी किती अद्वितीय मूल्यांपर्यंत प्रभावी आहे?

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

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

पाच अब्ज पंक्ती असलेले सारणी पूर्ण-मजकूर शोधण्याच्या सर्वोत्तम पद्धती कोणत्या आहेत?

वेगवेगळी उत्तरे आहेत. पहिले म्हणायचे आहे की क्लिकहाऊस हे पूर्ण-मजकूर शोध इंजिन नाही. यासाठी विशेष प्रणाली आहेत, उदाहरणार्थ, Elasticsearch и स्फिंक्स. तथापि, मी वाढत्या लोकांकडे असे म्हणताना पाहतो की ते Elasticsearch वरून ClickHouse वर स्विच करत आहेत.

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

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

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

या प्रकरणात, मी आणखी एक छोटी युक्ती ऑफर करण्यास तयार आहे. हे प्रायोगिक आहे - ते कार्य करू शकते, कदाचित नाही. क्लिकहाऊसमध्ये ट्रायग्राम ब्लूम फिल्टर्सच्या स्वरूपात पूर्ण-मजकूर निर्देशांक आहेत. Arenadata मधील आमच्या सहकाऱ्यांनी या अनुक्रमणिका आधीच वापरून पाहिल्या आहेत, आणि ते बर्‍याचदा इच्छितेप्रमाणे कार्य करतात.

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

अलीकडे, क्लिकहाऊसने पूर्ण-मजकूर शोधासाठी आणखी प्रगत वैशिष्ट्ये जोडली आहेत. हे, प्रथमतः, UTF-8 साठी किंवा फक्त ASCII साठी समर्थनासह केस-संवेदनशील, केस-संवेदनशील पर्यायांसह एकाच वेळी एकाच वेळी अनेक सबस्ट्रिंग्सचा शोध आहे. आपल्याला आवश्यक असलेले सर्वात प्रभावी निवडा.

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

तिसरे, आता regexps साठी अंदाजे शोध आणि substrings साठी अंदाजे शोध आहे. एखाद्या शब्दाचे स्पेलिंग चुकीचे असल्यास, तो जास्तीत जास्त जुळण्यासाठी शोधला जाईल.

मोठ्या संख्येने वापरकर्त्यांसाठी क्लिकहाऊसमध्ये प्रवेश व्यवस्थापित करण्याचा सर्वोत्तम मार्ग कोणता आहे?

मोठ्या संख्येने ग्राहक आणि विश्लेषकांसाठी प्रवेश कसा व्यवस्थित करायचा ते आम्हाला सांगा. रांग कशी तयार करावी, जास्तीत जास्त समवर्ती प्रश्नांना प्राधान्य कसे द्यावे आणि कोणत्या साधनांसह?

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

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

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

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

याव्यतिरिक्त, क्लिकहाऊसमध्ये दोन प्राधान्य सेटिंग्ज आहेत. दुर्दैवाने, ते खूप आदिम आहेत. एकाला फक्त म्हणतात प्राधान्य. जर प्राधान्यक्रम ≠ 0, आणि काही प्राधान्य असलेल्या विनंत्या अंमलात आणल्या जात असतील, परंतु त्याच वेळी प्राधान्य मूल्यासह विनंती अंमलात आणली जात असेल ज्याचे मूल्य कमी असेल, ज्याचा अर्थ उच्च प्राधान्य असेल, तर अधिक प्राधान्य मूल्य असलेली विनंती, जी म्हणजे कमी प्राधान्य, फक्त निलंबित केले आहे आणि या काळात अजिबात कार्य करणार नाही.

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

पुढील प्राधान्य सेटिंग कॉल केली जाते OS थ्रेडला प्राधान्य. हे लिनक्स शेड्युलरसाठी सर्व विनंती अंमलबजावणी थ्रेड्ससाठी छान मूल्य सेट करते. हे असे कार्य करते, परंतु तरीही ते कार्य करते. जर तुम्ही किमान छान मूल्य सेट केले - ते सर्वात मोठे मूल्य आहे आणि याचा अर्थ सर्वात कमी प्राधान्य - आणि उच्च प्राधान्य असलेल्या विनंत्यांसाठी -19 सेट केल्यास, CPU कमी-प्राधान्य विनंत्या उच्च-प्राधान्य असलेल्या विनंत्यांपेक्षा अंदाजे चार पट कमी वापरेल.

तुम्हाला कमाल विनंती अंमलात आणण्याची वेळ देखील कॉन्फिगर करण्याची आवश्यकता आहे - म्हणा, पाच मिनिटे. किमान क्वेरी गती ही सर्वात छान गोष्ट आहे. ही सेटिंग बर्‍याच काळापासून आहे आणि क्लिकहाऊसची गती कमी होत नाही हे सांगण्यासाठीच नव्हे तर सक्ती करणे आवश्यक आहे.

कल्पना करा, तुम्ही कॉन्फिगर केले: जर काही क्वेरी प्रति सेकंद दहा लाखांपेक्षा कमी पंक्ती प्रक्रिया करत असतील, तर तुम्ही हे करू शकत नाही. हे आमचे चांगले नाव, आमच्या चांगल्या डेटाबेसला बदनाम करते. यावर बंदी घालूया. प्रत्यक्षात दोन सेटिंग्ज आहेत. एक म्हणतात किमान अंमलबजावणी गती - प्रति सेकंद ओळींमध्ये, आणि किमान अंमलबजावणी गती तपासण्यापूर्वी दुसऱ्याला कालबाह्य म्हणतात - डीफॉल्टनुसार पंधरा सेकंद. म्हणजेच, पंधरा सेकंद शक्य आहे, आणि नंतर, जर ते हळू असेल, तर फक्त एक अपवाद टाका आणि विनंती रद्द करा.

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

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

दहा क्लायंटना एका क्वेरीचे निकाल देणे शक्य आहे का?

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

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

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

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

एक पर्यायी उपाय आहे जो क्लिकहाऊसच्या पुढे साइडकार म्हणून ठेवला आहे - क्लिक हाऊस प्रॉक्सी.

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

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

असिंक्रोनस ऑपरेशन्स आणि मटेरियलाइज्ड व्ह्यूजबद्दल काय?

एक समस्या आहे की रीप्ले इंजिनसह ऑपरेशन्स एसिंक्रोनस आहेत - प्रथम डेटा लिहिला जातो, नंतर तो कोसळतो. काही समुच्चयांसह एक भौतिक टॅब्लेट टॅब्लेटच्या खाली राहत असल्यास, डुप्लिकेट त्यामध्ये रेकॉर्ड केले जातील. आणि जर कोणतेही जटिल तर्क नसेल तर डेटा डुप्लिकेट केला जाईल. याबाबत काय करता येईल?

एक स्पष्ट उपाय आहे - अॅसिंक्रोनस कोलॅप्स ऑपरेशन दरम्यान मॅटव्यूजच्या विशिष्ट वर्गावर ट्रिगर लागू करणे. काही सिल्व्हर बुलेट किंवा तत्सम कार्यक्षमतेची अंमलबजावणी करण्याची योजना आहे का?

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

प्रतिकृती सारणीमध्ये घालताना, संपूर्ण घातलेले ब्लॉक डुप्लिकेट केले जातात. तुम्ही त्याच क्रमाने समान पंक्तींचा समान क्रमांक असलेला समान ब्लॉक पुन्हा घातल्यास, डेटाची डुप्लिकेट केली जाते. इन्सर्टच्या प्रतिसादात तुम्हाला "ओके" प्राप्त होईल, परंतु प्रत्यक्षात डेटाचे एक पॅकेट लिहिले जाईल आणि ते डुप्लिकेट केले जाणार नाही.

हे निश्चिततेसाठी आवश्यक आहे. समाविष्ट करताना तुम्हाला "ओके" प्राप्त झाल्यास, तुमचा डेटा समाविष्ट केला गेला आहे. जर तुम्हाला ClickHouse कडून एरर प्राप्त झाली असेल, तर याचा अर्थ ती घातली गेली नव्हती आणि तुम्हाला इन्सर्शनची पुनरावृत्ती करावी लागेल. पण जर इन्सर्शन करताना कनेक्शन हरवले असेल, तर डेटा टाकला होता की नाही हे तुम्हाला माहीत नाही. एकमात्र पर्याय पुन्हा समाविष्ट करणे पुनरावृत्ती आहे. जर डेटा प्रत्यक्षात घातला गेला असेल आणि तुम्ही तो पुन्हा टाकला असेल, तर ब्लॉक डिडुप्लिकेशन आहे. डुप्लिकेट टाळण्यासाठी हे आवश्यक आहे.

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

आता प्रश्नाबद्दल. तुमची परिस्थिती अधिक क्लिष्ट आहे कारण तुम्ही वैयक्तिक ओळींचे डुप्लिकेट रेकॉर्ड करत आहात. म्हणजेच, हे संपूर्ण पॅक डुप्लिकेट केलेले नाही, परंतु विशिष्ट रेषा आहेत आणि त्या पार्श्वभूमीवर कोसळतात. खरंच, डेटा मुख्य सारणीमध्ये कोलॅप्स केला जाईल, परंतु न संकुचित केलेला डेटा मटेरियलाइज्ड व्ह्यूवर जाईल आणि विलीनीकरणादरम्यान मटेरियलाइज्ड व्ह्यूजमध्ये काहीही होणार नाही. कारण एक भौतिक दृश्य हे इन्सर्ट ट्रिगरपेक्षा अधिक काही नाही. इतर ऑपरेशन्स दरम्यान, त्यात अतिरिक्त काहीही होत नाही.

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

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

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

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

आपल्याकडे काही प्रकारचे API असल्यास - विश्लेषकांसाठी, वापरकर्त्यांसाठी - तर, तत्त्वतः, हा एक पर्याय आहे. आपण नेहमी मोजत आहात, नेहमी मोजत आहात. हे दिवसातून एकदा किंवा इतर वेळी केले जाऊ शकते. तुम्‍ही तुम्‍हाला आवश्‍यक नसलेली आणि गंभीर नसलेली श्रेणी निवडता.

क्लिकहाऊसमध्ये बरेच लॉग आहेत. सर्व्हरवर घडणारी प्रत्येक गोष्ट मी एका दृष्टीक्षेपात कशी पाहू शकतो?

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

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

डॅशबोर्ड आहेत, जरी ते प्रमाणित नाहीत. आमच्या कंपनीत, सुमारे 60 संघ क्लिकहाऊस वापरतात, आणि सर्वात विचित्र गोष्ट अशी आहे की त्यांच्यापैकी अनेकांकडे त्यांनी स्वतःसाठी बनवलेले डॅशबोर्ड आहेत आणि थोडे वेगळे आहेत. काही संघ अंतर्गत Yandex.Cloud इंस्टॉलेशन वापरतात. सर्व आवश्यक नसले तरी काही तयार अहवाल आहेत. इतरांचे स्वतःचे आहे.

Metrica मधील माझ्या सहकाऱ्यांकडे Grafana मध्ये त्यांचा स्वतःचा डॅशबोर्ड आहे आणि त्यांच्या स्वतःच्या क्लस्टरसाठी माझा स्वतःचा डॅशबोर्ड आहे. मी सेरिफ कॅशेसाठी कॅशे हिट सारख्या गोष्टी पाहत आहे. आणि त्याहूनही कठीण म्हणजे आपण वेगवेगळी साधने वापरतो. मी Graphite-web नावाचे खूप जुने टूल वापरून माझा डॅशबोर्ड तयार केला आहे. तो पूर्णपणे कुरूप आहे. आणि मी अजूनही ते कसे वापरतो, जरी ग्राफाना कदाचित अधिक सोयीस्कर आणि सुंदर असेल.

डॅशबोर्डमध्ये मूळ गोष्ट समान आहे. हे क्लस्टरसाठी सिस्टम मेट्रिक्स आहेत: CPU, मेमरी, डिस्क, नेटवर्क. इतर म्हणजे एकाचवेळी विनंत्यांची संख्या, एकाचवेळी विलीनीकरणाची संख्या, प्रति सेकंद विनंत्यांची संख्या, MergeTree टेबलच्या विभाजनांसाठी जास्तीत जास्त भागांची संख्या, प्रतिकृती अंतर, प्रतिकृती रांगेचा आकार, प्रति सेकंद घातलेल्या पंक्तींची संख्या, घातलेल्या ब्लॉक्सची संख्या. प्रती सेकंदास. हे सर्व लॉगमधून नाही तर मेट्रिक्समधून मिळते.

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

मी स्वतः सायकल चालवली. परंतु मला एक प्रश्न आहे: जर हे सर्व प्रमाणित असेल आणि ग्राफाना प्रत्येकजण वापरत असेल, तर Yandex मध्ये असा अधिकृत डॅशबोर्ड का नाही?

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

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

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

सर्व्हर OOM मध्ये क्रॅश होऊ नये म्हणून विलीनीकरणावर कसा प्रभाव टाकायचा?

माझ्याकडे एक टेबल आहे, टेबलमध्ये फक्त एकच विभाजन आहे, ते ReplaceingMergeTree आहे. मी चार वर्षांपासून त्यात डेटा लिहित आहे. मला त्यात बदल करायचा होता आणि काही डेटा हटवायचा होता.

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

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

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

तुम्हाला माहिती आहे, विलीन करताना, सर्व्हर OOM मध्ये येणार नाही, कारण विलीन करताना, RAM ची मात्रा फक्त एका लहान श्रेणीच्या डेटासाठी वापरली जाते. त्यामुळे डेटा कितीही असला तरी सर्व काही ठीक होईल.

व्लादिमीर कोलोबाएव: ठीक आहे. येथे क्षण असा आहे की बगचे निराकरण केल्यानंतर, मी माझ्यासाठी एक नवीन आवृत्ती डाउनलोड केली आणि दुसर्या टेबलवर, एक लहान, जिथे अनेक विभाजने आहेत, मी एक समान ऑपरेशन केले. आणि विलीनीकरणादरम्यान, सर्व्हरवर सुमारे 100 GB RAM बर्न झाली. माझ्याकडे 150 व्याप्त आहेत, 100 खाल्लेले आहेत आणि 50 GB विंडो बाकी आहे, त्यामुळे मी OOM मध्ये पडलो नाही.

100 GB RAM वापरत असल्यास OOM मध्ये पडण्यापासून सध्या माझे संरक्षण काय करते? विलीनीकरणावरील RAM अचानक संपली तर काय करावे?

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

अर्थात, "केवळ बाबतीत" ओओएमपासून संरक्षण करणारी RAM मर्यादा असणे अनावश्यक ठरणार नाही. हे विलीनीकरण पूर्ण होण्यास मदत करणार नाही, ते पुन्हा सुरू होईल, काही उंबरठ्यावर पोहोचेल, अपवाद फेकून द्या आणि नंतर पुन्हा सुरू करा - यातून काहीही चांगले होणार नाही. परंतु तत्त्वतः, हे निर्बंध लागू करणे उपयुक्त ठरेल.

क्लिकहाऊससाठी गोलंग ड्रायव्हर कसा विकसित केला जाईल?

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

एक छोटी टीप. अनंत ऑर्डरच्या सामान्य स्वरूपाचे एक अद्भुत आणि प्रिय भांडार आहे - हे व्हर्टिका आहे. त्यांच्याकडे स्वतःचा अधिकृत पायथन ड्रायव्हर देखील आहे, ज्याला व्हर्टिका डेव्हलपर्स द्वारे समर्थित आहे. आणि बर्‍याच वेळा असे घडले की स्टोरेज आवृत्त्या आणि ड्रायव्हर आवृत्त्या नाटकीयरित्या वेगळ्या झाल्या आणि ड्रायव्हरने काही वेळा काम करणे थांबवले. आणि दुसरा मुद्दा. मला असे वाटते की या अधिकृत ड्रायव्हरसाठी समर्थन "निप्पल" सिस्टमद्वारे केले जाते - आपण त्यांना एक समस्या लिहा आणि ती कायमची लटकते.

माझे दोन प्रश्न आहेत. आता Kirill चा Golang ड्रायव्हर हा Golang वरून ClickHouse सह संवाद साधण्याचा जवळजवळ डीफॉल्ट मार्ग आहे. जोपर्यंत कोणीतरी अद्याप HTTP इंटरफेसद्वारे संप्रेषण करत नाही कारण त्याला ते तसे आवडते. या चालकाचा विकास कसा होणार? रेपॉजिटरीमध्येच कोणत्याही ब्रेकिंग बदलांसह ते समक्रमित केले जाईल का? आणि एखाद्या समस्येवर विचार करण्याची प्रक्रिया काय आहे?

किरील श्वाकोव्ह: पहिली गोष्ट म्हणजे प्रत्येक गोष्ट नोकरशाही पद्धतीने कशी तयार केली जाते. या मुद्द्यावर चर्चा झाली नाही, त्यामुळे माझ्याकडे उत्तर देण्यासारखे काही नाही.

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

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

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

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

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

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

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

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

आळशी_लोड सेटिंग सक्षम करून रीबूट केल्यानंतर बाह्य शब्दकोश उचलत नाही. काय करायचं?

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

कदाचित आमच्याकडे क्लिकहाऊसची जुनी आवृत्ती आहे, त्यामुळे शब्दकोश आपोआप लोड झाला नाही. असे होऊ शकते का?

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

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

शेवटच्या प्रश्नाचे उत्तर एकतर आवृत्ती जुनी आहे किंवा ती डीबग करणे आवश्यक आहे.

सिस्टीम रीलोड डिक्शनरी अनेक शब्दकोशांपैकी एकही डिक्शनरी लोड करत नाही या वस्तुस्थितीचे काय करावे जर त्यापैकी किमान एक त्रुटीसह अयशस्वी झाला?

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

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

क्लिकहाऊस कॉन्फिगरमध्ये तपशील कॉन्फिगर करण्याचा मार्ग आहे, परंतु त्रुटी असल्यास ते प्रदर्शित करू नका?

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

आम्ही ODBC ड्राइव्हर कॉन्फिगरेशनमध्ये तपशील जोडून ही त्रुटी सोडवली. क्लिकहाऊस कॉन्फिगरमध्ये तपशील कॉन्फिगर करण्याचा कोणताही मार्ग आहे, परंतु त्रुटींच्या बाबतीत हे तपशील प्रदर्शित करू नका?

odbc.ini मध्ये ही क्रेडेन्शियल्स निर्दिष्ट करणे आणि क्लिकहाऊसमध्येच फक्त ODBC डेटा स्त्रोताचे नाव निर्दिष्ट करणे हा येथे खरा उपाय आहे. हे इतर शब्दकोश स्रोतांसाठी होणार नाही - MySQL सह शब्दकोशासाठी किंवा इतरांसाठीही नाही, एरर मेसेज प्राप्त करताना तुम्हाला पासवर्ड दिसू नये. ODBC साठी, मी देखील बघेन - जर ते अस्तित्वात असेल, तर तुम्हाला ते काढून टाकावे लागेल.

बोनस: संमेलनांमधून झूम पार्श्वभूमी

चित्रावर क्लिक केल्याने, मेळाव्यातील बोनस पार्श्वभूमी सर्वात चिकाटीच्या वाचकांसाठी उघडेल. आम्ही Avito तंत्रज्ञान शुभंकरांसह आग विझवतो, सिस्टम प्रशासकाच्या खोलीतील किंवा जुन्या-शाळेतील संगणक क्लबमधील सहकार्‍यांशी चर्चा करतो आणि भित्तिचित्रांच्या पार्श्वभूमीवर पुलाखाली दररोज बैठका घेतो.

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