प्रश्नों और उत्तरों में उन्नत उपयोगकर्ताओं के लिए ClickHouse

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

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

सावधान रहें, कट के नीचे बहुत सारा टेक्स्ट है। हमें उम्मीद है कि प्रश्नों वाली सामग्री आपको नेविगेट करने में मदद करेगी।

सामग्री

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

यदि आप पाठ नहीं पढ़ना चाहते हैं, तो आप सभाओं की रिकॉर्डिंग देख सकते हैं हमारे यूट्यूब चैनल पर. टाइमकोड वीडियो के नीचे पहली टिप्पणी में हैं।

ClickHouse लगातार अपडेट किया जाता है, लेकिन हमारा डेटा नहीं। इसके बारे में क्या करना है?

ClickHouse लगातार अद्यतन किया जाता है, और हमारा डेटा, जिसे अंतिम रूप से संसाधित किया गया था, अद्यतन नहीं किया गया है और बैकअप प्रतिलिपि में है।

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

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

ClickHouse से डेटा का बैकअप लेने के लिए वर्तमान सर्वोत्तम प्रथाएँ क्या हैं?

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

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

आइए सर्वोत्तम प्रथाओं से शुरुआत करें। मेरे सहकर्मी हमेशा बैकअप के बारे में सवालों के जवाब में उन्हें Yandex.Cloud सेवा के बारे में याद दिलाने की सलाह देते हैं, जहां यह समस्या पहले ही हल हो चुकी है। इसलिए यदि संभव हो तो इसका प्रयोग करें।

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

मैं डेटा की मात्रा और क्लस्टर के आकार के आधार पर सबसे सरल समाधानों से शुरू करूंगा और सबसे परिष्कृत समाधानों के साथ समाप्त करूंगा। क्लस्टर जितना बड़ा होगा, समाधान उतना ही जटिल होगा।

यदि डेटा वाली तालिका केवल कुछ गीगाबाइट घेरती है, तो बैकअप इस प्रकार किया जा सकता है:

1. तालिका परिभाषा अर्थात मेटाडेटा सहेजें - तालिका बनाएँ दिखाएँ.
2. ClickHouse क्लाइंट का उपयोग करके डंप बनाएं - चयन * मेज से दायर करना। डिफ़ॉल्ट रूप से आपको TabSeparated प्रारूप में एक फ़ाइल प्राप्त होगी। यदि आप अधिक कुशल होना चाहते हैं, तो आप इसे मूल प्रारूप में कर सकते हैं।

यदि डेटा की मात्रा बड़ी है, तो बैकअप में अधिक समय और बहुत अधिक स्थान लगेगा। इसे तार्किक बैकअप कहा जाता है; यह ClickHouse डेटा प्रारूप से बंधा नहीं है। यदि ऐसा है, तो अंतिम उपाय के रूप में आप बैकअप ले सकते हैं और पुनर्प्राप्ति के लिए इसे MySQL पर अपलोड कर सकते हैं।

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

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

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

कभी-कभी आपको इससे भी बेहतर चीज़ की आवश्यकता होती है - ऐसे मामलों में जहां आपके पास प्रत्येक सर्वर पर दसियों या यहां तक ​​कि सैकड़ों टेराबाइट्स और सैकड़ों सर्वर होते हैं। यहां एक समाधान है जो मैंने Yandex.Metrica के अपने सहकर्मियों से लिया है। मैं हर किसी को इसकी अनुशंसा नहीं करूंगा - इसे पढ़ें और स्वयं निर्णय लें कि यह उपयुक्त है या नहीं।

सबसे पहले आपको बड़ी डिस्क शेल्फ़ वाले कई सर्वर बनाने होंगे। इसके बाद, इन सर्वरों पर, कई ClickHouse सर्वर उठाएं और उन्हें कॉन्फ़िगर करें ताकि वे समान शार्क के लिए दूसरी प्रतिकृति के रूप में काम करें। और फिर इन सर्वरों पर एक फ़ाइल सिस्टम या कुछ टूल का उपयोग करें जो आपको स्नैपशॉट बनाने की अनुमति देता है। यहां दो विकल्प हैं. पहला विकल्प LVM स्नैपशॉट है, दूसरा विकल्प Linux पर ZFS है।

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

क्या शाफ्टों में प्रतिकृतियों के नियंत्रित अंतराल को व्यवस्थित करना संभव होगा?

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

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

यदि कोई कमांड हमारे क्लस्टर में आया और उसे तोड़ दिया, तो हमारे पास एक घंटे के अंतराल के साथ एक सशर्त प्रतिकृति है, जहां हम कह सकते हैं कि चलो इस समय इसका उपयोग करते हैं, लेकिन हम पिछले दस मिनट तक इसमें परिवर्तन लागू नहीं करेंगे?

सबसे पहले, प्रतिकृतियों के नियंत्रित अंतराल के बारे में। उपयोगकर्ताओं से ऐसा अनुरोध था, और हमने जीथब पर इस अनुरोध के साथ एक मुद्दा बनाया: "अगर किसी को इसकी ज़रूरत है, तो इसे पसंद करें, दिल लगाएं।" किसी ने वितरण नहीं किया और मामला बंद कर दिया गया। हालाँकि, आप ClickHouse की स्थापना करके यह अवसर पहले ही प्राप्त कर सकते हैं। सच है, केवल संस्करण 20.3 से प्रारंभ हो रहा है।

ClickHouse लगातार बैकग्राउंड में डेटा मर्ज करता रहता है। जब एक मर्ज पूरा हो जाता है, तो डेटा के टुकड़ों के एक निश्चित सेट को एक बड़े टुकड़े से बदल दिया जाता है। साथ ही, डेटा के जो टुकड़े पहले थे वे कुछ समय तक डिस्क पर बने रहते हैं।

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

दूसरे, एक समय सीमा भी है - डेटा के पुराने टुकड़े डिस्क पर आठ मिनट तक पड़े रहते हैं। इन आठ मिनटों को अनुकूलित किया जा सकता है और यहां तक ​​कि एक दिन में भी बदला जा सकता है। इससे डिस्क स्थान खर्च होगा: डेटा प्रवाह के आधार पर, यह पता चलता है कि अंतिम दिन में डेटा न केवल दोगुना हो जाएगा, यह पांच गुना अधिक हो सकता है। लेकिन अगर कोई गंभीर समस्या है, तो आप ClickHouse सर्वर को रोक सकते हैं और सब कुछ सुलझा सकते हैं।

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

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

यही बात उत्परिवर्तन जैसे परिवर्तनों पर भी लागू होती है। कब आप करेंगे परिवर्तन हटाएँ या अद्यतन बदलें, यह टुकड़ा नहीं बदलता, बल्कि एक नया बनाता है। और फिर पुराने को हटा देता है.

यदि तालिका संरचना बदल गई हो तो क्या होगा?

पुरानी योजना के साथ बनाए गए बैकअप को कैसे पुनर्स्थापित करें? और दूसरा प्रश्न स्नैपशॉट और फ़ाइल सिस्टम टूल के मामले के बारे में है। क्या Linux LVM पर ZFS के बजाय Btrfs यहाँ अच्छा है?

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

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

डेटा पुनः साझाकरण में वर्तमान सर्वोत्तम प्रथाएँ क्या हैं?

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

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

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

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

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

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

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

तो यह तरीका नंबर एक है. और मैं आपके उत्तर की प्रतीक्षा कर रहा हूं, कि क्या विधि उपयुक्त है, या आगे बढ़ें।

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

एलेक्सी मिलोविदोव: यहाँ उत्तर अजीब है - हाँ, यह बुरा है, लेकिन यह काम कर सकता है। मैं बिल्कुल समझाऊंगा कि कैसे। यह आपके डेटा के पीछे आने वाले लोड परिदृश्य को देखने लायक है। यदि यह डेटा की निगरानी कर रहा है, तो हम लगभग निश्चित रूप से कह सकते हैं कि अधिकांश अनुरोध ताज़ा डेटा के लिए हैं।

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

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

प्रश्न का उत्तर देने के लिए मेरे पास कुछ और बिंदु हैं। उनमें से एक इस बारे में है कि शुरू में शार्डिंग योजना कैसे डिज़ाइन की जाए ताकि दोबारा शार्डिंग करने पर कम दर्द हो। यह हमेशा संभव नहीं है.

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

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

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

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

आप बिल्कुल सही हैं, हम किसी भी निगरानी प्रणाली की तरह, अंतिम दिन में पढ़ने के अधिकांश अनुरोधों का अनुभव करते हैं। लेकिन साथ ही, ऐतिहासिक डेटा पर भार भी काफी बड़ा है। यह मूल रूप से एक चेतावनी प्रणाली से है जो हर तीस सेकंड में घूमती है और ClickHouse से कहती है: “मुझे पिछले छह सप्ताह का डेटा दें। अब मेरे लिए उनसे किसी प्रकार का मूविंग औसत बनाएं, और वर्तमान मूल्य की तुलना ऐतिहासिक मूल्य से करें।"

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

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

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

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

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

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

एक विकल्प है जो बिल्कुल विपरीत है। कल्पना करें कि यदि हम डेटा को विभिन्न साइटों पर साझा करते हैं, और एक साइट के लिए अनुरोध एक शार्क पर जाता है। अब क्लस्टर प्रति सेकंड दस हजार अनुरोधों को संभालने में सक्षम होगा, लेकिन एक शार्ड पर कोई भी अनुरोध बहुत धीमी गति से काम करेगा। यह अब थ्रूपुट के संदर्भ में स्केल नहीं करेगा। खासकर यदि यह साइट avito.ru है। मैं रहस्य उजागर नहीं करूंगा अगर मैं कहूं कि एविटो रूनेट पर सबसे ज्यादा देखी जाने वाली साइटों में से एक है। और इसे एक टुकड़े पर संसाधित करना पागलपन होगा।

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

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

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

लेकिन मेरी कहानी अधूरी होगी अगर मैं यह न कहूँ कि हमने यह योजना छोड़ दी। नई योजना में, हमने सब कुछ बदल दिया और क्लिकहाउस-कॉपियर का उपयोग करके सभी डेटा कॉपी कर लिया।

नई योजना में सभी साइटों को दो श्रेणियों में बांटा गया है- बड़ी और छोटी। मुझे नहीं पता कि सीमा कैसे चुनी गई, लेकिन नतीजा यह हुआ कि बड़ी साइटें एक क्लस्टर पर रिकॉर्ड की गईं, जहां प्रत्येक में तीन प्रतिकृतियों के साथ 120 शार्ड हैं - यानी 360 सर्वर। और शार्डिंग योजना ऐसी है कि कोई भी अनुरोध एक ही बार में सभी शार्डों तक चला जाता है। यदि आप अब Yandex.Metrica में avito.ru के लिए कोई रिपोर्ट पेज खोलते हैं, तो अनुरोध 120 सर्वरों पर जाएगा। RuNet में कुछ बड़ी साइटें हैं। और अनुरोध प्रति सेकंड एक हजार नहीं, बल्कि सौ से भी कम हैं। यह सब वितरित तालिका द्वारा चुपचाप चबाया जाता है, जिसे उनमें से प्रत्येक 120 सर्वर के साथ संसाधित करता है।

और दूसरा क्लस्टर छोटी साइटों के लिए है। यहां साइट आईडी पर आधारित एक शार्डिंग योजना है, और प्रत्येक अनुरोध बिल्कुल एक शार्ड तक जाता है।

क्लिकहाउस में एक क्लिकहाउस-कॉपियर उपयोगिता है। क्या आप हमें उसके बारे में बता सकते हैं?

मैं तुरंत कहूंगा कि यह समाधान अधिक बोझिल और कुछ हद तक कम उत्पादक है। लाभ यह है कि यह आपके द्वारा निर्दिष्ट पैटर्न के अनुसार डेटा को पूरी तरह से नष्ट कर देता है। लेकिन उपयोगिता का दोष यह है कि यह बिल्कुल भी पुनः हार्ड नहीं होता है। यह एक क्लस्टर स्कीमा से दूसरे क्लस्टर स्कीमा में डेटा कॉपी करता है।

इसका मतलब यह है कि इसे काम करने के लिए आपके पास दो क्लस्टर होने चाहिए। वे एक ही सर्वर पर स्थित हो सकते हैं, लेकिन, फिर भी, डेटा को क्रमिक रूप से स्थानांतरित नहीं किया जाएगा, बल्कि कॉपी किया जाएगा।

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

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

आपके पास रीशार्डिंग नामक एक पायलट चीज़ थी। उसके साथ क्या?

2017 में, आपके पास रीशार्डिंग नामक एक पायलट चीज़ थी। ClickHouse में भी एक विकल्प है। जहां तक ​​मैं इसे समझता हूं, यह शुरू नहीं हुआ। क्या आप मुझे बता सकते हैं कि ऐसा क्यों हुआ? यह बहुत प्रासंगिक प्रतीत होता है.

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

क्या धीमी डिस्क पर ले जाने से पहले डेटा के सभी टुकड़ों को एक साथ मर्ज करना संभव है?

मर्ज के संदर्भ में धीमी डिस्क विकल्प की ओर कदम के साथ टीटीएल के बारे में प्रश्न। क्या क्रॉन के अलावा कोई अन्य तरीका है, जिससे धीमी डिस्क पर ले जाने से पहले सभी हिस्सों को एक में मिला दिया जाए?

इस प्रश्न का उत्तर कि क्या सभी टुकड़ों को स्थानांतरित करने से पहले किसी तरह स्वचालित रूप से उन्हें एक में चिपका देना संभव है - नहीं। मुझे नहीं लगता कि ये जरूरी है. आपको सभी हिस्सों को एक में मिलाने की ज़रूरत नहीं है, लेकिन बस इस तथ्य पर भरोसा करें कि वे स्वचालित रूप से धीमी डिस्क में स्थानांतरित हो जाएंगे।

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

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

यदि पहले से अनुकूलता की जांच करने का कोई तरीका नहीं है तो ClickHouse के नए संस्करणों में माइग्रेट कैसे करें?

इस विषय पर लगातार चर्चा होती रहती है ClickHouse टेलीग्राम चैट में विभिन्न संस्करणों को ध्यान में रखते हुए, और फिर भी। संस्करण 19.11 से 19.16 और, उदाहरण के लिए, 19.16 से 20.3 तक अपग्रेड करना कितना सुरक्षित है। सैंडबॉक्स में पहले से अनुकूलता की जांच किए बिना नए संस्करणों में माइग्रेट करने का सबसे अच्छा तरीका क्या है?

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

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

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

संस्करण 20.3.4 है. संख्या 20 निर्माण के वर्ष - 2020 को इंगित करता है। अंदर क्या है, इसके दृष्टिकोण से, यह कोई मायने नहीं रखता, इसलिए हम इस पर ध्यान नहीं देंगे। अगला - 20.3. हम दूसरी संख्या बढ़ाते हैं - इस मामले में 3 - हर बार जब हम कुछ नई कार्यक्षमता के साथ कोई रिलीज़ जारी करते हैं। यदि हम ClickHouse में कुछ सुविधा जोड़ना चाहते हैं, तो हमें यह संख्या बढ़ानी होगी। यानी वर्जन 20.4 में ClickHouse और भी बेहतर काम करेगा। तीसरा अंक 20.3.4 है. यहां 4 पैच रिलीज़ की संख्या है जिसमें हमने नई सुविधाएँ नहीं जोड़ीं, लेकिन कुछ बग्स को ठीक किया। और 4 का मतलब है कि हमने इसे चार बार किया।

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

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

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

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

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

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

एलेक्सी मिलोविदोव: मैं आपको बताऊंगा कि Yandex.Metrica के हमारे मित्रों का परीक्षण वातावरण कैसा है। एक क्लस्टर में 600 सर्वर थे, दूसरे में 360, और तीसरे में कई क्लस्टर हैं। उनमें से एक के लिए परीक्षण वातावरण केवल दो टुकड़े हैं जिनमें से प्रत्येक में दो प्रतिकृतियां हैं। दो टुकड़े क्यों? ताकि आप अकेले न रहें. और प्रतिकृतियां भी होनी चाहिए. बस एक निश्चित न्यूनतम राशि जो आप वहन कर सकते हैं।

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

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

और सब ठीक है न। हम उत्पादन में आगे बढ़ना शुरू कर रहे हैं। मुझे एक संदेश प्राप्त हुआ कि ग्राफ़ पर भार कई गुना बढ़ गया है। हम संस्करण वापस ला रहे हैं. मैं ग्राफ़ को देखता हूं और देखता हूं: रोलआउट के दौरान लोड वास्तव में कई गुना बढ़ गया, और जब वे रोल आउट हुए तो वापस कम हो गया। फिर हमने संस्करण को वापस रोल करना शुरू किया। और भार वैसे ही बढ़ा और वैसे ही वापस गिर गया। तो निष्कर्ष यह है: लेआउट के कारण लोड बढ़ गया है, कोई आश्चर्य की बात नहीं है।

तब सहकर्मियों को नया संस्करण स्थापित करने के लिए मनाना कठिन था। मैं कहता हूं: “यह ठीक है, रोल आउट करो। अपनी उंगलियाँ क्रॉस रखें, सब कुछ काम करेगा। अब ग्राफ़ पर भार बढ़ गया है, लेकिन सब कुछ ठीक है। वहाँ पर लटका हुआ।" सामान्य तौर पर, हमने यह किया, और बस इतना ही - संस्करण उत्पादन के लिए जारी किया गया था। लेकिन लगभग हर लेआउट के साथ समान समस्याएं उत्पन्न होती हैं।

माना जाता है कि किल क्वेरी से क्वेरी खत्म हो जाती हैं, लेकिन ऐसा नहीं होता है। क्यों?

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

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

अब एक अजीब सा जवाब मिलेगा. मुद्दा यह है कि किल क्वेरी क्वेरी को नहीं मारती है।

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

यह उन मामलों में काम नहीं करता जहां किसी ऑपरेशन पर अनुरोध अवरुद्ध है। सच है, सबसे अधिक संभावना है कि यह आपका मामला नहीं है, क्योंकि, आपके अनुसार, यह ढेर सारे सर्वर संसाधनों का उपयोग करता है। यह संभव है कि बाहरी सॉर्टिंग और कुछ अन्य विवरणों के मामले में यह काम नहीं करता है। लेकिन सामान्य तौर पर ऐसा नहीं होना चाहिए, यह एक बग है। और एकमात्र चीज जो मैं सुझा सकता हूं वह है ClickHouse को अपडेट करना।

रीडिंग लोड के तहत प्रतिक्रिया समय की गणना कैसे करें?

एक तालिका है जो आइटम समुच्चय को संग्रहीत करती है - विभिन्न काउंटर। पंक्तियों की संख्या लगभग सौ मिलियन है। यदि आप 1K आइटम के लिए 1K RPS डालते हैं तो क्या पूर्वानुमानित प्रतिक्रिया समय पर भरोसा करना संभव है?

सन्दर्भ को देखते हुए, हम पढ़ने के भार के बारे में बात कर रहे हैं, क्योंकि लिखने में कोई समस्या नहीं है - यहाँ तक कि एक हज़ार, यहाँ तक कि एक लाख, और कभी-कभी कई मिलियन पंक्तियाँ भी डाली जा सकती हैं।

पढ़ने के अनुरोध बहुत अलग हैं। चयन 1 में, ClickHouse प्रति सेकंड लगभग दसियों हज़ार अनुरोध निष्पादित कर सकता है, इसलिए एक कुंजी के अनुरोध के लिए भी पहले से ही कुछ संसाधनों की आवश्यकता होगी। और ऐसे बिंदु प्रश्न कुछ कुंजी-मूल्य डेटाबेस की तुलना में अधिक कठिन होंगे, क्योंकि प्रत्येक पढ़ने के लिए सूचकांक द्वारा डेटा के एक ब्लॉक को पढ़ना आवश्यक है। हमारा सूचकांक प्रत्येक रिकॉर्ड को नहीं, बल्कि प्रत्येक श्रेणी को संबोधित करता है। यानी आपको पूरी रेंज पढ़नी होगी - यह डिफ़ॉल्ट रूप से 8192 लाइनें हैं। और आपको कंप्रेस्ड डेटा ब्लॉक को 64 KB से 1 MB तक डीकंप्रेस करना होगा। आमतौर पर, ऐसी लक्षित क्वेरीज़ को पूरा होने में कुछ मिलीसेकेंड लगते हैं। लेकिन ये सबसे आसान विकल्प है.

आइए कुछ सरल अंकगणित का प्रयास करें। यदि आप कुछ मिलीसेकंड को एक हजार से गुणा करते हैं, तो आपको कुछ सेकंड मिलते हैं। ऐसा लगता है जैसे प्रति सेकंड एक हजार अनुरोधों को पूरा करना असंभव है, लेकिन वास्तव में यह संभव है, क्योंकि हमारे पास कई प्रोसेसर कोर हैं। इसलिए, सिद्धांत रूप में, ClickHouse कभी-कभी 1000 RPS रख सकता है, लेकिन छोटे अनुरोधों के लिए, विशेष रूप से लक्षित अनुरोधों के लिए।

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

कभी-कभी, निश्चित रूप से, आप अधिकतम संख्या में पॉइंट रीडिंग के लिए ClickHouse को कॉन्फ़िगर कर सकते हैं। इसके लिए क्या आवश्यक है? पहला है सूचकांक की ग्रैन्युलैरिटी को कम करना। इस मामले में, इसे घटाकर एक नहीं किया जाना चाहिए, बल्कि इस आधार पर कि सूचकांक में प्रविष्टियों की संख्या प्रति सर्वर कई मिलियन या दसियों लाख होगी। यदि तालिका में एक सौ मिलियन पंक्तियाँ हैं, तो ग्रैन्युलैरिटी को 64 पर सेट किया जा सकता है।

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

किरिल श्वाकोव: यदि वहाँ सामान्य खाते हों तो मैं सलाह दूँगा। यह एक काफी मानक स्थिति है जब ClickHouse किसी प्रकार का काउंटर संग्रहीत करता है। मेरे पास एक उपयोगकर्ता है, वह अमुक देश से है, और किसी तीसरे क्षेत्र से है, और मुझे धीरे-धीरे कुछ बढ़ाने की जरूरत है। MySQL लें, एक अद्वितीय कुंजी बनाएं - MySQL में यह एक डुप्लिकेट कुंजी है, और PostgreSQL में यह एक विरोध है - और एक प्लस चिह्न जोड़ें। ये काफी बेहतर काम करेगा.

जब आपके पास अधिक डेटा नहीं है, तो ClickHouse का उपयोग करने का कोई मतलब नहीं है। नियमित डेटाबेस हैं और वे यह काम अच्छे से करते हैं।

मैं ClickHouse में क्या बदलाव कर सकता हूँ ताकि कैश में अधिक डेटा रहे?

आइए एक स्थिति की कल्पना करें - सर्वर में 256 जीबी रैम है, दैनिक दिनचर्या में क्लिकहाउस लगभग 60-80 जीबी लेता है, चरम पर - 130 तक। क्या सक्षम और संशोधित किया जा सकता है ताकि कैश में अधिक डेटा हो और, तदनुसार , डिस्क पर कम यात्राएं होती हैं?

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

हालाँकि, यदि आप कुछ सरल प्रश्नों को और भी तेज़ करना चाहते हैं, तो ClickHouse के अंदर डीकंप्रेस्ड डेटा में कैश को सक्षम करना संभव है। यह कहा जाता है असम्पीडित कैश. config.xml कॉन्फ़िगरेशन फ़ाइल में, असम्पीडित कैश आकार को आपके लिए आवश्यक मान पर सेट करें - मैं आधे से अधिक खाली रैम की अनुशंसा नहीं करता, क्योंकि बाकी पेज कैश के अंतर्गत चला जाएगा।

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

मैं रैम में स्टोरेज के लिए स्टोरेज_कॉन्फिगरेशन को कैसे कॉन्फ़िगर कर सकता हूं?

नए ClickHouse दस्तावेज़ में मैंने संबंधित अनुभाग पढ़ा डेटा भंडारण के साथ. विवरण में तेज़ SSD वाला एक उदाहरण है।

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

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

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

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

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

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

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

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

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

पाँच अरब पंक्तियों वाली तालिका को पूर्ण-पाठ में खोजने के लिए सर्वोत्तम अभ्यास क्या हैं?

अलग-अलग उत्तर हैं. पहला यह कहना है कि ClickHouse एक पूर्ण-पाठ खोज इंजन नहीं है। इसके लिए विशेष प्रणालियाँ हैं, उदाहरण के लिए, Elasticsearch и गूढ़ व्यक्ति. हालाँकि, मैं तेजी से लोगों को यह कहते हुए देख रहा हूँ कि वे Elasticsearch से ClickHouse पर स्विच कर रहे हैं।

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

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

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

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

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

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

एक पास में अनेक रेगुलर एक्सप्रेशन की खोज भी सामने आई है। आपको X को एक सबस्ट्रिंग की तरह या X को दूसरी सबस्ट्रिंग की तरह लिखने की ज़रूरत नहीं है। आप तुरंत लिखते हैं, और सब कुछ यथासंभव कुशलतापूर्वक किया जाता है।

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

बड़ी संख्या में उपयोगकर्ताओं के लिए ClickHouse तक पहुंच व्यवस्थित करने का सबसे अच्छा तरीका क्या है?

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

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

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

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

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

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

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

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

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

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

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

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

क्या एक प्रश्न के परिणाम दस ग्राहकों को देना संभव है?

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

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

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

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

एक वैकल्पिक समाधान है जिसे ClickHouse के बगल में एक साइडकार के रूप में रखा गया है - क्लिकहाउस प्रॉक्सी.

किरिल श्वाकोव: ClickHouse Proxy में एक अंतर्निहित दर सीमक और एक अंतर्निहित परिणाम कैश है। वहां बहुत सारी सेटिंग्स की गईं क्योंकि एक समान समस्या का समाधान किया जा रहा था। प्रॉक्सी आपको अनुरोधों को कतारबद्ध करके सीमित करने और अनुरोध कैश कितने समय तक रहता है यह कॉन्फ़िगर करने की अनुमति देता है। यदि अनुरोध वास्तव में समान थे, तो प्रॉक्सी उन्हें कई बार भेजेगा, लेकिन क्लिकहाउस पर केवल एक बार जाएगा।

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

अतुल्यकालिक संचालन और भौतिक दृश्यों के बारे में क्या?

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

एक स्पष्ट समाधान है - एक अतुल्यकालिक पतन ऑपरेशन के दौरान मैटव्यू के एक निश्चित वर्ग पर एक ट्रिगर लागू करना। क्या ऐसी ही कार्यक्षमता लागू करने की कोई उम्मीद की किरण या योजना है?

यह समझने लायक है कि डिडुप्लीकेशन कैसे काम करता है। अब मैं आपको जो बताऊंगा वह प्रश्न के लिए प्रासंगिक नहीं है, लेकिन केवल मामले में यह याद रखने योग्य है।

किसी प्रतिकृति तालिका में सम्मिलित करते समय, संपूर्ण सम्मिलित ब्लॉकों का डुप्लिकेशन होता है। यदि आप उसी क्रम में समान पंक्तियों की समान संख्या वाले समान ब्लॉक को पुनः सम्मिलित करते हैं, तो डेटा डुप्लिकेट हो जाता है। सम्मिलित करने के जवाब में आपको "ओके" प्राप्त होगा, लेकिन वास्तव में डेटा का एक पैकेट लिखा जाएगा, और इसे डुप्लिकेट नहीं किया जाएगा।

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

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

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

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

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

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

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

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

ClickHouse में बहुत सारे लॉग हैं। मैं सर्वर पर होने वाली हर चीज़ को एक नज़र में कैसे देख सकता हूँ?

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

क्या आपके पास ClickHouse टीम, या आपके मित्रों की टीम है, जो तैयार डैशबोर्ड की कुछ कार्यक्षमता का समर्थन करती है जो इन लॉग को तैयार उत्पाद के रूप में प्रदर्शित करेगी? अंततः, केवल ClickHouse में लॉग देखना ही बढ़िया है। लेकिन यह बहुत अच्छा होगा यदि इसे डैशबोर्ड के रूप में पहले से ही तैयार किया गया हो। मुझे इससे एक किक मिलेगी.

डैशबोर्ड हैं, हालाँकि वे मानकीकृत नहीं हैं। हमारी कंपनी में, लगभग 60 टीमें ClickHouse का उपयोग करती हैं, और सबसे अजीब बात यह है कि उनमें से कई के पास स्वयं के लिए बनाए गए डैशबोर्ड हैं, और थोड़े अलग हैं। कुछ टीमें आंतरिक Yandex.Cloud इंस्टॉलेशन का उपयोग करती हैं। कुछ तैयार रिपोर्टें हैं, हालाँकि सभी आवश्यक नहीं हैं। दूसरों के पास अपना है.

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

डैशबोर्ड में मूल बात वही है. ये क्लस्टर के लिए सिस्टम मेट्रिक्स हैं: सीपीयू, मेमोरी, डिस्क, नेटवर्क। अन्य - एक साथ अनुरोधों की संख्या, एक साथ विलय की संख्या, प्रति सेकंड अनुरोधों की संख्या, मर्जट्री तालिका विभाजन के लिए खंडों की अधिकतम संख्या, प्रतिकृति अंतराल, प्रतिकृति कतार का आकार, प्रति सेकंड सम्मिलित पंक्तियों की संख्या, प्रति सेकंड सम्मिलित ब्लॉकों की संख्या। यह वह सब है जो लॉग से नहीं, बल्कि मेट्रिक्स से प्राप्त होता है।

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

मैंने इसे स्वयं बाइक से चलाया। लेकिन मेरा एक प्रश्न है - यदि यह सब मानकीकृत है, और ग्राफाना का उपयोग हर कोई करता है, तो यांडेक्स के पास ऐसा आधिकारिक डैशबोर्ड क्यों नहीं है?

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

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

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

मर्ज को कैसे प्रभावित करें ताकि सर्वर OOM में क्रैश न हो?

मेरे पास एक तालिका है, तालिका में केवल एक विभाजन है, यह ReplaceingMergeTree है। मैं चार साल से इसमें डेटा लिख ​​रहा हूं। मुझे इसमें बदलाव करना था और कुछ डेटा डिलीट करना था।

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

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

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

आप जानते हैं, विलय करते समय, सर्वर OOM में नहीं आएगा, क्योंकि विलय करते समय, RAM की मात्रा का उपयोग केवल डेटा की एक छोटी श्रृंखला के लिए किया जाता है। इसलिए डेटा की मात्रा की परवाह किए बिना सब कुछ ठीक रहेगा।

व्लादिमीर कोलोबेव: अच्छा। यहां क्षण ऐसा है कि बग ठीक होने के बाद, मैंने अपने लिए एक नया संस्करण डाउनलोड किया, और एक अन्य टेबल पर, एक छोटी टेबल पर, जहां कई विभाजन हैं, मैंने एक समान ऑपरेशन किया। और मर्ज के दौरान सर्वर पर लगभग 100 जीबी रैम बर्न हो गई। मेरे पास 150 थे, 100 खाये गये, और 50 जीबी विंडो बची थी, इसलिए मैं OOM में नहीं आया।

यदि यह वास्तव में 100 जीबी रैम की खपत करता है तो वर्तमान में मुझे OOM में गिरने से क्या बचाता है? अगर अचानक मर्ज पर रैम खत्म हो जाए तो क्या करें?

एलेक्सी मिलोविदोव: ऐसी समस्या है कि विशेष रूप से विलय के लिए रैम की खपत सीमित नहीं है। और दूसरी समस्या यह है कि यदि किसी प्रकार का मर्ज सौंपा गया है, तो उसे निष्पादित किया जाना चाहिए क्योंकि यह प्रतिकृति लॉग में दर्ज किया गया है। प्रतिकृति लॉग वह क्रियाएं हैं जो प्रतिकृति को एक सुसंगत स्थिति में लाने के लिए आवश्यक हैं। यदि आप मैन्युअल हेरफेर नहीं करते हैं जो इस प्रतिकृति लॉग को वापस रोल करेगा, तो मर्ज को एक या दूसरे तरीके से निष्पादित करना होगा।

निःसंदेह, ऐसी रैम सीमा होना अतिश्योक्तिपूर्ण नहीं होगी जो "बस मामले में" OOM से रक्षा करती हो। यह मर्ज को पूरा करने में मदद नहीं करेगा, यह फिर से शुरू होगा, कुछ सीमा तक पहुंचेगा, एक अपवाद फेंक देगा, और फिर फिर से शुरू होगा - इससे कुछ भी अच्छा नहीं होगा। लेकिन सिद्धांत रूप में, इस प्रतिबंध को लागू करना उपयोगी होगा।

ClickHouse के लिए गोलांग ड्राइवर कैसे विकसित किया जाएगा?

गोलांग ड्राइवर, जिसे किरिल श्वाकोव ने लिखा था, अब आधिकारिक तौर पर ClickHouse टीम द्वारा समर्थित है। वह क्लिकहाउस रिपॉजिटरी में, वह अब बड़ा और वास्तविक है।

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

मेरे दो प्रश्न हैं. अब किरिल का गोलांग ड्राइवर गोलांग से क्लिकहाउस के साथ संचार करने का लगभग डिफ़ॉल्ट तरीका है। जब तक कोई अभी भी http इंटरफ़ेस के माध्यम से संचार नहीं करता क्योंकि उसे यह पसंद है। इस ड्राइवर का विकास कैसे आगे बढ़ेगा? क्या इसे रिपॉजिटरी में किसी भी परिवर्तन के साथ सिंक्रनाइज़ किया जाएगा? और किसी मुद्दे पर विचार करने की प्रक्रिया क्या है?

किरिल श्वाकोव: पहला यह है कि सब कुछ नौकरशाही ढंग से कैसे व्यवस्थित किया जाता है। इस मुद्दे पर चर्चा नहीं हुई, इसलिए मेरे पास जवाब देने के लिए कुछ नहीं है.

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

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

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

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

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

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

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

इन ड्राइवरों के लिए हमारे पास कोई आंतरिक विकास नहीं है। सवाल यह है कि क्या हम किसी विशेष ड्राइवर के लिए नहीं, बल्कि सभी सामुदायिक ड्राइवरों के विकास के लिए एक व्यक्ति को काम पर रख सकते हैं, या क्या हम बाहर से किसी को ढूंढ सकते हैं।

आलसी_लोड सेटिंग सक्षम होने पर रीबूट के बाद बाहरी शब्दकोश लोड नहीं होता है। क्या करें?

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

शायद हमारे पास ClickHouse का पुराना संस्करण है, इसलिए शब्दकोश स्वचालित रूप से लोड नहीं हुआ। क्या ऐसा हो सकता है?

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

यह भारी शब्दकोशों के लिए बहुत सुविधाजनक नहीं है. उदाहरण के लिए, आपको MySQL से दस लाख पंक्तियाँ खींचने की आवश्यकता है। कोई व्यक्ति एक साधारण चयन करता है, लेकिन यह चयन उसी मिलियन पंक्तियों की प्रतीक्षा करेगा। यहां दो समाधान हैं. सबसे पहले आलसी_लोड को बंद करना है। दूसरे, जब सर्वर चालू हो तो उस पर लोड डालने से पहले ऐसा करें सिस्टम पुनः लोड शब्दकोश या बस एक क्वेरी करें जो शब्दकोश का उपयोग करती है। फिर शब्दकोश लोड हो जाएगा. आपको आलसी_लोड सेटिंग सक्षम करके शब्दकोशों की उपलब्धता को नियंत्रित करने की आवश्यकता है, क्योंकि ClickHouse उन्हें स्वचालित रूप से लोड नहीं करता है।

अंतिम प्रश्न का उत्तर यह है कि या तो संस्करण पुराना है या इसे डीबग करने की आवश्यकता है।

इस तथ्य का क्या करें कि सिस्टम पुनः लोड शब्दकोश कई शब्दकोशों में से किसी को भी लोड नहीं करता है यदि उनमें से कम से कम एक त्रुटि के साथ क्रैश हो जाता है?

सिस्टम रीलोड शब्दकोशों के बारे में एक और प्रश्न है। हमारे पास दो शब्दकोष हैं - एक लोडेड नहीं है, दूसरा लोडेड है। इस मामले में, सिस्टम रीलोड डिक्शनरी किसी भी डिक्शनरी को लोड नहीं करती है, और आपको सिस्टम रीलोड डिक्शनरी का उपयोग करके किसी विशिष्ट डिक्शनरी को उसके नाम से बिंदु-दर-बिंदु लोड करना होगा। क्या यह भी ClickHouse संस्करण से संबंधित है?

मैं आपको खुश करना चाहता हूँ। यह व्यवहार बदल रहा था. इसका मतलब है कि अगर आप ClickHouse को अपडेट करेंगे तो यह भी बदल जाएगा। यदि आप अपने वर्तमान व्यवहार से खुश नहीं हैं सिस्टम शब्दकोश पुनः लोड करें, अद्यतन करें, और आशा करते हैं कि यह बेहतरी के लिए बदलेगा।

क्या ClickHouse कॉन्फ़िगरेशन में विवरण कॉन्फ़िगर करने का कोई तरीका है, लेकिन त्रुटियों के मामले में उन्हें प्रदर्शित नहीं किया जा सकता है?

अगला प्रश्न शब्दकोश से संबंधित त्रुटियों, अर्थात् विवरणों के बारे में है। हमने शब्दकोश के लिए ClickHouse कॉन्फ़िगरेशन में कनेक्शन विवरण निर्दिष्ट किया है, और यदि कोई त्रुटि है, तो हमें प्रतिक्रिया में ये विवरण और पासवर्ड प्राप्त होते हैं।

हमने ODBC ड्राइवर कॉन्फ़िगरेशन में विवरण जोड़कर इस त्रुटि को हल किया। क्या ClickHouse कॉन्फ़िगरेशन में विवरण कॉन्फ़िगर करने का कोई तरीका है, लेकिन त्रुटियों के मामले में ये विवरण नहीं दिखाए जाएंगे?

यहां वास्तविक समाधान इन क्रेडेंशियल्स को odbc.ini में निर्दिष्ट करना है, और ClickHouse में केवल ODBC डेटा स्रोत नाम निर्दिष्ट करना है। ऐसा अन्य शब्दकोश स्रोतों के लिए नहीं होगा - न तो MySQL वाले शब्दकोश के लिए, न ही अन्य के लिए, आपको त्रुटि संदेश प्राप्त होने पर पासवर्ड नहीं देखना चाहिए। ओडीबीसी के लिए, मैं भी देखूंगा - यदि यह मौजूद है, तो आपको इसे हटाने की जरूरत है।

बोनस: सभाओं से ज़ूम के लिए पृष्ठभूमि

तस्वीर पर क्लिक करने पर, सबसे लगातार पाठकों के लिए सभाओं की बोनस पृष्ठभूमि खुल जाएगी। हमने एविटो प्रौद्योगिकी शुभंकर के साथ मिलकर आग बुझाई, हम सिस्टम प्रशासक के कमरे या पुराने स्कूल के कंप्यूटर क्लब के सहयोगियों से मुलाकात करते हैं, और हम भित्तिचित्रों की पृष्ठभूमि में पुल के नीचे दैनिक बैठकें आयोजित करते हैं।

स्रोत: www.habr.com