آن لائن تجزياتي سوال پروسيسنگ (OLAP) لاءِ هڪ کليل ذريعو ڪالمنر ڊيٽابيس مينيجمينٽ سسٽم آهي، جيڪو Yandex پاران ٺاهيل آهي. اهو استعمال ڪيو ويندو آهي Yandex، CloudFlare، VK.com، Badoo ۽ ٻين خدمتن کي سڄي دنيا ۾ ڊيٽا جي وڏي مقدار کي ذخيرو ڪرڻ لاء (هزارين قطار في سيڪنڊ يا ڊسڪ تي ذخيرو ٿيل ڊيٽا جي petabytes داخل ڪرڻ).
باقاعده، "string" DBMS ۾، جن جا مثال MySQL، Postgres، MS SQL سرور آهن، ڊيٽا هيٺين ترتيب ۾ ذخيرو ٿيل آهي:
ھن حالت ۾، ھڪڙي قطار سان لاڳاپيل قدر جسماني طور تي ويجھي ذخيرو ٿيل آھن. ڪالمن DBMSs ۾، مختلف ڪالمن مان قدر الڳ الڳ ذخيرو ٿيل آھن، ۽ ھڪڙي ڪالمن مان ڊيٽا گڏ گڏ ٿيل آھي:
ڪالمن DBMSs جا مثال آهن 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 سپورٽ ۽ رفتار کان تمام گهڻو متاثر ٿيو. هن ڊي بي ايم ايس جي رفتار جادو تي ٻڌل آهي.
آسانيء
Clickhouse Ubuntu تي هڪ واحد حڪم سان نصب ٿيل آهي. جيڪڏھن توھان ڄاڻو ٿا SQL، توھان فوري طور تي استعمال ڪرڻ شروع ڪري سگھو ٿا ڪلڪ ھاؤس پنھنجي ضرورتن لاءِ. تنهن هوندي، هن جو مطلب اهو ناهي ته توهان MySQL ۾ "ٺاهيو ٽيبل ٺاهي" ڪري سگهو ٿا ۽ ڪلڪ ڪيو SQL ۾ ڪاپي پيسٽ ڪريو.
MySQL جي مقابلي ۾، ٽيبل اسڪيما جي وصفن ۾ اهم ڊيٽا جي قسم جا فرق آهن، تنهن ڪري توهان کي اڃا به ڪجهه وقت جي ضرورت پوندي ٽيبل اسڪيما جي وصفن کي تبديل ڪرڻ ۽ ٽيبل انجڻ کي سکڻ لاءِ آرام سان.
Clickhouse بغير ڪنهن اضافي سافٽ ويئر جي تمام سٺو ڪم ڪري ٿو، پر جيڪڏهن توهان نقل استعمال ڪرڻ چاهيو ٿا، توهان کي انسٽال ڪرڻو پوندو ZooKeeper. سوالن جي ڪارڪردگي جو تجزيو شاندار نتيجا ڏيکاري ٿو - سسٽم جدولن ۾ سموري معلومات شامل آهي، ۽ سموري ڊيٽا پراڻي ۽ بورنگ SQL استعمال ڪندي حاصل ڪري سگھجي ٿي.
پيداوار
- سرور جي ترتيب تي Vertica ۽ MySQL سان ڪلڪ هائوس جو مقابلو: ٻه ساکٽ Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz؛ 128 GiB رام؛ md RAID-5 تي 8 6TB SATA HDD، ext4.
- ڪلڪ هائوس جو مقابلو Amazon RedShift ڪلائوڊ اسٽوريج سان.
- بلاگ جا حوالا :
ClickHouse ڊيٽابيس ۾ تمام سادي ڊيزائن آھي - ڪلستر ۾ سڀ نوڊس ھڪڙي ئي ڪارڪردگي رکن ٿا ۽ صرف ڪوآرڊينيشن لاءِ ZooKeeper استعمال ڪن ٿا. اسان ڪيترن ئي نوڊس جو ھڪڙو ننڍڙو ڪلستر ٺاھيو ۽ جانچ ڪئي، جنھن دوران اسان ڏٺو ته سسٽم ڪافي متاثر کن ڪارڪردگي آھي، جيڪا تجزياتي DBMS معيارن ۾ بيان ڪيل فائدن سان مطابقت رکي ٿي. اسان ڪلڪ ڪيو هاؤس جي پويان تصور تي ويجھو نظر وجهڻ جو فيصلو ڪيو. تحقيق ۾ پهرين رڪاوٽ اوزارن جي کوٽ ۽ ننڍي ClickHouse ڪميونٽي هئي، تنهن ڪري اسان هن DBMS جي ڊيزائن کي سمجهي ورتو ته اهو ڪيئن ڪم ڪري ٿو.
ClickHouse سڌو سنئون ڪافڪا کان ڊيٽا حاصل ڪرڻ جي حمايت نٿو ڪري ڇاڪاڻ ته اهو صرف هڪ ڊيٽابيس آهي، تنهنڪري اسان Go ۾ پنهنجي پنهنجي اڊاپٽر سروس لکيو. اهو پڙهي ٿو Cap'n Proto انڪوڊ ٿيل پيغام Kafka کان، انهن کي TSV ۾ تبديل ڪيو ۽ HTTP انٽرفيس ذريعي بيچ ۾ ڪلڪ هائوس ۾ داخل ڪيو. اسان بعد ۾ هن سروس کي ٻيهر لکيو ته گو لائبريري استعمال ڪرڻ لاءِ ڪلڪ هاؤس جي پنهنجي انٽرفيس سان گڏ ڪارڪردگي بهتر ڪرڻ لاءِ. جڏهن پيڪٽ حاصل ڪرڻ جي ڪارڪردگي جو جائزو وٺو، اسان هڪ اهم شيء دريافت ڪيو - اهو ظاهر ٿيو ته ڪلڪ هاؤس لاء هي ڪارڪردگي گهڻو ڪري پيڪٽ جي سائيز تي منحصر آهي، اهو آهي، هڪ ئي وقت ۾ داخل ڪيل قطارن جو تعداد. سمجھڻ لاءِ ائين ڇو ٿئي ٿو، اسان ڏٺو ته ڪيئن ClickHouse ڊيٽا کي ذخيرو ڪري ٿو.
مکيه انجڻ، يا بلڪه ٽيبل انجڻ جو خاندان، ڪلڪ هائوس طرفان ڊيٽا کي ذخيرو ڪرڻ لاءِ استعمال ڪيو ويو آهي MergeTree. هي انجڻ تصوراتي طور تي Google BigTable يا Apache Cassandra ۾ استعمال ٿيل LSM الورورٿم سان ملندڙ جلندڙ آهي، پر وچولي ميموري ٽيبل ٺاهڻ کان پاسو ڪري ٿو ۽ ڊيٽا کي سڌو ڊسڪ تي لکي ٿو. اهو ان کي بهترين لکڻ جي ذريعي ڏئي ٿو، ڇاڪاڻ ته هر داخل ٿيل پيڪٽ صرف پرائمري ڪيئي، دٻايو، ۽ ڊسڪ ڏانهن لکيل آهي هڪ ڀاڱو ٺاهڻ لاء.
ميموري ٽيبل جي غير موجودگي يا ڊيٽا جي "تازگي" جي ڪنهن به تصور جو مطلب اهو آهي ته انهن کي صرف شامل ڪري سگهجي ٿو؛ سسٽم تبديل ڪرڻ يا حذف ڪرڻ جي حمايت نٿو ڪري. في الحال، ڊيٽا کي ختم ڪرڻ جو واحد طريقو اهو آهي ته ان کي ڪئلينڊر جي مهيني ذريعي ختم ڪيو وڃي، ڇو ته حصا ڪڏهن به مهيني جي حد کي پار نه ڪندا آهن. ClickHouse ٽيم فعال طور تي ڪم ڪري رهي آهي انهي خصوصيت کي ڪسٽمائيز ڪرڻ لاءِ. ٻئي طرف، اهو لکندو ۽ ضم ڪري ٿو حصن کي تڪرار کان آزاد، تنهن ڪري I/O يا بنيادي سنترپشن ٿيڻ تائين سمورو داخلن جي تعداد سان لڪيريءَ سان ان پٽ اسڪيل حاصل ڪريو.
بهرحال، هن جو مطلب اهو پڻ آهي ته سسٽم ننڍن پيڪن لاء مناسب نه آهي، تنهنڪري ڪافڪا خدمتون ۽ داخل ڪندڙ بفرنگ لاء استعمال ڪيا ويا آهن. اڳيون، پس منظر ۾ ClickHouse مسلسل سيگمينٽ ضم ڪرڻ کي جاري رکي ٿو، ته جيئن معلومات جا ڪيترائي ننڍا ٽڪرا گڏ ڪيا ويندا ۽ وڌيڪ ڀيرا رڪارڊ ڪيو ويندو، اهڙيءَ طرح رڪارڊنگ جي شدت ۾ اضافو ٿيندو. بهرحال، تمام گھڻا غير ڳنڍيل حصا انسرٽس جي جارحيت واري ٿلهي جو سبب بڻجندا جيستائين انضمام جاري رھندو. اسان اهو محسوس ڪيو آهي ته حقيقي وقت جي انضمام ۽ انضمام جي ڪارڪردگي جي وچ ۾ بهترين سمجھوتا ٽيبل ۾ في سيڪنڊ جي محدود تعداد ۾ داخل ڪرڻ آهي.
ٽيبل پڙهڻ جي ڪارڪردگي لاء اهم انڊيڪسنگ آهي ۽ ڊسڪ تي ڊيٽا جو مقام. ڪابه پرواهه ناهي ته پروسيسنگ ڪيترو تيز آهي، جڏهن انجڻ کي ڊسڪ مان ڊيٽا جي ٽيرا بائيٽ اسڪين ڪرڻ جي ضرورت آهي ۽ صرف ان جو هڪ حصو استعمال ڪيو وڃي، اهو وقت وٺندو. ClickHouse هڪ ڪالمن جو اسٽور آهي، تنهنڪري هر ڀاڱي ۾ هر قطار لاءِ ترتيب ڏنل قدرن سان گڏ هر ڪالمن (ڪالمن) لاءِ هڪ فائيل شامل آهي. اهڙيءَ طرح، سوال مان غائب ٿيل سمورا ڪالمن پهريان ڇڏي سگھجن ٿا، ۽ پوءِ گھڻن سيلن کي ویکٹر ٿيل عمل سان متوازي طور تي عمل ڪري سگھجي ٿو. مڪمل اسڪين کان بچڻ لاء، هر ڀاڱي ۾ هڪ ننڍڙو انڊيڪس فائل آهي.
ڏنو ويو آهي ته سڀئي ڪالمن "پرائمري ڪي" جي ترتيب سان ترتيب ڏنل آهن، انڊيڪس فائل صرف هر Nth قطار جي ليبلز (قطع ڪيل قطار) تي مشتمل آهي انهن کي ياد رکڻ جي قابل ٿي سگھي ٿو انهن کي تمام وڏي جدولن لاء پڻ. مثال طور، توھان ڊفالٽ سيٽنگون سيٽ ڪري سگھو ٿا ”ھر 8192nd قطار کي نشان ھڻڻ“، پوءِ 1 ٽريلين سان ٽيبل جي ”معمولي“ انڊيڪسنگ. سٽون جيڪي آساني سان ميموري ۾ فٽ ٿين ٿيون صرف 122 اکر وٺن ٿيون.
سسٽم جي ترقي
ڪلڪ هاؤس جي ترقي ۽ سڌاري کي ڳولي سگهجي ٿو ۽ پڪ ڪريو ته "وڌڻ" جو عمل هڪ شاندار رفتار تي ٿئي ٿو.
مقبوليت
ڪلڪ هائوس جي مقبوليت تيزي سان وڌي رهي آهي، خاص طور تي روسي ڳالهائيندڙ ڪميونٽي ۾. گذريل سال جي هاءِ لوڊ 2018 ڪانفرنس (ماسڪو، نومبر 8-9، 2018) ڏيکاريو ويو ته اهڙا راکشس جيئن vk.com ۽ Badoo استعمال ڪن ٿا Clickhouse، جنهن سان اهي هڪ ئي وقت هزارين سرورن مان ڊيٽا (مثال طور لاگز) داخل ڪن ٿا. 40 منٽن جي وڊيو ۾ . مواد سان ڪم ڪرڻ جي آسانيءَ لاءِ جلد ئي اسان نقل حبر تي پوسٽ ڪنداسين.
درخواستون
تحقيق ڪرڻ ۾ ڪجهه وقت گذارڻ کان پوءِ، منهنجو خيال آهي ته اهڙا علائقا آهن جتي ClickHouse ڪارائتو ٿي سگهي ٿو يا مڪمل طور تي متبادل ٿي سگهي ٿو ٻيا، وڌيڪ روايتي ۽ مشهور حل جهڙوڪ MySQL، PostgreSQL، ELK، Google Big Query، Amazon RedShift، TimescaleDB، Hadoop، MapReduce، Pinot ۽ ڊروڊ. مٿي ڏنل ڊي بي ايم ايس کي جديد يا مڪمل طور تي تبديل ڪرڻ لاءِ ClickHouse استعمال ڪرڻ جا تفصيل بيان ڪري ٿو.
MySQL ۽ PostgreSQL جي صلاحيتن کي وڌائڻ
تازو ئي اسان جزوي طور MySQL کي تبديل ڪيو ClickHouse سان اسان جي نيوز ليٽر پليٽ فارم لاءِ . مسئلو اهو هو ته MySQL، خراب ڊيزائن جي ڪري، هر موڪليل اي ميل ۽ ان اي ميل جي هر لنڪ کي بيس 64 هيش سان لاگ ان ڪري رهيو هو، هڪ وڏي MySQL ٽيبل ٺاهي رهيو هو (email_stats). سروس سبسڪرائبرن کي صرف 10 ملين اي ميلون موڪلڻ کان پوءِ، هن ٽيبل 150 GB فائل جي جاءِ تي قبضو ڪيو، ۽ MySQL سادي سوالن تي ”بيوقوف“ ٿيڻ شروع ڪيو. فائل اسپيس جو مسئلو حل ڪرڻ لاءِ، اسان ڪاميابيءَ سان استعمال ڪيو InnoDB ٽيبل ڪمپريشن جنهن ان کي 4 جي فيڪٽر ذريعي گھٽايو. بهرحال، اهو اڃا به ڪو مطلب ناهي ته MySQL ۾ 20-30 ملين کان وڌيڪ اي ميلون ذخيرو ڪرڻ لاءِ صرف تاريخ پڙهڻ لاءِ، ڇاڪاڻ ته ڪو به سادو سوال جنهن کي ڪنهن سبب لاءِ مڪمل اسڪين ڪرڻ جي ضرورت آهي نتيجن کي ادل بدلائڻ ۾ ۽ تمام گهڻو I. /O لوڊ، جنهن جي باري ۾ اسان کي باقاعده ڊيڄاريندڙ ملي ٿي Zabbix کان.
ڪلڪ هاؤس استعمال ڪري ٿو ٻه کمپريشن الگورتھم جيڪي ڊيٽا جي مقدار کي گھٽائي ٿو تقريبن ، پر هن خاص صورت ۾ ڊيٽا خاص طور تي "compressible" هئي.
ELK کي تبديل ڪرڻ
منهنجي پنهنجي تجربي جي بنياد تي، ELK اسٽيڪ (ElasticSearch، Logstash ۽ Kibana، هن خاص صورت ۾ ElasticSearch) کي هلائڻ لاءِ تمام گهڻو وسيلن جي ضرورت آهي لاگز کي ذخيرو ڪرڻ لاءِ ضروري آهي. ElasticSearch هڪ بهترين انجڻ آهي جيڪڏهن توهان کي سٺي مڪمل ٽيڪسٽ لاگ سرچ جي ضرورت آهي (جنهن جي توهان کي واقعي ضرورت ناهي) پر مان حيران آهيان ته اهو اصل ۾ معياري لاگنگ انجڻ ڇو بڻجي ويو آهي. Logstash سان گڏ گڏ ٿيل ان جي ڪارڪردگي اسان کي ڪافي روشني لوڊ جي تحت پڻ مسئلا ڏني ۽ اسان کي وڌيڪ ۽ وڌيڪ رام ۽ ڊسڪ اسپيس شامل ڪرڻ جي ضرورت آهي. ڊيٽابيس جي طور تي، Clickhouse هيٺين سببن لاء ElasticSearch کان بهتر آهي:
- SQL ٻولي جي حمايت؛
- ذخيرو ٿيل ڊيٽا جي ڪمپريشن جي بهترين درجي؛
- مڪمل ٽيڪسٽ ڳولها جي بدران ريجڪس باقاعده اظهار جي ڳولا لاء سپورٽ؛
- بهتر سوال جي شيڊول ۽ اعلي مجموعي ڪارڪردگي.
في الحال، سڀ کان وڏو مسئلو پيدا ٿئي ٿو جڏهن ClickHouse سان ELK جي مقابلي ۾ لاگز اپلوڊ ڪرڻ لاء حل جي کوٽ آهي، انهي سان گڏ موضوع تي دستاويزن ۽ سبق جي کوٽ. ان کان علاوه، هر صارف ڊجيٽل سامونڊي دستياب استعمال ڪندي ELK ترتيب ڏئي سگهي ٿو، جيڪو اهڙين ٽيڪنالاجيز جي تيز رفتار تي عمل ڪرڻ لاء تمام ضروري آهي. هتي هڪ ڊيٽابيس انجڻ آهي، پر ClickHouse لاء اڃا تائين ڪا به فائل بيٽ ناهي. ها، اهو اتي آهي ۽ لاگ سان ڪم ڪرڻ لاء هڪ نظام ، اتي هڪ اوزار آهي لاگ فائل ڊيٽا داخل ڪرڻ لاءِ ClickHouse ۾، پر اهو سڀ ڪجهه وڌيڪ وقت وٺندو آهي. بهرحال، ClickHouse اڃا تائين ليڊر آهي ان جي سادگي جي ڪري، تنهنڪري شروعات ڪندڙ به ان کي آساني سان انسٽال ڪري سگهن ٿا ۽ صرف 10 منٽن ۾ مڪمل طور تي استعمال ڪرڻ شروع ڪري سگهن ٿا.
minimalist حلن کي ترجيح ڏيندي، مون FluentBit استعمال ڪرڻ جي ڪوشش ڪئي، تمام ٿوري ميموري سان لاگز موڪلڻ لاءِ هڪ اوزار، ClickHouse سان گڏ، ڪافڪا کي استعمال ڪرڻ کان پاسو ڪرڻ جي ڪوشش ڪندي. تنهن هوندي به، ننڍي incompatibilities کي خطاب ڪرڻ جي ضرورت آهي، جهڙوڪ ان کان اڳ پراڪسي پرت جي بغير ٿي سگھي ٿي جيڪا ڊيٽا کي FluentBit کان ClickHouse ۾ تبديل ڪري ٿي.
هڪ متبادل طور، Kibana هڪ ClickHouse پس منظر طور استعمال ڪري سگهجي ٿو . مان جيڪو سمجهان ٿو، اهو ڪارڪردگي جي مسئلن جو سبب بڻجي سگهي ٿو جڏهن ڊيٽا پوائنٽن جي وڏي انگ کي پيش ڪندي، خاص طور تي گرافانا جي پراڻن نسخن سان. اسان اڃان تائين Qwintry تي اها ڪوشش نه ڪئي آهي، پر ان بابت شڪايتون وقت بوقت ٽيليگرام تي ڪلڪ هائوس سپورٽ چينل تي ظاهر ٿينديون آهن.
Google Big Query ۽ Amazon RedShift جي متبادل (وڏين ڪمپنين لاءِ حل)
BigQuery لاءِ مثالي استعمال جو ڪيس JSON ڊيٽا جو 1 TB لوڊ ڪرڻ ۽ ان تي تجزياتي سوالن کي هلائڻ آهي. بگ سوال هڪ بهترين پراڊڪٽ آهي جنهن جي اسپيبلٽي کي وڌيڪ نه ٿو چئي سگهجي. هي ClickHouse کان گهڻو وڌيڪ پيچيده سافٽ ويئر آهي، جيڪو هڪ اندروني ڪلستر تي هلندو آهي، پر ڪلائنٽ جي نقطي نظر کان اهو ڪلڪ هائوس سان تمام گهڻو عام آهي. BigQuery جلدي مهانگو ٿي سگهي ٿو هڪ دفعو توهان في SELECT ادا ڪرڻ شروع ڪيو، تنهنڪري اهو هڪ سچو SaaS حل آهي ان جي سڀني فائدن ۽ نقصانن سان.
ڪلڪ هاؤس بهترين انتخاب آهي جڏهن توهان هلائي رهيا آهيو تمام گهڻا قيمتي سوال. وڌيڪ SELECT سوال جيڪي توهان هر روز هلائيندا آهيو، اوترو وڌيڪ اهو سمجهندو آهي بگ سوال کي ڪلڪ هاؤس سان تبديل ڪرڻ، ڇو ته اهڙي متبادل توهان کي هزارين ڊالر بچائي سگهي ٿي جڏهن اها ڊيٽا جي ڪيترن ئي ٽيرا بائيٽ جي پروسيس ٿيڻ جي اچي ٿي. اهو ذخيرو ٿيل ڊيٽا تي لاڳو نٿو ٿئي، جيڪو وڏي سوال ۾ پروسيس ڪرڻ لاء ڪافي سستو آهي.
Altinity جي گڏيل باني اليگزينڊر زيتسوف پاران هڪ مضمون ۾ اهڙي DBMS لڏپلاڻ جي فائدن بابت ڳالهائيندو آهي.
TimescaleDB متبادل
TimescaleDB هڪ PostgreSQL ايڪسٽينشن آهي جيڪا بهتر ڪري ٿي ٽائم سيريز ٽائيم سيريز سان گڏ ڪم ڪرڻ کي باقاعده ڊيٽابيس ۾ (, ).
جيتوڻيڪ ClickHouse وقت جي سيريز جي جڳهه ۾ هڪ سنگين مدمقابل نه آهي، پر ڪالمن جي جوڙجڪ ۽ ویکٹر سوالن تي عمل ڪرڻ، اهو تجزياتي سوال پروسيسنگ جي اڪثر ڪيسن ۾ TimescaleDB کان گهڻو تيز آهي. ساڳئي وقت، ClickHouse کان بيچ ڊيٽا حاصل ڪرڻ جي ڪارڪردگي تقريبن 3 ڀيرا وڌيڪ آهي، ۽ اهو پڻ 20 ڀيرا گهٽ ڊسڪ اسپيس استعمال ڪري ٿو، جيڪو تاريخي ڊيٽا جي وڏي مقدار جي پروسيسنگ لاء واقعي اهم آهي: .
ClickHouse جي برعڪس، TimescaleDB ۾ ڪجهه ڊسڪ اسپيس بچائڻ جو واحد طريقو ZFS يا ساڳي فائيل سسٽم استعمال ڪرڻ آهي.
ClickHouse تي ايندڙ تازه ڪاريون ممڪن طور تي ڊيلٽا ڪمپريشن کي متعارف ڪرايو ويندو، جيڪو ان کي پروسيسنگ ۽ ٽائيم سيريز ڊيٽا کي محفوظ ڪرڻ لاء اڃا به وڌيڪ موزون بڻائيندو. TimescaleDB ھيٺ ڏنل ڪيسن ۾ بيئر ClickHouse کان بھتر انتخاب ٿي سگھي ٿو.
- ننڍي تنصيب تمام ٿوري رام سان (<3 GB)؛
- ننڍڙن INSERTs جو هڪ وڏو تعداد جنهن کي توهان وڏي ٽڪرن ۾ بفر ڪرڻ نٿا چاهيو؛
- بهتر استحڪام، يونيفارم ۽ ACID گهرجن؛
- PostGIS سپورٽ؛
- موجوده PostgreSQL جدولن سان شامل ٿيڻ، ڇو ته Timescale DB بنيادي طور تي PostgreSQL آهي.
Hadoop ۽ MapReduce سسٽم سان مقابلو
Hadoop ۽ ٻيون MapReduce پراڊڪٽس تمام گھڻا پيچيده حساب ڪري سگھن ٿا، پر اھي وڏي دير سان ھلندا آھن. ClickHouse ھن مسئلي کي حل ڪري ٿو terabytes ڊيٽا جي پروسيسنگ ذريعي ۽ نتيجن کي لڳ ڀڳ فوري طور تي. اهڙيءَ طرح، ڪلڪ هاؤس تمام گهڻو اثرائتو آهي پرفارمنس تي تيز، انٽرايڪٽو تجزياتي تحقيق، جنهن کي ڊيٽا سائنسدانن جي دلچسپي هجڻ گهرجي.
Pinot ۽ Druid سان مقابلو
ClickHouse جا ويجھا مقابلا آھن ڪالمن، لڪير طور اسڪيلبل اوپن سورس پروڊڪٽس Pinot ۽ Druid. انهن سسٽم جي مقابلي ۾ هڪ بهترين ڪم آرٽيڪل ۾ شايع ٿيل آهي تاريخ 1 فيبروري 2018
ھن آرٽيڪل کي اپڊيٽ ڪرڻ جي ضرورت آھي - اھو چوي ٿو ته ClickHouse UPDATE ۽ DELETE عملن کي سپورٽ نٿو ڪري، جيڪو مڪمل طور تي جديد ورزن لاءِ صحيح نه آھي.
اسان وٽ انهن ڊيٽابيسن سان تمام گهڻو تجربو ناهي، پر مون کي بنيادي طور تي بنيادي ڍانچي جي پيچيدگي پسند نه آهي جيڪا Druid ۽ Pinot کي هلائڻ لاء گهربل آهي - اهو سڀني طرفن تي جاوا جي چوڌاري هلندڙ حصن جو هڪ سڄو گروپ آهي.
Druid ۽ Pinot Apache incubator منصوبا آھن، جن جي ترقي تفصيل سان ڍڪيل آھي اپاچي پنھنجي GitHub پروجيڪٽ جي صفحن تي. Pinot آڪٽوبر 2018 ۾ انڪيوبيٽر ۾ ظاهر ٿيو، ۽ ڊروڊ 8 مهينا اڳ ڄائو هو - فيبروري ۾.
AFS ڪيئن ڪم ڪري ٿو ان بابت معلومات جي کوٽ مون لاءِ ڪجهه، ۽ شايد بيوقوف، سوال اٿاري ٿي. مون کي عجب لڳو ته پنٽ ليکڪن اهو محسوس ڪيو ته اپاچي فائونڊيشن ڊروڊ جي لاءِ وڌيڪ سازگار آهي، ۽ ڇا اهو رويو مقابلي لاءِ حسد جو احساس پيدا ڪري ٿو؟ ڇا ڊروڊ جي ترقي سست ٿي ويندي ۽ پنوٽ جي ترقي تيز ٿي ويندي جيڪڏهن اوچتو اڳين جا پٺاڻ اوچتو بعد ۾ دلچسپي وٺندا؟
ClickHouse جا نقصان
ناپائيداري: ظاهر آهي، اهو اڃا تائين بورنگ ٽيڪنالاجي ناهي، پر ڪنهن به صورت ۾، اهڙي ڪا به شيء ٻين ڪالمن ڊي بي ايم ايسز ۾ نه آهي.
ننڍيون داخلون تيز رفتار سان سٺي ڪارڪردگي نه ٿيون ڪن: داخلن کي وڏن حصن ۾ ورهايو وڃي ڇاڪاڻ ته ننڍن داخلن جي ڪارڪردگي هر قطار ۾ ڪالمن جي تعداد جي تناسب ۾ گهٽجي ويندي آهي. اهڙي طرح ڪلڪ هائوس ڊسڪ تي ڊيٽا محفوظ ڪري ٿو - هر ڪالم 1 فائل يا وڌيڪ نمائندگي ڪري ٿو، تنهنڪري 1 ڪالمن تي مشتمل 100 قطار داخل ڪرڻ لاء، توهان کي گهٽ ۾ گهٽ 100 فائلون کولڻ ۽ لکڻ جي ضرورت آهي. اهو ئي سبب آهي ته بفرنگ داخل ڪرڻ لاءِ وچولي جي ضرورت هوندي آهي (جيستائين ڪلائنٽ پاڻ بفرنگ فراهم نه ڪري) - عام طور تي ڪافڪا يا ڪنهن قسم جو قطار مينيجمينٽ سسٽم. توھان پڻ استعمال ڪري سگھوٿا بفر ٽيبل انجڻ بعد ۾ ڊيٽا جي وڏي حصن کي MergeTree جدولن ۾ نقل ڪرڻ لاءِ.
ٽيبل جوائنس سرور جي رام طرفان محدود آهن، پر گهٽ ۾ گهٽ اهي آهن! مثال طور، Druid ۽ Pinot ۾ اهڙا ڪنيڪشن نه آهن، ڇاڪاڻ ته اهي سڌو سنئون ورهايل سسٽم ۾ لاڳو ڪرڻ ڏکيو آهن جيڪي نوڊس جي وچ ۾ ڊيٽا جي وڏي حصن کي منتقل ڪرڻ جي حمايت نٿا ڪن.
پهچڻ
اسان ايندڙ سالن ۾ Qwintry ۾ ClickHouse کي وڏي پيماني تي استعمال ڪرڻ جي منصوبابندي ڪريون ٿا، ڇاڪاڻ ته هي DBMS ڪارڪردگي جو هڪ بهترين توازن، گهٽ اوور هيڊ، اسڪيبلٽي ۽ سادگي مهيا ڪري ٿو. مون کي پڪ آهي ته اهو جلدي پکڙجڻ شروع ٿي ويندو جڏهن ڪلڪ هاؤس ڪميونٽي ان کي استعمال ڪرڻ جا وڌيڪ طريقا کڻي ايندي ته ان کي ننڍي کان وچين سائيز جي تنصيبات ۾.
ڪجھ اشتهار 🙂
اسان سان گڏ رهڻ لاء توهان جي مهرباني. ڇا توهان اسان جا مضمون پسند ڪندا آهيو؟ وڌيڪ دلچسپ مواد ڏسڻ چاهيو ٿا؟ آرڊر ڏيڻ يا دوستن کي سفارش ڪندي اسان جي مدد ڪريو، , داخلا-سطح سرورز جو هڪ منفرد اينالاگ، جيڪو اسان توهان لاءِ ايجاد ڪيو هو: (RAID1 ۽ RAID10 سان دستياب آهي، 24 ڪور تائين ۽ 40GB DDR4 تائين).
ڊيل R730xd 2x سستا Equinix Tier IV ڊيٽا سينٽر ۾ Amsterdam ۾؟ صرف هتي هالينڊ ۾! ڊيل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 کان! جي باري ۾ پڙهو
جو ذريعو: www.habr.com