PostgreSQL کے اندرونی میکانزم کی خصوصیات اسے کچھ حالات میں بہت تیز اور دوسروں میں "بہت تیز نہیں" ہونے دیتی ہیں۔ آج ہم DBMS کے کام کرنے کے طریقہ کار اور اس کے ساتھ ڈویلپر کیا کرتا ہے کے درمیان تنازعہ کی ایک بہترین مثال پر توجہ مرکوز کریں گے۔ اپ ڈیٹ بمقابلہ MVCC اصول.
سے مختصر کہانی :
جب ایک قطار کو اپ ڈیٹ کمانڈ کے ذریعے تبدیل کیا جاتا ہے، تو اصل میں دو آپریشن کیے جاتے ہیں: DELETE اور INSERT۔ میں تار کا موجودہ ورژن xmax اس ٹرانزیکشن کی تعداد کے برابر سیٹ ہے جس نے اپ ڈیٹ کیا تھا۔ پھر اس کی تخلیق ہوتی ہے۔ ایک نیا ورژن ایک ہی لائن؛ اس کی xmin قدر پچھلے ورژن کی xmax قدر کے ساتھ ملتی ہے۔
اس لین دین کے مکمل ہونے کے کچھ وقت بعد، پرانے یا نئے ورژن پر منحصر ہے۔ COMMIT/ROOLBACK، تسلیم کیا جائے گا۔ "مردہ" (مردہ ٹیپلز) گزرتے وقت VACUUM میز کے مطابق اور صاف.
لیکن یہ فوری طور پر نہیں ہوگا، لیکن "مردہ" کے ساتھ مسائل بہت جلد حاصل کیے جا سکتے ہیں - بار بار یا ایک بڑی میز میں، اور تھوڑی دیر بعد آپ کو اسی صورت حال کا سامنا کرنا پڑے گا .
#1: میں اسے منتقل کرنا پسند کرتا ہوں۔
فرض کریں کہ آپ کا طریقہ کار کاروباری منطق پر کام کر رہا ہے، اور اچانک اسے احساس ہوا کہ کسی ریکارڈ میں X فیلڈ کو اپ ڈیٹ کرنا ضروری ہوگا۔
UPDATE tbl SET X = <newX> WHERE pk = $1;پھر، جیسے جیسے عمل درآمد ہوتا ہے، یہ پتہ چلتا ہے کہ Y فیلڈ کو بھی اپ ڈیٹ کیا جانا چاہئے:
UPDATE tbl SET Y = <newY> WHERE pk = $1;... اور پھر Z بھی - کیوں چھوٹی چھوٹی باتوں پر وقت ضائع کریں؟
UPDATE tbl SET Z = <newZ> WHERE pk = $1;اب ہمارے پاس ڈیٹا بیس میں اس ریکارڈ کے کتنے ورژن ہیں؟ جی ہاں، 4 ٹکڑے! ان میں سے، ایک متعلقہ ہے، اور 3 کو آپ کے بعد [آٹو]ویکیوم کے ذریعے صاف کرنا پڑے گا۔
اس طرح مت کرو! استعمال کریں۔ ایک درخواست میں تمام فیلڈز کو اپ ڈیٹ کرنا - تقریبا ہمیشہ طریقہ کار کی منطق کو اس طرح تبدیل کیا جاسکتا ہے:
UPDATE tbl SET X = <newX>, Y = <newY>, Z = <newZ> WHERE pk = $1;#2: استعمال کریں IS DSTINCT FROM، لیوک!
تو، آپ اب بھی چاہتے تھے (مثال کے طور پر اسکرپٹ یا کنورٹر کے استعمال کے دوران)۔ اور اس طرح کچھ اسکرپٹ میں اڑتا ہے:
UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2;تقریباً اس فارم میں ایک درخواست اکثر اور تقریباً ہمیشہ خالی نئی فیلڈ کو پُر کرنے کے لیے نہیں، بلکہ ڈیٹا میں کچھ غلطیوں کو درست کرنے کے لیے ہوتی ہے۔ ایک ہی وقت میں، وہ خود موجودہ ڈیٹا کی درستگی کو بالکل بھی مدنظر نہیں رکھا جاتا ہے۔ - لیکن بیکار! یعنی، ریکارڈ کو دوبارہ لکھا جاتا ہے، چاہے اس میں وہی موجود ہو جو مطلوب تھا - لیکن کیوں؟ آئیے اسے ٹھیک کریں:
UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2 AND X IS DISTINCT FROM <newX>;
بہت سے لوگ اس طرح کے ایک شاندار آپریٹر کے وجود سے واقف نہیں ہیں، لہذا یہاں ایک دھوکہ دہی کی شیٹ ہے IS DISTINCT FROM اور دیگر منطقی آپریٹرز مدد کرنے کے لیے:
... اور کمپلیکس پر آپریشنز کے بارے میں تھوڑا سا ROW()- تاثرات:
#3: میں اپنے پیارے کو... بلاک کرکے پہچانتا ہوں۔
شروع کیے جا رہے ہیں دو ایک جیسے متوازی عمل، جن میں سے ہر ایک اندراج کو نشان زد کرنے کی کوشش کرتا ہے کہ یہ "جاری ہے":
UPDATE tbl SET processing = TRUE WHERE pk = $1;یہاں تک کہ اگر یہ عمل درحقیقت ایک دوسرے سے آزادانہ کام کرتے ہیں، لیکن ایک ہی ID کے اندر، دوسرا کلائنٹ اس درخواست پر "لاک" رہے گا جب تک کہ پہلی ٹرانزیکشن مکمل نہ ہوجائے۔
حل نمبر 1: کام کو پچھلے ایک تک کم کر دیا گیا ہے۔
آئیے اسے دوبارہ شامل کریں۔ IS DISTINCT FROM:
UPDATE tbl SET processing = TRUE WHERE pk = $1 AND processing IS DISTINCT FROM TRUE;اس فارم میں، دوسری درخواست صرف ڈیٹا بیس میں کچھ بھی تبدیل نہیں کرے گی، سب کچھ پہلے سے ہی ہے جیسا کہ ہونا چاہئے - لہذا، بلاکنگ واقع نہیں ہوگی. اگلا، ہم لاگو الگورتھم میں ریکارڈ کو "نہ ڈھونڈنے" کی حقیقت پر کارروائی کرتے ہیں۔
حل نمبر 2: مشاورتی تالے
ایک الگ مضمون کے لیے ایک بڑا موضوع، جس میں آپ پڑھ سکتے ہیں۔ .
حل نمبر 3: احمقانہ کالز
لیکن یہ بالکل وہی ہے جو آپ کے ساتھ ہونا چاہئے ایک ہی ریکارڈ کے ساتھ بیک وقت کام? یا مثال کے طور پر، آپ نے کلائنٹ کی طرف سے کاروباری منطق کو کال کرنے کے الگورتھم کے ساتھ گڑبڑ کی؟ اور اگر آپ اس کے بارے میں سوچتے ہیں؟
ماخذ: www.habr.com