ہائی لوڈ++ ماسکو 2018، کانگریس ہال۔ 9 نومبر، 15:00
خلاصہ اور پیشکش:
Yuri Nasretdinov (VKontakte): رپورٹ ہماری کمپنی میں ClickHouse کو لاگو کرنے کے تجربے کے بارے میں بات کرے گی - ہمیں اس کی ضرورت کیوں ہے، ہم کتنا ڈیٹا اسٹور کرتے ہیں، ہم اسے کیسے لکھتے ہیں، وغیرہ۔
اضافی مواد:
یوری ناصردینوف: - سب کو سلام! میرا نام یوری نصریتدینوف ہے، جیسا کہ میرا تعارف ہو چکا ہے۔ میں VKontakte میں کام کرتا ہوں۔ میں اس بارے میں بات کروں گا کہ ہم اپنے سرور فلیٹ (دسیوں ہزار) سے کلک ہاؤس میں ڈیٹا کیسے داخل کرتے ہیں۔
نوشتہ جات کیا ہیں اور انہیں کیوں جمع کرتے ہیں؟
ہم آپ کو کیا بتائیں گے: ہم نے کیا کیا، ہمیں بالترتیب "ClickHouse" کی ضرورت کیوں پڑی، ہم نے اسے کیوں منتخب کیا، آپ کسی بھی چیز کو ترتیب دیئے بغیر تقریباً کس قسم کی کارکردگی حاصل کر سکتے ہیں۔ میں آپ کو بفر ٹیبلز کے بارے میں، ان مسائل کے بارے میں اور اپنے حل کے بارے میں بتاؤں گا جو ہم نے اوپن سورس - KittenHouse اور Lighthouse سے تیار کیے ہیں۔
ہمیں کچھ بھی کرنے کی ضرورت کیوں پڑی (VKontakte پر سب کچھ ہمیشہ اچھا ہوتا ہے، ٹھیک ہے؟) ہم ڈیبگ لاگز کو جمع کرنا چاہتے تھے (اور وہاں سینکڑوں ٹیرا بائٹس ڈیٹا موجود تھے)، شاید کسی نہ کسی طرح اعدادوشمار کا حساب لگانا زیادہ آسان ہو؛ اور ہمارے پاس دسیوں ہزار سرورز کا بیڑا ہے جس سے یہ سب کچھ کرنے کی ضرورت ہے۔
ہم نے فیصلہ کیوں کیا؟ ہمارے پاس شاید نوشتہ جات کو ذخیرہ کرنے کے حل تھے۔ یہاں - اس طرح کا ایک عوامی "بیک اینڈ وی کے" ہے۔ میں اسے سبسکرائب کرنے کی انتہائی سفارش کرتا ہوں۔
نوشتہ جات کیا ہیں؟ یہ ایک انجن ہے جو خالی صفوں کو لوٹاتا ہے۔ VK میں انجن وہ ہیں جنہیں دوسرے مائیکرو سروسز کہتے ہیں۔ اور یہ رہا ایک مسکراتا ہوا اسٹیکر (کافی لائکس)۔ وہ کیسے؟ اچھا، آگے سنو!
نوشتہ جات کو ذخیرہ کرنے کے لیے کیا استعمال کیا جا سکتا ہے؟ ہڈپ کا ذکر نہ کرنا ناممکن ہے۔ پھر، مثال کے طور پر، Rsyslog (ان لاگز کو فائلوں میں اسٹور کرنا)۔ ایل ایس ڈی کون جانتا ہے کہ ایل ایس ڈی کیا ہے؟ نہیں، یہ LSD نہیں۔ بالترتیب فائلیں بھی اسٹور کریں۔ ٹھیک ہے، کلک ہاؤس ایک عجیب آپشن ہے۔
کلک ہاؤس اور حریف: ضروریات اور مواقع
ہم کیا چاہتے ہیں؟ ہم اس بات کو یقینی بنانا چاہتے ہیں کہ ہمیں آپریشن کے بارے میں زیادہ فکر کرنے کی ضرورت نہیں ہے، تاکہ یہ باکس کے باہر کام کرے، ترجیحاً کم سے کم ترتیب کے ساتھ۔ ہم بہت کچھ لکھنا چاہتے ہیں، اور جلدی لکھنا چاہتے ہیں۔ اور ہم اسے ہر طرح کے مہینوں، سالوں، یعنی طویل عرصے تک رکھنا چاہتے ہیں۔ ہم کسی ایسے مسئلے کو سمجھنا چاہتے ہیں جس کے ساتھ وہ ہمارے پاس آئے اور کہا، "یہاں کچھ کام نہیں کر رہا ہے،" اور یہ 3 مہینے پہلے تھا) اور ہم یہ دیکھنا چاہتے ہیں کہ 3 مہینے پہلے کیا ہوا تھا۔" ڈیٹا کمپریشن - یہ واضح ہے کہ یہ ایک پلس کیوں ہوگا - کیونکہ یہ اس میں لگنے والی جگہ کو کم کرتا ہے۔
اور ہمارے پاس ایسی دلچسپ ضرورت ہے: ہم بعض اوقات کچھ کمانڈز (مثال کے طور پر لاگز) کا آؤٹ پٹ لکھتے ہیں، یہ 4 کلو بائٹس سے زیادہ آسانی سے ہو سکتا ہے۔ اور اگر یہ چیز UDP پر کام کرتی ہے، تو اسے خرچ کرنے کی ضرورت نہیں ہے... اس میں کنکشن کے لیے کوئی "اوور ہیڈ" نہیں ہوگا، اور سرورز کی ایک بڑی تعداد کے لیے یہ ایک پلس ہوگا۔
آئیے دیکھتے ہیں کہ اوپن سورس ہمیں کیا پیش کرتا ہے۔ سب سے پہلے، ہمارے پاس لاگ انجن ہے - یہ ہمارا انجن ہے؛ اصولی طور پر وہ سب کچھ کر سکتا ہے، لمبی لائنیں بھی لکھ سکتا ہے۔ ٹھیک ہے، یہ ڈیٹا کو شفاف طریقے سے کمپریس نہیں کرتا ہے - اگر ہم چاہیں تو ہم خود بڑے کالموں کو کمپریس کر سکتے ہیں... ہم یقیناً نہیں چاہتے (اگر ممکن ہو)۔ مسئلہ صرف یہ ہے کہ وہ صرف وہی دے سکتا ہے جو اس کی یادداشت میں فٹ بیٹھتا ہے۔ باقی پڑھنے کے لیے آپ کو اس انجن کا binlog حاصل کرنا ہوگا اور اس کے مطابق اس میں کافی وقت لگتا ہے۔
اور کیا آپشنز ہیں؟ مثال کے طور پر، "Hadup". آپریشن میں آسانی... کون سوچتا ہے کہ ہڈپ کو ترتیب دینا آسان ہے؟ یقینا، ریکارڈنگ کے ساتھ کوئی مسئلہ نہیں ہے. پڑھتے ہوئے کبھی کبھی سوال اٹھتے ہیں۔ اصولی طور پر، میں کہوں گا کہ شاید نہیں، خاص طور پر نوشتہ جات کے لیے۔ طویل مدتی اسٹوریج - یقینا، ہاں، ڈیٹا کمپریشن - ہاں، لمبی تاریں - یہ واضح ہے کہ آپ ریکارڈ کرسکتے ہیں۔ لیکن سرورز کی ایک بڑی تعداد سے ریکارڈنگ... آپ کو ابھی بھی کچھ خود کرنا ہوگا!
Rsyslog درحقیقت، ہم نے اسے بیک اپ آپشن کے طور پر استعمال کیا تاکہ ہم اسے بغیر لاگ کو ڈالے پڑھ سکیں، لیکن یہ لمبی لائنیں نہیں لکھ سکتا؛ اصولی طور پر، یہ 4 کلو بائٹس سے زیادہ نہیں لکھ سکتا۔ آپ کو اسی طرح ڈیٹا کمپریشن خود کرنا ہوگا۔ پڑھنا فائلوں سے آئے گا۔
پھر ایل ایس ڈی کی "بدوشکا" ترقی ہے۔ بنیادی طور پر "Rsyslog" جیسا ہی ہے: یہ لمبی تاروں کو سپورٹ کرتا ہے، لیکن یہ UDP کے ذریعے کام نہیں کر سکتا اور درحقیقت اس کی وجہ سے، بدقسمتی سے، وہاں بہت سی چیزوں کو دوبارہ لکھنے کی ضرورت ہے۔ دسیوں ہزار سرورز سے ریکارڈ کرنے کے قابل ہونے کے لیے LSD کو دوبارہ ڈیزائن کرنے کی ضرورت ہے۔
اور یہاں! ایک مضحکہ خیز آپشن ElasticSearch ہے۔ کیسے کہوں؟ وہ پڑھنے کے ساتھ اچھا کر رہا ہے، یعنی، وہ جلدی پڑھتا ہے، لیکن لکھنے میں بہت اچھا نہیں ہے۔ سب سے پہلے، اگر یہ ڈیٹا کو کمپریس کرتا ہے، تو یہ بہت کمزور ہے۔ غالباً، ایک مکمل تلاش کے لیے اصل حجم سے بڑے ڈیٹا ڈھانچے کی ضرورت ہوتی ہے۔ اسے چلانا مشکل ہے اور اکثر اس کے ساتھ مسائل پیدا ہوتے ہیں۔ اور، دوبارہ، لچکدار میں ریکارڈنگ - ہمیں سب کچھ خود کرنا ہوگا.
یہاں کلک ہاؤس یقیناً ایک مثالی آپشن ہے۔ صرف یہ ہے کہ دسیوں ہزار سرورز سے ریکارڈنگ ایک مسئلہ ہے۔ لیکن کم از کم ایک مسئلہ ہے، ہم اسے کسی طرح حل کرنے کی کوشش کر سکتے ہیں۔ اور باقی رپورٹ اسی مسئلے کے بارے میں ہے۔ آپ ClickHouse سے کس قسم کی کارکردگی کی توقع کر سکتے ہیں؟
ہم اسے کیسے داخل کرنے جا رہے ہیں؟ مرج ٹری
آپ میں سے کس نے "ClickHouse" کے بارے میں نہیں سنا یا نہیں جانا؟ مجھے آپ کو بتانے کی ضرورت ہے، ہے نا؟ بہت تیز. وہاں کا اندراج - 1-2 گیگا بٹس فی سیکنڈ، 10 گیگا بٹس فی سیکنڈ تک کا پھٹنا دراصل اس کنفیگریشن کو برداشت کرسکتا ہے - یہاں دو 6 کور Xeons ہیں (یعنی سب سے زیادہ طاقتور بھی نہیں)، 256 گیگا بائٹس RAM، 20 ٹیرا بائٹس RAID میں (کسی نے بھی کنفیگر نہیں کیا، ڈیفالٹ سیٹنگز)۔ ClickHouse کے ڈویلپر، Alexey Milovidov، شاید وہاں بیٹھا رو رہا ہے کیونکہ ہم نے کچھ بھی کنفیگر نہیں کیا تھا (ہر چیز ہمارے لیے اس طرح کام کرتی تھی)۔ اس کے مطابق، اگر ڈیٹا کو اچھی طرح سے کمپریس کیا جائے تو تقریباً 6 بلین لائنز فی سیکنڈ کی اسکیننگ کی رفتار حاصل کی جا سکتی ہے۔ اگر آپ ٹیکسٹ سٹرنگ پر % پسند کرتے ہیں - 100 ملین لائنز فی سیکنڈ، یعنی یہ کافی تیز لگتا ہے۔
ہم اسے کیسے داخل کرنے جا رہے ہیں؟ ٹھیک ہے، آپ جانتے ہیں کہ VK پی ایچ پی استعمال کرتا ہے۔ ہم ہر پی ایچ پی کارکن سے HTTP کے ذریعے ہر ریکارڈ کے لیے MergeTree ٹیبل میں "ClickHouse" میں داخل کریں گے۔ اس سکیم میں مسئلہ کون دیکھتا ہے؟ کسی وجہ سے، سب نے اپنے ہاتھ نہیں اٹھائے۔ میں آپ کو بتاتا ہوں.
سب سے پہلے، بہت سارے سرور ہیں - اس کے مطابق، بہت سارے کنکشن (خراب) ہوں گے. پھر یہ بہتر ہے کہ MergeTree میں ڈیٹا کو فی سیکنڈ میں ایک بار سے زیادہ داخل نہ کیا جائے۔ اور کون جانتا ہے کیوں؟ ٹھیک ہے ٹھیک ہے. میں آپ کو اس بارے میں تھوڑا اور بتاؤں گا۔ ایک اور دلچسپ سوال یہ ہے کہ ہم تجزیات نہیں کر رہے ہیں، ہمیں ڈیٹا کو افزودہ کرنے کی ضرورت نہیں ہے، ہمیں انٹرمیڈیٹ سرورز کی ضرورت نہیں ہے، ہم براہ راست "ClickHouse" میں داخل کرنا چاہتے ہیں (ترجیحی طور پر - جتنا براہ راست، اتنا ہی بہتر)۔
اس کے مطابق، MergeTree میں اندراج کیسے کیا جاتا ہے؟ یہ کیوں بہتر ہے کہ اس میں ایک سیکنڈ یا اس سے کم بار سے زیادہ بار داخل نہ ہو؟ حقیقت یہ ہے کہ "ClickHouse" ایک کالم کا ڈیٹا بیس ہے اور ڈیٹا کو بنیادی کلید کے صعودی ترتیب میں ترتیب دیتا ہے، اور جب آپ داخل کرتے ہیں، تو بہت سی فائلیں کم از کم کالموں کی تعداد کے برابر بنتی ہیں جن میں ڈیٹا کو ترتیب دیا جاتا ہے۔ بنیادی کلید کے صعودی ترتیب میں (ایک الگ ڈائرکٹری بنائی جاتی ہے، ہر داخل کے لیے ڈسک پر فائلوں کا ایک سیٹ)۔ پھر اگلا اندراج آتا ہے، اور پس منظر میں وہ بڑے "پارٹیشنز" میں مل جاتے ہیں۔ چونکہ ڈیٹا کو ترتیب دیا گیا ہے، اس لیے زیادہ میموری استعمال کیے بغیر ترتیب شدہ دو فائلوں کو "ضم" کرنا ممکن ہے۔
لیکن، جیسا کہ آپ اندازہ لگا سکتے ہیں، اگر آپ ہر داخل کے لیے 10 فائلیں لکھتے ہیں، تو ClickHouse (یا آپ کا سرور) تیزی سے ختم ہو جائے گا، اس لیے بڑے بیچوں میں داخل کرنے کی سفارش کی جاتی ہے۔ اس کے مطابق، ہم نے کبھی بھی پہلی اسکیم کو پیداوار میں شروع نہیں کیا۔ ہم نے فوری طور پر ایک لانچ کیا، جو یہاں نمبر 2 میں ہے:
یہاں تصور کریں کہ تقریباً ایک ہزار سرورز ہیں جن پر ہم نے لانچ کیا ہے، وہاں صرف پی ایچ پی ہے۔ اور ہر سرور پر ہمارا مقامی ایجنٹ ہوتا ہے، جسے ہم "Kittenhouse" کہتے ہیں، جو "ClickHouse" کے ساتھ ایک کنکشن برقرار رکھتا ہے اور ہر چند سیکنڈ میں ڈیٹا داخل کرتا ہے۔ ڈیٹا کو MergeTree میں نہیں بلکہ بفر ٹیبل میں داخل کرتا ہے، جو MergeTree میں براہ راست داخل کرنے سے بچنے کے لیے بالکل ٹھیک کام کرتا ہے۔
بفر ٹیبل کے ساتھ کام کرنا
یہ کیا ہے؟ بفر ٹیبلز میموری کا ایک ٹکڑا ہے جو شارڈ ہوتا ہے (یعنی اسے اس میں کثرت سے ڈالا جا سکتا ہے)۔ وہ کئی ٹکڑوں پر مشتمل ہوتے ہیں، اور ہر ایک ٹکڑا ایک آزاد بفر کے طور پر کام کرتا ہے، اور انہیں آزادانہ طور پر فلش کیا جاتا ہے (اگر آپ کے پاس بفر میں بہت سے ٹکڑے ہیں، تو فی سیکنڈ میں کئی داخلات ہوں گے)۔ ان جدولوں سے پڑھنا ممکن ہے - پھر آپ بفر اور پیرنٹ ٹیبل کے مندرجات کے اتحاد کو پڑھتے ہیں، لیکن اس وقت تحریر مسدود ہے، اس لیے بہتر ہے کہ وہاں سے نہ پڑھیں۔ اور بفر ٹیبلز بہت اچھے QPS دکھاتے ہیں، یعنی 3 ہزار QPS تک داخل کرتے وقت آپ کو کوئی پریشانی نہیں ہوگی۔ یہ واضح ہے کہ اگر سرور پاور کھو دیتا ہے، تو ڈیٹا ضائع ہوسکتا ہے، کیونکہ یہ صرف میموری میں ذخیرہ کیا گیا تھا.
ایک ہی وقت میں، بفر والی اسکیم ALTER کو پیچیدہ بناتی ہے، کیونکہ آپ کو سب سے پہلے پرانی اسکیم کے ساتھ پرانے بفر ٹیبل کو گرانے کی ضرورت ہوتی ہے (ڈیٹا کہیں غائب نہیں ہوگا، کیونکہ ٹیبل کے حذف ہونے سے پہلے اسے فلش کردیا جائے گا)۔ پھر آپ اپنی ضرورت کی میز کو "تبدیل" کریں اور بفر ٹیبل دوبارہ بنائیں۔ اس کے مطابق، جب کہ کوئی بفر ٹیبل نہیں ہے، آپ کا ڈیٹا کہیں بھی نہیں جائے گا، لیکن آپ اسے کم از کم مقامی طور پر ڈسک پر رکھ سکتے ہیں۔
Kittenhouse کیا ہے اور یہ کیسے کام کرتا ہے؟
KittenHouse کیا ہے؟ یہ ایک پراکسی ہے۔ اندازہ لگائیں کہ کون سی زبان ہے؟ میں نے اپنی رپورٹ میں سب سے زیادہ ہائپ کے عنوانات جمع کیے - "کلک ہاؤس"، جاؤ، شاید مجھے کچھ اور یاد ہوگا۔ ہاں، یہ گو میں لکھا گیا ہے، کیونکہ میں واقعی میں نہیں جانتا کہ C میں کیسے لکھنا ہے، میں نہیں چاہتا۔
اس کے مطابق، یہ ہر سرور کے ساتھ ایک کنکشن برقرار رکھتا ہے اور میموری پر لکھ سکتا ہے۔ مثال کے طور پر، اگر ہم Clickhouse پر ایرر لاگ لکھتے ہیں، پھر اگر Clickhouse کے پاس ڈیٹا داخل کرنے کا وقت نہیں ہوتا ہے (آخر میں، اگر بہت زیادہ لکھا جاتا ہے)، تو ہم میموری کو سوجن نہیں کرتے - ہم صرف باقی کو باہر پھینک دیتے ہیں۔ کیونکہ اگر ہم غلطیوں کے فی سیکنڈ میں کئی گیگا بٹ لکھتے ہیں، تو ہم شاید کچھ کو باہر پھینک سکتے ہیں۔ کیٹن ہاؤس یہ کر سکتا ہے۔ اس کے علاوہ، یہ قابل اعتماد ترسیل انجام دے سکتا ہے، یعنی مقامی مشین پر ڈسک پر لکھنا اور ہر بار (وہاں، ہر دو سیکنڈ میں ایک بار) اس فائل سے ڈیٹا ڈیلیور کرنے کی کوشش کرتا ہے۔ اور پہلے ہم نے ریگولر ویلیوز فارمیٹ استعمال کیا - کچھ بائنری فارمیٹ نہیں، ٹیکسٹ فارمیٹ (جیسا کہ ریگولر ایس کیو ایل میں)۔
لیکن پھر یہ ہوا۔ ہم نے قابل اعتماد ترسیل کا استعمال کیا، نوشتہ جات لکھے، پھر فیصلہ کیا (یہ ایک مشروط ٹیسٹ کلسٹر تھا)... اسے کئی گھنٹوں کے لیے باہر رکھا گیا اور بیک اپ لایا گیا، اور ایک ہزار سرورز سے اندراج شروع ہوا - پتہ چلا کہ کلک ہاؤس میں ابھی بھی "کنکشن پر دھاگہ" - اس کے مطابق، ایک ہزار کنکشن میں، ایک فعال اندراج تقریبا ڈیڑھ ہزار کے سرور پر لوڈ اوسط کی طرف جاتا ہے. حیرت کی بات یہ ہے کہ سرور نے درخواستیں قبول کیں، لیکن کچھ دیر بعد بھی ڈیٹا داخل کیا گیا۔ لیکن سرور کے لیے اسے پیش کرنا بہت مشکل تھا...
nginx شامل کریں۔
تھریڈ فی کنکشن ماڈل کے لیے ایسا حل nginx ہے۔ ہم نے کلک ہاؤس کے سامنے nginx نصب کیا، ایک ہی وقت میں دو نقلوں کے لیے توازن قائم کیا (ہمارے اندراج کی رفتار میں 2 گنا اضافہ ہوا، حالانکہ یہ حقیقت نہیں ہے کہ ایسا ہونا چاہیے) اور کلک ہاؤس تک کنکشن کی تعداد کو محدود کر دیا۔ upstream اور، اس کے مطابق، 50 کنکشنز سے زیادہ، ایسا لگتا ہے کہ داخل کرنے کا کوئی فائدہ نہیں ہے۔
تب ہم نے محسوس کیا کہ عام طور پر اس اسکیم کے نقصانات ہیں، کیونکہ ہمارے یہاں صرف ایک nginx ہے۔ اس کے مطابق، اگر یہ nginx کریش ہو جاتا ہے، نقل کی موجودگی کے باوجود، ہم ڈیٹا کھو دیتے ہیں یا کم از کم، کہیں نہیں لکھتے۔ اس لیے ہم نے اپنا بوجھ توازن بنایا۔ ہم نے یہ بھی محسوس کیا کہ "Clickhouse" ابھی بھی نوشتہ جات کے لیے موزوں ہے، اور "شیطان" نے بھی اپنے نوشتہ جات کو "Clickhouse" میں لکھنا شروع کر دیا - بہت آسان، سچ پوچھیں۔ ہم اب بھی اسے دوسرے "شیطانوں" کے لیے استعمال کرتے ہیں۔
پھر ہم نے یہ دلچسپ مسئلہ دریافت کیا: اگر آپ ایس کیو ایل موڈ میں داخل کرنے کا غیر معیاری طریقہ استعمال کرتے ہیں، تو یہ ایک مکمل AST پر مبنی SQL پارسر کو مجبور کرتا ہے، جو کافی سست ہے۔ اس کے مطابق، ہم نے اس بات کو یقینی بنانے کے لیے ترتیبات شامل کی ہیں کہ ایسا کبھی نہ ہو۔ ہم نے لوڈ بیلنسنگ، صحت کی جانچ کی، تاکہ اگر کوئی مر جائے، تب بھی ہم ڈیٹا چھوڑ دیتے ہیں۔ اب ہمارے پاس کافی ٹیبلز ہیں جن کے لیے ہمیں مختلف کلک ہاؤس کلسٹرز کی ضرورت ہے۔ اور ہم نے دوسرے استعمالات کے بارے میں بھی سوچنا شروع کر دیا - مثال کے طور پر، ہم nginx ماڈیولز سے لاگ لکھنا چاہتے تھے، لیکن وہ نہیں جانتے کہ ہمارے RPC کا استعمال کرتے ہوئے بات چیت کیسے کی جائے۔ ٹھیک ہے، میں انہیں یہ سکھانا چاہوں گا کہ کس طرح کم از کم بھیجنا ہے - مثال کے طور پر، لوکل ہوسٹ پر UDP کے ذریعے ایونٹس وصول کرنا اور پھر انہیں Clickhouse پر بھیجنا۔
حل سے ایک قدم دور
حتمی اسکیم اس طرح نظر آنا شروع ہوئی (اس اسکیم کا چوتھا ورژن): کلک ہاؤس کے سامنے ہر سرور پر nginx ہوتا ہے (اسی سرور پر) اور صرف 50 ٹکڑوں کے کنکشن کی حد کے ساتھ لوکل ہوسٹ کو پراکسی کی درخواست کرتا ہے۔ . اور یہ سکیم پہلے ہی کافی کام کر رہی تھی، اس کے ساتھ سب کچھ بہت اچھا تھا۔
ہم تقریباً ایک ماہ تک ایسے ہی رہے۔ ہر کوئی خوش تھا، انہوں نے میزیں شامل کیں، انہوں نے مزید کہا، انہوں نے مزید کہا... عام طور پر، یہ پتہ چلا کہ جس طرح سے ہم نے بفر ٹیبلز کو شامل کیا وہ بہت زیادہ مناسب نہیں تھا (آئیے اسے اسی طرح رکھیں)۔ ہم نے ہر ٹیبل میں 16 ٹکڑے کیے اور چند سیکنڈ کا فلیش وقفہ۔ ہمارے پاس 20 میزیں تھیں اور ہر ٹیبل کو فی سیکنڈ میں 8 داخلے ملتے تھے - اور اس وقت "کلک ہاؤس" شروع ہوا... ریکارڈ سست ہونے لگا۔ وہ گزرے بھی نہیں تھے... Nginx میں بطور ڈیفالٹ ایک ایسی دلچسپ چیز تھی کہ اگر کنکشن اپ اسٹریم پر ختم ہو جاتے ہیں، تو یہ تمام نئی درخواستوں پر آسانی سے "502" واپس کر دیتا ہے۔
اور یہاں ہمارے پاس ہے (میں نے صرف کلک ہاؤس میں ہی لاگز کو دیکھا) تقریباً نصف فیصد درخواستیں ناکام ہوگئیں۔ اس کے مطابق، ڈسک کا استعمال زیادہ تھا، بہت سارے انضمام تھے۔ اچھا، میں نے کیا کیا؟ قدرتی طور پر، میں نے یہ جاننے کی زحمت نہیں کی کہ قطعی طور پر کنکشن اور اپ اسٹریم کیوں ختم ہوا۔
nginx کو ریورس پراکسی سے تبدیل کرنا
میں نے فیصلہ کیا کہ ہمیں اس کا انتظام خود کرنے کی ضرورت ہے، ہمیں اسے nginx پر چھوڑنے کی ضرورت نہیں ہے - nginx نہیں جانتا کہ Clickhouse میں کون سی میزیں ہیں، اور میں نے nginx کو ریورس پراکسی سے تبدیل کیا، جسے میں نے خود بھی لکھا۔
وہ کیا کر رہا ہے؟ یہ fasthttp لائبریری "goshnoy" کی بنیاد پر کام کرتا ہے، یعنی تیز، تقریباً nginx کی طرح تیز۔ معذرت، Igor، اگر آپ یہاں موجود ہیں (نوٹ: Igor Sysoev ایک روسی پروگرامر ہے جس نے nginx ویب سرور بنایا)۔ یہ سمجھ سکتا ہے کہ یہ کس قسم کے سوالات ہیں - INSERT یا SELECT - اس کے مطابق، یہ مختلف قسم کے سوالات کے لیے مختلف کنکشن پول رکھتا ہے۔
اس کے مطابق، یہاں تک کہ اگر ہمارے پاس اندراج کی درخواستوں کو مکمل کرنے کا وقت نہیں ہے، "منتخب" گزر جائیں گے، اور اس کے برعکس۔ اور یہ ڈیٹا کو بفر ٹیبلز میں گروپ کرتا ہے - ایک چھوٹے بفر کے ساتھ: اگر اس میں کوئی خامیاں ہوں، نحو کی خرابیاں، وغیرہ - تاکہ وہ بقیہ ڈیٹا کو بہت زیادہ متاثر نہ کریں، کیونکہ جب ہم بفر ٹیبلز میں آسانی سے داخل کرتے ہیں، تو ہم چھوٹی "بچی" تھی، اور نحو کی تمام غلطیاں صرف اس چھوٹے سے ٹکڑے کو متاثر کرتی تھیں۔ اور یہاں وہ پہلے ہی ایک بڑے بفر کو متاثر کریں گے۔ چھوٹا 1 میگا بائٹ ہے، یعنی اتنا چھوٹا نہیں۔
مطابقت پذیری داخل کرنا اور بنیادی طور پر nginx کو تبدیل کرنا، بنیادی طور پر وہی کام کرتا ہے جو nginx نے پہلے کیا تھا - آپ کو اس کے لیے مقامی "Kittenhouse" کو تبدیل کرنے کی ضرورت نہیں ہے۔ اور چونکہ یہ fasthttp استعمال کرتا ہے، یہ بہت تیز ہے - آپ ریورس پراکسی کے ذریعے سنگل انسرٹس کے لیے فی سیکنڈ 100 ہزار سے زیادہ درخواستیں کر سکتے ہیں۔ نظریاتی طور پر، آپ kittenhouse ریورس پراکسی میں ایک وقت میں ایک لائن ڈال سکتے ہیں، لیکن یقیناً ہم ایسا نہیں کرتے۔
اسکیم اس طرح نظر آنے لگی: "کیٹن ہاؤس"، ریورس پراکسی بہت سی درخواستوں کو ٹیبلز میں گروپ کرتی ہے اور اس کے نتیجے میں، بفر ٹیبلز ان کو اہم میں داخل کرتی ہیں۔
قاتل ایک عارضی حل ہے، بلی کا بچہ مستقل حل ہے۔
یہ ایک دلچسپ مسئلہ ہے... کیا آپ میں سے کسی نے fasthttp استعمال کیا ہے؟ POST کی درخواستوں کے ساتھ fasthttp کس نے استعمال کیا؟ شاید، واقعی ایسا نہیں ہونا چاہیے تھا، کیونکہ یہ درخواست کے باڈی کو بطور ڈیفالٹ بفر کرتا ہے، اور ہمارے بفر کا سائز 16 میگا بائٹس پر سیٹ کیا گیا تھا۔ اندراج نے کچھ وقت پر برقرار رہنا بند کر دیا، اور تمام دسیوں ہزار سرورز سے 16 میگا بائٹ کے ٹکڑے آنا شروع ہو گئے، اور کلک ہاؤس کو بھیجے جانے سے پہلے ان سب کو میموری میں بفر کر دیا گیا۔ اس کے مطابق، میموری ختم ہو گئی، آؤٹ آف میموری کلر آیا اور ریورس پراکسی (یا "کلک ہاؤس" کو مار ڈالا، جو نظریاتی طور پر ریورس پراکسی سے زیادہ "کھا سکتا ہے")۔ سائیکل خود کو دہرایا۔ بہت خوشگوار مسئلہ نہیں ہے۔ اگرچہ ہم نے کئی مہینوں کے آپریشن کے بعد ہی اس سے ٹھوکر کھائی۔
کیا میں نے کیا ہے؟ ایک بار پھر، میں واقعی میں یہ سمجھنا پسند نہیں کرتا کہ اصل میں کیا ہوا ہے۔ میرے خیال میں یہ بالکل واضح ہے کہ آپ کو میموری میں بفر نہیں ہونا چاہئے۔ میں فاسٹ ایچ ٹی پی کو پیچ نہیں کر سکا، حالانکہ میں نے کوشش کی۔ لیکن میں نے اسے بنانے کا ایک طریقہ تلاش کیا تاکہ کسی چیز کو پیچ کرنے کی ضرورت نہ ہو، اور میں HTTP میں اپنا طریقہ لے کر آیا - میں نے اسے KITTEN کہا۔ ٹھیک ہے، یہ منطقی ہے - "VK"، "بلی کا بچہ"... اور کیا؟...
اگر سرور پر بلی کے بچے کے طریقے کے ساتھ کوئی درخواست آتی ہے، تو سرور کو منطقی طور پر "میاؤ" کا جواب دینا چاہیے۔ اگر وہ اس کا جواب دیتا ہے، تو یہ سمجھا جاتا ہے کہ وہ اس پروٹوکول کو سمجھتا ہے، اور پھر میں کنکشن کو روکتا ہوں (fasthttp میں ایسا طریقہ ہے)، اور کنکشن "را" موڈ میں چلا جاتا ہے۔ مجھے اس کی ضرورت کیوں ہے؟ میں کنٹرول کرنا چاہتا ہوں کہ TCP کنکشنز سے پڑھنا کیسے ہوتا ہے۔ ٹی سی پی میں ایک حیرت انگیز خاصیت ہے: اگر کوئی دوسری طرف سے نہیں پڑھ رہا ہے، تو لکھنا انتظار کرنا شروع کر دیتا ہے، اور اس پر میموری خاص طور پر خرچ نہیں ہوتی ہے۔
اور اس لیے میں ایک وقت میں تقریباً 50 کلائنٹس سے پڑھتا ہوں (پچاس سے کیونکہ پچاس ضرور کافی ہونا چاہیے، چاہے ریٹ کسی اور ڈی سی سے آئے)... اس نقطہ نظر سے کھپت کم از کم 20 گنا کم ہوئی ہے، لیکن میں، سچ پوچھوں تو میں صحیح وقت کی پیمائش نہیں کر سکا، کیونکہ یہ پہلے ہی بے معنی ہے (یہ پہلے ہی غلطی کی سطح پر پہنچ چکا ہے)۔ پروٹوکول بائنری ہے، یعنی اس میں ٹیبل کا نام اور ڈیٹا ہوتا ہے۔ کوئی HTTP ہیڈر نہیں ہے، اس لیے میں نے ویب ساکٹ استعمال نہیں کیا (مجھے براؤزرز کے ساتھ بات چیت کرنے کی ضرورت نہیں ہے - میں نے ایک پروٹوکول بنایا ہے جو ہماری ضروریات کے مطابق ہے)۔ اور اس کے ساتھ سب کچھ ٹھیک ہو گیا۔
بفر ٹیبل اداس ہے۔
حال ہی میں ہم نے بفر ٹیبلز کی ایک اور دلچسپ خصوصیت دیکھی۔ اور یہ مسئلہ پہلے ہی دوسروں کے مقابلے میں بہت زیادہ تکلیف دہ ہے۔ آئیے اس صورت حال کا تصور کریں: آپ پہلے سے ہی کلک ہاؤس کو فعال طور پر استعمال کر رہے ہیں، آپ کے پاس درجنوں کلک ہاؤس سرورز ہیں، اور آپ کے پاس کچھ درخواستیں ہیں جنہیں پڑھنے میں بہت زیادہ وقت لگتا ہے (آئیے کہتے ہیں، 60 سیکنڈ سے زیادہ)؛ اور آپ اس وقت آکر Alter کرتے ہیں... اس دوران، "Alter" سے پہلے شروع ہونے والے "انتخابات" کو اس ٹیبل میں شامل نہیں کیا جائے گا، "Alter" شروع نہیں ہوگا - شاید کچھ خصوصیات کہ "Clickhouse" کیسے کام کرتا ہے یہ جگہ. شاید یہ طے کیا جا سکتا ہے؟ یا یہ ممکن نہیں؟
عام طور پر، یہ واضح ہے کہ حقیقت میں یہ اتنا بڑا مسئلہ نہیں ہے، لیکن بفر ٹیبل کے ساتھ یہ زیادہ تکلیف دہ ہو جاتا ہے. کیونکہ، اگر، آئیے کہتے ہیں، آپ کا "الٹر" ٹائم آؤٹ (اور یہ کسی دوسرے میزبان پر ختم ہو سکتا ہے - مثال کے طور پر، آپ پر نہیں، بلکہ ایک نقل پر)، تو پھر... آپ نے بفر ٹیبل کو حذف کر دیا، آپ کا "الٹر" ( یا کوئی اور میزبان) کا وقت ختم ہو گیا۔ پھر ایک "تبدیل" کی خرابی واقع ہوئی ہے) - آپ کو اب بھی اس بات کو یقینی بنانا ہوگا کہ ڈیٹا لکھا جانا جاری رہے: آپ بفر ٹیبلز واپس بناتے ہیں (پیرنٹ ٹیبل کے مطابق اسی اسکیم کے مطابق)، پھر "الٹر" گزرتا ہے، آخر کار ختم ہوتا ہے، اور ٹیبل کا بفر والدین سے اسکیما میں مختلف ہونا شروع ہو جاتا ہے۔ اس پر منحصر ہے کہ "الٹر" کیا تھا، داخل کرنا اب اس بفر ٹیبل پر نہیں جا سکتا ہے - یہ بہت افسوسناک ہے۔
ایسی علامت بھی ہے (شاید کسی نے اسے دیکھا ہو) - اسے کلک ہاؤس کے نئے ورژن میں query_thread_log کہا جاتا ہے۔ پہلے سے طے شدہ طور پر، کچھ ورژن میں ایک تھا. یہاں ہم نے چند مہینوں (840 گیگا بائٹس) میں 100 ملین ریکارڈ جمع کیے ہیں۔ یہ اس حقیقت کی وجہ سے ہے کہ وہاں "داخلے" لکھے گئے تھے (شاید اب، ویسے، وہ نہیں لکھے گئے ہیں)۔ جیسا کہ میں نے آپ کو بتایا، ہمارے "انسرٹس" چھوٹے ہیں - ہمارے پاس بفر ٹیبلز میں بہت سارے "انسرٹس" تھے۔ یہ واضح ہے کہ یہ غیر فعال ہے - میں صرف آپ کو بتا رہا ہوں کہ میں نے ہمارے سرور پر کیا دیکھا۔ کیوں؟ یہ بفر ٹیبل استعمال کرنے کے خلاف ایک اور دلیل ہے! سپاٹی بہت اداس ہے۔
کون جانتا تھا کہ اس آدمی کا نام سپوٹی ہے؟ وی کے ملازمین نے ہاتھ اٹھائے۔ ٹھیک ہے.
"KittenHouse" کے منصوبوں کے بارے میں
منصوبے عام طور پر مشترکہ نہیں ہوتے ہیں، ٹھیک ہے؟ اچانک آپ ان کو پورا نہیں کریں گے اور دوسرے لوگوں کی نظروں میں بہت اچھے نہیں لگیں گے۔ لیکن میں خطرہ لوں گا! ہم مندرجہ ذیل کام کرنا چاہتے ہیں: بفر ٹیبلز، مجھے ایسا لگتا ہے، اب بھی ایک بیساکھی ہیں اور ہمیں اندراج کو خود بفر کرنے کی ضرورت ہے۔ لیکن ہم اب بھی اسے ڈسک پر بفر نہیں کرنا چاہتے، لہذا ہم میموری میں اندراج کو بفر کریں گے۔
اس کے مطابق، جب "داخل" کیا جاتا ہے، تو یہ اب ہم آہنگ نہیں رہے گا - یہ پہلے سے ہی ایک بفر ٹیبل کے طور پر کام کرے گا، پیرنٹ ٹیبل میں داخل کرے گا (اچھی طرح سے، کسی دن بعد) اور ایک علیحدہ چینل کے ذریعے رپورٹ کرے گا جس میں داخلے گزر چکے ہیں اور کون نہیں ہے.
میں ہم وقت ساز داخل کیوں نہیں چھوڑ سکتا؟ یہ بہت زیادہ آسان ہے۔ حقیقت یہ ہے کہ اگر آپ 10 ہزار میزبانوں سے داخل کرتے ہیں، تو سب کچھ ٹھیک ہے - آپ کو ہر میزبان سے تھوڑا سا ملے گا، آپ وہاں ایک سیکنڈ میں ایک بار ڈالیں گے، سب کچھ ٹھیک ہے۔ لیکن میں چاہوں گا کہ یہ اسکیم کام کرے، مثال کے طور پر، دو مشینوں سے، تاکہ آپ تیز رفتاری سے ڈاؤن لوڈ کر سکیں - شاید کلک ہاؤس سے زیادہ سے زیادہ حاصل نہ کریں، لیکن ریورس پراکسی کے ذریعے ایک مشین سے کم از کم 100 میگا بائٹس فی سیکنڈ لکھیں۔ اس اسکیم کو بڑی اور چھوٹی دونوں مقداروں میں پیمانہ ہونا چاہیے، اس لیے ہم ہر اندراج کے لیے ایک سیکنڈ کا انتظار نہیں کر سکتے، اس لیے اسے غیر مطابقت پذیر ہونا چاہیے۔ اور اسی طرح، اندراج مکمل ہونے کے بعد غیر مطابقت پذیر تصدیقیں آنی چاہئیں۔ ہمیں معلوم ہوگا کہ آیا یہ گزر گیا یا نہیں۔
سب سے اہم بات یہ ہے کہ اس اسکیم میں ہم یقینی طور پر جانتے ہیں کہ اندراج ہوا ہے یا نہیں۔ اس صورت حال کا تصور کریں: آپ کے پاس ایک بفر ٹیبل ہے، آپ نے اس میں کچھ لکھا ہے، اور پھر، ہم کہتے ہیں، ٹیبل صرف پڑھنے کے موڈ میں چلا گیا اور بفر کو فلش کرنے کی کوشش کی۔ ڈیٹا کہاں جائے گا؟ وہ بفر میں رہیں گے۔ لیکن ہم اس کے بارے میں یقین سے نہیں کہہ سکتے - اگر کوئی اور خرابی ہو تو کیا ہوگا، جس کی وجہ سے ڈیٹا بفر میں نہیں رہے گا... ہمیشہ؟ الیکسی نے ہمیں یقین دلایا کہ سب کچھ ٹھیک ہو جائے گا۔ ہمارے پاس اس پر یقین نہ کرنے کی کوئی وجہ نہیں ہے۔ لیکن سب ایک جیسے: اگر ہم بفر ٹیبل استعمال نہیں کرتے ہیں، تو ان کے ساتھ کوئی مسئلہ نہیں ہوگا۔ دو گنا زیادہ میزیں بنانا بھی تکلیف دہ ہے، حالانکہ اصولی طور پر کوئی بڑی پریشانی نہیں ہے۔ یہ منصوبہ ہے۔
آئیے پڑھنے کی بات کرتے ہیں۔
اب پڑھنے کی بات کرتے ہیں۔ ہم نے یہاں اپنا ٹول بھی لکھا۔ ایسا لگتا ہے، ٹھیک ہے، یہاں اپنا آلہ کیوں لکھیں؟... اور Tabix کس نے استعمال کیا؟ کسی نہ کسی طرح چند لوگوں نے ہاتھ اٹھائے... اور Tabix کی کارکردگی سے کون مطمئن ہے؟ ٹھیک ہے، ہم اس سے خوش نہیں ہیں، اور یہ ڈیٹا دیکھنے کے لیے بہت آسان نہیں ہے۔ یہ تجزیات کے لیے ٹھیک ہے، لیکن صرف دیکھنے کے لیے یہ واضح طور پر بہتر نہیں ہے۔ تو میں نے اپنا، اپنا انٹرفیس لکھا۔
یہ بہت آسان ہے - یہ صرف ڈیٹا پڑھ سکتا ہے۔ وہ نہیں جانتا کہ گرافکس کیسے دکھانا ہے، وہ کچھ بھی کرنا نہیں جانتا۔ لیکن یہ دکھا سکتا ہے کہ ہمیں کیا ضرورت ہے: مثال کے طور پر، ٹیبل میں کتنی قطاریں ہیں، کتنی جگہ لیتی ہے (اسے کالموں میں توڑے بغیر)، یعنی ایک بہت ہی بنیادی انٹرفیس ہے جس کی ہمیں ضرورت ہے۔
اور یہ سیکوئل پرو سے بہت ملتا جلتا ہے، لیکن صرف ٹویٹر کے بوٹسٹریپ اور دوسرے ورژن پر بنایا گیا ہے۔ آپ پوچھتے ہیں: "یوری، دوسرے ورژن پر کیوں؟" کونسا سال؟ 2018؟ عام طور پر، میں نے یہ کافی عرصہ پہلے "Muscle" (MySQL) کے لیے کیا تھا اور وہاں کے سوالات میں صرف چند سطریں تبدیل کیں، اور اس نے "Clickhouse" کے لیے کام کرنا شروع کر دیا، جس کے لیے خصوصی شکریہ! کیونکہ تجزیہ کار "مسل" سے بہت ملتا جلتا ہے، اور سوالات بہت ملتے جلتے ہیں - بہت آسان، خاص طور پر پہلے۔
ٹھیک ہے، یہ ٹیبلز کو فلٹر کر سکتا ہے، ٹیبل کی ساخت اور مواد کو دکھا سکتا ہے، آپ کو ترتیب دینے، کالموں کے حساب سے فلٹر کرنے کی اجازت دیتا ہے، اس سوال کو ظاہر کرتا ہے جس کے نتیجے میں نتیجہ نکلا، متاثرہ قطاریں (نتیجتاً کتنی)، یعنی ڈیٹا دیکھنے کے لیے بنیادی چیزیں۔ بہت تیز۔
ایک ایڈیٹر بھی ہے۔ میں نے ایمانداری سے Tabix سے پورا ایڈیٹر چرانے کی کوشش کی، لیکن میں ایسا نہیں کر سکا۔ لیکن کسی نہ کسی طرح یہ کام کرتا ہے۔ اصول میں، یہ سب ہے.
"کلک ہاؤس" اڈوں کے لیے موزوں ہے۔
میں آپ کو بتانا چاہتا ہوں کہ کلک ہاؤس، تمام بیان کردہ مسائل کے باوجود، نوشتہ جات کے لیے بہت موزوں ہے۔ سب سے اہم بات یہ ہے کہ یہ ہمارے مسئلے کو حل کرتا ہے - یہ بہت تیز ہے اور آپ کو کالم کے حساب سے لاگ فلٹر کرنے کی اجازت دیتا ہے۔ اصولی طور پر، بفر ٹیبلز نے اچھی کارکردگی کا مظاہرہ نہیں کیا ہے، لیکن عام طور پر کوئی نہیں جانتا کہ کیوں... شاید اب آپ بہتر جان چکے ہوں گے کہ آپ کو کہاں پریشانی ہوگی۔
TCP؟ عام طور پر، VK میں UDP استعمال کرنے کا رواج ہے۔ اور جب میں نے TCP استعمال کیا... یقیناً، مجھے کسی نے نہیں کہا: "یوری، تم کس بارے میں بات کر رہے ہو! آپ نہیں کر سکتے، آپ کو UDP کی ضرورت ہے۔ پتہ چلا کہ TCP اتنا خوفناک نہیں ہے۔ صرف یہ ہے کہ، اگر آپ کے پاس دسیوں ہزار فعال مرکبات ہیں جو آپ لکھتے ہیں، تو آپ کو اسے کچھ زیادہ احتیاط سے تیار کرنے کی ضرورت ہے۔ لیکن یہ ممکن ہے، اور بہت آسان ہے.
میں نے ہائی لوڈ سائبیریا پر "کیٹن ہاؤس" اور "لائٹ ہاؤس" پوسٹ کرنے کا وعدہ کیا تھا اگر ہر کسی نے ہمارے عوامی "VK بیک اینڈ" کو سبسکرائب کیا... اور آپ جانتے ہیں، سب نے سبسکرائب نہیں کیا... یقینا، میں آپ سے ہمارے سبسکرائب کرنے کا مطالبہ نہیں کروں گا۔ عوام. آپ میں سے اب بھی بہت سارے ہیں، کوئی ناراض بھی ہو سکتا ہے، لیکن پھر بھی، براہ کرم سبسکرائب کریں (اور یہاں مجھے بلی کی طرح آنکھیں بنانا ہوں گی)۔ وہ ہے . بہت بہت شکریہ! گیتوب ہمارا ہے۔ . کلک ہاؤس سے آپ کے بال نرم اور ریشمی ہوں گے۔
منتظم: - دوستو، اب سوالات کے لیے۔ ہم تعریفی سرٹیفکیٹ اور VHS پر آپ کی رپورٹ پیش کرنے کے فوراً بعد۔
یوری ناصردینوف (اس کے بعد YN کہا جاتا ہے): - آپ VHS پر میری رپورٹ کو کیسے ریکارڈ کرنے کے قابل تھے اگر یہ ابھی ختم ہو گئی ہے؟
منتظم: - آپ یہ بھی پوری طرح سے طے نہیں کر سکتے کہ "کلک ہاؤس" کیسے کام کرے گا یا نہیں! دوستو، سوالات کے لیے 5 منٹ!
آپ کے سوالات
سامعین سے سوال (اس کے بعد Q کے طور پر جانا جاتا ہے): - صبح بخیر۔ رپورٹ کے لیے آپ کا بہت بہت شکریہ۔ میرے دو سوال ہیں۔ میں کسی فضول بات سے شروع کروں گا: کیا خاکوں میں "کیٹن ہاؤس" کے نام میں حروف کی تعداد (3، 4، 7...) بلیوں کے اطمینان کو متاثر کرتی ہے؟
YN: - کس چیز کی مقدار؟
З: - خط ٹی. تین ٹی ہیں، کہیں تین ٹی کے آس پاس۔
YN: - کیا میں نے اسے ٹھیک نہیں کیا؟ ٹھیک ہے، یقینا یہ کرتا ہے! یہ مختلف پروڈکٹس ہیں - میں اس وقت آپ کو دھوکہ دے رہا تھا۔ ٹھیک ہے، میں مذاق کر رہا ہوں - اس سے کوئی فرق نہیں پڑتا۔ آہ، یہیں! نہیں، یہ وہی چیز ہے، میں نے ایک ٹائپنگ کی ہے.
З: - آپ کا شکریہ. دوسرا سوال سنجیدہ ہے۔ جہاں تک میں سمجھتا ہوں، Clickhouse میں، بفر ٹیبلز خصوصی طور پر میموری میں رہتے ہیں، ڈسک پر بفر نہیں ہوتے اور اس کے مطابق، مستقل نہیں ہوتے۔
YN: - جی ہاں.
З: - اور ایک ہی وقت میں، آپ کا کلائنٹ ڈسک پر بفر کرتا ہے، جس سے ان ہی لاگز کی ترسیل کی کچھ ضمانت ہوتی ہے۔ لیکن کلک ہاؤس میں اس کی کسی بھی طرح سے ضمانت نہیں ہے۔ وضاحت کریں کہ گارنٹی کس طرح کی جاتی ہے، کس وجہ سے؟... یہ طریقہ کار مزید تفصیل سے ہے۔
YN: - جی ہاں، نظریاتی طور پر یہاں کوئی تضاد نہیں ہے، کیونکہ جب کلک ہاؤس گرتا ہے، تو آپ حقیقت میں اسے لاکھوں مختلف طریقوں سے تلاش کر سکتے ہیں۔ اگر کلک ہاؤس کریش ہو جاتا ہے (اگر یہ غلط طریقے سے ختم ہوتا ہے)، تو آپ اپنے لاگ کا تھوڑا سا ریوائنڈ کر سکتے ہیں جو آپ نے لکھا تھا اور اس لمحے سے شروع کر سکتے ہیں جب سب کچھ بالکل ٹھیک تھا۔ ہم کہتے ہیں کہ آپ ایک منٹ کو ریوائنڈ کرتے ہیں، یعنی یہ سمجھا جاتا ہے کہ آپ نے ایک منٹ میں سب کچھ فلش کر دیا ہے۔
З: - یعنی، "کیٹن ہاؤس" کھڑکی کو زیادہ دیر تک رکھتا ہے اور گرنے کی صورت میں اسے پہچان سکتا ہے اور اسے ریوائنڈ کر سکتا ہے؟
YN: - لیکن یہ تھیوری میں ہے۔ عملی طور پر، ہم ایسا نہیں کرتے، اور قابل اعتماد ترسیل صفر سے لامحدود اوقات تک ہوتی ہے۔ لیکن اوسطاً ایک۔ ہم مطمئن ہیں کہ اگر کلک ہاؤس کسی وجہ سے کریش ہو جاتا ہے یا سرورز "ریبوٹ" ہو جاتے ہیں، تو ہم تھوڑا سا کھو دیتے ہیں۔ باقی تمام معاملات میں کچھ نہیں ہوگا۔
З: - ہیلو. شروع سے ہی مجھے ایسا لگتا تھا کہ آپ واقعی رپورٹ کے شروع سے ہی UDP استعمال کر رہے ہوں گے۔ آپ کے پاس HTTP ہے، وہ سب کچھ... اور آپ نے بیان کیے گئے زیادہ تر مسائل، جیسا کہ میں سمجھتا ہوں، اس خاص حل کی وجہ سے پیدا ہوئے تھے...
YN: - ہم TCP کیا استعمال کرتے ہیں؟
З: - بنیادی طور پر ہاں۔
YN: - نہیں.
З: - یہ fasthttp کے ساتھ تھا کہ آپ کو پریشانی تھی، کنکشن کے ساتھ آپ کو پریشانی تھی۔ اگر آپ نے ابھی UDP استعمال کیا ہوتا تو آپ اپنے آپ کو کچھ وقت بچا لیتے۔ ٹھیک ہے، طویل پیغامات یا کسی اور چیز کے ساتھ مسائل ہوں گے ...
YN: - کے ساتھ کیا؟
З: - طویل پیغامات کے ساتھ، چونکہ یہ MTU میں فٹ نہیں ہو سکتا، کچھ اور... ٹھیک ہے، ان کے اپنے مسائل ہو سکتے ہیں۔ سوال یہ ہے کہ: UDP کیوں نہیں؟
YN: – مجھے یقین ہے کہ TCP/IP تیار کرنے والے مصنفین مجھ سے زیادہ ہوشیار ہیں اور مجھ سے بہتر جانتے ہیں کہ پیکٹوں کو سیریلائز کرنے کا طریقہ (تاکہ وہ چلے جائیں)، اسی وقت بھیجنے والی ونڈو کو ایڈجسٹ کریں، نیٹ ورک کو اوورلوڈ نہ کریں، کیا رائے دیں پڑھا نہیں ہے، دوسری طرف شمار نہیں کیا جا رہا ہے... یہ تمام مسائل، میری رائے میں، UDP میں موجود ہوں گے، صرف مجھے اس سے بھی زیادہ کوڈ لکھنا پڑے گا جو میں نے پہلے ہی لکھا تھا تاکہ اسی چیز کو خود سے لاگو کیا جا سکے۔ ناقص مجھے سی میں لکھنا بھی پسند نہیں ہے، وہاں چھوڑ دو...
З: - بس آسان! ٹھیک بھیجا گیا اور کسی بھی چیز کا انتظار نہ کریں - یہ مکمل طور پر غیر مطابقت پذیر ہے۔ ایک نوٹیفکیشن واپس آیا کہ سب کچھ ٹھیک ہے - اس کا مطلب ہے کہ وہ پہنچ گیا ہے۔ اگر یہ نہیں آتا ہے تو اس کا مطلب ہے کہ یہ برا ہے۔
YN: - مجھے دونوں کی ضرورت ہے - مجھے ڈیلیوری کی گارنٹی کے ساتھ اور ڈلیوری کی گارنٹی کے بغیر دونوں بھیجنے کے قابل ہونا چاہیے۔ یہ دو مختلف منظرنامے ہیں۔ مجھے کچھ نوشتہ کھونے کی ضرورت نہیں ہے یا انہیں وجہ کے اندر کھونے کی ضرورت نہیں ہے۔
З: - میں وقت ضائع نہیں کروں گا۔ اس پر مزید بحث کی ضرورت ہے۔ شکریہ
منتظم: - کس کے پاس سوالات ہیں - آسمان کی طرف ہاتھ!
З: - ہیلو، میں ساشا ہوں. رپورٹ کے وسط میں کہیں ایک احساس نمودار ہوا کہ TCP کے علاوہ، ایک ریڈی میڈ حل استعمال کرنا ممکن ہے - کسی قسم کا کافکا۔
YN: - ٹھیک ہے... میں نے آپ کو بتایا تھا کہ میں انٹرمیڈیٹ سرور استعمال نہیں کرنا چاہتا، کیونکہ... کافکا میں، پتہ چلتا ہے کہ ہمارے پاس دس ہزار میزبان ہیں۔ درحقیقت، ہمارے پاس دسیوں ہزار میزبان ہیں۔ بغیر کسی پراکسی کے کافکا کے ساتھ کرنا بھی تکلیف دہ ہو سکتا ہے۔ اس کے علاوہ، سب سے اہم بات، یہ اب بھی "لیٹنسی" دیتا ہے، یہ اضافی میزبان دیتا ہے جو آپ کے پاس ہونا ضروری ہے۔ لیکن میں ان کے پاس نہیں رہنا چاہتا - میں چاہتا ہوں ...
З: "لیکن آخر میں یہ ویسے بھی نکلا۔"
YN: - نہیں، کوئی میزبان نہیں ہیں! یہ سب کلک ہاؤس میزبانوں پر کام کرتا ہے۔
З: - ٹھیک ہے، اور "کیٹن ہاؤس"، جو الٹا ہے - وہ کہاں رہتا ہے؟
YN: - کلک ہاؤس ہوسٹ پر، یہ ڈسک پر کچھ نہیں لکھتا ہے۔
З: - آئیے فرض کریں۔
منتظم: - کیا آپ مطمئن ہیں؟ کیا ہم آپ کو تنخواہ دے سکتے ہیں؟
З: - ہاں تم کر سکتے ہو. درحقیقت، ایک ہی چیز کو حاصل کرنے کے لیے بہت سی بیساکھییں ہیں، اور اب - TCP کے موضوع پر پچھلا جواب، میری رائے میں، اس صورتحال سے متصادم ہے۔ ایسا لگتا ہے جیسے سب کچھ میرے گھٹنوں کے بل بہت کم وقت میں کیا جا سکتا تھا۔
YN: - اور یہ بھی کہ میں کافکا کو کیوں استعمال نہیں کرنا چاہتا تھا، کیونکہ کلک ہاؤس ٹیلی گرام چیٹ میں کافی شکایات تھیں، مثال کے طور پر، کافکا کے پیغامات گم ہو گئے تھے۔ خود کافکا سے نہیں، بلکہ کافکا اور کلکہاؤس کے انضمام میں؛ یا وہاں کچھ نہیں جڑا؟ موٹے طور پر، اس وقت کافکا کے لیے ایک مؤکل لکھنا ضروری ہوگا۔ مجھے نہیں لگتا کہ اس سے آسان یا زیادہ قابل اعتماد حل ہو سکتا ہے۔
З: - مجھے بتائیں، آپ نے کوئی قطار یا کسی قسم کی عام بس کیوں نہیں آزمائی؟ چونکہ آپ کہتے ہیں کہ غیر مطابقت پذیری کے ساتھ آپ خود قطار کے ذریعے لاگ بھیج سکتے ہیں اور قطار کے ذریعے متضاد طور پر جواب وصول کرسکتے ہیں؟
YN: - براہ کرم تجویز کریں کہ کون سی قطاریں استعمال کی جا سکتی ہیں؟
З: - کوئی بھی، یہاں تک کہ اس بات کی ضمانت کے بغیر کہ وہ ترتیب میں ہیں۔ کچھ قسم کی Redis، RMQ...
YN: – مجھے یہ احساس ہے کہ Redis ممکنہ طور پر کلک ہاؤس کو نکالنے والے ایک میزبان (کئی سرورز کے معنی میں) پر بھی اتنی مقدار میں اضافہ نہیں کر سکے گا۔ میں کسی ثبوت کے ساتھ اس کا بیک اپ نہیں لے سکتا (میں نے اسے بینچ مارک نہیں کیا ہے)، لیکن مجھے ایسا لگتا ہے کہ ریڈیس یہاں بہترین حل نہیں ہے۔ اصولی طور پر، اس نظام کو ایک اصلاحی پیغام کی قطار کے طور پر سمجھا جا سکتا ہے، لیکن جو صرف "کلک ہاؤس" کے لیے تیار کیا گیا ہے۔
منتظم: - یوری، آپ کا بہت شکریہ. میں سوال و جواب کو یہیں ختم کرنے کی تجویز پیش کرتا ہوں اور کہتا ہوں کہ سوال کرنے والوں میں سے کس کو کتاب دیں گے۔
YN: - میں سوال پوچھنے والے پہلے شخص کو کتاب دینا چاہوں گا۔
منتظم: - کمال ہے! زبردست! شاندار! بہت شکریہ!
کچھ اشتہارات 🙂
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (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