ELK, बिग क्वेरी और TimescaleDB के प्रतिस्थापन के रूप में Clickhouse का उपयोग करना

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

सामान्य "स्ट्रिंग" DBMS में, जिनमें से उदाहरण MySQL, Postgres, MS SQL Server हैं, डेटा इस क्रम में संग्रहीत है:



इस स्थिति में, एक पंक्ति से संबंधित मान भौतिक रूप से संग्रहीत होते हैं। एक स्तंभ DBMS में, अलग-अलग कॉलम के मान अलग-अलग संग्रहीत किए जाते हैं, और एक कॉलम का डेटा एक साथ संग्रहीत किया जाता है:



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

मेल- फ़ॉरवर्डिंग कंपनी क्विंट्री ने 2018 में रिपोर्टिंग के लिए Clickhouse का उपयोग शुरू किया और इसकी सादगी, स्केलेबिलिटी, SQL समर्थन और गति से बहुत प्रभावित हुई। इस डीबीएमएस की गति जादू से सीमाबद्ध थी।

आराम

एक एकल आदेश के साथ क्लिकहाउस उबंटू पर स्थापित होता है। यदि आप SQL जानते हैं, तो आप तुरंत अपनी आवश्यकताओं के लिए Clickhouse का उपयोग शुरू कर सकते हैं। हालांकि, इसका मतलब यह नहीं है कि आप MySQL में "शो क्रिएट टेबल" चला सकते हैं और क्लिकहाउस में SQL को कॉपी-पेस्ट कर सकते हैं।

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

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

उत्पादकता

• एक कॉन्फ़िगरेशन सर्वर पर वर्टिका और MySQL के साथ क्लिकहाउस की तुलना बेंचमार्क : दो Intel® Xeon® CPU सॉकेट E5-2650 v2 @ 2.60GHz; 128 GiB RAM; 8 6TB SATA HDD पर md RAID -5, ext4।
• बेंचमार्क अमेजन रेडशिफ्ट क्लाउड डेटा स्टोरेज के साथ क्लिकहाउस की तुलना करता है।
• Cloudflare Clickhouse प्रदर्शन ब्लॉग के कुछ अंश:

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

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

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

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

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

यह देखते हुए कि सभी कॉलम "प्राथमिक कुंजी" द्वारा सॉर्ट किए जाते हैं, इंडेक्स फ़ाइल में प्रत्येक Nth पंक्ति के केवल लेबल (कैप्चर की गई पंक्तियाँ) होती हैं, ताकि वे बहुत बड़ी टेबल के लिए भी मेमोरी में स्टोर करने में सक्षम हों। उदाहरण के लिए, आप डिफ़ॉल्ट सेटिंग्स "हर 8192 वीं पंक्ति को चिह्नित" कर सकते हैं, फिर 1 ट्रिलियन के साथ "मेजर" की तालिका का अनुक्रमण। लाइनें, जो आसानी से मेमोरी में फिट हो जाती हैं, केवल 122,070 वर्णों पर कब्जा कर लेंगी।

सिस्टम का विकास

क्लिकहाउस के विकास और सुधार को गिथब रेपो से पता लगाया जा सकता है और सुनिश्चित करें कि "बड़े होने" की प्रक्रिया एक प्रभावशाली गति से आगे बढ़ रही है।

लोकप्रियता

क्लिकहाउस तेजी से बढ़ रहा है, खासकर रूसी भाषी समुदाय में। पिछले साल के सम्मेलन हाई लोड 2018 (मॉस्को, नवंबर 8--9, 2018) से पता चला है कि vk.com और Badoo जैसे राक्षस Clickhouse का उपयोग करते हैं, जिसके साथ वे एक ही समय में दसियों हज़ार सर्वरों से डेटा (उदाहरण के लिए, लॉग) पेस्ट करते हैं। 40-मिनट के वीडियो में, VKontakte टीम के यूरी नसेरेतिनोव इस बारे में बात करते हैं कि यह कैसे किया जाता है । जल्द ही हम सामग्री के साथ काम करने की सुविधा के लिए हैबर पर प्रतिलेख पोस्ट करेंगे।

आवेदन क्षेत्रों

कुछ समय शोध करने के बाद, मुझे लगता है कि ऐसे क्षेत्र हैं जिनमें ClickHouse उपयोगी हो सकता है या अन्य, अधिक पारंपरिक और लोकप्रिय समाधानों को बदलने में सक्षम हो सकता है, जैसे कि MySQL, PostgreSQL, ELK, Google बिग क्वेरी, अमेज़न RedShift। TimescaleDB, Hadoop, MapReduce, Pinot और Druid। उपरोक्त DBMS को अपग्रेड या पूरी तरह से बदलने के लिए ClickHouse का उपयोग करने के विवरण निम्नलिखित हैं।

MySQL और PostgreSQL का विस्तार

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



Clickhouse दो संपीड़न एल्गोरिदम का उपयोग करता है जो डेटा की मात्रा को लगभग 3-4 गुना कम कर देता है , लेकिन इस विशेष मामले में डेटा विशेष रूप से "संपीड़ित" था।

ELK रिप्लेसमेंट

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

• SQL बोली समर्थन;
• संग्रहीत डेटा का सबसे अच्छा संपीड़न अनुपात;
• पूर्ण-पाठ खोजों के बजाय रेगेक्स नियमित अभिव्यक्ति खोजों के लिए समर्थन;
• बेहतर क्वेरी योजना और उच्च समग्र प्रदर्शन।

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

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

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

Google बिग क्वेरी और अमेज़न RedShift की जगह (बड़ी कंपनियों के लिए समाधान)

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

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

अल्टिनिटी के सह-संस्थापक अलेक्जेंडर जैतसेव का लेख, "स्विचिंग टू क्लिकहाउस," इस तरह के डीबीओ के प्रवास के लाभों के बारे में बात करता है।

TimescaleDB की जगह

TimescaleDB एक PostgreSQL एक्सटेंशन है जो एक नियमित डेटाबेस ( https://docs.timescale.com/v1.0/introduction , https://habr.com/en/company/zabbix/blog-458530) में टाइम सीरीज़ के समय के साथ काम को अनुकूलित करता है। / ) है।

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

ClickHouse के विपरीत, TimescaleDB में कुछ डिस्क स्थान को बचाने का एकमात्र तरीका ZFS या समान फ़ाइल सिस्टम का उपयोग करना है।

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

• बहुत कम मात्रा में रैम के साथ छोटे इंस्टॉलेशन (<3 जीबी);
• बड़ी संख्या में छोटे INSERT जिन्हें आप बड़े टुकड़ों में बफर नहीं करना चाहते हैं;
• बेहतर स्थिरता, एकरूपता और एसीआईडी ​​आवश्यकताओं;
• पोस्टजीआईएस समर्थन;
• मौजूदा PostgreSQL तालिकाओं के साथ विलय, क्योंकि Timescale DB अनिवार्य रूप से PostgreSQL है।

Hadoop और MapReduce Systems के साथ प्रतिस्पर्धा

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

पिनोट और ड्र्यूड के साथ प्रतियोगिता

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



इस लेख को अपडेट करने की आवश्यकता है - यह बताता है कि ClickHouse UPDATE और DELETE संचालन का समर्थन नहीं करता है, जो नवीनतम संस्करणों के लिए पूरी तरह से सच नहीं है।

हमारे पास इन DBMS के साथ पर्याप्त अनुभव नहीं है, लेकिन मैं Druid और Pinot को चलाने के लिए उपयोग किए जाने वाले बुनियादी ढांचे की जटिलता की तरह नहीं हूं - यह सभी पक्षों से जावा से घिरा "चलती भागों" का एक पूरा गुच्छा है।

ड्र्यूड और पिनोट अपाचे इनक्यूबेटर परियोजनाएं हैं, जिनके विकास की प्रगति को अपाचे ने अपने गिटहब परियोजनाओं के पृष्ठों पर विस्तार से कवर किया है। Pinot अक्टूबर 2018 में इनक्यूबेटर में दिखाई दिया, और Druid का जन्म 8 महीने पहले - फरवरी में हुआ था।

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

ClickHouse का नुकसान

अपरिपक्वता: जाहिर है, यह अभी भी एक उबाऊ तकनीक नहीं है, लेकिन किसी भी मामले में, अन्य स्तंभ डीबीएमएस में ऐसा कुछ भी नहीं देखा जाता है।

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

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

निष्कर्ष

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

विज्ञापन का एक सा :)

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

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?