ELK, Big Query आणि TimescaleDB साठी बदली म्हणून क्लिकहाऊस वापरणे

क्लिकहाऊस Yandex द्वारे तयार केलेली ऑनलाइन विश्लेषणात्मक क्वेरी प्रक्रियेसाठी (OLAP) एक मुक्त स्रोत स्तंभीय डेटाबेस व्यवस्थापन प्रणाली आहे. हे Yandex, CloudFlare, VK.com, Badoo आणि जगभरातील इतर सेवांद्वारे खरोखरच मोठ्या प्रमाणात डेटा (प्रति सेकंद हजारो पंक्ती किंवा डिस्कवर साठवलेला डेटा पेटाबाइट्स) साठवण्यासाठी वापरला जातो.

नियमित, "स्ट्रिंग" DBMS मध्ये, ज्याची उदाहरणे MySQL, Postgres, MS SQL Server आहेत, डेटा खालील क्रमाने संग्रहित केला जातो:

या प्रकरणात, एका पंक्तीशी संबंधित मूल्ये जवळील भौतिकरित्या संग्रहित केली जातात. स्तंभीय DBMSs मध्ये, वेगवेगळ्या स्तंभांमधील मूल्ये स्वतंत्रपणे संग्रहित केली जातात आणि एका स्तंभातील डेटा एकत्र संग्रहित केला जातो:

स्तंभीय DBMS ची उदाहरणे आहेत Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, k+ Druid.

मेल फॉरवर्डर कंपनी क्विंट्री रिपोर्टिंगसाठी 2018 मध्ये क्लिकहाऊस वापरण्यास सुरुवात केली आणि त्याची साधेपणा, स्केलेबिलिटी, SQL समर्थन आणि गतीने खूप प्रभावित झाले. या डीबीएमएसचा वेग जादूवर आहे.

कमी

क्लिकहाऊस उबंटूवर एका आदेशासह स्थापित केले आहे. जर तुम्हाला SQL माहित असेल, तर तुम्ही तुमच्या गरजांसाठी क्लिकहाऊस वापरणे त्वरित सुरू करू शकता. तथापि, याचा अर्थ असा नाही की तुम्ही MySQL मध्ये “शो तयार टेबल” करू शकता आणि क्लिकहाऊसमध्ये SQL कॉपी-पेस्ट करू शकता.

MySQL च्या तुलनेत, टेबल स्कीमा व्याख्यांमध्ये महत्त्वपूर्ण डेटा प्रकार फरक आहेत, त्यामुळे तुम्हाला टेबल स्कीमा व्याख्या बदलण्यासाठी आणि आरामदायी होण्यासाठी टेबल इंजिन शिकण्यासाठी अद्याप थोडा वेळ लागेल.

क्लिकहाऊस कोणत्याही अतिरिक्त सॉफ्टवेअरशिवाय उत्तम कार्य करते, परंतु जर तुम्हाला प्रतिकृती वापरायची असेल, तर तुम्हाला ZooKeeper इंस्टॉल करावे लागेल. क्वेरी कार्यप्रदर्शन विश्लेषण उत्कृष्ट परिणाम दर्शविते - सिस्टम टेबलमध्ये सर्व माहिती असते आणि जुने आणि कंटाळवाणे SQL वापरून सर्व डेटा पुनर्प्राप्त केला जाऊ शकतो.

उत्पादकता

• बेंचमार्क सर्व्हर कॉन्फिगरेशनवर Vertica आणि MySQL सह क्लिकहाऊसची तुलना: दोन सॉकेट Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB रॅम; md RAID-5 8 6TB SATA HDD, ext4 वर.
• बेंचमार्क Amazon RedShift क्लाउड स्टोरेजसह क्लिकहाऊसची तुलना.
• ब्लॉगचे उतारे क्लिकहाऊस कामगिरीवर क्लाउडफ्लेअर:

क्लिकहाऊस डेटाबेसची रचना अगदी सोपी आहे - क्लस्टरमधील सर्व नोड्सची कार्यक्षमता समान आहे आणि फक्त समन्वयासाठी ZooKeeper वापरतात. आम्ही अनेक नोड्सचा एक छोटा क्लस्टर तयार केला आणि चाचणी केली, ज्या दरम्यान आम्हाला आढळले की सिस्टमची प्रभावी कामगिरी आहे, जी विश्लेषणात्मक DBMS बेंचमार्कमधील नमूद केलेल्या फायद्यांशी संबंधित आहे. आम्ही क्लिकहाऊसमागील संकल्पना जवळून पाहण्याचा निर्णय घेतला. संशोधनातील पहिला अडथळा साधनांचा अभाव आणि लहान क्लिकहाऊस समुदाय होता, म्हणून आम्ही हे कसे कार्य करते हे समजून घेण्यासाठी या डीबीएमएसच्या डिझाइनचा शोध घेतला.

क्लिकहाऊस थेट काफ्काकडून डेटा प्राप्त करण्यास समर्थन देत नाही कारण तो फक्त एक डेटाबेस आहे, म्हणून आम्ही Go मध्ये आमची स्वतःची अडॅप्टर सेवा लिहिली. त्यात काफ्का कडून आलेले Cap'n Proto एन्कोड केलेले संदेश वाचले, त्यांना TSV मध्ये रूपांतरित केले आणि HTTP इंटरफेसद्वारे बॅचमध्ये क्लिकहाऊसमध्ये समाविष्ट केले. कार्यप्रदर्शन सुधारण्यासाठी ClickHouse च्या स्वतःच्या इंटरफेसच्या संयोगाने Go लायब्ररी वापरण्यासाठी आम्ही नंतर ही सेवा पुन्हा लिहिली. पॅकेट्स प्राप्त करण्याच्या कार्यक्षमतेचे मूल्यांकन करताना, आम्हाला एक महत्त्वाची गोष्ट सापडली - असे दिसून आले की क्लिकहाऊससाठी हे कार्यप्रदर्शन पॅकेटच्या आकारावर, म्हणजेच एकाच वेळी घातलेल्या पंक्तींच्या संख्येवर अवलंबून असते. हे का घडते हे समजून घेण्यासाठी, आम्ही क्लिकहाऊस डेटा कसा संग्रहित करतो ते पाहिले.

क्लिकहाऊसद्वारे डेटा संग्रहित करण्यासाठी वापरले जाणारे मुख्य इंजिन किंवा टेबल इंजिनचे कुटुंब म्हणजे MergeTree. हे इंजिन संकल्पनात्मकपणे Google BigTable किंवा Apache Cassandra मध्ये वापरल्या जाणार्‍या LSM अल्गोरिदमसारखे आहे, परंतु इंटरमीडिएट मेमरी टेबल तयार करणे टाळते आणि डेटा थेट डिस्कवर लिहिते. हे त्याला उत्कृष्ट लेखन थ्रूपुट देते, कारण प्रत्येक समाविष्ट केलेले पॅकेट केवळ प्राथमिक की, संकुचित, आणि विभाग तयार करण्यासाठी डिस्कवर लिहिलेले आहे.

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

सारणी वाचन कार्यप्रदर्शनाची गुरुकिल्ली म्हणजे अनुक्रमणिका आणि डिस्कवरील डेटाचे स्थान. प्रक्रिया कितीही जलद असली तरीही, जेव्हा इंजिनला डिस्कवरून टेराबाइट डेटा स्कॅन करण्याची आणि त्यातील काही भाग वापरण्याची आवश्यकता असते, तेव्हा वेळ लागेल. क्लिकहाऊस हे स्तंभीय स्टोअर आहे, म्हणून प्रत्येक विभागामध्ये प्रत्येक स्तंभासाठी (स्तंभ) प्रत्येक पंक्तीसाठी क्रमवारी केलेल्या मूल्यांसह एक फाइल असते. अशा प्रकारे, क्वेरीमधून गहाळ असलेले संपूर्ण स्तंभ प्रथम वगळले जाऊ शकतात आणि नंतर व्हेक्टराइज्ड अंमलबजावणीच्या समांतर अनेक सेलवर प्रक्रिया केली जाऊ शकते. पूर्ण स्कॅन टाळण्यासाठी, प्रत्येक विभागामध्ये एक लहान अनुक्रमणिका फाइल असते.

सर्व स्तंभ "प्राथमिक की" द्वारे क्रमवारी लावलेले आहेत हे लक्षात घेऊन, इंडेक्स फाइलमध्ये फक्त प्रत्येक Nव्या पंक्तीची लेबले (कॅप्चर केलेल्या पंक्ती) असतात ज्यामुळे त्यांना अगदी मोठ्या टेबलसाठी देखील मेमरीमध्ये ठेवता येते. उदाहरणार्थ, तुम्ही डीफॉल्ट सेटिंग्ज "प्रत्येक 8192 व्या पंक्तीवर चिन्हांकित करा", नंतर 1 ट्रिलियन असलेल्या टेबलचे "अल्प" अनुक्रमणिका सेट करू शकता. मेमरीमध्ये सहज बसणाऱ्या रेषा फक्त 122 वर्ण घेतील.

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

क्लिकहाऊसचा विकास आणि सुधारणा येथे शोधल्या जाऊ शकतात गिथब रेपो आणि "वाढण्याची" प्रक्रिया प्रभावी गतीने होत असल्याचे सुनिश्चित करा.

लोकप्रियता

क्लिकहाऊसची लोकप्रियता झपाट्याने वाढत आहे, विशेषत: रशियन भाषिक समुदायामध्ये. गेल्या वर्षीच्या उच्च भार 2018 परिषदेत (मॉस्को, 8-9 नोव्हेंबर, 2018) असे दिसून आले की vk.com आणि Badoo सारखे राक्षस क्लिकहाऊस वापरतात, ज्यासह ते एकाच वेळी हजारो सर्व्हरमधून डेटा (उदाहरणार्थ, लॉग) समाविष्ट करतात. 40 मिनिटांच्या व्हिडिओमध्ये व्हीकॉन्टाक्टे संघातील युरी नसरेटिनोव्ह हे कसे केले जाते याबद्दल बोलतो. सामग्रीसह कार्य करणे सोपे व्हावे यासाठी आम्ही लवकरच हाब्रीवर उतारा पोस्ट करू.

अनुप्रयोग

संशोधनात काही वेळ घालवल्यानंतर, मला वाटते की अशी काही क्षेत्रे आहेत जिथे क्लिकहाऊस उपयुक्त ठरू शकेल किंवा इतर, अधिक पारंपारिक आणि लोकप्रिय उपाय जसे की MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot आणि पूर्णपणे बदलू शकेल. ड्रुइड. वरील डीबीएमएसचे आधुनिकीकरण किंवा पूर्णपणे पुनर्स्थित करण्यासाठी क्लिकहाऊस वापरण्याच्या तपशीलांचे वर्णन खालीलप्रमाणे आहे.

MySQL आणि PostgreSQL च्या क्षमतांचा विस्तार करणे

नुकतेच आम्ही आमच्या न्यूजलेटर प्लॅटफॉर्मसाठी MySQL च्या जागी क्लिकहाऊससह अंशतः बदलले मौटिक वृत्तपत्र. अडचण अशी होती की, खराब डिझाइनमुळे, MySQL पाठवलेला प्रत्येक ईमेल आणि त्या ईमेलमधील प्रत्येक लिंक बेस64 हॅशने लॉग करत होता, एक प्रचंड MySQL टेबल (email_stats) तयार करत होता. सेवा सदस्यांना फक्त 10 दशलक्ष ईमेल पाठवल्यानंतर, या टेबलने 150 GB फाईल जागा व्यापली आणि MySQL साध्या प्रश्नांवर "मूर्ख" होऊ लागले. फाइल स्पेस समस्येचे निराकरण करण्यासाठी, आम्ही InnoDB टेबल कॉम्प्रेशनचा यशस्वीरित्या वापर केला ज्यामुळे ते 4 च्या घटकाने कमी केले. तथापि, केवळ इतिहास वाचण्याच्या फायद्यासाठी MySQL मध्ये 20-30 दशलक्ष पेक्षा जास्त ईमेल संचयित करण्यात अद्याप अर्थ नाही, कारण कोणत्याही कारणास्तव पूर्ण स्कॅन करण्याची आवश्यकता असलेल्या कोणत्याही सोप्या क्वेरीचा परिणाम स्वॅपमध्ये होतो आणि बरेच आय. /O लोड, त्यानुसार आम्हाला नियमितपणे Zabbix कडून चेतावणी प्राप्त झाली.

क्लिकहाऊस दोन कॉम्प्रेशन अल्गोरिदम वापरतात जे डेटा व्हॉल्यूम अंदाजे कमी करतात 3-4 वेळा, परंतु या विशिष्ट प्रकरणात डेटा विशेषतः "संकुचित करण्यायोग्य" होता.

ELK बदलत आहे

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

• एसक्यूएल बोली समर्थन;
• संग्रहित डेटाच्या कॉम्प्रेशनची सर्वोत्तम पदवी;
• संपूर्ण मजकूर शोधांऐवजी Regex नियमित अभिव्यक्ती शोधांसाठी समर्थन;
• सुधारित क्वेरी शेड्यूलिंग आणि उच्च एकूण कार्यप्रदर्शन.

सध्या, क्लिकहाऊसची ELK शी तुलना करताना उद्भवणारी सर्वात मोठी समस्या म्हणजे लॉग अपलोड करण्यासाठी उपायांचा अभाव, तसेच या विषयावरील दस्तऐवज आणि ट्यूटोरियलचा अभाव. शिवाय, प्रत्येक वापरकर्ता डिजिटल महासागर मॅन्युअल वापरून ELK कॉन्फिगर करू शकतो, जे अशा तंत्रज्ञानाच्या जलद अंमलबजावणीसाठी खूप महत्वाचे आहे. डेटाबेस इंजिन आहे, परंतु क्लिकहाऊससाठी अद्याप कोणतेही फाइलबीट नाही. होय, ते तेथे आहे अस्खलित आणि लॉगसह कार्य करण्यासाठी एक प्रणाली लॉगहाऊस, एक साधन आहे क्लिकटेल क्लिकहाऊसमध्ये लॉग फाइल डेटा प्रविष्ट करण्यासाठी, परंतु या सर्व गोष्टींना अधिक वेळ लागतो. तथापि, क्लिकहाऊस त्याच्या साधेपणामुळे अजूनही आघाडीवर आहे, त्यामुळे नवशिक्याही ते सहजपणे स्थापित करू शकतात आणि केवळ 10 मिनिटांत ते पूर्णपणे कार्यशीलपणे वापरण्यास प्रारंभ करू शकतात.

मिनिमलिस्ट सोल्यूशन्सला प्राधान्य देत, मी काफ्का वापरणे टाळण्याचा प्रयत्न करत असताना, क्लिकहाऊससह, अगदी कमी मेमरीसह लॉग पाठवण्याचे साधन FluentBit वापरण्याचा प्रयत्न केला. तथापि, किरकोळ विसंगतींना संबोधित करणे आवश्यक आहे, जसे की तारीख स्वरूप समस्याफ्लुएंटबिट वरून क्लिकहाऊसमध्ये डेटा रूपांतरित करणार्‍या प्रॉक्सी लेयरशिवाय हे केले जाऊ शकते.

एक पर्याय म्हणून, किबाना क्लिकहाऊस बॅकएंड म्हणून वापरला जाऊ शकतो ग्राफाना. मला जे समजले त्यावरून, विशेषत: Grafana च्या जुन्या आवृत्त्यांसह, मोठ्या संख्येने डेटा पॉइंट रेंडर करताना यामुळे कार्यप्रदर्शन समस्या उद्भवू शकतात. आम्‍ही अद्याप क्विन्‍ट्रीमध्‍ये हा प्रयत्न केला नाही, परंतु टेलीग्राममधील क्लिकहाऊस सपोर्ट चॅनेलवर वेळोवेळी याबाबत तक्रारी येतात.

Google Big Query आणि Amazon RedShift बदलणे (मोठ्या कंपन्यांसाठी उपाय)

BigQuery साठी आदर्श वापर केस म्हणजे 1 TB JSON डेटा लोड करणे आणि त्यावर विश्लेषणात्मक क्वेरी चालवणे. Big Query हे एक उत्कृष्ट उत्पादन आहे ज्याची स्केलेबिलिटी ओव्हरस्टेटेड केली जाऊ शकत नाही. हे ClickHouse पेक्षा अधिक क्लिष्ट सॉफ्टवेअर आहे, जे अंतर्गत क्लस्टरवर चालते, परंतु क्लायंटच्या दृष्टिकोनातून ते ClickHouse मध्ये बरेच साम्य आहे. एकदा तुम्ही प्रति SELECT पैसे भरणे सुरू केले की BigQuery त्वरीत महाग होऊ शकते, म्हणून हे सर्व साधक आणि बाधकांसह एक खरे SaaS समाधान आहे.

तुम्‍ही संगणकीयदृष्ट्या महागड्या क्‍वेरीज करत असताना क्लिकहाऊस हा सर्वोत्तम पर्याय आहे. तुम्ही दररोज जितक्या जास्त SELECT क्वेरी चालवता तितकेच Big Query ला ClickHouse ने बदलणे अधिक अर्थपूर्ण ठरते, कारण अशा रिप्लेसमेंटमुळे अनेक टेराबाइट डेटावर प्रक्रिया होत असताना तुमची हजारो डॉलर्सची बचत होऊ शकते. बिग क्‍वेरीमध्‍ये प्रक्रिया करण्‍यासाठी खूप स्वस्त असलेल्या संचयित डेटावर हे लागू होत नाही.

अल्टिनिटीचे सह-संस्थापक अलेक्झांडर जैत्सेव्ह यांच्या लेखात "क्लिकहाऊसवर स्विच करणे" अशा DBMS स्थलांतराच्या फायद्यांबद्दल बोलतो.

TimescaleDB बदली

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

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

ClickHouse च्या विपरीत, TimescaleDB मध्ये काही डिस्क जागा वाचवण्याचा एकमेव मार्ग म्हणजे ZFS किंवा तत्सम फाइल सिस्टम वापरणे.

ClickHouse मधील आगामी अद्यतने बहुधा डेल्टा कॉम्प्रेशन सादर करतील, जे टाइम सीरिज डेटावर प्रक्रिया करण्यासाठी आणि संचयित करण्यासाठी अधिक योग्य बनवेल. खालील प्रकरणांमध्ये टाइमस्केलडीबी बेअर क्लिकहाऊसपेक्षा चांगली निवड असू शकते:

• अगदी कमी RAM (<3 GB) सह लहान स्थापना;
• मोठ्या संख्येने लहान INSERTs ज्यांना आपण मोठ्या तुकड्यांमध्ये बफर करू इच्छित नाही;
• उत्तम सुसंगतता, एकसमानता आणि ACID आवश्यकता;
• पोस्टजीआयएस समर्थन;
• विद्यमान PostgreSQL सारण्यांसह सामील होणे, कारण Timescale DB मूलत: PostgreSQL आहे.

Hadoop आणि MapReduce प्रणालीसह स्पर्धा

Hadoop आणि इतर MapReduce उत्पादने बरीच जटिल गणना करू शकतात, परंतु ते मोठ्या विलंबाने चालतात. ClickHouse डेटाच्या टेराबाइट्सवर प्रक्रिया करून आणि जवळजवळ त्वरित परिणाम तयार करून या समस्येचे निराकरण करते. अशा प्रकारे, क्लिकहाऊस जलद, परस्परसंवादी विश्लेषणात्मक संशोधन करण्यासाठी अधिक प्रभावी आहे, जे डेटा शास्त्रज्ञांना स्वारस्य असले पाहिजे.

Pinot आणि Druid सह स्पर्धा

ClickHouse चे सर्वात जवळचे स्पर्धक स्तंभीय, रेखीय स्केलेबल ओपन सोर्स उत्पादने Pinot आणि Druid आहेत. या प्रणालींची तुलना करणारे एक उत्कृष्ट कार्य लेखात प्रकाशित केले आहे रोमाना लेव्हेंटोवा दिनांक 1 फेब्रुवारी 2018

हा लेख अद्ययावत करणे आवश्यक आहे - त्यात असे म्हटले आहे की क्लिकहाऊस अद्यतन आणि हटवा ऑपरेशन्सना समर्थन देत नाही, जे नवीनतम आवृत्त्यांसाठी पूर्णपणे सत्य नाही.

आम्हाला या डेटाबेसेसचा फारसा अनुभव नाही, परंतु ड्रुइड आणि पिनोट चालविण्यासाठी आवश्यक असलेल्या पायाभूत सुविधांची जटिलता मला खरोखर आवडत नाही - हे सर्व बाजूंनी जावाने वेढलेले हलणारे भाग आहे.

Druid आणि Pinot हे Apache इनक्यूबेटर प्रकल्प आहेत, ज्याची प्रगती Apache द्वारे त्याच्या GitHub प्रकल्प पृष्ठांवर तपशीलवार कव्हर केली आहे. पिनोट ऑक्टोबर 2018 मध्ये इनक्यूबेटरमध्ये दिसला आणि ड्र्यूडचा जन्म 8 महिन्यांपूर्वी - फेब्रुवारीमध्ये झाला.

AFS कसे कार्य करते याबद्दल माहितीचा अभाव माझ्यासाठी काही, आणि कदाचित मूर्खपणाचे प्रश्न निर्माण करतो. मला आश्चर्य वाटते की पिनोट लेखकांच्या लक्षात आले की अपाचे फाउंडेशन ड्रुइडसाठी अधिक अनुकूल आहे आणि प्रतिस्पर्ध्याबद्दलच्या या वृत्तीमुळे मत्सराची भावना निर्माण झाली आहे का? ड्रुइडचा विकास मंदावेल आणि पिनॉटच्या विकासाला वेग येईल का, जर पूर्वीच्या समर्थकांना नंतरच्या काळात अचानक रस निर्माण झाला?

क्लिकहाऊसचे तोटे

अपरिपक्वता: स्पष्टपणे, हे अद्याप कंटाळवाणे तंत्रज्ञान नाही, परंतु कोणत्याही परिस्थितीत, इतर स्तंभीय DBMS मध्ये असे काहीही दिसून येत नाही.

लहान इन्सर्ट्स उच्च वेगाने चांगली कामगिरी करत नाहीत: इन्सर्ट मोठ्या भागांमध्ये विभागले जाणे आवश्यक आहे कारण प्रत्येक ओळीतील कॉलम्सच्या प्रमाणात लहान इन्सर्टची कार्यक्षमता कमी होते. अशा प्रकारे क्लिकहाऊस डिस्कवर डेटा संग्रहित करते - प्रत्येक स्तंभ 1 किंवा त्याहून अधिक फाइलचे प्रतिनिधित्व करतो, म्हणून 1 स्तंभ असलेली 100 पंक्ती घालण्यासाठी, तुम्हाला किमान 100 फाइल्स उघडणे आणि लिहिणे आवश्यक आहे. म्हणूनच बफरिंग इन्सर्टसाठी मध्यस्थाची आवश्यकता असते (जोपर्यंत क्लायंट स्वतः बफरिंग प्रदान करत नाही) - सामान्यतः काफ्का किंवा काही प्रकारची रांग व्यवस्थापन प्रणाली. तुम्‍ही बफर टेबल इंजिनचा वापर नंतर MergeTree टेबलमध्‍ये डेटाचा मोठा भाग कॉपी करण्‍यासाठी करू शकता.

टेबल जोडणे सर्व्हरच्या RAM द्वारे मर्यादित आहेत, परंतु किमान ते तेथे आहेत! उदाहरणार्थ, ड्रुइड आणि पिनॉटमध्ये असे कनेक्शन अजिबात नाही, कारण त्यांना नोड्स दरम्यान डेटाचा मोठा भाग हलविण्यास समर्थन न देणाऱ्या वितरित प्रणालींमध्ये थेट अंमलबजावणी करणे कठीण आहे.

निष्कर्ष

येत्या काही वर्षांत क्विंट्रीमध्ये क्लिकहाऊसचा मोठ्या प्रमाणावर वापर करण्याची आमची योजना आहे, कारण हे DBMS कामगिरी, कमी ओव्हरहेड, स्केलेबिलिटी आणि साधेपणाचे उत्कृष्ट संतुलन प्रदान करते. मला खात्री आहे की क्लिकहाऊस समुदायाने लहान ते मध्यम आकाराच्या स्थापनेमध्ये वापरण्याचे आणखी मार्ग शोधून काढले की ते लवकर पसरण्यास सुरुवात होईल.

काही जाहिराती 🙂

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

डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीव्ही $199 पासून नेदरलँड मध्ये! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com