بروس مومجیان کی 2020 ٹاک کا ٹرانسکرپٹ "پوسٹگریس لاک مینیجر کو کھولنا"۔
(نوٹ: سلائیڈز سے تمام SQL سوالات اس لنک سے حاصل کیے جا سکتے ہیں: )
ہیلو! یہاں روس میں دوبارہ آنا بہت اچھا ہے۔ مجھے افسوس ہے کہ میں پچھلے سال نہیں آ سکا، لیکن اس سال آئیون اور میرے پاس بڑے منصوبے ہیں۔ مجھے یہاں زیادہ کثرت سے آنے کی امید ہے۔ مجھے روس آنا اچھا لگتا ہے۔ میں Tyumen، Tver کا دورہ کروں گا. مجھے بہت خوشی ہے کہ میں ان شہروں کا دورہ کر سکوں گا۔
میرا نام بروس موجیان ہے۔ میں انٹرپرائز ڈی بی میں کام کرتا ہوں اور 23 سال سے پوسٹگریس کے ساتھ کام کر رہا ہوں۔ میں فلاڈیلفیا، امریکہ میں رہتا ہوں۔ میں سال میں تقریباً 90 دن سفر کرتا ہوں۔ اور میں تقریباً 40 کانفرنسوں میں شرکت کرتا ہوں۔ میرا ، جس میں وہ سلائیڈز ہیں جو اب میں آپ کو دکھاؤں گا۔ لہذا، کانفرنس کے بعد آپ انہیں میری ذاتی ویب سائٹ سے ڈاؤن لوڈ کر سکتے ہیں۔ اس میں تقریباً 30 پیشکشیں بھی شامل ہیں۔ ویڈیوز اور بلاگ اندراجات کی ایک بڑی تعداد بھی موجود ہے، 500 سے زیادہ۔ یہ کافی معلوماتی وسیلہ ہے۔ اور اگر آپ اس مواد میں دلچسپی رکھتے ہیں، تو میں آپ کو اسے استعمال کرنے کی دعوت دیتا ہوں۔
پوسٹگریس کے ساتھ کام شروع کرنے سے پہلے میں ایک استاد، پروفیسر ہوا کرتا تھا۔ اور میں بہت خوش ہوں کہ اب میں آپ کو وہ بتانے کے قابل ہوں گا جو میں آپ کو بتانے والا ہوں۔ یہ میری سب سے دلچسپ پیشکشوں میں سے ایک ہے۔ اور یہ پیشکش 110 سلائیڈوں پر مشتمل ہے۔ ہم سادہ باتوں سے بات شروع کریں گے، اور آخر تک رپورٹ مزید پیچیدہ ہوتی جائے گی، اور کافی پیچیدہ ہو جائے گی۔
یہ ایک ناخوشگوار گفتگو ہے۔ بلاک کرنا سب سے زیادہ مقبول موضوع نہیں ہے۔ ہم چاہتے ہیں کہ یہ کہیں غائب ہو جائے۔ یہ دانتوں کے ڈاکٹر کے پاس جانے جیسا ہے۔
- لاک کرنا بہت سارے لوگوں کے لئے ایک مسئلہ ہے جو ڈیٹا بیس میں کام کرتے ہیں اور ایک ہی وقت میں متعدد عمل چل رہے ہیں۔ انہیں بلاک کرنے کی ضرورت ہے۔ یعنی آج میں آپ کو بلاکنگ پر بنیادی معلومات دوں گا۔
- ٹرانزیکشن IDs یہ پیشکش کا ایک بورنگ حصہ ہے، لیکن انہیں سمجھنے کی ضرورت ہے۔
- آگے ہم بلاکنگ کی اقسام کے بارے میں بات کریں گے۔ یہ کافی مکینیکل حصہ ہے۔
- اور ذیل میں ہم بلاک کرنے کی کچھ مثالیں دیں گے۔ اور اسے سمجھنا کافی مشکل ہوگا۔
آئیے بلاک کرنے کی بات کرتے ہیں۔
ہماری اصطلاحات کافی پیچیدہ ہیں۔ آپ میں سے کتنے لوگ جانتے ہیں کہ یہ حوالہ کہاں سے آیا ہے؟ دو لوگ. یہ Colossal Cave Adventure نامی گیم سے ہے۔ میرے خیال میں یہ 80 کی دہائی میں ٹیکسٹ پر مبنی کمپیوٹر گیم تھا۔ وہاں آپ کو ایک غار میں، بھولبلییا میں جانا پڑا، اور متن بدل گیا، لیکن مواد ہر بار تقریباً ایک جیسا تھا۔ اس طرح مجھے یہ کھیل یاد ہے۔
اور یہاں ہم ان تالے کا نام دیکھتے ہیں جو اوریکل سے ہمارے پاس آئے تھے۔ ہم انہیں استعمال کرتے ہیں۔
یہاں ہم ایسی اصطلاحات دیکھتے ہیں جو مجھے الجھاتی ہیں۔ مثال کے طور پر، شیئر اپ ڈیٹ ECXLUSIVE۔ اگلا شیئر RAW ECXLUSIVE۔ سچ پوچھیں تو یہ نام زیادہ واضح نہیں ہیں۔ ہم ان پر مزید تفصیل سے غور کرنے کی کوشش کریں گے۔ کچھ میں لفظ "شیئر" ہوتا ہے، جس کا مطلب الگ کرنا ہے۔ کچھ میں لفظ "خصوصی" ہوتا ہے۔ بعض میں یہ دونوں الفاظ ہیں۔ میں شروع کرنا چاہوں گا کہ یہ تالے کیسے کام کرتے ہیں۔
اور لفظ "رسائی" بھی بہت اہم ہے۔ اور الفاظ "صف" ایک تار ہیں۔ یعنی رسائی کی تقسیم، قطار کی تقسیم۔
ایک اور مسئلہ جسے پوسٹگریس میں سمجھنے کی ضرورت ہے، جس کا میں بدقسمتی سے اپنی گفتگو میں احاطہ نہیں کر سکوں گا، وہ ہے MVCC۔ میری ویب سائٹ پر اس موضوع پر ایک الگ پیشکش ہے۔ اور اگر آپ کو لگتا ہے کہ یہ پیشکش مشکل ہے، MVCC شاید میری مشکل ترین ہے۔ اور اگر آپ دلچسپی رکھتے ہیں، تو آپ اسے ویب سائٹ پر دیکھ سکتے ہیں۔ آپ ویڈیو دیکھ سکتے ہیں۔
ایک اور چیز جو ہمیں سمجھنے کی ضرورت ہے وہ ہے ٹرانزیکشن آئی ڈی۔ بہت سے لین دین منفرد شناخت کنندگان کے بغیر کام نہیں کر سکتے۔ اور یہاں ہمارے پاس ایک وضاحت ہے کہ لین دین کیا ہے۔ پوسٹگریس کے پاس دو ٹرانزیکشن نمبرنگ سسٹم ہیں۔ میں جانتا ہوں کہ یہ بہت خوبصورت حل نہیں ہے۔
یہ بھی ذہن میں رکھیں کہ سلائیڈز کو سمجھنا کافی مشکل ہو گا، اس لیے جو چیز سرخ رنگ سے ہائی لائٹ کی گئی ہے اس پر آپ کو توجہ دینے کی ضرورت ہے۔
چلو دیکھتے ہیں. لین دین کا نمبر سرخ رنگ میں نمایاں کیا گیا ہے۔ SELECT pg_back فنکشن یہاں دکھایا گیا ہے۔ یہ میرا ٹرانزیکشن اور ٹرانزیکشن ID واپس کرتا ہے۔
ایک اور بات، اگر آپ کو یہ پریزنٹیشن پسند ہے اور آپ اسے اپنے ڈیٹا بیس پر چلانا چاہتے ہیں، تو آپ گلابی رنگ کے اس لنک پر جا کر اس پریزنٹیشن کے لیے SQL ڈاؤن لوڈ کر سکتے ہیں۔ اور آپ اسے آسانی سے اپنے PSQL میں چلا سکتے ہیں اور پوری پیشکش فوری طور پر آپ کی سکرین پر آجائے گی۔ اس میں پھول نہیں ہوں گے، لیکن کم از کم ہم اسے دیکھ سکتے ہیں۔
اس صورت میں ہم ٹرانزیکشن ID دیکھتے ہیں۔ یہ وہ نمبر ہے جو ہم نے اسے تفویض کیا ہے۔ اور پوسٹگریس میں ایک اور قسم کی ٹرانزیکشن آئی ڈی ہے جسے ورچوئل ٹرانزیکشن آئی ڈی کہتے ہیں۔
اور ہمیں یہ سمجھنا چاہیے۔ یہ بہت اہم ہے، ورنہ ہم پوسٹگریس میں لاکنگ کو نہیں سمجھ پائیں گے۔
ورچوئل ٹرانزیکشن ID ایک ٹرانزیکشن ID ہے جس میں مستقل اقدار نہیں ہوتی ہیں۔ مثال کے طور پر، اگر میں SELECT کمانڈ چلاتا ہوں، تو میں غالباً ڈیٹا بیس کو تبدیل نہیں کروں گا، میں کچھ بھی لاک نہیں کروں گا۔ لہذا جب ہم ایک سادہ SELECT چلاتے ہیں، تو ہم اس لین دین کو ایک مستقل ID نہیں دیتے ہیں۔ ہم اسے وہاں صرف ایک ورچوئل آئی ڈی دیتے ہیں۔
اور یہ پوسٹگریس کی کارکردگی کو بہتر بناتا ہے، صفائی کی صلاحیتوں کو بہتر بناتا ہے، لہذا ورچوئل ٹرانزیکشن ID دو نمبروں پر مشتمل ہوتی ہے۔ سلیش سے پہلے پہلا نمبر بیک اینڈ آئی ڈی ہے۔ اور دائیں طرف ہمیں صرف ایک کاؤنٹر نظر آتا ہے۔
لہذا، اگر میں کوئی درخواست چلاتا ہوں، تو یہ کہتا ہے کہ بیک اینڈ آئی ڈی 2 ہے۔
اور اگر میں اس طرح کے لین دین کا ایک سلسلہ چلاتا ہوں، تو ہم دیکھتے ہیں کہ جب بھی میں کوئی سوال چلاتا ہوں تو کاؤنٹر بڑھتا جاتا ہے۔ مثال کے طور پر، جب میں استفسار 2/10، 2/11، 2/12، وغیرہ چلاتا ہوں۔
یاد رہے کہ یہاں دو کالم ہیں۔ بائیں طرف ہم ورچوئل ٹرانزیکشن ID - 2/12 دیکھتے ہیں۔ اور دائیں طرف ہمارے پاس ایک مستقل ٹرانزیکشن آئی ڈی ہے۔ اور یہ میدان خالی ہے۔ اور یہ لین دین ڈیٹا بیس میں ترمیم نہیں کرتا ہے۔ اس لیے میں اسے مستقل ٹرانزیکشن آئی ڈی نہیں دیتا۔
جیسے ہی میں analyze کمانڈ ((ANALYZE)) چلاتا ہوں، وہی سوال مجھے ایک مستقل ٹرانزیکشن ID دیتا ہے۔ دیکھو یہ ہمارے لیے کیسے بدل گیا ہے۔ میرے پاس یہ ID پہلے نہیں تھی، لیکن اب میرے پاس ہے۔
تو یہاں ایک اور درخواست ہے، ایک اور لین دین۔ ورچوئل ٹرانزیکشن نمبر 2/13 ہے۔ اور اگر میں مسلسل ٹرانزیکشن آئی ڈی مانگتا ہوں، تو جب میں استفسار کروں گا تو مجھے مل جائے گا۔
تو، ایک بار اور. ہمارے پاس ایک ورچوئل ٹرانزیکشن ID اور ایک مستقل ٹرانزیکشن ID ہے۔ پوسٹگریس کے رویے کو سمجھنے کے لیے صرف اس نکتے کو سمجھیں۔
ہم تیسرے حصے کی طرف بڑھتے ہیں۔ یہاں ہم پوسٹگریس میں مختلف قسم کے تالے سے گزریں گے۔ یہ بہت دلچسپ نہیں ہے۔ آخری حصہ بہت زیادہ دلچسپ ہوگا۔ لیکن ہمیں بنیادی باتوں پر غور کرنا چاہیے، کیونکہ ورنہ ہم سمجھ نہیں پائیں گے کہ آگے کیا ہوگا۔
ہم اس سیکشن کے ذریعے جائیں گے، ہم ہر قسم کے تالے کو دیکھیں گے۔ اور میں آپ کو اس کی مثالیں دکھاؤں گا کہ وہ کیسے انسٹال ہوتے ہیں، وہ کیسے کام کرتے ہیں، میں آپ کو کچھ سوالات دکھاؤں گا جنہیں آپ یہ دیکھنے کے لیے استعمال کر سکتے ہیں کہ پوسٹگریس میں لاکنگ کیسے کام کرتی ہے۔
استفسار بنانے اور یہ دیکھنے کے لیے کہ پوسٹگریس میں کیا ہو رہا ہے، ہمیں سسٹم ویو میں استفسار جاری کرنے کی ضرورت ہے۔ اس صورت میں، pg_lock کو سرخ رنگ میں نمایاں کیا گیا ہے۔ Pg_lock ایک سسٹم ٹیبل ہے جو ہمیں بتاتا ہے کہ پوسٹگریس میں فی الحال کون سے تالے استعمال میں ہیں۔
تاہم، میرے لیے خود آپ کو pg_lock دکھانا بہت مشکل ہے کیونکہ یہ کافی پیچیدہ ہے۔ تو میں نے ایک نظریہ بنایا جو دکھاتا ہے pg_locks. اور یہ میرے لیے کچھ کام بھی کرتا ہے جو مجھے بہتر طور پر سمجھنے کی اجازت دیتا ہے۔ یعنی، اس میں میرے تالے، میرا اپنا سیشن وغیرہ شامل نہیں ہے۔ یہ صرف معیاری SQL ہے اور یہ آپ کو بہتر طریقے سے دکھانے کی اجازت دیتا ہے کہ کیا ہو رہا ہے۔
ایک اور مسئلہ یہ ہے کہ یہ نظارہ بہت وسیع ہے، اس لیے مجھے دوسرا - lockview2 بنانا ہوگا۔
اور یہ مجھے ٹیبل سے مزید کالم دکھاتا ہے۔ اور ایک اور جو مجھے باقی کالم دکھاتا ہے۔ یہ کافی پیچیدہ ہے، اس لیے میں نے اسے ہر ممکن حد تک سادہ انداز میں پیش کرنے کی کوشش کی۔
تو ہم نے ایک ٹیبل بنایا جسے لاک ڈیمو کہتے ہیں۔ اور ہم نے وہاں ایک لائن بنائی۔ یہ ہماری نمونہ کی میز ہے. اور ہم صرف آپ کو تالے کی مثالیں دکھانے کے لیے سیکشنز بنائیں گے۔
تو، ایک قطار، ایک کالم. پہلی قسم کے تالے کو ACCESS SHARE کہا جاتا ہے۔ یہ سب سے کم پابندی والی بلاکنگ ہے۔ اس کا مطلب یہ ہے کہ یہ عملی طور پر دوسرے تالے کے ساتھ متصادم نہیں ہے۔
اور اگر ہم واضح طور پر کسی لاک کی وضاحت کرنا چاہتے ہیں تو ہم "لاک ٹیبل" کمانڈ چلاتے ہیں۔ اور یہ واضح طور پر بلاک ہو جائے گا، یعنی ACCESS SHARE موڈ میں ہم لاک ٹیبل کو لانچ کرتے ہیں۔ اور اگر میں PSQL کو پس منظر میں چلاتا ہوں، تو میں اپنے پہلے سیشن سے دوسرے سیشن کو اس طرح شروع کرتا ہوں۔ یعنی میں یہاں کیا کروں گا؟ میں دوسرے سیشن میں جاتا ہوں اور اسے کہتا ہوں "مجھے اس درخواست کے لیے لاک ویو دکھائیں۔" اور یہاں میرے پاس اس ٹیبل میں ایکسیس شیئر لاک ہے۔ یہ بالکل وہی ہے جو میں نے درخواست کی تھی۔ اور وہ کہتا ہے کہ بلاک تفویض کر دیا گیا ہے۔ بہت آسان.
اس کے علاوہ اگر ہم دوسرے کالم کو دیکھیں تو وہاں کچھ نہیں ہے۔ وہ خالی ہیں۔
اور اگر میں "SELECT" کمانڈ چلاتا ہوں، تو AccessShareLock کی درخواست کرنے کا یہ مضمر (واضح) طریقہ ہے۔ لہذا میں اپنا ٹیبل جاری کرتا ہوں اور استفسار چلاتا ہوں اور استفسار متعدد قطاریں لوٹاتا ہے۔ اور ایک لائن میں ہم AccessShareLock دیکھتے ہیں۔ اس طرح، ٹیبل پر SELECT AccessShareLock کو کال کرتا ہے۔ اور یہ عملی طور پر کسی بھی چیز سے متصادم نہیں ہے کیونکہ یہ ایک نچلی سطح کا لاک ہے۔
اگر میں SELECT چلاتا ہوں اور تین مختلف ٹیبلز ہوں تو کیا ہوگا؟ پہلے میں صرف ایک ٹیبل چلا رہا تھا، اب میں تین چلا رہا ہوں: pg_class، pg_namespace اور pg_attribute۔
اور اب جب میں استفسار کو دیکھتا ہوں تو مجھے تین ٹیبلز میں 9 AccessShareLocks نظر آتے ہیں۔ کیوں؟ تین ٹیبلز کو نیلے رنگ میں نمایاں کیا گیا ہے: pg_attribute، pg_class، pg_namespace۔ لیکن آپ یہ بھی دیکھ سکتے ہیں کہ تمام اشاریہ جات جو ان ٹیبلز کے ذریعے بیان کیے گئے ہیں ان میں بھی AccessShareLock ہے۔
اور یہ ایک ایسا تالا ہے جو عملی طور پر دوسروں سے متصادم نہیں ہوتا۔ اور یہ صرف یہ ہے کہ جب ہم اسے منتخب کرتے ہیں تو ہمیں ٹیبل کو دوبارہ ترتیب دینے سے روکتے ہیں۔ یہ سمجھ میں آتا ہے. یعنی اگر ہم کسی ٹیبل کو سلیکٹ کرتے ہیں تو وہ اسی لمحے غائب ہو جاتا ہے، تو یہ غلط ہے۔ ایکسیس شیئر ایک نچلی سطح کا لاک ہے جو ہمیں بتاتا ہے کہ "جب میں کام کر رہا ہوں تو اس ٹیبل کو مت چھوڑیں". بنیادی طور پر، وہ بس اتنا ہی کرتی ہے۔
ROW SHARE - یہ تالا تھوڑا مختلف ہے۔
آئیے ایک مثال لیتے ہیں۔ ہر قطار کو انفرادی طور پر لاک کرنے کا ROW SHARE طریقہ منتخب کریں۔. اس طرح کوئی بھی انہیں حذف یا تبدیل نہیں کر سکتا جب تک ہم انہیں دیکھ رہے ہوں۔
تو SHARE LOCK کیا کرتا ہے؟ ہم دیکھتے ہیں کہ SELECT کے لیے ٹرانزیکشن ID 681 ہے۔ اور یہ دلچسپ ہے۔ یہاں کیا ہوا ہے؟ پہلی بار جب ہم نمبر دیکھتے ہیں "لاک" فیلڈ میں ہے۔ ہم ٹرانزیکشن ID لیتے ہیں اور یہ کہتا ہے کہ یہ اسے خصوصی موڈ میں بلاک کر رہا ہے۔ یہ صرف اتنا کرتا ہے کہ میرے پاس ایک قطار ہے جو ٹیبل میں کہیں تکنیکی طور پر بند ہے۔ لیکن وہ یہ نہیں بتاتا کہ کہاں ہے۔ ہم اس پر مزید تفصیل سے تھوڑی دیر بعد دیکھیں گے۔
یہاں ہم کہتے ہیں کہ تالا ہم استعمال کرتے ہیں۔
لہذا، ایک خصوصی تالا واضح طور پر کہتا ہے کہ یہ خصوصی ہے۔ اور یہ بھی کہ اگر آپ اس ٹیبل میں ایک قطار کو حذف کرتے ہیں، تو ایسا ہی ہوگا، جیسا کہ آپ دیکھ سکتے ہیں۔
SHARE EXCLUSIVE ایک لمبا لاک ہے۔
یہ (ANALYZE) تجزیہ کار کمانڈ ہے جسے استعمال کیا جائے گا۔
شیئر لاک - آپ شیئر موڈ میں واضح طور پر لاک کرسکتے ہیں۔
آپ ایک منفرد انڈیکس بھی بنا سکتے ہیں۔ اور وہاں آپ SHARE LOCK دیکھ سکتے ہیں، جو ان کا حصہ ہے۔ اور یہ میز کو لاک کرتا ہے اور اس پر SHARE LOCK لگا دیتا ہے۔
پہلے سے طے شدہ طور پر، ٹیبل پر SHARE LOCK کا مطلب ہے کہ دوسرے لوگ ٹیبل کو پڑھ سکتے ہیں، لیکن کوئی بھی اس میں ترمیم نہیں کر سکتا۔ اور یہ بالکل وہی ہوتا ہے جب آپ ایک منفرد انڈیکس بناتے ہیں۔
اگر میں ایک انوکھا کنکرنٹلی انڈیکس بناتا ہوں، تو میرے پاس لاکنگ کی ایک مختلف قسم ہوگی کیونکہ جیسا کہ آپ کو یاد ہے، بیک وقت انڈیکس استعمال کرنے سے لاکنگ کی ضرورت کم ہوجاتی ہے۔ اور اگر میں ایک نارمل لاک، ایک نارمل انڈیکس استعمال کرتا ہوں، تو میں اس طرح ٹیبل انڈیکس پر لکھنے سے روکوں گا جب تک یہ بنایا جا رہا ہے۔ اگر میں بیک وقت انڈیکس استعمال کرتا ہوں، تو مجھے ایک مختلف قسم کی لاکنگ استعمال کرنے کی ضرورت ہے۔
SHARE ROW EXCLUSIVE - دوبارہ اسے واضح طور پر (واضح طور پر) سیٹ کیا جا سکتا ہے۔
یا ہم ایک قاعدہ تشکیل دے سکتے ہیں، یعنی ایک مخصوص کیس لے لیں جس میں اسے استعمال کیا جائے گا۔
خصوصی تالا لگانے کا مطلب ہے کہ کوئی اور میز کو تبدیل نہیں کر سکتا۔
یہاں ہم مختلف قسم کے تالے دیکھتے ہیں۔
EXCESS EXCLUSIVE، مثال کے طور پر، ایک بلاکنگ کمانڈ ہے۔ مثال کے طور پر، اگر آپ کرتے ہیں CLUSTER tableتو اس کا مطلب یہ ہوگا کہ وہاں کوئی بھی نہیں لکھ سکے گا۔ اور یہ نہ صرف خود میز کو بلکہ اشاریہ جات کو بھی مقفل کرتا ہے۔
یہ رسائی کے خصوصی بلاکنگ کا دوسرا صفحہ ہے، جہاں ہم بالکل وہی دیکھتے ہیں جو ٹیبل میں بلاک کرتا ہے۔ یہ انفرادی ٹیبل کی قطاروں کو لاک کرتا ہے، جو کافی دلچسپ ہے۔
یہ تمام بنیادی معلومات ہے جو میں دینا چاہتا تھا۔ ہم نے تالے کے بارے میں بات کی، ٹرانزیکشن آئی ڈی کے بارے میں، ہم نے ورچوئل ٹرانزیکشن آئی ڈی کے بارے میں، مستقل ٹرانزیکشن آئی ڈی کے بارے میں بات کی۔
اور اب ہم کچھ بلاک کرنے والی مثالیں دیکھیں گے۔ یہ سب سے دلچسپ حصہ ہے۔ ہم بہت دلچسپ کیسز دیکھیں گے۔ اور اس پریزنٹیشن میں میرا مقصد آپ کو بہتر سمجھنا ہے کہ پوسٹگریس اصل میں کیا کر رہا ہے جب وہ کچھ چیزوں کو روکنے کی کوشش کرتا ہے۔ مجھے لگتا ہے کہ وہ حصوں کو روکنے میں بہت اچھا ہے۔
آئیے کچھ مخصوص مثالوں کو دیکھتے ہیں۔
ہم ایک ٹیبل میں ٹیبل اور ایک قطار سے شروع کریں گے۔ جب میں کچھ داخل کرتا ہوں تو میرے پاس میز پر ExclusiveLock، ٹرانزیکشن ID اور ExclusiveLock ڈسپلے ہوتا ہے۔
اگر میں مزید دو قطاریں داخل کروں تو کیا ہوگا؟ اور اب ہماری میز میں تین قطاریں ہیں۔ اور میں نے ایک قطار ڈالی اور اسے آؤٹ پٹ کے طور پر ملا۔ اور اگر میں دو مزید قطاریں ڈالوں تو اس میں کیا عجیب بات ہے؟ یہاں ایک عجیب چیز ہے کیونکہ میں نے اس ٹیبل میں تین قطاریں شامل کی ہیں، لیکن میرے پاس ابھی بھی لاک ٹیبل میں دو قطاریں ہیں۔ اور یہ بنیادی طور پر پوسٹگریس کا بنیادی طرز عمل ہے۔
بہت سے لوگ سوچتے ہیں کہ اگر آپ ڈیٹا بیس میں 100 قطاروں کو لاک کرتے ہیں، تو آپ کو 100 لاک اندراجات بنانے کی ضرورت ہوگی۔ اگر میں ایک ساتھ 1 قطاروں کو بلاک کرتا ہوں، تو مجھے اس طرح کے 000 سوالات کی ضرورت ہوگی۔ اور اگر مجھے بلاک کرنے کے لیے ایک ملین یا ایک ارب کی ضرورت ہے۔ لیکن اگر ہم ایسا کرتے ہیں تو یہ بہت اچھا کام نہیں کرے گا۔ اگر آپ نے ایک ایسا نظام استعمال کیا ہے جو ہر انفرادی قطار کے لیے بلاکنگ اندراجات تخلیق کرتا ہے، تو آپ دیکھ سکتے ہیں کہ یہ پیچیدہ ہے۔ کیونکہ آپ کو فوری طور پر ایک لاک ٹیبل کی وضاحت کرنے کی ضرورت ہے جو اوور فلو ہوسکتا ہے، لیکن پوسٹگریس ایسا نہیں کرتا ہے۔
اور جو چیز اس سلائیڈ کے بارے میں واقعی اہم ہے وہ یہ ہے کہ یہ واضح طور پر ظاہر کرتا ہے کہ MVCC کے اندر ایک اور نظام چلتا ہے جو انفرادی قطاروں کو مقفل کرتا ہے۔ لہذا جب آپ اربوں قطاروں کو لاک کرتے ہیں، تو پوسٹگریس ایک ارب الگ الگ لاکنگ کمانڈز نہیں بناتا ہے۔ اور اس کا پیداواری صلاحیت پر بہت اچھا اثر پڑتا ہے۔
اپ ڈیٹ کے بارے میں کیا خیال ہے؟ میں ابھی قطار کو اپ ڈیٹ کر رہا ہوں، اور آپ دیکھ سکتے ہیں کہ اس نے ایک ساتھ دو مختلف آپریشن کیے ہیں۔ اس نے ایک ہی وقت میں ٹیبل کو لاک کردیا، لیکن اس نے انڈیکس کو بھی لاک کردیا۔ اور اسے انڈیکس کو لاک کرنے کی ضرورت تھی کیونکہ اس ٹیبل پر انوکھی رکاوٹیں ہیں۔ اور ہم اس بات کو یقینی بنانا چاہتے ہیں کہ کوئی بھی اسے تبدیل نہ کرے، اس لیے ہم اسے بلاک کر دیتے ہیں۔
اگر میں دو قطاروں کو اپ ڈیٹ کرنا چاہتا ہوں تو کیا ہوگا؟ اور ہم دیکھتے ہیں کہ وہ اسی طرح برتاؤ کرتا ہے۔ ہم دو گنا زیادہ اپ ڈیٹ کرتے ہیں، لیکن لاک لائنوں کی بالکل اتنی ہی تعداد۔
اگر آپ سوچ رہے ہیں کہ Postgres یہ کیسے کرتا ہے، تو آپ کو یہ جاننے کے لیے MVCC پر میری بات چیت سننی ہوگی کہ Postgres ان لائنوں کو اندرونی طور پر کیسے نشان زد کرتا ہے کہ یہ تبدیل ہوتی ہے۔ اور پوسٹگریس کے پاس ایک طریقہ ہے جس میں وہ یہ کرتا ہے، لیکن یہ ٹیبل لاکنگ کی سطح پر نہیں کرتا، یہ اسے کم اور زیادہ موثر سطح پر کرتا ہے۔
اگر میں کچھ حذف کرنا چاہتا ہوں تو کیا ہوگا؟ اگر میں حذف کرتا ہوں، مثال کے طور پر، ایک قطار اور میرے پاس اب بھی میرے دو بلاکنگ ان پٹ موجود ہیں، اور یہاں تک کہ اگر میں ان سب کو حذف کرنا چاہتا ہوں، تب بھی وہ موجود ہیں۔
اور، مثال کے طور پر، میں 1 لائنیں ڈالنا چاہتا ہوں، اور پھر 000 لائنوں کو حذف یا شامل کرنا چاہتا ہوں، پھر وہ انفرادی لائنیں جو میں شامل کرتا ہوں یا تبدیل کرتا ہوں، وہ یہاں ریکارڈ نہیں کی جاتیں۔ وہ سیریز کے اندر ہی نچلی سطح پر لکھے گئے ہیں۔ اور MVCC تقریر کے دوران میں نے اس بارے میں تفصیل سے بات کی۔ لیکن یہ بہت اہم ہے جب آپ تالے کا تجزیہ کر رہے ہیں اس بات کو یقینی بنانے کے لیے کہ آپ میز کی سطح پر لاک کر رہے ہیں اور آپ یہ نہیں دیکھ رہے ہیں کہ یہاں انفرادی قطاریں کیسے ریکارڈ کی جا رہی ہیں۔
واضح بلاکنگ کے بارے میں کیا خیال ہے؟
اگر میں ریفریش پر کلک کرتا ہوں تو میرے پاس دو قطاریں بند ہو جاتی ہیں۔ اور اگر میں ان سب کو منتخب کرتا ہوں اور "ہر جگہ اپ ڈیٹ کریں" پر کلک کرتا ہوں، تب بھی میرے پاس دو بلاکنگ ریکارڈ موجود ہیں۔
ہم ہر ایک قطار کے لیے الگ الگ ریکارڈ نہیں بناتے ہیں۔ کیونکہ پھر پیداواری صلاحیت کم ہو جاتی ہے، اس میں بہت زیادہ ہو سکتا ہے۔ اور ہم خود کو ایک ناخوشگوار صورتحال میں پا سکتے ہیں۔
اور وہی چیز، اگر ہم مشترکہ کرتے ہیں، تو ہم اسے 30 بار کر سکتے ہیں۔
ہم اپنی میز کو بحال کرتے ہیں، ہر چیز کو حذف کرتے ہیں، پھر ایک قطار دوبارہ داخل کرتے ہیں۔
ایک اور برتاؤ جو آپ پوسٹگریس میں دیکھتے ہیں جو بہت مشہور اور مطلوبہ سلوک ہے وہ یہ ہے کہ آپ اپ ڈیٹ یا سلیکٹ کرسکتے ہیں۔ اور آپ یہ کام ایک ہی وقت میں کر سکتے ہیں۔ اور سلیکٹ اپ ڈیٹ کو بلاک نہیں کرتا اور وہی چیز مخالف سمت میں۔ ہم قاری سے کہتے ہیں کہ مصنف کو بلاک نہ کریں، اور مصنف نے قاری کو بلاک نہیں کیا۔
میں آپ کو اس کی ایک مثال دکھاتا ہوں۔ میں اب ایک انتخاب کروں گا۔ اس کے بعد ہم INSERT کریں گے۔ اور پھر آپ دیکھ سکتے ہیں - 694۔ آپ اس لین دین کی ID دیکھ سکتے ہیں جس نے یہ داخل کیا تھا۔ اور اس طرح یہ کام کرتا ہے۔
اور اگر میں اب اپنی بیک اینڈ آئی ڈی کو دیکھتا ہوں تو یہ اب 695 ہے۔
اور میں اپنے ٹیبل میں 695 کو ظاہر ہوتے دیکھ سکتا ہوں۔
اور اگر میں یہاں اس طرح اپ ڈیٹ کرتا ہوں تو مجھے ایک مختلف کیس ملتا ہے۔ اس معاملے میں، 695 ایک خصوصی لاک ہے، اور اپ ڈیٹ کا رویہ ایک جیسا ہے، لیکن ان کے درمیان کوئی تنازعہ نہیں ہے، جو کہ کافی غیر معمولی ہے۔
اور آپ دیکھ سکتے ہیں کہ سب سے اوپر یہ ShareLock ہے، اور نیچے یہ ExclusiveLock ہے۔ اور دونوں لین دین کام ہو گیا۔
اور یہ سمجھنے کے لیے کہ یہ کیسے ہوتا ہے آپ کو MVCC میں میری گفتگو سننے کی ضرورت ہے۔ لیکن یہ ایک مثال ہے کہ آپ اسے ایک ہی وقت میں کر سکتے ہیں، یعنی ایک ہی وقت میں ایک SELECT اور اپ ڈیٹ کریں۔
آئیے دوبارہ ترتیب دیں اور ایک اور آپریشن کریں۔
اگر آپ ایک ہی قطار میں بیک وقت دو اپ ڈیٹس چلانے کی کوشش کرتے ہیں تو اسے بلاک کر دیا جائے گا۔ اور یاد رکھو، میں نے کہا تھا کہ قاری لکھنے والے کو بلاک نہیں کرتا، اور لکھاری قاری کو بلاک نہیں کرتا، لیکن ایک لکھاری دوسرے مصنف کو بلاک کرتا ہے۔ یعنی، ہم ایک ہی وقت میں دو افراد کو ایک ہی قطار کو اپ ڈیٹ نہیں کر سکتے۔ آپ کو ان میں سے ایک کے ختم ہونے تک انتظار کرنا ہوگا۔
اور اس کی وضاحت کرنے کے لیے، میں لاک ڈیمو ٹیبل کو دیکھوں گا۔ اور ہم ایک قطار کو دیکھیں گے۔ فی لین دین 698۔
ہم نے اسے 2 میں اپ ڈیٹ کر دیا ہے۔ 699 پہلی اپ ڈیٹ ہے۔ اور یہ کامیاب رہا یا یہ زیر التواء لین دین میں ہے اور ہمارے تصدیق یا منسوخی کا انتظار کر رہا ہے۔
لیکن کچھ اور دیکھیں - 2/51 ہمارا پہلا لین دین ہے، ہمارا پہلا سیشن ہے۔ 3/112 دوسری درخواست ہے جو اوپر سے آئی ہے جس نے اس قدر کو 3 میں تبدیل کر دیا ہے۔ اور اگر آپ نے دیکھا، تو اوپر والے نے خود کو لاک کر دیا، جو کہ 699 ہے۔ لیکن 3/112 نے تالا نہیں دیا۔ Lock_mode کالم کہتا ہے کہ وہ کس چیز کا انتظار کر رہا ہے۔ یہ 699 کی توقع رکھتا ہے۔ اور اگر آپ دیکھیں کہ 699 کہاں ہے، تو یہ زیادہ ہے۔ اور پہلے سیشن میں کیا کیا؟ اس نے اپنی ٹرانزیکشن ID پر ایک خصوصی لاک بنایا۔ پوسٹگریس اس طرح کرتا ہے۔ یہ اس کی اپنی ٹرانزیکشن ID کو بلاک کرتا ہے۔ اور اگر آپ کسی کی تصدیق یا منسوخی کا انتظار کرنا چاہتے ہیں، تو آپ کو انتظار کرنا ہوگا جب تک کہ کوئی زیر التواء لین دین ہو۔ اور اسی لیے ہم ایک عجیب و غریب لکیر دیکھ سکتے ہیں۔
آئیے دوبارہ دیکھتے ہیں۔ بائیں طرف ہم اپنی پروسیسنگ ID دیکھتے ہیں۔ دوسرے کالم میں ہم اپنی ورچوئل ٹرانزیکشن ID دیکھتے ہیں، اور تیسرے میں ہم lock_type دیکھتے ہیں۔ اس کا کیا مطلب ہے؟ بنیادی طور پر یہ کیا کہتا ہے کہ یہ ٹرانزیکشن ID کو مسدود کر رہا ہے۔ لیکن نوٹ کریں کہ نیچے کی تمام قطاریں رشتہ بتاتی ہیں۔ اور اس طرح آپ کے پاس میز پر دو قسم کے تالے ہیں۔ رشتے کا تالا ہے۔ اور پھر ٹرانزیکشنڈ بلاکنگ ہے، جہاں آپ خود ہی بلاک کرتے ہیں، جو بالکل وہی ہوتا ہے جو پہلی قطار میں ہوتا ہے یا بالکل نیچے، جہاں ٹرانزیکشنڈ ہوتا ہے، جہاں ہم 699 کے آپریشن کے مکمل ہونے کا انتظار کرتے ہیں۔
میں دیکھوں گا کہ یہاں کیا ہوتا ہے۔ اور یہاں دو چیزیں بیک وقت ہوتی ہیں۔ آپ پہلی قطار میں ایک ٹرانزیکشن ID لاک کو دیکھ رہے ہیں جو خود ہی لاک ہوجاتا ہے۔ اور وہ لوگوں کو انتظار کرنے کے لیے خود کو روکتی ہے۔
اگر آپ 6 ویں لائن کو دیکھیں تو یہ وہی اندراج ہے جو پہلی ہے۔ اور اس وجہ سے ٹرانزیکشن 699 بلاک ہے۔ 700 سیلف لاکنگ بھی ہے۔ اور پھر نیچے والی قطار میں آپ دیکھیں گے کہ ہم 699 کے آپریشن کے مکمل ہونے کا انتظار کر رہے ہیں۔
اور lock_type میں، آپ کو نمبر نظر آتے ہیں۔
آپ دیکھ سکتے ہیں کہ یہ 0/10 ہے۔ اور یہ صفحہ نمبر ہے، اور اس مخصوص قطار کا آفسیٹ بھی۔
اور آپ دیکھتے ہیں کہ جب ہم اپ ڈیٹ کرتے ہیں تو یہ 0/11 ہو جاتا ہے۔
لیکن حقیقت میں یہ 0/10 ہے، کیونکہ اس آپریشن کا انتظار ہے۔ ہمارے پاس یہ دیکھنے کا موقع ہے کہ یہ وہ سلسلہ ہے جس کی تصدیق کرنے کا میں انتظار کر رہا ہوں۔
ایک بار جب ہم اس کی تصدیق کر لیتے ہیں اور کمٹ کو دباتے ہیں، اور جب اپ ڈیٹ ختم ہو جاتا ہے، تو ہمیں دوبارہ یہی ملتا ہے۔ ٹرانزیکشن 700 واحد لاک ہے، یہ کسی اور کا انتظار نہیں کرتا کیونکہ اس کا ارتکاب کیا گیا تھا۔ یہ صرف لین دین کے مکمل ہونے کا انتظار کرتا ہے۔ ایک بار 699 رن آؤٹ ہوجانے کے بعد ہم کسی چیز کا انتظار نہیں کرتے۔ اور اب ٹرانزیکشن 700 کہتا ہے کہ سب کچھ ٹھیک ہے، کہ اس میں تمام اجازت شدہ میزوں پر ضرورت کے تمام تالے موجود ہیں۔
اور اس ساری چیز کو مزید پیچیدہ بنانے کے لیے، ہم ایک اور نظریہ بناتے ہیں، جو اس بار ہمیں ایک درجہ بندی فراہم کرے گا۔ مجھے امید نہیں ہے کہ آپ اس درخواست کو سمجھیں گے۔ لیکن یہ ہمیں ایک واضح نظریہ دے گا کہ کیا ہو رہا ہے۔
یہ ایک تکراری نظریہ ہے جس کا دوسرا حصہ بھی ہے۔ اور پھر یہ سب کچھ دوبارہ ایک ساتھ لاتا ہے۔ آئیے اس کو استعمال کریں۔
کیا ہوگا اگر ہم بیک وقت تین اپڈیٹس کریں اور کہیں کہ قطار اب تین ہے۔ اور ہم 3 سے 4 کو تبدیل کریں گے۔
اور یہاں ہم 4 دیکھتے ہیں۔ اور ٹرانزیکشن ID 702۔
اور پھر میں 4 سے 5 کو تبدیل کروں گا۔ اور 5 سے 6، اور 6 سے 7۔ اور میں بہت سے لوگوں کو قطار میں کھڑا کروں گا جو اس ایک ٹرانزیکشن کے ختم ہونے کا انتظار کر رہے ہوں گے۔
اور سب کچھ واضح ہو جاتا ہے۔ پہلی قطار کیا ہے؟ یہ 702 ہے۔ یہ وہ ٹرانزیکشن آئی ڈی ہے جو اصل میں اس قدر کو سیٹ کرتی ہے۔ میرے گرانٹڈ کالم میں کیا لکھا ہے؟ میرے پاس نشانات ہیں۔ f. یہ میری اپ ڈیٹس ہیں جو (5, 6, 7) کو منظور نہیں کیا جا سکتا کیونکہ ہم ٹرانزیکشن ID 702 کے ختم ہونے کا انتظار کر رہے ہیں۔ وہاں ہمارے پاس ٹرانزیکشن آئی ڈی بلاکنگ ہے۔ اور اس کے نتیجے میں 5 ٹرانزیکشنل آئی ڈی لاک ہوتے ہیں۔
اور اگر آپ 704 کو دیکھیں تو 705 پر، وہاں ابھی تک کچھ نہیں لکھا گیا ہے، کیونکہ وہ نہیں جانتے کہ ابھی کیا ہو رہا ہے۔ وہ صرف یہ لکھتے ہیں کہ انہیں کچھ پتہ نہیں کہ کیا ہو رہا ہے۔ اور وہ صرف سو جائیں گے کیونکہ وہ کسی کے ختم ہونے کا انتظار کر رہے ہیں اور جب قطار بدلنے کا موقع ملے گا تو بیدار ہو جائیں گے۔
یہ ایسا ہی لگتا ہے۔ یہ واضح ہے کہ وہ سب 12ویں لائن کا انتظار کر رہے ہیں۔
یہ وہی ہے جو ہم نے یہاں دیکھا۔ یہاں 0/12 ہے۔
لہذا ایک بار جب پہلی ٹرانزیکشن منظور ہو جاتی ہے، تو آپ یہاں دیکھ سکتے ہیں کہ درجہ بندی کیسے کام کرتی ہے۔ اور اب سب کچھ واضح ہو گیا ہے۔ وہ سب صاف ہو جاتے ہیں۔ اور وہ حقیقت میں ابھی تک انتظار کر رہے ہیں۔
یہ ہے کیا ہو رہا ہے۔ 702 عہد کرتا ہے۔ اور اب 703 کو یہ قطار لاک ملتا ہے، اور پھر 704 703 کے کمٹمنٹ کا انتظار کرنے لگتا ہے۔ اور 705 بھی اس کا انتظار کر رہا ہے۔ اور جب یہ سب مکمل ہو جاتا ہے تو وہ خود کو صاف کر لیتے ہیں۔ اور میں یہ بتانا چاہوں گا کہ ہر کوئی قطار میں کھڑا ہے۔ اور یہ ٹریفک جام کی صورت حال سے بہت ملتا جلتا ہے جب ہر کوئی پہلی گاڑی کا انتظار کر رہا ہوتا ہے۔ پہلی گاڑی رکتی ہے اور سب ایک لمبی لائن میں لگ جاتے ہیں۔ پھر یہ حرکت کرتا ہے، پھر اگلی گاڑی آگے چل کر اپنا بلاک وغیرہ حاصل کر سکتی ہے۔
اور اگر یہ آپ کو کافی پیچیدہ نہیں لگتا ہے، تو اب ہم آپ سے تعطل کے بارے میں بات کریں گے۔ میں نہیں جانتا کہ آپ میں سے کس نے ان کا سامنا کیا ہے۔ ڈیٹا بیس سسٹمز میں یہ کافی عام مسئلہ ہے۔ لیکن تعطل اس وقت ہوتا ہے جب ایک سیشن کچھ کرنے کے لیے دوسرے سیشن کا انتظار کر رہا ہوتا ہے۔ اور اس وقت ایک اور سیشن انتظار کر رہا ہے کہ پہلے سیشن کچھ کر سکے۔
اور، مثال کے طور پر، اگر ایوان کہتا ہے: "مجھے کچھ دو" اور میں کہتا ہوں: "نہیں، میں آپ کو صرف اس صورت میں دوں گا جب آپ مجھے کچھ اور دیں گے۔" اور وہ کہتا ہے، "نہیں، اگر تم مجھے نہیں دو گے تو میں تمہیں نہیں دوں گا۔" اور ہم ایک تعطل کی صورتحال میں ختم ہوجاتے ہیں۔ مجھے یقین ہے کہ ایوان ایسا نہیں کرے گا، لیکن آپ اس کا مطلب سمجھتے ہیں کہ ہمارے پاس دو لوگ ہیں جو کچھ حاصل کرنا چاہتے ہیں اور وہ اس وقت تک دینے کے لیے تیار نہیں ہوتے جب تک کہ دوسرا شخص انھیں وہ نہ دے جو وہ چاہتے ہیں۔ اور کوئی حل نہیں ہے۔
اور بنیادی طور پر، آپ کے ڈیٹا بیس کو اس کا پتہ لگانے کی ضرورت ہے۔ اور پھر آپ کو سیشنوں میں سے ایک کو حذف یا بند کرنے کی ضرورت ہے، کیونکہ دوسری صورت میں وہ ہمیشہ کے لیے وہاں رہیں گے۔ اور ہم اسے ڈیٹا بیس میں دیکھتے ہیں، ہم اسے آپریٹنگ سسٹم میں دیکھتے ہیں۔ اور ان تمام جگہوں پر جہاں ہمارے پاس متوازی عمل ہیں، ایسا ہو سکتا ہے۔
اور اب ہم دو تعطل نصب کریں گے۔ ہم 50 اور 80 ڈالیں گے۔ پہلی قطار میں، میں 50 سے 50 تک اپ ڈیٹ کروں گا۔ مجھے ٹرانزیکشن نمبر 710 ملے گا۔
اور پھر میں 80 سے 81، اور 50 کو 51 میں تبدیل کروں گا۔
اور یہ ایسا ہی نظر آئے گا۔ اور اس طرح 710 میں ایک قطار بلاک ہے، اور 711 تصدیق کا انتظار کر رہا ہے۔ جب ہم نے اپ ڈیٹ کیا تو ہم نے یہ دیکھا۔ 710 ہماری سیریز کا مالک ہے۔ اور 711 ٹرانزیکشن مکمل کرنے کے لیے 710 کا انتظار کر رہا ہے۔
اور یہ یہاں تک کہتا ہے کہ تعطل کس صف میں ہوتا ہے۔ اور یہیں سے یہ عجیب و غریب ہونا شروع ہوتا ہے۔
اب ہم 80 سے 80 کو اپ ڈیٹ کر رہے ہیں۔
اور یہیں سے تعطل کا آغاز ہوتا ہے۔ 710 711 سے جواب کا انتظار کر رہا ہے، اور 711 710 کا انتظار کر رہا ہے۔ اور یہ اچھی طرح ختم نہیں ہوگا۔ اور اس سے نکلنے کا کوئی راستہ نہیں ہے۔ اور وہ ایک دوسرے سے جواب کی توقع کریں گے۔
اور یہ صرف ہر چیز میں تاخیر کرنا شروع کردے گا۔ اور ہم یہ نہیں چاہتے۔
اور پوسٹگریس کے پاس نوٹس لینے کے طریقے ہیں جب ایسا ہوتا ہے۔ اور جب ایسا ہوتا ہے، تو آپ کو یہ غلطی ملتی ہے۔ اور اس سے یہ واضح ہوتا ہے کہ فلاں فلاں عمل دوسرے پراسیس سے SHARE LOCK کا انتظار کر رہا ہے، یعنی جو 711 پراسیس سے بلاک ہے۔ اور وہ عمل فلاں ٹرانزیکشن ID پر SHARE LOCK دینے کا انتظار کر رہا تھا اور فلاں عمل سے بلاک کر دیا گیا تھا۔ اس لیے یہاں تعطل کی صورتحال ہے۔
کیا تین طرفہ تعطل ہے؟ کیا یہ ممکن ہے؟ جی ہاں.
ہم ان نمبروں کو ایک ٹیبل میں داخل کرتے ہیں۔ ہم 40 سے 40 کو تبدیل کرتے ہیں، ہم بلاکنگ کرتے ہیں۔
ہم 60 سے 61، 80 کو 81 میں تبدیل کرتے ہیں۔
اور پھر ہم 80 کو تبدیل کرتے ہیں اور پھر بوم!
اور 714 اب 715 کا انتظار کر رہا ہے۔ 716 واں 715 کا انتظار کر رہا ہے۔ اور اس پر کچھ نہیں کیا جا سکتا۔
یہاں اب دو لوگ نہیں ہیں، یہاں پہلے ہی تین لوگ موجود ہیں۔ میں تم سے کچھ چاہتا ہوں، یہ تیسرے شخص سے کچھ چاہتا ہے اور تیسرا مجھ سے کچھ چاہتا ہے۔ اور ہم تین طرفہ انتظار میں ختم ہوتے ہیں کیونکہ ہم سب دوسرے شخص کا انتظار کر رہے ہیں کہ وہ کیا کرنے کی ضرورت ہے۔
اور پوسٹگریس جانتا ہے کہ یہ کس قطار میں ہوتا ہے۔ اور اس طرح یہ آپ کو درج ذیل پیغام دے گا، جو ظاہر کرتا ہے کہ آپ کو ایک مسئلہ ہے جہاں تین ان پٹ ایک دوسرے کو بلاک کر رہے ہیں۔ اور یہاں کوئی پابندیاں نہیں ہیں۔ یہ معاملہ ہو سکتا ہے جہاں 20 اندراجات ایک دوسرے کو بلاک کر دیں۔
اگلا مسئلہ سلسلہ وار ہے۔
اگر خصوصی serializable تالا.
اور ہم 719 پر واپس آتے ہیں۔ اس کا آؤٹ پٹ بالکل نارمل ہے۔
اور آپ لین دین کو سیریلائز کرنے کے لیے کلک کر سکتے ہیں۔
اور آپ کو احساس ہے کہ اب آپ کے پاس ایک مختلف قسم کا SA لاک ہے - اس کا مطلب ہے سیریلائزیبل۔
اور اس لیے ہمارے پاس SARieadLock نامی ایک نئی قسم کا تالا ہے، جو ایک سیریل لاک ہے اور آپ کو سیریلز میں داخل ہونے کی اجازت دیتا ہے۔
اور آپ منفرد اشاریہ جات بھی داخل کر سکتے ہیں۔
اس جدول میں ہمارے پاس منفرد اشاریہ جات ہیں۔
لہذا اگر میں یہاں نمبر 2 ڈالتا ہوں، تو میرے پاس 2 ہے۔ لیکن سب سے اوپر، میں ایک اور 2 اندر ڈالتا ہوں۔ اور آپ دیکھ سکتے ہیں کہ 721 میں ایک خصوصی لاک ہے۔ لیکن اب 722 اپنے آپریشن کو مکمل کرنے کے لیے 721 کا انتظار کر رہا ہے کیونکہ یہ 2 کو داخل نہیں کر سکتا جب تک کہ اسے معلوم نہ ہو کہ 721 کا کیا ہو گا۔
اور اگر ہم ذیلی لین دین کرتے ہیں۔
یہاں ہمارے پاس 723 ہیں۔
اور اگر ہم پوائنٹ کو محفوظ کرتے ہیں اور پھر اسے اپ ڈیٹ کرتے ہیں تو ہمیں ایک نئی ٹرانزیکشن آئی ڈی مل جاتی ہے۔ یہ طرز عمل کا ایک اور نمونہ ہے جس سے آپ کو آگاہ ہونے کی ضرورت ہے۔ اگر ہم اسے واپس کرتے ہیں تو ٹرانزیکشن آئی ڈی ختم ہو جاتی ہے۔ 724 جا رہا ہے۔ لیکن اب ہمارے پاس 725 ہیں۔
تو میں یہاں کیا کرنے کی کوشش کر رہا ہوں؟ میں آپ کو غیر معمولی تالے کی مثالیں دکھانے کی کوشش کر رہا ہوں جو آپ کو مل سکتے ہیں: چاہے یہ سیریلائز ہونے والے تالے ہوں یا SAVEPOINT، یہ مختلف قسم کے تالے ہیں جو لاک ٹیبل میں ظاہر ہوں گے۔
یہ واضح (واضح) تالے کی تخلیق ہے، جس میں pg_advisory_lock ہے۔
اور آپ دیکھتے ہیں کہ بلاک کرنے کی قسم بطور ایڈوائزری درج ہے۔ اور یہاں یہ سرخ رنگ میں "مشورہ" کہتا ہے۔ اور آپ pg_advisory_unlock کے ساتھ اس طرح کو بیک وقت بلاک کر سکتے ہیں۔
اور آخر میں، میں آپ کو ایک اور ذہن اڑا دینے والی چیز دکھانا چاہوں گا۔ میں ایک اور منظر بناؤں گا۔ لیکن میں pg_stat_activity ٹیبل کے ساتھ pg_locks ٹیبل میں شامل ہو جاؤں گا۔ اور میں یہ کیوں کرنا چاہتا ہوں؟ کیونکہ یہ مجھے تمام موجودہ سیشنز کو دیکھنے اور دیکھنے کی اجازت دے گا اور بالکل یہ دیکھ سکتا ہے کہ وہ کس قسم کے تالے کا انتظار کر رہے ہیں۔ اور یہ کافی دلچسپ ہے جب ہم لاک ٹیبل اور استفسار کی میز کو ایک ساتھ رکھتے ہیں۔
اور یہاں ہم pg_stat_view بناتے ہیں۔
اور ہم قطار کو ایک ایک کرکے اپ ڈیٹ کرتے ہیں۔ اور یہاں ہم 724 دیکھتے ہیں۔ اور پھر ہم اپنی قطار کو تین میں اپ ڈیٹ کرتے ہیں۔ اور اب آپ یہاں کیا دیکھتے ہیں؟ یہ درخواستیں ہیں، یعنی آپ کو درخواستوں کی پوری فہرست نظر آتی ہے جو بائیں کالم میں درج ہیں۔ اور پھر دائیں طرف آپ رکاوٹیں اور وہ کیا بناتے ہیں دیکھ سکتے ہیں۔ اور یہ آپ کے لیے زیادہ واضح ہو سکتا ہے تاکہ آپ کو ہر بار ہر سیشن میں واپس جانے کی ضرورت نہ پڑے اور دیکھیں کہ آیا آپ کو اس میں شامل ہونے کی ضرورت ہے یا نہیں۔ وہ ہمارے لیے کرتے ہیں۔
ایک اور خصوصیت جو بہت مفید ہے۔ pg_blocking_pids. آپ نے شاید اس کے بارے میں کبھی نہیں سنا ہوگا۔ وہ کیا کر رہی ہے؟ یہ ہمیں یہ بتانے کی اجازت دیتا ہے کہ اس سیشن 11740 کے لیے یہ کس مخصوص پراسیس آئی ڈی کا انتظار کر رہا ہے۔ اور آپ دیکھ سکتے ہیں کہ 11740 724 کا انتظار کر رہا ہے۔ اور 724 سب سے اوپر ہے۔ اور 11306 آپ کی پراسیس آئی ڈی ہے۔ بنیادی طور پر، یہ فنکشن آپ کے لاک ٹیبل سے گزرتا ہے۔ اور میں جانتا ہوں کہ یہ تھوڑا سا پیچیدہ ہے، لیکن آپ اسے سمجھنے کا انتظام کرتے ہیں۔ بنیادی طور پر یہ فنکشن اس لاک ٹیبل سے گزرتا ہے اور یہ جاننے کی کوشش کرتا ہے کہ اس پروسیس آئی ڈی کو وہ تالے کہاں دیئے گئے ہیں جن کا وہ انتظار کر رہا ہے۔ اور یہ یہ جاننے کی بھی کوشش کرتا ہے کہ لاک کا انتظار کرنے والے عمل کی شناخت کون سی ہے۔ تو آپ اس فنکشن کو چلا سکتے ہیں۔ pg_blocking_pids.
اور یہ بہت مفید ہو سکتا ہے. ہم نے اسے صرف ورژن 9.6 میں شامل کیا، لہذا یہ خصوصیت صرف 5 سال پرانی ہے، لیکن یہ بہت، بہت مفید ہے۔ اور یہی دوسری درخواست پر بھی لاگو ہوتا ہے۔ یہ بالکل وہی دکھاتا ہے جو ہمیں دیکھنے کی ضرورت ہے۔
یہ وہی ہے جس کے بارے میں میں آپ سے بات کرنا چاہتا تھا۔ اور جیسا کہ میں نے توقع کی تھی، ہم نے اپنا سارا وقت استعمال کیا کیونکہ بہت ساری سلائیڈیں تھیں۔ اور سلائیڈز ڈاؤن لوڈ کے لیے دستیاب ہیں۔ میں یہاں ہونے کے لیے آپ کا شکریہ ادا کرنا چاہوں گا۔ مجھے یقین ہے کہ آپ باقی کانفرنس سے لطف اندوز ہوں گے، بہت بہت شکریہ!
سوالات:
مثال کے طور پر، اگر میں قطاروں کو اپ ڈیٹ کرنے کی کوشش کر رہا ہوں، اور دوسرا سیشن پوری ٹیبل کو حذف کرنے کی کوشش کر رہا ہے۔ جہاں تک میں سمجھتا ہوں، انٹنٹ لاک کی طرح کچھ ہونا چاہیے۔ کیا پوسٹگریس میں ایسی کوئی چیز ہے؟
آئیے بالکل شروع کی طرف واپس چلتے ہیں۔ آپ کو یاد ہوگا کہ جب آپ کچھ بھی کرتے ہیں، مثال کے طور پر جب آپ SELECT کرتے ہیں، تو ہم ایک AccessShareLock جاری کرتے ہیں۔ اور یہ میز کو گرنے سے روکتا ہے۔ لہذا اگر آپ، مثال کے طور پر، کسی ٹیبل میں ایک قطار کو اپ ڈیٹ کرنا چاہتے ہیں یا کسی قطار کو حذف کرنا چاہتے ہیں، تو کوئی ایک ہی وقت میں پوری ٹیبل کو حذف نہیں کر سکتا کیونکہ آپ نے اس AccessShareLock کو پوری میز پر اور قطار کے اوپر رکھا ہوا ہے۔ اور ایک بار جب آپ کام کر لیں تو وہ اسے حذف کر سکتے ہیں۔ لیکن جب آپ وہاں کسی چیز کو براہ راست تبدیل کرتے ہیں، تو وہ اسے کرنے کے قابل نہیں ہوں گے۔
چلو اسے پھر کرتے ہیں. آئیے ڈیلیٹ مثال کی طرف چلتے ہیں۔ اور آپ دیکھتے ہیں کہ کس طرح پوری میز کے اوپر قطار میں ایک خصوصی تالا لگا ہوا ہے۔
یہ تالا خصوصی کی طرح نظر آئے گا، ٹھیک ہے؟
ہاں، ایسا لگتا ہے۔ میں سمجھتا ہوں کہ آپ کیا بات کر رہے ہیں۔ آپ کہہ رہے ہیں کہ اگر میں SELECT کرتا ہوں تو میرے پاس ShareExclusive ہے اور پھر میں اسے Row Exclusive بناتا ہوں، کیا یہ کوئی مسئلہ بن جاتا ہے؟ لیکن حیرت کی بات یہ ہے کہ یہ کوئی مسئلہ نہیں ہے۔ ایسا لگتا ہے کہ لاک کی ڈگری میں اضافہ ہوتا ہے، لیکن بنیادی طور پر میرے پاس ایک لاک ہے جو حذف ہونے سے روکتا ہے۔ اور اب، جب میں اس تالے کو زیادہ طاقتور بناتا ہوں، تب بھی یہ حذف ہونے سے روکتا ہے۔ تو ایسا نہیں ہے کہ میں اوپر جا رہا ہوں۔ یعنی، اس نے اسے ہونے سے روکا جب یہ بھی نچلی سطح پر تھا، لہذا جب میں اس کی سطح کو بڑھاتا ہوں تب بھی یہ ٹیبل کو حذف ہونے سے روکتا ہے۔
میں سمجھتا ہوں کہ آپ کیا بات کر رہے ہیں۔ یہاں کوئی تالے میں اضافے کا معاملہ نہیں ہے، جہاں آپ ایک مضبوط کو متعارف کرانے کے لیے ایک تالا ترک کرنے کی کوشش کر رہے ہیں۔ یہاں یہ پورے بورڈ میں اس روک تھام کو بڑھاتا ہے، لہذا اس سے کوئی تنازعہ پیدا نہیں ہوتا ہے۔ لیکن یہ ایک اچھا سوال ہے۔ یہ پوچھنے کے لیے آپ کا بہت شکریہ!
جب ہمارے پاس بہت سارے سیشن ہوں، صارفین کی ایک بڑی تعداد ہو تو تعطل کی صورتحال سے بچنے کے لیے ہمیں کیا کرنے کی ضرورت ہے؟
پوسٹگریس خود بخود تعطل کے حالات کو نوٹ کرتا ہے۔ اور یہ خود بخود ایک سیشن کو حذف کر دے گا۔ ڈیڈ بلاکنگ سے بچنے کا واحد طریقہ لوگوں کو اسی ترتیب میں بلاک کرنا ہے۔ لہذا جب آپ اپنی درخواست کو دیکھتے ہیں، اکثر تعطل کی وجہ... آئیے تصور کریں کہ میں دو مختلف چیزوں کو بلاک کرنا چاہتا ہوں۔ ایک ایپلیکیشن ٹیبل 1 کو لاک کرتی ہے، اور دوسری ایپلی کیشن 2 کو لاک کرتی ہے، اور پھر ٹیبل 1۔ اور تعطل سے بچنے کا سب سے آسان طریقہ یہ ہے کہ آپ اپنی ایپلیکیشن کو دیکھیں اور اس بات کو یقینی بنانے کی کوشش کریں کہ لاکنگ تمام ایپلی کیشنز میں ایک ہی ترتیب سے ہو۔ اور یہ عام طور پر 80% مسائل کو ختم کرتا ہے، کیونکہ ہر قسم کے لوگ یہ ایپلی کیشنز لکھتے ہیں۔ اور اگر آپ انہیں اسی ترتیب سے بلاک کرتے ہیں، تو آپ کو تعطل کی صورتحال کا سامنا نہیں کرنا پڑے گا۔
آپ کی کارکردگی کا بہت بہت شکریہ! آپ نے ویکیوم فل کے بارے میں بات کی اور، اگر میں صحیح طور پر سمجھتا ہوں، تو ویکیوم فل الگ اسٹوریج میں ریکارڈز کی ترتیب کو بگاڑ دیتا ہے، اس لیے وہ موجودہ ریکارڈ کو غیر تبدیل شدہ رکھتے ہیں۔ ویکیوم فل خصوصی لاک رسائی کیوں لیتا ہے اور یہ تحریری کارروائیوں سے کیوں متصادم ہے؟
یہ ایک اچھا سوال ہے۔ وجہ یہ ہے کہ ویکیوم فل ٹیبل لیتا ہے۔ اور ہم بنیادی طور پر ٹیبل کا ایک نیا ورژن بنا رہے ہیں۔ اور میز نیا ہو جائے گا. یہ پتہ چلتا ہے کہ یہ ٹیبل کا بالکل نیا ورژن ہوگا۔ اور مسئلہ یہ ہے کہ جب ہم ایسا کرتے ہیں تو ہم نہیں چاہتے کہ لوگ اسے پڑھیں کیونکہ ہمیں ان کی ضرورت ہے کہ وہ نیا ٹیبل دیکھیں۔ اور اس طرح یہ پچھلے سوال سے جڑتا ہے۔ اگر ہم ایک ہی وقت میں پڑھ سکتے ہیں، تو ہم اسے منتقل نہیں کر سکیں گے اور لوگوں کو ایک نئی میز کی طرف لے جا سکیں گے۔ ہمیں ہر ایک کے اس ٹیبل کو پڑھنا ختم کرنے کا انتظار کرنا ہوگا، اور اس لیے یہ بنیادی طور پر ایک خصوصی صورت حال ہے۔
ہم صرف یہ کہتے ہیں کہ ہم شروع سے ہی مقفل کرتے ہیں کیونکہ ہم جانتے ہیں کہ بالکل آخر میں ہمیں ہر ایک کو نئی کاپی پر منتقل کرنے کے لیے ایک خصوصی تالے کی ضرورت ہوگی۔ تو ہم ممکنہ طور پر اس کو حل کر سکتے ہیں۔ اور ہم اسے بیک وقت انڈیکسنگ کے ساتھ اس طرح کرتے ہیں۔ لیکن یہ کرنا بہت زیادہ مشکل ہے۔ اور اس کا تعلق لاک خصوصی کے بارے میں آپ کے پچھلے سوال سے ہے۔
کیا پوسٹگریس میں لاکنگ ٹائم آؤٹ شامل کرنا ممکن ہے؟ اوریکل میں، میں، مثال کے طور پر، "اپ ڈیٹ کرنے کے لیے منتخب کریں" لکھ سکتا ہوں اور اپ ڈیٹ کرنے سے پہلے 50 سیکنڈ انتظار کر سکتا ہوں۔ یہ درخواست کے لیے اچھا تھا۔ لیکن پوسٹگریس میں، مجھے یا تو اسے فوراً کرنے کی ضرورت ہے اور بالکل انتظار نہیں کرنا، یا کچھ وقت تک انتظار کرنا ہے۔
ہاں، آپ اپنے تالے پر، اپنے تالے پر ٹائم آؤٹ کا انتخاب کر سکتے ہیں۔ آپ نو وے کمانڈ بھی جاری کر سکتے ہیں، جو... اگر آپ فوری طور پر لاک حاصل نہیں کر سکتے ہیں۔ لہذا، یا تو لاک ٹائم آؤٹ یا کوئی اور چیز جو آپ کو ایسا کرنے کی اجازت دے گی۔ یہ نحوی سطح پر نہیں کیا جاتا ہے۔ یہ سرور پر متغیر کے طور پر کیا جاتا ہے۔ کبھی کبھی یہ استعمال نہیں کیا جا سکتا.
کیا آپ سلائیڈ 75 کھول سکتے ہیں؟
جی ہاں.
اور میرا سوال درج ذیل ہے۔ دونوں اپ ڈیٹ کے عمل 703 کی توقع کیوں کر رہے ہیں؟
اور یہ ایک بہت بڑا سوال ہے۔ مجھے سمجھ نہیں آتی، ویسے، پوسٹگریس ایسا کیوں کرتا ہے۔ لیکن جب 703 بنایا گیا تو یہ 702 کی توقع کر رہا تھا۔ اور جب 704 اور 705 ظاہر ہوتے ہیں تو ایسا لگتا ہے کہ وہ نہیں جانتے کہ وہ کیا توقع کر رہے ہیں کیونکہ وہاں ابھی کچھ نہیں ہے۔ اور پوسٹگریس اس طرح کرتا ہے: جب آپ کو تالا نہیں ملتا، تو یہ لکھتا ہے "آپ پر کارروائی کرنے کا کیا فائدہ؟"، کیونکہ آپ پہلے ہی کسی کا انتظار کر رہے ہیں۔ تو ہم اسے ہوا میں ہی معلق رہنے دیں گے، یہ اسے بالکل بھی اپ ڈیٹ نہیں کرے گا۔ لیکن یہاں کیا ہوا؟ جیسے ہی 702 نے عمل مکمل کیا اور 703 کو اس کا لاک موصول ہوا، سسٹم واپس آگیا۔ اور اس نے کہا کہ اب ہمارے پاس دو لوگ ہیں جو انتظار کر رہے ہیں۔ اور پھر آئیے ان کو ایک ساتھ اپ ڈیٹ کریں۔ اور ہم اشارہ کرتے ہیں کہ دونوں توقع کر رہے ہیں۔
مجھے نہیں معلوم کہ پوسٹگریس ایسا کیوں کرتا ہے۔ لیکن ایک مسئلہ ہے جسے f…. مجھے لگتا ہے کہ یہ روسی زبان میں کوئی اصطلاح نہیں ہے۔ یہ تب ہوتا ہے جب ہر کوئی ایک قلعے کا انتظار کر رہا ہوتا ہے، چاہے 20 حکام ہی محل کے انتظار میں ہوں۔ اور اچانک وہ سب ایک ہی وقت میں جاگ اٹھے۔ اور ہر کوئی ردعمل ظاہر کرنے کی کوشش کرنے لگتا ہے۔ لیکن سسٹم ایسا بناتا ہے کہ ہر کوئی 703 کا انتظار کر رہا ہے۔ کیونکہ وہ سب انتظار کر رہے ہیں، اور ہم فوری طور پر ان سب کو لائن کر دیں گے۔ اور اگر کوئی اور نئی درخواست ظاہر ہوتی ہے جو اس کے بعد پیدا ہوئی تھی، مثال کے طور پر، 707، تو پھر خالی پن ہو جائے گا۔
اور مجھے لگتا ہے کہ ایسا اس لیے کیا گیا ہے کہ ہم یہ کہہ سکیں کہ اس مرحلے پر 702 703 کا انتظار کر رہا ہے، اور اس کے بعد آنے والوں کو اس میدان میں کوئی داخلہ نہیں ملے گا۔ لیکن جیسے ہی پہلا ویٹر چلا جاتا ہے، وہ تمام لوگ جو اپ ڈیٹ سے پہلے اس لمحے انتظار کر رہے تھے ایک ہی ٹوکن وصول کرتے ہیں۔ اور اس لیے میں سمجھتا ہوں کہ ایسا اس لیے کیا گیا ہے تاکہ ہم ترتیب سے کارروائی کر سکیں تاکہ وہ صحیح طریقے سے ترتیب دی جائیں۔
میں نے اسے ہمیشہ ایک عجیب و غریب واقعہ کے طور پر دیکھا۔ کیونکہ یہاں، مثال کے طور پر، ہم ان کو بالکل بھی درج نہیں کرتے ہیں۔ لیکن مجھے ایسا لگتا ہے کہ جب بھی ہم کوئی نیا تالا دیتے ہیں، ہم ان تمام لوگوں کو دیکھتے ہیں جو انتظار کے مراحل میں ہیں۔ پھر ہم ان سب کو قطار میں کھڑا کرتے ہیں۔ اور پھر جو بھی نیا آتا ہے وہ صرف اس وقت قطار میں آتا ہے جب اگلا شخص کارروائی مکمل کر لیتا ہے۔ بہت اچھا سوال ہے۔ آپ کے سوال کا بہت بہت شکریہ!
مجھے ایسا لگتا ہے کہ جب 705 704 کی توقع کرتا ہے تو یہ بہت زیادہ منطقی ہے۔
لیکن یہاں مسئلہ درج ذیل ہے۔ تکنیکی طور پر، آپ ایک یا دوسرے کو جاگ سکتے ہیں۔ اور اس طرح ہم ایک یا دوسرے سے جاگیں گے۔ لیکن نظام میں کیا ہوتا ہے؟ آپ دیکھ سکتے ہیں کہ کس طرح سب سے اوپر 703 نے اپنی ہی ٹرانزیکشن آئی ڈی کو بلاک کر دیا ہے۔ پوسٹگریس اس طرح کام کرتا ہے۔ اور 703 کو اس کی اپنی ٹرانزیکشن آئی ڈی سے بلاک کر دیا گیا ہے، اس لیے اگر کوئی انتظار کرنا چاہتا ہے، تو وہ 703 کا انتظار کرے گا۔ اور جوہر میں، 703 مکمل ہو جاتا ہے۔ اور اس کی تکمیل کے بعد ہی کوئی ایک عمل بیدار ہوتا ہے۔ اور ہم نہیں جانتے کہ یہ کس قسم کا عمل ہوگا۔ پھر ہم آہستہ آہستہ ہر چیز پر عملدرآمد کرتے ہیں۔ لیکن یہ واضح نہیں ہے کہ کون سا عمل پہلے بیدار ہوتا ہے، کیونکہ یہ ان میں سے کوئی بھی عمل ہوسکتا ہے۔ بنیادی طور پر، ہمارے پاس ایک شیڈولر تھا جس نے کہا کہ اب ہم ان میں سے کسی بھی عمل کو بیدار کر سکتے ہیں۔ ہم صرف بے ترتیب میں ایک چنتے ہیں۔ لہٰذا ان دونوں کو نوٹ کرنے کی ضرورت ہے کیونکہ ہم ان میں سے کسی ایک کو بھی بیدار کر سکتے ہیں۔
اور مسئلہ یہ ہے کہ ہمارے پاس CP-infinity ہے۔ اور اس وجہ سے، یہ کافی امکان ہے کہ ہم بعد میں جاگ سکتے ہیں۔ اور اگر، مثال کے طور پر، ہم بعد والے کو بیدار کرتے ہیں، تو ہم اس کا انتظار کریں گے جسے ابھی بلاک ملا ہے، اس لیے ہم اس بات کا تعین نہیں کرتے کہ پہلے کس کو بیدار کیا جائے گا۔ ہم صرف ایسی صورت حال پیدا کرتے ہیں، اور نظام انہیں بے ترتیب ترتیب میں بیدار کر دے گا۔
ہے . دیکھو وہ بھی دلچسپ اور مفید ہیں۔ موضوع، یقینا، بہت پیچیدہ ہے. آپ کا بہت بہت شکریہ، بروس!
ماخذ: www.habr.com