چونکہ کلک ہاؤس ایک خصوصی نظام ہے، اس لیے اسے استعمال کرتے وقت اس کے فن تعمیر کی خصوصیات کو مدنظر رکھنا ضروری ہے۔ اس رپورٹ میں، الیکسی کلک ہاؤس کا استعمال کرتے وقت عام غلطیوں کی مثالوں کے بارے میں بات کریں گے، جو کام کو بے اثر کر سکتی ہیں۔ عملی مثالیں دکھائے گی کہ کس طرح ایک یا دوسری ڈیٹا پروسیسنگ اسکیم کا انتخاب شدت کے حکم سے کارکردگی کو بدل سکتا ہے۔
سب کو سلام! میرا نام الیکسی ہے، میں کلک ہاؤس بناتا ہوں۔
سب سے پہلے، میں آپ کو خوش کرنے کے لیے جلدی کرتا ہوں، آج میں آپ کو یہ نہیں بتاؤں گا کہ کلک ہاؤس کیا ہے۔ سچ پوچھیں تو میں اس سے تھک گیا ہوں۔ ہر بار میں آپ کو بتاتا ہوں کہ یہ کیا ہے. اور شاید ہر کوئی پہلے ہی جانتا ہے۔
اس کے بجائے، میں آپ کو بتاؤں گا کہ اس میں کیا ممکنہ غلطیاں ہیں، یعنی آپ ClickHouse کو غلط طریقے سے کیسے استعمال کر سکتے ہیں۔ درحقیقت، ڈرنے کی کوئی ضرورت نہیں ہے، کیونکہ ہم ClickHouse کو ایک ایسے نظام کے طور پر تیار کر رہے ہیں جو سادہ، آسان اور باکس سے باہر کام کرتا ہے۔ میں نے اسے انسٹال کیا، کوئی مسئلہ نہیں۔
لیکن آپ کو پھر بھی اس بات کو ذہن میں رکھنے کی ضرورت ہے کہ یہ سسٹم مخصوص ہے اور آپ آسانی سے ایک غیر معمولی استعمال کے معاملے کو دیکھ سکتے ہیں جو اس سسٹم کو اس کے کمفرٹ زون سے باہر لے جائے گا۔
تو، وہاں کس قسم کی ریک ہے؟ زیادہ تر میں واضح چیزوں کے بارے میں بات کروں گا۔ سب کچھ سب پر عیاں ہے، ہر کوئی سب کچھ سمجھتا ہے اور خوش ہو سکتا ہے کہ وہ اتنے ہوشیار ہیں، اور جو نہیں سمجھتے وہ کچھ نیا سیکھیں گے۔
پہلی اور سب سے آسان مثال، جو بدقسمتی سے اکثر ہوتی ہے، چھوٹے بیچوں کے ساتھ بڑی تعداد میں داخل کرنا ہے، یعنی چھوٹے داخلوں کی ایک بڑی تعداد۔
اگر ہم غور کریں کہ ClickHouse کیسے داخل کرتا ہے، تو آپ ایک درخواست میں کم از کم ایک ٹیرا بائٹ ڈیٹا بھیج سکتے ہیں۔ یہ کوئی مسئلہ نہیں ہے.
اور آئیے دیکھتے ہیں کہ عام کارکردگی کیا ہوگی۔ مثال کے طور پر، ہمارے پاس Yandex.Metrica ڈیٹا سے ایک ٹیبل ہے۔ ہٹ۔ 105 کچھ کالم۔ 700 بائٹس غیر کمپریسڈ۔ اور ہم ایک ملین قطاروں کے بیچوں میں اچھے طریقے سے داخل کریں گے۔
ہم میز میں MergeTree داخل کرتے ہیں، اس سے نصف ملین قطاریں فی سیکنڈ نکلتی ہیں۔ زبردست. نقل شدہ جدول میں یہ تھوڑا چھوٹا ہوگا، تقریباً 400 قطاریں فی سیکنڈ۔
اور اگر آپ کورم اندراج کو فعال کرتے ہیں، تو آپ کو تھوڑا کم، لیکن پھر بھی اچھی کارکردگی، 250 شرائط فی سیکنڈ ملتی ہیں۔ کلک ہاؤس* میں کورم داخل کرنا ایک غیر دستاویزی خصوصیت ہے۔
* 2020 تک، .
اگر آپ کچھ برا کرتے ہیں تو کیا ہوتا ہے؟ ہم MergeTree ٹیبل میں ایک قطار داخل کرتے ہیں اور فی سیکنڈ 59 قطاریں حاصل کرتے ہیں۔ یہ 10 گنا سست ہے۔ ReplicatedMergeTree میں - 000 قطاریں فی سیکنڈ۔ اور اگر کورم آن کیا جائے تو 6 لائنیں فی سیکنڈ نکلتی ہیں۔ میری رائے میں، یہ ایک قسم کی مطلق گھٹیا پن ہے۔ آپ اس طرح سست کیسے ہوسکتے ہیں؟ یہاں تک کہ میں نے اپنی ٹی شرٹ پر لکھا ہے کہ کلک ہاؤس کو سست نہیں ہونا چاہئے۔ لیکن اس کے باوجود کبھی کبھی ایسا ہوتا ہے۔
دراصل یہ ہماری کوتاہی ہے۔ ہم آسانی سے سب کچھ ٹھیک کر سکتے تھے، لیکن ہم نے ایسا نہیں کیا۔ اور ہم نے ایسا نہیں کیا کیونکہ ہمارے اسکرپٹ کو اس کی ضرورت نہیں تھی۔ ہمارے پاس پہلے سے ہی قصاب تھے۔ ہمیں صرف اپنے داخلی راستے پر بیچ موصول ہوئے، اور کوئی مسئلہ نہیں۔ ہم اسے داخل کرتے ہیں اور سب کچھ ٹھیک کام کرتا ہے۔ لیکن، یقینا، ہر طرح کے منظرنامے ممکن ہیں۔ مثال کے طور پر، جب آپ کے پاس سرورز کا ایک گروپ ہے جس پر ڈیٹا تیار ہوتا ہے۔ اور وہ اتنی کثرت سے ڈیٹا داخل نہیں کرتے ہیں، لیکن پھر بھی وہ بار بار داخل ہوتے ہیں۔ اور ہمیں کسی نہ کسی طرح اس سے بچنے کی ضرورت ہے۔
تکنیکی نقطہ نظر سے، نقطہ یہ ہے کہ جب آپ کلک ہاؤس میں داخل کرتے ہیں، تو ڈیٹا کسی بھی یادداشت میں ختم نہیں ہوتا ہے۔ ہمارے پاس ایک حقیقی لاگ ڈھانچہ MergeTree بھی نہیں ہے، بلکہ صرف ایک MergeTree ہے، کیونکہ یہاں نہ تو کوئی لاگ ہے اور نہ ہی میم ٹیبل۔ ہم فوری طور پر ڈیٹا کو فائل سسٹم میں لکھتے ہیں، پہلے سے کالموں میں ترتیب دیا گیا ہے۔ اور اگر آپ کے پاس 100 کالم ہیں، تو 200 سے زیادہ فائلوں کو الگ ڈائرکٹری میں لکھنے کی ضرورت ہوگی۔ یہ سب بہت بوجھل ہے۔
اور سوال یہ پیدا ہوتا ہے: "یہ کیسے کریں؟" اگر صورتحال ایسی ہے کہ آپ کو اب بھی کسی نہ کسی طرح کلک ہاؤس میں ڈیٹا ریکارڈ کرنے کی ضرورت ہے۔
طریقہ 1۔ یہ سب سے آسان طریقہ ہے۔ کسی قسم کی تقسیم شدہ قطار کا استعمال کریں۔ مثال کے طور پر کافکا۔ آپ آسانی سے کافکا سے ڈیٹا نکالتے ہیں اور اسے سیکنڈ میں ایک بار بیچ دیتے ہیں۔ اور سب کچھ ٹھیک ہو جائے گا، آپ ریکارڈ کریں، سب کچھ ٹھیک کام کرتا ہے۔
نقصانات یہ ہیں کہ کافکا ایک اور بڑا تقسیم شدہ نظام ہے۔ میں یہ بھی سمجھتا ہوں کہ کیا آپ کی کمپنی میں کافکا پہلے سے موجود ہے۔ یہ اچھا ہے، یہ آسان ہے۔ لیکن اگر یہ موجود نہیں ہے، تو آپ کو اپنے پروجیکٹ میں ایک اور تقسیم شدہ نظام کو گھسیٹنے سے پہلے تین بار سوچنا چاہیے۔ اور اس طرح متبادلات پر غور کرنے کے قابل ہے۔
طریقہ 2۔ یہ ایک پرانے اسکول کا متبادل ہے اور ساتھ ہی بہت آسان ہے۔ کیا آپ کے پاس کسی قسم کا سرور ہے جو آپ کے لاگز تیار کرتا ہے۔ اور یہ صرف آپ کے لاگز کو ایک فائل میں لکھتا ہے۔ اور ایک سیکنڈ میں ایک بار، مثال کے طور پر، ہم اس فائل کا نام تبدیل کرتے ہیں اور ایک نئی فائل کو پھاڑ دیتے ہیں۔ اور ایک علیحدہ اسکرپٹ، یا تو کرون یا کسی ڈیمون کے ذریعے، سب سے پرانی فائل لیتا ہے اور اسے ClickHouse میں لکھتا ہے۔ اگر آپ ایک سیکنڈ میں ایک بار نوشتہ جات ریکارڈ کرتے ہیں تو سب کچھ ٹھیک ہو جائے گا۔
لیکن اس طریقہ کار کا نقصان یہ ہے کہ اگر آپ کا سرور جس پر لاگز تیار ہوتے ہیں وہ کہیں غائب ہو جائے تو ڈیٹا بھی غائب ہو جائے گا۔
طریقہ 3۔ ایک اور دلچسپ طریقہ ہے، جس کے لیے عارضی فائلوں کی ضرورت نہیں ہے۔ مثال کے طور پر، آپ کے پاس کسی قسم کا ایڈورٹائزنگ اسپنر یا کوئی اور دلچسپ ڈیمون ہے جو ڈیٹا تیار کرتا ہے۔ اور آپ بفر میں براہ راست RAM میں ڈیٹا کا ایک گروپ جمع کر سکتے ہیں۔ اور جب کافی وقت گزر جائے، تو آپ اس بفر کو ایک طرف رکھ دیں، ایک نیا بنائیں، اور ایک الگ تھریڈ میں، جو پہلے سے جمع ہو چکا ہے اسے ClickHouse میں داخل کریں۔
دوسری طرف، ڈیٹا بھی کِل -9 کے ساتھ غائب ہو جاتا ہے۔ اگر آپ کا سرور کریش ہو جاتا ہے، تو آپ یہ ڈیٹا کھو دیں گے۔ اور ایک اور مسئلہ یہ ہے کہ اگر آپ ڈیٹا بیس پر لکھنے سے قاصر تھے تو آپ کا ڈیٹا RAM میں جمع ہو جائے گا۔ اور یا تو رام ختم ہو جائے گا، یا آپ آسانی سے ڈیٹا کھو دیں گے۔
طریقہ 4. ایک اور دلچسپ طریقہ۔ کیا آپ کے پاس سرور کا عمل ہے۔ اور یہ کلک ہاؤس کو فوری طور پر ڈیٹا بھیج سکتا ہے، لیکن اسے ایک کنکشن میں کریں۔ مثال کے طور پر، میں نے ٹرانسفر انکوڈنگ کے ساتھ ایک HTTP درخواست بھیجی: insert کے ساتھ chunked. اور یہ بہت شاذ و نادر ہی ٹکڑوں کو تیار کرتا ہے، آپ ہر لائن بھیج سکتے ہیں، حالانکہ اس ڈیٹا کو تیار کرنے کے لیے اوور ہیڈ ہوگا۔
تاہم، اس معاملے میں ڈیٹا فوری طور پر کلک ہاؤس کو بھیج دیا جائے گا۔ اور کلک ہاؤس انہیں خود بفر کرے گا۔
لیکن مسائل بھی پیدا ہوتے ہیں۔ اب آپ ڈیٹا سے محروم ہو جائیں گے، بشمول آپ کا عمل کب ختم ہو جائے گا اور اگر ClickHouse کا عمل ختم ہو جائے گا، کیونکہ یہ ایک نامکمل داخل ہوگا۔ اور ClickHouse میں داخلے قطاروں کے سائز میں ایک مخصوص مخصوص حد تک ایٹم ہوتے ہیں۔ اصول میں، یہ ایک دلچسپ طریقہ ہے. بھی استعمال کیا جا سکتا ہے۔
طریقہ 5۔ یہاں ایک اور دلچسپ طریقہ ہے۔ یہ ڈیٹا بیچنگ کے لیے کمیونٹی کے تیار کردہ سرور کی ایک قسم ہے۔ میں نے خود اسے نہیں دیکھا، اس لیے میں کسی چیز کی ضمانت نہیں دے سکتا۔ تاہم، خود ClickHouse کے لیے کوئی ضمانت فراہم نہیں کی گئی ہے۔ یہ اوپن سورس بھی ہے، لیکن دوسری طرف، آپ کو معیار کے کچھ اسٹینڈرڈ کی عادت ہو سکتی ہے جسے ہم فراہم کرنے کی کوشش کرتے ہیں۔ لیکن اس چیز کے لیے - مجھے نہیں معلوم، GitHub پر جائیں، کوڈ دیکھیں۔ شاید انہوں نے کچھ نارمل لکھا ہو۔
* 2020 تک، بھی غور میں شامل کیا جانا چاہیے۔ .
طریقہ 6. دوسرا طریقہ بفر ٹیبلز کا استعمال کرنا ہے۔ اس طریقہ کار کا فائدہ یہ ہے کہ اس کا استعمال شروع کرنا بہت آسان ہے۔ ایک بفر ٹیبل بنائیں اور اسے اس میں ڈالیں۔
نقصان یہ ہے کہ مسئلہ مکمل طور پر حل نہیں ہوتا۔ اگر، MergeTree جیسی شرح میں، آپ کو ڈیٹا کو ایک بیچ فی سیکنڈ کے حساب سے گروپ کرنا ہے، پھر بفر ٹیبل میں شرح میں، آپ کو کم از کم کئی ہزار فی سیکنڈ تک گروپ کرنا ہوگا۔ اگر یہ فی سیکنڈ 10 سے زیادہ ہے، تو یہ اب بھی خراب ہوگا۔ اور اگر آپ اسے بیچوں میں ڈالیں تو آپ نے دیکھا کہ یہ ایک لاکھ لائنیں فی سیکنڈ بنتی ہے۔ اور یہ پہلے سے ہی کافی بھاری ڈیٹا پر ہے۔
اور بفر ٹیبلز میں بھی لاگ نہیں ہوتا ہے۔ اور اگر آپ کے سرور میں کچھ گڑبڑ ہے تو ڈیٹا ضائع ہو جائے گا۔
اور بونس کے طور پر، ہمیں حال ہی میں ClickHouse میں کافکا سے ڈیٹا بازیافت کرنے کا موقع ملا ہے۔ ایک میز انجن ہے - کافکا. آپ صرف تخلیق کریں۔ اور آپ اس پر مادی نمائندگی کو لٹکا سکتے ہیں۔ اس صورت میں، یہ خود کافکا سے ڈیٹا نکالے گا اور اسے ان ٹیبلز میں داخل کرے گا جن کی آپ کو ضرورت ہے۔
اور اس موقع کے بارے میں خاص طور پر خوش کن بات یہ ہے کہ یہ ہم نہیں تھے جنہوں نے یہ کیا۔ یہ کمیونٹی کی خصوصیت ہے۔ اور جب میں "کمیونٹی فیچر" کہتا ہوں، تو میرا مطلب ہے بغیر کسی حقارت کے۔ ہم نے کوڈ پڑھا، جائزہ لیا، اسے ٹھیک کام کرنا چاہیے۔
* 2020 تک، اسی طرح کی حمایت سامنے آئی ہے۔ .
ڈیٹا داخل کرتے وقت اور کیا تکلیف یا غیر متوقع ہو سکتی ہے؟ اگر آپ اقدار داخل کرنے کی درخواست کرتے ہیں اور اقدار میں کچھ حسابی اظہار لکھتے ہیں۔ مثال کے طور پر، now() بھی ایک حسابی اظہار ہے۔ اور اس صورت میں، ClickHouse کو مجبور کیا جاتا ہے کہ وہ ہر سطر پر ان تاثرات کے ترجمان کو شروع کرے، اور کارکردگی شدت کے حکم سے گر جائے گی۔ اس سے بچنا بہتر ہے۔
* اس وقت، مسئلہ مکمل طور پر حل ہوچکا ہے، VALUES میں اظہارات کا استعمال کرتے وقت کارکردگی میں کوئی کمی نہیں ہے۔
ایک اور مثال یہ ہے کہ جب آپ کے پاس ایک بیچ پر ڈیٹا موجود ہو جو پارٹیشنز کے ایک گروپ سے تعلق رکھتا ہو تو کچھ مسائل ہو سکتے ہیں۔ پہلے سے طے شدہ طور پر، ClickHouse پارٹیشنز ماہانہ ہوتے ہیں۔ اور اگر آپ دس لاکھ قطاروں کا بیچ ڈالتے ہیں، اور کئی سالوں کا ڈیٹا موجود ہے، تو آپ کے پاس کئی درجن پارٹیشنز ہوں گے۔ اور یہ اس حقیقت کے مترادف ہے کہ بیچز سائز میں کئی دس گنا چھوٹے ہوں گے، کیونکہ اندر وہ ہمیشہ پہلے پارٹیشنز میں تقسیم ہوتے ہیں۔
* حال ہی میں، تجرباتی موڈ میں، ClickHouse نے رائٹ-ہیڈ لاگ کے ساتھ RAM میں ٹکڑوں اور ٹکڑوں کے کمپیکٹ فارمیٹ کے لیے تعاون شامل کیا، جو تقریباً مکمل طور پر مسئلہ کو حل کرتا ہے۔
اب آئیے دوسری قسم کے مسئلے کو دیکھتے ہیں یعنی ڈیٹا ٹائپنگ۔
ڈیٹا ٹائپنگ سخت یا سٹرنگ ہو سکتی ہے۔ سٹرنگ تب ہوتی ہے جب آپ نے ابھی اسے لیا اور اعلان کیا کہ آپ کے تمام فیلڈز قسم کے سٹرنگ ہیں۔ یہ بیکار ہے۔ ایسا کرنے کی ضرورت نہیں ہے۔
آئیے معلوم کریں کہ ان صورتوں میں اسے صحیح طریقے سے کیسے کرنا ہے جب آپ یہ کہنا چاہتے ہیں کہ ہمارے پاس کچھ فیلڈ، ایک سٹرنگ ہے، اور کلک ہاؤس کو خود ہی اس کا پتہ لگانے دیں، اور میں پریشان نہیں ہوں گا۔ لیکن یہ ابھی بھی کچھ کوشش کرنے کے قابل ہے۔
مثال کے طور پر، ہمارے پاس ایک IP ایڈریس ہے۔ ایک صورت میں، ہم نے اسے ایک تار کے طور پر محفوظ کیا۔ مثال کے طور پر، 192.168.1.1. اور دوسری صورت میں، یہ UInt32* کی ایک بڑی تعداد ہوگی۔ IPv32 ایڈریس کے لیے 4 بٹس کافی ہیں۔
سب سے پہلے، عجیب بات یہ ہے کہ ڈیٹا کو تقریباً مساوی طور پر کمپریس کیا جائے گا۔ فرق ضرور ہوگا، لیکن اتنا بڑا نہیں۔ لہذا ڈسک I/O کے ساتھ کوئی خاص مسئلہ نہیں ہے۔
لیکن پروسیسر کے وقت اور استفسار کے عمل کے وقت میں ایک سنگین فرق ہے۔
آئیے منفرد IP پتوں کی تعداد شمار کرتے ہیں اگر وہ نمبرز کے طور پر محفوظ ہیں۔ یہ فی سیکنڈ 137 ملین لائنوں پر کام کرتا ہے۔ اگر وہی تاروں کی شکل میں ہو تو 37 ملین لائنیں فی سیکنڈ۔ پتہ نہیں یہ اتفاق کیوں ہوا؟ میں نے خود ان درخواستوں پر عمل کیا۔ لیکن پھر بھی تقریباً 4 گنا سست۔
اور اگر آپ ڈسک کی جگہ کے فرق کا حساب لگائیں تو پھر بھی فرق ہے۔ اور فرق تقریباً ایک چوتھائی ہے، کیونکہ بہت سارے منفرد IP پتے ہیں۔ اور اگر قلیل تعداد میں مختلف معانی کے ساتھ لکیریں ہوں، تو وہ لغت کے مطابق تقریباً ایک ہی حجم میں آسانی سے کمپریس ہو جائیں گی۔
اور چار گنا وقت کا فرق سڑک پر نہیں ہوتا۔ ہو سکتا ہے کہ آپ کو برا نہ لگے، لیکن جب میں اتنا فرق دیکھتا ہوں تو مجھے دکھ ہوتا ہے۔
آئیے مختلف کیسز کو دیکھتے ہیں۔
1. ایک صورت جب آپ کے پاس کچھ مختلف منفرد اقدار ہوں۔ اس معاملے میں، ہم ایک سادہ پریکٹس استعمال کرتے ہیں جسے آپ شاید جانتے ہیں اور کسی بھی DBMS کے لیے استعمال کر سکتے ہیں۔ یہ سب نہ صرف ClickHouse کے لیے معنی رکھتا ہے۔ ڈیٹا بیس میں صرف عددی شناخت کنندہ لکھیں۔ اور آپ سٹرنگز میں تبدیل کر سکتے ہیں اور اپنی ایپلیکیشن کے سائیڈ پر واپس جا سکتے ہیں۔
مثال کے طور پر، آپ کے پاس ایک علاقہ ہے۔ اور آپ اسے تار کے طور پر محفوظ کرنے کی کوشش کر رہے ہیں۔ اور وہاں لکھا ہوگا: ماسکو اور ماسکو ریجن۔ اور جب میں دیکھتا ہوں کہ یہ "ماسکو" کہتا ہے، تو یہ کچھ بھی نہیں ہے، لیکن جب یہ ماسکو ہے، تو یہ کسی نہ کسی طرح پوری طرح اداس ہو جاتا ہے۔ یہ کتنے بائٹس ہیں۔
اس کے بجائے، ہم صرف Ulnt32 اور 250 نمبر لکھتے ہیں۔ ہمارے پاس Yandex میں 250 ہیں، لیکن آپ کا نمبر مختلف ہو سکتا ہے۔ صرف اس صورت میں، میں یہ کہوں گا کہ ClickHouse میں جیو بیس کے ساتھ کام کرنے کی بلٹ ان صلاحیت ہے۔ آپ صرف خطوں کے ساتھ ایک ڈائرکٹری لکھتے ہیں، جس میں درجہ بندی بھی شامل ہے، یعنی وہاں ماسکو، ماسکو ریجن، اور ہر وہ چیز ہوگی جس کی آپ کو ضرورت ہے۔ اور آپ درخواست کی سطح پر تبدیل کر سکتے ہیں۔
دوسرا آپشن تقریباً ایک جیسا ہے، لیکن کلک ہاؤس کے اندر سپورٹ کے ساتھ۔ یہ Enum ڈیٹا کی قسم ہے۔ آپ صرف ان تمام اقدار کو لکھتے ہیں جن کی آپ کو ضرورت ہے Enum کے اندر۔ مثال کے طور پر، ڈیوائس کی قسم اور وہاں لکھیں: ڈیسک ٹاپ، موبائل، ٹیبلٹ، ٹی وی۔ مجموعی طور پر 4 اختیارات ہیں۔
نقصان یہ ہے کہ آپ کو وقتا فوقتا اسے تبدیل کرنے کی ضرورت ہے۔ صرف ایک آپشن شامل کیا گیا۔ آئیے ٹیبل کو تبدیل کرتے ہیں۔ درحقیقت، کلک ہاؤس میں الٹر ٹیبل مفت ہے۔ خاص طور پر Enum کے لیے مفت کیونکہ ڈسک کا ڈیٹا تبدیل نہیں ہوتا ہے۔ لیکن اس کے باوجود، الٹر ٹیبل پر ایک لاک* حاصل کر لیتا ہے اور اس وقت تک انتظار کرنا چاہیے جب تک کہ تمام انتخاب پر عمل درآمد نہ ہو جائے۔ اور اس کے بعد ہی اس میں ردوبدل کیا جائے گا، یعنی ابھی بھی کچھ تکلیفیں باقی ہیں۔
* ClickHouse کے تازہ ترین ورژن میں، ALTER کو مکمل طور پر غیر مسدود کیا گیا ہے۔
ایک اور آپشن جو کلک ہاؤس کے لیے کافی منفرد ہے وہ ہے بیرونی لغات کو جوڑنا۔ آپ ClickHouse میں نمبر لکھ سکتے ہیں، اور اپنی ڈائریکٹریز کو اپنے لیے آسان کسی بھی سسٹم میں رکھ سکتے ہیں۔ مثال کے طور پر، آپ استعمال کر سکتے ہیں: MySQL، Mongo، Postgres. یہاں تک کہ آپ اپنی مائیکرو سروس بھی بنا سکتے ہیں جو اس ڈیٹا کو HTTP کے ذریعے بھیجے گی۔ اور کلک ہاؤس کی سطح پر، آپ ایک فنکشن لکھتے ہیں جو اس ڈیٹا کو نمبرز سے سٹرنگز میں تبدیل کر دے گا۔
بیرونی ٹیبل پر شمولیت کو انجام دینے کا یہ ایک خصوصی لیکن بہت موثر طریقہ ہے۔ اور دو آپشنز ہیں۔ ایک شکل میں، یہ ڈیٹا مکمل طور پر کیش کیا جائے گا، مکمل طور پر RAM میں موجود ہوگا اور کچھ فریکوئنسی کے ساتھ اپ ڈیٹ کیا جائے گا۔ اور دوسرے آپشن میں، اگر یہ ڈیٹا RAM میں فٹ نہیں ہوتا ہے، تو آپ اسے جزوی طور پر کیش کر سکتے ہیں۔
یہاں ایک مثال ہے۔ Yandex.Direct ہے۔ اور ایک اشتہاری کمپنی اور بینرز موجود ہیں۔ ممکنہ طور پر لاکھوں اشتہاری کمپنیاں ہیں۔ اور وہ تقریباً رام میں فٹ ہوتے ہیں۔ اور اربوں بینرز ہیں، وہ فٹ نہیں ہوتے۔ اور ہم MySQL سے کیشڈ ڈکشنری استعمال کرتے ہیں۔
صرف مسئلہ یہ ہے کہ کیشڈ ڈکشنری ٹھیک کام کرے گی اگر ہٹ ریٹ 100% کے قریب ہو۔ اگر یہ چھوٹا ہے، تو ڈیٹا کے ہر بیچ کے لیے استفسارات پر کارروائی کرتے وقت، آپ کو درحقیقت گمشدہ کلیدیں لینا ہوں گی اور MySQL سے ڈیٹا حاصل کرنا ہوگا۔ ClickHouse کے بارے میں، میں اب بھی اس بات کی ضمانت دے سکتا ہوں - ہاں، یہ سست نہیں ہوتا، میں دوسرے سسٹمز کے بارے میں بات نہیں کروں گا۔
اور بونس کے طور پر، لغات کلک ہاؤس میں ڈیٹا کو اپ ڈیٹ کرنے کا ایک بہت آسان طریقہ ہے۔ یعنی آپ کے پاس ایڈورٹائزنگ کمپنیوں کی رپورٹ تھی، صارف نے صرف ایڈورٹائزنگ کمپنی بدل دی اور تمام پرانے ڈیٹا میں، تمام رپورٹس میں، یہ ڈیٹا بھی بدل گیا۔ اگر آپ قطاروں کو براہ راست ٹیبل پر لکھتے ہیں، تو انہیں اپ ڈیٹ کرنا ناممکن ہو جائے گا۔
دوسرا طریقہ جب آپ نہیں جانتے کہ اپنے تاروں کے لیے شناخت کنندہ کہاں سے حاصل کرنا ہے۔ آپ اسے آسانی سے ہیش کر سکتے ہیں۔ مزید یہ کہ سب سے آسان آپشن 64 بٹ ہیش لینا ہے۔
صرف مسئلہ یہ ہے کہ اگر ہیش 64 بٹ ہے، تو آپ کو تقریبا یقینی طور پر تصادم ہوگا۔ کیونکہ اگر وہاں ایک ارب لائنیں ہوں تو امکان پہلے ہی نمایاں ہوجاتا ہے۔
اور اس طرح اشتہاری کمپنیوں کے نام ہیش کرنا بہت اچھا نہیں ہوگا۔ مختلف کمپنیوں کی اشتہاری مہمات کو ملایا جائے تو کچھ سمجھ سے باہر ہوگا۔
اور ایک سادہ چال ہے۔ سچ ہے، یہ سنجیدہ ڈیٹا کے لیے بھی زیادہ موزوں نہیں ہے، لیکن اگر کوئی چیز زیادہ سنجیدہ نہیں ہے، تو صرف کلائنٹ شناخت کنندہ کو لغت کی کلید میں شامل کریں۔ اور پھر آپ کو تصادم پڑے گا، لیکن صرف ایک کلائنٹ کے اندر۔ اور ہم Yandex.Metrica میں لنک کے نقشوں کے لیے یہ طریقہ استعمال کرتے ہیں۔ ہمارے پاس وہاں یو آر ایل ہیں، ہم ہیشز اسٹور کرتے ہیں۔ اور ہم جانتے ہیں کہ یقیناً تصادم ہوتے ہیں۔ لیکن جب صفحہ ظاہر ہوتا ہے، تو اس امکان کو نظر انداز کیا جا سکتا ہے کہ ایک صارف کے ایک صفحے پر کچھ یو آر ایل ایک ساتھ پھنس گئے ہوں گے اور اس کا نوٹس لیا جائے گا۔
بونس کے طور پر، بہت سے آپریشنز کے لیے اکیلے ہیشز کافی ہیں اور خود تاروں کو کہیں بھی ذخیرہ کرنے کی ضرورت نہیں ہے۔
ایک اور مثال یہ ہے کہ اگر تار مختصر ہیں، مثال کے طور پر، ویب سائٹ کے ڈومین۔ وہ جیسا ہے ذخیرہ کیا جا سکتا ہے. یا، مثال کے طور پر، براؤزر کی زبان ru 2 بائٹس ہے۔ بلاشبہ، مجھے بائٹس کے لیے واقعی افسوس ہے، لیکن پریشان نہ ہوں، 2 بائٹس افسوس کی بات نہیں ہے۔ براہ کرم اسے جیسا ہے برقرار رکھیں، فکر نہ کریں۔
ایک اور صورت یہ ہے کہ جب، اس کے برعکس، بہت ساری لائنیں ہیں اور ان میں بہت سی منفرد ہیں، اور سیٹ بھی ممکنہ طور پر لامحدود ہے۔ ایک عام مثال تلاش کے فقرے یا URLs ہیں۔ فقرے تلاش کریں، بشمول ٹائپوز۔ آئیے دیکھتے ہیں کہ روزانہ تلاش کے کتنے منفرد جملے ہوتے ہیں۔ اور یہ پتہ چلتا ہے کہ وہ تمام واقعات کے تقریبا نصف ہیں. اور اس صورت میں، آپ سوچ سکتے ہیں کہ آپ کو ڈیٹا کو معمول پر لانے، شناخت کنندگان کو شمار کرنے اور اسے ایک علیحدہ جدول میں رکھنے کی ضرورت ہے۔ لیکن آپ کو ایسا کرنے کی ضرورت نہیں ہے۔ بس ان لائنوں کو جوں کا توں رکھیں۔
بہتر ہے کہ کوئی چیز ایجاد نہ کی جائے، کیونکہ اگر آپ اسے الگ سے ذخیرہ کرتے ہیں، تو آپ کو جوائن کرنے کی ضرورت ہوگی۔ اور یہ شمولیت، بہترین طور پر، میموری تک بے ترتیب رسائی ہے، اگر یہ اب بھی میموری میں فٹ بیٹھتا ہے۔ اگر یہ فٹ نہیں ہوتا ہے، تو پھر مسائل ہوں گے.
اور اگر ڈیٹا اپنی جگہ پر محفوظ ہے، تو اسے فائل سسٹم سے مطلوبہ ترتیب میں پڑھا جاتا ہے اور سب کچھ ٹھیک ہے۔
اگر آپ کے پاس URLs یا کوئی اور پیچیدہ لمبی تار ہے، تو یہ قابل غور ہے کہ آپ کسی قسم کے اقتباس کا پہلے سے حساب لگا سکتے ہیں اور اسے الگ کالم میں لکھ سکتے ہیں۔
URLs کے لیے، مثال کے طور پر، آپ ڈومین کو الگ سے اسٹور کر سکتے ہیں۔ اور اگر آپ کو واقعی ڈومین کی ضرورت ہے، تو صرف اس کالم کو استعمال کریں، اور یو آر ایل وہاں پڑے ہوں گے، اور آپ انہیں چھو بھی نہیں پائیں گے۔
آئیے دیکھتے ہیں کہ کیا فرق ہے۔ ClickHouse میں ایک خصوصی فنکشن ہے جو ڈومین کا حساب لگاتا ہے۔ یہ بہت تیز ہے، ہم نے اسے بہتر بنایا ہے۔ اور، سچ پوچھیں تو، یہ RFC کی تعمیل بھی نہیں کرتا، لیکن اس کے باوجود یہ ہماری ضرورت کی ہر چیز پر غور کرتا ہے۔
اور ایک صورت میں ہم صرف URLs حاصل کریں گے اور ڈومین کا حساب لگائیں گے۔ یہ 166 ملی سیکنڈ تک کام کرتا ہے۔ اور اگر آپ ریڈی میڈ ڈومین لیتے ہیں، تو یہ صرف 67 ملی سیکنڈز کا نکلتا ہے، یعنی تقریباً تین گنا تیز۔ اور یہ اس لیے تیز نہیں ہے کہ ہمیں کچھ حساب کتاب کرنے کی ضرورت ہے، بلکہ اس لیے کہ ہم کم ڈیٹا پڑھتے ہیں۔
اسی لیے ایک درخواست، جو سست ہے، اس کی رفتار گیگا بائٹس فی سیکنڈ زیادہ ہے۔ کیونکہ یہ زیادہ گیگا بائٹس پڑھتا ہے۔ یہ مکمل طور پر غیر ضروری ڈیٹا ہے۔ لگتا ہے کہ درخواست تیزی سے چل رہی ہے، لیکن اسے مکمل ہونے میں زیادہ وقت لگتا ہے۔
اور اگر آپ ڈسک پر ڈیٹا کی مقدار کو دیکھیں تو پتہ چلتا ہے کہ یو آر ایل 126 میگا بائٹس ہے، اور ڈومین صرف 5 میگا بائٹس ہے۔ یہ 25 گنا کم نکلتا ہے۔ لیکن اس کے باوجود، درخواست کو صرف 4 گنا تیزی سے عمل میں لایا جاتا ہے۔ لیکن اس کی وجہ یہ ہے کہ ڈیٹا گرم ہے۔ اور اگر یہ ٹھنڈا ہوتا تو ڈسک I/O کی وجہ سے یہ شاید 25 گنا تیز ہوتا۔
ویسے، اگر آپ اندازہ لگائیں کہ ڈومین یو آر ایل سے کتنا چھوٹا ہے، تو یہ تقریباً 4 گنا چھوٹا نکلتا ہے۔ لیکن کسی وجہ سے، ڈسک پر ڈیٹا 25 گنا کم ہوتا ہے۔ کیوں؟ کمپریشن کی وجہ سے۔ اور URL کمپریسڈ ہے، اور ڈومین کمپریسڈ ہے۔ لیکن اکثر یو آر ایل میں کچرے کا ایک گچھا ہوتا ہے۔
اور، یقینا، یہ صحیح ڈیٹا کی قسموں کو استعمال کرنے کی ادائیگی کرتا ہے جو خاص طور پر مطلوبہ اقدار کے لیے تیار کی گئی ہیں یا جو موزوں ہیں۔ اگر آپ IPv4 میں ہیں، تو UInt32* اسٹور کریں۔ اگر IPv6، تو FixedString(16)، کیونکہ IPv6 ایڈریس 128 بٹس ہے، یعنی براہ راست بائنری فارمیٹ میں اسٹور کیا جاتا ہے۔
لیکن کیا ہوگا اگر آپ کے پاس کبھی کبھی IPv4 پتے ہوں اور کبھی IPv6؟ ہاں، آپ دونوں کو ذخیرہ کر سکتے ہیں۔ ایک کالم IPv4 کے لیے، دوسرا IPv6 کے لیے۔ بلاشبہ، IPv4 میں IPv6 ڈسپلے کرنے کا آپشن موجود ہے۔ یہ بھی کام کرے گا، لیکن اگر آپ کو اکثر درخواستوں میں IPv4 ایڈریس کی ضرورت ہوتی ہے، تو اسے الگ کالم میں ڈالنا اچھا ہوگا۔
* ClickHouse میں اب الگ الگ IPv4, IPv6 ڈیٹا کی قسمیں ہیں جو اعداد و شمار کی طرح مؤثر طریقے سے ڈیٹا کو ذخیرہ کرتی ہیں، لیکن سٹرنگز کی طرح آسانی سے ان کی نمائندگی کرتی ہیں۔
یہ نوٹ کرنا بھی ضروری ہے کہ ڈیٹا کو پہلے سے پروسیس کرنے کے قابل ہے۔ مثال کے طور پر، آپ کو کچھ خام لاگز موصول ہوتے ہیں۔ اور ہوسکتا ہے کہ آپ کو انہیں ابھی کلک ہاؤس میں نہیں رکھنا چاہئے، حالانکہ یہ کچھ نہ کرنا بہت پرکشش ہے اور سب کچھ کام کرے گا۔ لیکن یہ اب بھی ممکن ہے کہ حساب سے باہر لے جانے کے قابل ہے.
مثال کے طور پر، براؤزر ورژن. کچھ قریبی ڈیپارٹمنٹ میں، جس پر میں انگلی نہیں اٹھانا چاہتا، براؤزر کا ورژن اس طرح محفوظ ہے، یعنی سٹرنگ کے طور پر: 12.3۔ اور پھر، ایک رپورٹ بنانے کے لیے، وہ اس تار کو لے کر اسے ایک صف میں تقسیم کرتے ہیں، اور پھر صف کے پہلے عنصر میں۔ قدرتی طور پر، سب کچھ سست ہو جاتا ہے. میں نے پوچھا کہ وہ ایسا کیوں کرتے ہیں۔ انہوں نے مجھے بتایا کہ وہ قبل از وقت اصلاح پسند نہیں کرتے۔ اور مجھے قبل از وقت مایوسی پسند نہیں ہے۔
تو اس صورت میں اسے 4 کالموں میں تقسیم کرنا زیادہ درست ہوگا۔ یہاں خوفزدہ نہ ہوں، کیونکہ یہ کلک ہاؤس ہے۔ کلک ہاؤس ایک کالمی ڈیٹا بیس ہے۔ اور جتنے صاف ستھرا کالم، اتنا ہی بہتر۔ 5 براؤزر ورژن ہوں گے، 5 کالم بنائیں۔ یہ ٹھیک ہے.
اب دیکھتے ہیں کہ اگر آپ کے پاس بہت لمبی تاریں، بہت لمبی صفیں ہیں تو کیا کریں۔ انہیں ClickHouse میں ذخیرہ کرنے کی بالکل بھی ضرورت نہیں ہے۔ اس کے بجائے، آپ صرف ClickHouse میں شناخت کنندہ کو اسٹور کر سکتے ہیں۔ اور ان لمبی لائنوں کو کسی اور سسٹم میں ڈال دیں۔
مثال کے طور پر، ہماری تجزیاتی خدمات میں سے ایک میں ایونٹ کے کچھ پیرامیٹرز ہیں۔ اور اگر واقعات کے بہت سے پیرامیٹرز ہیں، تو ہم صرف پہلے 512 کو محفوظ کرتے ہیں جو سامنے آتے ہیں۔ کیونکہ 512 افسوس کی بات نہیں ہے۔
اور اگر آپ اپنے ڈیٹا کی قسموں کے بارے میں فیصلہ نہیں کر سکتے ہیں، تو آپ کلک ہاؤس میں بھی ڈیٹا ریکارڈ کر سکتے ہیں، لیکن لاگ ٹائپ کی ایک عارضی جدول میں، خاص طور پر عارضی ڈیٹا کے لیے۔ اس کے بعد، آپ تجزیہ کر سکتے ہیں کہ آپ کے پاس وہاں کیا قدروں کی تقسیم ہے، عام طور پر کیا ہے، اور صحیح قسمیں تخلیق کر سکتے ہیں۔
*کلک ہاؤس میں اب ڈیٹا کی قسم ہے۔ جو آپ کو کم محنت کے ساتھ سٹرنگز کو مؤثر طریقے سے ذخیرہ کرنے کی اجازت دیتا ہے۔
اب ایک اور دلچسپ کیس دیکھتے ہیں۔ بعض اوقات چیزیں لوگوں کے لیے عجیب کام کرتی ہیں۔ میں اندر آتا ہوں اور یہ دیکھتا ہوں۔ اور فوری طور پر ایسا لگتا ہے کہ یہ کچھ انتہائی تجربہ کار، ہوشیار منتظم نے کیا ہے جو MySQL ورژن 3.23 کو ترتیب دینے کا وسیع تجربہ رکھتے ہیں۔
یہاں ہم ایک ہزار میزیں دیکھتے ہیں، جن میں سے ہر ایک کو تقسیم کرنے کے بقیہ کو ریکارڈ کرتا ہے کون جانتا ہے کہ ہزار سے کیا ہے۔
اصولی طور پر، میں دوسرے لوگوں کے تجربے کا احترام کرتا ہوں، بشمول اس تکلیف کی سمجھ جو اس تجربے کے ذریعے حاصل کی جا سکتی ہے۔
اور وجوہات کم و بیش واضح ہیں۔ یہ پرانے دقیانوسی تصورات ہیں جو دوسرے سسٹمز کے ساتھ کام کرتے ہوئے جمع ہو سکتے ہیں۔ مثال کے طور پر، MyISAM ٹیبلز میں کلسٹرڈ پرائمری کلید نہیں ہے۔ اور ڈیٹا کو تقسیم کرنے کا یہ طریقہ اسی فعالیت کو حاصل کرنے کی ایک مایوس کن کوشش ہو سکتی ہے۔
ایک اور وجہ یہ ہے کہ بڑی میزوں پر کسی بھی تبدیلی کی کارروائی کرنا مشکل ہے۔ سب کچھ بلاک ہو جائے گا۔ اگرچہ MySQL کے جدید ورژن میں یہ مسئلہ اب اتنا سنگین نہیں ہے۔
یا، مثال کے طور پر، مائیکرو شارڈنگ، لیکن بعد میں اس پر مزید۔
کلک ہاؤس میں ایسا کرنے کی ضرورت نہیں ہے، کیونکہ، سب سے پہلے، بنیادی کلید کلسٹرڈ ہے، ڈیٹا کو بنیادی کلید کے ذریعے ترتیب دیا جاتا ہے۔
اور بعض اوقات لوگ مجھ سے پوچھتے ہیں: "کلک ہاؤس میں رینج کے سوالات کی کارکردگی میز کے سائز کے لحاظ سے کیسے مختلف ہوتی ہے؟" میں کہتا ہوں کہ یہ بالکل نہیں بدلتا۔ مثال کے طور پر، آپ کے پاس ایک ارب قطاروں والی میز ہے اور آپ دس لاکھ قطاروں کی رینج پڑھتے ہیں۔ سب کچھ ٹھیک ہے. اگر ایک ٹیبل میں ایک ٹریلین قطاریں ہیں اور آپ دس لاکھ قطاریں پڑھتے ہیں تو یہ تقریباً ایک جیسی ہوگی۔
اور، دوسری بات، ہر قسم کی چیزیں جیسے دستی پارٹیشنز کی ضرورت نہیں ہے۔ اگر آپ اندر جائیں اور دیکھیں کہ فائل سسٹم میں کیا ہے، تو آپ دیکھیں گے کہ ٹیبل بہت بڑی چیز ہے۔ اور اندر پارٹیشنز جیسا کچھ ہے۔ یعنی کلک ہاؤس آپ کے لیے سب کچھ کرتا ہے اور آپ کو تکلیف نہیں اٹھانی پڑتی۔
کلک ہاؤس میں الٹر مفت ہے اگر کالم ایڈ/ڈراپ کو تبدیل کریں۔
اور آپ کو چھوٹی میزیں نہیں بنانا چاہئے، کیونکہ اگر آپ کے پاس ایک میز میں 10 قطاریں یا 10،000 قطاریں ہیں، تو اس سے کوئی فرق نہیں پڑتا۔ ClickHouse ایک ایسا نظام ہے جو تھرو پٹ کو بہتر بناتا ہے، تاخیر سے نہیں، اس لیے 10 لائنوں پر کارروائی کرنا کوئی معنی نہیں رکھتا۔
ایک بڑی میز استعمال کرنا درست ہے۔ پرانے دقیانوسی تصورات سے جان چھڑائیں، سب ٹھیک ہو جائے گا۔
اور بونس کے طور پر، تازہ ترین ورژن میں اب ہم انفرادی پارٹیشنز پر ہر طرح کی دیکھ بھال کے کام انجام دینے کے لیے ایک صوابدیدی تقسیم کاری کلید بنانے کی صلاحیت رکھتے ہیں۔
مثال کے طور پر، آپ کو بہت سی چھوٹی میزوں کی ضرورت ہوتی ہے، مثال کے طور پر، جب کچھ درمیانی ڈیٹا کو پروسیس کرنے کی ضرورت ہوتی ہے، تو آپ کو ٹکڑے ملتے ہیں اور فائنل ٹیبل پر لکھنے سے پہلے آپ کو ان میں تبدیلی کرنے کی ضرورت ہوتی ہے۔ اس معاملے کے لئے، ایک شاندار ٹیبل انجن ہے - StripeLog. یہ TinyLog کی طرح ہے، صرف بہتر.
* اب کلک ہاؤس کے پاس بھی ہے۔ .
ایک اور اینٹی پیٹرن مائکرو شارڈنگ ہے۔ مثال کے طور پر، آپ کو ڈیٹا شارڈ کرنے کی ضرورت ہے اور آپ کے پاس 5 سرور ہیں، اور کل 6 سرورز ہوں گے۔ اور آپ سوچتے ہیں کہ اس ڈیٹا کو کیسے متوازن کیا جائے۔ اور اس کے بجائے آپ 5 شارڈز میں نہیں بلکہ 1 شارڈز میں ٹوٹ جاتے ہیں۔ اور پھر آپ ان مائیکرو شارڈز میں سے ہر ایک کو الگ سرور پر نقشہ بناتے ہیں۔ اور آپ کو، مثال کے طور پر، ایک سرور پر 000 کلک ہاؤسز ملیں گے۔ الگ الگ بندرگاہوں یا علیحدہ ڈیٹا بیس پر الگ الگ مثالیں۔
لیکن کلک ہاؤس میں یہ بہت اچھا نہیں ہے۔ کیونکہ یہاں تک کہ ایک کلک ہاؤس مثال ایک درخواست پر کارروائی کرنے کے لیے تمام دستیاب سرور وسائل کو استعمال کرنے کی کوشش کرتا ہے۔ یعنی، آپ کے پاس کسی قسم کا سرور ہے اور اس میں، مثال کے طور پر، 56 پروسیسر کور ہیں۔ آپ ایک سوال چلا رہے ہیں جس میں ایک سیکنڈ لگتا ہے اور یہ 56 کور استعمال کرے گا۔ اور اگر آپ نے وہاں ایک سرور پر 200 کلک ہاؤسز رکھے تو پتہ چلتا ہے کہ 10 تھریڈز شروع ہو جائیں گے۔ عام طور پر، سب کچھ بہت خراب ہو جائے گا.
ایک اور وجہ یہ ہے کہ ان مثالوں میں کام کی تقسیم ناہموار ہوگی۔ کچھ پہلے ختم ہوں گے، کچھ بعد میں ختم ہوں گے۔ اگر یہ سب کچھ ایک مثال میں ہوا ہے، تو کلک ہاؤس خود ہی یہ جان لے گا کہ ڈیٹا کو تھریڈز کے درمیان صحیح طریقے سے کیسے تقسیم کیا جائے۔
اور دوسری وجہ یہ ہے کہ آپ کے پاس TCP کے ذریعے انٹر پروسیسر کمیونیکیشن ہوگی۔ ڈیٹا کو سیریلائز، ڈی سیریلائز کرنا پڑے گا، اور یہ مائیکرو شارڈز کی ایک بڑی تعداد ہے۔ یہ صرف مؤثر طریقے سے کام نہیں کرے گا.
ایک اور اینٹی پیٹرن، حالانکہ اسے شاید ہی اینٹی پیٹرن کہا جاسکتا ہے۔ یہ پری ایگریگیشن کی ایک بڑی مقدار ہے۔
عام طور پر، پہلے سے جمع کرنا اچھا ہے۔ آپ کے پاس ایک ارب قطاریں تھیں، آپ نے اسے جمع کیا اور یہ 1 قطاریں بن گئیں، اور اب استفسار فوری طور پر مکمل ہو جاتا ہے۔ سب کچھ بہت اچھا ہے. آپ یہ کر سکتے ہیں. اور اس کے لیے، کلک ہاؤس کے پاس بھی ایک خاص ٹیبل کی قسم ہے، AggregatingMergeTree، جو ڈیٹا داخل ہونے کے ساتھ ہی انکریمنٹل ایگریگیشن کرتا ہے۔
لیکن ایسے اوقات ہوتے ہیں جب آپ سوچتے ہیں کہ ہم اس طرح کے ڈیٹا کو جمع کریں گے اور اس طرح کے ڈیٹا کو جمع کریں گے۔ اور کچھ پڑوسی محکمہ میں، میں یہ بھی نہیں کہنا چاہتا کہ کون سا، وہ SummingMergeTree ٹیبلز کو بنیادی کلید کے ذریعے خلاصہ کرنے کے لیے استعمال کرتے ہیں، اور تقریباً 20 کالم بنیادی کلید کے طور پر استعمال ہوتے ہیں۔ صرف اس صورت میں، میں نے رازداری کے لیے کچھ کالموں کے نام تبدیل کیے ہیں، لیکن یہ کافی حد تک ہے۔
اور ایسے مسائل پیدا ہوتے ہیں۔ سب سے پہلے، آپ کے ڈیٹا کا حجم بہت کم نہیں ہوتا ہے۔ مثال کے طور پر، یہ تین گنا کم ہوتا ہے. لامحدود تجزیاتی صلاحیتوں کو برداشت کرنے کے لیے تین گنا اچھی قیمت ہو گی جو آپ کے ڈیٹا کو جمع نہ کرنے کی صورت میں پیدا ہوتی ہیں۔ اگر اعداد و شمار کو جمع کیا جاتا ہے، تو تجزیات کے بجائے آپ کو صرف قابل رحم اعداد و شمار ملیں گے۔
اور اس میں کیا خاص بات ہے؟ حقیقت یہ ہے کہ پڑوسی محکمہ کے یہ لوگ بعض اوقات جا کر پرائمری کلید میں دوسرا کالم شامل کرنے کو کہتے ہیں۔ یعنی، ہم نے ڈیٹا کو اس طرح جمع کیا، لیکن اب ہم تھوڑا اور چاہتے ہیں۔ لیکن ClickHouse کے پاس الٹر پرائمری کلید نہیں ہے۔ لہذا، ہمیں C++ میں کچھ اسکرپٹ لکھنے ہوں گے۔ اور مجھے اسکرپٹ پسند نہیں ہیں، چاہے وہ C++ میں ہوں۔
اور اگر آپ دیکھیں کہ ClickHouse کس لیے بنایا گیا تھا، تو غیر جمع شدہ ڈیٹا بالکل وہی منظر نامہ ہے جس کے لیے یہ پیدا ہوا تھا۔ اگر آپ غیر جمع شدہ ڈیٹا کے لیے ClickHouse استعمال کر رہے ہیں، تو آپ اسے ٹھیک کر رہے ہیں۔ اگر آپ مجموعی طور پر، یہ کبھی کبھی قابل معافی ہے.
ایک اور دلچسپ معاملہ لامحدود لوپ میں سوالات کا ہے۔ کبھی کبھی میں کسی پروڈکشن سرور پر جاتا ہوں اور وہاں شو پروسیس لسٹ دیکھتا ہوں۔ اور جب بھی مجھے پتہ چلتا ہے کہ کچھ خوفناک ہو رہا ہے۔
مثلاً اس طرح۔ یہ فوری طور پر واضح ہے کہ سب کچھ ایک درخواست میں کیا جا سکتا ہے۔ بس وہاں یو آر ایل اور فہرست لکھیں۔
لامتناہی لوپ میں اس طرح کے بہت سے سوالات کیوں خراب ہیں؟ اگر ایک انڈیکس استعمال نہیں کیا جاتا ہے، تو آپ کو ایک ہی ڈیٹا پر بہت سے پاس ہوں گے۔ لیکن اگر انڈیکس استعمال کیا جاتا ہے، مثال کے طور پر، آپ کے پاس ru کے لیے ایک بنیادی کلید ہے اور آپ وہاں url = کچھ لکھتے ہیں۔ اور آپ کو لگتا ہے کہ اگر ٹیبل سے صرف ایک یو آر ایل پڑھا جائے تو سب کچھ ٹھیک ہو جائے گا۔ لیکن اصل میں نہیں۔ کیونکہ کلک ہاؤس سب کچھ بیچوں میں کرتا ہے۔
جب اسے ڈیٹا کی ایک مخصوص رینج کو پڑھنے کی ضرورت ہوتی ہے، تو وہ تھوڑا زیادہ پڑھتا ہے، کیونکہ ClickHouse میں انڈیکس بہت کم ہے۔ یہ انڈیکس آپ کو ٹیبل میں ایک انفرادی قطار تلاش کرنے کی اجازت نہیں دیتا، صرف کسی قسم کی حد۔ اور ڈیٹا کو بلاکس میں کمپریس کیا جاتا ہے۔ ایک سطر کو پڑھنے کے لیے، آپ کو پورا بلاک لے کر اسے ہٹانا ہوگا۔ اور اگر آپ سوالات کا ایک گروپ کر رہے ہیں، تو آپ کے پاس بہت زیادہ اوورلیپ ہوگا، اور آپ کو بار بار کرنے کے لیے بہت زیادہ کام کرنا پڑے گا۔
اور بونس کے طور پر، آپ نوٹ کر سکتے ہیں کہ ClickHouse میں آپ کو میگا بائٹس حتیٰ کہ سینکڑوں میگا بائٹس کو IN سیکشن میں منتقل کرنے سے نہیں گھبرانا چاہیے۔ مجھے اپنی پریکٹس سے یاد ہے کہ اگر MySQL میں ہم قدروں کا ایک گروپ IN سیکشن میں منتقل کرتے ہیں، مثال کے طور پر، ہم وہاں کچھ نمبروں کی 100 میگا بائٹس منتقل کرتے ہیں، تو MySQL 10 گیگا بائٹس میموری کھا جاتا ہے اور اس کے علاوہ کچھ نہیں ہوتا، سب کچھ۔ خراب کام کرتا ہے.
اور دوسرا یہ ہے کہ ClickHouse میں، اگر آپ کے سوالات ایک انڈیکس کا استعمال کرتے ہیں، تو یہ ہمیشہ مکمل اسکین سے زیادہ سست نہیں ہوتا، یعنی اگر آپ کو تقریباً پورا ٹیبل پڑھنے کی ضرورت ہے، تو یہ ترتیب وار جائے گا اور پوری ٹیبل کو پڑھے گا۔ عام طور پر، وہ خود ہی اس کا پتہ لگائے گا۔
لیکن اس کے باوجود کچھ مشکلات ہیں۔ مثال کے طور پر، حقیقت یہ ہے کہ IN ایک subquery کے ساتھ انڈیکس کا استعمال نہیں کرتا ہے۔ لیکن یہ ہمارا مسئلہ ہے اور ہمیں اسے حل کرنے کی ضرورت ہے۔ یہاں کوئی بنیادی بات نہیں ہے۔ ہم اسے ٹھیک کریں گے*۔
اور ایک اور دلچسپ بات یہ ہے کہ اگر آپ کے پاس ایک بہت لمبی درخواست ہے اور تقسیم شدہ درخواست کی پروسیسنگ جاری ہے، تو یہ بہت لمبی درخواست ہر سرور کو بغیر کمپریشن کے بھیج دی جائے گی۔ مثال کے طور پر، 100 میگا بائٹس اور 500 سرورز۔ اور، اس کے مطابق، آپ کے پاس 50 گیگا بائٹس نیٹ ورک پر منتقل ہوں گی۔ اسے منتقل کیا جائے گا اور پھر سب کچھ کامیابی سے مکمل ہو جائے گا۔
* پہلے ہی استعمال کر رہے ہیں؛ وعدے کے مطابق سب کچھ طے پا گیا۔
اور کافی عام معاملہ ہے جب درخواستیں API سے آتی ہیں۔ مثال کے طور پر، آپ نے اپنی خود کی کسی قسم کی خدمت بنائی ہے۔ اور اگر کسی کو آپ کی خدمت کی ضرورت ہے، تو آپ API کھولتے ہیں اور لفظی طور پر دو دن بعد آپ دیکھتے ہیں کہ کچھ سمجھ سے باہر ہو رہا ہے۔ سب کچھ اوورلوڈ ہے اور کچھ خوفناک درخواستیں آرہی ہیں جو کبھی نہیں ہونی چاہئیں تھیں۔
اور اس کا ایک ہی حل ہے۔ اگر آپ نے API کھولا ہے، تو آپ کو اسے کاٹنا پڑے گا۔ مثال کے طور پر، کسی قسم کے کوٹے متعارف کروائیں۔ کوئی اور عام اختیارات نہیں ہیں۔ ورنہ وہ فوراً اسکرپٹ لکھیں گے اور مسائل پیدا ہوں گے۔
اور ClickHouse میں ایک خاص خصوصیت ہے - کوٹہ کیلکولیشن۔ مزید یہ کہ آپ اپنے کوٹہ کی کلید کو منتقل کر سکتے ہیں۔ یہ، مثال کے طور پر، اندرونی صارف ID ہے۔ اور ان میں سے ہر ایک کے لیے کوٹے کا حساب آزادانہ طور پر کیا جائے گا۔
اب ایک اور دلچسپ بات۔ یہ دستی نقل ہے۔
میں بہت سے ایسے معاملات کے بارے میں جانتا ہوں جہاں ClickHouse میں بلٹ ان ریپلیکیشن سپورٹ ہونے کے باوجود، لوگ ClickHouse کو دستی طور پر نقل کرتے ہیں۔
اصول کیا ہے؟ آپ کے پاس ڈیٹا پروسیسنگ پائپ لائن ہے۔ اور یہ آزادانہ طور پر کام کرتا ہے، مثال کے طور پر، مختلف ڈیٹا سینٹرز میں۔ آپ کلک ہاؤس میں ایک ہی ڈیٹا کو اسی طرح لکھتے ہیں۔ درست، پریکٹس سے پتہ چلتا ہے کہ آپ کے کوڈ میں کچھ خصوصیات کی وجہ سے ڈیٹا اب بھی مختلف ہو جائے گا۔ مجھے امید ہے کہ یہ آپ میں ہے۔
اور وقتاً فوقتاً آپ کو اب بھی دستی طور پر مطابقت پذیر ہونا پڑے گا۔ مثال کے طور پر، مہینے میں ایک بار منتظم rsync کرتے ہیں۔
درحقیقت، ClickHouse میں بنائی گئی نقل کو استعمال کرنا بہت آسان ہے۔ لیکن کچھ تضادات ہوسکتے ہیں، کیونکہ اس کے لیے آپ کو ZooKeeper استعمال کرنے کی ضرورت ہے۔ میں ZooKeeper کے بارے میں کچھ برا نہیں کہوں گا، اصولی طور پر یہ سسٹم کام کرتا ہے، لیکن ایسا ہوتا ہے کہ لوگ جاوا فوبیا کی وجہ سے اسے استعمال نہیں کرتے، کیونکہ ClickHouse اتنا اچھا سسٹم ہے، جو C++ میں لکھا ہوا ہے، جسے آپ استعمال کر سکتے ہیں اور سب کچھ ٹھیک ہو جائے گا . اور زو کیپر جاوا میں ہے۔ اور کسی نہ کسی طرح آپ دیکھنا بھی نہیں چاہتے، لیکن پھر آپ دستی نقل استعمال کر سکتے ہیں۔
کلک ہاؤس ایک عملی نظام ہے۔ وہ آپ کی ضروریات کو مدنظر رکھتی ہے۔ اگر آپ کے پاس دستی نقل ہے، تو آپ ایک تقسیم شدہ ٹیبل بنا سکتے ہیں جو آپ کے دستی نقلوں کو دیکھتا ہے اور ان کے درمیان فیل اوور کرتا ہے۔ اور یہاں تک کہ ایک خاص آپشن بھی ہے جو آپ کو فلاپ سے بچنے کی اجازت دیتا ہے، چاہے آپ کی لکیریں منظم طریقے سے ہٹ جائیں۔
اگر آپ قدیم ٹیبل انجن استعمال کرتے ہیں تو مزید مسائل پیدا ہو سکتے ہیں۔ کلک ہاؤس ایک کنسٹرکٹر ہے جس میں مختلف ٹیبل انجنوں کا ایک گروپ ہے۔ تمام سنگین معاملات کے لیے، جیسا کہ دستاویزات میں لکھا گیا ہے، MergeTree فیملی سے ٹیبل استعمال کریں۔ اور باقی سب - یہ انفرادی معاملات یا ٹیسٹ کے لئے ہے.
MergeTree ٹیبل میں، آپ کو کسی تاریخ اور وقت کی ضرورت نہیں ہے۔ آپ اب بھی اسے استعمال کر سکتے ہیں۔ اگر کوئی تاریخ اور وقت نہیں ہے تو لکھیں کہ ڈیفالٹ 2000 ہے۔ یہ کام کرے گا اور وسائل کی ضرورت نہیں پڑے گی۔
اور سرور کے نئے ورژن میں، آپ یہ بھی بتا سکتے ہیں کہ آپ کے پاس پارٹیشن کلید کے بغیر کسٹم پارٹیشننگ ہے۔ ایسا ہی ہوگا۔
دوسری طرف، آپ قدیم ٹیبل انجن استعمال کر سکتے ہیں۔ مثال کے طور پر، ڈیٹا کو ایک بار بھریں اور دیکھیں، موڑ دیں اور حذف کریں۔ آپ لاگ استعمال کرسکتے ہیں۔
یا انٹرمیڈیٹ پروسیسنگ کے لیے چھوٹے حجم کو اسٹور کرنا StripeLog یا TinyLog ہے۔
میموری کو استعمال کیا جا سکتا ہے اگر ڈیٹا کی مقدار کم ہو اور آپ رام میں کسی چیز کو آسانی سے گھما سکتے ہیں۔
ClickHouse واقعی ری نارملائزڈ ڈیٹا کو پسند نہیں کرتا۔
یہاں ایک عام مثال ہے۔ یہ URLs کی ایک بڑی تعداد ہے۔ آپ انہیں اگلے ٹیبل میں رکھیں۔ اور پھر انہوں نے ان کے ساتھ جوائن کرنے کا فیصلہ کیا، لیکن یہ ایک اصول کے طور پر کام نہیں کرے گا، کیونکہ ClickHouse صرف Hash JOIN کو سپورٹ کرتا ہے۔ اگر بہت سارے ڈیٹا کے لیے کافی RAM نہیں ہے جسے کنیکٹ کرنے کی ضرورت ہے، تو JOIN* کام نہیں کرے گا۔
اگر اعداد و شمار اعلی کارڈینیلیٹی کا ہے، تو پریشان نہ ہوں، اسے غیر معمولی شکل میں ذخیرہ کریں، URLs براہ راست مین ٹیبل میں موجود ہیں۔
* اور اب ClickHouse میں بھی ایک مرج جوائن ہے، اور یہ ان حالات میں کام کرتا ہے جہاں انٹرمیڈیٹ ڈیٹا RAM میں فٹ نہیں ہوتا ہے۔ لیکن یہ بے اثر ہے اور سفارش نافذ رہتی ہے۔
ایک دو اور مثالیں، لیکن مجھے پہلے ہی شک ہے کہ آیا وہ پیٹرن مخالف ہیں یا نہیں۔
کلک ہاؤس میں ایک معروف خامی ہے۔ یہ نہیں جانتا کہ کیسے اپ ڈیٹ کیا جائے*۔ کچھ طریقوں سے، یہ بھی اچھا ہے۔ اگر آپ کے پاس کچھ اہم ڈیٹا ہے، مثال کے طور پر، اکاؤنٹنگ، تو کوئی بھی اسے بھیج نہیں سکے گا، کیونکہ کوئی اپ ڈیٹ نہیں ہے۔
* بیچ موڈ میں اپ ڈیٹ اور ڈیلیٹ کے لیے سپورٹ کافی عرصہ پہلے شامل کی گئی ہے۔
لیکن کچھ خاص طریقے ہیں جو اپ ڈیٹس کی اجازت دیتے ہیں گویا پس منظر میں۔ مثال کے طور پر، ReplaceMergeTree جیسی میزیں۔ وہ بیک گراؤنڈ انضمام کے دوران اپ ڈیٹ کرتے ہیں۔ آپ اسے آپٹمائز ٹیبل کا استعمال کرکے مجبور کرسکتے ہیں۔ لیکن ایسا اکثر نہ کریں، کیونکہ یہ پارٹیشن کو مکمل طور پر اوور رائٹ کر دے گا۔
ClickHouse میں تقسیم شدہ JOINs کو بھی استفسار کے منصوبہ ساز کے ذریعے خراب طریقے سے ہینڈل کیا جاتا ہے۔
برا، لیکن کبھی کبھی ٹھیک ہے.
منتخب* کا استعمال کرتے ہوئے ڈیٹا کو واپس پڑھنے کے لیے صرف کلک ہاؤس کا استعمال کرنا۔
میں بوجھل حسابات کے لیے ClickHouse استعمال کرنے کی سفارش نہیں کروں گا۔ لیکن یہ مکمل طور پر درست نہیں ہے، کیونکہ ہم پہلے ہی اس سفارش سے دور جا رہے ہیں۔ اور ہم نے حال ہی میں ClickHouse - Catboost میں مشین لرننگ ماڈلز کو لاگو کرنے کی صلاحیت شامل کی ہے۔ اور یہ مجھے پریشان کرتا ہے کیونکہ میں سوچتا ہوں، "کتنی وحشت ہے۔ یہ فی بائٹ کتنے سائیکل نکلتا ہے! مجھے واقعی بائٹس پر گھڑیاں ضائع کرنے سے نفرت ہے۔
لیکن گھبرائیں نہیں، کلک ہاؤس انسٹال کریں، سب ٹھیک ہو جائے گا۔ اگر کچھ ہے تو، ہماری ایک کمیونٹی ہے۔ ویسے کمیونٹی آپ ہیں۔ اور اگر آپ کو کوئی مسئلہ درپیش ہے، تو آپ کم از کم ہماری چیٹ پر جا سکتے ہیں، اور امید ہے کہ وہ آپ کی مدد کریں گے۔
آپ کے سوالات
رپورٹ کے لیے شکریہ! میں ClickHouse کے کریش ہونے کی شکایت کہاں کر سکتا ہوں؟
آپ ابھی ذاتی طور پر مجھ سے شکایت کر سکتے ہیں۔
میں نے حال ہی میں کلک ہاؤس کا استعمال شروع کیا ہے۔ میں نے فوری طور پر cli انٹرفیس کو گرا دیا۔
کیا ایک سکور.
تھوڑی دیر بعد میں نے سرور کو ایک چھوٹی سی سلیکٹ کے ساتھ کریش کر دیا۔
آپ کے پاس ٹیلنٹ ہے۔
میں نے ایک GitHub بگ کھولا، لیکن اسے نظر انداز کر دیا گیا۔
ہم دیکھیں گے.
الیکسی نے مجھے رپورٹ میں شرکت کے لیے دھوکہ دیا، مجھے یہ بتانے کا وعدہ کیا کہ آپ اندر موجود ڈیٹا تک کیسے رسائی حاصل کرتے ہیں۔
بہت آسان ہے.
مجھے اس بات کا کل احساس ہوا۔ مزید تفصیلات۔
وہاں کوئی خوفناک چالیں نہیں ہیں۔ صرف بلاک بہ بلاک کمپریشن ہے۔ ڈیفالٹ LZ4 ہے، آپ ZSTD* کو فعال کر سکتے ہیں۔ بلاکس 64 کلو بائٹ سے 1 میگا بائٹ تک۔
* خصوصی کمپریشن کوڈیکس کے لیے بھی سپورٹ موجود ہے جسے دوسرے الگورتھم کے ساتھ ایک سلسلہ میں استعمال کیا جا سکتا ہے۔
کیا بلاکس صرف خام ڈیٹا ہیں؟
بالکل کچا نہیں۔ صفیں ہیں۔ اگر آپ کے پاس عددی کالم ہے، تو قطار میں نمبر ایک صف میں رکھے جاتے ہیں۔
یہ بات واضح ہے.
الیکسی، ایک مثال جو IPs پر UniqExact کے ساتھ تھی، یعنی یہ حقیقت کہ uniqExact کو نمبروں کے مقابلے لائنوں کے حساب سے حساب کرنے میں زیادہ وقت لگتا ہے، وغیرہ۔ کیا ہوگا اگر ہم پروف ریڈنگ کے وقت اپنے کانوں اور کاسٹ کے ساتھ فینٹ استعمال کریں؟ یعنی، لگتا ہے آپ نے کہا ہے کہ ہماری ڈسک پر یہ بہت مختلف نہیں ہے۔ اگر ہم ڈسک اور کاسٹ سے لائنوں کو پڑھیں تو کیا ہمارے مجموعے تیز ہوں گے یا نہیں؟ یا پھر بھی ہم یہاں تھوڑا سا فائدہ اٹھائیں گے؟ مجھے ایسا لگتا ہے کہ آپ نے اس کا تجربہ کیا ہے، لیکن کسی وجہ سے بینچ مارک میں اس کی نشاندہی نہیں کی۔
مجھے لگتا ہے کہ یہ کاسٹنگ کے بغیر سست ہوگا۔ اس صورت میں، IP ایڈریس کو سٹرنگ سے پارس کیا جانا چاہیے۔ بلاشبہ، ClickHouse پر، ہمارے IP ایڈریس کو پارس کرنا بھی بہتر ہے۔ ہم نے بہت کوشش کی لیکن وہاں آپ کے نمبر دس ہزارویں شکل میں لکھے ہوئے ہیں۔ بہت غیر آرام دہ۔ دوسری طرف، UniqExact فنکشن سٹرنگز پر سست کام کرے گا، نہ صرف اس لیے کہ یہ سٹرنگز ہیں، بلکہ اس لیے بھی کہ الگورتھم کی ایک مختلف تخصص کا انتخاب کیا گیا ہے۔ سٹرنگز کو آسانی سے مختلف طریقے سے پروسیس کیا جاتا ہے۔
کیا ہوگا اگر ہم ایک زیادہ قدیم ڈیٹا ٹائپ لیں؟ مثال کے طور پر، ہم نے صارف کی آئی ڈی، جو ہمارے پاس موجود ہے، اسے ایک لائن کے طور پر لکھ دیا، اور پھر اسے گھمایا، کیا یہ زیادہ مزہ آئے گا یا نہیں؟
مجھے شک ہے. میرے خیال میں یہ اور بھی افسوسناک ہوگا، کیوں کہ آخر کار نمبروں کو پارس کرنا ایک سنگین مسئلہ ہے۔ مجھے ایسا لگتا ہے کہ اس ساتھی نے ایک رپورٹ بھی دی ہے کہ دس ہزارویں شکل میں نمبروں کو پارس کرنا کتنا مشکل ہے، لیکن شاید نہیں۔
الیکسی، رپورٹ کے لیے آپ کا بہت شکریہ! اور ClickHouse کے لیے آپ کا بہت بہت شکریہ! میرے پاس منصوبوں کے بارے میں ایک سوال ہے۔ کیا لغات کو نامکمل طور پر اپ ڈیٹ کرنے کے لیے کسی خصوصیت کا کوئی منصوبہ ہے؟
یہ ہے، ایک جزوی ریبوٹ؟
ہاں ہاں. وہاں ایک MySQL فیلڈ سیٹ کرنے کی صلاحیت کی طرح، یعنی اس کے بعد اپ ڈیٹ کریں تاکہ لغت بہت بڑی ہو تو صرف یہ ڈیٹا لوڈ ہو۔
ایک بہت ہی دلچسپ خصوصیت۔ اور مجھے لگتا ہے کہ کسی شخص نے ہماری بات چیت میں اسے تجویز کیا ہے۔ شاید یہ آپ بھی تھے۔
مجھے ایسا نہیں لگتا۔
بہت اچھا، اب پتہ چلا کہ دو درخواستیں ہیں۔ اور آپ اسے آہستہ آہستہ کرنا شروع کر سکتے ہیں۔ لیکن میں آپ کو فوراً خبردار کرنا چاہتا ہوں کہ یہ فیچر لاگو کرنا کافی آسان ہے۔ یعنی تھیوری میں، آپ کو صرف ٹیبل میں ورژن نمبر لکھنے کی ضرورت ہے اور پھر لکھنا ہے: فلاں اور فلاں سے کم ورژن۔ اس کا مطلب یہ ہے کہ، زیادہ تر امکان ہے، ہم اسے پرجوشوں کو پیش کریں گے۔ کیا آپ ایک پرجوش ہیں؟
ہاں، لیکن، بدقسمتی سے، C++ میں نہیں۔
کیا آپ کے ساتھی C++ میں لکھنا جانتے ہیں؟
میں کسی کو ڈھونڈ لوں گا۔
زبردست*.
* یہ خصوصیت رپورٹ کے دو ماہ بعد شامل کی گئی تھی - سوال کے مصنف نے اسے تیار کیا اور اسے بھیجا۔ .
آپ کا شکریہ!
ہیلو! رپورٹ کے لیے شکریہ! آپ نے بتایا کہ کلک ہاؤس اپنے پاس دستیاب تمام وسائل کو استعمال کرنے میں بہت اچھا ہے۔ اور لکسوفٹ کے ساتھ والے اسپیکر نے روسی پوسٹ کے حل کے بارے میں بات کی۔ انہوں نے کہا کہ وہ واقعی کلک ہاؤس کو پسند کرتے ہیں، لیکن انہوں نے اسے اپنے اہم حریف کے بجائے استعمال نہیں کیا کیونکہ یہ تمام سی پی یو کو کھا رہا تھا۔ اور وہ اسے اپنے فن تعمیر میں، اپنے زو کیپر میں ڈاکرز کے ساتھ نہیں لگا سکے۔ کیا یہ ممکن ہے کہ کسی طرح ClickHouse کو محدود کیا جائے تاکہ وہ ہر اس چیز کو استعمال نہ کرے جو اس کے لیے دستیاب ہو؟
جی ہاں، یہ ممکن ہے اور بہت آسان ہے. اگر آپ کم کور استعمال کرنا چاہتے ہیں، تو صرف لکھیں۔ set max_threads = 1. اور بس، یہ درخواست کو ایک کور میں انجام دے گا۔ مزید برآں، آپ مختلف صارفین کے لیے مختلف ترتیبات کی وضاحت کر سکتے ہیں۔ تو کوئی مسئلہ نہیں۔ اور Luxoft سے اپنے ساتھیوں کو بتائیں کہ یہ اچھا نہیں ہے کہ انہیں دستاویزات میں یہ ترتیب نہیں ملی۔
الیکسی، ہیلو! میں اس سوال کے بارے میں پوچھنا چاہوں گا۔ یہ پہلی بار نہیں ہے جب میں نے سنا ہے کہ بہت سے لوگ کلک ہاؤس کو لاگز کے لیے اسٹوریج کے طور پر استعمال کرنا شروع کر رہے ہیں۔ رپورٹ میں آپ نے کہا تھا کہ ایسا نہ کریں، یعنی آپ کو لمبی تاریں ذخیرہ کرنے کی ضرورت نہیں ہے۔ آپ اس کے بارے میں کیا سوچتے ہیں؟
سب سے پہلے، لاگز، ایک اصول کے طور پر، طویل تار نہیں ہوتے ہیں۔ یقیناً مستثنیات ہیں۔ مثال کے طور پر، جاوا میں لکھی گئی کچھ سروس مستثنیٰ ہے، یہ لاگ ان ہے۔ اور اسی طرح ایک لامتناہی لوپ میں، اور ہارڈ ڈرائیو پر جگہ ختم ہو جاتی ہے۔ حل بہت آسان ہے۔ اگر لائنیں بہت لمبی ہیں تو انہیں کاٹ دیں۔ لمبی کا مطلب کیا ہے؟ دسیوں کلو بائٹس خراب ہیں*۔
* ClickHouse کے تازہ ترین ورژنز میں، "اڈاپٹیو انڈیکس گرینولریٹی" کو فعال کیا گیا ہے، جو زیادہ تر حصے کے لیے لمبی قطاروں کو ذخیرہ کرنے کے مسئلے کو ختم کرتا ہے۔
کیا ایک کلو بائٹ نارمل ہے؟
یہ عام ہے.
ہیلو! رپورٹ کے لیے شکریہ! میں نے پہلے ہی چیٹ میں اس کے بارے میں پوچھا تھا، لیکن مجھے یاد نہیں کہ مجھے جواب ملا یا نہیں۔ کیا کسی طرح سی ٹی ای کے انداز میں WITH سیکشن کو بڑھانے کا منصوبہ ہے؟
ابھی تک نہیں. ہمارا WITH سیکشن کچھ غیر سنجیدہ ہے۔ یہ ہمارے لیے ایک چھوٹی سی خصوصیت کی طرح ہے۔
میں سمجھتا ہوں۔ شکریہ!
رپورٹ کے لیے شکریہ! بہت دلچسپ! عالمی سوال۔ کیا ڈیٹا ڈیلیٹ کرنے میں ترمیم کرنے کا کوئی منصوبہ ہے، شاید کسی قسم کے اسٹبس کی شکل میں؟
لازمی طور پر. یہ ہماری قطار میں ہمارا پہلا کام ہے۔ اب ہم فعال طور پر سوچ رہے ہیں کہ سب کچھ صحیح طریقے سے کیسے کیا جائے۔ اور آپ کو کی بورڈ* کو دبانا شروع کر دینا چاہیے۔
* کی بورڈ پر بٹن دبائے اور سب کچھ کیا۔
کیا اس سے سسٹم کی کارکردگی متاثر ہوگی یا نہیں؟ کیا اندراج اتنا ہی تیز ہوگا جتنا اب ہے؟
شاید ڈیلیٹ خود اور اپڈیٹس خود بہت بھاری ہوں گے، لیکن اس سے سلیکٹس کی کارکردگی یا انسرٹس کی کارکردگی متاثر نہیں ہوگی۔
اور ایک چھوٹا سا سوال۔ پریزنٹیشن میں آپ نے بنیادی کلید کے بارے میں بات کی۔ اس کے مطابق، ہمارے پاس پارٹیشننگ ہے، جو ڈیفالٹ کے لحاظ سے ماہانہ ہے، درست؟ اور جب ہم ایک مہینہ میں فٹ ہونے والی تاریخ کی حد مقرر کرتے ہیں، تو صرف اس تقسیم کو پڑھا جاتا ہے، ٹھیک ہے؟
جی ہاں.
ایک سوال. اگر ہم کسی بنیادی کلید کو منتخب نہیں کر سکتے ہیں، تو کیا اسے خاص طور پر "تاریخ" فیلڈ کے مطابق کرنا درست ہے تاکہ پس منظر میں اس ڈیٹا کی دوبارہ ترتیب کم ہو تاکہ یہ زیادہ منظم انداز میں فٹ ہو؟ اگر آپ کے پاس رینج کے سوالات نہیں ہیں اور آپ کوئی بنیادی کلید بھی منتخب نہیں کر سکتے ہیں، تو کیا بنیادی کلید میں تاریخ ڈالنا مناسب ہے؟
جی ہاں.
ہو سکتا ہے کہ پرائمری کلید میں ایک فیلڈ ڈالنا سمجھ میں آئے جو ڈیٹا کو بہتر طور پر کمپریس کرے گا اگر اسے اس فیلڈ کے مطابق ترتیب دیا جائے۔ مثال کے طور پر یوزر آئی ڈی۔ صارف، مثال کے طور پر، اسی سائٹ پر جاتا ہے۔ اس صورت میں، صارف کی شناخت اور وقت ڈالیں. اور پھر آپ کا ڈیٹا بہتر طور پر کمپریس ہو جائے گا۔ جہاں تک تاریخ کا تعلق ہے، اگر آپ کے پاس واقعی تاریخوں پر رینج کے سوالات نہیں ہیں اور نہ ہی ہیں، تو آپ کو تاریخ کو بنیادی کلید میں ڈالنے کی ضرورت نہیں ہے۔
ٹھیک ہے آپ کا بہت بہت شکریہ!
ماخذ: www.habr.com