ClickHouse का प्रभावी उपयोग। एलेक्सी मिलोविदोव (यांडेक्स)

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

नमस्ते! मेरा नाम एलेक्सी है, मैं ClickHouse बनाता हूँ।

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

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

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

तो, रेक क्या हैं? मूलतः मैं स्पष्ट चीजों के बारे में बात करूंगा। हर किसी के लिए सब कुछ स्पष्ट है, हर कोई सब कुछ समझता है और खुश हो सकता है कि वे इतने स्मार्ट हैं, और जो नहीं समझते वे कुछ नया सीखेंगे।

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

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

और आइए देखें कि विशिष्ट प्रदर्शन क्या होगा। उदाहरण के लिए, हमारे पास Yandex.Metrics डेटा वाली एक तालिका है। हिट्स. 105 कुछ कॉलम. 700 बाइट्स असम्पीडित. और हम अच्छे तरीके से दस लाख लाइनों के बैच सम्मिलित करेंगे।

हम मर्जट्री तालिका में सम्मिलित करते हैं, प्रति सेकंड आधा मिलियन पंक्तियाँ प्राप्त होती हैं। महान। एक प्रतिकृति तालिका में - यह थोड़ी कम होगी, लगभग 400 पंक्तियाँ प्रति सेकंड।

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

*2020 तक, पहले से ही प्रलेखित.

यदि आप कुछ बुरा करते हैं तो क्या होगा? हम मर्जट्री तालिका में एक पंक्ति सम्मिलित करते हैं और प्रति सेकंड 59 पंक्तियाँ प्राप्त करते हैं। यह 10 गुना धीमा है। ReplicationMergeTree में - प्रति सेकंड 000 पंक्तियाँ। और यदि कोरम चालू कर दिया जाए तो प्रति सेकंड 6 पंक्तियाँ प्राप्त होती हैं। मेरी राय में, यह किसी प्रकार की पूर्ण बकवास है। आप ऐसे कैसे धीमे हो सकते हैं? मैंने अपनी टी-शर्ट पर भी लिखा है कि ClickHouse को धीमा नहीं करना चाहिए। लेकिन फिर भी कभी-कभी ऐसा हो जाता है.

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

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

और सवाल उठता है: "इसे सही तरीके से कैसे करें?" यदि ऐसी स्थिति है, तो आपको अभी भी किसी तरह ClickHouse पर डेटा लिखना होगा।

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

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

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

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

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

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

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

हालाँकि, इस मामले में, डेटा तुरंत ClickHouse को भेज दिया जाएगा। और ClickHouse स्वयं उन्हें बफर कर देगा।

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

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

*2020 तक, इसे भी विचार में जोड़ा जाना चाहिए बिल्ली का बच्चा घर.

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

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

और बफ़र तालिकाओं में भी कोई लॉग नहीं है। और अगर आपके सर्वर में कुछ गड़बड़ी हुई तो डेटा नष्ट हो जाएगा.

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

और इस अवसर के बारे में विशेष रूप से प्रसन्न करने वाली बात यह है कि यह हम नहीं थे जिन्होंने इसे किया। यह एक सामुदायिक विशेषता है. और जब मैं "सामुदायिक सुविधा" कहता हूं, तो मेरा मतलब बिना किसी अवमानना ​​के होता है। हमने कोड पढ़ा, समीक्षा की, इसे ठीक काम करना चाहिए।

*2020 तक, इसी तरह का समर्थन सामने आया है RabbitMQ.

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

* फिलहाल, समस्या पूरी तरह से हल हो गई है, VALUES में अभिव्यक्तियों का उपयोग करने पर कोई प्रदर्शन प्रतिगमन नहीं होता है।

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

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

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

डेटा टाइपिंग सख्त या स्ट्रिंग हो सकती है। स्ट्रिंग तब होती है जब आपने इसे अभी लिया और घोषित किया कि आपके सभी फ़ील्ड स्ट्रिंग प्रकार के हैं। यह बेकार है. ऐसा करने की कोई जरूरत नहीं है.

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

उदाहरण के लिए, हमारे पास एक आईपी एड्रेस है। एक मामले में, हमने इसे एक स्ट्रिंग के रूप में सहेजा। उदाहरण के लिए, 192.168.1.1. अन्यथा, यह कई प्रकार का UInt32* होगा। IPv32 पते के लिए 4 बिट पर्याप्त है।

सबसे पहले, अजीब तरह से, डेटा लगभग समान रूप से संपीड़ित किया जाएगा। निःसंदेह, अंतर होगा, लेकिन उतना बड़ा नहीं। इसलिए डिस्क I/O में कोई विशेष समस्या नहीं है।

लेकिन सीपीयू समय और क्वेरी निष्पादन समय में गंभीर अंतर है।

आइए अद्वितीय आईपी पतों की संख्या गिनें यदि उन्हें संख्याओं के रूप में संग्रहीत किया गया है। यह प्रति सेकंड 137 मिलियन लाइन तक काम करता है। यदि वही स्ट्रिंग के रूप में हो तो 37 मिलियन लाइन प्रति सेकंड। मुझे नहीं पता कि ये संयोग क्यों बना. मैंने इन अनुरोधों को स्वयं पूरा किया। लेकिन फिर भी लगभग 4 गुना धीमा।

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

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

आइए अलग-अलग मामलों पर नजर डालें.

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

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

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

दूसरा विकल्प लगभग समान है, लेकिन ClickHouse के अंदर समर्थन के साथ। यह Enum डेटा प्रकार है. आप बस Enum के अंदर आवश्यक सभी मान लिखें। उदाहरण के लिए, डिवाइस का प्रकार और वहां लिखें: डेस्कटॉप, मोबाइल, टैबलेट, टीवी। कुल मिलाकर 4 विकल्प हैं.

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

* ClickHouse के हाल के संस्करणों में, ALTER को पूरी तरह से गैर-अवरुद्ध बना दिया गया है।

एक अन्य विकल्प जो ClickHouse के लिए काफी अनोखा है वह है बाहरी शब्दकोशों को जोड़ना। आप ClickHouse में संख्याएँ लिख सकते हैं, और अपनी निर्देशिकाओं को अपने लिए सुविधाजनक किसी भी सिस्टम में रख सकते हैं। उदाहरण के लिए, आप इसका उपयोग कर सकते हैं: MySQL, Mongo, Postgres। आप अपना स्वयं का माइक्रोसर्विसेज भी बना सकते हैं जो इस डेटा को http के माध्यम से भेजेगा। और ClickHouse स्तर पर, आप एक फ़ंक्शन लिखते हैं जो इस डेटा को संख्याओं से स्ट्रिंग में परिवर्तित कर देगा।

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

यहाँ एक उदाहरण है। Yandex.Direct है। और एक विज्ञापन कंपनी और बैनर है. संभवतः लाखों विज्ञापन कंपनियाँ हैं। और मोटे तौर पर रैम में फिट बैठता है। और अरबों बैनर हैं, वे फिट नहीं बैठते। और हम MySQL से कैश्ड डिक्शनरी का उपयोग कर रहे हैं।

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

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

दूसरा तरीका जब आप नहीं जानते कि अपनी स्ट्रिंग के लिए पहचानकर्ता कहां से प्राप्त करें। आप बस हैश कर सकते हैं. और सबसे आसान विकल्प 64-बिट हैश लेना है।

एकमात्र समस्या यह है कि यदि हैश 64-बिट है, तो आपके बीच लगभग निश्चित रूप से टकराव होगा। क्योंकि यदि एक अरब रेखाएँ हैं, तो संभावना पहले से ही मूर्त होती जा रही है।

और विज्ञापन कंपनियों के नाम इस तरह से मिटाना बहुत अच्छा नहीं होगा। अगर अलग-अलग कंपनियों के विज्ञापन अभियान आपस में मिल जाएं तो कुछ समझ से परे होगा.

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

बोनस के रूप में, कई परिचालनों के लिए, केवल हैश ही पर्याप्त हैं और स्ट्रिंग्स को कहीं भी संग्रहीत नहीं किया जा सकता है।

एक अन्य उदाहरण यदि स्ट्रिंग छोटी हैं, जैसे वेबसाइट डोमेन। इन्हें वैसे ही संग्रहित किया जा सकता है. या, उदाहरण के लिए, ब्राउज़र भाषा ru 2 बाइट्स है। निःसंदेह, मुझे बाइट्स के लिए खेद है, लेकिन चिंता न करें, 2 बाइट्स कोई खेद नहीं हैं। कृपया इसे ऐसे ही रखें, चिंता न करें।

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

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

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

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

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

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

और एक मामले में, हम बस यूआरएल प्राप्त करेंगे और डोमेन की गणना करेंगे। यह 166 मिलीसेकेंड बनता है। और यदि आप एक रेडीमेड डोमेन लेते हैं, तो यह केवल 67 मिलीसेकंड यानी लगभग तीन गुना तेज हो जाता है। और तेज़, इसलिए नहीं कि हमें कुछ गणनाएँ करने की ज़रूरत है, बल्कि इसलिए कि हम कम डेटा पढ़ते हैं।

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

और यदि आप डिस्क पर डेटा की मात्रा को देखें, तो पता चलता है कि URL 126 मेगाबाइट है, और डोमेन केवल 5 मेगाबाइट है। यह 25 गुना कम निकलता है। हालाँकि, क्वेरी अभी भी केवल 4 गुना तेज़ है। लेकिन ऐसा इसलिए है क्योंकि डेटा गर्म है। और यदि यह ठंडा होता, तो डिस्क I/O के कारण संभवतः यह 25 गुना तेज़ होता।

वैसे, अगर आप मूल्यांकन करें कि डोमेन यूआरएल से कितना कम है, तो यह लगभग 4 गुना हो जाता है। लेकिन किसी कारण से, डिस्क पर डेटा 25 गुना कम लगता है। क्यों? संपीड़न के कारण. और यूआरएल संपीड़ित है, और डोमेन संपीड़ित है। लेकिन अक्सर यूआरएल में ढेर सारा कचरा होता है।

और, निश्चित रूप से, यह सही डेटा प्रकारों का उपयोग करने लायक है जो विशेष रूप से सही मानों या फिट होने के लिए डिज़ाइन किए गए हैं। यदि आप IPv4 में हैं तो UInt32* स्टोर करें। यदि आईपीवी6, तो फिक्स्डस्ट्रिंग(16), क्योंकि आईपीवी6 पता 128 बिट्स है, यानी सीधे बाइनरी प्रारूप में स्टोर करें।

लेकिन क्या होगा यदि आपके पास कभी IPv4 पते हों और कभी IPv6? हां, आप दोनों रख सकते हैं. एक कॉलम IPv4 के लिए, दूसरा IPv6 के लिए। बेशक, IPv4 को IPv6 में मैप करने का विकल्प है। यह भी काम करेगा, लेकिन अगर आपको अक्सर अपने अनुरोधों में IPv4 पते की आवश्यकता होती है, तो इसे एक अलग कॉलम में रखना अच्छा होगा।

* अब ClickHouse में अलग-अलग IPv4, IPv6 डेटा प्रकार हैं जो डेटा को संख्याओं की तरह कुशलता से संग्रहीत करते हैं, लेकिन उन्हें स्ट्रिंग्स के रूप में सुविधाजनक रूप से प्रस्तुत करते हैं।

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

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

तो ऐसे में इसे 4 कॉलम में बांटना ज्यादा सही होगा. यहां डरो मत, क्योंकि यह ClickHouse है। ClickHouse एक कॉलम डेटाबेस है। और छोटे कॉलम जितने साफ-सुथरे होंगे, उतना अच्छा होगा। 5 ब्राउज़र संस्करण होंगे, 5 कॉलम बनाएं। यह ठीक है।

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

उदाहरण के लिए, हमारी एक एनालिटिक्स सेवा में कुछ इवेंट पैरामीटर हैं। और यदि घटनाओं में बहुत सारे पैरामीटर आते हैं, तो हम सामने आने वाले पहले 512 को सहेज लेते हैं। क्योंकि 512 कोई अफ़सोस की बात नहीं है।

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

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

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

यहां हम एक हजार तालिकाएं देखते हैं, जिनमें से प्रत्येक में कौन जानता है कि क्या को एक हजार से विभाजित करने के शेष भाग को दर्ज किया गया है।

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

और कारण कमोबेश स्पष्ट हैं। ये पुरानी रूढ़ियाँ हैं जो अन्य प्रणालियों के साथ काम करते समय जमा हो सकती हैं। उदाहरण के लिए, MyISAM तालिकाओं में क्लस्टर्ड प्राथमिक कुंजी नहीं होती है। और डेटा साझा करने का यह तरीका समान कार्यक्षमता प्राप्त करने का एक हताश प्रयास हो सकता है।

दूसरा कारण यह है कि बड़ी तालिकाओं पर कोई भी परिवर्तन कार्य करना कठिन होता है। सब कुछ ब्लॉक हो जाएगा. हालाँकि MySQL के आधुनिक संस्करणों में यह समस्या अब इतनी गंभीर नहीं है।

या, उदाहरण के लिए, माइक्रोशार्डिंग, लेकिन उस पर बाद में और अधिक जानकारी।

ClickHouse में, आपको ऐसा करने की आवश्यकता नहीं है, क्योंकि, सबसे पहले, प्राथमिक कुंजी को क्लस्टर किया जाता है, डेटा को प्राथमिक कुंजी द्वारा क्रमबद्ध किया जाता है।

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

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

यदि ऐड/ड्रॉप कॉलम में परिवर्तन किया जाए तो ClickHouse में परिवर्तन निःशुल्क है।

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

एक बड़ी मेज का उपयोग करना सही है। पुरानी रूढ़ियों से छुटकारा पाएं, सब ठीक हो जाएगा।

और एक बोनस के रूप में, नवीनतम संस्करण में अब हमारे पास अलग-अलग विभाजनों पर सभी प्रकार के रखरखाव संचालन करने के लिए एक मनमाना विभाजन कुंजी बनाने की क्षमता है।

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

* अब ClickHouse के पास और भी बहुत कुछ है टेबल फ़ंक्शन इनपुट.

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

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

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

और दूसरा कारण यह है कि आपके पास टीसीपी पर इंटरप्रोसेसर संचार होगा। डेटा को क्रमबद्ध, डिसेरिएलाइज़ करना होगा, और यह माइक्रोशार्ड की एक बड़ी संख्या है। यह बस काम नहीं करेगा.

एक और एंटीपैटर्न, हालांकि इसे शायद ही एंटीपैटर्न कहा जा सकता है। यह पूर्व-एकत्रीकरण की एक बड़ी मात्रा है.

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

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

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

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

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

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

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

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

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

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

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

हालाँकि, कुछ कठिनाइयाँ हैं। उदाहरण के लिए, सबक्वेरी वाला IN इंडेक्स का उपयोग नहीं करता है। लेकिन यह हमारी समस्या है और हमें इसे ठीक करना होगा. यहां कुछ भी मौलिक नहीं है. चलो यह करते हैं*।

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

* पहले से ही उपयोग कर रहा है; वादे के मुताबिक सब कुछ तय हो गया.

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

और इसका एक ही समाधान है. अगर आपने एपीआई ओपन किया है तो आपको उसे कट करना होगा. उदाहरण के लिए, कुछ कोटा दर्ज करने के लिए. कोई अन्य उचित विकल्प नहीं हैं. अन्यथा, वे तुरंत एक स्क्रिप्ट लिख देंगे और समस्याएं होंगी।

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

अब एक और दिलचस्प बात. यह मैन्युअल प्रतिकृति है.

मैं ऐसे कई मामलों को जानता हूं, जहां ClickHouse में अंतर्निहित प्रतिकृति समर्थन होने के बावजूद, लोग ClickHouse को मैन्युअल रूप से दोहराते हैं।

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

और समय-समय पर आपको अभी भी मैन्युअल रूप से सिंक करना होगा। उदाहरण के लिए, महीने में एक बार व्यवस्थापक rsync करते हैं।

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

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

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

मर्जट्री तालिका में, आपको किसी दिनांक और समय की आवश्यकता नहीं है। आप अभी भी उपयोग कर सकते हैं. यदि कोई दिनांक और समय नहीं है, तो लिखें कि डिफ़ॉल्ट 2000 है। यह काम करेगा और संसाधनों की आवश्यकता नहीं होगी.

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

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

या मध्यवर्ती प्रसंस्करण के लिए छोटी मात्रा में भंडारण स्ट्राइपलॉग या टाइनीलॉग है।

यदि थोड़ी मात्रा में डेटा हो और रैम में कुछ घुमा दिया जाए तो मेमोरी का उपयोग किया जा सकता है।

ClickHouse को पुनर्सामान्यीकृत डेटा बहुत पसंद नहीं है।

यहाँ एक विशिष्ट उदाहरण है. यह यूआरएल की एक बड़ी संख्या है. आप उन्हें बगल वाली टेबल पर रख दें. और फिर हमने उनके साथ JOIN करने का निर्णय लिया, लेकिन यह एक नियम के रूप में काम नहीं करेगा, क्योंकि ClickHouse केवल हैश JOIN का समर्थन करता है। यदि कनेक्ट करने के लिए बहुत सारे डेटा के लिए पर्याप्त RAM नहीं है, तो JOIN काम नहीं करेगा*।

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

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

कुछ और उदाहरण, लेकिन मुझे पहले से ही संदेह है कि वे पैटर्न-विरोधी हैं या नहीं।

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

* बैच मोड में अपडेट और डिलीट के लिए समर्थन लंबे समय से जोड़ा गया है।

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

ClickHouse में वितरित JOINs - इसे भी क्वेरी प्लानर द्वारा खराब ढंग से नियंत्रित किया जाता है।

बुरा, लेकिन कभी-कभी ठीक भी।

चयन* के साथ डेटा को वापस पढ़ने के लिए ClickHouse का उपयोग करना।

मैं भारी गणनाओं के लिए ClickHouse का उपयोग करने की अनुशंसा नहीं करूंगा। लेकिन यह पूरी तरह सच नहीं है, क्योंकि हम पहले से ही इस सिफारिश से दूर जा रहे हैं। और हमने हाल ही में ClickHouse - Catboost में मशीन लर्निंग मॉडल लागू करने की क्षमता जोड़ी है। और यह मुझे चिंतित करता है, क्योंकि मुझे लगता है: “क्या भयावहता है। प्रति बाइट कितने चक्र निकलते हैं! बाइट्स पर घड़ी चक्र शुरू करना मेरे लिए अफ़सोस की बात है।

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

सवाल

रिपोर्ट के लिए धन्यवाद! मैं ClickHouse के क्रैश होने की शिकायत कहाँ कर सकता हूँ?

आप अभी मुझसे व्यक्तिगत रूप से शिकायत कर सकते हैं।

मैंने हाल ही में ClickHouse का उपयोग शुरू किया है। सीएलआई इंटरफ़ेस को तुरंत हटा दिया गया।

आप भाग्यशाली हैं।

थोड़ी देर बाद मैंने एक छोटे से चयन के साथ सर्वर को क्रैश कर दिया।

आपके पास प्रतिभा है।

मैंने GitHub बग खोला, लेकिन इसे नज़रअंदाज कर दिया गया।

हम देखेंगे।

एलेक्सी ने मुझे रिपोर्ट में भाग लेने के लिए धोखा दिया, यह वादा करके कि आप अंदर डेटा कैसे निचोड़ रहे हैं।

बहुत आसान है.

इसका एहसास मुझे कल हुआ. अधिक विशिष्टताएँ.

कोई भयानक चालें नहीं हैं. यह सिर्फ ब्लॉक-दर-ब्लॉक संपीड़न है। डिफ़ॉल्ट LZ4 है, आप ZSTD* सक्षम कर सकते हैं। 64 किलोबाइट से 1 मेगाबाइट तक के ब्लॉक।

* विशेष संपीड़न कोडेक्स के लिए भी समर्थन है जिसका उपयोग अन्य एल्गोरिदम के साथ श्रृंखला में किया जा सकता है।

क्या ब्लॉक सिर्फ कच्चा डेटा हैं?

बिल्कुल कच्चा नहीं. सरणियाँ हैं. यदि आपके पास एक संख्यात्मक कॉलम है, तो एक पंक्ति में संख्याएँ एक सरणी में जमा हो जाती हैं।

मैं देखता हूं।

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

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

और यदि हम अधिक आदिम डेटा प्रकार लें? उदाहरण के लिए, उन्होंने हमारे पास मौजूद उपयोगकर्ता आईडी को लिखा, इसे एक पंक्ति के रूप में लिखा, और फिर इसे डाला, क्या यह अधिक मजेदार होगा या नहीं?

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

एलेक्सी, रिपोर्ट के लिए बहुत-बहुत धन्यवाद! और ClickHouse के लिए बहुत बहुत धन्यवाद! मेरे पास योजनाओं के बारे में एक प्रश्न है. क्या शब्दकोशों को अपूर्ण रूप से अद्यतन करने की योजना में कोई सुविधा है?

यानी आंशिक रीबूट?

हां हां। जैसे वहां एक MySQL फ़ील्ड सेट करने की क्षमता, यानी बाद में अपडेट करना ताकि केवल यह डेटा लोड किया जा सके यदि शब्दकोश बहुत बड़ा है।

बहुत दिलचस्प सुविधा. और, मुझे ऐसा लगता है, किसी व्यक्ति ने हमारी चैट में इसका सुझाव दिया था। शायद यह आप भी थे.

मुझे ऐसा नहीं लगता।

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

हाँ, लेकिन दुर्भाग्य से C++ में नहीं।

क्या आपके सहकर्मी C++ में लिख सकते हैं?

मैं किसी को ढूंढ लूंगा.

महान*।

* यह सुविधा रिपोर्ट के दो महीने बाद जोड़ी गई थी - इसे प्रश्न के लेखक द्वारा विकसित किया गया था और उसके द्वारा प्रस्तुत किया गया था अनुरोध निवेदन करें.

शुक्रिया!

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

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

एलेक्सी, नमस्ते! मैं यह प्रश्न पूछना चाहूँगा. यह पहली बार नहीं है कि मैंने सुना है कि बहुत से लोग लॉग के लिए रिपॉजिटरी के रूप में ClickHouse का उपयोग करना शुरू कर रहे हैं। रिपोर्ट में आपने कहा कि ऐसा न करें यानी आपको लंबी लाइनें लगाने की जरूरत नहीं है. आप इसके बारे में क्या सोचते हैं?

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

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

क्या एक किलोबाइट सामान्य है?

यह सामान्य है

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

अभी तक नहीं। विद अनुभाग कुछ हद तक तुच्छ है। यह हमारे लिए एक छोटी सुविधा की तरह है.

मैं समझता हूँ। धन्यवाद!

रिपोर्ट के लिए धन्यवाद! बहुत ही रोचक! वैश्विक प्रश्न. क्या ऐसा करने की योजना बनाई गई है, शायद किसी प्रकार के स्टब्स के रूप में, डेटा विलोपन में संशोधन?

अनिवार्य रूप से। यह हमारी कतार में हमारा पहला कार्य है। हम अब सक्रिय रूप से इस बारे में सोच रहे हैं कि सब कुछ ठीक कैसे किया जाए। और आपको कीबोर्ड* दबाना शुरू कर देना चाहिए।

*कीबोर्ड पर बटन दबाए और सब कुछ हो गया।

क्या यह किसी तरह सिस्टम प्रदर्शन को प्रभावित करेगा या नहीं? क्या इन्सर्ट उतना तेज़ होगा जितना अभी है?

शायद डिलीट स्वयं, अपडेट स्वयं बहुत भारी होंगे, लेकिन यह किसी भी तरह से चयन के प्रदर्शन और आवेषण के प्रदर्शन को प्रभावित नहीं करेगा।

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

हां.

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

हां.

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

ठीक बहुत - बहुत धन्यवाद!

स्रोत: www.habr.com