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

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

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

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

सामग्री

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सबसे पहले, जब तक चुनिंदा क्वेरीज़ उनका उपयोग करती हैं, तब तक उन्हें संग्रहीत किया जाता रहेगा, ताकि नॉन-ब्लॉकिंग ऑपरेशन सुनिश्चित हो सके। चुनिंदा क्वेरीज़ बिना किसी समस्या के पुराने खंडों को पढ़ सकती हैं।

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

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

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

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

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

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

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

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

डेटा रीशर्डिंग में वर्तमान सर्वोत्तम प्रथाएं क्या हैं?

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

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

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

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

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

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

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

तो, ये है पहला तरीका। और मैं आपके जवाब का इंतज़ार कर रहा हूँ, क्या ये तरीका उपयुक्त है, या हमें आगे बढ़ना चाहिए?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ClickHouse में clickhouse-copier नाम की एक उपयोगिता है। क्या आप हमें इसके बारे में बता सकते हैं?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

संस्करण 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 क्लस्टर है, तो परीक्षण वातावरण उससे छोटा नहीं होना चाहिए, या कम से कम दस गुना छोटा होना चाहिए। यह बिल्कुल भी सच नहीं है।

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

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

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

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

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

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

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

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

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

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

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

अब इसका जवाब थोड़ा अजीब होगा। बात यह है कि किल क्वेरी, क्वेरीज़ को नहीं मारती।

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

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

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

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

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

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

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

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

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

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

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

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

कैश में अधिक डेटा रखने के लिए मुझे ClickHouse में क्या ट्यून करना चाहिए?

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

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

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

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

मैं RAM में संग्रहीत करने के लिए storage_configuration को कैसे कॉन्फ़िगर कर सकता हूँ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह समझना ज़रूरी है कि डीडुप्लीकेशन कैसे काम करता है। मैं अभी जिस बारे में बात करने जा रहा हूँ, वह इस प्रश्न से संबंधित नहीं है, लेकिन किसी भी स्थिति में इसे याद रखना ज़रूरी है।

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

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

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

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

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

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

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

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

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

ClickHouse में बहुत सारे लॉग हैं। मैं किसी भी समय सर्वर पर होने वाली हर घटना को कैसे देख सकता हूँ?

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

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

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

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

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

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

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

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

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

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

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

मेरे पास एक टेबल है, उस टेबल में सिर्फ़ एक ही पार्टिशन है, जिसका नाम है ReplacingMergeTree. मैं चार साल से उसमें डेटा लिख रहा हूँ। मुझे उसमें कुछ बदलाव करने और कुछ डेटा हटाने की ज़रूरत थी।

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

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

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

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

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

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

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

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

ClickHouse के लिए Golang ड्राइवर का विकास कैसे होगा?

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

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

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

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

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

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

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

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

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

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

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

हमारे अंदर इन ड्राइवरों के लिए कोई विकास योजना नहीं है। सवाल यह है कि क्या हम किसी अलग व्यक्ति को नियुक्त कर सकते हैं, इस विशिष्ट ड्राइवर के लिए नहीं, बल्कि सभी सामुदायिक ड्राइवरों के विकास के लिए, या फिर हम बाहर से किसी को ढूँढ सकते हैं।

lazy_load सक्षम होने पर रीबूट करने के बाद बाह्य शब्दकोश प्रारंभ नहीं होता है। क्या करें?

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

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

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

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

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

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

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

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

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

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

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

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

बोनस: गेट-टुगेदर की ज़ूम पृष्ठभूमि

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

स्रोत: www.habr.com