ELK, Big Query र TimescaleDB को प्रतिस्थापनको रूपमा Clickhouse प्रयोग गर्दै

क्लिकहाउस Yandex द्वारा सिर्जना गरिएको अनलाइन विश्लेषणात्मक क्वेरी प्रशोधन (OLAP) को लागि खुला स्रोत स्तम्भ डेटाबेस व्यवस्थापन प्रणाली हो। यो Yandex, CloudFlare, VK.com, Badoo र विश्वभरका अन्य सेवाहरूद्वारा साँच्चै ठूलो मात्रामा डाटा भण्डारण गर्न प्रयोग गरिन्छ (प्रति सेकेन्ड हजारौं पङ्क्तिहरू वा डिस्कमा भण्डार गरिएको डाटाको पेटाबाइटहरू)।

सामान्य, "स्ट्रिङ" DBMS मा, जसका उदाहरणहरू MySQL, Postgres, MS SQL Server हुन्, डाटा यस क्रममा भण्डारण गरिन्छ:

यस अवस्थामा, एक पङ्क्तिसँग सम्बन्धित मानहरू भौतिक रूपमा छेउमा भण्डार गरिएको छ। स्तम्भ DBMS मा, विभिन्न स्तम्भहरूबाट मानहरू अलग-अलग भण्डारण गरिन्छ, र एक स्तम्भको डेटा सँगै भण्डारण गरिन्छ:

स्तम्भ DBMS का उदाहरणहरू Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, kb+ Druid, हुन्।

कम्पनी एक मेल फर्वार्डर हो क्विन्ट्री मैले रिपोर्टिङको लागि 2018 मा क्लिकहाउस प्रयोग गर्न थालें र यसको सरलता, स्केलेबिलिटी, SQL समर्थन, र गतिबाट धेरै प्रभावित भएँ। यस DBMS को गति जादू मा सीमाना छ।

सरलता

क्लिकहाउस एकल आदेशको साथ Ubuntu मा स्थापना गर्दछ। यदि तपाइँ SQL थाहा छ भने, तपाइँ तुरुन्तै तपाइँको आवश्यकताहरु को लागी Clickhouse को उपयोग गर्न को लागी सुरु गर्न सक्नुहुन्छ। यद्यपि, यसको मतलब यो होइन कि तपाइँ MySQL मा "सिर्जना तालिका देखाउन" र Clickhouse मा SQL प्रतिलिपि गर्न सक्नुहुन्छ।

MySQL को तुलनामा, यस DBMS मा तालिका स्कीमा परिभाषाहरूमा महत्त्वपूर्ण डेटा प्रकार भिन्नताहरू छन्, त्यसैले तपाईंलाई अझै पनि तालिका स्किमा परिभाषाहरू परिवर्तन गर्न र सहज हुनको लागि तालिका इन्जिनहरू सिक्न केही समय चाहिन्छ।

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

उत्पादकता

• बेन्चमार्क कन्फिगरेसन सर्भरमा क्लिकहाउस बनाम Vertica र MySQL तुलनाहरू: दुई सकेट Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 8 6TB SATA HDD, ext4 मा।
• बेन्चमार्क Amazon RedShift क्लाउड भण्डारणको साथ Clickhouse को तुलना।
• ब्लग अंशहरू क्लिकहाउस प्रदर्शनको बारेमा क्लाउडफ्लेयर:

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

ClickHouse ले काफ्काबाट सीधै डाटा प्राप्त गर्न समर्थन गर्दैन, किनकि यो केवल एक डाटाबेस हो, त्यसैले हामीले Go मा हाम्रो आफ्नै एडाप्टर सेवा लेख्यौं। यसले काफ्काबाट आएको Cap'n Proto सङ्केतित सन्देशहरू पढ्यो, तिनीहरूलाई TSV मा रूपान्तरण गर्‍यो, र HTTP इन्टरफेस मार्फत ब्याचहरूमा क्लिकहाउसमा सम्मिलित गर्‍यो। हामीले कार्यसम्पादन सुधार गर्न हाम्रो आफ्नै ClickHouse इन्टरफेससँग संयोजनमा Go लाइब्रेरी प्रयोग गर्न यो सेवालाई पछि लेख्यौं। प्याकेटहरू प्राप्त गर्ने कार्यसम्पादनको मूल्याङ्कन गर्दा, हामीले एउटा महत्त्वपूर्ण कुरा पत्ता लगायौं - यो पत्ता लाग्यो कि क्लिकहाउसको लागि यो कार्यसम्पादन प्याकेटको साइजमा निर्भर गर्दछ, अर्थात्, एकै समयमा सम्मिलित पङ्क्तिहरूको संख्या। यो किन हुन्छ भनेर बुझ्नको लागि, हामीले क्लिकहाउसले डाटा कसरी भण्डारण गर्छ भन्ने अध्ययन गर्यौं।

मुख्य इन्जिन, वा बरु, डाटा भण्डारणको लागि ClickHouse द्वारा प्रयोग गरिएको टेबल इन्जिनहरूको परिवार, MergeTree हो। यो इन्जिन अवधारणात्मक रूपमा Google BigTable वा Apache Cassandra मा प्रयोग गरिएको LSM एल्गोरिथ्मसँग मिल्दोजुल्दो छ, तर मध्यवर्ती मेमोरी तालिका निर्माण गर्नबाट बच्न र सीधै डिस्कमा डाटा लेख्छ। यसले यसलाई उत्कृष्ट लेखन थ्रुपुट दिन्छ, किनकि प्रत्येक सम्मिलित प्याकेटलाई "प्राथमिक कुञ्जी" प्राथमिक कुञ्जी द्वारा मात्र क्रमबद्ध गरिएको छ, संकुचित गरिएको छ, र खण्ड बनाउनको लागि डिस्कमा लेखिएको छ।

मेमोरी तालिकाको अनुपस्थिति वा डेटाको "ताजगी" को कुनै अवधारणाको मतलब यो पनि हो कि तिनीहरू मात्र थप्न सकिन्छ, प्रणालीले परिवर्तन वा मेटाउन समर्थन गर्दैन। आजको रूपमा, डेटा मेटाउने एक मात्र तरिका भनेको यसलाई क्यालेन्डर महिना अनुसार मेटाउनु हो, किनकि खण्डहरू कहिले पनि महिनाको सीमा पार गर्दैनन्। ClickHouse टोली सक्रिय रूपमा यस सुविधालाई अनुकूलन योग्य बनाउन काम गरिरहेको छ। अर्कोतर्फ, यसले लेखन र मर्ज खण्डहरूलाई विवादरहित बनाउँछ, त्यसैले I/O वा कोरहरू सन्तुलित नभएसम्म समानान्तर इन्सर्टहरूको संख्यासँग थ्रुपुट स्केलहरू प्राप्त गर्नुहोस्।
यद्यपि, यो परिस्थितिको अर्थ यो पनि हो कि प्रणाली साना प्याकेटहरूको लागि उपयुक्त छैन, त्यसैले काफ्का सेवाहरू र इन्सर्टरहरू बफरिङका लागि प्रयोग गरिन्छ। थप रूपमा, पृष्ठभूमिमा क्लिकहाउसले खण्डहरूलाई निरन्तर मर्ज गर्न जारी राख्छ, ताकि धेरै साना जानकारीहरू जोडिनेछ र धेरै पटक रेकर्ड गरिनेछ, जसले गर्दा रेकर्डिङ तीव्रता बढ्छ। यद्यपि, धेरै धेरै असंबद्ध भागहरूले मर्ज जारी रहँदा सम्म सम्मिलितहरूको आक्रामक थ्रॉटलिंग निम्त्याउनेछ। हामीले फेला पारेका छौं कि वास्तविक-समय डेटा इन्जेसन र इन्जेसन कार्यसम्पादन बीचको उत्तम सम्झौता तालिकामा प्रति सेकेन्ड सम्मिलितहरूको सीमित संख्या स्वीकार गर्नु हो।

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

सबै स्तम्भहरू "प्राथमिक कुञ्जी" द्वारा क्रमबद्ध गरिएका छन् भन्ने कुरालाई ध्यानमा राखी, अनुक्रमणिका फाइलले धेरै ठूला तालिकाहरूको लागि पनि मेमोरीमा राख्न सक्षम हुनको लागि प्रत्येक Nth पङ्क्तिको लेबलहरू (क्याप्चर गरिएका पङ्क्तिहरू) मात्र समावेश गर्दछ। उदाहरणका लागि, तपाईंले पूर्वनिर्धारित सेटिङहरूलाई "प्रत्येक 8192 औं पङ्क्तिमा चिन्ह लगाउनुहोस्", त्यसपछि 1 ट्रिलियन भएको तालिकाको "कम" अनुक्रमणिका सेट गर्न सक्नुहुन्छ। मेमोरीमा सजिलैसँग फिट हुने रेखाहरूले मात्र 122 क्यारेक्टरहरू लिन्छन्।

प्रणाली विकास

Clickhouse को विकास र सुधार मा ट्रेस गर्न सकिन्छ Github रेपो र सुनिश्चित गर्नुहोस् कि "बढ्दो" को प्रक्रिया एक प्रभावशाली गतिमा भइरहेको छ।

लोकप्रियता

यस्तो देखिन्छ कि क्लिकहाउसको लोकप्रियता तीव्र रूपमा बढिरहेको छ, विशेष गरी रूसी भाषा बोल्ने समुदायमा। गत वर्षको उच्च लोड 2018 सम्मेलन (मस्को, नोभेम्बर 8-9, 2018) ले देखायो कि vk.com र Badoo जस्ता राक्षसहरूले क्लिकहाउस प्रयोग गर्छन्, जसले एकै साथ हजारौं सर्भरहरूबाट डाटा (उदाहरणका लागि, लगहरू) सम्मिलित गर्दछ। ४० मिनेटको भिडियोमा VKontakte टोलीबाट युरी Nasretdinov यो कसरी भयो भन्ने बारे कुरा गर्छ। सामग्रीसँग काम गर्ने सुविधाको लागि हामी छिट्टै हाबरमा ट्रान्सक्रिप्ट पोस्ट गर्नेछौं।

अनुप्रयोगहरू

अनुसन्धानमा केही समय बिताएपछि, मलाई लाग्छ कि त्यहाँ क्षेत्रहरू छन् जहाँ क्लिकहाउस उपयोगी हुन सक्छ वा पूर्ण रूपमा अन्य परम्परागत र लोकप्रिय समाधानहरू जस्तै MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot र प्रतिस्थापन गर्न सक्षम हुन सक्छ। ड्रुइड। माथिको DBMS अपग्रेड वा पूर्ण रूपमा प्रतिस्थापन गर्न ClickHouse प्रयोग गर्ने विवरणहरू निम्न छन्।

MySQL र PostgreSQL विस्तार गर्दै

भर्खरै, हामीले आंशिक रूपमा MySQL लाई न्यूजलेटर प्लेटफर्मको लागि ClickHouse को साथ बदल्यौं मौटिक न्यूजलेटर। समस्या यो थियो कि MySQL ले एउटा ठुलो MySQL तालिका (email_stats) सिर्जना गरी पठाइएको प्रत्येक इमेल र त्यस इमेलको प्रत्येक लिङ्कलाई बेस64 ह्यासको साथ लगाइयो। सेवाका सदस्यहरूलाई मात्र 10 मिलियन इमेलहरू पठाएपछि, यो तालिकाले 150 GB फाइल ठाउँ ओगटेको छ, र MySQL ले साधारण प्रश्नहरूमा "मूर्ख" हुन थाल्यो। फाइल स्पेस समस्या समाधान गर्न, हामीले सफलतापूर्वक InnoDB टेबल कम्प्रेसन प्रयोग गर्यौं, जसले यसलाई 4 को कारकले घटाएको छ। यद्यपि, इतिहास पढ्नको लागि मात्र MySQL मा 20-30 मिलियन भन्दा बढी इमेलहरू भण्डारण गर्नुको कुनै अर्थ छैन, कुनै पनि कारणले गर्दा स्वैप र भारी I/O मा पूर्ण स्क्यान परिणामहरू गर्नु पर्ने कुनै पनि साधारण प्रश्नको रूपमा। ओभरहेड, जसको बारेमा हामीले नियमित रूपमा Zabbix चेतावनीहरू प्राप्त गर्यौं।

क्लिकहाउसले दुई कम्प्रेसन एल्गोरिदमहरू प्रयोग गर्दछ जसले डाटाको मात्रा लगभग घटाउँछ 3-4 पटक, तर यस विशेष अवस्थामा, डाटा विशेष गरी "संकुचित" थियो।

ELK प्रतिस्थापन

मेरो आफ्नै अनुभवको आधारमा, ELK स्ट्याक (ElasticSearch, Logstash र Kibana, यो विशेष अवस्थामा ElasticSearch) लाई लगहरू भण्डारण गर्न आवश्यक भन्दा धेरै संसाधनहरू चलाउन आवश्यक छ। इलास्टिकसर्च एक उत्कृष्ट इन्जिन हो यदि तपाई राम्रो पूर्ण-पाठ लग खोज चाहनुहुन्छ (जुन मलाई तपाईलाई वास्तवमै आवश्यक छ जस्तो लाग्दैन), तर म सोच्दै छु किन यो वास्तविक मानक लगिङ इन्जिन भएको छ। यसको इन्जेसन कार्यसम्पादन, Logstash सँग मिलाएर, हामीलाई एकदम हल्का वर्कलोडहरूमा पनि समस्याहरू दियो र थप र अधिक RAM र डिस्क ठाउँ थप्न आवश्यक छ। डाटाबेसको रूपमा, Clickhouse निम्न कारणहरूको लागि ElasticSearch भन्दा राम्रो छ:

• SQL बोली समर्थन;
• भण्डारण डाटा को कम्प्रेसन को सबै भन्दा राम्रो डिग्री;
• पूर्ण पाठ खोजको सट्टा Regex खोजको लागि समर्थन;
• सुधारिएको क्वेरी तालिका र राम्रो समग्र प्रदर्शन।

हाल, ELK सँग ClickHouse तुलना गर्दा उत्पन्न हुने सबैभन्दा ठूलो समस्या लगहरू अपलोड गर्नका लागि समाधानको अभाव, साथै यस विषयमा कागजात र ट्यूटोरियलहरूको अभाव हो। एकै समयमा, प्रत्येक प्रयोगकर्ताले डिजिटल महासागर म्यानुअल प्रयोग गरेर ELK सेट अप गर्न सक्छ, जुन त्यस्ता प्रविधिहरूको द्रुत कार्यान्वयनको लागि धेरै महत्त्वपूर्ण छ। यहाँ डाटाबेस इन्जिन छ, तर ClickHouse को लागि अझै Filebeat छैन। हो त्यहाँ छ प्रवाहित र लगहरूसँग काम गर्ने प्रणाली लग घर, त्यहाँ एक उपकरण छ पुच्छर क्लिक गर्नुहोस् ClickHouse मा लग फाइल डाटा प्रविष्ट गर्न, तर यो सबै थप समय लाग्छ। यद्यपि, ClickHouse अझै पनि यसको सरलताको कारणले बाटोमा नेतृत्व गर्दछ, त्यसैले शुरुआतीहरूले पनि यसलाई सजिलैसँग स्थापना गर्न सक्छन् र केवल 10 मिनेटमा पूर्ण रूपमा कार्यात्मक प्रयोग सुरु गर्न सक्छन्।

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

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

Google Big Query र Amazon RedShift को प्रतिस्थापन (ठूला कम्पनीहरूको लागि समाधान)

BigQuery को लागि आदर्श प्रयोग केस JSON डेटाको 1TB लोड गर्नु र त्यसमा विश्लेषणात्मक प्रश्नहरू चलाउनु हो। Big Query एउटा उत्कृष्ट उत्पादन हो जसको स्केलेबिलिटी बढी अनुमान गर्न गाह्रो छ। यो आन्तरिक क्लस्टरमा चलिरहेको ClickHouse भन्दा धेरै जटिल सफ्टवेयर हो, तर ग्राहकको दृष्टिकोणबाट, यसमा ClickHouse सँग धेरै समानता छ। तपाईंले प्रत्येक SELECT को लागि भुक्तान गर्न थाल्नुभयो भने BigQuery ले द्रुत रूपमा "मूल्य बढाउन" सक्छ, त्यसैले यो यसको सबै फाइदा र बेफाइदाहरू सहितको वास्तविक SaaS समाधान हो।

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

Altinity को सह-संस्थापक अलेक्जेन्डर Zaitsev द्वारा एक लेखमा "क्लिकहाउसमा सर्दै" यस्तो DBMS माइग्रेसनका फाइदाहरू वर्णन गर्दछ।

TimescaleDB प्रतिस्थापन

TimescaleDB एक PostgreSQL एक्स्टेन्सन हो जसले नियमित डेटाबेसमा टाइम्सरीहरूसँग काम गर्ने अनुकूलन गर्दछ (https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

यद्यपि ClickHouse समय शृङ्खलाको स्थानमा गम्भीर प्रतियोगी होइन, तर स्तम्भ संरचना र भेक्टर क्वेरी कार्यान्वयनको सन्दर्भमा, विश्लेषणात्मक प्रश्नहरू प्रशोधन गर्ने अधिकांश अवस्थामा यो TimescaleDB भन्दा धेरै छिटो छ। एकै समयमा, क्लिकहाउस प्याकेट डाटा प्राप्त गर्ने कार्यसम्पादन लगभग 3 गुणा बढी छ, साथै, यसले 20 गुणा कम डिस्क स्पेस प्रयोग गर्दछ, जुन ऐतिहासिक डाटाको ठूलो मात्रा प्रशोधन गर्नको लागि वास्तवमै महत्त्वपूर्ण छ: 
https://www.altinity.com/blog/ClickHouse-for-time-series.

ClickHouse को विपरीत, TimescaleDB मा केहि डिस्क स्पेस बचत गर्ने एकमात्र तरिका ZFS वा समान फाइल प्रणालीहरू प्रयोग गर्नु हो।

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

• धेरै थोरै र्याम (<3 GB) संग सानो स्थापनाहरू;
• ठूलो संख्यामा साना INSERT हरू जुन तपाईं ठूला टुक्राहरूमा बफर गर्न चाहनुहुन्न;
• राम्रो स्थिरता, एकरूपता र ACID आवश्यकताहरू;
• PostGIS समर्थन;
• अवस्थित PostgreSQL तालिकाहरूसँग मर्ज गर्नुहोस्, किनकि Timescale DB अनिवार्य रूपमा PostgreSQL हो।

Hadoop र MapReduce प्रणाली संग प्रतिस्पर्धा

Hadoop र अन्य MapReduce उत्पादनहरूले धेरै जटिल गणनाहरू गर्न सक्छन्, तर तिनीहरू ठूलो विलम्बतामा चल्ने प्रवृत्ति हुन्छन्। ClickHouse ले यो समस्यालाई टेराबाइट डाटाको प्रशोधन गरेर र लगभग तुरुन्तै परिणामहरू उत्पादन गरेर समाधान गर्छ। तसर्थ, क्लिकहाउस छिटो, अन्तरक्रियात्मक विश्लेषणात्मक अनुसन्धान गर्नको लागि धेरै कुशल छ, जुन डाटा वैज्ञानिकहरूको लागि चासोको हुनुपर्छ।

Pinot र Druid संग प्रतिस्पर्धा

ClickHouse का निकटतम प्रतियोगीहरू स्तम्भ, रैखिक रूपमा मापनयोग्य खुला स्रोत उत्पादनहरू Pinot र Druid हुन्। यी प्रणालीहरू तुलना गर्ने उत्कृष्ट काम लेखमा प्रकाशित गरिएको छ रोमाना लेभेन्टोवा फेब्रुअरी 1, 2018

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

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

Druid र Pinot Apache इन्क्युबेटर परियोजनाहरू हुन्, जसलाई Apache द्वारा तिनीहरूको GitHub परियोजना पृष्ठहरूमा विस्तृत रूपमा कभर गरिएको छ। पिनोट अक्टोबर २०१८ मा इन्क्युबेटरमा देखा परेको थियो र ड्रुइडको जन्म ८ महिना अघि फेब्रुअरीमा भएको थियो।

AFS ले कसरी काम गर्छ भन्ने बारे जानकारीको अभावले मेरो लागि केही, र सायद मूर्ख प्रश्नहरू खडा गर्छ। मलाई आश्चर्य छ कि पिनोटका लेखकहरूले Apache फाउन्डेशन ड्रुइडप्रति बढी डिस्पोज गरेको याद गरे, र के प्रतियोगीप्रतिको यस्तो मनोवृत्तिले ईर्ष्याको भावना पैदा गर्छ? के Druid को विकास सुस्त हुनेछ र पिनोट को विकास को गति मा पहिले को समर्थन गर्ने प्रायोजकहरु अचानक पछि चासो राख्छन्?

क्लिकहाउसका बेफाइदाहरू

अपरिपक्वता: जाहिर छ, यो अझै पनि बोरिंग टेक्नोलोजी हो, तर कुनै पनि अवस्थामा, अन्य स्तम्भ DBMS मा यस्तो केहि देखिदैन।

साना इन्सर्टहरूले उच्च गतिमा राम्रो प्रदर्शन गर्दैनन्: इन्सर्टहरूलाई ठूला टुक्राहरूमा विभाजन गरिनुपर्छ किनभने प्रत्येक पङ्क्तिमा स्तम्भहरूको संख्याको अनुपातमा साना इन्सर्टहरूको कार्यसम्पादन घट्छ। यसरी क्लिकहाउसले डिस्कमा डाटा भण्डारण गर्छ - प्रत्येक स्तम्भको अर्थ 1 फाइल वा बढी हुन्छ, त्यसैले 1 स्तम्भहरू भएको 100 पङ्क्ति सम्मिलित गर्न, तपाईंले कम्तिमा 100 फाइलहरू खोल्न र लेख्नुपर्छ। यसैले इन्सर्ट बफरिङलाई मध्यस्थकर्ता चाहिन्छ (जबसम्म ग्राहक आफैले बफरिङ प्रदान गर्दैन) - सामान्यतया काफ्का वा कुनै प्रकारको लाइनिङ प्रणाली। तपाईले बफर टेबल इन्जिन प्रयोग गर्न सक्नुहुनेछ पछि डेटाको ठूला टुक्राहरूलाई MergeTree तालिकाहरूमा प्रतिलिपि गर्न।

तालिका जोड्नेहरू सर्भर RAM द्वारा सीमित छन्, तर कम्तिमा तिनीहरू त्यहाँ छन्! उदाहरणका लागि, Druid र Pinot सँग त्यस्ता जडानहरू छैनन्, किनकि तिनीहरू नोडहरू बीच डाटाको ठूलो भाग सार्न समर्थन नगर्ने वितरित प्रणालीहरूमा प्रत्यक्ष रूपमा कार्यान्वयन गर्न गाह्रो हुन्छन्।

निष्कर्ष

आगामी वर्षहरूमा, हामी Qwintry मा ClickHouse को व्यापक प्रयोग गर्ने योजना बनाउँछौं, किनकि यो DBMS ले प्रदर्शन, कम ओभरहेड, स्केलेबिलिटी, र सरलताको उत्कृष्ट सन्तुलन प्रदान गर्दछ। म पक्का छु कि क्लिकहाउस समुदायले यसलाई सानो र मध्यम स्थापनाहरूमा प्रयोग गर्ने थप तरिकाहरू लिएर आउँदा यो द्रुत रूपमा फैलिनेछ।

केही विज्ञापनहरू 🙂

हामीसँग रहनु भएकोमा धन्यवाद। तपाईलाई हाम्रा लेखहरू मनपर्छ? थप रोचक सामग्री हेर्न चाहनुहुन्छ? हामीलाई अर्डर गरेर वा साथीहरूलाई सिफारिस गरेर समर्थन गर्नुहोस्, $4.99 बाट विकासकर्ताहरूको लागि क्लाउड VPS, प्रविष्टि-स्तर सर्भरहरूको एक अद्वितीय एनालग, जुन हामीले तपाईंको लागि आविष्कार गरेको हो: VPS (KVM) E5-2697 v3 (6 कोर) 10GB DDR4 480GB SSD 1Gbps $ 19 बाट वा कसरी सर्भर साझा गर्ने बारे सम्पूर्ण सत्य? (RAID1 र RAID10 सँग उपलब्ध, 24 कोर सम्म र 40GB DDR4 सम्म)।

डेल R730xd 2x एम्स्टर्डमको इक्विनिक्स टियर IV डाटा सेन्टरमा सस्तो छ? यहाँ मात्र 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 बाट नेदरल्याण्ड मा! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 बाट! बारे पढ्नुहोस् पूर्वाधार कर्पोरेशन कसरी निर्माण गर्ने। डेल R730xd E5-2650 v4 सर्भरहरूको प्रयोगको साथ एक पैसाको लागि 9000 यूरो मूल्यको वर्ग?

स्रोत: www.habr.com