PostgreSQL Antipatterns: ”مئل“ جي لشڪر سان وڙهڻ

PostgreSQL جي اندروني ميڪانيزم جون خاصيتون ان کي ڪجهه حالتن ۾ تمام تيز ۽ ٻين ۾ "تمام تيز نه" جي اجازت ڏين ٿيون. اڄ اسان هڪ شاندار مثال تي ڌيان ڏينداسين تڪرار جي وچ ۾ هڪ DBMS ڪيئن ڪم ڪري ٿو ۽ ڊولپر ان سان ڇا ڪندو آهي. تازه ڪاري بمقابله MVCC اصول.

کان مختصر ڪهاڻي عظيم مضمون:

جڏهن هڪ قطار UPDATE حڪم جي ذريعي تبديل ڪئي وئي آهي، ٻه عمل اصل ۾ ڪيا ويا آهن: DELETE ۽ INSERT. IN تار جو موجوده نسخو xmax مقرر ڪيل ٽرانزيڪشن جي تعداد جي برابر آهي جيڪا تازه ڪاري ڪئي. ان کان پوء اهو ٺهيل آهي هڪ نئون نسخو ساڳي لائن؛ ان جي xmin قدر اڳئين ورزن جي xmax قدر سان ٺهڪي اچي ٿي.

هن ٽرانزيڪشن مڪمل ٿيڻ کان پوء ڪجهه وقت، پراڻو يا نئون نسخو، منحصر آهي COMMIT/ROOLBACK، تسليم ڪيو ويندو "مئل" (مردار ٽوپل) جڏهن گذري ٿو VACUUM ٽيبل جي مطابق ۽ صاف.

پر اهو فوري طور تي نه ٿيندو، پر "مئل" سان مسئلا تمام جلدي حاصل ڪري سگھجن ٿيون - بار بار سان يا رڪارڊ جي وڏي تازه ڪاري هڪ وڏي ٽيبل ۾، ۽ ٿوري دير کان پوء توهان ساڳئي صورتحال کي منهن ڏيندو VACUUM مدد ڪرڻ جي قابل نه هوندا.

#1: مان ان کي منتقل ڪرڻ پسند ڪريان ٿو

اچو ته توهان جو طريقو ڪاروبار منطق تي ڪم ڪري رهيو آهي، ۽ اوچتو اهو محسوس ٿئي ٿو ته اهو ضروري هوندو ته ايڪس فيلڊ کي اپڊيٽ ڪرڻ لاء ڪجهه رڪارڊ ۾:

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 DISTINCT 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