آن لائن تجزیاتی استفسار پروسیسنگ (OLAP) کے لیے ایک اوپن سورس کالمر ڈیٹا بیس مینجمنٹ سسٹم ہے، جسے Yandex نے بنایا ہے۔ یہ Yandex، CloudFlare، VK.com، Badoo اور دنیا بھر میں دیگر سروسز کے ذریعے واقعی بڑی مقدار میں ڈیٹا (ہزاروں قطاریں فی سیکنڈ یا ڈسک پر ذخیرہ شدہ ڈیٹا کی پیٹا بائٹس داخل کرنا) ذخیرہ کرنے کے لیے استعمال کیا جاتا ہے۔
ایک باقاعدہ، "سٹرنگ" DBMS میں، جس کی مثالیں MySQL، Postgres، MS SQL Server ہیں، ڈیٹا کو درج ذیل ترتیب میں محفوظ کیا جاتا ہے:
اس صورت میں، ایک قطار سے متعلق قدریں جسمانی طور پر قریب ہی محفوظ ہوتی ہیں۔ کالم DBMSs میں، مختلف کالموں کی قدروں کو الگ الگ ذخیرہ کیا جاتا ہے، اور ایک کالم کا ڈیٹا ایک ساتھ ذخیرہ کیا جاتا ہے:
کالم DBMSs کی مثالیں 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 میں شروع کیا اور اس کی سادگی، اسکیل ایبلٹی، ایس کیو ایل سپورٹ اور رفتار سے بہت متاثر ہوا۔ اس DBMS کی رفتار جادو سے جڑی ہوئی ہے۔
کو کم
کلک ہاؤس اوبنٹو پر ایک ہی کمانڈ کے ساتھ انسٹال ہے۔ اگر آپ ایس کیو ایل کو جانتے ہیں تو آپ فوری طور پر اپنی ضروریات کے لیے کلک ہاؤس کا استعمال شروع کر سکتے ہیں۔ تاہم، اس کا مطلب یہ نہیں ہے کہ آپ MySQL میں "شو تخلیق ٹیبل" کر سکتے ہیں اور کلک ہاؤس میں ایس کیو ایل کو کاپی پیسٹ کر سکتے ہیں۔
MySQL کے مقابلے میں، ٹیبل اسکیما کی تعریفوں میں ڈیٹا کی قسم کے اہم فرق ہیں، اس لیے آپ کو ابھی بھی ٹیبل اسکیما کی تعریفوں کو تبدیل کرنے اور آرام سے رہنے کے لیے ٹیبل انجن سیکھنے میں کچھ وقت درکار ہوگا۔
کلک ہاؤس بغیر کسی اضافی سافٹ ویئر کے بہت اچھا کام کرتا ہے، لیکن اگر آپ نقل استعمال کرنا چاہتے ہیں، تو آپ کو ZooKeeper انسٹال کرنے کی ضرورت ہوگی۔ استفسار کی کارکردگی کا تجزیہ بہترین نتائج دکھاتا ہے - سسٹم ٹیبل میں تمام معلومات موجود ہیں، اور تمام ڈیٹا کو پرانے اور بورنگ SQL کا استعمال کرتے ہوئے بازیافت کیا جا سکتا ہے۔
کارکردگی
- سرور کنفیگریشن پر Vertica اور MySQL کے ساتھ Clickhouse کا موازنہ: دو ساکٹ Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz؛ 128 جی بی ریم؛ md RAID-5 8 6TB SATA HDD، ext4 پر۔
- ایمیزون ریڈ شفٹ کلاؤڈ اسٹوریج کے ساتھ کلک ہاؤس کا موازنہ۔
- بلاگ کے اقتباسات :
ClickHouse ڈیٹابیس کا ڈیزائن بہت آسان ہے - کلسٹر کے تمام نوڈس ایک جیسی فعالیت رکھتے ہیں اور صرف کوآرڈینیشن کے لیے ZooKeeper استعمال کرتے ہیں۔ ہم نے کئی نوڈس کا ایک چھوٹا سا کلسٹر بنایا اور جانچ کی، جس کے دوران ہم نے پایا کہ سسٹم کی کارکردگی کافی متاثر کن ہے، جو کہ تجزیاتی DBMS بینچ مارکس میں بیان کردہ فوائد کے مساوی ہے۔ ہم نے ClickHouse کے پیچھے تصور پر گہری نظر ڈالنے کا فیصلہ کیا۔ تحقیق کی راہ میں پہلی رکاوٹ ٹولز کی کمی اور کلک ہاؤس کی چھوٹی کمیونٹی تھی، اس لیے ہم نے اس DBMS کے ڈیزائن کا جائزہ لیا تاکہ یہ سمجھ سکیں کہ یہ کیسے کام کرتا ہے۔
ClickHouse کافکا سے براہ راست ڈیٹا وصول کرنے کی حمایت نہیں کرتا ہے کیونکہ یہ صرف ایک ڈیٹا بیس ہے، اس لیے ہم نے Go میں اپنی اڈاپٹر سروس لکھی ہے۔ اس نے کافکا کے Cap'n Proto انکوڈ شدہ پیغامات کو پڑھا، انہیں TSV میں تبدیل کیا اور HTTP انٹرفیس کے ذریعے بیچوں میں کلک ہاؤس میں داخل کیا۔ ہم نے بعد میں اس سروس کو دوبارہ لکھا تاکہ Go لائبریری کو ClickHouse کے اپنے انٹرفیس کے ساتھ مل کر کارکردگی کو بہتر بنایا جا سکے۔ پیکٹ وصول کرنے کی کارکردگی کا جائزہ لیتے وقت، ہم نے ایک اہم چیز دریافت کی - یہ پتہ چلا کہ ClickHouse کے لیے یہ کارکردگی کافی حد تک پیکٹ کے سائز پر منحصر ہے، یعنی بیک وقت داخل کی گئی قطاروں کی تعداد۔ یہ سمجھنے کے لیے کہ ایسا کیوں ہوتا ہے، ہم نے دیکھا کہ کس طرح کلک ہاؤس ڈیٹا کو اسٹور کرتا ہے۔
مرکزی انجن، یا ٹیبل انجنوں کا خاندان، جو کلک ہاؤس ڈیٹا کو ذخیرہ کرنے کے لیے استعمال کرتا ہے وہ مرجٹری ہے۔ یہ انجن تصوراتی طور پر گوگل بگ ٹیبل یا اپاچی کیسینڈرا میں استعمال ہونے والے ایل ایس ایم الگورتھم سے ملتا جلتا ہے، لیکن انٹرمیڈیٹ میموری ٹیبل بنانے سے گریز کرتا ہے اور ڈیٹا کو براہ راست ڈسک پر لکھتا ہے۔ یہ اسے بہترین تحریری تھرو پٹ دیتا ہے، کیونکہ ہر داخل کردہ پیکٹ کو صرف بنیادی کلید کے ذریعے ترتیب دیا جاتا ہے، کمپریس کیا جاتا ہے، اور ایک طبقہ بنانے کے لیے ڈسک پر لکھا جاتا ہے۔
میموری ٹیبل کی عدم موجودگی یا ڈیٹا کی "تازگی" کے کسی تصور کا مطلب یہ ہے کہ انہیں صرف شامل کیا جا سکتا ہے؛ سسٹم تبدیل کرنے یا حذف کرنے کی حمایت نہیں کرتا ہے۔ فی الحال، ڈیٹا کو حذف کرنے کا واحد طریقہ کیلنڈر مہینے کے مطابق اسے حذف کرنا ہے، کیونکہ طبقات کبھی بھی مہینے کی حد سے تجاوز نہیں کرتے ہیں۔ ClickHouse ٹیم اس خصوصیت کو حسب ضرورت بنانے کے لیے سرگرم عمل ہے۔ دوسری طرف، یہ لکھنے اور ضم کرنے والے حصوں کو تنازعات سے پاک بناتا ہے، لہذا I/O یا بنیادی سنترپتی ہونے تک ہم آہنگی داخلوں کی تعداد کے ساتھ لکیری طور پر تھرو پٹ اسکیلز حاصل کریں۔
تاہم، اس کا مطلب یہ بھی ہے کہ یہ نظام چھوٹے پیکٹوں کے لیے موزوں نہیں ہے، اس لیے کافکا سروسز اور انسرٹرز بفرنگ کے لیے استعمال کیے جاتے ہیں۔ اس کے بعد، پس منظر میں کلک ہاؤس مسلسل سیگمنٹ انضمام کو انجام دیتا رہتا ہے، تاکہ معلومات کے بہت سے چھوٹے ٹکڑوں کو یکجا کیا جائے اور زیادہ بار ریکارڈ کیا جائے، اس طرح ریکارڈنگ کی شدت میں اضافہ ہوتا ہے۔ تاہم، جب تک انضمام جاری رہے گا بہت زیادہ غیر منسلک حصے داخلوں کی جارحانہ تھروٹلنگ کا سبب بنیں گے۔ ہم نے پایا ہے کہ ریئل ٹائم ادخال اور ادخال کی کارکردگی کے درمیان بہترین سمجھوتہ ٹیبل میں فی سیکنڈ محدود تعداد میں داخل کرنا ہے۔
ٹیبل ریڈ پرفارمنس کی کلید انڈیکسنگ اور ڈسک پر ڈیٹا کی لوکیشن ہے۔ اس بات سے کوئی فرق نہیں پڑتا ہے کہ پروسیسنگ کتنی تیز ہے، جب انجن کو ڈسک سے ٹیرا بائٹس ڈیٹا کو اسکین کرنے اور اس کے صرف ایک حصے کو استعمال کرنے کی ضرورت ہوتی ہے، اس میں وقت لگے گا۔ کلک ہاؤس ایک کالمی اسٹور ہے، لہذا ہر سیگمنٹ میں ہر کالم (کالم) کے لیے ہر قطار کے لیے ترتیب شدہ اقدار کے ساتھ ایک فائل ہوتی ہے۔ اس طرح، استفسار سے غائب پورے کالموں کو پہلے چھوڑا جا سکتا ہے، اور پھر متعدد سیلز کو ویکٹرائزڈ ایگزیکیوشن کے متوازی طور پر پروسیس کیا جا سکتا ہے۔ مکمل اسکین سے بچنے کے لیے، ہر سیگمنٹ میں ایک چھوٹی انڈیکس فائل ہوتی ہے۔
یہ دیکھتے ہوئے کہ تمام کالموں کو "پرائمری کلید" کے ذریعے ترتیب دیا گیا ہے، انڈیکس فائل میں صرف ہر Nth قطار کے لیبلز (کیپچر شدہ قطاروں) پر مشتمل ہوتا ہے تاکہ انہیں بہت بڑی میزوں کے لیے بھی میموری میں رکھا جاسکے۔ مثال کے طور پر، آپ ڈیفالٹ سیٹنگز کو "ہر 8192ویں قطار کو نشان زد کریں"، پھر 1 ٹریلین والے ٹیبل کی "معمولی" انڈیکسنگ پر سیٹ کر سکتے ہیں۔ وہ لائنیں جو میموری میں آسانی سے فٹ ہوجاتی ہیں صرف 122 حروف لے گی۔
نظام کی ترقی
کلک ہاؤس کی ترقی اور بہتری کا پتہ لگایا جا سکتا ہے۔ اور یقینی بنائیں کہ "بڑھنے" کا عمل متاثر کن رفتار سے ہوتا ہے۔
مقبولیت
ایسا لگتا ہے کہ کلک ہاؤس کی مقبولیت تیزی سے بڑھ رہی ہے، خاص طور پر روسی بولنے والی کمیونٹی میں۔ پچھلے سال کی ہائی لوڈ 2018 کانفرنس (ماسکو، 8-9 نومبر، 2018) نے ظاہر کیا کہ vk.com اور Badoo جیسے مونسٹر کلک ہاؤس کا استعمال کرتے ہیں، جس کے ساتھ وہ بیک وقت دسیوں ہزار سرورز سے ڈیٹا (مثال کے طور پر لاگز) داخل کرتے ہیں۔ 40 منٹ کی ویڈیو میں . مواد کے ساتھ کام کرنے میں آسانی کے لیے ہم جلد ہی نقل کو حبر پر پوسٹ کریں گے۔
درخواستیں
تحقیق میں کچھ وقت گزارنے کے بعد، میرے خیال میں ایسے علاقے ہیں جہاں ClickHouse کارآمد ہو سکتا ہے یا مکمل طور پر دوسرے، زیادہ روایتی اور مقبول حلوں کی جگہ لے سکتا ہے جیسے MySQL، PostgreSQL، ELK، Google Big Query، Amazon RedShift، TimescaleDB، Hadoop، MapReduce، Pinot اور ڈریوڈ مندرجہ ذیل DBMS کو جدید بنانے یا مکمل طور پر تبدیل کرنے کے لیے ClickHouse کے استعمال کی تفصیلات بیان کرتا ہے۔
MySQL اور PostgreSQL کی صلاحیتوں کو بڑھانا
ابھی حال ہی میں ہم نے MySQL کو جزوی طور پر اپنے نیوز لیٹر پلیٹ فارم کے لیے ClickHouse سے تبدیل کر دیا ہے۔ . مسئلہ یہ تھا کہ MySQL، ناقص ڈیزائن کی وجہ سے، بھیجی گئی ہر ای میل اور اس ای میل میں موجود ہر لنک کو بیس 64 ہیش کے ساتھ لاگ کر رہا تھا، جس سے MySQL کا ایک بہت بڑا ٹیبل (email_stats) بن رہا تھا۔ سروس سبسکرائبرز کو صرف 10 ملین ای میلز بھیجنے کے بعد، اس ٹیبل نے 150 GB فائل کی جگہ پر قبضہ کر لیا، اور MySQL سادہ سوالات پر "احمقانہ" ہونے لگا۔ فائل کی جگہ کے مسئلے کو حل کرنے کے لیے، ہم نے کامیابی کے ساتھ InnoDB ٹیبل کمپریشن کا استعمال کیا جس نے اسے 4 کے عنصر سے کم کردیا۔ تاہم، صرف تاریخ کو پڑھنے کی خاطر MySQL میں 20-30 ملین سے زیادہ ای میلز کو ذخیرہ کرنا اب بھی کوئی معنی نہیں رکھتا، کیونکہ کوئی بھی سادہ سوال جس کو کسی وجہ سے مکمل اسکین کرنے کی ضرورت ہوتی ہے اس کے نتیجے میں تبادلہ ہوتا ہے اور بہت سارے /O لوڈ، جس کے بارے میں ہمیں باقاعدگی سے Zabbix سے انتباہات موصول ہوتے ہیں۔
کلک ہاؤس دو کمپریشن الگورتھم استعمال کرتا ہے جو ڈیٹا کے حجم کو تقریباً کم کرتا ہے۔ ، لیکن اس خاص معاملے میں ڈیٹا خاص طور پر "کمپریس ایبل" تھا۔
ELK کو تبدیل کرنا
میرے اپنے تجربے کی بنیاد پر، ELK اسٹیک (ElasticSearch، Logstash اور Kibana، اس خاص معاملے میں ElasticSearch) کو لاگز کو ذخیرہ کرنے کی ضرورت سے کہیں زیادہ وسائل کی ضرورت ہوتی ہے۔ اگر آپ کو اچھی فل ٹیکسٹ لاگ سرچ کی ضرورت ہو تو ElasticSearch ایک بہترین انجن ہے (جس کی میرے خیال میں آپ کو واقعی ضرورت نہیں ہے)، لیکن میں حیران ہوں کہ یہ ڈی فیکٹو معیاری لاگنگ انجن کیوں بن گیا ہے۔ Logstash کے ساتھ مل کر اس کی انجسٹ کارکردگی نے ہمیں کافی ہلکے بوجھ میں بھی مسائل پیدا کیے اور ہمیں زیادہ سے زیادہ RAM اور ڈسک کی جگہ شامل کرنے کی ضرورت پڑی۔ ڈیٹا بیس کے طور پر، Clickhouse درج ذیل وجوہات کی بنا پر ElasticSearch سے بہتر ہے۔
- ایس کیو ایل بولی سپورٹ؛
- ذخیرہ شدہ ڈیٹا کے کمپریشن کی بہترین ڈگری؛
- مکمل متن کی تلاش کے بجائے ریجیکس ریگولر ایکسپریشن کی تلاش کے لیے سپورٹ؛
- بہتر استفسار کا شیڈولنگ اور اعلی مجموعی کارکردگی۔
فی الحال، سب سے بڑا مسئلہ جو ClickHouse کا ELK سے موازنہ کرتے وقت پیدا ہوتا ہے وہ ہے لاگز اپ لوڈ کرنے کے لیے حل کی کمی کے ساتھ ساتھ اس موضوع پر دستاویزات اور سبق کی کمی۔ مزید یہ کہ، ہر صارف ڈیجیٹل اوشین مینوئل کا استعمال کرتے ہوئے ELK کو ترتیب دے سکتا ہے، جو اس طرح کی ٹیکنالوجیز کے تیزی سے نفاذ کے لیے بہت اہم ہے۔ ایک ڈیٹا بیس انجن ہے، لیکن کلک ہاؤس کے لیے ابھی تک کوئی فائل بیٹ نہیں ہے۔ جی ہاں، یہ وہاں ہے اور لاگز کے ساتھ کام کرنے کا نظام ، ایک آلہ ہے کلک ہاؤس میں لاگ فائل کا ڈیٹا داخل کرنے کے لیے، لیکن اس سب میں زیادہ وقت لگتا ہے۔ تاہم، ClickHouse اپنی سادگی کی وجہ سے اب بھی سرفہرست ہے، لہٰذا ابتدائی افراد بھی اسے آسانی سے انسٹال کر سکتے ہیں اور صرف 10 منٹ میں اسے مکمل طور پر فعال طور پر استعمال کرنا شروع کر سکتے ہیں۔
کم سے کم حل کو ترجیح دیتے ہوئے، میں نے کافکا کے استعمال سے بچنے کی کوشش کرتے ہوئے، کلک ہاؤس کے ساتھ، بہت کم میموری والے لاگز بھیجنے کے لیے ایک ٹول FluentBit کو استعمال کرنے کی کوشش کی۔ تاہم، معمولی عدم مطابقتوں کو حل کرنے کی ضرورت ہے، جیسے اس سے پہلے یہ پراکسی لیئر کے بغیر کیا جا سکتا ہے جو ڈیٹا کو FluentBit سے ClickHouse میں تبدیل کرتی ہے۔
متبادل کے طور پر، Kibana کو ClickHouse بیک اینڈ کے طور پر استعمال کیا جا سکتا ہے۔ . میں جو سمجھتا ہوں اس سے، یہ کارکردگی کے مسائل کا سبب بن سکتا ہے جب بڑی تعداد میں ڈیٹا پوائنٹس پیش کرتے ہیں، خاص طور پر گرافانا کے پرانے ورژن کے ساتھ۔ ہم نے ابھی تک Qwintry میں اس کی کوشش نہیں کی ہے، لیکن اس بارے میں شکایات وقتاً فوقتاً ٹیلی گرام میں ClickHouse سپورٹ چینل پر ظاہر ہوتی رہتی ہیں۔
Google Big Query اور Amazon RedShift کی تبدیلی (بڑی کمپنیوں کے لیے حل)
BigQuery کے لیے مثالی استعمال کا معاملہ JSON ڈیٹا کا 1 TB لوڈ کرنا اور اس پر تجزیاتی استفسارات چلانا ہے۔ Big Query ایک بہترین پروڈکٹ ہے جس کی توسیع پذیری کو بڑھاوا نہیں دیا جا سکتا۔ یہ ClickHouse سے کہیں زیادہ پیچیدہ سافٹ ویئر ہے، جو ایک اندرونی کلسٹر پر چلتا ہے، لیکن کلائنٹ کے نقطہ نظر سے یہ ClickHouse کے ساتھ بہت زیادہ مشترک ہے۔ ایک بار جب آپ فی SELECT ادائیگی کرنا شروع کر دیتے ہیں تو BigQuery تیزی سے مہنگا ہو سکتا ہے، لہذا یہ اپنے تمام فوائد اور نقصانات کے ساتھ ایک حقیقی SaaS حل ہے۔
کلک ہاؤس بہترین انتخاب ہے جب آپ کمپیوٹیشنل طور پر مہنگے سوالات چلا رہے ہوں۔ آپ روزانہ جتنے زیادہ SELECT سوالات چلاتے ہیں، اتنا ہی زیادہ سمجھ میں آتا ہے Big Query کو ClickHouse سے تبدیل کرنا، کیونکہ اس طرح کی تبدیلی آپ کے ہزاروں ڈالر کی بچت کر سکتی ہے جب بہت سے ٹیرا بائٹس ڈیٹا پر کارروائی کی جائے۔ یہ ذخیرہ شدہ ڈیٹا پر لاگو نہیں ہوتا ہے، جس پر Big Query میں کارروائی کرنا کافی سستا ہے۔
Altinity کے شریک بانی الیگزینڈر زیٹسیف کے ایک مضمون میں ایسی DBMS منتقلی کے فوائد کے بارے میں بات کرتا ہے۔
ٹائم اسکیل ڈی بی کی تبدیلی
TimescaleDB ایک PostgreSQL ایکسٹینشن ہے جو ٹائم سیریز ٹائم سیریز کے ساتھ باقاعدہ ڈیٹا بیس میں کام کرنے کو بہتر بناتا ہے (, ).
اگرچہ کلک ہاؤس ٹائم سیریز کے طاق میں کوئی سنجیدہ حریف نہیں ہے، لیکن کالمی ڈھانچہ اور ویکٹر کے استفسار پر عمل درآمد، یہ تجزیاتی استفسار کی کارروائی کے زیادہ تر معاملات میں TimescaleDB سے زیادہ تیز ہے۔ ایک ہی وقت میں، ClickHouse سے بیچ ڈیٹا حاصل کرنے کی کارکردگی تقریباً 3 گنا زیادہ ہے، اور یہ 20 گنا کم ڈسک کی جگہ بھی استعمال کرتا ہے، جو کہ تاریخی ڈیٹا کی بڑی مقدار پر کارروائی کرنے کے لیے واقعی اہم ہے: .
ClickHouse کے برعکس، TimescaleDB میں کچھ ڈسک کی جگہ بچانے کا واحد طریقہ ZFS یا اسی طرح کے فائل سسٹم کا استعمال ہے۔
ClickHouse میں آنے والی اپ ڈیٹس ممکنہ طور پر ڈیلٹا کمپریشن کو متعارف کرائے گی، جو اسے ٹائم سیریز کے ڈیٹا کی پروسیسنگ اور ذخیرہ کرنے کے لیے اور بھی موزوں بنائے گی۔ TimescaleDB درج ذیل صورتوں میں ننگے ClickHouse سے بہتر انتخاب ہو سکتا ہے:
- بہت کم RAM کے ساتھ چھوٹی تنصیبات (<3 GB)؛
- چھوٹی INSERTs کی ایک بڑی تعداد جسے آپ بڑے ٹکڑوں میں بفر نہیں کرنا چاہتے ہیں۔
- بہتر مستقل مزاجی، یکسانیت اور ACID کی ضروریات؛
- پوسٹ جی آئی ایس سپورٹ؛
- موجودہ PostgreSQL ٹیبلز کے ساتھ شامل ہونا، کیونکہ Timescale DB بنیادی طور پر PostgreSQL ہے۔
Hadoop اور MapReduce سسٹمز کے ساتھ مقابلہ
Hadoop اور دیگر MapReduce پروڈکٹس بہت زیادہ پیچیدہ حسابات کر سکتے ہیں، لیکن وہ بہت زیادہ تاخیر کے ساتھ چلتے ہیں۔ ClickHouse ٹیرا بائٹس ڈیٹا پر کارروائی کرکے اور تقریباً فوری طور پر نتائج پیدا کرکے اس مسئلے کو حل کرتا ہے۔ اس طرح، ClickHouse تیز رفتار، انٹرایکٹو تجزیاتی تحقیق کو انجام دینے میں بہت زیادہ مؤثر ہے، جو ڈیٹا سائنسدانوں کے لیے دلچسپی کا باعث ہونی چاہیے۔
Pinot اور Druid کے ساتھ مقابلہ
کلک ہاؤس کے قریب ترین حریف کالم، لکیری طور پر توسیع پذیر اوپن سورس مصنوعات Pinot اور Druid ہیں۔ ان نظاموں کا موازنہ کرنے والا ایک بہترین کام مضمون میں شائع ہوا ہے۔ مورخہ 1 فروری 2018
اس مضمون کو اپ ڈیٹ کرنے کی ضرورت ہے - یہ کہتا ہے کہ ClickHouse اپ ڈیٹ اور ڈیلیٹ آپریشنز کو سپورٹ نہیں کرتا، جو کہ تازہ ترین ورژنز کے لیے مکمل طور پر درست نہیں ہے۔
ہمارے پاس ان ڈیٹا بیس کے ساتھ بہت زیادہ تجربہ نہیں ہے، لیکن مجھے درحقیقت بنیادی ڈھانچے کی پیچیدگی پسند نہیں ہے جو ڈروڈ اور پنوٹ کو چلانے کے لیے درکار ہے - یہ ہر طرف سے جاوا سے گھرے ہوئے حصوں کا ایک پورا گروپ ہے۔
Druid اور Pinot اپاچی انکیوبیٹر پروجیکٹس ہیں، جن کی پیشرفت کو اپاچی نے اپنے GitHub پروجیکٹ کے صفحات پر تفصیل سے بتایا ہے۔ پنوٹ اکتوبر 2018 میں انکیوبیٹر میں نمودار ہوا، اور ڈروڈ کی پیدائش 8 ماہ قبل فروری میں ہوئی تھی۔
AFS کیسے کام کرتا ہے اس کے بارے میں معلومات کی کمی میرے لیے کچھ، اور شاید احمقانہ سوالات پیدا کرتی ہے۔ مجھے حیرت ہے کہ کیا پنوٹ کے مصنفین نے دیکھا کہ اپاچی فاؤنڈیشن ڈروڈ کے لیے زیادہ سازگار ہے، اور کیا حریف کے ساتھ یہ رویہ حسد کا باعث بنا؟ کیا ڈروڈ کی ترقی سست ہو جائے گی اور پنوٹ کی ترقی کی رفتار تیز ہو جائے گی اگر سابق کے حامی اچانک بعد میں دلچسپی لیتے ہیں؟
کلک ہاؤس کے نقصانات
ناپختگی: ظاہر ہے، یہ اب بھی بورنگ ٹیکنالوجی نہیں ہے، لیکن کسی بھی صورت میں، دیگر کالمی ڈی بی ایم ایس میں ایسا کچھ نہیں دیکھا جاتا۔
چھوٹے داخلے تیز رفتاری سے اچھی کارکردگی کا مظاہرہ نہیں کرتے: داخلوں کو بڑے حصوں میں تقسیم کیا جانا چاہیے کیونکہ چھوٹے داخلوں کی کارکردگی ہر قطار میں کالموں کی تعداد کے تناسب سے کم ہوتی ہے۔ اس طرح کلک ہاؤس ڈسک پر ڈیٹا اسٹور کرتا ہے - ہر کالم 1 فائل یا اس سے زیادہ کی نمائندگی کرتا ہے، لہذا 1 کالموں پر مشتمل 100 قطار داخل کرنے کے لیے، آپ کو کم از کم 100 فائلیں کھولنے اور لکھنے کی ضرورت ہے۔ یہی وجہ ہے کہ بفرنگ انسرٹس کے لیے ایک مڈل مین کی ضرورت ہوتی ہے (جب تک کہ کلائنٹ خود بفرنگ فراہم نہ کرے) - عام طور پر کافکا یا کسی قسم کا قطار کے انتظام کا نظام۔ آپ بعد میں ڈیٹا کے بڑے ٹکڑوں کو MergeTree ٹیبلز میں کاپی کرنے کے لیے بفر ٹیبل انجن کا استعمال بھی کر سکتے ہیں۔
ٹیبل جوائنز سرور کی RAM کے ذریعے محدود ہیں، لیکن کم از کم وہ وہاں موجود ہیں! مثال کے طور پر، Druid اور Pinot میں اس طرح کے کنکشن بالکل نہیں ہیں، کیونکہ ان کا براہ راست تقسیم شدہ نظاموں میں نفاذ مشکل ہے جو کہ نوڈس کے درمیان ڈیٹا کے بڑے ٹکڑوں کو منتقل کرنے کی حمایت نہیں کرتے ہیں۔
نتائج
ہم آنے والے سالوں میں Qwintry میں ClickHouse کو وسیع پیمانے پر استعمال کرنے کا ارادہ رکھتے ہیں، کیونکہ یہ DBMS کارکردگی، کم اوور ہیڈ، اسکیل ایبلٹی اور سادگی کا بہترین توازن فراہم کرتا ہے۔ مجھے پورا یقین ہے کہ جب کلک ہاؤس کمیونٹی اسے چھوٹے سے درمیانے سائز کی تنصیبات میں استعمال کرنے کے مزید طریقے لے کر آئے گی تو یہ تیزی سے پھیلنا شروع ہو جائے گا۔
کچھ اشتہارات 🙂
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔
ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا
ماخذ: www.habr.com