Redshift से ClickHouse में स्विच करना

एक लंबे समय के लिए, iFunny ने Redshift का उपयोग बैकएंड सेवाओं और मोबाइल एप्लिकेशन में होने वाली घटनाओं के लिए डेटाबेस के रूप में किया। इसे इसलिए चुना गया क्योंकि कार्यान्वयन के समय, बड़े और लागत और सुविधा में तुलनीय विकल्प नहीं थे।

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

समस्या

iFunny को Yandex.Metrica के समान सेवा की आवश्यकता थी, लेकिन विशेष रूप से घरेलू खपत के लिए। मैं समझाऊंगा क्यों।

बाहरी ग्राहक ईवेंट लिखते हैं। यह मोबाइल एप्लिकेशन, वेबसाइट या आंतरिक बैकएंड सेवाएं हो सकती हैं। इन ग्राहकों के लिए यह समझाना बहुत मुश्किल है कि इवेंट रिसेप्शन सेवा वर्तमान में अनुपलब्ध है, "इसे 15 मिनट या एक घंटे में भेजने का प्रयास करें"। कई ग्राहक हैं, वे हर समय घटनाओं को भेजना चाहते हैं और बिल्कुल भी इंतजार नहीं कर सकते।

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

यदि हम संख्याओं के बारे में बात करते हैं, तो हमें SQL प्रश्नों के लिए उपलब्ध "हॉट" फॉर्म में तीन महीनों के लिए डेटा जमा करते हुए, प्रति दिन लगभग पाँच बिलियन इवेंट्स (300 GB संपीड़ित डेटा) लेने की आवश्यकता होती है, और दो साल के लिए "ठंड" में या अधिक, लेकिन इतना है कि कुछ दिनों के भीतर हम उन्हें "गर्म" में बदल सकते हैं।

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

यह पता चला है कि हमें डेटाबेस के लिए लगभग 40 टीबी डिस्क की आवश्यकता है, और "कोल्ड" स्टोरेज के लिए लगभग 250 टीबी।

Redshift समाधान

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

इसके बाद, आपको किसी तरह डेटा को Redshift तक पहुंचाना होगा। यहां सब कुछ काफी सरल है: रेडशिफ्ट में एक अंतर्निहित S3 आयातक है, जो डेटा लोड करने के लिए अनुशंसित तरीका है। इसलिए, हर 10 मिनट में एक बार एक स्क्रिप्ट शुरू होती है जो Redshift से जुड़ती है और इसे s3://events-bucket/main/year=2018/month=10/day=14/10_3* उपसर्ग का उपयोग करके डेटा डाउनलोड करने के लिए कहती है s3://events-bucket/main/year=2018/month=10/day=14/10_3*

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

उसी Airflow में, उसी तरह, शेड्यूल के अनुसार, स्क्रिप्ट काम करती है जो डेटाबेस से जुड़ती है और बाहरी रिपॉजिटरी से आवधिक डाउनलोड करती है, या INSERT INTO ... SELECT ... के रूप में घटनाओं के एकत्रीकरण का निर्माण करती है INSERT INTO ... SELECT ...

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

Redshift के तहत, 4 ds2.8xlarge इंस्टेंस का उपयोग किया गया (36 सीपीयू, 16 टीबी एचडीडी), जो कुल मिलाकर हमें 64 टीबी डिस्क स्थान देता है।

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

ClickHouse संक्रमण प्रेरणा

बेशक, अगर कोई समस्या नहीं थी, तो किसी ने भी ClickHouse के लिए पलायन करने के बारे में नहीं सोचा होगा। हालाँकि, वे थे।

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

आवश्यक अंतर, हमेशा की तरह, विवरण में है।

दैनिक तालिका

डिस्क पर डेटा छाँटना और वास्तव में इसे Redshift में हटाना तब होता है जब आप करते हैं:

 VACUUM <tablename> 

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

डुप्लिकेट

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

निगरानी और रखरखाव

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

की लागत

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

संक्रमण की प्रक्रिया

सबसे पहले, हमने एक मशीन से एक छोटा क्लिकहाउस इंस्टॉलेशन उठाया, जहां हम समय-समय पर निर्मित उपकरणों का उपयोग करके, S3 से डेटा डाउनलोड करते हैं। इस प्रकार, हम ClickHouse की गति और क्षमताओं के बारे में हमारी धारणाओं का परीक्षण करने में सक्षम थे।

डेटा की एक छोटी प्रति पर परीक्षण के कुछ हफ़्ते के बाद, यह स्पष्ट हो गया कि क्लिकहाउस के साथ Redshift को बदलने के लिए, कई मुद्दों को हल करना होगा:

• किस प्रकार के उदाहरणों और तैनाती के लिए डिस्क पर;
• प्रतिकृति का उपयोग करने के लिए?
• कैसे स्थापित करें, कॉन्फ़िगर करें और चलाएं;
• निगरानी कैसे करें;
• कौन सी योजना होगी;
• S3 से डेटा कैसे वितरित करें;
• मानक एसक्यूएल से गैर-मानक तक सभी प्रश्नों को कैसे फिर से लिखना है?

उदाहरणों और डिस्क के प्रकार । प्रोसेसर, डिस्क और मेमोरी की संख्या में, उन्होंने रेडशिफ्ट की वर्तमान स्थापना पर निर्माण करने का निर्णय लिया। स्थानीय NVMe- डिस्क के साथ i3- इंस्टेंस सहित कई विकल्प थे, लेकिन प्रत्येक उदाहरण के लिए 8T ST1 EBS के रूप में r5.4xlarge और भंडारण पर रोक लगाने का फैसला किया। अनुमान के मुताबिक, इसमें आधी लागत के लिए रेडशिफ्ट के साथ तुलनीय प्रदर्शन करना चाहिए था। इसी समय, ईबीएस डिस्क के उपयोग के कारण, हमें सरल बैकअप और डिस्क के स्नैपशॉट के माध्यम से पुनर्प्राप्ति मिलती है, लगभग रेडशिफ्ट की तरह।

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

स्थापना। यह सबसे आसान हिस्सा है। Ansible के लिए एक छोटी सी पर्याप्त भूमिका, जो तैयार किए गए RPM पैकेजों को स्थापित करेगी और प्रत्येक होस्ट पर समान कॉन्फ़िगरेशन बनाएगी।

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

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

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

S3 से ClickHouse में डेटा की डिलीवरी । यह सबसे लंबी प्रक्रियाओं में से एक थी। यह केवल अंतर्निहित ClickHouse टूल द्वारा लोडिंग बनाने में काम नहीं करता है, क्योंकि S3 पर डेटा JSON में है, प्रत्येक फ़ील्ड को अपने स्वयं के jsonpath में निकालने की आवश्यकता होती है, जैसा कि हमने Redshift में किया था, और कभी-कभी रूपांतरण का उपयोग करने की भी आवश्यकता होती है: उदाहरण के लिए, DD96C92F-3F4D-44C6-BCD3-E25EB26389E9 में मानक रिकॉर्ड से एक संदेश का UUID। DD96C92F-3F4D-44C6-BCD3-E25EB26389E9 बाइट में परिवर्तित होते हैं और फिक्स्डस्ट्रिंग (16) टाइप में डालते हैं।

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

बाहरी स्रोतों से डेटा आयात करने में कोई बड़ी समस्या नहीं थी। उन लिपियों में, जो उन्होंने Redshift से ClickHouse के गंतव्य को बदल दिया था।

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

 <dictionaries> <dictionary> <name>geoip_asn_blocks_ipv4</name> <source> <file> <path>GeoLite2-ASN-Blocks-IPv4.csv</path> <format>CSVWithNames</format> </file> <\/source> <lifetime>300</lifetime> <layout> <ip_trie /> </layout> <structure> <key> <attribute> <name>prefix</name> <type>String</type> </attribute> </key> <attribute> <name>autonomous_system_number</name> <type>UInt32</type> <null_value>0</null_value> </attribute> <attribute> <name>autonomous_system_organization</name> <type>String</type> <null_value>?</null_value> </attribute> </structure> </dictionary> </dictionaries> 

इस कॉन्‍फ़‍िगरेशन को /etc/clickhouse-server/geoip_asn_blocks_ipv4_dictionary.xml में डालने के लिए पर्याप्‍त है, जिसके बाद आप आईपी पते पर प्रदाता का नाम पाने के लिए डिक्शनरी में प्रश्‍न कर सकते हैं:

 SELECT dictGetString('geoip_asn_blocks_ipv4', 'autonomous_system_organization', tuple(IPv4StringToNum('192.168.1.1'))); 

डेटा स्कीमा बदलें । जैसा कि ऊपर उल्लेख किया गया है, हमने अभी तक प्रतिकृति का उपयोग नहीं करने का फैसला किया है, क्योंकि अब हम दुर्घटनाओं या नियोजित कार्य के मामले में दुर्गम होने का जोखिम उठा सकते हैं, और डेटा की एक प्रतिलिपि पहले से ही s3 पर है और हम इसे उचित समय पर ClickHouse में स्थानांतरित कर सकते हैं। यदि कोई प्रतिकृति नहीं है, तो उन्होंने चिड़ियाघरकीपर का विस्तार नहीं किया, और चिड़ियाघरकीपर की अनुपस्थिति भी DDL प्रश्नों में ON CLUSTER अभिव्यक्ति का उपयोग करने में असमर्थता का कारण बनती है। यह समस्या एक छोटी अजगर स्क्रिप्ट द्वारा हल की गई थी जो प्रत्येक ClickHouse होस्ट से कनेक्ट होती है (अब तक उनमें से केवल आठ हैं) और निर्दिष्ट SQL क्वेरी को निष्पादित करता है।

ClickHouse में अधूरा SQL सपोर्ट । Redshift सिंटैक्स से ClickHouse सिंटैक्स में अनुरोधों को स्थानांतरित करने की प्रक्रिया आयातक के विकास के साथ समानांतर में चली गई, और यह मुख्य रूप से विश्लेषकों की एक टीम द्वारा निपटा गया था। अजीब तरह से पर्याप्त है, लेकिन यह मामला जोइन में भी नहीं था, लेकिन खिड़की के कार्यों में। यह समझने के लिए कि उन्हें सरणियों और लैम्ब्डा कार्यों के माध्यम से कैसे किया जा सकता है, इसमें कई दिन लगे। यह अच्छा है कि यह मुद्दा अक्सर ClickHouse के बारे में रिपोर्टों में शामिल है, जिनमें से एक बड़ी संख्या है, उदाहरण के लिए, event.yandex.ru/lib/talks/5420 । इस बिंदु पर, डेटा पहले से ही दो स्थानों पर एक बार लिखा गया था: दोनों Redshift में और नए ClickHouse में, इसलिए जब हमने अनुरोध स्थानांतरित किया, तो हमने परिणामों की तुलना की। गति की तुलना करना समस्याग्रस्त था, क्योंकि हमने संपत्तियों के एक बड़े स्तंभ को हटा दिया था, और अधिकांश प्रश्न केवल आवश्यक स्तंभों के साथ काम करना शुरू कर दिए थे, जिन्होंने निश्चित रूप से एक महत्वपूर्ण वृद्धि दी थी, लेकिन उन प्रश्नों में जहां गुण स्तंभ ने भाग नहीं लिया था, उसी तरह काम किया, या थोड़ा तेज।

परिणामस्वरूप, हमें निम्नलिखित योजना मिली:

परिणाम

नीचे की पंक्ति में, हमें निम्नलिखित लाभ मिले:

• 90 की बजाय एक टेबल
• सेवा अनुरोधों को मिलीसेकंड में निष्पादित किया जाता है
• लागत आधी हो गई है
• डुप्लिकेट घटनाओं को आसानी से हटाना

ऐसे नुकसान भी हैं जिनके लिए हम तैयार हैं:

• दुर्घटना की स्थिति में, आपको स्वयं क्लस्टर को सुधारना होगा
• स्कीमा परिवर्तन अब प्रत्येक होस्ट पर अलग से किए जाने की आवश्यकता है
• नए संस्करणों के लिए अद्यतन इसे स्वयं करना होगा

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

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