اپریل میں، Avito انجینئرز کلیک ہاؤس کے مرکزی ڈویلپر الیکسی میلووڈوف اور انٹیگروس کے گولانگ ڈویلپر کیرل شواکوف کے ساتھ آن لائن میٹنگز کے لیے جمع ہوئے۔ ہم نے اس بات پر تبادلہ خیال کیا کہ ہم ڈیٹا بیس مینجمنٹ سسٹم کا استعمال کیسے کرتے ہیں اور ہمیں کن مشکلات کا سامنا کرنا پڑتا ہے۔
میٹنگ کی بنیاد پر، ہم نے بیک اپس، ڈیٹا ری شارڈنگ، بیرونی لغات، گولانگ ڈرائیور اور ClickHouse ورژن کو اپ ڈیٹ کرنے کے بارے میں اپنے اور سامعین کے سوالات کے ماہرین کے جوابات کے ساتھ ایک مضمون مرتب کیا ہے۔ یہ ان ڈویلپرز کے لیے مفید ہو سکتا ہے جو پہلے ہی Yandex DBMS کے ساتھ فعال طور پر کام کر رہے ہیں اور اس کے حال اور مستقبل میں دلچسپی رکھتے ہیں۔ پہلے سے طے شدہ طور پر، جوابات Alexey Milovidov کے ہیں، جب تک کہ دوسری صورت میں نہ لکھا جائے۔
ہوشیار رہو، کٹ کے نیچے بہت زیادہ متن ہے۔ ہم امید کرتے ہیں کہ سوالات کے ساتھ مواد آپ کو تشریف لانے میں مدد کرے گا۔
مواد
اگر آپ متن نہیں پڑھنا چاہتے تو آپ اجتماعات کی ریکارڈنگ دیکھ سکتے ہیں۔ . ٹائم کوڈز ویڈیو کے نیچے پہلے تبصرے میں ہیں۔
کلک ہاؤس کو مسلسل اپ ڈیٹ کیا جاتا ہے، لیکن ہمارا ڈیٹا ایسا نہیں ہے۔ اس کے بارے میں کیا کرنا ہے؟
ClickHouse کو مسلسل اپ ڈیٹ کیا جاتا ہے، اور ہمارا ڈیٹا، جسے حتمی طور پر بہتر بنایا گیا تھا، اپ ڈیٹ نہیں کیا گیا اور بیک اپ کاپی میں ہے۔
ہم کہتے ہیں کہ ہمیں کچھ مسئلہ تھا اور ڈیٹا ضائع ہو گیا تھا۔ ہم نے بحال کرنے کا فیصلہ کیا، اور یہ پتہ چلا کہ پرانے پارٹیشنز، جو بیک اپ سرورز پر محفوظ ہیں، کلک ہاؤس کے موجودہ استعمال شدہ ورژن سے بہت مختلف ہیں۔ ایسی صورت حال میں کیا کرنا چاہیے، اور کیا یہ ممکن ہے؟
ایسی صورت حال جس میں آپ نے بیک اپ سے ڈیٹا کو پرانے فارمیٹ میں بحال کیا ہے، لیکن یہ نئے ورژن سے منسلک نہیں ہے، ناممکن ہے۔ ہم اس بات کو یقینی بناتے ہیں کہ کلک ہاؤس میں ڈیٹا فارمیٹ ہمیشہ پیچھے کی طرف مطابقت رکھتا ہے۔ یہ فعالیت میں پسماندہ مطابقت سے کہیں زیادہ اہم ہے اگر کچھ شاذ و نادر ہی استعمال ہونے والے فنکشن کا برتاؤ بدل گیا ہو۔ کلک ہاؤس کا نیا ورژن ہمیشہ ڈسک پر محفوظ کردہ ڈیٹا کو پڑھنے کے قابل ہونا چاہیے۔ یہ قانون ہے۔
ClickHouse سے ڈیٹا کا بیک اپ لینے کے لیے موجودہ بہترین طریقے کیا ہیں؟
بیک اپ کیسے بنایا جائے، اس بات کو مدنظر رکھتے ہوئے کہ ہمارے پاس حتمی آپریشنز، ٹیرا بائٹس کا ایک بہت بڑا ڈیٹا بیس، اور ڈیٹا جو کہ اپ ڈیٹ کیا گیا ہے، پچھلے تین دنوں سے، اور پھر اس پر کوئی طریقہ کار نہیں ہوتا؟
ہم اپنا حل خود بنا سکتے ہیں اور bash پر لکھ سکتے ہیں: ان بیک اپ کاپیوں کو اس طرح جمع کریں۔ شاید کسی چیز کو بیساکھی لگانے کی ضرورت نہیں ہے، اور سائیکل بہت پہلے ایجاد ہوئی تھی؟
آئیے بہترین طریقوں سے شروع کریں۔ بیک اپ کے بارے میں سوالات کے جواب میں میرے ساتھی ہمیشہ مشورہ دیتے ہیں کہ انہیں Yandex.Cloud سروس کے بارے میں یاد دلائیں، جہاں یہ مسئلہ پہلے ہی حل ہو چکا ہے۔ لہذا اگر ممکن ہو تو اسے استعمال کریں۔
بیک اپ کے لیے کوئی مکمل حل نہیں ہے، سو فیصد کلک ہاؤس میں بنایا گیا ہے۔ کچھ خالی جگہیں ہیں جو استعمال کی جا سکتی ہیں۔ مکمل حل حاصل کرنے کے لیے، آپ کو یا تو دستی طور پر تھوڑا سا ٹنکر کرنا پڑے گا، یا اسکرپٹ کی شکل میں ریپرز بنانا ہوں گے۔
میں سب سے آسان حل کے ساتھ شروع کروں گا اور ڈیٹا کے حجم اور کلسٹر کے سائز کے لحاظ سے سب سے زیادہ نفیس حلوں کے ساتھ ختم کروں گا۔ کلسٹر جتنا بڑا ہوگا، حل اتنا ہی پیچیدہ ہوگا۔
اگر ڈیٹا کے ساتھ ٹیبل صرف چند گیگا بائٹس پر قبضہ کرتا ہے، تو بیک اپ اس طرح کیا جا سکتا ہے:
- ٹیبل کی تعریف کو محفوظ کریں یعنی میٹا ڈیٹا - بنائیں ٹیبل دکھائیں۔.
- کلک ہاؤس کلائنٹ کا استعمال کرتے ہوئے ایک ڈمپ بنائیں - منتخب * میز سے فائل کرنے کے لئے. پہلے سے طے شدہ طور پر آپ کو TabSeparated فارمیٹ میں ایک فائل موصول ہوگی۔ اگر آپ زیادہ موثر بننا چاہتے ہیں، تو آپ اسے مقامی شکل میں کر سکتے ہیں۔
اگر ڈیٹا کی مقدار زیادہ ہے، تو بیک اپ میں زیادہ وقت اور کافی جگہ لگے گی۔ اسے منطقی بیک اپ کہا جاتا ہے؛ یہ ClickHouse ڈیٹا فارمیٹ سے منسلک نہیں ہے۔ اگر ایسا ہے، تو آخری حربے کے طور پر آپ بیک اپ لے سکتے ہیں اور اسے ریکوری کے لیے MySQL پر اپ لوڈ کر سکتے ہیں۔
مزید جدید صورتوں کے لیے، کلک ہاؤس میں مقامی فائل سسٹم میں پارٹیشنز کا سنیپ شاٹ بنانے کی بلٹ ان صلاحیت ہے۔ یہ خصوصیت درخواست کے طور پر دستیاب ہے۔ ٹیبل منجمد پارٹیشن کو تبدیل کریں۔. یا بس ٹیبل منجمد تبدیل کریں - یہ پوری میز کا ایک سنیپ شاٹ ہے۔
سنیپ شاٹ ایک شارڈ پر ایک ٹیبل کے لیے مستقل طور پر بنایا جائے گا، یعنی اس طرح پورے کلسٹر کا ایک مستقل سنیپ شاٹ بنانا ناممکن ہے۔ لیکن زیادہ تر کاموں کے لیے ایسی کوئی ضرورت نہیں ہے، اور ہر شارڈ پر ایک درخواست پر عمل درآمد کرنا اور ایک مستقل سنیپ شاٹ حاصل کرنا کافی ہے۔ یہ ہارڈ لنکس کی شکل میں بنایا گیا ہے اور اس لیے اضافی جگہ نہیں لیتا ہے۔ اس کے بعد، آپ اس سنیپ شاٹ کو بیک اپ سرور یا اس اسٹوریج میں کاپی کرتے ہیں جسے آپ بیک اپ کے لیے استعمال کرتے ہیں۔
اس طرح کے بیک اپ کو بحال کرنا کافی آسان ہے۔ پہلے، موجودہ ٹیبل کی تعریفوں کا استعمال کرتے ہوئے ٹیبل بنائیں۔ اس کے بعد، پارٹیشنز کے محفوظ کردہ سنیپ شاٹس کو ان ٹیبلز کے لیے ڈائرکٹری-ڈیٹیچڈ میں کاپی کریں اور استفسار کو چلائیں۔ تقسیم منسلک کریں. یہ حل اعداد و شمار کے سب سے زیادہ سنجیدہ حجم کے لیے کافی موزوں ہے۔
بعض اوقات آپ کو کچھ ٹھنڈا بھی درکار ہوتا ہے - ایسی صورتوں میں جہاں آپ کے پاس ہر سرور اور سیکڑوں سرورز پر دسیوں یا یہاں تک کہ سینکڑوں ٹیرابائٹس ہوں۔ یہاں ایک حل ہے جسے میں نے Yandex.Metrica سے اپنے ساتھیوں سے اٹھایا ہے۔ میں ہر کسی کو اس کی سفارش نہیں کروں گا - اسے پڑھیں اور خود فیصلہ کریں کہ آیا یہ مناسب ہے یا نہیں۔
سب سے پہلے آپ کو بڑی ڈسک شیلف کے ساتھ کئی سرورز بنانے کی ضرورت ہے۔ اس کے بعد، ان سرورز پر، کئی ClickHouse سرورز کو اٹھائیں اور انہیں ترتیب دیں تاکہ وہ اسی شارڈز کے لیے دوسری نقل کے طور پر کام کریں۔ اور پھر ان سرورز پر فائل سسٹم یا کوئی ٹول استعمال کریں جو آپ کو اسنیپ شاٹس بنانے کی اجازت دیتا ہے۔ یہاں دو آپشنز ہیں۔ پہلا آپشن LVM سنیپ شاٹس ہے، دوسرا آپشن لینکس پر ZFS ہے۔
اس کے بعد، ہر روز آپ کو ایک سنیپ شاٹ بنانے کی ضرورت ہے، یہ جھوٹ بولے گا اور کچھ جگہ لے گا۔ قدرتی طور پر، اگر اعداد و شمار میں تبدیلی آتی ہے، تو جگہ کی مقدار وقت کے ساتھ بڑھ جائے گی۔ یہ سنیپ شاٹ کسی بھی وقت نکالا جا سکتا ہے اور ڈیٹا بحال ہو سکتا ہے، ایسا عجیب حل۔ اس کے علاوہ، ہمیں ان نقلوں کو بھی ترتیب میں محدود کرنے کی ضرورت ہے تاکہ وہ لیڈر بننے کی کوشش نہ کریں۔
کیا شافٹ میں نقل کی ایک کنٹرول وقفہ کو منظم کرنا ممکن ہو گا؟
اس سال آپ کلک ہاؤس میں شافٹ بنانے کی منصوبہ بندی کر رہے ہیں۔ کیا ان میں نقلوں کے کنٹرول شدہ وقفے کو منظم کرنا ممکن ہوگا؟ ہم تبدیلیوں اور دیگر تبدیلیوں کے ساتھ اپنے آپ کو منفی منظرناموں سے بچانے کے لیے اسے استعمال کرنا چاہیں گے۔
کیا تبدیلیوں کے لیے کسی قسم کا رول بیک کرنا ممکن ہے؟ مثال کے طور پر، موجودہ شافٹ میں، لے لو اور کہو کہ اس لمحے تک آپ تبدیلیوں کو لاگو کرتے ہیں، اور اس لمحے سے آپ تبدیلیوں کو لاگو کرنا چھوڑ دیتے ہیں؟
اگر ہمارے کلسٹر پر کوئی کمانڈ آیا اور اسے توڑ دیا، تو ہمارے پاس ایک گھنٹے کے وقفے کے ساتھ ایک مشروط نقل ہے، جہاں ہم کہہ سکتے ہیں کہ چلو اس وقت اسے استعمال کرتے ہیں، لیکن ہم آخری دس منٹ تک اس میں تبدیلیاں لاگو نہیں کریں گے؟
سب سے پہلے، نقل کے کنٹرول شدہ وقفے کے بارے میں۔ صارفین کی طرف سے اس طرح کی درخواست تھی، اور ہم نے اس درخواست کے ساتھ Github پر ایک مسئلہ پیدا کیا: "اگر کسی کو اس کی ضرورت ہو، تو اسے پسند کریں، دل لگا دیں۔" کسی نے ڈیلیور نہیں کیا اور مسئلہ بند ہو گیا۔ تاہم، آپ ClickHouse کو ترتیب دے کر پہلے ہی یہ موقع حاصل کر سکتے ہیں۔ سچ ہے، صرف ورژن 20.3 سے شروع ہوتا ہے۔
ClickHouse مسلسل ڈیٹا کو بیک گراؤنڈ میں ضم کرتا ہے۔ جب انضمام مکمل ہو جاتا ہے، تو ڈیٹا کے ٹکڑوں کا ایک مخصوص سیٹ ایک بڑے ٹکڑے سے بدل دیا جاتا ہے۔ ایک ہی وقت میں، ڈیٹا کے ٹکڑے جو پہلے موجود تھے کچھ دیر تک ڈسک پر رہتے ہیں۔
سب سے پہلے، وہ اس وقت تک ذخیرہ ہوتے رہتے ہیں جب تک کہ ان کو استعمال کرنے والے منتخب سوالات موجود ہوں، تاکہ نان بلاکنگ آپریشن فراہم کیا جا سکے۔ منتخب سوالات پرانے ٹکڑوں سے آسانی سے پڑھے جاتے ہیں۔
دوسرا، ایک وقت کی حد بھی ہے - ڈیٹا کے پرانے ٹکڑے آٹھ منٹ تک ڈسک پر پڑے رہتے ہیں۔ یہ آٹھ منٹ اپنی مرضی کے مطابق بنائے جا سکتے ہیں اور یہاں تک کہ ایک دن میں تبدیل ہو سکتے ہیں۔ اس سے ڈسک کی جگہ خرچ ہوگی: ڈیٹا کے بہاؤ پر منحصر ہے، یہ پتہ چلتا ہے کہ آخری دن میں ڈیٹا نہ صرف دوگنا ہوگا، بلکہ یہ پانچ گنا زیادہ ہوسکتا ہے۔ لیکن اگر کوئی سنگین مسئلہ ہے تو، آپ ClickHouse سرور کو روک سکتے ہیں اور ہر چیز کو حل کر سکتے ہیں۔
اب سوال یہ پیدا ہوتا ہے کہ یہ تبدیلیوں سے کیسے بچاتا ہے؟ یہاں ایک گہرائی سے نظر ڈالنے کے قابل ہے، کیونکہ کلک ہاؤس کے پرانے ورژن میں، الٹر نے اس طرح کام کیا کہ اس نے براہ راست ٹکڑے ٹکڑے کر دئیے۔ کچھ فائلوں کے ساتھ ڈیٹا کا ایک ٹکڑا ہے، اور ہم کرتے ہیں، مثال کے طور پر، ڈراپ کالم کو تبدیل کریں۔. پھر یہ کالم جسمانی طور پر تمام حصوں سے ہٹا دیا جاتا ہے۔
لیکن ورژن 20.3 سے شروع کرتے ہوئے، الٹر میکانزم کو مکمل طور پر تبدیل کر دیا گیا ہے، اور اب ڈیٹا کے ٹکڑے ہمیشہ ناقابل تغیر رہتے ہیں۔ وہ بالکل بھی تبدیل نہیں ہوتے ہیں - تبدیلیاں اب اسی طرح کام کرتی ہیں جس طرح ضم ہوتا ہے۔ جگہ پر ایک ٹکڑے کو تبدیل کرنے کے بجائے، ہم ایک نیا بناتے ہیں. نئے ٹکڑوں میں، وہ فائلیں جو تبدیل نہیں ہوئیں ہارڈ لنکس بن جاتی ہیں، اور اگر ہم کسی کالم کو حذف کرتے ہیں، تو وہ نئے حصے میں غائب ہو جائے گا۔ پرانا ٹکڑا آٹھ منٹ کے بعد ڈیفالٹ کے طور پر حذف ہو جائے گا، اور یہاں آپ اوپر بیان کردہ ترتیبات کو موافقت کر سکتے ہیں۔
تغیرات جیسے تغیرات پر بھی یہی لاگو ہوتا ہے۔ جب آپ کرتے ہیں۔ حذف کو تبدیل کریں یا اپ ڈیٹ کو تبدیل کریں، یہ ٹکڑے کو تبدیل نہیں کرتا ہے، لیکن ایک نیا بناتا ہے۔ اور پھر پرانے کو حذف کر دیتا ہے۔
اگر میز کا ڈھانچہ بدل گیا ہے تو کیا ہوگا؟
پرانی اسکیم کے ساتھ بنایا گیا بیک اپ کیسے بحال کیا جائے؟ اور دوسرا سوال سنیپ شاٹس اور فائل سسٹم ٹولز کے معاملے کے بارے میں ہے۔ کیا لینکس LVM پر ZFS کی بجائے Btrfs یہاں اچھا ہے؟
اگر تم کرو تقسیم منسلک کریں ایک مختلف ساخت کے ساتھ پارٹیشنز، پھر کلک ہاؤس آپ کو بتائے گا کہ یہ ممکن نہیں ہے۔ یہ ہے حل۔ سب سے پہلے پرانے ڈھانچے کے ساتھ MergeTree قسم کا ایک عارضی ٹیبل بنانا، اٹیچ کا استعمال کرتے ہوئے وہاں ڈیٹا منسلک کرنا، اور الٹر استفسار کرنا۔ پھر آپ یا تو اس ڈیٹا کو کاپی یا ٹرانسفر کر سکتے ہیں اور دوبارہ منسلک کر سکتے ہیں، یا درخواست استعمال کر سکتے ہیں۔ ٹیبل منتقل پارٹیشن کو تبدیل کریں۔.
اب دوسرا سوال یہ ہے کہ کیا Btrfs کو استعمال کیا جا سکتا ہے؟ شروع کرنے کے لیے، اگر آپ کے پاس LVM ہے، تو LVM سنیپ شاٹس کافی ہیں، اور فائل سسٹم ext4 ہو سکتا ہے، اس سے کوئی فرق نہیں پڑتا۔ Btrts کے ساتھ، سب کچھ اس کے استعمال میں آپ کے تجربے پر منحصر ہے۔ یہ ایک پختہ فائل سسٹم ہے، لیکن اس بارے میں اب بھی کچھ شکوک و شبہات موجود ہیں کہ کسی خاص منظر نامے میں عملی طور پر سب کچھ کیسے کام کرے گا۔ میں اسے استعمال کرنے کی سفارش نہیں کروں گا جب تک کہ آپ کے پاس پروڈکشن میں Btrfs نہ ہوں۔
ڈیٹا ری شارڈنگ میں موجودہ بہترین طریقے کیا ہیں؟
دوبارہ تقسیم کا مسئلہ پیچیدہ اور کثیر جہتی ہے۔ یہاں کئی ممکنہ جوابات ہیں۔ آپ ایک طرف سے جا کر یہ کہہ سکتے ہیں - ClickHouse میں بلٹ ان ریشارڈنگ فیچر نہیں ہے۔ لیکن مجھے ڈر ہے کہ یہ جواب کسی کو سوٹ نہیں کرے گا۔ لہذا، آپ دوسری طرف سے جا کر کہہ سکتے ہیں کہ ClickHouse کے پاس ڈیٹا کو دوبارہ شیئر کرنے کے بہت سے طریقے ہیں۔
اگر کلسٹر میں جگہ ختم ہو جاتی ہے یا یہ بوجھ کو نہیں سنبھال سکتا تو آپ نئے سرورز شامل کرتے ہیں۔ لیکن یہ سرور ڈیفالٹ کے لحاظ سے خالی ہیں، ان پر کوئی ڈیٹا نہیں ہے، کوئی بوجھ نہیں ہے۔ آپ کو ڈیٹا کو دوبارہ ترتیب دینے کی ضرورت ہے تاکہ یہ نئے، بڑے کلسٹر میں یکساں طور پر پھیل جائے۔
ایسا کرنے کا پہلا طریقہ یہ ہے کہ درخواست کا استعمال کرتے ہوئے پارٹیشنز کے کچھ حصے کو نئے سرورز پر کاپی کریں۔ ٹیبل بازیافت پارٹیشن کو تبدیل کریں۔. مثال کے طور پر، آپ کے مہینے کے لحاظ سے پارٹیشنز تھے، اور آپ 2017 کا پہلا مہینہ لے کر اسے ایک نئے سرور پر کاپی کرتے ہیں، پھر تیسرے مہینے کو کسی اور نئے سرور پر کاپی کرتے ہیں۔ اور آپ ایسا کرتے ہیں جب تک کہ یہ کم و بیش نہ ہوجائے۔
منتقلی صرف ان پارٹیشنز کے لیے کی جا سکتی ہے جو ریکارڈنگ کے دوران تبدیل نہیں ہوتے ہیں۔ تازہ پارٹیشنز کے لیے، ریکارڈنگ کو غیر فعال کرنا پڑے گا، کیونکہ ان کی منتقلی جوہری نہیں ہے۔ بصورت دیگر، آپ ڈیٹا میں ڈپلیکیٹس یا خلاء کے ساتھ ختم ہوجائیں گے۔ تاہم، یہ طریقہ عملی ہے اور کافی مؤثر طریقے سے کام کرتا ہے. ریڈی میڈ کمپریسڈ پارٹیشنز نیٹ ورک پر منتقل ہوتے ہیں، یعنی ڈیٹا کو کمپریس یا دوبارہ انکوڈ نہیں کیا جاتا ہے۔
اس طریقہ کار میں ایک خرابی ہے، اور یہ شارڈنگ اسکیم پر منحصر ہے، چاہے آپ نے اس شارڈنگ اسکیم کا عہد کیا ہے، آپ کے پاس کون سی شارڈنگ کی ہے۔ میٹرکس کے معاملے میں آپ کی مثال میں، شارڈنگ کلید راستے کی ہیش ہے۔ جب آپ ڈسٹری بیوٹڈ ٹیبل کو منتخب کرتے ہیں، تو یہ ایک ساتھ کلسٹر کے تمام شارڈز پر جاتا ہے اور وہاں سے ڈیٹا لیتا ہے۔
اس کا مطلب یہ ہے کہ اس سے آپ کو کوئی فرق نہیں پڑتا کہ کون سا ڈیٹا کس شارڈ پر ختم ہوا۔ اہم بات یہ ہے کہ ایک راستے کے ساتھ ڈیٹا ایک شارڈ پر ختم ہوتا ہے، لیکن کون سا اہم نہیں ہے۔ اس صورت میں، ریڈی میڈ پارٹیشنز کی منتقلی بالکل درست ہے، کیونکہ منتخب سوالات کے ساتھ آپ کو مکمل ڈیٹا بھی ملے گا - چاہے دوبارہ شیئر کرنے سے پہلے ہو یا بعد میں، اسکیم سے کوئی فرق نہیں پڑتا۔
لیکن ایسے معاملات ہیں جو زیادہ پیچیدہ ہیں۔ اگر ایپلی کیشن منطق کی سطح پر آپ ایک خاص شارڈنگ اسکیم پر انحصار کرتے ہیں، کہ یہ کلائنٹ فلاں فلاں شارڈ پر واقع ہے، اور درخواست براہ راست وہاں بھیجی جا سکتی ہے، نہ کہ تقسیم شدہ میز پر۔ یا آپ ClickHouse کا کافی حالیہ ورژن استعمال کر رہے ہیں اور ترتیب کو فعال کر دیا ہے۔ غیر استعمال شدہ شارڈز کو بہتر بنائیں. اس صورت میں، منتخب استفسار کے دوران، جہاں سیکشن میں اظہار کا تجزیہ کیا جائے گا اور اس کا حساب لگایا جائے گا کہ شارڈنگ اسکیم کے مطابق کون سے شارڈز کو استعمال کرنے کی ضرورت ہے۔ یہ کام کرتا ہے بشرطیکہ ڈیٹا کو اس شارڈنگ اسکیم کے مطابق تقسیم کیا گیا ہو۔ اگر آپ انہیں دستی طور پر دوبارہ ترتیب دیتے ہیں تو خط و کتابت تبدیل ہو سکتی ہے۔
تو یہ طریقہ نمبر ایک ہے۔ اور میں آپ کے جواب کا انتظار کر رہا ہوں، آیا طریقہ مناسب ہے، یا آگے بڑھتے ہیں۔
Vladimir Kolobaev، Avito میں نظام کے لیڈ ایڈمنسٹریٹر: الیکسی، آپ نے جس طریقہ کا ذکر کیا ہے وہ بہت اچھا کام نہیں کرتا جب آپ کو پڑھنے سمیت بوجھ پھیلانے کی ضرورت ہوتی ہے۔ ہم ایک ایسا پارٹیشن لے سکتے ہیں جو ماہانہ ہو اور پچھلے مہینے کو دوسرے نوڈ پر لے جا سکتا ہے، لیکن جب اس ڈیٹا کے لیے کوئی درخواست آتی ہے، تو ہم اسے صرف لوڈ کریں گے۔ لیکن ہم پورے کلسٹر کو لوڈ کرنا چاہیں گے، کیونکہ بصورت دیگر، کچھ وقت کے لیے پڑھنے کے پورے بوجھ کو دو شارڈز سے پروسیس کیا جائے گا۔
الیکسی میلووڈوف: یہاں جواب عجیب ہے - ہاں، یہ برا ہے، لیکن یہ کام کر سکتا ہے۔ میں بالکل وضاحت کروں گا کہ کیسے۔ یہ آپ کے ڈیٹا کے پیچھے آنے والے لوڈ منظر نامے کو دیکھنے کے قابل ہے۔ اگر یہ مانیٹرنگ ڈیٹا ہے، تو ہم تقریباً یقینی طور پر کہہ سکتے ہیں کہ درخواستوں کی اکثریت تازہ ڈیٹا کے لیے ہے۔
آپ نے نئے سرورز انسٹال کیے، پرانے پارٹیشنز کو منتقل کیا، لیکن یہ بھی تبدیل کیا کہ تازہ ڈیٹا کیسے ریکارڈ کیا جاتا ہے۔ اور تازہ ڈیٹا پورے کلسٹر میں پھیلا دیا جائے گا۔ اس طرح، صرف پانچ منٹ کے بعد، آخری پانچ منٹ کی درخواستیں کلسٹر کو یکساں طور پر لوڈ کر دیں گی؛ ایک دن کے بعد، XNUMX گھنٹے کی درخواستیں کلسٹر کو یکساں طور پر لوڈ کر دیں گی۔ اور پچھلے مہینے کی درخواستیں، بدقسمتی سے، صرف کلسٹر سرورز کے حصے میں جائیں گی۔
لیکن اکثر آپ کے پاس فروری 2019 کے لیے درخواستیں نہیں ہوں گی۔ زیادہ امکان ہے، اگر درخواستیں 2019 میں جاتی ہیں، تو وہ پورے 2019 کے لیے ہوں گی - وقت کی ایک بڑی مدت کے لیے، نہ کہ کچھ چھوٹی رینج کے لیے۔ اور ایسی درخواستیں کلسٹر کو یکساں طور پر لوڈ کرنے کے قابل بھی ہوں گی۔ لیکن عام طور پر، آپ کا تبصرہ بالکل درست ہے کہ یہ ایک ایڈہاک حل ہے جو ڈیٹا کو مکمل طور پر یکساں طور پر نہیں پھیلاتا ہے۔
میرے پاس سوال کا جواب دینے کے لیے کچھ اور نکات ہیں۔ ان میں سے ایک یہ ہے کہ ابتدائی طور پر شارڈنگ اسکیم کو کس طرح ڈیزائن کیا جائے تاکہ دوبارہ شارڈنگ کم درد کا باعث بنے۔ یہ ہمیشہ ممکن نہیں ہوتا۔
مثال کے طور پر، آپ کے پاس مانیٹرنگ ڈیٹا ہے۔ مانیٹرنگ ڈیٹا تین وجوہات کی بنا پر بڑھ رہا ہے۔ پہلا تاریخی ڈیٹا جمع کرنا ہے۔ دوسرا ٹریفک میں اضافہ ہے۔ اور تیسرا ان چیزوں کی تعداد میں اضافہ ہے جو نگرانی کے تابع ہیں۔ نئی مائیکرو سروسز اور میٹرکس ہیں جنہیں محفوظ کرنے کی ضرورت ہے۔
یہ ممکن ہے کہ ان میں سے سب سے بڑا اضافہ تیسری وجہ سے منسلک ہے - نگرانی کے استعمال میں اضافہ۔ اور اس صورت میں، یہ بوجھ کی نوعیت کو دیکھنے کے قابل ہے، اہم منتخب سوالات کیا ہیں۔ بنیادی منتخب سوالات غالباً میٹرکس کے کچھ ذیلی سیٹ پر مبنی ہوں گے۔
مثال کے طور پر، کچھ سروس کے ذریعہ کچھ سرورز پر سی پی یو کا استعمال۔ یہ پتہ چلتا ہے کہ چابیاں کا ایک مخصوص ذیلی سیٹ ہے جس کے ذریعے آپ کو یہ ڈیٹا ملتا ہے۔ اور خود اس ڈیٹا کے لیے درخواست کافی آسان ہے اور دسیوں ملی سیکنڈ میں مکمل ہو جاتی ہے۔ مانیٹرنگ سروسز اور ڈیش بورڈز کے لیے استعمال کیا جاتا ہے۔ مجھے امید ہے کہ میں اس کو صحیح طریقے سے سمجھ گیا ہوں۔
ولادیمیر کولوبایف: حقیقت یہ ہے کہ ہم اکثر تاریخی اعداد و شمار سے اپیل کرتے ہیں، کیونکہ ہم موجودہ صورت حال کا حقیقی وقت میں تاریخی سے موازنہ کرتے ہیں۔ اور ہمارے لیے ڈیٹا کی ایک بڑی مقدار تک فوری رسائی حاصل کرنا ضروری ہے، اور ClickHouse اس کے ساتھ ایک بہترین کام کرتا ہے۔
آپ بالکل درست کہہ رہے ہیں، ہمیں کسی بھی مانیٹرنگ سسٹم کی طرح آخری دن میں زیادہ تر پڑھی جانے والی درخواستوں کا تجربہ ہوتا ہے۔ لیکن ایک ہی وقت میں، تاریخی ڈیٹا پر بوجھ بھی کافی بڑا ہے۔ یہ بنیادی طور پر ایک الرٹنگ سسٹم سے ہے جو ہر تیس سیکنڈ کے قریب جاتا ہے اور ClickHouse سے کہتا ہے: "مجھے پچھلے چھ ہفتوں کا ڈیٹا دیں۔ اب مجھے ان سے کسی قسم کی متحرک اوسط بنائیں، اور آئیے موجودہ قدر کا تاریخی قدر سے موازنہ کریں۔
میں یہ کہنا چاہوں گا کہ اس طرح کی حالیہ درخواستوں کے لیے ہمارے پاس ایک اور چھوٹی میز ہے جس میں ہم صرف دو دن کا ڈیٹا محفوظ کرتے ہیں، اور اہم درخواستیں اس میں آتی ہیں۔ ہم صرف بڑے شارڈ ٹیبل پر بڑے تاریخی سوالات بھیجتے ہیں۔
الیکسی میلووڈوف: بدقسمتی سے، یہ آپ کے منظر نامے پر ناقص طور پر لاگو ہوتا ہے، لیکن میں آپ کو دو خراب اور پیچیدہ شارڈنگ اسکیموں کی تفصیل بتاؤں گا جنہیں استعمال کرنے کی ضرورت نہیں ہے، لیکن جو میرے دوستوں کی خدمت میں استعمال ہوتی ہیں۔
Yandex.Metrica واقعات کے ساتھ ایک اہم کلسٹر ہے۔ ایونٹس صفحہ کے ملاحظات، کلکس اور تبدیلیاں ہیں۔ زیادہ تر درخواستیں ایک مخصوص ویب سائٹ پر جاتی ہیں۔ آپ Yandex.Metrica سروس کھولتے ہیں، آپ کے پاس ایک ویب سائٹ ہے - avito.ru، رپورٹ پر جائیں، اور آپ کی ویب سائٹ کے لیے درخواست کی جاتی ہے۔
لیکن دوسری درخواستیں ہیں - تجزیاتی اور عالمی - جو اندرونی تجزیہ کاروں کی طرف سے کی گئی ہیں۔ صرف اس صورت میں، میں نوٹ کرتا ہوں کہ اندرونی تجزیہ کار صرف Yandex خدمات کے لیے درخواستیں کرتے ہیں۔ لیکن اس کے باوجود، یہاں تک کہ Yandex کی خدمات بھی تمام ڈیٹا کا ایک اہم حصہ رکھتی ہیں۔ یہ مخصوص کاؤنٹرز کے لیے نہیں بلکہ وسیع تر فلٹرنگ کے لیے درخواستیں ہیں۔
ڈیٹا کو اس طرح کیسے ترتیب دیا جائے کہ سب کچھ ایک کاؤنٹر کے لیے موثر طریقے سے کام کرے، اور عالمی سوالات بھی؟ ایک اور مشکل یہ ہے کہ کلک ہاؤس میں میٹرکس کلسٹر کے لیے درخواستوں کی تعداد کئی ہزار فی سیکنڈ ہے۔ ایک ہی وقت میں، ایک کلک ہاؤس سرور غیر معمولی درخواستوں کو نہیں سنبھال سکتا، مثال کے طور پر، کئی ہزار فی سیکنڈ۔
کلسٹر کا سائز چھ سو کچھ سرورز ہے۔ اگر آپ اس کلسٹر پر صرف ایک ڈسٹری بیوٹڈ ٹیبل کھینچتے ہیں اور وہاں کئی ہزار درخواستیں بھیجتے ہیں، تو یہ انہیں ایک سرور پر بھیجنے سے بھی بدتر ہو جائے گا۔ دوسری طرف، یہ اختیار کہ ڈیٹا یکساں طور پر پھیلا ہوا ہے، اور ہم جا کر تمام سرورز سے درخواست کرتے ہیں، فوری طور پر مسترد کر دیا جاتا ہے۔
ایک آپشن ہے جو متضاد طور پر مخالف ہے۔ تصور کریں کہ کیا ہم ڈیٹا کو تمام سائٹس پر شارڈ کرتے ہیں، اور ایک سائٹ کی درخواست ایک شارڈ پر جاتی ہے۔ اب کلسٹر فی سیکنڈ دس ہزار درخواستوں کو ہینڈل کرنے کے قابل ہو گا، لیکن ایک شارڈ پر کوئی ایک درخواست بہت آہستہ کام کرے گی۔ یہ اب تھرو پٹ کے لحاظ سے پیمانہ نہیں ہوگا۔ خاص طور پر اگر یہ سائٹ avito.ru ہے. میں راز افشا نہیں کروں گا اگر میں یہ کہوں کہ Avito RuNet کی سب سے زیادہ دیکھی جانے والی سائٹوں میں سے ایک ہے۔ اور اسے ایک شارڈ پر پروسیس کرنا پاگل پن ہوگا۔
لہذا، sharding سکیم ایک زیادہ ہوشیار طریقے سے ڈیزائن کیا گیا ہے. پورے کلسٹر کو کئی کلسٹرز میں تقسیم کیا گیا ہے، جسے ہم تہہ کہتے ہیں۔ ہر کلسٹر میں ایک درجن سے لے کر کئی درجن شارڈز ہوتے ہیں۔ کل اس طرح کے انتیس کلسٹرز ہیں۔
یہ سب پیمانہ کیسے ہوتا ہے؟ کلسٹرز کی تعداد تبدیل نہیں ہوتی - جیسا کہ چند سال پہلے انتیس تھا، اب بھی ایسا ہی ہے۔ لیکن ان میں سے ہر ایک کے اندر، ہم دھیرے دھیرے شارڈز کی تعداد میں اضافہ کرتے ہیں جیسا کہ ہم ڈیٹا جمع کرتے ہیں۔ اور مجموعی طور پر شارڈنگ اسکیم اس طرح ہے: ان کلسٹرز کو ویب سائٹس میں تقسیم کیا گیا ہے، اور یہ سمجھنے کے لیے کہ کون سی ویب سائٹ کس کلسٹر پر ہے، MySQL میں ایک علیحدہ میٹا بیس استعمال کیا جاتا ہے۔ ایک سائٹ - ایک کلسٹر پر۔ اور اس کے اندر، وزیٹر آئی ڈی کے مطابق شارڈنگ ہوتی ہے۔
ریکارڈنگ کرتے وقت، ہم انہیں وزیٹر ID کی تقسیم کے بقیہ حصے سے تقسیم کرتے ہیں۔ لیکن جب ایک نیا شارڈ شامل کرتے ہیں تو، شارڈنگ اسکیم بدل جاتی ہے؛ ہم تقسیم ہوتے رہتے ہیں، لیکن بقیہ حصے کے ساتھ دوسرے نمبر سے۔ اس کا مطلب ہے کہ ایک وزیٹر پہلے ہی کئی سرورز پر موجود ہے، اور آپ اس پر بھروسہ نہیں کر سکتے۔ یہ صرف اس بات کو یقینی بنانے کے لیے کیا جاتا ہے کہ ڈیٹا کو بہتر طور پر کمپریس کیا جائے۔ اور درخواستیں کرتے وقت، ہم تقسیم شدہ ٹیبل پر جاتے ہیں، جو کلسٹر کو دیکھتا ہے اور درجنوں سرورز تک رسائی حاصل کرتا ہے۔ یہ ایسی احمقانہ سکیم ہے۔
لیکن میری کہانی ادھوری رہے گی اگر میں یہ نہ کہوں کہ ہم نے اس سکیم کو چھوڑ دیا۔ نئی اسکیم میں، ہم نے ہر چیز کو تبدیل کیا اور کلک ہاؤس کاپیئر کا استعمال کرتے ہوئے تمام ڈیٹا کو کاپی کیا۔
نئی اسکیم میں تمام سائٹس کو دو زمروں میں تقسیم کیا گیا ہے - بڑی اور چھوٹی۔ میں نہیں جانتا کہ حد کا انتخاب کیسے کیا گیا، لیکن نتیجہ یہ نکلا کہ بڑی سائٹس ایک کلسٹر پر ریکارڈ کی جاتی ہیں، جہاں 120 شارڈز ہیں جن میں سے ہر ایک میں تین نقلیں ہیں - یعنی 360 سرورز۔ اور شارڈنگ اسکیم ایسی ہے کہ کوئی بھی درخواست ایک ساتھ تمام شارڈز کو جاتی ہے۔ اگر آپ اب Yandex.Metrica میں avito.ru کے لیے کوئی رپورٹ صفحہ کھولتے ہیں، تو درخواست 120 سرورز پر جائے گی۔ RuNet میں کچھ بڑی سائٹیں ہیں۔ اور درخواستیں ایک ہزار فی سیکنڈ نہیں بلکہ سو سے بھی کم ہیں۔ یہ سب خاموشی سے ڈسٹری بیوٹڈ ٹیبل کے ذریعے چبایا جاتا ہے، جس میں سے ہر ایک 120 سرورز کے ساتھ عمل کرتا ہے۔
اور دوسرا کلسٹر چھوٹی سائٹس کے لیے ہے۔ یہاں سائٹ ID پر مبنی ایک شارڈنگ اسکیم ہے، اور ہر درخواست بالکل ایک شارڈ پر جاتی ہے۔
کلک ہاؤس میں کلک ہاؤس کاپیئر یوٹیلیٹی ہے۔ کیا آپ ہمیں اس کے بارے میں بتا سکتے ہیں؟
میں ابھی کہوں گا کہ یہ حل زیادہ بوجھل اور کچھ کم نتیجہ خیز ہے۔ فائدہ یہ ہے کہ یہ آپ کے بتائے ہوئے پیٹرن کے مطابق ڈیٹا کو مکمل طور پر سمیر کرتا ہے۔ لیکن افادیت کی خرابی یہ ہے کہ یہ بالکل بھی دوبارہ نہیں ہوتی ہے۔ یہ ایک کلسٹر اسکیما سے دوسرے کلسٹر اسکیما میں ڈیٹا کاپی کرتا ہے۔
اس کا مطلب ہے کہ اس کے کام کرنے کے لیے آپ کے پاس دو کلسٹر ہونے چاہئیں۔ وہ ایک ہی سرورز پر واقع ہوسکتے ہیں، لیکن، اس کے باوجود، ڈیٹا کو بتدریج منتقل نہیں کیا جائے گا، بلکہ کاپی کیا جائے گا۔
مثال کے طور پر، چار سرور تھے، اب آٹھ ہیں۔ آپ تمام سرورز، نئی لوکل ٹیبلز پر ایک نیا ڈسٹری بیوٹڈ ٹیبل بناتے ہیں اور کلک ہاؤس کاپیئر لانچ کرتے ہیں، اس میں کام کی اسکیم کی نشاندہی کرتے ہیں کہ اسے وہاں سے پڑھنا چاہیے، نئی شارڈنگ اسکیم کو قبول کرنا چاہیے اور ڈیٹا کو وہاں منتقل کرنا چاہیے۔ اور پرانے سرورز پر آپ کو اب کے مقابلے میں ڈیڑھ گنا زیادہ جگہ کی ضرورت ہوگی، کیونکہ پرانا ڈیٹا ان پر موجود رہنا چاہیے، اور آدھا وہی پرانا ڈیٹا ان کے اوپر آجائے گا۔ اگر آپ نے پہلے سے سوچا تھا کہ ڈیٹا کو دوبارہ شیئر کرنے کی ضرورت ہے اور جگہ موجود ہے تو یہ طریقہ مناسب ہے۔
کلک ہاؤس کاپیئر اندر کیسے کام کرتا ہے؟ یہ ایک شارڈ پر ایک ٹیبل کے ایک پارٹیشن پر کارروائی کرنے کے لئے تمام کاموں کو کاموں کے ایک سیٹ میں توڑ دیتا ہے۔ ان تمام کاموں کو متوازی طور پر انجام دیا جا سکتا ہے، اور کلک ہاؤس کاپیئر کو مختلف مشینوں پر ایک سے زیادہ مثالوں میں چلایا جا سکتا ہے، لیکن یہ ایک پارٹیشن کے لیے جو کچھ کرتا ہے وہ انسرٹ سلیکٹ سے زیادہ کچھ نہیں ہے۔ ڈیٹا کو پڑھا جاتا ہے، ڈیکمپریس کیا جاتا ہے، دوبارہ تقسیم کیا جاتا ہے، پھر دوبارہ کمپریس کیا جاتا ہے، کہیں لکھا جاتا ہے، اور دوبارہ ترتیب دیا جاتا ہے۔ یہ ایک سخت فیصلہ ہے۔
آپ کے پاس ایک پائلٹ چیز تھی جسے resharding کہتے ہیں۔ اس کے ساتھ کیا؟
2017 میں، آپ کے پاس ایک پائلٹ چیز تھی جسے resharding کہتے ہیں۔ کلک ہاؤس میں بھی ایک آپشن موجود ہے۔ جیسا کہ میں سمجھتا ہوں، یہ نہیں ہوا. کیا آپ مجھے بتا سکتے ہیں کہ ایسا کیوں ہوا؟ یہ بہت متعلقہ معلوم ہوتا ہے۔
سارا مسئلہ یہ ہے کہ اگر ڈیٹا کو جگہ جگہ دوبارہ جمع کرنا ضروری ہے تو اسے جوہری طور پر کرنے کے لیے بہت پیچیدہ ہم آہنگی کی ضرورت ہے۔ جب ہم نے یہ دیکھنا شروع کیا کہ یہ ہم آہنگی کیسے کام کرتی ہے، تو یہ واضح ہو گیا کہ بنیادی مسائل تھے۔ اور یہ بنیادی مسائل نہ صرف نظریاتی ہیں، بلکہ فوری طور پر خود کو عملی طور پر کسی ایسی چیز کی شکل میں ظاہر کرنا شروع کر دیا جس کی وضاحت بہت آسان ہے - کچھ بھی کام نہیں کرتا۔
کیا ڈیٹا کے تمام ٹکڑوں کو سست ڈسک پر منتقل کرنے سے پہلے ایک ساتھ ضم کرنا ممکن ہے؟
انضمام کے تناظر میں سست ڈسک آپشن میں منتقل ہونے کے ساتھ TTL کے بارے میں سوال۔ کیا کوئی طریقہ ہے، کرون کے ذریعے، تمام پرزوں کو سست ڈسک پر منتقل کرنے سے پہلے ایک میں ضم کر دیا جائے؟
سوال کا جواب یہ ہے کہ کیا یہ ممکن ہے کہ تمام ٹکڑوں کو منتقل کرنے سے پہلے خود بخود ایک میں چپکا دیا جائے - نہیں۔ مجھے نہیں لگتا کہ یہ ضروری ہے۔ آپ کو تمام حصوں کو ایک میں ضم کرنے کی ضرورت نہیں ہے، لیکن صرف اس حقیقت پر اعتماد کریں کہ وہ خود بخود سست ڈسک میں منتقل ہوجائیں گے۔
ہمارے پاس ٹرانسفر رولز کے دو معیار ہیں۔ پہلا جیسا بھرا ہوا ہے۔ اگر موجودہ سٹوریج ٹائر میں خالی جگہ کی ایک خاص فیصد سے کم ہے، تو ہم ایک حصہ منتخب کرتے ہیں اور اسے آہستہ اسٹوریج میں منتقل کرتے ہیں۔ یا اس کے بجائے، سست نہیں، لیکن اگلا - جیسا کہ آپ ترتیب دیتے ہیں۔
دوسرا معیار سائز ہے۔ یہ بڑے ٹکڑوں کو منتقل کرنے کے بارے میں ہے۔ آپ فاسٹ ڈسک پر خالی جگہ کے مطابق حد کو ایڈجسٹ کر سکتے ہیں، اور ڈیٹا خود بخود منتقل ہو جائے گا۔
اگر پہلے سے مطابقت کی جانچ کرنے کا کوئی طریقہ نہیں ہے تو ClickHouse کے نئے ورژن میں کیسے منتقل کیا جائے؟
اس موضوع پر باقاعدگی سے بحث کی جاتی ہے۔ اکاؤنٹ میں مختلف ورژن لینے، اور اب بھی. ورژن 19.11 سے 19.16 تک اور مثال کے طور پر 19.16 سے 20.3 تک اپ گریڈ کرنا کتنا محفوظ ہے۔ پہلے سے سینڈ باکس میں مطابقت کی جانچ کیے بغیر نئے ورژن میں منتقل ہونے کا بہترین طریقہ کیا ہے؟
یہاں کئی "سنہری" اصول ہیں۔ پہلا - . یہ بڑا ہے، لیکن پیچھے کی طرف متضاد تبدیلیوں کے بارے میں الگ پیراگراف ہیں۔ ان نکات کو سرخ جھنڈا نہ سمجھیں۔ یہ عام طور پر معمولی عدم مطابقتیں ہیں جن میں کچھ کنارے کی فعالیت شامل ہوتی ہے جسے آپ استعمال نہیں کرتے ہیں۔
دوم، اگر سینڈ باکس میں مطابقت کو چیک کرنے کا کوئی طریقہ نہیں ہے، اور آپ فوری طور پر پروڈکشن میں اپ ڈیٹ کرنا چاہتے ہیں، تو تجویز یہ ہے کہ آپ کو ایسا کرنے کی ضرورت نہیں ہے۔ پہلے ایک سینڈ باکس بنائیں اور ٹیسٹ کریں۔ اگر کوئی ٹیسٹ ماحول نہیں ہے، تو آپ کے پاس بہت بڑی کمپنی نہیں ہے، جس کا مطلب ہے کہ آپ اپنے لیپ ٹاپ میں کچھ ڈیٹا کاپی کر سکتے ہیں اور اس بات کو یقینی بنا سکتے ہیں کہ اس پر سب کچھ صحیح طریقے سے کام کر رہا ہے۔ آپ اپنی مشین پر مقامی طور پر کئی نقلیں بھی اٹھا سکتے ہیں۔ یا آپ کسی قریبی جگہ سے ایک نیا ورژن اٹھا سکتے ہیں اور وہاں کچھ ڈیٹا اپ لوڈ کر سکتے ہیں - یعنی ایک بہتر ٹیسٹ ماحول بنائیں۔
ایک اور قاعدہ یہ ہے کہ پروڈکشن میں کیڑے پکڑنے اور اس کے بعد فوری اصلاحات کی وجہ سے ورژن کی ریلیز کے بعد ایک ہفتہ تک اپ ڈیٹ نہ کیا جائے۔ آئیے کلک ہاؤس کے ورژنز کی تعداد معلوم کریں تاکہ الجھن میں نہ پڑیں۔
ورژن 20.3.4 ہے۔ 20 نمبر تیاری کے سال کی نشاندہی کرتا ہے - 2020۔ اندر کیا ہے اس کے نقطہ نظر سے، اس سے کوئی فرق نہیں پڑتا، لہذا ہم اس پر توجہ نہیں دیں گے۔ اگلا - 20.3. ہم دوسرے نمبر کو بڑھاتے ہیں - اس معاملے میں 3 - ہر بار جب ہم کچھ نئی فعالیت کے ساتھ ریلیز جاری کرتے ہیں۔ اگر ہم کلک ہاؤس میں کچھ فیچر شامل کرنا چاہتے ہیں تو ہمیں اس تعداد کو بڑھانا ہوگا۔ یعنی ورژن 20.4 میں کلک ہاؤس اور بھی بہتر کام کرے گا۔ تیسرا ہندسہ 20.3.4 ہے۔ یہاں 4 پیچ ریلیز کی تعداد ہے جس میں ہم نے نئی خصوصیات شامل نہیں کیں، لیکن کچھ کیڑے ٹھیک کیے ہیں۔ اور 4 کا مطلب ہے کہ ہم نے اسے چار بار کیا۔
یہ مت سوچیں کہ یہ کوئی خوفناک چیز ہے۔ عام طور پر صارف تازہ ترین ورژن انسٹال کرسکتا ہے اور یہ ہر سال اپ ٹائم کے ساتھ بغیر کسی پریشانی کے کام کرے گا۔ لیکن تصور کریں کہ بٹ میپس کو پروسیس کرنے کے کسی فنکشن میں، جسے ہمارے چینی کامریڈز نے شامل کیا تھا، غلط دلائل دینے پر سرور کریش ہو جاتا ہے۔ اس کو ٹھیک کرنا ہماری ذمہ داری ہے۔ ہم ایک نیا پیچ ورژن جاری کریں گے اور کلک ہاؤس مزید مستحکم ہو جائے گا۔
اگر آپ کے پاس کلک ہاؤس پروڈکشن میں چل رہا ہے، اور کلک ہاؤس کا نیا ورژن اضافی خصوصیات کے ساتھ سامنے آتا ہے - مثال کے طور پر، 20.4.1 سب سے پہلا ورژن ہے، تو پہلے ہی دن اسے پروڈکشن میں ڈالنے میں جلدی نہ کریں۔ اس کی ضرورت بھی کیوں ہے؟ اگر آپ پہلے سے کلک ہاؤس استعمال نہیں کرتے ہیں، تو آپ اسے انسٹال کر سکتے ہیں، اور غالباً سب کچھ ٹھیک ہو جائے گا۔ لیکن اگر ClickHouse پہلے سے ہی مستحکم طریقے سے کام کر رہا ہے، تو پیچ اور اپ ڈیٹس پر نظر رکھیں کہ ہم کن مسائل کو حل کر رہے ہیں۔
کریل شواکوف: میں ٹیسٹ کے ماحول کے بارے میں تھوڑا سا اضافہ کرنا چاہوں گا۔ ہر کوئی ٹیسٹ کے ماحول سے بہت ڈرتا ہے اور کسی وجہ سے وہ مانتے ہیں کہ اگر آپ کے پاس کلک ہاؤس کا ایک بہت بڑا کلسٹر ہے، تو ٹیسٹ کا ماحول کم یا کم از کم دس گنا چھوٹا نہیں ہونا چاہیے۔ ایسا بالکل نہیں ہے۔
میں آپ کو اپنی مثال سے بتا سکتا ہوں۔ میرے پاس ایک پروجیکٹ ہے، اور کلک ہاؤس ہے۔ ہمارا امتحانی ماحول صرف اس کے لیے ہے - یہ ہیٹزنر میں بیس یورو کی ایک چھوٹی سی ورچوئل مشین ہے، جہاں بالکل سب کچھ تعینات ہے۔ ایسا کرنے کے لیے، ہمارے پاس Ansible میں مکمل آٹومیشن ہے، اور اس لیے اصولی طور پر، اس سے کوئی فرق نہیں پڑتا کہ کہاں جانا ہے - ہارڈویئر سرورز پر یا صرف ورچوئل مشینوں میں تعینات کرنا ہے۔
کیا کیا جا سکتا ہے؟ یہ اچھا ہوگا کہ ClickHouse دستاویزات میں ایک مثال فراہم کریں کہ آپ اپنے گھر میں ایک چھوٹے سے کلسٹر کو کیسے تعینات کریں - Docker میں، LXC میں، شاید ایک Ansible playbook بنائیں، کیونکہ مختلف لوگوں کی مختلف تعیناتیاں ہوتی ہیں۔ یہ بہت آسان ہو جائے گا. جب آپ پانچ منٹ میں ایک کلسٹر لے کر تعینات کرتے ہیں، تو کچھ معلوم کرنے کی کوشش کرنا بہت آسان ہوتا ہے۔ یہ بہت زیادہ آسان ہے، کیونکہ ایسے پروڈکشن ورژن میں شامل ہونا جس کا آپ نے تجربہ نہیں کیا ہے، کہیں بھی نہیں جانا ہے۔ کبھی کبھی یہ کام کرتا ہے اور کبھی کبھی ایسا نہیں ہوتا ہے۔ اور اس لیے کامیابی کی امید رکھنا برا ہے۔
میکسم کوٹیاکوف، سینئر بیک اینڈ انجینئر ایویٹو: میں بڑی کمپنیوں کو درپیش مسائل کی ایک سیریز سے ٹیسٹ کے ماحول کے بارے میں تھوڑا سا اضافہ کروں گا۔ ہمارے پاس ایک مکمل کلک ہاؤس قبولیت کا کلسٹر ہے؛ ڈیٹا اسکیموں اور ترتیبات کے لحاظ سے، یہ اس چیز کی بالکل صحیح کاپی ہے جو پروڈکشن میں ہے۔ اس کلسٹر کو کم سے کم وسائل کے ساتھ کافی حد تک رن ڈاون کنٹینرز میں تعینات کیا گیا ہے۔ ہم وہاں پروڈکشن ڈیٹا کا ایک خاص فیصد لکھتے ہیں، خوش قسمتی سے کافکا میں اس سلسلے کی نقل تیار کرنا ممکن ہے۔ وہاں موجود ہر چیز مطابقت پذیر اور پیمانہ ہے - صلاحیت اور بہاؤ دونوں کے لحاظ سے، اور، نظریہ میں، باقی تمام چیزیں برابر ہونے کی وجہ سے، اسے میٹرکس کے لحاظ سے پیداوار کی طرح برتاؤ کرنا چاہیے۔ ممکنہ طور پر دھماکہ خیز ہر چیز کو پہلے اس سٹینڈ پر لپیٹ دیا جاتا ہے اور تیار ہونے تک کئی دنوں تک وہاں چھوڑ دیا جاتا ہے۔ لیکن قدرتی طور پر، یہ حل مہنگا، مشکل ہے اور اس میں غیر صفر امدادی لاگت ہے۔
الیکسی میلووڈوف: میں آپ کو بتاؤں گا کہ Yandex.Metrica کے ہمارے دوستوں کا امتحانی ماحول کیسا ہے۔ ایک کلسٹر میں 600 سے زیادہ سرورز تھے، دوسرے میں 360 تھے، اور تیسرا اور کئی کلسٹرز ہیں۔ ان میں سے ایک کے لیے ٹیسٹ کا ماحول صرف دو شارڈز ہے جس میں ہر ایک میں دو نقلیں ہیں۔ دو ٹکڑے کیوں؟ تاکہ آپ اکیلے نہ ہوں۔ اور نقلیں بھی ہونی چاہئیں۔ صرف ایک مخصوص کم از کم رقم جو آپ برداشت کر سکتے ہیں۔
یہ ٹیسٹ ماحول آپ کو یہ چیک کرنے کی اجازت دیتا ہے کہ آیا آپ کے سوالات کام کر رہے ہیں اور اگر کوئی اہم چیز ٹوٹ گئی ہے۔ لیکن اکثر مسائل بالکل مختلف نوعیت کے ہوتے ہیں، جب سب کچھ کام کرتا ہے، لیکن بوجھ میں کچھ چھوٹی تبدیلیاں ہوتی ہیں۔
میں آپ کو ایک مثال دیتا ہوں۔ ہم نے کلک ہاؤس کا نیا ورژن انسٹال کرنے کا فیصلہ کیا۔ اسے آزمائشی ماحول پر پوسٹ کیا گیا ہے، Yandex.Metrica میں خودکار ٹیسٹ مکمل ہو چکے ہیں، جو کہ پرانے ورژن اور نئے ورژن کے ڈیٹا کا موازنہ کرتے ہیں، جو پوری پائپ لائن کو چلا رہے ہیں۔ اور ظاہر ہے، ہمارے CI کے گرین ٹیسٹ۔ ورنہ ہم یہ ورژن تجویز بھی نہ کرتے۔
سب کچھ ٹھیک ہے. ہم پیداوار میں منتقل ہونا شروع کر رہے ہیں۔ مجھے ایک پیغام موصول ہوا کہ گراف پر بوجھ کئی گنا بڑھ گیا ہے۔ ہم ورژن کو واپس لے رہے ہیں۔ میں گراف کو دیکھتا ہوں اور دیکھتا ہوں: رول آؤٹ کے دوران دراصل بوجھ کئی گنا بڑھ گیا، اور جب وہ رول آؤٹ ہوا تو واپس کم ہوا۔ پھر ہم نے ورژن کو واپس کرنا شروع کیا۔ اور بوجھ اسی طرح بڑھا اور اسی طرح واپس گر گیا۔ تو نتیجہ یہ ہے: ترتیب کی وجہ سے بوجھ بڑھ گیا ہے، کوئی تعجب کی بات نہیں۔
پھر نئے ورژن کو انسٹال کرنے کے لیے ساتھیوں کو قائل کرنا مشکل تھا۔ میں کہتا ہوں: "یہ ٹھیک ہے، رول آؤٹ۔ اپنی انگلیاں کراس رکھیں، سب کام ہو جائے گا۔ اب گراف پر بوجھ بڑھ گیا ہے، لیکن سب کچھ ٹھیک ہے۔ وہیں رک جاؤ۔" عام طور پر، ہم نے یہ کیا، اور یہ ہے - ورژن پیداوار کے لئے جاری کیا گیا تھا. لیکن تقریباً ہر ترتیب کے ساتھ اسی طرح کے مسائل پیدا ہوتے ہیں۔
کِل استفسار سے سوالات کو ختم کرنا سمجھا جاتا ہے، لیکن ایسا نہیں ہوتا۔ کیوں؟
ایک صارف، کسی قسم کا تجزیہ کار، میرے پاس آیا اور ایک درخواست کی جس نے میرا کلک ہاؤس کلسٹر ڈال دیا۔ کچھ نوڈ یا پورا کلسٹر، اس پر منحصر ہے کہ درخواست کس نقل یا شارڈ پر گئی تھی۔ میں دیکھ رہا ہوں کہ اس سرور پر تمام CPU وسائل ایک شیلف میں ہیں، ہر چیز سرخ ہے۔ ایک ہی وقت میں، ClickHouse خود درخواستوں کا جواب دیتا ہے۔ اور میں لکھتا ہوں: "براہ کرم مجھے دکھائیں، عمل کی فہرست، کس درخواست نے یہ جنون پیدا کیا۔"
مجھے یہ درخواست مل گئی اور میں اس پر قتل لکھتا ہوں۔ اور میں دیکھ رہا ہوں کہ کچھ نہیں ہو رہا ہے۔ میرا سرور ایک شیلف میں ہے، کلک ہاؤس پھر مجھے کچھ حکم دیتا ہے، ظاہر کرتا ہے کہ سرور زندہ ہے، اور سب کچھ بہت اچھا ہے۔ لیکن میرے پاس تمام صارف کی درخواستوں میں تنزلی ہے، انحطاط کلک ہاؤس میں ریکارڈ کے ساتھ شروع ہوتا ہے، اور میرا قتل کا سوال کام نہیں کرتا ہے۔ کیوں؟ میں نے سوچا کہ قتل کے سوال سے سوالات کو ختم کرنا تھا، لیکن ایسا نہیں ہوتا۔
اب ایک عجیب سا جواب آئے گا۔ نقطہ یہ ہے کہ قتل کے استفسار سے سوالات ختم نہیں ہوتے ہیں۔
Kill query ایک چھوٹا سا باکس چیک کرتا ہے جسے "میں چاہتا ہوں کہ اس استفسار کو ختم کر دیا جائے۔" اور ہر بلاک پر کارروائی کرتے وقت درخواست خود اس جھنڈے کو دیکھتی ہے۔ اگر یہ سیٹ ہے تو درخواست کام کرنا بند کر دیتی ہے۔ معلوم ہوا کہ درخواست کو کوئی نہیں مارتا، اسے خود ہی سب کچھ چیک کرکے روکنا ہوگا۔ اور یہ ان تمام صورتوں میں کام کرے جہاں درخواست ڈیٹا کے بلاکس پر کارروائی کی حالت میں ہو۔ یہ ڈیٹا کے اگلے بلاک پر کارروائی کرے گا، جھنڈا چیک کرے گا اور رک جائے گا۔
یہ ان صورتوں میں کام نہیں کرتا جہاں درخواست کو کچھ آپریشن پر روک دیا گیا ہو۔ سچ ہے، غالباً یہ آپ کا معاملہ نہیں ہے، کیونکہ، آپ کے مطابق، یہ سرور کے ایک ٹن وسائل استعمال کرتا ہے۔ یہ ممکن ہے کہ یہ بیرونی چھانٹی اور کچھ دیگر تفصیلات کے معاملے میں کام نہ کرے۔ لیکن عام طور پر ایسا نہیں ہونا چاہیے، یہ ایک بگ ہے۔ اور صرف ایک چیز جس کی میں سفارش کرسکتا ہوں وہ ہے کلک ہاؤس کو اپ ڈیٹ کرنا۔
پڑھنے کے بوجھ کے تحت جوابی وقت کا حساب کیسے لگائیں؟
ایک میز ہے جو اشیاء کے مجموعی ذخیرہ کرتا ہے - مختلف کاؤنٹرز۔ لائنوں کی تعداد تقریباً ایک سو ملین ہے۔ اگر آپ 1K آئٹمز کے لیے 1K RPS ڈالتے ہیں تو کیا متوقع جوابی وقت پر اعتماد کرنا ممکن ہے؟
سیاق و سباق کو دیکھتے ہوئے، ہم پڑھنے کے بوجھ کے بارے میں بات کر رہے ہیں، کیونکہ لکھنے کے ساتھ کوئی مسئلہ نہیں ہے - یہاں تک کہ ایک ہزار، یہاں تک کہ ایک لاکھ، اور بعض اوقات کئی ملین قطاریں ڈالی جا سکتی ہیں۔
پڑھنے کی درخواستیں بہت مختلف ہیں۔ منتخب 1 میں، ClickHouse فی سیکنڈ میں دسیوں ہزار درخواستیں انجام دے سکتا ہے، لہذا ایک کلید کی درخواستوں کے لیے پہلے سے ہی کچھ وسائل کی ضرورت ہوگی۔ اور اس طرح کے نکات کے سوالات کچھ کلیدی قدر والے ڈیٹا بیس کی نسبت زیادہ مشکل ہوں گے، کیونکہ ہر پڑھنے کے لیے انڈیکس کے حساب سے ڈیٹا کا ایک بلاک پڑھنا ضروری ہے۔ ہمارا انڈیکس ہر ریکارڈ کو نہیں بلکہ ہر رینج کو ایڈریس کرتا ہے۔ یعنی آپ کو پوری رینج پڑھنی پڑے گی - یہ 8192 لائنیں بطور ڈیفالٹ ہے۔ اور آپ کو کمپریسڈ ڈیٹا بلاک کو 64 KB سے 1 MB تک ڈیکمپریس کرنا پڑے گا۔ عام طور پر، اس طرح کے ھدف بنائے گئے سوالات کو مکمل ہونے میں چند ملی سیکنڈ لگتے ہیں۔ لیکن یہ سب سے آسان آپشن ہے۔
آئیے کچھ آسان ریاضی کی کوشش کریں۔ اگر آپ چند ملی سیکنڈز کو ہزار سے ضرب دیتے ہیں تو آپ کو چند سیکنڈ ملتے ہیں۔ ایسا لگتا ہے کہ فی سیکنڈ ہزار درخواستوں کو برقرار رکھنا ناممکن ہے، لیکن حقیقت میں یہ ممکن ہے، کیونکہ ہمارے پاس کئی پروسیسر کور ہیں۔ لہذا، اصولی طور پر، ClickHouse بعض اوقات 1000 RPS رکھ سکتا ہے، لیکن مختصر درخواستوں کے لیے، خاص طور پر ٹارگٹ شدہ درخواستوں کے لیے۔
اگر آپ کو سادہ درخواستوں کی تعداد کے حساب سے کلک ہاؤس کلسٹر کی پیمائش کرنے کی ضرورت ہے، تو میں سب سے آسان چیز کی سفارش کرتا ہوں - نقل کی تعداد میں اضافہ کریں اور بے ترتیب نقل پر درخواستیں بھیجیں۔ اگر ایک نقل فی سیکنڈ میں پانچ سو درخواستیں رکھتی ہے، جو کہ مکمل طور پر حقیقت پسندانہ ہے، تو تین نقلیں ڈیڑھ ہزار کو ہینڈل کریں گی۔
بعض اوقات، یقیناً، آپ زیادہ سے زیادہ پوائنٹ ریڈنگ کے لیے ClickHouse کو ترتیب دے سکتے ہیں۔ اس کے لیے کیا ضرورت ہے؟ سب سے پہلے انڈیکس کی گرینولریٹی کو کم کرنا ہے۔ اس صورت میں، اسے ایک تک کم نہیں کیا جانا چاہئے، بلکہ اس بنیاد پر کہ انڈیکس میں اندراجات کی تعداد کئی ملین یا دسیوں ملین فی سرور ہوگی۔ اگر ٹیبل میں ایک سو ملین قطاریں ہیں، تو گرانولریٹی کو 64 پر سیٹ کیا جا سکتا ہے۔
آپ کمپریسڈ بلاک کا سائز کم کر سکتے ہیں۔ اس کے لیے سیٹنگز موجود ہیں۔ کم سے کم کمپریس بلاک سائز, زیادہ سے زیادہ کمپریس بلاک سائز. ان کو کم کیا جا سکتا ہے، ڈیٹا سے دوبارہ بھرا جا سکتا ہے، اور پھر ہدف بنائے گئے سوالات تیز تر ہوں گے۔ لیکن پھر بھی، کلک ہاؤس کلیدی قدر کا ڈیٹا بیس نہیں ہے۔ چھوٹی درخواستوں کی ایک بڑی تعداد ایک لوڈ اینٹی پیٹرن ہے۔
کریل شواکوف: اگر وہاں عام اکاؤنٹس ہوں تو میں مشورہ دوں گا۔ جب کلک ہاؤس کسی قسم کا کاؤنٹر اسٹور کرتا ہے تو یہ کافی معیاری صورتحال ہے۔ میرے پاس ایک صارف ہے، وہ فلاں فلاں ملک سے ہے، اور کسی تیسرے فیلڈ سے ہے، اور مجھے بتدریج کچھ بڑھانے کی ضرورت ہے۔ MySQL لیں، ایک منفرد کلید بنائیں - MySQL میں یہ ایک ڈپلیکیٹ کلید ہے، اور PostgreSQL میں یہ ایک تنازعہ ہے - اور ایک جمع کا نشان شامل کریں۔ یہ بہت بہتر کام کرے گا۔
جب آپ کے پاس زیادہ ڈیٹا نہیں ہوتا ہے، تو ClickHouse استعمال کرنے میں زیادہ فائدہ نہیں ہوتا۔ باقاعدہ ڈیٹا بیس موجود ہیں اور وہ یہ کام اچھی طرح کرتے ہیں۔
میں کلک ہاؤس میں کیا موافقت کر سکتا ہوں تاکہ زیادہ ڈیٹا کیش میں ہو؟
آئیے ایک صورت حال کا تصور کریں - سرورز کے پاس 256 GB RAM ہے، روزانہ کے معمول میں ClickHouse تقریباً 60-80 GB لیتا ہے، چوٹی پر - 130 تک۔ کس چیز کو فعال اور موافق بنایا جا سکتا ہے تاکہ زیادہ ڈیٹا کیش میں ہو اور اس کے مطابق، ڈسک پر کم دورے ہیں؟
عام طور پر، آپریٹنگ سسٹم کا صفحہ کیش اس کا اچھا کام کرتا ہے۔ اگر آپ صرف اوپر کو کھولتے ہیں تو وہاں کیشڈ یا مفت دیکھیں - یہ بھی بتاتا ہے کہ کتنا کیش ہے - پھر آپ دیکھ سکتے ہیں کہ تمام مفت میموری کیش کے لیے استعمال کی گئی ہے۔ اور اس ڈیٹا کو پڑھتے وقت اسے ڈسک سے نہیں بلکہ رام سے پڑھا جائے گا۔ ایک ہی وقت میں، میں کہہ سکتا ہوں کہ کیش کو مؤثر طریقے سے استعمال کیا جاتا ہے کیونکہ یہ کمپریسڈ ڈیٹا ہے جو کیش کیا جاتا ہے.
تاہم، اگر آپ کچھ آسان سوالات کو مزید تیز کرنا چاہتے ہیں، تو ClickHouse کے اندر ڈیکمپریسڈ ڈیٹا میں کیش کو فعال کرنا ممکن ہے۔ یہ کہا جاتا ہے غیر کمپریسڈ کیشے. config.xml کنفیگریشن فائل میں، غیر کمپریسڈ کیش سائز کو اپنی ضرورت کے مطابق سیٹ کریں - میں مفت RAM کے نصف سے زیادہ کی تجویز نہیں کرتا ہوں، کیونکہ باقی صفحہ کیشے کے نیچے چلے جائیں گے۔
اس کے علاوہ، درخواست کی سطح کی دو ترتیبات ہیں۔ پہلی ترتیب - غیر کمپریسڈ کیشے کا استعمال کریں۔ - اس کا استعمال بھی شامل ہے۔ اسے تمام درخواستوں کے لیے فعال کرنے کی سفارش کی جاتی ہے، سوائے بھاری درخواستوں کے، جو تمام ڈیٹا کو پڑھ سکتے ہیں اور کیشے کو فلش کر سکتے ہیں۔ اور دوسری ترتیب کچھ ایسی ہے جیسے کیشے کو استعمال کرنے کے لیے لائنوں کی زیادہ سے زیادہ تعداد۔ یہ خود بخود بڑے سوالات کو محدود کر دیتا ہے تاکہ وہ کیشے کو نظرانداز کر دیں۔
میں رام میں اسٹوریج کے لیے اسٹوریج_کنفیگریشن کو کیسے ترتیب دے سکتا ہوں؟
کلک ہاؤس کی نئی دستاویزات میں میں نے متعلقہ سیکشن پڑھا۔ . تفصیل تیز SSD کے ساتھ ایک مثال پر مشتمل ہے۔
مجھے حیرت ہے کہ حجم گرم میموری کے ساتھ ایک ہی چیز کو کس طرح ترتیب دیا جاسکتا ہے۔ اور ایک سوال۔ اس ڈیٹا آرگنائزیشن کے ساتھ سلیکٹ کیسے کام کرتا ہے، کیا یہ پورے سیٹ کو پڑھے گا یا صرف وہی جو ڈسک پر ہے، اور کیا یہ ڈیٹا میموری میں کمپریسڈ ہے؟ اور اس طرح کے ڈیٹا آرگنائزیشن کے ساتھ پری ویل سیکشن کیسے کام کرتا ہے؟
یہ ترتیب ڈیٹا کے ٹکڑوں کے ذخیرہ کو متاثر کرتی ہے، اور ان کا فارمیٹ کسی بھی طرح تبدیل نہیں ہوتا ہے۔
آئیے قریب سے دیکھیں۔
آپ ڈیٹا اسٹوریج کو رام میں کنفیگر کر سکتے ہیں۔ ڈسک کے لیے جو کچھ ترتیب دیا گیا ہے وہ اس کا راستہ ہے۔ آپ ایک tmpfs پارٹیشن بناتے ہیں جو فائل سسٹم میں کسی راستے پر نصب ہوتا ہے۔ آپ اس راستے کو گرم ترین پارٹیشن کے لیے ڈیٹا ذخیرہ کرنے کے راستے کے طور پر بتاتے ہیں، ڈیٹا کے ٹکڑے آنا شروع ہو جاتے ہیں اور وہاں لکھا جاتا ہے، سب کچھ ٹھیک ہے۔
لیکن میں کم وشوسنییتا کی وجہ سے ایسا کرنے کی سفارش نہیں کرتا ہوں، حالانکہ اگر آپ کے پاس مختلف ڈیٹا سینٹرز میں کم از کم تین نقلیں ہیں، تو یہ ممکن ہے۔ اگر کچھ ہوتا ہے تو، ڈیٹا بحال ہو جائے گا. آئیے تصور کریں کہ سرور اچانک بند ہو گیا اور واپس آن ہو گیا۔ تقسیم دوبارہ لگائی گئی، لیکن وہاں کچھ نہیں تھا۔ جب ClickHouse سرور شروع ہوتا ہے، تو یہ دیکھتا ہے کہ اس کے پاس یہ ٹکڑے نہیں ہیں، حالانکہ ZooKeeper میٹا ڈیٹا کے مطابق، وہ وہاں ہونے چاہئیں۔ وہ دیکھتا ہے کہ ان کے پاس کون سی نقلیں ہیں، ان کی درخواست کرتا ہے اور انہیں ڈاؤن لوڈ کرتا ہے۔ اس طرح ڈیٹا بحال ہو جائے گا۔
اس لحاظ سے، RAM میں ڈیٹا کو ذخیرہ کرنا بنیادی طور پر اسے ڈسک پر ذخیرہ کرنے سے مختلف نہیں ہے، کیونکہ جب ڈیٹا ڈسک پر لکھا جاتا ہے، تو یہ بھی پہلے صفحہ کیشے میں ختم ہوتا ہے اور بعد میں جسمانی طور پر لکھا جاتا ہے۔ یہ فائل سسٹم ماؤنٹنگ آپشن پر منحصر ہے۔ لیکن صرف اس صورت میں، میں کہوں گا کہ کلک ہاؤس داخل کرتے وقت fsync نہیں ہوتا ہے۔
اس صورت میں، RAM میں ڈیٹا بالکل اسی شکل میں محفوظ کیا جاتا ہے جیسا کہ ڈسک پر ہے۔ اسی طرح منتخب سوال ان ٹکڑوں کو منتخب کرتا ہے جن کو پڑھنے کی ضرورت ہے، ٹکڑوں میں ضروری ڈیٹا رینجز کو منتخب کرتی ہے، اور انہیں پڑھتی ہے۔ اور prewhere بالکل ویسا ہی کام کرتا ہے، قطع نظر اس کے کہ ڈیٹا RAM میں تھا یا ڈسک پر۔
انوکھی اقدار کی کتنی تعداد تک کم کارڈنالٹی موثر ہے؟
کم کارڈینیلیٹی کو چالاکی سے ڈیزائن کیا گیا ہے۔ یہ ڈیٹا لغات مرتب کرتا ہے، لیکن وہ مقامی ہیں۔ سب سے پہلے، ہر ٹکڑے کے لیے مختلف لغات ہیں، اور دوسری بات، یہاں تک کہ ایک ٹکڑے کے اندر بھی وہ ہر رینج کے لیے مختلف ہو سکتے ہیں۔ جب منفرد اقدار کی تعداد ایک حد تک پہنچ جاتی ہے — ایک ملین، میرے خیال میں — لغت کو صرف شیلف کر دیا جاتا ہے اور ایک نئی تخلیق کی جاتی ہے۔
جواب عام طور پر ہے: ہر مقامی رینج کے لیے - کہیں، ہر دن کے لیے - کہیں ایک ملین منفرد اقدار تک کم کارڈنالٹی موثر ہے۔ اس کے بعد صرف ایک فال بیک ہوگا، جس میں صرف ایک نہیں بلکہ بہت سی مختلف لغات استعمال ہوں گی۔ یہ تقریباً ایک باقاعدہ سٹرنگ کالم کی طرح کام کرے گا، شاید تھوڑا کم موثر، لیکن کارکردگی میں کوئی سنگین کمی نہیں ہوگی۔
پانچ بلین قطاروں والے ٹیبل کو مکمل متن تلاش کرنے کے بہترین طریقے کیا ہیں؟
مختلف جوابات ہیں۔ سب سے پہلے یہ کہنا ہے کہ کلک ہاؤس ایک مکمل ٹیکسٹ سرچ انجن نہیں ہے۔ اس کے لیے خاص نظام موجود ہیں، مثال کے طور پر، и . تاہم، میں لوگوں کو تیزی سے یہ کہتے ہوئے دیکھ رہا ہوں کہ وہ Elasticsearch سے ClickHouse میں تبدیل ہو رہے ہیں۔
ایسا کیوں ہوتا ہے؟ وہ اس کی وضاحت اس حقیقت سے کرتے ہیں کہ Elasticsearch کچھ جلدوں پر بوجھ کا مقابلہ کرنا چھوڑ دیتا ہے، انڈیکسز کی تعمیر سے شروع ہوتا ہے۔ اشاریہ جات بہت بوجھل ہو جاتے ہیں، اور اگر آپ ڈیٹا کو صرف ClickHouse میں منتقل کرتے ہیں، تو پتہ چلتا ہے کہ وہ حجم کے لحاظ سے کئی گنا زیادہ مؤثر طریقے سے محفوظ کیے جاتے ہیں۔ ایک ہی وقت میں، تلاش کے سوالات اکثر اس طرح کے نہیں ہوتے تھے کہ اعداد و شمار کے پورے حجم میں مورفولوجی کو مدنظر رکھتے ہوئے کچھ فقرے تلاش کرنا ضروری تھا، لیکن بالکل مختلف۔ مثال کے طور پر، پچھلے چند گھنٹوں کے دوران نوشتہ جات میں بائٹس کا کچھ نتیجہ تلاش کریں۔
اس صورت میں، آپ ClickHouse میں ایک انڈیکس بناتے ہیں، جس کا پہلا فیلڈ تاریخ اور وقت ہوگا۔ اور سب سے بڑا ڈیٹا کٹ آف تاریخ کی حد پر مبنی ہوگا۔ منتخب کردہ تاریخ کی حد کے اندر، ایک اصول کے طور پر، مکمل متن کی تلاش کرنا پہلے سے ہی ممکن ہے، یہاں تک کہ لائک کا استعمال کرتے ہوئے بروٹ فورس کا طریقہ بھی استعمال کیا جائے۔ ClickHouse میں لائک آپریٹر سب سے زیادہ موثر جیسا آپریٹر ہے جو آپ کو مل سکتا ہے۔ اگر آپ کو کچھ بہتر لگے تو مجھے بتائیں۔
لیکن پھر بھی، جیسا کہ ایک مکمل اسکین ہے۔ اور مکمل اسکین نہ صرف CPU پر بلکہ ڈسک پر بھی سست ہو سکتا ہے۔ اگر اچانک آپ کے پاس روزانہ ایک ٹیرا بائٹ ڈیٹا ہے، اور آپ دن میں کوئی لفظ تلاش کرتے ہیں، تو آپ کو ٹیرا بائٹ کو اسکین کرنا پڑے گا۔ اور یہ غالباً باقاعدہ ہارڈ ڈرائیوز پر ہے، اور آخر میں وہ اس طرح لوڈ کیے جائیں گے کہ آپ SSH کے ذریعے اس سرور تک رسائی حاصل نہیں کر پائیں گے۔
اس صورت میں، میں ایک اور چھوٹی چال پیش کرنے کے لیے تیار ہوں۔ یہ تجرباتی ہے - یہ کام کر سکتا ہے، یہ نہیں ہو سکتا۔ کلک ہاؤس میں ٹریگرام بلوم فلٹرز کی شکل میں مکمل متن کے اشاریہ جات ہیں۔ Arenadata میں ہمارے ساتھیوں نے پہلے ہی ان اشاریہ جات کو آزمایا ہے، اور وہ اکثر بالکل ٹھیک کام کرتے ہیں۔
ان کو صحیح طریقے سے استعمال کرنے کے لیے، آپ کو یہ اچھی طرح سمجھنا چاہیے کہ وہ کس طرح کام کرتے ہیں: ٹریگرام بلوم فلٹر کیا ہے اور اس کا سائز کیسے منتخب کیا جائے۔ میں کہہ سکتا ہوں کہ وہ کچھ نایاب فقروں، ذیلی اسٹرنگز پر سوالات کے لیے مدد کریں گے جو ڈیٹا میں شاذ و نادر ہی پائے جاتے ہیں۔ اس صورت میں، ذیلی رینجز کو اشاریہ جات کے ذریعے منتخب کیا جائے گا اور کم ڈیٹا پڑھا جائے گا۔
حال ہی میں، کلک ہاؤس نے مکمل متن کی تلاش کے لیے مزید جدید فنکشنز کا اضافہ کیا ہے۔ یہ، سب سے پہلے، ایک ہی پاس میں ایک ساتھ سب اسٹرنگز کے ایک گروپ کی تلاش ہے، بشمول وہ اختیارات جو کیس-حساس، کیس-غیر حساس، UTF-8 یا صرف ASCII کے لیے سپورٹ کے ساتھ۔ آپ کی ضرورت سب سے مؤثر ایک کا انتخاب کریں.
ایک پاس میں متعدد ریگولر ایکسپریشنز کی تلاش بھی ظاہر ہوئی ہے۔ آپ کو ایک سبسٹرنگ کی طرح X یا دوسرے سبسٹرنگ کی طرح X لکھنے کی ضرورت نہیں ہے۔ آپ فوراً لکھتے ہیں، اور ہر چیز ہر ممکن حد تک مؤثر طریقے سے کی جاتی ہے۔
تیسرا، اب regexps کے لیے ایک تخمینی تلاش اور ذیلی اسٹرنگ کے لیے ایک تخمینی تلاش ہے۔ اگر کسی نے کوئی لفظ غلط لکھا ہے تو اسے زیادہ سے زیادہ مماثلت کے لیے تلاش کیا جائے گا۔
صارفین کی ایک بڑی تعداد کے لیے ClickHouse تک رسائی کو منظم کرنے کا بہترین طریقہ کیا ہے؟
ہمیں بتائیں کہ صارفین اور تجزیہ کاروں کی ایک بڑی تعداد کے لیے رسائی کو کس طرح منظم کیا جائے۔ ایک قطار کیسے بنائیں، زیادہ سے زیادہ ہم آہنگی کے سوالات کو ترجیح دیں، اور کن ٹولز کے ساتھ؟
اگر کلسٹر کافی بڑا ہے، تو ایک اچھا حل یہ ہوگا کہ دو اور سرورز کو بڑھایا جائے، جو تجزیہ کاروں کے لیے انٹری پوائنٹ بن جائے گا۔ یعنی، تجزیہ کاروں کو کلسٹر میں مخصوص شارڈز تک رسائی کی اجازت نہ دیں، بلکہ بغیر ڈیٹا کے دو خالی سرورز بنائیں، اور ان پر رسائی کے حقوق کو ترتیب دیں۔ اس صورت میں، تقسیم شدہ درخواستوں کے لیے صارف کی ترتیبات ریموٹ سرورز پر منتقل ہو جاتی ہیں۔ یعنی، آپ ان دو سرورز پر ہر چیز کو ترتیب دیتے ہیں، اور سیٹنگز کا اثر پورے کلسٹر پر ہوتا ہے۔
اصولی طور پر، ان سرورز کے پاس کوئی ڈیٹا نہیں ہے، لیکن درخواستوں پر عمل درآمد کے لیے ان پر ریم کی مقدار بہت اہم ہے۔ ڈسک کو عارضی ڈیٹا کے لیے بھی استعمال کیا جا سکتا ہے اگر بیرونی جمع یا بیرونی چھانٹنا فعال ہو۔
ان ترتیبات کو دیکھنا ضروری ہے جو تمام ممکنہ حدود سے وابستہ ہیں۔ اگر میں اب ایک تجزیہ کار کے طور پر Yandex.Metrica کلسٹر پر جاؤں اور ایک درخواست پوچھوں ہٹ سے گنتی منتخب کریں۔، پھر مجھے فوری طور پر ایک استثناء دیا جائے گا کہ میں درخواست پر عمل نہیں کر سکتا۔ قطاروں کی زیادہ سے زیادہ تعداد جو مجھے اسکین کرنے کی اجازت ہے ایک سو بلین ہے، اور کلسٹر پر ایک ٹیبل میں ان میں سے پچاس ٹریلین ہیں۔ یہ پہلی حد ہے۔
ہم کہتے ہیں کہ میں قطار کی حد کو ہٹاتا ہوں اور استفسار کو دوبارہ چلاتا ہوں۔ پھر میں مندرجہ ذیل استثناء دیکھوں گا - ترتیب فعال ہے۔ تاریخ کے لحاظ سے قوت انڈیکس. اگر میں نے تاریخ کی حد متعین نہیں کی ہے تو میں استفسار مکمل نہیں کر سکتا۔ آپ کو اسے دستی طور پر بتانے کے لیے تجزیہ کاروں پر انحصار کرنے کی ضرورت نہیں ہے۔ ایک عام صورت وہ ہوتی ہے جب تاریخ کی حد لکھی جاتی ہے جہاں واقعہ کی تاریخ ہفتے کے درمیان ہوتی ہے۔ اور پھر انہوں نے غلط جگہ پر صرف ایک بریکٹ کی وضاحت کی، اور اس کے بجائے اور یہ یا - یا URL میچ نکلا۔ اگر کوئی حد نہیں ہے تو، یہ URL کالم کو کرال کرے گا اور صرف ایک ٹن وسائل ضائع کرے گا۔
اس کے علاوہ، ClickHouse کی دو ترجیحی ترتیبات ہیں۔ بدقسمتی سے، وہ بہت قدیم ہیں. ایک کو صرف کہا جاتا ہے۔ ترجیح. اگر ترجیح ≠ 0، اور کچھ ترجیح کے ساتھ درخواستوں پر عمل درآمد کیا جا رہا ہے، لیکن اس سے کم کی ترجیحی قدر والی درخواست پر عمل کیا جا رہا ہے، جس کا مطلب ہے اعلی ترجیح، تو ایک درخواست جس کی ترجیحی قدر زیادہ ہے، جس کا مطلب ہے کم ترجیح ، صرف معطل ہے اور اس وقت کے دوران بالکل کام نہیں کرے گا۔
یہ ایک بہت ہی خام ترتیب ہے اور ان صورتوں کے لیے موزوں نہیں ہے جہاں کلسٹر پر مسلسل بوجھ ہو۔ لیکن اگر آپ کے پاس مختصر، پھٹی ہوئی درخواستیں ہیں جو اہم ہیں، اور کلسٹر زیادہ تر بیکار ہے، تو یہ سیٹ اپ موزوں ہے۔
اگلی ترجیحی ترتیب کو کہا جاتا ہے۔ OS تھریڈ کی ترجیح. یہ آسانی سے لینکس شیڈیولر کے لئے تمام درخواستوں پر عمل درآمد کے دھاگوں کے لئے اچھی قیمت کا تعین کرتا ہے۔ یہ ایسا کام کرتا ہے، لیکن یہ اب بھی کام کرتا ہے۔ اگر آپ کم از کم اچھی قدر مقرر کرتے ہیں - یہ قدر میں سب سے بڑی ہے، اور اس لیے سب سے کم ترجیح - اور اعلی ترجیح والی درخواستوں کے لیے -19 سیٹ کریں، تو CPU کم ترجیحی درخواستوں کو اعلی ترجیح والی درخواستوں سے تقریباً چار گنا کم استعمال کرے گا۔
آپ کو درخواست پر عمل درآمد کے زیادہ سے زیادہ وقت کو بھی ترتیب دینے کی ضرورت ہے - کہیے، پانچ منٹ۔ استفسار پر عمل درآمد کی کم از کم رفتار بہترین چیز ہے۔ یہ ترتیب ایک طویل عرصے سے چلی آ رہی ہے، اور یہ نہ صرف یہ کہنے کے لیے کہ ClickHouse کی رفتار کم نہیں ہوتی، بلکہ اسے زبردستی کرنے کی ضرورت ہے۔
تصور کریں، آپ نے ترتیب دیا: اگر کچھ استفسار فی سیکنڈ XNUMX لاکھ قطاروں سے کم پر عمل کرتا ہے، تو آپ ایسا نہیں کر سکتے۔ یہ ہمارے اچھے نام، ہمارے اچھے ڈیٹا بیس کو بدنام کرتا ہے۔ آئیے صرف اس پر پابندی لگا دیں۔ اصل میں دو سیٹنگز ہیں۔ ایک کہا جاتا ہے۔ کم از کم عملدرآمد کی رفتار - فی سیکنڈ لائنوں میں، اور سیکنڈ کو ٹائم آؤٹ کہا جاتا ہے اس سے پہلے کہ کم از کم عمل درآمد کی رفتار کی جانچ پڑتال کریں - ڈیفالٹ کے لحاظ سے پندرہ سیکنڈ۔ یعنی، پندرہ سیکنڈ ممکن ہے، اور پھر، اگر یہ سست ہے، تو صرف ایک استثناء پھینک دیں اور درخواست کو روک دیں۔
آپ کو کوٹہ بھی ترتیب دینے کی ضرورت ہے۔ ClickHouse میں بلٹ ان کوٹہ کی خصوصیت ہے جو وسائل کی کھپت کو شمار کرتی ہے۔ لیکن، بدقسمتی سے، ہارڈ ویئر کے وسائل نہیں جیسے کہ CPU، ڈسکیں، بلکہ منطقی ہیں - پروسیس شدہ درخواستوں، لائنوں اور بائٹس کی تعداد۔ اور آپ ترتیب دے سکتے ہیں، مثال کے طور پر، پانچ منٹ کے اندر زیادہ سے زیادہ ایک سو درخواستیں اور فی گھنٹہ ایک ہزار درخواستیں۔
یہ کیوں ضروری ہے؟ کیونکہ کچھ تجزیاتی سوالات دستی طور پر براہ راست ClickHouse کلائنٹ سے کیے جائیں گے۔ اور سب ٹھیک ہو جائے گا۔ لیکن اگر آپ کی کمپنی میں جدید تجزیہ کار ہیں، تو وہ اسکرپٹ لکھیں گے، اور اسکرپٹ میں غلطی ہوسکتی ہے۔ اور یہ ایرر درخواست کو ایک لامحدود لوپ میں انجام دینے کا سبب بنے گی۔ اس سے ہمیں اپنے آپ کو بچانے کی ضرورت ہے۔
کیا دس کلائنٹس کو ایک سوال کے نتائج دینا ممکن ہے؟
ہمارے پاس بہت سے صارفین ہیں جو ایک ہی وقت میں بہت بڑی درخواستوں کے ساتھ آنا پسند کرتے ہیں۔ درخواست بڑی ہوتی ہے اور اصولی طور پر اس پر جلد عمل درآمد ہوتا ہے، لیکن اس حقیقت کی وجہ سے کہ ایک ہی وقت میں ایسی بہت سی درخواستیں ہوتی ہیں، یہ بہت تکلیف دہ ہو جاتی ہے۔ کیا ایک ہی درخواست پر عمل کرنا ممکن ہے، جو لگاتار دس بار، ایک بار پہنچی، اور نتیجہ دس کلائنٹس کو دے؟
مسئلہ یہ ہے کہ ہمارے پاس انٹرمیڈیٹ ڈیٹا کی کیش یا کیش کے نتائج نہیں ہیں۔ آپریٹنگ سسٹم کا ایک صفحہ کیش ہے، جو آپ کو ڈسک سے ڈیٹا کو دوبارہ پڑھنے سے روک دے گا، لیکن بدقسمتی سے، ڈیٹا کو اب بھی ڈی کمپریسڈ، ڈی سیریلائزڈ اور ری پروسیس کیا جائے گا۔
میں کسی نہ کسی طرح اس سے بچنا چاہوں گا، یا تو انٹرمیڈیٹ ڈیٹا کو کیش کرکے، یا اسی طرح کے سوالات کو کسی قسم کی قطار میں کھڑا کرکے اور نتائج کا کیش شامل کرکے۔ ہمارے پاس فی الحال ترقی میں ایک پل کی درخواست ہے جو ایک درخواست کیشے کو جوڑتی ہے، لیکن صرف ان اور جوائن سیکشنز میں ذیلی سوالات کے لیے - یعنی حل نامکمل ہے۔
تاہم ہمیں بھی ایسی صورتحال کا سامنا ہے۔ ایک خاص طور پر کینونیکل مثال صفحہ بندی کے سوالات ہیں۔ ایک رپورٹ ہے، اس کے کئی صفحات ہیں، اور حد 10 کی درخواست ہے۔ پھر وہی بات، لیکن حد 10,10۔ پھر اگلا صفحہ۔ اور سوال یہ ہے کہ ہم ہر بار یہ سب کیوں گنتے ہیں؟ لیکن اب اس کا کوئی حل نہیں ہے، اور اس سے بچنے کا کوئی طریقہ نہیں ہے۔
ایک متبادل حل ہے جسے کلک ہاؤس کے آگے سائڈ کار کے طور پر رکھا گیا ہے۔ .
کریل شواکوف: کلک ہاؤس پراکسی میں بلٹ ان ریٹ محدود کرنے والا اور بلٹ ان رزلٹ کیش ہے۔ وہاں بہت سی سیٹنگز بنائی گئی تھیں کیونکہ اسی طرح کا مسئلہ حل ہو رہا تھا۔ پراکسی آپ کو قطار میں لگا کر درخواستوں کو محدود کرنے اور یہ ترتیب دینے کی اجازت دیتا ہے کہ درخواست کیشے کتنی دیر تک زندہ رہتی ہے۔ اگر درخواستیں واقعی ایک جیسی تھیں تو پراکسی انہیں کئی بار بھیجے گا، لیکن کلک ہاؤس کو صرف ایک بار جائے گا۔
Nginx کے مفت ورژن میں کیش بھی ہے، اور یہ بھی کام کرے گا۔ Nginx میں یہاں تک کہ ترتیبات ہیں کہ اگر درخواستیں ایک ہی وقت میں پہنچ جاتی ہیں، تو یہ دوسروں کو اس وقت تک سست کر دے گی جب تک کہ ایک مکمل نہ ہو جائے۔ لیکن یہ کلک ہاؤس پراکسی میں ہے کہ سیٹ اپ بہت بہتر ہے۔ یہ خاص طور پر ClickHouse کے لیے بنایا گیا تھا، خاص طور پر ان درخواستوں کے لیے، اس لیے یہ زیادہ موزوں ہے۔ ٹھیک ہے، انسٹال کرنا آسان ہے۔
غیر مطابقت پذیر کارروائیوں اور مادی نظریات کے بارے میں کیا خیال ہے؟
ایک مسئلہ ہے کہ ری پلے انجن کے ساتھ آپریشنز غیر مطابقت پذیر ہیں - پہلے ڈیٹا لکھا جاتا ہے، پھر وہ گر جاتا ہے۔ اگر کچھ مجموعوں کے ساتھ ایک مادی گولی نشان کے نیچے رہتی ہے، تو اس پر نقلیں لکھی جائیں گی۔ اور اگر کوئی پیچیدہ منطق نہیں ہے، تو ڈیٹا ڈپلیکیٹ کیا جائے گا. آپ اس کے بارے میں کیا کر سکتے ہیں؟
ایک واضح حل ہے - ایک غیر مطابقت پذیر خاتمے کے آپریشن کے دوران میٹ ویوز کی ایک مخصوص کلاس پر ٹرگر کو نافذ کرنا۔ کیا چاندی کی گولیاں ہیں یا اسی طرح کی فعالیت کو نافذ کرنے کے منصوبے ہیں؟
یہ سمجھنے کے قابل ہے کہ ڈپلیکیشن کیسے کام کرتی ہے۔ اب میں آپ کو جو بتاؤں گا وہ سوال سے متعلق نہیں ہے، لیکن صرف اس صورت میں کہ یہ یاد رکھنے کے قابل ہو۔
نقل شدہ ٹیبل میں داخل کرتے وقت، پورے داخل کردہ بلاکس کی نقل تیار کی جاتی ہے۔ اگر آپ ایک ہی ترتیب میں ایک ہی قطار کی ایک ہی تعداد پر مشتمل ایک ہی بلاک کو دوبارہ داخل کرتے ہیں، تو ڈیٹا ڈپلیکیٹ ہوجاتا ہے۔ داخل کرنے کے جواب میں آپ کو "ٹھیک ہے" موصول ہوگا، لیکن درحقیقت ڈیٹا کا ایک پیکٹ لکھا جائے گا، اور اسے نقل نہیں کیا جائے گا۔
یقین کے لیے یہ ضروری ہے۔ اگر آپ کو اندراج کے دوران "Ok" موصول ہوتا ہے، تو آپ کا ڈیٹا داخل کر دیا گیا ہے۔ اگر آپ کو ClickHouse سے کوئی غلطی موصول ہوتی ہے، تو اس کا مطلب ہے کہ وہ داخل نہیں کیے گئے تھے اور آپ کو دوبارہ داخل کرنے کی ضرورت ہے۔ لیکن اگر اندراج کے دوران کنکشن ٹوٹ جاتا ہے، تو آپ نہیں جانتے کہ ڈیٹا داخل کیا گیا تھا یا نہیں۔ واحد آپشن یہ ہے کہ اندراج کو دوبارہ دہرایا جائے۔ اگر ڈیٹا واقعی داخل کیا گیا تھا اور آپ نے اسے دوبارہ داخل کیا تو، بلاک ڈپلیکیشن ہے۔ نقل سے بچنے کے لیے یہ ضروری ہے۔
اور یہ بھی اہم ہے کہ یہ مادی نظریات کے لیے کیسے کام کرتا ہے۔ اگر مرکزی جدول میں داخل کرتے وقت ڈیٹا کو ڈپلیکیٹ کیا گیا تھا، تو یہ مادی منظر میں بھی نہیں جائے گا۔
اب سوال کے بارے میں۔ آپ کی صورتحال زیادہ پیچیدہ ہے کیونکہ آپ انفرادی لائنوں کے ڈپلیکیٹ ریکارڈ کر رہے ہیں۔ یعنی، یہ پورا پیک نہیں ہے جو ڈپلیکیٹ ہے، بلکہ مخصوص لائنیں، اور وہ پس منظر میں گر جاتی ہیں۔ درحقیقت، ڈیٹا مین ٹیبل میں سمٹ جائے گا، لیکن غیر منقطع ڈیٹا مادّی شدہ منظر پر جائے گا، اور انضمام کے دوران مادّی شدہ نظاروں کے ساتھ کچھ نہیں ہوگا۔ کیونکہ ایک مادی نظریہ داخل کرنے کے محرک سے زیادہ کچھ نہیں ہے۔ دیگر کارروائیوں کے دوران، اس سے کوئی اضافی چیز نہیں ہوتی ہے۔
اور میں تمہیں یہاں خوش نہیں کر سکتا۔ آپ کو صرف اس کیس کے لیے ایک مخصوص حل تلاش کرنے کی ضرورت ہے۔ مثال کے طور پر، کیا اسے ایک مادّہ نظر میں دوبارہ چلانا ممکن ہے، اور ڈپلیکیشن کا طریقہ اسی طرح کام کر سکتا ہے۔ لیکن بدقسمتی سے، ہمیشہ نہیں. اگر یہ جمع ہے تو یہ کام نہیں کرے گا۔
کریل شواکوف: ہمارے پاس بیساکھی کی تعمیر بھی پہلے دن تھی۔ ایک مسئلہ تھا کہ اشتہاری نقوش ہیں، اور کچھ ڈیٹا ہے جسے ہم حقیقی وقت میں دکھا سکتے ہیں - یہ صرف نقوش ہیں۔ وہ شاذ و نادر ہی ڈپلیکیٹ ہوتے ہیں، لیکن اگر ایسا ہوتا ہے، تو ہم بعد میں بہرحال انہیں منہدم کر دیں گے۔ اور ایسی چیزیں تھیں جو ڈپلیکیٹ نہیں ہوسکتی تھیں - کلکس اور یہ پوری کہانی۔ لیکن میں بھی انہیں تقریباً فوراً دکھانا چاہتا تھا۔
مادی نظریات کیسے بنائے گئے؟ ایسے خیالات تھے جہاں اسے براہ راست لکھا گیا تھا - اسے خام ڈیٹا پر لکھا گیا تھا، اور آراء پر لکھا گیا تھا۔ وہاں، کسی وقت ڈیٹا بہت درست نہیں ہوتا، اسے ڈپلیکیٹ کیا جاتا ہے، وغیرہ۔ اور جدول کا ایک دوسرا حصہ ہے، جہاں وہ بالکل ایک جیسے نظر آتے ہیں جیسے کہ مادّی نظر آتے ہیں، یعنی وہ ساخت میں بالکل ایک جیسے ہیں۔ تھوڑی دیر میں ہم ڈیٹا کو دوبارہ گنتے ہیں، ڈپلیکیٹ کے بغیر ڈیٹا کو گنتے ہیں، ان ٹیبلز پر لکھتے ہیں۔
ہم API کے ذریعے گئے - یہ دستی طور پر ClickHouse میں کام نہیں کرے گا۔ اور API نظر آتا ہے: جب میرے پاس ٹیبل میں آخری اضافے کی تاریخ ہوتی ہے، جہاں اس بات کی ضمانت دی جاتی ہے کہ درست ڈیٹا کا پہلے ہی حساب لگایا جا چکا ہے، اور یہ ایک ٹیبل اور دوسرے ٹیبل سے درخواست کرتا ہے۔ ایک سے درخواست ایک خاص وقت تک کا انتخاب کرتی ہے، اور دوسرے سے اسے وہ ملتا ہے جو ابھی تک شمار نہیں کیا گیا ہے۔ اور یہ کام کرتا ہے، لیکن اکیلے کلک ہاؤس کے ذریعے نہیں۔
اگر آپ کے پاس کسی قسم کا API ہے - تجزیہ کاروں کے لیے، صارفین کے لیے - تو اصولی طور پر، یہ ایک آپشن ہے۔ آپ ہمیشہ گنتے رہتے ہیں، ہمیشہ گنتے رہتے ہیں۔ یہ دن میں ایک بار یا کسی اور وقت کیا جا سکتا ہے۔ آپ اپنے لیے ایک ایسی حد کا انتخاب کرتے ہیں جس کی آپ کو ضرورت نہیں ہے اور نہ ہی اہم ہے۔
کلک ہاؤس میں بہت سارے لاگ ہیں۔ میں سرور کے ساتھ ہونے والی ہر چیز کو ایک نظر میں کیسے دیکھ سکتا ہوں؟
ClickHouse میں مختلف لاگز کی ایک بہت بڑی تعداد ہے، اور یہ تعداد بڑھ رہی ہے۔ نئے ورژن میں، ان میں سے کچھ پہلے سے طے شدہ طور پر بھی فعال ہوتے ہیں؛ پرانے ورژن میں اپ ڈیٹ کرتے وقت ان کا فعال ہونا ضروری ہے۔ تاہم، ان میں سے زیادہ سے زیادہ ہیں. بالآخر، میں یہ دیکھنا چاہوں گا کہ میرے سرور کے ساتھ اب کیا ہو رہا ہے، شاید کسی قسم کے سمری ڈیش بورڈ پر۔
کیا آپ کی کلک ہاؤس ٹیم میں، یا آپ کے دوستوں کی ٹیموں میں، جو ریڈی میڈ ڈیش بورڈز کی کچھ فعالیت کو سپورٹ کرتے ہیں جو ان لاگز کو بطور ریڈی میڈ پروڈکٹ ظاہر کریں گے؟ بالآخر، کلک ہاؤس میں لاگز کو دیکھنا بہت اچھا ہے۔ لیکن یہ بہت اچھا ہو گا اگر اسے پہلے سے ڈیش بورڈ کی شکل میں تیار کر لیا جائے۔ میں اس سے ایک کک نکالوں گا۔
ڈیش بورڈز ہیں، حالانکہ وہ معیاری نہیں ہیں۔ ہماری کمپنی میں، تقریباً 60 ٹیمیں ClickHouse استعمال کرتی ہیں، اور سب سے عجیب بات یہ ہے کہ ان میں سے بہت سے ڈیش بورڈز ہیں جو انہوں نے اپنے لیے بنائے ہیں، اور کچھ مختلف۔ کچھ ٹیمیں داخلی Yandex.Cloud انسٹالیشن کا استعمال کرتی ہیں۔ کچھ ریڈی میڈ رپورٹس ہیں، حالانکہ تمام ضروری نہیں ہیں۔ دوسروں کے اپنے ہیں۔
میٹریکا کے میرے ساتھیوں کا گرافانا میں اپنا ڈیش بورڈ ہے، اور میرے پاس ان کے کلسٹر کے لیے اپنا ڈیش بورڈ ہے۔ میں سیرف کیشے کے لیے کیشے ہٹ جیسی چیزوں کو دیکھ رہا ہوں۔ اور اس سے بھی زیادہ مشکل یہ ہے کہ ہم مختلف ٹولز استعمال کرتے ہیں۔ میں نے اپنا ڈیش بورڈ Graphite-web نامی ایک بہت پرانے ٹول کا استعمال کرتے ہوئے بنایا۔ وہ بالکل بدصورت ہے۔ اور میں اب بھی اسے اسی طرح استعمال کرتا ہوں، حالانکہ گرافانا شاید زیادہ آسان اور خوبصورت ہوگا۔
ڈیش بورڈز میں بنیادی چیز ایک ہی ہے۔ یہ کلسٹر کے لیے سسٹم میٹرکس ہیں: CPU، میموری، ڈسک، نیٹ ورک۔ دیگر - بیک وقت درخواستوں کی تعداد، بیک وقت انضمام کی تعداد، فی سیکنڈ درخواستوں کی تعداد، MergeTree ٹیبل پارٹیشنز کے لیے زیادہ سے زیادہ تعداد، نقل کی وقفہ، نقل کی قطار کا سائز، فی سیکنڈ داخل کی گئی قطاروں کی تعداد، فی سیکنڈ داخل کردہ بلاکس کی تعداد۔ یہ وہ سب کچھ ہے جو نوشتہ جات سے نہیں بلکہ میٹرکس سے حاصل ہوتا ہے۔
ولادیمیر کولوبایف: الیکسی، میں اسے تھوڑا درست کرنا چاہوں گا۔ گرافانا ہے۔ گرافانا کے پاس ایک ڈیٹا سورس ہے، جو کہ کلک ہاؤس ہے۔ یعنی میں Grafana سے براہ راست ClickHouse پر درخواستیں کر سکتا ہوں۔ کلک ہاؤس میں لاگز کے ساتھ ایک میز ہے، یہ سب کے لیے یکساں ہے۔ نتیجے کے طور پر، میں گرافانا میں اس لاگ ٹیبل تک رسائی حاصل کرنا چاہتا ہوں اور وہ درخواستیں دیکھنا چاہتا ہوں جو میرا سرور کرتا ہے۔ اس طرح کا ڈیش بورڈ ہونا بہت اچھا ہوگا۔
میں نے خود اسے بائیک کیا۔ لیکن میرا ایک سوال ہے - اگر یہ سب معیاری ہے، اور Grafana کو ہر کوئی استعمال کرتا ہے، تو Yandex کے پاس ایسا آفیشل ڈیش بورڈ کیوں نہیں ہے؟
کریل شواکوف: درحقیقت، ڈیٹا سورس جو ClickHouse پر جاتا ہے اب Altinity کو سپورٹ کرتا ہے۔ اور میں صرف ایک ویکٹر دینا چاہتا ہوں کہ کہاں کھودنا ہے اور کس کو دھکیلنا ہے۔ آپ ان سے پوچھ سکتے ہیں، کیونکہ Yandex اب بھی ClickHouse بناتا ہے، نہ کہ اس کے ارد گرد کی کہانی۔ Altinity فی الحال ClickHouse کو فروغ دینے والی اہم کمپنی ہے۔ وہ اسے نہیں چھوڑیں گے بلکہ اس کی حمایت کریں گے۔ کیونکہ، اصولی طور پر، Grafana ویب سائٹ پر ڈیش بورڈ اپ لوڈ کرنے کے لیے، آپ کو صرف اسے رجسٹر کرکے اپ لوڈ کرنے کی ضرورت ہے - کوئی خاص مسئلہ نہیں ہے۔
الیکسی میلووڈوف: گزشتہ ایک سال کے دوران، ClickHouse نے کئی سوالات کی پروفائلنگ کی صلاحیتوں کو شامل کیا ہے۔ وسائل کے استعمال پر ہر درخواست کے لیے میٹرکس ہیں۔ اور ابھی حال ہی میں، ہم نے ایک نچلے درجے کے استفسار کا پروفائلر شامل کیا ہے تاکہ یہ دیکھا جا سکے کہ ایک سوال ہر ملی سیکنڈ میں کہاں خرچ کر رہا ہے۔ لیکن اس فعالیت کو استعمال کرنے کے لیے، مجھے کنسول کلائنٹ کو کھول کر ایک درخواست ٹائپ کرنی ہوگی، جسے میں ہمیشہ بھول جاتا ہوں۔ میں نے اسے کہیں محفوظ کیا اور بھولتا رہا کہ بالکل کہاں۔
کاش کوئی ایسا ٹول ہوتا جس نے ابھی کہا ہو، یہ ہیں آپ کے بھاری سوالات، استفسار کی کلاس کے لحاظ سے گروپ کیے گئے ہیں۔ میں نے ایک پر دبایا، اور وہ مجھے بتائیں گے کہ اسی لیے یہ بھاری ہے۔ اب ایسا کوئی حل نہیں ہے۔ اور یہ واقعی بہت عجیب بات ہے کہ جب لوگ مجھ سے پوچھتے ہیں: "مجھے بتائیں، کیا گرافانا کے لیے کوئی تیار شدہ ڈیش بورڈ موجود ہیں؟"، میں کہتا ہوں: "Grafana ویب سائٹ پر جائیں، وہاں ایک "Dashboards" کمیونٹی ہے، اور وہاں ایک ڈیش بورڈ موجود ہے۔ Dimka سے، Kostyan سے ایک ڈیش بورڈ ہے۔ میں نہیں جانتا کہ یہ کیا ہے، میں نے اسے خود استعمال نہیں کیا ہے۔"
انضمام کو کیسے متاثر کیا جائے تاکہ سرور OOM میں کریش نہ ہو؟
میرے پاس ایک ٹیبل ہے، ٹیبل میں صرف ایک پارٹیشن ہے، وہ ReplaceingMergeTree ہے۔ میں چار سال سے اس میں ڈیٹا لکھ رہا ہوں۔ مجھے اس میں ردوبدل کرنے اور کچھ ڈیٹا کو حذف کرنے کی ضرورت تھی۔
میں نے یہ کیا، اور اس درخواست کی پروسیسنگ کے دوران، کلسٹر میں موجود تمام سرورز پر موجود تمام میموری ختم ہوگئی، اور کلسٹر کے تمام سرورز OOM میں چلے گئے۔ پھر وہ سب ایک ساتھ اٹھے، اسی آپریشن، اس ڈیٹا بلاک کو ملانا شروع کیا، اور دوبارہ OOM میں گر گئے۔ پھر وہ دوبارہ اٹھے اور پھر گر پڑے۔ اور یہ معاملہ رکا نہیں۔
پھر پتہ چلا کہ یہ دراصل ایک بگ تھا جسے لڑکوں نے ٹھیک کر دیا تھا۔ یہ بہت اچھا ہے، آپ کا بہت بہت شکریہ۔ لیکن ایک باقی رہ گیا۔ اور اب، جب میں ٹیبل میں کسی قسم کا انضمام کرنے کے بارے میں سوچتا ہوں، تو میرے پاس ایک سوال ہے - میں ان انضمام کو کسی طرح متاثر کیوں نہیں کر سکتا؟ مثال کے طور پر، انہیں مطلوبہ RAM کی مقدار، یا اصولی طور پر، اس مخصوص ٹیبل پر کارروائی کرنے والی رقم سے محدود کریں۔
میرے پاس "میٹرکس" نامی ایک ٹیبل ہے، براہ کرم میرے لیے دو تھریڈز میں اس پر کارروائی کریں۔ متوازی طور پر دس یا پانچ انضمام بنانے کی ضرورت نہیں ہے، اسے دو میں کریں. مجھے لگتا ہے کہ میرے پاس دو کے لئے کافی میموری ہے، لیکن یہ دس پر کارروائی کرنے کے لئے کافی نہیں ہوسکتا ہے۔ خوف کیوں رہتا ہے؟ کیونکہ ٹیبل بڑھ رہا ہے، اور کسی دن مجھے ایک ایسی صورتحال کا سامنا کرنا پڑے گا جو اصولی طور پر اب کسی بگ کی وجہ سے نہیں ہے، بلکہ اس لیے کہ ڈیٹا اتنی بڑی مقدار میں بدل جائے گا کہ میرے پاس اتنی میموری نہیں ہوگی سرور اور پھر ضم ہونے پر سرور OOM میں کریش ہو جائے گا۔ مزید یہ کہ میں میوٹیشن کو منسوخ کر سکتا ہوں، لیکن مرجی اب وہاں نہیں ہے۔
آپ جانتے ہیں، ضم ہونے پر، سرور OOM میں نہیں آئے گا، کیونکہ انضمام کے وقت، RAM کی مقدار صرف ڈیٹا کی ایک چھوٹی رینج کے لیے استعمال ہوتی ہے۔ لہذا ڈیٹا کی مقدار سے قطع نظر سب کچھ ٹھیک ہو جائے گا۔
ولادیمیر کولوبایف: ٹھیک. یہاں وہ لمحہ ایسا ہے کہ بگ ٹھیک ہونے کے بعد، میں نے اپنے لیے ایک نیا ورژن ڈاؤن لوڈ کیا، اور ایک اور میز پر، ایک چھوٹا، جہاں بہت سے پارٹیشنز ہیں، میں نے اسی طرح کا آپریشن کیا۔ اور انضمام کے دوران، سرور پر تقریباً 100 جی بی ریم جل گئی تھی۔ میرے پاس 150 قبضے میں تھے، 100 کھا گئے تھے، اور 50 GB ونڈو باقی تھی، اس لیے میں OOM میں نہیں آیا۔
اگر یہ حقیقت میں 100 GB RAM استعمال کرتا ہے تو فی الحال مجھے OOM میں گرنے سے کیا بچاتا ہے؟ اگر اچانک انضمام پر RAM ختم ہو جائے تو کیا کریں؟
الیکسی میلووڈوف: ایک ایسا مسئلہ ہے کہ خاص طور پر انضمام کے لیے RAM کا استعمال محدود نہیں ہے۔ اور دوسرا مسئلہ یہ ہے کہ اگر کسی قسم کا انضمام تفویض کیا گیا ہے، تو اسے عمل میں لانا ضروری ہے کیونکہ یہ نقل کے لاگ میں درج ہے۔ نقل لاگ وہ اعمال ہیں جن کی نقل کو مستقل حالت میں لانے کے لیے درکار ہے۔ اگر آپ دستی ہیرا پھیری نہیں کرتے ہیں جو اس نقل کے لاگ کو واپس لے جائیں گے، تو انضمام کو کسی نہ کسی طریقے سے انجام دینا پڑے گا۔
بلاشبہ، RAM کی حد رکھنا ضرورت سے زیادہ نہیں ہوگا جو "صرف اس صورت میں" OOM کے خلاف حفاظت کرتا ہے۔ یہ انضمام کو مکمل کرنے میں مدد نہیں کرے گا، یہ دوبارہ شروع ہو جائے گا، کسی حد تک پہنچ جائے گا، ایک استثناء پھینک دیں، اور پھر دوبارہ شروع کریں - اس سے کچھ اچھا نہیں ہوگا۔ لیکن اصولی طور پر اس پابندی کو متعارف کرانا مفید ہوگا۔
کلک ہاؤس کے لیے گولانگ ڈرائیور کیسے تیار کیا جائے گا؟
گولانگ ڈرائیور، جسے کرل شواکوف نے لکھا تھا، اب سرکاری طور پر کلک ہاؤس ٹیم کی حمایت حاصل ہے۔ وہ وہ اب بڑا اور حقیقی ہے۔
ایک چھوٹا سا نوٹ۔ لامحدود ترتیب کی عام شکلوں کا ایک حیرت انگیز اور محبوب ذخیرہ ہے - یہ ورٹیکا ہے۔ ان کے پاس اپنا آفیشل ازگر ڈرائیور بھی ہے، جسے ورٹیکا ڈویلپرز کی حمایت حاصل ہے۔ اور کئی بار ایسا ہوا کہ سٹوریج کے ورژن اور ڈرائیور کے ورژن کافی ڈرامائی انداز میں مختلف ہو گئے، اور ڈرائیور نے کسی وقت کام کرنا چھوڑ دیا۔ اور دوسرا نکتہ۔ مجھے لگتا ہے کہ اس آفیشل ڈرائیور کے لیے سپورٹ "نپل" سسٹم کے ذریعے کی جاتی ہے - آپ انہیں ایک مسئلہ لکھتے ہیں، اور یہ ہمیشہ کے لیے لٹک جاتا ہے۔
میرے دو سوال ہیں۔ اب Kirill کا Golang ڈرائیور Golang سے ClickHouse کے ساتھ بات چیت کرنے کا تقریباً طے شدہ طریقہ ہے۔ جب تک کہ کوئی اب بھی HTTP انٹرفیس کے ذریعے بات چیت نہیں کرتا ہے کیونکہ وہ اسے اس طرح پسند کرتا ہے۔ اس ڈرائیور کی ترقی کیسے آگے بڑھے گی؟ کیا اسے ذخیرہ میں ہی کسی توڑ پھوڑ کے ساتھ ہم آہنگ کیا جائے گا؟ اور کسی مسئلے پر غور کرنے کا طریقہ کار کیا ہے؟
کریل شواکوف: پہلا یہ ہے کہ کس طرح ہر چیز کو بیوروکریٹ طریقے سے منظم کیا جاتا ہے۔ اس نکتے پر بات نہیں کی گئی، اس لیے میرے پاس جواب دینے کے لیے کچھ نہیں ہے۔
اس مسئلے کے بارے میں سوال کا جواب دینے کے لیے، ہمیں ڈرائیور کی تھوڑی سی تاریخ درکار ہے۔ میں نے ایک ایسی کمپنی میں کام کیا جس کے پاس بہت زیادہ ڈیٹا تھا۔ یہ ایک ایڈورٹائزنگ اسپنر تھا جس میں بہت سارے ایونٹس تھے جنہیں کہیں اسٹور کرنے کی ضرورت تھی۔ اور کسی وقت کلک ہاؤس نمودار ہوا۔ ہم نے اسے ڈیٹا سے بھر دیا، اور پہلے تو سب کچھ ٹھیک تھا، لیکن پھر کلک ہاؤس کریش ہوگیا۔ اس وقت ہم نے فیصلہ کیا کہ ہمیں اس کی ضرورت نہیں ہے۔
ایک سال بعد، ہم کلک ہاؤس کو استعمال کرنے کے خیال پر واپس آئے، اور ہمیں کسی طرح وہاں ڈیٹا لکھنے کی ضرورت تھی۔ تعارفی پیغام یہ تھا: ہارڈ ویئر بہت کمزور ہے، وسائل کم ہیں۔ لیکن ہم نے ہمیشہ اس طرح کام کیا ہے، اور اس لیے ہم نے مقامی پروٹوکول کی طرف دیکھا۔
چونکہ ہم گو میں کام کر رہے تھے، یہ واضح تھا کہ ہمیں گو ڈرائیور کی ضرورت ہے۔ میں نے اسے تقریباً پورا وقت کیا - یہ میرا کام کا کام تھا۔ ہم اسے ایک خاص مقام پر لے آئے، اور اصولی طور پر کسی نے یہ گمان نہیں کیا کہ ہمارے علاوہ کوئی اسے استعمال کرے گا۔ پھر CloudFlare بالکل اسی مسئلے کے ساتھ آیا، اور کچھ عرصے تک ہم نے ان کے ساتھ بہت آسانی سے کام کیا، کیونکہ ان کے پاس وہی کام تھے۔ مزید یہ کہ، ہم نے یہ کام خود ClickHouse اور ڈرائیور دونوں میں کیا۔
کسی وقت، میں نے اسے کرنا چھوڑ دیا، کیونکہ کلک ہاؤس اور کام کے لحاظ سے میری سرگرمی تھوڑی بدل گئی۔ اس لیے مسائل بند نہیں ہوتے۔ وقتاً فوقتاً، جن لوگوں کو خود کسی چیز کی ضرورت ہوتی ہے وہ ذخیرہ کرنے کا عہد کرتے ہیں۔ پھر میں پل کی درخواست کو دیکھتا ہوں اور بعض اوقات میں خود بھی کچھ ترمیم کرتا ہوں، لیکن ایسا شاذ و نادر ہی ہوتا ہے۔
میں ڈرائیور کے پاس واپس جانا چاہتا ہوں۔ کئی سال پہلے، جب یہ ساری چیز شروع ہوئی، کلک ہاؤس بھی مختلف اور مختلف صلاحیتوں کے ساتھ تھا۔ اب ہمیں یہ سمجھ آ گئی ہے کہ ڈرائیور کو دوبارہ کیسے بنایا جائے تاکہ یہ اچھی طرح کام کرے۔ اگر ایسا ہوتا ہے، تو جمع شدہ بیساکھیوں کی وجہ سے ورژن 2 کسی بھی صورت میں مطابقت نہیں رکھتا۔
مجھے نہیں معلوم کہ اس معاملے کو کیسے منظم کیا جائے۔ میرے پاس خود زیادہ وقت نہیں ہے۔ اگر کچھ لوگ ڈرائیور کو ختم کر دیتے ہیں، تو میں ان کی مدد کر سکتا ہوں اور انہیں بتا سکتا ہوں کہ کیا کرنا ہے۔ لیکن منصوبے کی ترقی میں Yandex کی فعال شرکت پر ابھی تک بات نہیں کی گئی۔
الیکسی میلووڈوف: درحقیقت ان ڈرائیوروں کے بارے میں ابھی تک کوئی بیوروکریسی نہیں ہے۔ صرف یہ ہے کہ وہ ایک سرکاری تنظیم میں جمع کرائے جاتے ہیں، یعنی اس ڈرائیور کو Go کے لیے آفیشل ڈیفالٹ حل کے طور پر تسلیم کیا جاتا ہے۔ کچھ اور ڈرائیور بھی ہیں لیکن وہ الگ سے آتے ہیں۔
ہمارے پاس ان ڈرائیوروں کے لیے کوئی اندرونی ترقی نہیں ہے۔ سوال یہ ہے کہ کیا ہم اس مخصوص ڈرائیور کے لیے نہیں بلکہ تمام کمیونٹی ڈرائیوروں کی ترقی کے لیے انفرادی شخص کو ملازمت پر رکھ سکتے ہیں یا ہم باہر سے کسی کو تلاش کر سکتے ہیں۔
لازی_لوڈ سیٹنگ فعال ہونے کے ساتھ ریبوٹ کے بعد بیرونی لغت لوڈ نہیں ہوتی ہے۔ کیا کرنا ہے؟
ہمارے پاس lazy_load کی ترتیب فعال ہے، اور سرور کے دوبارہ شروع ہونے کے بعد، لغت خود لوڈ نہیں ہوتی ہے۔ صارف کے اس لغت تک رسائی کے بعد ہی اسے اٹھایا جاتا ہے۔ اور پہلی بار جب میں اس تک رسائی حاصل کرتا ہوں، تو یہ ایک غلطی دیتا ہے۔ کیا ClickHouse کا استعمال کرتے ہوئے لغات کو خود بخود لوڈ کرنا ممکن ہے، یا کیا آپ کو ہمیشہ ان کی تیاری کو خود کنٹرول کرنے کی ضرورت ہے تاکہ صارفین کو غلطیاں موصول نہ ہوں؟
شاید ہمارے پاس کلک ہاؤس کا پرانا ورژن ہے، اس لیے لغت خود بخود لوڈ نہیں ہوئی۔ کیا ایسا ہو سکتا ہے؟
سب سے پہلے، ایک استفسار کا استعمال کرتے ہوئے لغات کو زبردستی لوڈ کیا جا سکتا ہے۔ نظام دوبارہ لوڈ لغات. دوم، غلطی کے حوالے سے - اگر لغت پہلے سے لوڈ ہے، تو سوالات لوڈ کیے گئے ڈیٹا کی بنیاد پر کام کریں گے۔ اگر لغت ابھی تک لوڈ نہیں ہوئی ہے، تو اسے درخواست کے دوران براہ راست لوڈ کیا جائے گا۔
یہ بھاری لغات کے لیے زیادہ آسان نہیں ہے۔ مثال کے طور پر، آپ کو MySQL سے دس لاکھ قطاریں کھینچنے کی ضرورت ہے۔ کوئی ایک سادہ انتخاب کرتا ہے، لیکن یہ انتخاب اسی ملین قطاروں کا انتظار کرے گا۔ یہاں دو حل ہیں۔ سب سے پہلے سست_لوڈ کو بند کرنا ہے۔ دوسری بات یہ کہ جب سرور اوپر ہو تو اس پر بوجھ ڈالنے سے پہلے کر لیں۔ نظام کو دوبارہ لوڈ کرنے کی لغت یا صرف ایک استفسار کریں جس میں لغت استعمال ہو۔ پھر لغت لوڈ ہو جائے گی۔ آپ کو lazy_load سیٹنگ کو فعال کرنے کے ساتھ لغات کی دستیابی کو کنٹرول کرنے کی ضرورت ہے، کیونکہ ClickHouse انہیں خود بخود لوڈ نہیں کرتا ہے۔
آخری سوال کا جواب یہ ہے کہ یا تو ورژن پرانا ہے یا اسے ڈیبگ کرنے کی ضرورت ہے۔
اس حقیقت کا کیا کیا جائے کہ سسٹم ری لوڈ ڈکشنریز بہت سی لغتوں میں سے کسی کو لوڈ نہیں کرتی ہیں اگر ان میں سے کم از کم ایک غلطی کے ساتھ کریش ہو جائے؟
سسٹم کو دوبارہ لوڈ کرنے کی لغات کے بارے میں ایک اور سوال ہے۔ ہمارے پاس دو لغات ہیں - ایک لوڈ نہیں ہے، دوسری لوڈ ہے. اس صورت میں، سسٹم ری لوڈ ڈکشنریز کوئی لغت لوڈ نہیں کرتی ہے، اور آپ کو سسٹم ری لوڈ ڈکشنری کا استعمال کرتے ہوئے اس کے نام سے ایک مخصوص کو پوائنٹ بہ پوائنٹ لوڈ کرنا ہوگا۔ کیا اس کا تعلق ClickHouse ورژن سے بھی ہے؟
میں آپ کو خوش کرنا چاہتا ہوں. یہ رویہ بدل رہا تھا۔ اس کا مطلب ہے کہ اگر آپ کلک ہاؤس کو اپ ڈیٹ کرتے ہیں تو یہ بھی بدل جائے گا۔ اگر آپ اپنے موجودہ رویے سے خوش نہیں ہیں۔ نظام دوبارہ لوڈ لغات، اپ ڈیٹ کریں، اور آئیے امید کرتے ہیں کہ یہ بہتر کے لیے بدل جاتا ہے۔
کیا ClickHouse کی تشکیل میں تفصیلات کو ترتیب دینے کا کوئی طریقہ ہے، لیکن غلطیوں کی صورت میں انہیں ظاہر نہ کریں؟
اگلا سوال لغت سے متعلق غلطیوں کا ہے، یعنی تفصیلات۔ ہم نے لغت کے لیے ClickHouse config میں کنکشن کی تفصیلات بتا دی ہیں، اور اگر کوئی غلطی ہو تو ہمیں جواب میں یہ تفصیلات اور پاس ورڈ موصول ہو جاتا ہے۔
ہم نے ODBC ڈرائیور کی ترتیب میں تفصیلات شامل کرکے اس غلطی کو حل کیا۔ کیا ClickHouse کی تشکیل میں تفصیلات کو ترتیب دینے کا کوئی طریقہ ہے، لیکن غلطیوں کی صورت میں یہ تفصیلات نہ دکھائیں؟
یہاں اصل حل یہ ہے کہ ان اسناد کو odbc.ini میں بیان کیا جائے، اور خود ClickHouse میں صرف ODBC ڈیٹا ماخذ کا نام بتائیں۔ یہ دوسرے لغت کے ذرائع کے لیے نہیں ہو گا - نہ ہی MySQL والی لغت کے لیے، اور نہ ہی دوسروں کے لیے، جب آپ کو غلطی کا پیغام موصول ہوتا ہے تو آپ کو پاس ورڈ نہیں دیکھنا چاہیے۔ ODBC کے لیے، میں بھی دیکھوں گا - اگر یہ موجود ہے، تو آپ کو اسے ہٹانے کی ضرورت ہے۔
بونس: اجتماعات سے زوم کے لیے پس منظر
تصویر پر کلک کرنے سے، سب سے زیادہ مستقل قارئین کے لیے اجتماعات کے بونس پس منظر کھل جائیں گے۔ ہم Avito ٹیکنالوجی کے ماسکوٹس کے ساتھ مل کر آگ بجھاتے ہیں، ہم سسٹم ایڈمنسٹریٹر کے کمرے یا پرانے اسکول کے کمپیوٹر کلب کے ساتھیوں کے ساتھ بات چیت کرتے ہیں، اور ہم گرافٹی کے پس منظر میں پل کے نیچے روزانہ میٹنگ کرتے ہیں۔
ماخذ: www.habr.com