اگلی HighLoad++ کانفرنس 6 اور 7 اپریل 2020 کو سینٹ پیٹرزبرگ میں منعقد ہوگی۔
تفصیلات اور ٹکٹ . ہائی لوڈ++ سائبیریا 2019۔ ہال "کراسنویارسک"۔ 25 جون، 12:00۔ مقالہ جات اور .
ایسا ہوتا ہے کہ عملی تقاضے نظریہ سے متصادم ہوتے ہیں، جہاں تجارتی مصنوعات کے لیے اہم پہلوؤں کو مدنظر نہیں رکھا جاتا۔ یہ گفتگو تجارتی مصنوعات کی ضروریات پر مبنی تعلیمی تحقیق کی بنیاد پر Causal مستقل مزاجی کے اجزاء بنانے کے لیے مختلف طریقوں کو منتخب کرنے اور ان کو یکجا کرنے کا عمل پیش کرتی ہے۔ سامعین منطقی گھڑیوں، انحصار سے باخبر رہنے، سسٹم کی حفاظت، گھڑی کی مطابقت پذیری، اور MongoDB نے کچھ حلوں پر کیوں طے کیا اس کے بارے میں موجودہ نظریاتی نقطہ نظر کے بارے میں سیکھیں گے۔
میخائل ٹیولینیف (اس کے بعد MT کہا جاتا ہے): - میں Causal consistency کے بارے میں بات کروں گا - یہ وہ خصوصیت ہے جس پر ہم نے MongoDB میں کام کیا ہے۔ میں تقسیم شدہ نظاموں کے ایک گروپ میں کام کرتا ہوں، ہم نے یہ تقریباً دو سال پہلے کیا تھا۔
اس عمل میں، مجھے اپنے آپ کو بہت ساری علمی تحقیق سے آشنا کرنا پڑا، کیونکہ اس خصوصیت کا کافی اچھی طرح سے مطالعہ کیا گیا ہے۔ اس سے معلوم ہوا کہ ایک بھی مضمون پروڈکشن ڈیٹابیس میں مطلوبہ چیزوں میں فٹ نہیں بیٹھتا ہے کیونکہ بہت ہی مخصوص تقاضوں کی وجہ سے جو شاید کسی پروڈکشن ایپلی کیشن میں موجود ہوں۔
میں اس بارے میں بات کروں گا کہ ہم، تعلیمی تحقیق کے صارفین کے طور پر، اس سے کچھ کیسے تیار کرتے ہیں جسے ہم اپنے صارفین کو ایک تیار شدہ ڈش کے طور پر پیش کر سکتے ہیں جو استعمال میں آسان اور محفوظ ہو۔
وجہ مستقل مزاجی آئیے تصورات کی وضاحت کرتے ہیں۔
شروع کرنے کے لیے، میں عام الفاظ میں یہ کہنا چاہتا ہوں کہ Causal consistency کیا ہے۔ دو کردار ہیں - لیونارڈ اور پینی (ٹی وی سیریز "دی بگ بینگ تھیوری"):
ہم کہتے ہیں کہ پینی یورپ میں ہے اور لیونارڈ اسے ایک سرپرائز پارٹی دینا چاہتا ہے۔ اور وہ اسے اپنی فرینڈ لسٹ سے نکالنے سے بہتر کچھ نہیں سوچ سکتا، اپنے تمام دوستوں کو فیڈ پر ایک اپ ڈیٹ بھیجتا ہے: "آئیے پینی کو خوش کریں!" (وہ یورپ میں ہے، جب وہ سوتی ہے، وہ یہ سب کچھ نہیں دیکھتی اور نہ دیکھ سکتی ہے، کیونکہ وہ وہاں نہیں ہے)۔ بالآخر، وہ اس پوسٹ کو حذف کر دیتی ہے، اسے فیڈ سے مٹا دیتی ہے اور رسائی کو بحال کرتی ہے تاکہ اسے کسی چیز کا نوٹس نہ لگے اور کوئی اسکینڈل نہ ہو۔
یہ سب ٹھیک اور اچھا ہے، لیکن چلو مان لیتے ہیں کہ نظام تقسیم ہے اور چیزیں تھوڑی غلط ہو گئی ہیں. مثال کے طور پر، یہ ہو سکتا ہے کہ اس پوسٹ کے شائع ہونے کے بعد Penny کی رسائی پر پابندی لگ گئی، اگر واقعات کا تعلق وجہ اور اثر سے نہیں ہے۔ درحقیقت، یہ اس کی ایک مثال ہے جب کسی کاروباری فنکشن کو انجام دینے کے لیے Causal مستقل مزاجی کی ضرورت ہوتی ہے (اس معاملے میں)۔
درحقیقت، یہ ڈیٹا بیس کی کافی غیر معمولی خصوصیات ہیں - بہت کم لوگ ان کی حمایت کرتے ہیں۔ آئیے ماڈلز کی طرف چلتے ہیں۔
مستقل مزاجی کے ماڈل
ڈیٹا بیس میں مستقل مزاجی کا ماڈل کیا ہے؟ یہ کچھ ضمانتیں ہیں جو تقسیم شدہ نظام اس بارے میں دیتا ہے کہ کلائنٹ کون سا ڈیٹا حاصل کر سکتا ہے اور کس ترتیب میں۔
اصولی طور پر، تمام مستقل مزاجی کے ماڈل اس بات پر آتے ہیں کہ تقسیم شدہ نظام ایک ایسے نظام سے کتنا ملتا جلتا ہے جو چلتا ہے، مثال کے طور پر، لیپ ٹاپ پر ایک نوڈ پر۔ اور اس طرح ایک ایسا نظام جو ہزاروں جیو ڈسٹری بیوٹڈ "نوڈز" پر چلتا ہے ایک لیپ ٹاپ سے ملتا جلتا ہے، جس میں اصولی طور پر یہ تمام خصوصیات خود بخود انجام پاتی ہیں۔
لہذا، مستقل مزاجی کے ماڈل صرف تقسیم شدہ نظاموں پر لاگو ہوتے ہیں۔ تمام سسٹمز جو پہلے موجود تھے اور ایک ہی عمودی اسکیلنگ پر چلتے تھے اس طرح کے مسائل کا سامنا نہیں کرتے تھے۔ ایک بفر کیش تھا، اور ہر چیز ہمیشہ اس سے پڑھی جاتی تھی۔
ماڈل مضبوط
دراصل، پہلا ماڈل ہی مضبوط ہے (یا عروج کی صلاحیت کی لکیر، جیسا کہ اسے اکثر کہا جاتا ہے)۔ یہ ایک مستقل مزاجی کا نمونہ ہے جو اس بات کو یقینی بناتا ہے کہ ہر تبدیلی، ایک بار اس بات کی تصدیق ہو جائے کہ یہ واقع ہو چکی ہے، سسٹم کے تمام صارفین کو دکھائی دے گی۔
یہ ڈیٹا بیس میں تمام واقعات کا عالمی ترتیب بناتا ہے۔ یہ ایک بہت مضبوط مستقل مزاجی کی خاصیت ہے، اور یہ عام طور پر بہت مہنگی ہوتی ہے۔ تاہم، یہ بہت اچھی طرح سے حمایت کی جاتی ہے. یہ بہت مہنگا اور سست ہے - یہ صرف شاذ و نادر ہی استعمال ہوتا ہے۔ اسے عروج کی صلاحیت کہتے ہیں۔
ایک اور مضبوط خاصیت ہے جو اسپنر میں سپورٹ کی جاتی ہے - جسے External Consistency کہتے ہیں۔ ہم اس پر تھوڑی دیر بعد بات کریں گے۔
کازال
اگلا ایک Causal ہے، جو بالکل وہی ہے جس کے بارے میں میں بات کر رہا تھا۔ Strong اور Causal کے درمیان کئی اور ذیلی سطحیں ہیں جن کے بارے میں میں بات نہیں کروں گا، لیکن وہ سب Causal پر ابلتے ہیں۔ یہ ایک اہم ماڈل ہے کیونکہ یہ تمام ماڈلز میں سب سے مضبوط ہے، نیٹ ورک یا پارٹیشنز کی موجودگی میں سب سے مضبوط مستقل مزاجی ہے۔
Causals دراصل ایک ایسی صورتحال ہے جس میں واقعات ایک وجہ اور اثر کے تعلق سے جڑے ہوتے ہیں۔ اکثر انہیں کلائنٹ کے نقطہ نظر سے اپنے حقوق پر پڑھیں کے طور پر سمجھا جاتا ہے۔ اگر کلائنٹ نے کچھ اقدار کا مشاہدہ کیا ہے، تو وہ وہ اقدار نہیں دیکھ سکتا جو ماضی میں تھیں۔ وہ پہلے سے ہی پریفکس ریڈنگ دیکھنا شروع کر رہا ہے۔ یہ سب ایک ہی چیز پر آتا ہے۔
ایک مستقل مزاجی ماڈل کے طور پر Causals سرور پر واقعات کی ایک جزوی ترتیب ہے، جس میں تمام کلائنٹس کے واقعات کو ایک ہی ترتیب میں دیکھا جاتا ہے۔ اس معاملے میں، لیونارڈ اور پینی.
حتمی
تیسرا ماڈل واقعہ مستقل مزاجی ہے۔ یہ وہی ہے جو بالکل تمام تقسیم شدہ نظاموں کی حمایت کرتے ہیں، کم سے کم ماڈل جو بالکل بھی معنی رکھتا ہے۔ اس کا مطلب مندرجہ ذیل ہے: جب ہمارے اعداد و شمار میں کچھ تبدیلیاں آتی ہیں، تو کسی وقت وہ مستقل ہو جاتے ہیں۔
ایسے وقت میں وہ کچھ نہیں کہتی، ورنہ وہ External Consistency میں بدل جاتی - یہ بالکل مختلف کہانی ہوگی۔ بہر حال، یہ ایک بہت مقبول ماڈل، سب سے زیادہ عام ہے. پہلے سے طے شدہ طور پر، تقسیم شدہ نظاموں کے تمام صارفین Eventual Consistency استعمال کرتے ہیں۔
میں کچھ تقابلی مثالیں دینا چاہتا ہوں:
ان تیروں کا کیا مطلب ہے؟
- تاخیر. جیسے جیسے مستقل مزاجی میں اضافہ ہوتا ہے، یہ واضح وجوہات کی بنا پر بڑا ہوتا جاتا ہے: آپ کو مزید ریکارڈ بنانے، کلسٹر میں حصہ لینے والے تمام میزبانوں اور نوڈس سے تصدیق حاصل کرنے کی ضرورت ہے کہ ڈیٹا پہلے سے موجود ہے۔ اس کے مطابق، Eventual Consistency کا سب سے تیز جواب ہے، کیونکہ وہاں، ایک اصول کے طور پر، آپ اسے میموری پر بھی کر سکتے ہیں اور یہ اصولی طور پر کافی ہوگا۔
- دستیابی اگر ہم اسے نیٹ ورک کے ٹوٹ جانے، پارٹیشنز، یا کسی قسم کی ناکامی کی موجودگی میں جواب دینے کی سسٹم کی صلاحیت کے طور پر سمجھتے ہیں، تو مستقل مزاجی کے ماڈل کے کم ہونے کے ساتھ ہی غلطی کی برداشت بڑھ جاتی ہے، کیونکہ ہمارے لیے یہ کافی ہے کہ ایک میزبان زندہ رہے اور ایک ہی وقت میں۔ وقت کچھ ڈیٹا تیار کرتا ہے۔ حتمی مستقل مزاجی ڈیٹا کے بارے میں کسی بھی چیز کی ضمانت نہیں دیتی ہے - یہ کچھ بھی ہوسکتا ہے۔
- بے ضابطگیوں ایک ہی وقت میں، یقینا، بے ضابطگیوں کی تعداد میں اضافہ ہوتا ہے. مضبوط مستقل مزاجی میں ان کا تقریباً کوئی وجود نہیں ہونا چاہیے، لیکن حتمی مستقل مزاجی میں وہ کچھ بھی ہو سکتے ہیں۔ سوال یہ پیدا ہوتا ہے: اگر لوگ بے ضابطگیوں پر مشتمل ہوں تو لوگ حتمی مستقل مزاجی کا انتخاب کیوں کرتے ہیں؟ اس کا جواب یہ ہے کہ واقعاتی مطابقت کے ماڈل لاگو ہوتے ہیں اور بے ضابطگیاں موجود ہیں، مثال کے طور پر، مختصر مدت میں؛ وزرڈ کو پڑھنے اور کم و بیش مستقل ڈیٹا کو پڑھنے کے لیے استعمال کرنا ممکن ہے۔ مضبوط مستقل مزاجی کے ماڈل استعمال کرنا اکثر ممکن ہوتا ہے۔ عملی طور پر یہ کام کرتا ہے، اور اکثر بے ضابطگیوں کی تعداد وقت میں محدود ہوتی ہے۔
CAP نظریہ
جب آپ الفاظ کی مستقل مزاجی، دستیابی کو دیکھتے ہیں - آپ کے ذہن میں کیا آتا ہے؟ یہ ٹھیک ہے - CAP تھیوریم! اب میں اس افسانے کو دور کرنا چاہتا ہوں... یہ میں نہیں ہوں - یہ مارٹن کلیپ مین ہے، جس نے ایک شاندار مضمون لکھا، ایک شاندار کتاب۔
CAP نظریہ ایک اصول ہے جو 2000 کی دہائی میں وضع کیا گیا تھا کہ مستقل مزاجی، دستیابی، تقسیم: کوئی بھی دو لیں، اور آپ تین کا انتخاب نہیں کر سکتے۔ یہ ایک خاص اصول تھا۔ اسے چند سال بعد گلبرٹ اور لنچ نے ایک نظریہ کے طور پر ثابت کیا۔ پھر اسے منتر کے طور پر استعمال کیا جانے لگا - سسٹمز کو CA، CP، AP وغیرہ میں تقسیم کیا جانے لگا۔
یہ نظریہ درحقیقت درج ذیل صورتوں کے لیے ثابت ہوا تھا... سب سے پہلے، دستیابی کو صفر سے سینکڑوں تک مسلسل قدر نہیں سمجھا جاتا تھا (0 - نظام "مردہ" ہے، 100 - فوری جواب دیتا ہے؛ ہم اس پر غور کرنے کے عادی ہیں) ، لیکن الگورتھم کی خاصیت کے طور پر، جو اس بات کی ضمانت دیتا ہے کہ اس کے تمام عمل کے لیے یہ ڈیٹا واپس کرتا ہے۔
جوابی وقت کے بارے میں ایک لفظ بھی نہیں ہے! ایک الگورتھم ہے جو 100 سال بعد ڈیٹا واپس کرتا ہے - ایک بالکل شاندار دستیاب الگورتھم، جو CAP تھیوریم کا حصہ ہے۔
دوسرا: نظریہ ایک ہی کلید کی اقدار میں تبدیلیوں کے لیے ثابت ہوا، اس حقیقت کے باوجود کہ یہ تبدیلیاں قابل سائز ہیں۔ اس کا مطلب یہ ہے کہ حقیقت میں وہ عملی طور پر استعمال نہیں ہوتے ہیں، کیونکہ ماڈلز مختلف ہیں Eventual Consistency، Strong Consistency (شاید)۔
یہ سب کس لیے ہے؟ مزید یہ کہ CAP تھیوریم بالکل اسی شکل میں جس میں یہ ثابت ہوا ہے عملی طور پر قابل اطلاق نہیں ہے اور شاذ و نادر ہی استعمال ہوتا ہے۔ نظریاتی شکل میں، یہ کسی نہ کسی طرح ہر چیز کو محدود کرتا ہے۔ یہ ایک خاص اصول ہے جو بدیہی طور پر درست ہے، لیکن عام طور پر ثابت نہیں ہوا ہے.
Causal مستقل مزاجی سب سے مضبوط ماڈل ہے۔
اب جو ہو رہا ہے وہ یہ ہے کہ آپ تینوں چیزیں حاصل کر سکتے ہیں: مستقل مزاجی، پارٹیشنز کا استعمال کرتے ہوئے دستیابی۔ خاص طور پر، Causal consistency سب سے مضبوط مستقل مزاجی ماڈل ہے، جو اب بھی پارٹیشنز (نیٹ ورک میں بریک) کی موجودگی میں کام کرتا ہے۔ یہی وجہ ہے کہ یہ بہت زیادہ دلچسپی کا باعث ہے، اور اسی وجہ سے ہم نے اسے اٹھایا۔
سب سے پہلے، یہ ایپلیکیشن ڈویلپرز کے کام کو آسان بناتا ہے۔ خاص طور پر، سرور سے زبردست تعاون کی موجودگی: جب ایک کلائنٹ کے اندر موجود تمام ریکارڈز دوسرے کلائنٹ پر اسی ترتیب میں پہنچنے کی ضمانت دی جاتی ہے۔ دوم، یہ پارٹیشنز کو برداشت کرتا ہے۔
مونگو ڈی بی اندرونی کچن
یہ یاد کرتے ہوئے کہ یہ دوپہر کا کھانا ہے، ہم کچن میں چلے جاتے ہیں۔ میں آپ کو سسٹم ماڈل کے بارے میں بتاؤں گا، یعنی مونگو ڈی بی ان لوگوں کے لیے کیا ہے جو اس طرح کے ڈیٹا بیس کے بارے میں پہلی بار سن رہے ہیں۔
MongoDB (اس کے بعد "MongoDB" کہا جاتا ہے) ایک تقسیم شدہ نظام ہے جو افقی اسکیلنگ کو سپورٹ کرتا ہے، یعنی شارڈنگ؛ اور ہر شارڈ کے اندر یہ ڈیٹا فالتو پن کو بھی سپورٹ کرتا ہے، یعنی نقل۔
MongoDB میں شارڈنگ (ریلیشنل ڈیٹا بیس نہیں) خودکار توازن کو انجام دیتی ہے، یعنی دستاویزات کے ہر مجموعہ (یا رشتہ دار ڈیٹا کے لحاظ سے "ٹیبل") کو ٹکڑوں میں تقسیم کیا جاتا ہے، اور سرور خود بخود انہیں شارڈز کے درمیان منتقل کرتا ہے۔
Query Router، جو درخواستیں تقسیم کرتا ہے، کلائنٹ کے لیے کچھ کلائنٹ ہوتا ہے جس کے ذریعے یہ کام کرتا ہے۔ یہ پہلے ہی جانتا ہے کہ کہاں اور کون سا ڈیٹا واقع ہے اور تمام درخواستوں کو صحیح شارڈ کی طرف ہدایت کرتا ہے۔
ایک اور اہم نکتہ: MongoDB ایک واحد ماسٹر ہے۔ ایک پرائمری ہے - یہ ایسے ریکارڈ لے سکتا ہے جو اس میں موجود کلیدوں کو سپورٹ کرتے ہیں۔ آپ ملٹی ماسٹر لکھ نہیں سکتے۔
ہم نے 4.2 ریلیز کیا - وہاں نئی دلچسپ چیزیں نمودار ہوئیں۔ خاص طور پر، انہوں نے لوسین - سرچ - یعنی ایگزیکیوٹیبل جاوا کو براہ راست مونگو میں داخل کیا، اور وہاں لوسین کے ذریعے تلاش کرنا ممکن ہو گیا، جیسا کہ Elastica میں ہوتا ہے۔
اور انہوں نے ایک نیا پروڈکٹ بنایا - چارٹس، یہ اٹلس (منگو کے اپنے کلاؤڈ) پر بھی دستیاب ہے۔ ان کے پاس ایک مفت ٹائر ہے - آپ اس کے ساتھ کھیل سکتے ہیں۔ مجھے واقعی چارٹس پسند آئے - ڈیٹا ویژولائزیشن، بہت بدیہی۔
اجزاء Causal مستقل مزاجی
میں نے تقریباً 230 مضامین کا شمار کیا جو اس موضوع پر شائع ہوئے ہیں - لیسلی لیمپرٹ سے۔ اب میں اپنی یادداشت سے ان مواد کے کچھ حصے آپ تک پہنچاتا ہوں۔
یہ سب لیسلی لیمپرٹ کے ایک مضمون سے شروع ہوا، جو 1970 کی دہائی میں لکھا گیا تھا۔ جیسا کہ آپ دیکھ سکتے ہیں، اس موضوع پر کچھ تحقیق اب بھی جاری ہے۔ اب Causal consistency تقسیم شدہ نظاموں کی ترقی کے سلسلے میں دلچسپی کا سامنا کر رہی ہے۔
پابندیاں
کیا پابندیاں ہیں؟ یہ دراصل اہم نکات میں سے ایک ہے، کیونکہ پیداواری نظام جو پابندیاں عائد کرتا ہے وہ ان پابندیوں سے بہت مختلف ہے جو تعلیمی مضامین میں موجود ہیں۔ وہ اکثر کافی مصنوعی ہوتے ہیں۔
- سب سے پہلے، "MongoDB" ایک واحد ماسٹر ہے، جیسا کہ میں پہلے ہی کہہ چکا ہوں (یہ بہت آسان بناتا ہے)۔
- ہم سمجھتے ہیں کہ سسٹم کو تقریباً 10 ہزار شارڈز کو سپورٹ کرنا چاہیے۔ ہم کوئی تعمیراتی فیصلے نہیں کر سکتے جو اس قدر کو واضح طور پر محدود کر دے۔
- ہمارے پاس کلاؤڈ ہے، لیکن ہم فرض کرتے ہیں کہ ایک شخص کو اب بھی موقع ملنا چاہیے جب وہ بائنری ڈاؤن لوڈ کرتا ہے، اسے اپنے لیپ ٹاپ پر چلاتا ہے، اور سب کچھ اچھا کام کرتا ہے۔
- ہم کچھ ایسا فرض کرتے ہیں جو ریسرچ شاذ و نادر ہی فرض کرتی ہے: بیرونی کلائنٹس جو چاہیں کر سکتے ہیں۔ MongoDB اوپن سورس ہے۔ اس کے مطابق، کلائنٹ اتنے ہوشیار اور ناراض ہوسکتے ہیں - وہ ہر چیز کو توڑنا چاہتے ہیں. ہم قیاس کرتے ہیں کہ بازنطینی فیلرز کی ابتدا ہو سکتی ہے۔
- بیرونی کلائنٹس کے لیے جو دائرہ سے باہر ہیں، ایک اہم حد ہے: اگر یہ خصوصیت غیر فعال ہے، تو کارکردگی میں کوئی کمی نہیں دیکھی جانی چاہیے۔
- ایک اور نکتہ عام طور پر علم مخالف ہے: پچھلے ورژن اور مستقبل کے ورژن کی مطابقت۔ پرانے ڈرائیوروں کو نئی اپ ڈیٹس کو سپورٹ کرنا چاہیے، اور ڈیٹا بیس کو پرانے ڈرائیوروں کو سپورٹ کرنا چاہیے۔
عام طور پر، یہ سب پابندیاں عائد کرتا ہے۔
Causal مستقل مزاجی کے اجزاء
اب میں کچھ اجزاء کے بارے میں بات کروں گا۔ اگر ہم عام طور پر Causal consistency پر غور کریں تو ہم بلاکس کو منتخب کر سکتے ہیں۔ ہم نے ان کاموں میں سے انتخاب کیا جن کا تعلق ایک خاص بلاک سے ہے: انحصار سے باخبر رہنا، گھڑیوں کا انتخاب، ان گھڑیوں کو ایک دوسرے کے ساتھ کیسے ہم آہنگ کیا جا سکتا ہے، اور ہم کس طرح حفاظت کو یقینی بناتے ہیں - یہ اس کا ایک خاکہ ہے جس کے بارے میں میں بات کروں گا:
مکمل انحصار سے باخبر رہنا
اس کی ضرورت کیوں ہے؟ تاکہ جب ڈیٹا کو نقل کیا جائے تو ہر ریکارڈ، ہر ڈیٹا کی تبدیلی میں یہ معلومات ہوتی ہے کہ یہ کن تبدیلیوں پر منحصر ہے۔ پہلی اور سادہ تبدیلی تب ہوتی ہے جب ہر پیغام جس میں ریکارڈ ہوتا ہے پچھلے پیغامات کے بارے میں معلومات پر مشتمل ہوتا ہے:
اس مثال میں، گھوبگھرالی بریکٹ میں نمبر ریکارڈ نمبرز ہیں۔ کبھی کبھی اقدار کے ساتھ یہ ریکارڈ مکمل طور پر منتقل کر دیا جاتا ہے، کبھی کبھی کچھ ورژن منتقل کر دیا جاتا ہے. سب سے اہم بات یہ ہے کہ ہر تبدیلی میں پچھلی تبدیلی کے بارے میں معلومات ہوتی ہیں (ظاہر ہے کہ یہ سب کچھ اپنے اندر رکھتا ہے)۔
ہم نے یہ طریقہ استعمال نہ کرنے کا فیصلہ کیوں کیا (مکمل ٹریکنگ)؟ ظاہر ہے، کیونکہ یہ نقطہ نظر ناقابل عمل ہے: سوشل نیٹ ورک میں کوئی بھی تبدیلی اس سوشل نیٹ ورک کی تمام پچھلی تبدیلیوں پر منحصر ہوتی ہے، ہر اپ ڈیٹ میں فیس بک یا VKontakte کی منتقلی اس کے باوجود، مکمل انحصار سے باخبر رہنے کے بارے میں بہت ساری تحقیق ہے – یہ پری سوشل نیٹ ورکس ہیں؛ کچھ حالات میں یہ واقعی کام کرتا ہے۔
واضح انحصار سے باخبر رہنا
اگلا زیادہ محدود ہے۔ معلومات کی منتقلی کو بھی یہاں سمجھا جاتا ہے، لیکن صرف وہی جو واضح طور پر منحصر ہے۔ ایک اصول کے طور پر، درخواست کے ذریعہ کس چیز کا تعین کیا جاتا ہے اس پر منحصر ہے۔ جب ڈیٹا کو نقل کیا جاتا ہے، استفسار صرف اس صورت میں جوابات دیتا ہے جب سابقہ انحصار مطمئن ہو، یعنی دکھایا گیا ہو۔ یہ اس بات کا نچوڑ ہے کہ Causal مستقل مزاجی کیسے کام کرتی ہے۔
وہ دیکھتی ہے کہ ریکارڈ 5 کا انحصار ریکارڈ 1، 2، 3، 4 پر ہے - اس کے مطابق، وہ پینی کے رسائی کے فیصلے کے ذریعے کی گئی تبدیلیوں تک کلائنٹ تک رسائی حاصل کرنے سے پہلے انتظار کرتی ہے، جب تمام پچھلی تبدیلیاں ڈیٹا بیس سے گزر چکی ہیں۔
یہ ہم پر بھی مناسب نہیں ہے، کیونکہ ابھی بھی بہت زیادہ معلومات موجود ہیں، اور اس سے چیزیں سست ہو جائیں گی۔ ایک اور طریقہ ہے...
لیمپورٹ کلاک
وہ بہت پرانے ہیں۔ لیمپورٹ کلاک کا مطلب ہے کہ یہ انحصار ایک اسکیلر فنکشن میں جوڑ دیا جاتا ہے، جسے لیمپورٹ کلاک کہا جاتا ہے۔
اسکیلر فنکشن کچھ خلاصہ نمبر ہے۔ اسے اکثر منطقی وقت کہا جاتا ہے۔ ہر ایونٹ کے ساتھ، یہ کاؤنٹر بڑھتا ہے. کاؤنٹر، جو فی الحال عمل کے لیے جانا جاتا ہے، ہر پیغام بھیجتا ہے۔ یہ واضح ہے کہ عمل ہم آہنگی سے باہر ہو سکتے ہیں، ان کے بالکل مختلف اوقات ہو سکتے ہیں۔ اس کے باوجود، نظام کسی نہ کسی طرح اس طرح کے پیغام رسانی کے ساتھ گھڑی کو متوازن کرتا ہے۔ اس معاملے میں کیا ہوتا ہے؟
میں نے اسے واضح کرنے کے لیے اس بڑے شارڈ کو دو حصوں میں تقسیم کیا: دوست ایک نوڈ میں رہ سکتے ہیں، جس میں مجموعہ کا ایک ٹکڑا ہوتا ہے، اور فیڈ دوسرے نوڈ میں رہ سکتا ہے، جس میں اس مجموعہ کا ایک ٹکڑا ہوتا ہے۔ کیا یہ واضح ہے کہ وہ لائن سے باہر کیسے نکل سکتے ہیں؟ پہلا فیڈ کہے گا: "نقل شدہ"، اور پھر دوست۔ اگر سسٹم کسی قسم کی گارنٹی فراہم نہیں کرتا ہے کہ فیڈ کو اس وقت تک نہیں دکھایا جائے گا جب تک کہ فرینڈز کلیکشن میں فرینڈز پر انحصار نہیں کیا جاتا، تو ہمارے پاس بالکل وہی صورتحال ہوگی جس کا میں نے ذکر کیا ہے۔
آپ دیکھتے ہیں کہ فیڈ پر کاؤنٹر ٹائم منطقی طور پر کیسے بڑھتا ہے:
لہٰذا اس لیمپورٹ کلاک اور کازل مستقل مزاجی کی اصل خاصیت (لیمپورٹ کلاک کے ذریعے بیان کی گئی) یہ ہے: اگر ہمارے پاس ایونٹس A اور B ہیں، اور ایونٹ B واقعہ A* پر منحصر ہے، تو اس کے بعد یہ ہے کہ ایونٹ A کا منطقی وقت اس سے کم ہے۔ LogicalTime from Event B
* کبھی کبھی وہ یہ بھی کہتے ہیں کہ A B سے پہلے ہوا، یعنی A B سے پہلے ہوا - یہ ایک خاص رشتہ ہے جو عام طور پر پیش آنے والے واقعات کے پورے مجموعہ کو جزوی طور پر ترتیب دیتا ہے۔
اس کے برعکس غلط ہے۔ یہ دراصل لیمپورٹ کلاک کے اہم نقصانات میں سے ایک ہے - جزوی ترتیب۔ بیک وقت ہونے والے واقعات کے بارے میں ایک تصور ہے، یعنی ایسے واقعات جن میں نہ تو (A B سے پہلے ہوا) اور نہ ہی (A B سے پہلے ہوا)۔ ایک مثال لیونارڈ کا ایک دوست کے طور پر کسی اور کا متوازی اضافہ ہوگا (مثال کے طور پر لیونارڈ نہیں، بلکہ شیلڈن)۔
یہ وہ خاصیت ہے جو اکثر لیمپورٹ گھڑیوں کے ساتھ کام کرتے وقت استعمال ہوتی ہے: وہ خاص طور پر فنکشن کو دیکھتے ہیں اور اس سے وہ یہ نتیجہ اخذ کرتے ہیں کہ شاید یہ واقعات منحصر ہیں۔ کیونکہ ایک طریقہ درست ہے: اگر LogicalTime A LogicalTime B سے کم ہے، تو B A سے پہلے نہیں ہو سکتا۔ اور اگر زیادہ، تو شاید.
ویکٹر کلاک
لیمپورٹ گھڑی کی منطقی ترقی ویکٹر کلاک ہے۔ ان میں فرق ہے کہ یہاں موجود ہر نوڈ کی اپنی الگ گھڑی ہوتی ہے، اور وہ ایک ویکٹر کے طور پر منتقل ہوتے ہیں۔
اس صورت میں، آپ دیکھتے ہیں کہ ویکٹر کا زیروتھ انڈیکس فیڈ کے لیے ذمہ دار ہے، اور ویکٹر کا پہلا انڈیکس فرینڈز (ان نوڈز میں سے ہر ایک) کے لیے ہے۔ اور اب وہ بڑھیں گے: لکھتے وقت "فیڈ" کا صفر انڈیکس بڑھ جاتا ہے - 1، 2، 3:
ویکٹر کلاک کیوں بہتر ہے؟ کیونکہ وہ آپ کو یہ جاننے کی اجازت دیتے ہیں کہ کون سے واقعات بیک وقت ہوتے ہیں اور کب وہ مختلف نوڈس پر ہوتے ہیں۔ یہ MongoDB جیسے شارڈنگ سسٹم کے لیے بہت اہم ہے۔ تاہم، ہم نے اس کا انتخاب نہیں کیا، حالانکہ یہ ایک حیرت انگیز چیز ہے، اور یہ بہت اچھا کام کرتا ہے، اور یہ شاید ہمارے لیے مناسب ہو گا...
اگر ہمارے پاس 10 ہزار شارڈز ہیں، تو ہم 10 ہزار اجزاء کو منتقل نہیں کر سکتے، چاہے ہم اسے کمپریس کریں یا کوئی اور چیز لے کر آئیں - پے لوڈ اب بھی اس پورے ویکٹر کے حجم سے کئی گنا چھوٹا ہوگا۔ لہٰذا، اپنے دل اور دانت پیستے ہوئے، ہم نے یہ طریقہ ترک کر دیا اور دوسری طرف چلے گئے۔
اسپنر ٹرو ٹائم۔ ایٹمی گھڑی
میں نے کہا کہ اسپینر کے بارے میں کوئی کہانی ہوگی۔ یہ XNUMX ویں صدی سے بالکل اچھی چیز ہے: جوہری گھڑیاں، GPS مطابقت پذیری۔
کیا خیال ہے؟ "اسپینر" ایک گوگل سسٹم ہے جو حال ہی میں لوگوں کے لیے بھی دستیاب ہوا ہے (انہوں نے اس میں ایس کیو ایل شامل کیا ہے)۔ ہر لین دین پر کچھ وقت کی مہر ہوتی ہے۔ چونکہ وقت مطابقت پذیر ہوتا ہے*، ہر واقعہ کو ایک مخصوص وقت تفویض کیا جا سکتا ہے - جوہری گھڑیوں کا انتظار کا وقت ہوتا ہے، جس کے بعد ایک مختلف وقت "ہونے" کی ضمانت دی جاتی ہے۔
اس طرح، صرف ڈیٹا بیس پر لکھنے اور کچھ وقت کا انتظار کرنے سے، ایونٹ کی سیریلائزیبلٹی خود بخود یقینی ہو جاتی ہے۔ ان کے پاس سب سے مضبوط Consistency ماڈل ہے جس کا اصولی طور پر تصور کیا جا سکتا ہے - یہ External Consistency ہے۔
لیمپارٹ گھڑیوں کے ساتھ یہ بنیادی مسئلہ ہے - وہ تقسیم شدہ نظاموں پر کبھی بھی ہم آہنگ نہیں ہوتے ہیں۔ وہ ہٹ سکتے ہیں؛ یہاں تک کہ NTP کے ساتھ بھی، وہ اب بھی بہت اچھا کام نہیں کرتے ہیں۔ "اسپینر" کے پاس ایک ایٹمی گھڑی ہے اور ہم وقت سازی، ایسا لگتا ہے، مائیکرو سیکنڈز ہے۔
ہم نے انتخاب کیوں نہیں کیا؟ ہم یہ نہیں سمجھتے کہ ہمارے صارفین کے پاس بلٹ ان ایٹم کلاک ہے۔ جب وہ ظاہر ہوتے ہیں، ہر لیپ ٹاپ میں بنائے جاتے ہیں، وہاں ایک طرح کی زبردست GPS مطابقت پذیری ہوگی - پھر ہاں... لیکن اس وقت کے لیے جو سب سے بہتر ممکن ہے وہ ہے Amazon، بیس اسٹیشنز - جنونیوں کے لیے... اس لیے ہم نے دوسری گھڑیاں استعمال کیں۔ .
ہائبرڈ گھڑی
یہ اصل میں ہے جو MongoDB میں ٹک کرتا ہے جب Causal مستقل مزاجی کو یقینی بناتا ہے۔ وہ ہائبرڈ کیسے ہیں؟ ہائبرڈ ایک اسکیلر ویلیو ہے، لیکن اس کے دو اجزاء ہیں:
- پہلا یونکس عہد ہے ("کمپیوٹر کی دنیا کے آغاز" سے کتنے سیکنڈ گزر چکے ہیں)۔
- دوسرا کچھ اضافہ ہے، ایک 32 بٹ غیر دستخط شدہ انٹ بھی۔
یہ سب ہے، اصل میں. یہ نقطہ نظر ہے: وہ حصہ جو وقت کا ذمہ دار ہے ہر وقت گھڑی کے ساتھ ہم آہنگ ہوتا ہے۔ جب بھی کوئی اپ ڈیٹ ہوتا ہے، یہ حصہ گھڑی کے ساتھ مطابقت پذیر ہوتا ہے اور یہ پتہ چلتا ہے کہ وقت ہمیشہ کم و بیش درست ہوتا ہے، اور اضافہ آپ کو ان واقعات کے درمیان فرق کرنے کی اجازت دیتا ہے جو وقت کے ایک ہی مقام پر پیش آئے تھے۔
یہ MongoDB کے لیے کیوں اہم ہے؟ کیونکہ یہ آپ کو وقت کے ایک خاص موڑ پر کسی قسم کے بیک اپ ریستوراں بنانے کی اجازت دیتا ہے، یعنی ایونٹ کو وقت کے حساب سے ترتیب دیا جاتا ہے۔ جب کچھ واقعات کی ضرورت ہو تو یہ ضروری ہے۔ ڈیٹا بیس کے لیے، واقعات ڈیٹابیس میں ہونے والی تبدیلیاں ہیں جو وقت کے کچھ وقفوں پر ہوتی ہیں۔
میں صرف آپ کو سب سے اہم وجہ بتاؤں گا (براہ کرم، کسی کو مت بتائیں)! ہم نے ایسا اس لیے کیا کیونکہ منگو ڈی بی اوپلاگ میں منظم، انڈیکسڈ ڈیٹا ایسا ہی لگتا ہے۔ OpLog ایک ڈیٹا ڈھانچہ ہے جو ڈیٹا بیس میں بالکل تمام تبدیلیوں پر مشتمل ہے: وہ سب سے پہلے OpLog پر جاتے ہیں، اور پھر جب یہ نقل کی گئی تاریخ یا شارڈ ہوتی ہے تو وہ خود سٹوریج پر لاگو ہوتے ہیں۔
یہ بنیادی وجہ تھی۔ پھر بھی، ڈیٹا بیس تیار کرنے کے لیے عملی تقاضے بھی ہیں، جس کا مطلب ہے کہ یہ سادہ ہونا چاہیے - چھوٹا کوڈ، جتنا ممکن ہو کچھ ٹوٹی ہوئی چیزیں جنہیں دوبارہ لکھنے اور جانچنے کی ضرورت ہے۔ حقیقت یہ ہے کہ ہمارے اوپلاگس کو ہائبرڈ گھڑیوں کے ذریعہ ترتیب دیا گیا تھا اس نے بہت مدد کی اور ہمیں صحیح انتخاب کرنے کی اجازت دی۔ اس نے واقعی ادائیگی کی اور کسی نہ کسی طرح جادوئی طور پر پہلے ہی پروٹو ٹائپ پر کام کیا۔ یہ بہت ٹھنڈا تھا!
گھڑی کی مطابقت پذیری۔
سائنسی ادب میں ہم آہنگی کے کئی طریقے بیان کیے گئے ہیں۔ میں ہم وقت سازی کے بارے میں بات کر رہا ہوں جب ہمارے پاس دو مختلف شارڈ ہوتے ہیں۔ اگر ایک ریپلیکا سیٹ ہے، تو کسی بھی ہم آہنگی کی ضرورت نہیں ہے: یہ ایک "سنگل ماسٹر" ہے۔ ہمارے پاس ایک OpLog ہے، جس میں تمام تبدیلیاں آتی ہیں - اس صورت میں، سب کچھ پہلے سے ہی "Oplog" میں ترتیب سے ترتیب دیا گیا ہے۔ لیکن اگر ہمارے پاس دو مختلف شارڈز ہیں، تو وقت کی ہم آہنگی یہاں اہم ہے۔ یہ وہ جگہ ہے جہاں ویکٹر گھڑی نے زیادہ مدد کی! لیکن ہمارے پاس وہ نہیں ہیں۔
دوسرا موزوں ہے - یہ "دل کی دھڑکن" ہے۔ کچھ سگنلز کا تبادلہ ممکن ہے جو وقت کی ہر اکائی میں ہوتا ہے۔ لیکن دل کی دھڑکنیں بہت سست ہیں، ہم اپنے مؤکل کو تاخیر فراہم نہیں کر سکتے۔
سچا وقت یقیناً ایک شاندار چیز ہے۔ لیکن، ایک بار پھر، یہ شاید مستقبل ہے... اگرچہ یہ پہلے سے ہی اٹلس میں کیا جا سکتا ہے، وہاں پہلے سے ہی تیز رفتار "ایمیزون" ٹائم سنکرونائزر موجود ہیں۔ لیکن یہ سب کے لیے دستیاب نہیں ہوگا۔
گپ شپ تب ہوتی ہے جب تمام پیغامات میں وقت شامل ہوتا ہے۔ یہ تقریباً وہی ہے جو ہم استعمال کرتے ہیں۔ نوڈس، ڈرائیور، ڈیٹا نوڈ روٹر کے درمیان ہر پیغام، MongoDB کے لیے بالکل ہر چیز کسی نہ کسی قسم کا عنصر ہے، ایک ڈیٹا بیس کا جزو جس میں ایک گھڑی ہوتی ہے جو چلتی ہے۔ ان کے پاس ہر جگہ ہائبرڈ ٹائم کا مطلب ہے، یہ منتقل ہوتا ہے۔ 64 بٹس؟ یہ اجازت دیتا ہے، یہ ممکن ہے.
یہ سب ایک ساتھ کیسے کام کرتا ہے؟
یہاں میں اسے تھوڑا آسان بنانے کے لیے ایک ریپلیکا سیٹ دیکھ رہا ہوں۔ پرائمری اور سیکنڈری ہیں۔ سیکنڈری نقل تیار کرتا ہے اور ہمیشہ پرائمری کے ساتھ مکمل طور پر ہم آہنگ نہیں ہوتا ہے۔
ایک اندراج "پرائمری" میں ایک مخصوص وقت کی قدر کے ساتھ ہوتا ہے۔ اگر یہ زیادہ سے زیادہ ہے تو اس داخل سے داخلی تعداد میں 11 کا اضافہ ہوتا ہے۔ یا یہ گھڑی کی قدروں کو چیک کرے گا اور گھڑی کے ساتھ مطابقت پذیری کرے گا اگر گھڑی کی قدریں زیادہ ہیں۔ یہ آپ کو وقت کے مطابق ترتیب دینے کی اجازت دیتا ہے۔
ریکارڈنگ کرنے کے بعد، ایک اہم لمحہ ہوتا ہے۔ گھڑی "MongoDB" میں ہے اور صرف "Oplog" پر لکھنے کی صورت میں اضافہ کیا جاتا ہے۔ یہ وہ واقعہ ہے جو نظام کی حالت بدل دیتا ہے۔ بالکل تمام کلاسک مضامین میں، ایک واقعہ اس وقت سمجھا جاتا ہے جب کوئی پیغام نوڈ سے ٹکراتا ہے: پیغام آ گیا ہے، جس کا مطلب ہے کہ نظام نے اپنی حالت بدل دی ہے۔
یہ اس حقیقت کی وجہ سے ہے کہ تحقیق کے دوران یہ مکمل طور پر واضح نہیں ہے کہ اس پیغام کی تشریح کیسے کی جائے گی۔ ہم یقینی طور پر جانتے ہیں کہ اگر یہ "Oplog" میں ظاہر نہیں ہوتا ہے، تو اس کی کسی بھی طرح تشریح نہیں کی جائے گی، اور نظام کی حالت میں تبدیلی صرف "Oplog" میں ایک اندراج ہے۔ یہ ہمارے لیے ہر چیز کو آسان بناتا ہے: ماڈل اسے آسان بناتا ہے، اور ہمیں اسے ایک ریپلیکا سیٹ اور بہت سی دوسری مفید چیزوں کے اندر منظم کرنے کی اجازت دیتا ہے۔
وہ قدر جو پہلے سے "Oplog" پر لکھی ہوئی ہے واپس کر دی جاتی ہے - ہم جانتے ہیں کہ "Oplog" میں یہ قدر پہلے سے موجود ہے، اور اس کا وقت 12 ہے۔ اب کہہ لیں، پڑھنا ایک اور نوڈ (سیکنڈری) سے شروع ہوتا ہے، اور یہ کلسٹر ٹائم کے بعد منتقل ہوتا ہے۔ پیغام. وہ کہتے ہیں: "مجھے ہر وہ چیز درکار ہے جو کم از کم 12 کے بعد یا بارہ کے دوران ہوا" (اوپر تصویر دیکھیں)۔
اسی کو Causal a consistent (CAT) کہا جاتا ہے۔ نظریہ میں ایسا تصور ہے کہ یہ وقت کا کچھ ٹکڑا ہے، جو اپنے آپ میں مطابقت رکھتا ہے۔ اس صورت میں، ہم کہہ سکتے ہیں کہ یہ اس نظام کی حالت ہے جو 12 کے وقت دیکھی گئی تھی۔
اب یہاں ابھی کچھ بھی نہیں ہے، کیونکہ اس قسم کی صورت حال کی تقلید اس وقت ہوتی ہے جب آپ کو پرائمری سے ڈیٹا نقل کرنے کے لیے سیکنڈری کی ضرورت ہوتی ہے۔ وہ انتظار کرتا ہے ... اور اب ڈیٹا آ گیا ہے - وہ ان اقدار کو واپس کرتا ہے۔
یہ بہت زیادہ ہے کہ یہ سب کیسے کام کرتا ہے۔ تقریبا.
"تقریبا" کا کیا مطلب ہے؟ آئیے مان لیں کہ کوئی ایسا شخص ہے جس نے پڑھا اور سمجھا ہے کہ یہ سب کیسے کام کرتا ہے۔ میں نے محسوس کیا کہ جب بھی کلسٹر ٹائم ہوتا ہے، یہ اندرونی منطقی گھڑی کو اپ ڈیٹ کرتا ہے، اور پھر اگلی اندراج ایک سے بڑھ جاتی ہے۔ اس فنکشن میں 20 لائنیں لگتی ہیں۔ فرض کریں کہ یہ شخص سب سے بڑا 64 بٹ نمبر، مائنس ون منتقل کرتا ہے۔
’’مائنس ون‘‘ کیوں؟ کیونکہ اندرونی گھڑی کو اس قدر میں بدل دیا جائے گا (ظاہر ہے کہ یہ موجودہ وقت سے سب سے بڑا ممکنہ اور بڑا ہے)، پھر "اوپلاگ" میں ایک اندراج ہو گا، اور گھڑی کو ایک اور یونٹ کے ذریعے بڑھایا جائے گا - اور وہاں پہلے سے ہی زیادہ سے زیادہ قدر ہو (بس تمام اکائیاں ہیں، جانے کے لیے کہیں اور نہیں ہے) , unsaint ints)۔
یہ واضح ہے کہ اس کے بعد یہ نظام کسی بھی چیز کے لیے بالکل ناقابل رسائی ہو جاتا ہے۔ اسے صرف اتارا اور صاف کیا جا سکتا ہے - بہت زیادہ دستی کام۔ مکمل دستیابی:
مزید یہ کہ اگر اسے کہیں اور نقل کیا جاتا ہے، تو پورا کلسٹر نیچے گر جاتا ہے۔ ایک بالکل ناقابل قبول صورتحال جسے کوئی بھی بہت جلد اور آسانی سے ترتیب دے سکتا ہے! لہذا، ہم نے اس لمحے کو سب سے اہم سمجھا۔ اسے کیسے روکا جائے؟
ہمارا طریقہ کلسٹر ٹائم پر دستخط کرنا ہے۔
اس طرح یہ پیغام میں منتقل ہوتا ہے (نیلے متن سے پہلے)۔ لیکن ہم نے ایک دستخط (نیلا متن) بھی بنانا شروع کیا:
دستخط ایک کلید کے ذریعہ تیار کیا جاتا ہے جو ڈیٹا بیس کے اندر، ایک محفوظ دائرے کے اندر محفوظ ہوتا ہے۔ خود تیار اور اپ ڈیٹ ہوتا ہے (صارفین کو اس کے بارے میں کچھ نظر نہیں آتا)۔ ایک ہیش تیار کی جاتی ہے، اور ہر پیغام پر دستخط کیے جاتے ہیں جب بنائے جاتے ہیں اور موصول ہونے پر اس کی تصدیق کی جاتی ہے۔
یہ سوال شاید لوگوں کے ذہنوں میں ابھرتا ہے: "یہ چیزوں کو کتنا سست کرتا ہے؟" میں نے آپ کو بتایا کہ اسے تیزی سے کام کرنا چاہیے، خاص طور پر اس خصوصیت کی عدم موجودگی میں۔
اس معاملے میں Causal consistency استعمال کرنے کا کیا مطلب ہے؟ یہ آفٹر کلسٹر ٹائم پیرامیٹر کو ظاہر کرنا ہے۔ اس کے بغیر، یہ بہرحال قدروں کو آسانی سے پاس کرے گا۔ گپ شپ، ورژن 3.6 سے شروع ہوتی ہے، ہمیشہ کام کرتی ہے۔
اگر ہم دستخطوں کی مستقل نسل کو چھوڑ دیتے ہیں، تو یہ ایک خصوصیت کی عدم موجودگی میں بھی نظام کو سست کر دے گا، جو ہمارے نقطہ نظر اور ضروریات کو پورا نہیں کرتا ہے۔ تو ہم نے کیا کیا؟
جلدی کرو!
یہ کافی آسان چیز ہے، لیکن چال دلچسپ ہے - میں اسے شیئر کروں گا، شاید کسی کو دلچسپی ہو۔
ہمارے پاس ایک ہیش ہے جو دستخط شدہ ڈیٹا کو محفوظ کرتا ہے۔ تمام ڈیٹا کیشے سے گزرتا ہے۔ کیش مخصوص وقت پر دستخط نہیں کرتا ہے، لیکن حد. جب کچھ قدر آتی ہے، ہم ایک رینج تیار کرتے ہیں، آخری 16 بٹس کو ماسک کرتے ہیں، اور ہم اس قدر پر دستخط کرتے ہیں:
اس طرح کے دستخط حاصل کرنے سے، ہم سسٹم کو (نسبتاً) 65 ہزار گنا تیز کر دیتے ہیں۔ یہ بہت اچھا کام کرتا ہے: جب ہم نے تجربات کیے، تو وقت درحقیقت 10 ہزار گنا کم ہوا جب ہمارے پاس ایک ترتیب وار اپ ڈیٹ تھا۔ یہ واضح ہے کہ جب وہ اختلاف کرتے ہیں تو یہ کام نہیں کرتا۔ لیکن زیادہ تر عملی معاملات میں یہ کام کرتا ہے۔ دستخط کے ساتھ رینج دستخط کے امتزاج نے سیکیورٹی کا مسئلہ حل کردیا۔
ہم نے کیا سیکھا ہے؟
اس سے ہم نے سبق سیکھا:
- ہمیں مواد، کہانیاں، مضامین پڑھنے کی ضرورت ہے، کیونکہ ہمارے پاس بہت سی دلچسپ چیزیں ہیں۔ جب ہم کسی خصوصیت پر کام کرتے ہیں (خاص طور پر اب، جب ہم لین دین کرتے تھے، وغیرہ)، تو ہمیں پڑھنے اور سمجھنے کی ضرورت ہوتی ہے۔ اس میں وقت لگتا ہے، لیکن یہ حقیقت میں بہت مفید ہے کیونکہ یہ واضح کرتا ہے کہ ہم کہاں ہیں۔ ایسا لگتا ہے کہ ہم کوئی نئی چیز لے کر نہیں آئے - ہم نے صرف اجزاء لیے۔
عام طور پر، جب کوئی تعلیمی کانفرنس ہوتی ہے تو سوچ میں ایک خاص فرق ہوتا ہے (مثال کے طور پر سگمن) - ہر کوئی نئے آئیڈیاز پر توجہ مرکوز کرتا ہے۔ ہمارے الگورتھم کے بارے میں کیا نیا ہے؟ یہاں کوئی خاص نئی بات نہیں ہے۔ نیاپن اس بات میں ہے کہ ہم نے موجودہ نقطہ نظر کو ایک ساتھ ملایا۔ لہذا، پہلی چیز کلاسیکی کو پڑھنا ہے، جس کا آغاز لیمپارٹ سے ہوتا ہے۔
- پیداوار میں، ضروریات بالکل مختلف ہیں. مجھے یقین ہے کہ آپ میں سے بہت سے لوگوں کو ایک تجریدی خلا میں "کروی" ڈیٹا بیس کا سامنا نہیں ہے، لیکن عام، حقیقی چیزوں کے ساتھ جن کی دستیابی، تاخیر اور غلطی کو برداشت کرنے میں مسائل ہیں۔
- آخری بات یہ ہے کہ ہمیں مختلف نظریات کو دیکھنا تھا اور کئی مکمل طور پر مختلف مضامین کو ایک ساتھ ملانا تھا۔ دستخط کرنے کا خیال، مثال کے طور پر، عام طور پر ایک مضمون سے آیا جس میں Paxos پروٹوکول پر غور کیا گیا، جو کہ غیر بازنطینی فیلرز کے لیے اجازت پروٹوکول کے اندر ہے، بازنطینی والوں کے لیے - اجازت کے پروٹوکول سے باہر... عام طور پر، یہ بالکل وہی ہے جو ہم کرنا ختم ہو گیا.
یہاں بالکل نیا نہیں ہے! لیکن جیسے ہی ہم نے ان سب کو ملایا... یہ بالکل ایسا ہی ہے جیسے کہ اولیویر سلاد کی ترکیب بکواس ہے، کیونکہ انڈے، مایونیز اور کھیرے پہلے ہی ایجاد ہو چکے ہیں... یہ ایک ہی کہانی کے بارے میں ہے۔
میں اس کے ساتھ ختم کروں گا۔ شکریہ!
آپ کے سوالات
سامعین سے سوال (اس کے بعد ب کے طور پر حوالہ دیا گیا): - آپ کا شکریہ، میخائل، رپورٹ کے لیے! وقت کا موضوع دلچسپ ہے۔ آپ گپ شپ استعمال کر رہے ہیں۔ ان کا کہنا تھا کہ ہر کسی کا اپنا وقت ہوتا ہے، ہر کسی کو اپنا مقامی وقت معلوم ہوتا ہے۔ جیسا کہ میں اسے سمجھتا ہوں، ہمارے پاس ایک ڈرائیور ہے - ڈرائیوروں کے ساتھ بہت سے کلائنٹ بھی ہو سکتے ہیں، سوالات کے منصوبہ ساز بھی، شارڈز بھی... اور اگر ہمارے ہاں اچانک کوئی تضاد ہو جائے تو سسٹم کیا نیچے آتا ہے: کوئی فیصلہ کرتا ہے کہ یہ کسی کے لیے ہے ایک منٹ آگے، کوئی ایک منٹ پیچھے؟ آخر ہم کہاں جائیں گے؟
MT: - واقعی بہت اچھا سوال! میں صرف شارڈز کے بارے میں بات کرنا چاہتا تھا۔ اگر میں سوال کو صحیح طریقے سے سمجھتا ہوں، تو ہمارے پاس درج ذیل صورت حال ہے: شارڈ 1 اور شارڈ 2 ہے، ان دونوں شارڈز سے پڑھنا ہوتا ہے - ان میں تضاد ہے، وہ ایک دوسرے کے ساتھ تعامل نہیں کرتے، کیونکہ وہ جو وقت جانتے ہیں وہ مختلف ہے، خاص طور پر وہ وقت جب وہ oplogs میں موجود ہوتے ہیں۔
فرض کریں کہ شارڈ 1 نے ایک ملین ریکارڈ بنائے، شارڈ 2 نے کچھ بھی نہیں کیا، اور درخواست دو شارڈز پر آئی۔ اور پہلے والے کا آفٹر کلسٹر ٹائم ایک ملین سے زیادہ ہے۔ ایسی صورت حال میں، جیسا کہ میں نے وضاحت کی، شارڈ 2 کبھی بھی جواب نہیں دے گا۔
پر: - میں جاننا چاہتا تھا کہ وہ کس طرح مطابقت پذیر ہوتے ہیں اور ایک منطقی وقت کا انتخاب کرتے ہیں؟
MT: - مطابقت پذیری کرنا بہت آسان ہے۔ شارڈ، جب کلسٹر ٹائم کے بعد اس کے پاس آتا ہے اور اسے "اوپلاگ" میں وقت نہیں ملتا ہے، کوئی منظور شدہ آغاز نہیں کرتا ہے۔ یعنی وہ اپنے ہاتھوں سے اپنے وقت کو اس قدر کی طرف بڑھاتا ہے۔ اس کا مطلب ہے کہ اس میں اس درخواست سے مماثل کوئی واقعات نہیں ہیں۔ وہ اس واقعہ کو مصنوعی طور پر تخلیق کرتا ہے اور اس طرح Causal Consistent بن جاتا ہے۔
پر: - اگر اس کے بعد کچھ اور واقعات اس کے سامنے آجائیں جو نیٹ ورک میں کہیں گم ہو گئے تھے؟
MT: - شارڈ کو اس طرح ڈیزائن کیا گیا ہے کہ وہ دوبارہ نہیں آئیں گے، کیونکہ یہ ایک ہی ماسٹر ہے۔ اگر اس نے پہلے ہی سائن اپ کیا ہے، تو وہ نہیں آئیں گے، لیکن بعد میں آئیں گے۔ ایسا نہیں ہو سکتا کہ کوئی چیز کہیں پھنس جائے، پھر وہ کچھ نہ لکھے، اور پھر یہ واقعات آ جائیں - اور Causal مستقل مزاجی ٹوٹ جائے۔ جب وہ کچھ نہیں لکھتا ہے تو ان سب کو آگے آنا چاہئے (وہ ان کا انتظار کرے گا)۔
پر: - میرے پاس قطاروں کے حوالے سے کئی سوالات ہیں۔ Causal مستقل مزاجی فرض کرتی ہے کہ اعمال کی ایک مخصوص قطار ہے جسے انجام دینے کی ضرورت ہے۔ اگر ہمارا ایک پیکج غائب ہو جائے تو کیا ہوگا؟ یہ ہے 10ویں، 11ویں... 12ویں غائب ہو گئی ہے، اور باقی سب اس کے سچ ہونے کا انتظار کر رہے ہیں۔ اور اچانک ہماری گاڑی مر گئی، ہم کچھ نہیں کر سکتے۔ کیا قطار کی زیادہ سے زیادہ لمبائی ہے جو عمل درآمد سے پہلے جمع ہو جاتی ہے؟ جب کوئی ایک ریاست کھو جاتی ہے تو کون سی مہلک ناکامی ہوتی ہے؟ مزید یہ کہ اگر ہم یہ لکھ لیں کہ کوئی سابقہ حالت ہے تو ہمیں کسی نہ کسی طرح اس سے آغاز کرنا چاہیے؟ لیکن انہوں نے اسے دور نہیں کیا!
MT: - ایک بہت اچھا سوال بھی! ہم کیا کر رہے ہیں؟ MongoDB میں کورم رائٹ، کورم ریڈز کا تصور ہے۔ کن صورتوں میں پیغام ضائع ہو سکتا ہے؟ جب تحریر کا کورم نہ ہو یا جب پڑھنے کا کورم نہ ہو (کچھ قسم کا کوڑا بھی چپک سکتا ہے)۔
Causal consistency کے حوالے سے ایک بڑا تجرباتی ٹیسٹ کیا گیا جس کا نتیجہ یہ نکلا کہ جب لکھنا اور پڑھنا کورم نہیں ہے تو Causal consistency کی خلاف ورزی ہوتی ہے۔ بالکل وہی جو آپ کہتے ہیں!
ہمارا مشورہ: Causal consistency استعمال کرتے وقت کم از کم کورم ریڈنگ کا استعمال کریں۔ اس صورت میں، کچھ بھی ضائع نہیں ہوگا، چاہے کورم ریکارڈ کھو جائے... یہ ایک آرتھوگونل صورتحال ہے: اگر صارف نہیں چاہتا کہ ڈیٹا ضائع ہو، تو اسے کورم ریکارڈ استعمال کرنے کی ضرورت ہے۔ وجہ مستقل مزاجی پائیداری کی ضمانت نہیں دیتی۔ نقل اور نقل سے وابستہ مشینری کے ذریعے استحکام کی ضمانت دی جاتی ہے۔
پر: - جب ہم کوئی ایسی مثال بناتے ہیں جو ہمارے لیے شارڈنگ کرتا ہے (بالترتیب مالک نہیں، بلکہ غلام)، یہ اپنی مشین کے یونکس ٹائم یا "ماسٹر" کے وقت پر انحصار کرتا ہے۔ کیا یہ پہلی بار یا وقتاً فوقتاً مطابقت پذیر ہوتا ہے؟
MT: - میں ابھی واضح کروں گا۔ شارڈ (یعنی افقی تقسیم) - وہاں ہمیشہ ایک بنیادی ہوتا ہے۔ اور ایک شارڈ میں "ماسٹر" ہوسکتا ہے اور اس کی نقلیں ہوسکتی ہیں۔ لیکن شارڈ ہمیشہ ریکارڈنگ کو سپورٹ کرتا ہے، کیونکہ اسے کچھ ڈومین کو سپورٹ کرنا چاہیے (شارڈ میں پرائمری ہے)۔
پر: - تو سب کچھ مکمل طور پر "ماسٹر" پر منحصر ہے؟ کیا ماسٹر ٹائم ہمیشہ استعمال ہوتا ہے؟
MT: - جی ہاں. آپ علامتی طور پر کہہ سکتے ہیں: گھڑی ٹک ٹک کر رہی ہے جب "ماسٹر" میں، "اوپلاگ" میں داخلہ ہوتا ہے۔
پر: - ہمارے پاس ایک کلائنٹ ہے جو جڑتا ہے اور اسے وقت کے بارے میں کچھ جاننے کی ضرورت نہیں ہے؟
MT: - آپ کو کچھ بھی جاننے کی ضرورت نہیں ہے! اگر ہم اس کے بارے میں بات کرتے ہیں کہ یہ کلائنٹ پر کیسے کام کرتا ہے: جب کلائنٹ Causal consistency استعمال کرنا چاہتا ہے، تو اسے ایک سیشن کھولنے کی ضرورت ہوتی ہے۔ اب سب کچھ موجود ہے: سیشن میں لین دین، اور حقوق کی بازیافت... ایک سیشن کلائنٹ کے ساتھ پیش آنے والے منطقی واقعات کی ترتیب ہے۔
اگر وہ اس سیشن کو کھولتا ہے اور وہاں کہتا ہے کہ وہ Causal consistency چاہتا ہے (اگر سیشن بطور ڈیفالٹ Causal consistency کو سپورٹ کرتا ہے) تو سب کچھ خود بخود کام کرتا ہے۔ ڈرائیور اس وقت کو یاد رکھتا ہے اور جب اسے نیا پیغام ملتا ہے تو اسے بڑھاتا ہے۔ یہ یاد رکھتا ہے کہ ڈیٹا واپس کرنے والے سرور سے پچھلے والے نے کیا جواب دیا تھا۔ اگلی درخواست afterCluster پر مشتمل ہوگی ("اس سے زیادہ وقت")۔
کلائنٹ کو بالکل کچھ جاننے کی ضرورت نہیں ہے! یہ اس کے لیے بالکل مبہم ہے۔ اگر لوگ ان خصوصیات کو استعمال کرتے ہیں، تو وہ کیا کر سکتے ہیں؟ سب سے پہلے، آپ ثانوی کو محفوظ طریقے سے پڑھ سکتے ہیں: آپ پرائمری کو لکھ سکتے ہیں اور جغرافیائی طور پر نقل شدہ سیکنڈری سے پڑھ سکتے ہیں اور یقینی بنائیں کہ یہ کام کرتا ہے۔ ایک ہی وقت میں، پرائمری پر ریکارڈ کیے گئے سیشنز کو سیکنڈری میں بھی منتقل کیا جا سکتا ہے، یعنی آپ ایک نہیں بلکہ کئی سیشن استعمال کر سکتے ہیں۔
پر: – کمپیوٹ سائنس کی ایک نئی پرت – CRDT (تصادم سے پاک نقل شدہ ڈیٹا کی قسمیں) ڈیٹا کی اقسام – کا تعلق حتمی مستقل مزاجی کے موضوع سے ہے۔ کیا آپ نے اس قسم کے ڈیٹا کو ڈیٹا بیس میں ضم کرنے پر غور کیا ہے اور آپ اس کے بارے میں کیا کہہ سکتے ہیں؟
MT: - اچھا سوال! CRDT تحریری تنازعات کو سمجھتا ہے: MongoDB میں، سنگل ماسٹر۔
پر: - میرا ڈیوپس سے ایک سوال ہے۔ حقیقی دنیا میں، ایسے Jesuitical حالات ہوتے ہیں جب بازنطینی ناکامی واقع ہوتی ہے، اور محفوظ دائرے کے اندر برے لوگ پروٹوکول میں گھسنا شروع کر دیتے ہیں، ایک خاص طریقے سے کرافٹ پیکج بھیجتے ہیں؟
MT: - دائرہ کے اندر برے لوگ ٹروجن ہارس کی طرح ہیں! دائرے کے اندر برے لوگ بہت سی برائیاں کر سکتے ہیں۔
پر: - یہ واضح ہے کہ سرور میں ایک سوراخ چھوڑنا، جس کے ذریعے آپ ہاتھیوں کا چڑیا گھر ڈال سکتے ہیں اور پورے جھرمٹ کو ہمیشہ کے لیے گرا سکتے ہیں... دستی بحالی میں وقت لگے گا... اسے ہلکے سے کہنا، یہ ہے غلط. دوسری طرف، یہ دلچسپ ہے: حقیقی زندگی میں، عملی طور پر، ایسے حالات ہیں جب قدرتی طور پر اسی طرح کے اندرونی حملے ہوتے ہیں؟
MT: - چونکہ مجھے حقیقی زندگی میں سیکیورٹی کی خلاف ورزیوں کا شاذ و نادر ہی سامنا ہوتا ہے، اس لیے میں یہ نہیں کہہ سکتا کہ آیا وہ ہوتی ہیں۔ لیکن اگر ہم ترقی کے فلسفے کے بارے میں بات کریں تو ہم اس طرح سوچتے ہیں: ہمارے پاس ایک دائرہ ہے جو لوگوں کو تحفظ فراہم کرتا ہے - یہ ایک قلعہ ہے، ایک دیوار ہے۔ اور فریم کے اندر آپ جو چاہیں کر سکتے ہیں۔ یہ واضح ہے کہ صرف دیکھنے کی صلاحیت رکھنے والے صارفین ہیں، اور ایسے صارفین ہیں جن کے پاس ڈائریکٹری کو مٹانے کی صلاحیت ہے۔
حقوق پر منحصر ہے، صارف جو نقصان پہنچا سکتا ہے وہ چوہا ہو سکتا ہے، یا یہ ہاتھی ہو سکتا ہے۔ یہ واضح ہے کہ مکمل حقوق کا حامل صارف کچھ بھی کر سکتا ہے۔ محدود حقوق والا صارف نمایاں طور پر کم نقصان پہنچا سکتا ہے۔ خاص طور پر یہ نظام کو نہیں توڑ سکتا۔
پر: – محفوظ دائرے میں، کسی نے سرور کو مکمل طور پر تباہ کرنے کے لیے سرور کے لیے غیر متوقع پروٹوکول بنانے کی کوشش کی، اور اگر آپ خوش قسمت ہیں، تو پورا کلسٹر... کیا یہ کبھی بھی "اچھا" ملتا ہے؟
MT: "میں نے ایسی چیزوں کے بارے میں کبھی نہیں سنا۔" حقیقت یہ ہے کہ آپ اس طرح سرور کو کریش کر سکتے ہیں کوئی راز نہیں ہے۔ اندر سے ناکام، پروٹوکول سے ہونے کی وجہ سے، ایک مجاز صارف ہونے کے ناطے جو پیغام میں کچھ ایسا لکھ سکتا ہے... درحقیقت، یہ ناممکن ہے، کیونکہ اس کی تصدیق ہو جائے گی۔ اس تصدیق کو غیر فعال کرنا ان صارفین کے لیے ممکن ہے جو یہ نہیں چاہتے ہیں - پھر یہ ان کا مسئلہ ہے۔ انہوں نے، موٹے طور پر، دیواروں کو خود ہی تباہ کر دیا اور آپ وہاں ایک ہاتھی کو دھکیل سکتے ہیں، جو روند جائے گا... لیکن عام طور پر، آپ مرمت کرنے والے کے طور پر تیار ہو سکتے ہیں، آ کر اسے باہر نکال سکتے ہیں!
پر: - رپورٹ کے لیے شکریہ۔ سرجی (Yandex). مونگ میں ایک مستقل ہے جو ریپلیکا سیٹ میں ووٹنگ ممبران کی تعداد کو محدود کرتا ہے، اور یہ مستقل 7 (سات) ہے۔ یہ مستقل کیوں ہے؟ یہ کسی قسم کا پیرامیٹر کیوں نہیں ہے؟
MT: - ہمارے پاس 40 نوڈس کے ساتھ ریپلیکا سیٹ ہیں۔ ہمیشہ اکثریت ہوتی ہے۔ مجھے نہیں معلوم کہ کون سا ورژن...
پر: – ریپلیکا سیٹ میں آپ نان ووٹنگ ممبرز چلا سکتے ہیں، لیکن زیادہ سے زیادہ 7 ووٹنگ ممبرز ہوتے ہیں۔ اگر ہمارا ریپلیکا سیٹ 3 ڈیٹا سینٹرز میں پھیلا ہوا ہے تو اس صورت میں ہم شٹ ڈاؤن سے کیسے بچ سکتے ہیں؟ ایک ڈیٹا سینٹر آسانی سے بند ہوسکتا ہے، اور دوسری مشین گر سکتی ہے۔
MT: - یہ پہلے ہی رپورٹ کے دائرہ کار سے تھوڑا سا باہر ہے۔ یہ ایک عمومی سوال ہے۔ شاید میں آپ کو اس کے بارے میں بعد میں بتا سکوں۔
کچھ اشتہارات 🙂
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔
ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا
ماخذ: www.habr.com