مندرجہ ذیل ڈیٹا بیس میں Yandex کی شراکت کا جائزہ لیا جائے گا۔
- کلک ہاؤس
- وڈسی
- وقت میں ایک نقطہ پر بحالی (WAL-G)
- پوسٹگری ایس کیو ایل (بشمول لاگ ایرز، ایمچیک، ہیپ چیک)
- گرین پلم
ویڈیو:
ہیلو دنیا! میرا نام اینڈری بوروڈن ہے۔ اور میں Yandex.Cloud پر جو کچھ کرتا ہوں وہ Yandex.Cloud اور Yandex.Cloud کلائنٹس کے مفاد میں کھلا رشتہ دار ڈیٹا بیس تیار کرنا ہے۔
اس گفتگو میں، ہم ان چیلنجوں کے بارے میں بات کریں گے جن کا سامنا اوپن ڈیٹا بیس کو پیمانے پر کرنا ہے۔ یہ کیوں ضروری ہے؟ کیونکہ چھوٹے چھوٹے مسائل جو مچھروں کی طرح پھر ہاتھی بن جاتے ہیں۔ جب آپ کے پاس بہت سے کلسٹر ہوتے ہیں تو وہ بڑے ہو جاتے ہیں۔
لیکن یہ بنیادی چیز نہیں ہے۔ ناقابل یقین چیزیں ہوتی ہیں۔ وہ چیزیں جو ایک ملین میں سے ایک کیس میں ہوتی ہیں۔ اور بادل کے ماحول میں، آپ کو اس کے لیے تیار رہنا ہوگا، کیونکہ جب کوئی چیز پیمانے پر موجود ہوتی ہے تو ناقابل یقین چیزیں بہت زیادہ ممکن ہوجاتی ہیں۔
لیکن! اوپن ڈیٹا بیس کا کیا فائدہ ہے؟ حقیقت یہ ہے کہ آپ کے پاس کسی بھی مسئلے سے نمٹنے کا ایک نظریاتی موقع ہے۔ آپ کے پاس سورس کوڈ ہے، آپ کو پروگرامنگ کا علم ہے۔ ہم اسے یکجا کرتے ہیں اور یہ کام کرتا ہے۔
اوپن سورس سافٹ ویئر پر کام کرنے میں کیا طریقے ہیں؟
- سب سے سیدھا طریقہ سافٹ ویئر استعمال کرنا ہے۔ اگر آپ پروٹوکول استعمال کرتے ہیں، اگر آپ معیارات استعمال کرتے ہیں، اگر آپ فارمیٹس استعمال کرتے ہیں، اگر آپ اوپن سورس سافٹ ویئر میں سوالات لکھتے ہیں، تو آپ پہلے ہی اس کی حمایت کرتے ہیں۔
- آپ اس کے ماحولیاتی نظام کو بڑا بنا رہے ہیں۔ آپ بگ کی جلد پتہ لگانے کے امکانات کو بڑھا دیتے ہیں۔ آپ اس نظام کی وشوسنییتا کو بڑھاتے ہیں۔ آپ مارکیٹ میں ڈویلپرز کی دستیابی میں اضافہ کرتے ہیں۔ آپ اس سافٹ ویئر کو بہتر بنائیں۔ اگر آپ نے ابھی اسٹائل حاصل کیا اور وہاں کسی چیز کے ساتھ ٹنکر کیا تو آپ پہلے سے ہی ایک شراکت دار ہیں۔
- ایک اور قابل فہم طریقہ اوپن سورس سافٹ ویئر کو سپانسر کرنا ہے۔ مثال کے طور پر، معروف گوگل سمر آف کوڈ پروگرام، جب گوگل پوری دنیا کے طلباء کی ایک بڑی تعداد کو قابل فہم رقم ادا کرتا ہے تاکہ وہ کھلے سافٹ ویئر پروجیکٹس تیار کریں جو لائسنسنگ کی مخصوص ضروریات کو پورا کرتے ہیں۔
- یہ ایک بہت ہی دلچسپ نقطہ نظر ہے کیونکہ یہ سافٹ ویئر کو کمیونٹی سے توجہ ہٹائے بغیر تیار ہونے کی اجازت دیتا ہے۔ گوگل، ایک ٹیکنالوجی دیو کے طور پر، یہ نہیں کہتا کہ ہم یہ فیچر چاہتے ہیں، ہم اس مسئلے کو ٹھیک کرنا چاہتے ہیں اور ہمیں وہاں کھودنے کی ضرورت ہے۔ گوگل کا کہنا ہے: "آپ جو کرتے ہیں وہ کریں۔ جس طرح آپ کام کر رہے ہیں اسی طرح کام کرتے رہیں اور سب کچھ ٹھیک ہو جائے گا۔
- اوپن سورس میں حصہ لینے کا اگلا طریقہ شرکت ہے۔ جب آپ کو اوپن سورس سافٹ ویئر میں کوئی مسئلہ ہوتا ہے اور وہاں ڈویلپرز ہوتے ہیں تو آپ کے ڈویلپرز مسائل کو حل کرنا شروع کر دیتے ہیں۔ وہ آپ کے بنیادی ڈھانچے کو زیادہ موثر، آپ کے پروگراموں کو تیز تر اور زیادہ قابل اعتماد بنانا شروع کر دیتے ہیں۔
اوپن سورس سافٹ ویئر کے میدان میں سب سے مشہور Yandex منصوبوں میں سے ایک ClickHouse ہے۔ یہ ایک ڈیٹا بیس ہے جو Yandex.Metrica کو درپیش چیلنجوں کے جواب کے طور پر پیدا ہوا تھا۔
اور ایک ڈیٹا بیس کے طور پر، اسے ایک ماحولیاتی نظام بنانے اور اسے دوسرے ڈویلپرز (نہ صرف Yandex کے اندر) کے ساتھ مل کر تیار کرنے کے لیے اوپن سورس میں بنایا گیا تھا۔ اور اب یہ ایک بڑا منصوبہ ہے جس میں بہت سی مختلف کمپنیاں شامل ہیں۔
Yandex.Cloud میں، ہم نے Yandex آبجیکٹ اسٹوریج کے اوپر، یعنی کلاؤڈ اسٹوریج کے اوپر ClickHouse بنایا ہے۔
بادل میں یہ کیوں ضروری ہے؟ کیونکہ کوئی بھی ڈیٹا بیس اس مثلث میں، اس اہرام میں، میموری کی اقسام کے اس درجہ بندی میں کام کرتا ہے۔ آپ کے پاس تیز لیکن چھوٹے رجسٹر اور سستے بڑے لیکن سست SSDs، ہارڈ ڈرائیوز اور کچھ دیگر بلاک ڈیوائسز ہیں۔ اور اگر آپ پرامڈ کے اوپری حصے میں موثر ہیں، تو آپ کے پاس ایک تیز ڈیٹا بیس ہے۔ اگر آپ اس اہرام کے نچلے حصے میں موثر ہیں، تو آپ کے پاس ایک چھوٹا ڈیٹا بیس ہے۔ اور اس سلسلے میں، نیچے سے ایک اور تہہ شامل کرنا ڈیٹا بیس کی اسکیل ایبلٹی بڑھانے کے لیے ایک منطقی طریقہ ہے۔
یہ کیسے ہو سکتا تھا؟ یہ اس رپورٹ میں ایک اہم نکتہ ہے۔
- ہم ایم ڈی ایس پر کلک ہاؤس لاگو کرسکتے ہیں۔ MDS ایک اندرونی Yandex کلاؤڈ اسٹوریج انٹرفیس ہے۔ یہ عام S3 پروٹوکول سے زیادہ پیچیدہ ہے، لیکن یہ بلاک ڈیوائس کے لیے زیادہ موزوں ہے۔ ڈیٹا ریکارڈ کرنے کے لیے یہ بہتر ہے۔ اس کے لیے مزید پروگرامنگ کی ضرورت ہے۔ پروگرامرز پروگرام کریں گے، یہ اور بھی اچھا ہے، یہ دلچسپ ہے۔
- S3 ایک زیادہ عام طریقہ ہے جو کچھ خاص قسم کے کام کے بوجھ سے کم موافقت کی قیمت پر انٹرفیس کو آسان بناتا ہے۔
قدرتی طور پر، پورے ClickHouse ایکو سسٹم کو فعالیت فراہم کرنے اور Yandex.Cloud کے اندر مطلوبہ کام کرنے کے خواہشمند، ہم نے اس بات کو یقینی بنانے کا فیصلہ کیا کہ کلک ہاؤس کی پوری کمیونٹی اس سے مستفید ہو۔ ہم نے کلک ہاؤس کو S3 پر لاگو کیا، MDS پر کلک ہاؤس نہیں۔ اور یہ بہت کام ہے۔
حوالہ جات:
"فائل سسٹم تجریدی پرت"
"AWS SDK S3 انضمام"
"S3 کے لیے IDisk انٹرفیس کا بنیادی نفاذ"
"IDisk انٹرفیس کے ساتھ لاگ اسٹوریج انجنوں کا انضمام"
"S3 اور SeekableReadBuffer کے لیے لاگ انجن سپورٹ"
"اسٹوریج اسٹرائپ لاگ S3 سپورٹ"
"S3 کے لیے سٹوریج MergeTree ابتدائی سپورٹ"
"S3 کے لیے MergeTree کی مکمل حمایت"
"S3 پر ReplicatedMergeTree کی حمایت کریں"
"ایس 3 اسٹوریج کے لیے پہلے سے طے شدہ اسناد اور کسٹم ہیڈر شامل کریں"
"متحرک پراکسی ترتیب کے ساتھ S3"
"پراکسی حل کرنے والے کے ساتھ S3"
کلک ہاؤس میں ورچوئل فائل سسٹم کو نافذ کرنے کے لیے یہ پل ریکوئسٹ لسٹ ہے۔ یہ پل کی درخواستوں کی ایک بڑی تعداد ہے۔
حوالہ جات:
"DiskS3 ہارڈ لنکس کا بہترین نفاذ"
"S3 HTTP کلائنٹ - میموری میں رسپانس اسٹریم کو کاپی کرنے سے گریز کریں"
"S3 HTTP میں پوری رسپانس اسٹریم کو میموری میں کاپی کرنے سے گریز کریں۔
کلائنٹ"
"S3 ڈسک کے لیے کیش مارک اور انڈیکس فائلوں کی اہلیت"
"پرزوں کو DiskLocal سے DiskS3 میں متوازی طور پر منتقل کریں"
لیکن کام وہیں ختم نہیں ہوا۔ فیچر بننے کے بعد، اس فعالیت کو بہتر بنانے کے لیے کچھ اور کام کی ضرورت تھی۔
حوالہ جات:
"SelectedRows اور SelectedBytes ایونٹس شامل کریں"
"S3 درخواست سے system.events میں پروفائلنگ ایونٹس شامل کریں"
"QueryTimeMicroseconds، SelectQueryTimeMicroseconds اور InsertQueryTimeMicroseconds شامل کریں"
اور پھر اسے قابل تشخیص بنانا، نگرانی قائم کرنا اور اسے قابل انتظام بنانا ضروری تھا۔
اور یہ سب کچھ اس لیے کیا گیا تاکہ پوری کمیونٹی، پورے کلک ہاؤس ماحولیاتی نظام کو اس کام کا نتیجہ ملے۔
آئیے ٹرانزیکشنل ڈیٹا بیس کی طرف چلتے ہیں، OLTP ڈیٹا بیس کی طرف، جو ذاتی طور پر میرے زیادہ قریب ہیں۔
یہ اوپن سورس DBMS ڈویلپمنٹ ڈویژن ہے۔ یہ لوگ ٹرانزیکشنل اوپن ڈیٹا بیس کو بہتر بنانے کے لیے اسٹریٹ میجک کر رہے ہیں۔
پروجیکٹوں میں سے ایک، جس کی مثال استعمال کرتے ہوئے ہم بات کر سکتے ہیں کہ ہم کیسے اور کیا کرتے ہیں، پوسٹگریس میں کنکشن پولر ہے۔
پوسٹگریس ایک پروسیس ڈیٹا بیس ہے۔ اس کا مطلب یہ ہے کہ ڈیٹا بیس میں ممکنہ حد تک کم نیٹ ورک کنکشن ہونے چاہئیں جو لین دین کو سنبھالتے ہیں۔
دوسری طرف، بادل کے ماحول میں، ایک عام صورت حال اس وقت ہوتی ہے جب ایک ہی وقت میں ایک کلسٹر میں ایک ہزار کنکشن آتے ہیں۔ اور کنکشن پولر کا کام ایک ہزار کنکشنز کو سرور کنکشن کی ایک چھوٹی تعداد میں پیک کرنا ہے۔
ہم کہہ سکتے ہیں کہ کنکشن پولر ٹیلی فون آپریٹر ہے جو بائٹس کو دوبارہ ترتیب دیتا ہے تاکہ وہ ڈیٹا بیس تک مؤثر طریقے سے پہنچ سکیں۔
بدقسمتی سے، کنکشن پولر کے لیے کوئی اچھا روسی لفظ نہیں ہے۔ کبھی کبھی اسے ملٹی پلیکسر کنکشن کہا جاتا ہے۔ اگر آپ جانتے ہیں کہ کنکشن پولر کو کیا کہتے ہیں، تو مجھے ضرور بتائیں، مجھے درست روسی تکنیکی زبان بولنے میں بہت خوشی ہوگی۔
ہم نے کنکشن پولرز کی چھان بین کی جو منظم پوسٹگریس کلسٹر کے لیے موزوں تھے۔ اور PgBouncer ہمارے لیے بہترین انتخاب تھا۔ لیکن ہمیں PgBouncer کے ساتھ کئی مسائل کا سامنا کرنا پڑا۔ کئی سال پہلے، Volodya Borodin نے رپورٹس دی تھیں کہ ہم PgBouncer استعمال کرتے ہیں، ہمیں ہر چیز پسند ہے، لیکن اس میں باریکیاں ہیں، اس پر کام کرنے کے لیے کچھ ہے۔
اور ہم نے کام کیا۔ ہم نے ان مسائل کو حل کیا جن کا ہمیں سامنا ہوا، ہم نے باؤنسر کو پیچ کیا، اور پل کی درخواستوں کو اوپر کی طرف بڑھانے کی کوشش کی۔ لیکن بنیادی سنگل تھریڈنگ کے ساتھ کام کرنا مشکل تھا۔
ہمیں پیچ والے باؤنسرز سے جھرنوں کو جمع کرنا تھا۔ جب ہمارے پاس بہت سے سنگل تھریڈڈ باؤنسر ہوتے ہیں، تو اوپر کی پرت کے کنکشن باؤنسرز کی اندرونی تہہ میں منتقل ہو جاتے ہیں۔ یہ ایک ناقص انتظام شدہ نظام ہے جسے آگے پیچھے بنانا اور پیمانہ کرنا مشکل ہے۔
ہم اس نتیجے پر پہنچے کہ ہم نے اپنا کنکشن پولر بنایا، جسے اوڈیسی کہتے ہیں۔ ہم نے اسے شروع سے لکھا ہے۔
2019 میں، PgCon کانفرنس میں، میں نے یہ پولر ڈویلپر کمیونٹی کو پیش کیا۔ اب ہمارے پاس GitHub پر 2 سے کم ستارے ہیں، یعنی پروجیکٹ زندہ ہے، پروجیکٹ مقبول ہے۔
اور اگر آپ Yandex.Cloud میں Postgres کلسٹر بناتے ہیں، تو یہ بلٹ ان Odyssey کے ساتھ ایک کلسٹر ہوگا، جو کلسٹر کو آگے یا پیچھے اسکیل کرتے وقت دوبارہ ترتیب دیا جاتا ہے۔
ہم نے اس منصوبے سے کیا سیکھا؟ مسابقتی پروجیکٹ کا آغاز ہمیشہ ایک جارحانہ قدم ہوتا ہے، یہ ایک انتہائی اقدام ہوتا ہے جب ہم کہتے ہیں کہ ایسے مسائل ہیں جو کافی تیزی سے حل نہیں ہورہے ہیں، وقت کے وقفوں میں حل نہیں کیے جارہے ہیں جو ہمارے مطابق ہوں گے۔ لیکن یہ ایک موثر اقدام ہے۔
PgBouncer تیزی سے تیار ہونے لگا۔
اور اب دوسرے منصوبے سامنے آئے ہیں۔ مثال کے طور پر، pgagroal، جسے Red Hat ڈویلپرز نے تیار کیا ہے۔ وہ اسی طرح کے اہداف کا تعاقب کرتے ہیں اور اسی طرح کے خیالات کو لاگو کرتے ہیں، لیکن یقیناً، ان کی اپنی خصوصیات کے ساتھ، جو pgagroal ڈویلپرز کے قریب ہیں۔
پوسٹگریس کمیونٹی کے ساتھ کام کرنے کا ایک اور معاملہ وقت پر بحال ہو رہا ہے۔ یہ ناکامی کے بعد ریکوری ہے، یہ بیک اپ سے ریکوری ہے۔
بہت سے بیک اپ ہیں اور وہ سب مختلف ہیں۔ تقریباً ہر پوسٹگریس فروش کا اپنا بیک اپ حل ہوتا ہے۔
اگر آپ تمام بیک اپ سسٹم لیں، ایک فیچر میٹرکس بنائیں اور مذاق میں اس میٹرکس میں ڈیٹرمیننٹ کا حساب لگائیں تو یہ صفر ہوگا۔ اس کا کیا مطلب ہے؟ کیا ہوگا اگر آپ ایک مخصوص بیک اپ فائل لیتے ہیں، تو اسے باقی تمام فائلوں سے جمع نہیں کیا جاسکتا۔ یہ اپنے نفاذ میں منفرد ہے، یہ اپنے مقصد میں منفرد ہے، یہ ان خیالات میں منفرد ہے جو اس میں سمائے ہوئے ہیں۔ اور وہ سب مخصوص ہیں۔
جب ہم اس مسئلے پر کام کر رہے تھے، CitusData نے WAL-G پروجیکٹ شروع کیا۔ یہ ایک بیک اپ سسٹم ہے جو بادل کے ماحول پر نظر رکھ کر بنایا گیا تھا۔ اب CitusData پہلے سے ہی Microsoft کا حصہ ہے۔ اور اس وقت، ہمیں واقعی وہ آئیڈیاز پسند آئے جو WAL-G کی ابتدائی ریلیز میں بیان کیے گئے تھے۔ اور ہم نے اس پروجیکٹ میں اپنا حصہ ڈالنا شروع کیا۔
اب اس پروجیکٹ میں بہت سے درجنوں ڈویلپرز ہیں، لیکن WAL-G میں سب سے اوپر 10 تعاون کرنے والوں میں 6 Yandexoids شامل ہیں۔ ہم وہاں اپنے بہت سے خیالات لائے۔ اور بلاشبہ، ہم نے خود ان کو لاگو کیا، خود ان کا تجربہ کیا، انہیں خود پیداوار میں شامل کیا، ہم انہیں خود استعمال کرتے ہیں، بڑی WAL-G کمیونٹی کے ساتھ بات چیت کرتے ہوئے، ہم خود ہی اندازہ لگاتے ہیں کہ آگے کہاں جانا ہے۔
اور ہمارے نقطہ نظر سے، اب یہ بیک اپ سسٹم، بشمول ہماری کوششوں کو مدنظر رکھتے ہوئے، بادل کے ماحول کے لیے بہترین بن گیا ہے۔ یہ کلاؤڈ میں پوسٹگریس کا بیک اپ لینے کی بہترین قیمت ہے۔
اس کا کیا مطلب ہے؟ ہم ایک کافی بڑے آئیڈیا کو فروغ دے رہے تھے: بیک اپ محفوظ ہونا چاہیے، چلانے کے لیے سستا ہونا چاہیے اور جتنی جلدی ممکن ہو بحال ہونا چاہیے۔
اسے چلانے کے لیے سستا کیوں ہونا چاہیے؟ جب کچھ بھی نہیں ٹوٹا ہے، تو آپ کو یہ نہیں معلوم ہونا چاہیے کہ آپ کے پاس بیک اپ ہیں۔ سب کچھ ٹھیک کام کرتا ہے، آپ جتنا ممکن ہو سکے کم سے کم CPU ضائع کرتے ہیں، آپ اپنے ڈسک کے وسائل کا زیادہ سے زیادہ استعمال کرتے ہیں، اور آپ نیٹ ورک کو زیادہ سے زیادہ بائٹس بھیجتے ہیں تاکہ آپ کی قیمتی خدمات کے پے لوڈ میں مداخلت نہ ہو۔
اور جب سب کچھ ٹوٹ جاتا ہے، مثال کے طور پر، ایڈمن نے ڈیٹا چھوڑ دیا، کچھ غلط ہو گیا، اور آپ کو فوری طور پر ماضی میں واپس جانے کی ضرورت ہے، آپ تمام رقم کے ساتھ ٹھیک ہو جائیں گے، کیونکہ آپ چاہتے ہیں کہ آپ کا ڈیٹا جلد اور برقرار رہے۔
اور ہم نے اس سادہ خیال کو فروغ دیا۔ اور، یہ ہمیں لگتا ہے، ہم نے اسے نافذ کرنے میں کامیاب کیا.
لیکن یہ سب کچھ نہیں ہے۔ ہم ایک اور چھوٹی چیز چاہتے تھے۔ ہم بہت سے مختلف ڈیٹا بیس چاہتے تھے۔ ہمارے تمام کلائنٹ پوسٹگریس استعمال نہیں کرتے ہیں۔ کچھ لوگ MySQL، MongoDB استعمال کرتے ہیں۔ کمیونٹی میں، دوسرے ڈویلپرز نے FoundationDB کو سپورٹ کیا ہے۔ اور یہ فہرست مسلسل پھیل رہی ہے۔
کمیونٹی کو ڈیٹا بیس کے کلاؤڈ میں منظم ماحول میں چلائے جانے کا خیال پسند ہے۔ اور ڈویلپرز اپنے ڈیٹا بیس کو برقرار رکھتے ہیں، جن کا بیک اپ ہمارے بیک اپ سسٹم کے ساتھ پوسٹگریس کے ساتھ یکساں طور پر لیا جا سکتا ہے۔
ہم نے اس کہانی سے کیا سیکھا؟ ہماری مصنوعات، ایک ترقیاتی ڈویژن کے طور پر، کوڈ کی لائنیں نہیں ہیں، یہ بیانات نہیں ہیں، یہ فائلیں نہیں ہیں۔ ہماری پروڈکٹ پل کی درخواستیں نہیں ہیں۔ یہ وہ خیالات ہیں جو ہم کمیونٹی تک پہنچاتے ہیں۔ یہ تکنیکی مہارت اور کلاؤڈ ماحول کی طرف ٹیکنالوجی کی نقل و حرکت ہے۔
پوسٹگریس جیسا ڈیٹا بیس موجود ہے۔ مجھے پوسٹگریس کور سب سے زیادہ پسند ہے۔ میں کمیونٹی کے ساتھ پوسٹگریس کور کو تیار کرنے میں بہت زیادہ وقت صرف کرتا ہوں۔
لیکن یہاں یہ کہنا ضروری ہے کہ Yandex.Cloud میں منظم ڈیٹا بیس کی اندرونی تنصیب ہے۔ اور یہ Yandex.Mail میں بہت پہلے شروع ہوا تھا۔ وہ مہارت جو اب پوسٹگریس کو منظم کرنے کا باعث بنی ہے اس وقت جمع ہوئی جب میل پوسٹگریس میں جانا چاہتی تھی۔
میل کی کلاؤڈ سے بہت ملتی جلتی ضروریات ہیں۔ اس کے لیے ضروری ہے کہ آپ اپنے ڈیٹا میں کسی بھی مقام پر غیر متوقع طور پر تیزی سے بڑھنے کے قابل ہوں۔ اور میل میں پہلے سے ہی لاکھوں میل باکسز کا بوجھ تھا جس میں صارفین کی ایک بہت بڑی تعداد ہے جو مسلسل بہت سی درخواستیں کرتے ہیں۔
اور یہ اس ٹیم کے لیے کافی سنگین چیلنج تھا جو پوسٹگریس تیار کر رہی تھی۔ اس کے بعد، ہمیں جو بھی مسائل درپیش تھے اس کی اطلاع کمیونٹی کو دی جاتی تھی۔ اور یہ مسائل کچھ جگہوں پر کمیونٹی کی طرف سے درست کیے گئے تھے، یہاں تک کہ کچھ دوسرے ڈیٹا بیسز کے لیے ادائیگی کی مدد کی سطح پر اور اس سے بھی بہتر۔ یعنی، آپ PgSQL ہیکر کو خط بھیج سکتے ہیں اور 40 منٹ کے اندر جواب موصول کر سکتے ہیں۔ کچھ ڈیٹا بیس میں ادا شدہ سپورٹ یہ سوچ سکتا ہے کہ آپ کے بگ سے زیادہ ترجیحی چیزیں ہیں۔
اب پوسٹگریس کی اندرونی تنصیب کچھ پیٹا بائٹس ڈیٹا ہے۔ یہ فی سیکنڈ لاکھوں درخواستیں ہیں۔ یہ ہزاروں کلسٹرز ہیں۔ یہ بہت بڑے پیمانے پر ہے۔
لیکن ایک nuance ہے. یہ فینسی نیٹ ورک ڈرائیوز پر نہیں بلکہ کافی سادہ ہارڈ ویئر پر رہتا ہے۔ اور خاص طور پر دلچسپ نئی چیزوں کے لیے آزمائشی ماحول ہے۔
اور ٹیسٹ کے ماحول میں ایک خاص لمحے پر ہمیں ایک پیغام موصول ہوا جس میں بتایا گیا کہ ڈیٹا بیس کے اشاریہ جات کے اندرونی انویرینٹس کی خلاف ورزی ہوئی ہے۔
ایک غیر متزلزل ایک قسم کا رشتہ ہے جسے ہم ہمیشہ برقرار رکھنے کی توقع کرتے ہیں۔
ہمارے لیے بہت نازک صورتحال ہے۔ یہ اشارہ کرتا ہے کہ کچھ ڈیٹا ضائع ہو سکتا ہے۔ اور ڈیٹا کا نقصان سراسر تباہ کن چیز ہے۔
عام خیال جس کی ہم منظم ڈیٹا بیس میں پیروی کرتے ہیں وہ یہ ہے کہ کوشش کے باوجود بھی ڈیٹا کو کھونا مشکل ہوگا۔ یہاں تک کہ اگر آپ جان بوجھ کر انہیں ہٹاتے ہیں، تب بھی آپ کو طویل عرصے تک ان کی غیر موجودگی کو نظر انداز کرنے کی ضرورت ہوگی۔ ڈیٹا سیکیورٹی ایک ایسا مذہب ہے جس کی ہم پوری تندہی سے پیروی کرتے ہیں۔
اور یہاں ایک ایسی صورت حال پیدا ہوتی ہے جو بتاتی ہے کہ ایسی صورت حال ہو سکتی ہے جس کے لیے ہم تیار نہ ہوں۔ اور ہم اس صورتحال کے لیے تیاری کرنے لگے۔
ہم نے سب سے پہلا کام ان ہزاروں کلسٹرز کے نوشتہ جات کو دفن کرنا تھا۔ ہم نے پایا کہ کون سے کلسٹرز ڈسکوں پر دشواری والے فرم ویئر کے ساتھ موجود تھے جو ڈیٹا پیج اپ ڈیٹس کو کھو رہے تھے۔ تمام پوسٹگریس ڈیٹا کوڈ کو نشان زد کیا۔ اور ہم نے ان پیغامات کو نشان زد کیا ہے جو کوڈ کے ساتھ اندرونی انویریئنٹس کی خلاف ورزیوں کی نشاندہی کرتے ہیں جو ڈیٹا کی بدعنوانی کا پتہ لگانے کے لیے ڈیزائن کیا گیا ہے۔
اس پیچ کو کمیونٹی نے بغیر کسی بحث کے عملی طور پر قبول کر لیا، کیونکہ ہر مخصوص معاملے میں یہ واضح تھا کہ کچھ برا ہوا تھا اور اس کی اطلاع لاگ کو دی جانی تھی۔
اس کے بعد، ہم اس مقام پر پہنچے کہ ہمارے پاس مانیٹرنگ ہے جو لاگز کو اسکین کرتی ہے۔ اور مشکوک پیغامات کی صورت میں وہ ڈیوٹی آفیسر کو جگاتا ہے اور ڈیوٹی آفیسر اس کی مرمت کرتا ہے۔
لیکن! لاگ سکیننگ ایک کلسٹر پر سستا آپریشن ہے اور ہزار کلسٹرز کے لیے تباہ کن طور پر مہنگا ہے۔
ہم نے ایک توسیع لکھی جسے کہا جاتا ہے۔ . یہ ڈیٹا بیس کا ایک منظر بناتا ہے جس میں آپ ماضی کی غلطیوں پر سستے اور تیزی سے اعدادوشمار منتخب کر سکتے ہیں۔ اور اگر ہمیں ڈیوٹی آفیسر کو جگانے کی ضرورت ہے، تو ہم گیگا بائٹ فائلوں کو اسکین کیے بغیر، بلکہ ہیش ٹیبل سے چند بائٹس نکال کر اس بارے میں معلوم کریں گے۔
اس توسیع کو اپنایا گیا ہے، مثال کے طور پر، کے لیے مخزن میں . اگر آپ اسے استعمال کرنا چاہتے ہیں تو آپ اسے خود انسٹال کر سکتے ہیں۔ یقیناً یہ اوپن سورس ہے۔
لیکن یہ سب کچھ نہیں ہے۔ ہم نے اشاریہ جات میں غیر متغیر خلاف ورزیوں کو تلاش کرنے کے لیے، کمیونٹی کی تعمیر کردہ ایک توسیع Amcheck کا استعمال شروع کیا۔
اور ہمیں پتہ چلا کہ اگر آپ اسے بڑے پیمانے پر چلاتے ہیں تو کیڑے ہوتے ہیں۔ ہم نے انہیں ٹھیک کرنا شروع کر دیا۔ ہماری تصحیحیں قبول کر لی گئی ہیں۔
ہم نے دریافت کیا کہ یہ توسیع GiST اور GIT اشاریہ جات کا تجزیہ نہیں کر سکتی۔ ہم نے انہیں سہارا دیا۔ لیکن کمیونٹی کی طرف سے اس حمایت پر اب بھی بات کی جا رہی ہے، کیونکہ یہ نسبتاً نئی فعالیت ہے اور اس میں بہت ساری تفصیلات موجود ہیں۔
اور ہم نے یہ بھی دریافت کیا کہ جب نقل کرنے والے لیڈر، ماسٹر پر خلاف ورزیوں کے اشاریہ جات کی جانچ پڑتال کرتے ہیں، تو سب کچھ ٹھیک کام کرتا ہے، لیکن نقلوں پر، پیروکار پر، بدعنوانی کی تلاش اتنی موثر نہیں ہوتی۔ تمام انویرینٹس کی جانچ نہیں کی جاتی ہے۔ اور ایک متغیر نے ہمیں بہت پریشان کیا۔ اور ہم نے ڈیڑھ سال کمیونٹی کے ساتھ بات چیت کرتے ہوئے گزارے تاکہ نقلوں پر اس چیک کو فعال کیا جا سکے۔
ہم نے کوڈ لکھا ہے جو تمام کر سکتے ہیں ... پروٹوکول پر عمل کرنا چاہئے. ہم نے کرنچی ڈیٹا سے پیٹر گگھن کے ساتھ کافی دیر تک اس پیچ پر تبادلہ خیال کیا۔ اس پیچ کو قبول کرنے کے لیے اسے پوسٹگریس میں موجود بی ٹری میں قدرے ترمیم کرنا پڑی۔ وہ مان گیا۔ اور اب نقلوں پر اشاریہ جات کی جانچ پڑتال بھی ان خلاف ورزیوں کا پتہ لگانے کے لیے کافی موثر ہو گئی ہے جن کا ہم نے سامنا کیا۔ یعنی یہ وہ خلاف ورزیاں ہیں جو ڈسک کے فرم ویئر میں خرابیوں، پوسٹگریس میں کیڑے، لینکس کرنل میں کیڑے اور ہارڈ ویئر کے مسائل کی وجہ سے ہو سکتی ہیں۔ مسائل کے ذرائع کی کافی وسیع فہرست جس کے لیے ہم تیاری کر رہے تھے۔
لیکن اشاریہ جات کے علاوہ، ڈھیر جیسا ایک حصہ ہے، یعنی وہ جگہ جہاں ڈیٹا کو محفوظ کیا جاتا ہے۔ اور بہت سے انویریئنٹس نہیں ہیں جن کی جانچ کی جاسکتی ہے۔
ہمارے پاس ہیپ چیک نامی ایک توسیع ہے۔ ہم نے اسے تیار کرنا شروع کیا۔ اور متوازی طور پر، ہمارے ساتھ مل کر، انٹرپرائز ڈی بی کمپنی نے بھی ایک ماڈیول لکھنا شروع کیا، جسے انہوں نے اسی طرح ہیپ چیک کہا۔ صرف ہم نے اسے PgHeapcheck کہا، اور انہوں نے اسے صرف Heapcheck کہا۔ ان کے پاس یہ اسی طرح کے افعال کے ساتھ ہے، تھوڑا سا مختلف دستخط، لیکن ایک جیسے خیالات کے ساتھ۔ انہوں نے انہیں کچھ جگہوں پر تھوڑا بہتر نافذ کیا۔ اور انہوں نے اسے پہلے اوپن سورس میں پوسٹ کیا تھا۔
اور اب ہم ان کی توسیع کو ترقی دے رہے ہیں، کیونکہ یہ اب ان کی توسیع نہیں بلکہ کمیونٹی کی توسیع ہے۔ اور مستقبل میں، یہ دانا کا حصہ ہے جو سب کو فراہم کیا جائے گا تاکہ وہ مستقبل کے مسائل کے بارے میں پہلے سے جان سکیں۔
کچھ جگہوں پر، ہم یہاں تک کہ اس نتیجے پر پہنچے کہ ہمارے نگرانی کے نظام میں غلط مثبت ہیں۔ مثال کے طور پر، 1C سسٹم۔ ڈیٹا بیس کا استعمال کرتے وقت، پوسٹگریس بعض اوقات اس میں ڈیٹا لکھتا ہے جسے وہ پڑھ سکتا ہے، لیکن pg_dump نہیں پڑھ سکتا۔
یہ صورتحال ہمارے مسئلے کا پتہ لگانے کے نظام میں بدعنوانی کی طرح لگ رہی تھی۔ ڈیوٹی آفیسر کو جگایا گیا۔ ڈیوٹی آفیسر نے دیکھا کہ کیا ہو رہا ہے۔ کچھ دیر بعد ایک گاہک آیا اور کہنے لگا کہ مجھے مسئلہ ہے۔ حاضرین نے بتایا کہ مسئلہ کیا ہے۔ لیکن مسئلہ پوسٹگریس کور میں ہے۔
مجھے اس خصوصیت کے بارے میں ایک بحث ملی۔ اور اس نے لکھا کہ ہمیں اس خصوصیت کا سامنا کرنا پڑا اور یہ ناگوار تھا، ایک شخص رات کو جاگتا تھا تاکہ یہ معلوم کر سکے کہ یہ کیا ہے۔
کمیونٹی نے جواب دیا، "اوہ، ہمیں واقعی اسے ٹھیک کرنے کی ضرورت ہے۔"
میرے پاس ایک سادہ سی تشبیہ ہے۔ اگر آپ ایسے جوتے میں چل رہے ہیں جس میں ریت کا ایک دانہ ہے، تو اصولی طور پر، آپ آگے بڑھ سکتے ہیں - کوئی بڑی بات نہیں۔ اگر آپ ہزاروں لوگوں کو جوتے بیچتے ہیں تو آئیے بغیر ریت کے جوتے ہی بنا لیں۔ اور اگر آپ کے جوتے استعمال کرنے والوں میں سے کوئی میراتھن دوڑ رہا ہے، تو آپ بہت اچھے جوتے بنانا چاہتے ہیں، اور پھر انہیں اپنے تمام صارفین تک پیمانہ کریں۔ اور ایسے غیر متوقع صارفین ہمیشہ بادل کے ماحول میں ہوتے ہیں۔ ہمیشہ ایسے صارفین ہوتے ہیں جو کسی نہ کسی اصل طریقے سے کلسٹر کا استحصال کرتے ہیں۔ ہمیں اس کے لیے ہمیشہ تیار رہنا چاہیے۔
ہم نے یہاں کیا سیکھا؟ ہم نے ایک سادہ سی بات سیکھی: سب سے اہم چیز کمیونٹی کو سمجھانا ہے کہ کوئی مسئلہ ہے۔ اگر کمیونٹی نے مسئلہ کو تسلیم کر لیا ہے، تو اس مسئلے کو حل کرنے کے لئے قدرتی مقابلہ پیدا ہوتا ہے. کیونکہ ہر کوئی ایک اہم مسئلہ حل کرنا چاہتا ہے۔ تمام وینڈرز، تمام ہیکرز سمجھتے ہیں کہ وہ خود اس ریک پر قدم رکھ سکتے ہیں، اس لیے وہ انہیں ختم کرنا چاہتے ہیں۔
اگر آپ کسی مسئلے پر کام کر رہے ہیں، لیکن یہ آپ کے علاوہ کسی کو پریشان نہیں کرتا، لیکن آپ اس پر منظم طریقے سے کام کرتے ہیں اور بالآخر اسے ایک مسئلہ سمجھا جاتا ہے، تو آپ کی پل کی درخواست ضرور قبول کی جائے گی۔ آپ کا پیچ قبول کیا جائے گا، آپ کی بہتری یا بہتری کی درخواستوں کا بھی کمیونٹی کے ذریعہ جائزہ لیا جائے گا۔ دن کے اختتام پر، ہم ڈیٹا بیس کو ایک دوسرے کے لیے بہتر بناتے ہیں۔
ایک دلچسپ ڈیٹا بیس گرین پلم ہے۔ یہ پوسٹگریس کوڈ بیس پر مبنی ایک انتہائی متوازی ڈیٹا بیس ہے، جس سے میں بہت واقف ہوں۔
اور گرین پلم میں دلچسپ فعالیت ہے - آپٹمائزڈ ٹیبلز کو شامل کریں۔ یہ وہ میزیں ہیں جنہیں آپ جلدی سے شامل کر سکتے ہیں۔ وہ یا تو کالم یا قطار ہوسکتے ہیں۔
لیکن کوئی کلسٹرنگ نہیں تھی، یعنی ایسی کوئی فعالیت نہیں تھی جہاں آپ ٹیبل میں موجود ڈیٹا کو ترتیب کے مطابق ترتیب دے سکیں جو انڈیکس میں سے کسی ایک میں ہے۔
ٹیکسی والے لوگ میرے پاس آئے اور کہا: "اینڈرے، آپ پوسٹگریس کو جانتے ہیں۔ اور یہاں یہ تقریبا ایک ہی ہے. 20 منٹ پر سوئچ کریں۔ تم لے لو اور کرو۔" میں نے سوچا کہ ہاں، میں پوسٹگریس کو جانتا ہوں، 20 منٹ کے لیے سوئچ کر رہا ہوں - مجھے یہ کرنے کی ضرورت ہے۔
لیکن نہیں، یہ 20 منٹ کا نہیں تھا، میں نے اسے مہینوں میں لکھا۔ PgConf.Russia کانفرنس میں، میں نے Pivotal سے Heikki Linakangas سے رابطہ کیا اور پوچھا: "کیا اس میں کوئی مسئلہ ہے؟ کوئی ضمیمہ آپٹمائزڈ ٹیبل کلسٹرنگ کیوں نہیں ہے؟" وہ کہتے ہیں: "آپ ڈیٹا لیتے ہیں۔ آپ ترتیب دیں، آپ دوبارہ ترتیب دیں۔ یہ صرف ایک کام ہے۔" میں: "اوہ، ہاں، آپ کو صرف اسے لینے اور کرنے کی ضرورت ہے۔" وہ کہتے ہیں: "ہاں، ہمیں ایسا کرنے کے لیے آزاد ہاتھ کی ضرورت ہے۔" میں نے سوچا کہ مجھے یہ ضرور کرنے کی ضرورت ہے۔
اور چند ماہ بعد میں نے ایک پل کی درخواست جمع کرائی جس نے اس فعالیت کو نافذ کیا۔ اس پل کی درخواست کا Pivotal نے کمیونٹی کے ساتھ مل کر جائزہ لیا۔ یقینا، وہاں کیڑے تھے.
لیکن سب سے دلچسپ بات یہ ہے کہ جب اس پل کی درخواست کو ملایا گیا تو گرین پلم میں ہی کیڑے پائے گئے۔ ہم نے پایا ہے کہ ہیپ ٹیبلز کبھی کبھی کلسٹر ہونے پر لین دین کو توڑ دیتے ہیں۔ اور یہ ایک ایسی چیز ہے جسے ٹھیک کرنے کی ضرورت ہے۔ اور وہ اس جگہ پر ہے جسے میں نے ابھی چھوا تھا۔ اور میرا فطری ردعمل تھا - ٹھیک ہے، مجھے بھی کرنے دو۔
میں نے اس مسئلے کو ٹھیک کر دیا۔ فکسرز کو پل کی درخواست بھیجی۔ وہ مارا گیا تھا.
جس کے بعد معلوم ہوا کہ یہ فعالیت PostgreSQL 12 کے گرین پلم ورژن میں حاصل کرنے کی ضرورت ہے۔ یعنی 20 منٹ کا ایڈونچر نئی دلچسپ مہم جوئی کے ساتھ جاری ہے۔ موجودہ ترقی کو چھونا دلچسپ تھا، جہاں کمیونٹی نئی اور سب سے اہم خصوصیات کاٹ رہی ہے۔ یہ منجمد ہے۔
لیکن یہ وہیں ختم نہیں ہوا۔ سب کچھ کے بعد، یہ پتہ چلا کہ ہمیں اس سب کے لئے دستاویزات لکھنے کی ضرورت ہے.
میں نے دستاویزات لکھنا شروع کر دیں۔ خوش قسمتی سے، Pivotal کے دستاویزی فلم ساز ساتھ آئے۔ انگریزی ان کی مادری زبان ہے۔ انہوں نے دستاویزات کے ساتھ میری مدد کی۔ درحقیقت، انہوں نے خود وہی لکھا جسے میں نے اصل انگریزی میں تجویز کیا۔
اور یہاں، ایسا لگتا ہے، ایڈونچر ختم ہو گیا. اور کیا آپ جانتے ہیں کہ پھر کیا ہوا؟ ٹیکسی والے میرے پاس آئے اور کہا: "ابھی دو مہم جوئی باقی ہیں، ہر ایک 10 منٹ کے لیے۔" اور میں انہیں کیا بتاؤں؟ میں نے کہا کہ اب میں پیمانے پر رپورٹ دوں گا، پھر ہم آپ کی مہم جوئی دیکھیں گے، کیونکہ یہ ایک دلچسپ کام ہے۔
اس کیس سے ہم نے کیا سیکھا؟ کیونکہ اوپن سورس کے ساتھ کام کرنا ہمیشہ کسی مخصوص شخص کے ساتھ کام کرتا ہے، یہ ہمیشہ کمیونٹی کے ساتھ کام کرتا ہے۔ کیونکہ ہر ایک مرحلے پر میں نے کسی نہ کسی ڈویلپر، کسی ٹیسٹر، کسی ہیکر، کسی ڈاکومینٹری، کسی آرکیٹیکٹ کے ساتھ کام کیا۔ میں نے گرین پلم کے ساتھ کام نہیں کیا، میں نے گرین پلم کے آس پاس کے لوگوں کے ساتھ کام کیا۔
لیکن! ایک اور اہم نکتہ ہے - یہ صرف کام ہے۔ یعنی تم آؤ، کافی پیو، کوڈ لکھو۔ ہر طرح کے سادہ انویرینٹس کام کرتے ہیں۔ اسے عام طور پر کرو - یہ ٹھیک ہو جائے گا! اور یہ کافی دلچسپ کام ہے۔ Yandex.Cloud کلائنٹس، Yandex کے اندر اور باہر ہمارے کلسٹرز کے صارفین سے اس کام کی درخواست ہے۔ اور میں سمجھتا ہوں کہ جن منصوبوں میں ہم حصہ لیں گے ان کی تعداد بڑھے گی اور ہماری شمولیت کی گہرائی بھی بڑھے گی۔
بس۔ آئیے سوالات کی طرف چلتے ہیں۔
سوالات کا سیشن
ہیلو! ہمارے پاس ایک اور سوال و جواب کا سیشن ہے۔ اور اسٹوڈیو اینڈری بوروڈن میں۔ یہ وہ شخص ہے جس نے ابھی آپ کو اوپن سورس میں Yandex.Cloud اور Yandex کی شراکت کے بارے میں بتایا ہے۔ ہماری رپورٹ اب مکمل طور پر کلاؤڈ کے بارے میں نہیں ہے، لیکن ساتھ ہی ہم ایسی ٹیکنالوجیز پر مبنی ہیں۔ آپ نے Yandex کے اندر جو کچھ کیا اس کے بغیر، Yandex.Cloud میں کوئی سروس نہیں ہوگی، لہذا ذاتی طور پر میری طرف سے آپ کا شکریہ۔ اور براڈکاسٹ سے پہلا سوال: "آپ نے جن پروجیکٹوں کا ذکر کیا ہے ان میں سے ہر ایک کس پر لکھا ہے؟"
WAL-G میں بیک اپ سسٹم گو میں لکھا ہوا ہے۔ یہ ان نئے منصوبوں میں سے ایک ہے جن پر ہم نے کام کیا ہے۔ وہ لفظی طور پر صرف 3 سال کا ہے۔ اور ایک ڈیٹا بیس اکثر وشوسنییتا کے بارے میں ہوتا ہے۔ اور اس کا مطلب ہے کہ ڈیٹا بیس کافی پرانے ہیں اور وہ عام طور پر C میں لکھے جاتے ہیں۔ پوسٹگریس پروجیکٹ تقریباً 30 سال پہلے شروع ہوا تھا۔ پھر C89 صحیح انتخاب تھا۔ اور اس پر پوسٹگریس لکھا ہوا ہے۔ مزید جدید ڈیٹا بیس جیسے ClickHouse عام طور پر C++ میں لکھے جاتے ہیں۔ سسٹم کی تمام تر نشوونما C اور C++ کے آس پاس ہے۔
ہمارے فنانشل مینیجر سے ایک سوال، جو کلاؤڈ کے اخراجات کے لیے ذمہ دار ہے: "کلاؤڈ اوپن سورس کو سپورٹ کرنے پر پیسہ کیوں خرچ کرتا ہے؟"
یہاں مالیاتی مینیجر کے لیے ایک آسان جواب ہے۔ ہم اپنی خدمات کو بہتر بنانے کے لیے ایسا کرتے ہیں۔ ہم کن طریقوں سے بہتر کر سکتے ہیں؟ ہم چیزوں کو زیادہ مؤثر طریقے سے، تیز تر، اور چیزوں کو مزید توسیع پذیر بنا سکتے ہیں۔ لیکن ہمارے لئے، یہ کہانی بنیادی طور پر وشوسنییتا کے بارے میں ہے. مثال کے طور پر، بیک اپ سسٹم میں ہم اس پر لاگو ہونے والے 100% پیچ کا جائزہ لیتے ہیں۔ ہم جانتے ہیں کہ کوڈ کیا ہے۔ اور ہم نئے ورژنز کو پروڈکشن میں لانے میں زیادہ آرام دہ ہیں۔ یعنی، سب سے پہلے، یہ اعتماد کے بارے میں ہے، ترقی کے لئے تیاری کے بارے میں اور وشوسنییتا کے بارے میں
ایک اور سوال: "کیا Yandex.Cloud میں رہنے والے بیرونی صارفین کی ضروریات اندرونی کلاؤڈ میں رہنے والے اندرونی صارفین سے مختلف ہیں؟"
لوڈ پروفائل یقیناً مختلف ہے۔ لیکن میرے شعبہ کے نقطہ نظر سے تمام خاص اور دلچسپ کیسز غیر معیاری لوڈ پر بنائے جاتے ہیں۔ تخیل کے ساتھ ڈویلپرز، ڈویلپرز جو غیر متوقع طور پر کرتے ہیں، اندرونی اور بیرونی طور پر پائے جانے کا امکان ہے. اس سلسلے میں، ہم سب تقریبا ایک جیسے ہیں. اور، شاید، ڈیٹا بیس کے Yandex آپریشن کے اندر واحد اہم خصوصیت یہ ہوگی کہ Yandex کے اندر ہمارے پاس ایک تعلیم ہے۔ کسی وقت، کچھ دستیابی زون مکمل طور پر سائے میں چلا جاتا ہے، اور تمام Yandex سروسز کو اس کے باوجود کسی نہ کسی طرح کام کرنا جاری رکھنا چاہیے۔ یہ ایک چھوٹا سا فرق ہے۔ لیکن یہ ڈیٹا بیس اور نیٹ ورک اسٹیک کے انٹرفیس پر بہت زیادہ تحقیقی ترقی پیدا کرتا ہے۔ بصورت دیگر، بیرونی اور اندرونی تنصیبات خصوصیات کے لیے ایک جیسی درخواستیں اور قابل اعتماد اور کارکردگی کو بہتر بنانے کے لیے ایک جیسی درخواستیں پیدا کرتی ہیں۔
اگلا سوال: "آپ ذاتی طور پر اس حقیقت کے بارے میں کیسے محسوس کرتے ہیں کہ آپ جو کچھ کرتے ہیں اس کا زیادہ تر استعمال دوسرے بادلوں کے ذریعہ کیا جاتا ہے؟" ہم مخصوص کا نام نہیں لیں گے، لیکن بہت سے پروجیکٹس جو Yandex.Cloud میں کیے گئے تھے دوسرے لوگوں کے بادلوں میں استعمال ہوتے ہیں۔
یہ ٹھنڈا ہے۔ سب سے پہلے، یہ اس بات کی علامت ہے کہ ہم نے کچھ ٹھیک کیا ہے۔ اور یہ انا کو نوچ دیتا ہے۔ اور ہمیں زیادہ یقین ہے کہ ہم نے صحیح فیصلہ کیا ہے۔ دوسری طرف، یہ امید ہے کہ مستقبل میں یہ ہمارے لیے نئے آئیڈیاز، تھرڈ پارٹی صارفین کی نئی درخواستیں لائے گا۔ GitHub پر زیادہ تر مسائل انفرادی سسٹم ایڈمنسٹریٹرز، انفرادی DBAs، انفرادی آرکیٹیکٹس، انفرادی انجینئرز کی طرف سے بنائے جاتے ہیں، لیکن بعض اوقات منظم تجربہ رکھنے والے لوگ آتے ہیں اور کہتے ہیں کہ 30% مخصوص معاملات میں ہمیں یہ مسئلہ درپیش ہے اور آئیے سوچتے ہیں کہ اسے کیسے حل کیا جائے۔ یہ وہی ہے جس کا ہم سب سے زیادہ انتظار کر رہے ہیں۔ ہم دوسرے کلاؤڈ پلیٹ فارمز کے ساتھ تجربات کا اشتراک کرنے کے منتظر ہیں۔
آپ نے میراتھن کے بارے میں بہت بات کی۔ میں جانتا ہوں کہ آپ نے ماسکو میں میراتھن دوڑائی۔ اس کے نتیجے میں؟ PostgreSQL سے لڑکوں کو پیچھے چھوڑ دیا؟
نہیں، Oleg Bartunov بہت تیزی سے دوڑتا ہے۔ اس نے مجھ سے ایک گھنٹہ آگے ختم کیا۔ مجموعی طور پر، میں اس سے خوش ہوں کہ میں نے کتنی دور حاصل کی ہے۔ میرے لیے صرف ختم کرنا ایک کارنامہ تھا۔ مجموعی طور پر، یہ حیرت کی بات ہے کہ پوسٹگریس کمیونٹی میں بہت سارے رنرز ہیں۔ مجھے ایسا لگتا ہے کہ ایروبک کھیلوں اور سسٹم پروگرامنگ کی خواہش کے درمیان کچھ قسم کا رشتہ ہے۔
کیا آپ کہہ رہے ہیں کہ ClickHouse میں کوئی رنرز نہیں ہیں؟
مجھے یقین ہے کہ وہ وہاں موجود ہیں۔ کلک ہاؤس بھی ایک ڈیٹا بیس ہے۔ ویسے، اولیگ اب مجھے لکھ رہا ہے: "کیا ہم رپورٹ کے بعد بھاگیں گے؟" یہ بہت اچھا خیال ہے۔
نکیتا سے براڈکاسٹ کا ایک اور سوال: "آپ نے گرین پلم میں بگ کو خود کیوں ٹھیک کیا اور جونیئرز کو کیوں نہیں دیا؟" سچ ہے، یہ بہت واضح نہیں ہے کہ بگ کیا ہے اور کس سروس میں، لیکن اس کا مطلب شاید وہی ہے جس کے بارے میں آپ نے بات کی ہے۔
ہاں اصولی طور پر کسی کو دیا جا سکتا تھا۔ یہ صرف وہی کوڈ تھا جسے میں نے ابھی تبدیل کیا۔ اور اسے فوراً جاری رکھنا فطری تھا۔ اصولی طور پر، ٹیم کے ساتھ مہارت کا اشتراک کرنے کا خیال ایک اچھا خیال ہے۔ ہم یقینی طور پر اپنے ڈویژن کے تمام ممبران کے درمیان گرین پلم کے کاموں کا اشتراک کریں گے۔
چونکہ ہم جونیئرز کے بارے میں بات کر رہے ہیں، یہاں ایک سوال ہے۔ اس شخص نے پوسٹگریس میں پہلا کمٹ بنانے کا فیصلہ کیا۔ پہلا عہد کرنے کے لیے اسے کیا کرنے کی ضرورت ہے؟
یہ ایک دلچسپ سوال ہے: "کہاں سے شروع کریں؟" دانا میں کسی چیز سے شروع کرنا عام طور پر کافی مشکل ہوتا ہے۔ پوسٹگریس میں، مثال کے طور پر، کرنے کی فہرست ہے۔ لیکن درحقیقت یہ ایک پرچہ ہے جو انہوں نے کرنے کی کوشش کی، لیکن کامیابی نہ ہوئی۔ یہ پیچیدہ چیزیں ہیں۔ اور عام طور پر آپ کو ماحولیاتی نظام میں کچھ افادیتیں مل سکتی ہیں، کچھ ایکسٹینشنز جنہیں بہتر بنایا جا سکتا ہے، جو کرنل ڈویلپرز کی طرف سے کم توجہ مبذول کرواتے ہیں۔ اور، اس کے مطابق، وہاں ترقی کے لئے مزید پوائنٹس ہیں. گوگل سمر آف کوڈ پروگرام میں، ہر سال پوسٹگریس کمیونٹی بہت سے مختلف موضوعات پیش کرتی ہے جن پر توجہ دی جا سکتی ہے۔ میرے خیال میں اس سال ہمارے پاس تین طالب علم تھے۔ یہاں تک کہ ایک نے WAL-G میں ان موضوعات پر لکھا جو Yandex کے لیے اہم ہیں۔ گرین پلم میں، پوسٹگریس کمیونٹی کے مقابلے میں سب کچھ آسان ہے، کیونکہ گرین پلم ہیکرز پل کی درخواستوں کو بہت اچھا سمجھتے ہیں اور فوراً جائزہ لینا شروع کر دیتے ہیں۔ پوسٹگریس کو پیچ بھیجنا مہینوں کی بات ہے، لیکن گرین پلم ایک دن میں آئے گا اور دیکھے گا کہ آپ نے کیا کیا ہے۔ ایک اور چیز یہ ہے کہ گرین پلم کو موجودہ مسائل کو حل کرنے کی ضرورت ہے۔ Greenplum بڑے پیمانے پر استعمال نہیں کیا جاتا ہے، لہذا آپ کے مسئلے کو تلاش کرنا کافی مشکل ہے. اور سب سے پہلے، ہمیں یقیناً مسائل کو حل کرنے کی ضرورت ہے۔
ماخذ: www.habr.com