सोलर गैलेक्सी में Clickhouse को कैसे चुना गया

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

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

अनुरोध उदाहरण:

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

• शुद्ध पोस्टग्रेज;
  
  • Postgres + cstore_fdw;
  • Slickhouse;
  • लचीला।

पोस्टग्रैजेस बनाम इलास्टिक की तुलना

पहले चरण में, हमने Elastic and Postgres + cstore की तुलना की। पोस्टग्रेज को सबसे करीब से माना जाता था, क्योंकि यह पहले से ही सिस्टम में उपयोग किया गया था, और इसके साथ काम करने के लिए विशेषज्ञता उपलब्ध थी।

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

हालांकि, यह अपने स्वयं के आधार से बेहतर था, जिसने इलास्टिक में इस बनाम 5-6 सेकंड और पोस्टग्रेज में 15-55 सेकंड का समय लिया।

पोस्टग्रुप बनाम क्लिकहाउस तुलना

स्रोत डेटा

Https://github.com/wizardjedi/clickhouse-test के साथ हमने पोस्टग्रेज और क्लिकहाउस के साथ कंटेनर लिए। इन कंटेनरों को टेबल बनाने के लिए डिज़ाइन किया गया था।

पोस्टग्रेज के लिए टेबल व्यू:

प्राथमिक कुंजी को हटाया जाना था, क्योंकि पोस्टग्रेज़ में विदेशी तालिका इसकी अनुमति नहीं देती है।

Clickhouse के लिए, ऐसी तालिका बनाना इस प्रकार है:

Postgres के लिए cstore स्थापित करने की प्रक्रिया से खुद को परिचित करने के लिए, https://github.com/citusdata/cstore_fdw पर जाएं ।

साथ ही, cstore स्थापित करते समय, आपको postgresql-server-dev-XY पैकेज को स्थापित करने की आवश्यकता होती है

प्रदर्शन की तुलना करते समय, निम्नलिखित डेटा आकार (मेगाबाइट में) का उपयोग किया गया था:

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

यह पता चला कि क्लिकहाउस के लिए वे निश्चित रूप से नहीं बढ़े।

कम्प्यूटिंग सिस्टम पैरामीटर

निर्माता: इंटेल
पंक्ति: कोर i5
मॉडल: 8250U
घड़ी की आवृत्ति: प्रति कोर 1.60GHz
कोस: ४
रैम: 16 जीबी
एसएसडी: 256 जीबी

डेटाबेस में डेटा लोड हो रहा है

Clickhouse में डेटा की इतनी मात्रा के लिए, उन्होंने बहुत जल्दी लोड किया: 1 घंटा 40 मिनट (यह 600 मिलियन ट्यूपल्स के लिए है)।

सबसे पहले, हमने एक फ़ाइल में सब कुछ डाउनलोड करने की योजना बनाई, लेकिन "bad_alloc" त्रुटि प्रदर्शित की गई। स्पष्ट रूप से, मेमोरी आवंटित करने के लिए Clickhouse की अक्षमता के कारण। कोई हल नहीं मिला। इसलिए, 600 मिलियन ट्यूपल्स को प्रत्येक 20 मिलियन की 30 फ़ाइलों में विभाजित किया गया था। इस मामले में, प्रत्येक फ़ाइल को 3 मिनट से थोड़ा अधिक डाउनलोड किया गया था।

पोस्टग्रेज के साथ, चीजें अधिक जटिल थीं, लेकिन केवल शुरुआत में। INSERT INTO <table_name> (विशेषताएँ) युक्त कच्चे sql फ़ाइलों को डाउनलोड करना समय सारणी आदेशों का उपयोग कर रहा है। इसलिए, सब कुछ सीएसवी प्रारूप में बदल दिया गया और सीएसपी के साथ COPY <table_name> FROM कमांड को निष्पादित किया गया।

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

प्रदर्शन की तुलना

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

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

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

Clickhouse में बहुत सारी रैम होती है।

कॉन्फ़िगरेशन फ़ाइल में /etc/clickhouse/users.xml, <max_memory_usage> 12000000000 </ max_memory_usage> और <max_bytes_before_external_sage> 1000000000 </ max_btes_before_external_sort> निर्दिष्ट किए गए थे।

कुछ प्रश्नों के लिए, RAM पर्याप्त नहीं थी, यही वजह है कि हमें इसे बढ़ाना पड़ा। उसके बाद, अनुरोधों का प्रसंस्करण जारी रहा, लेकिन अंतिम अनुरोध पर यह अभी भी बाधित था। मेमोरी खपत को सीमित करने के लिए कई और पैरामीटर उपलब्ध थे https://clickhouse.yandex/docs/ru/query_language/queries/ ।

ऐसा हुआ कि हमने 600_000_000 के बजाय क्लिकहाउस: 695_640_000 ट्यूपल्स में थोड़ा और डेटा जोड़ा, लेकिन इसने उन्हें जीतने से नहीं रोका।

Cstore_fdw पर, आप विभिन्न मापदंडों को कॉन्फ़िगर कर सकते हैं https://github.com/citusdata/cstore_fdw/issues/174 , https://github.com/citusdata/cstore_fdw , जो प्रदर्शन को प्रभावित करते हैं।

विभाजन

विभाजन के लिए, यह Clickhouse https://github.com/yandex/ClickHouse/blob/master/docs/ru/table_engines/custom_partitioning_key.md , https://clickhouse.yandex/docs/ru/table_engines/custom_partitioning_key में भी है। / , और पोस्टग्रेज (10 और 11 संस्करण) में। क्लिकहाउस में विभाजन का एक उदाहरण https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00502_custom_partitioning-local.sql और https://github.com/yandex/ClickHouse/issues/1513 पर पाया जा सकता है। ।

Postgres में विभाजन का उपयोग संभव है, क्योंकि cstore केवल विदेशी तालिकाओं के साथ काम करता है, क्योंकि आपको इसके लिए एक सर्वर बनाने की आवश्यकता होती है, और आप नियमित तालिकाओं के लिए सर्वर निर्दिष्ट नहीं कर सकते। एक विदेशी तालिका को विभाजन में विभाजित नहीं किया जा सकता है, यह स्वयं विभाजन के रूप में कार्य कर सकता है। इसलिए, विभाजन का उपयोग करने का केवल एक ही संभव तरीका है: एक नियमित अभिभावक तालिका बनाएं, आप इसमें विभाजन के रूप में विदेशी तालिकाओं को संलग्न कर सकते हैं, जो पहले से ही cstore_fdw पर काम करते हैं।

क्लिकहाउस पर, विभाजन बॉक्स से बाहर काम करता है।

निष्कर्ष

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