ڪنهن ڏينهن ڏور مستقبل ۾، غير ضروري ڊيٽا جي خودڪار هٽائڻ هڪ DBMS جي اهم ڪمن مان هڪ هوندو [1]. ساڳئي وقت ۾، اسان کي پاڻ کي غير ضروري ڊيٽا کي ختم ڪرڻ يا منتقل ڪرڻ جو خيال رکڻو پوندو گهٽ قيمتي اسٽوريج سسٽم ۾. اچو ته چئو ته توهان ڪيترن ئي ملين قطار کي ختم ڪرڻ جو فيصلو ڪيو. هڪ بلڪل سادو ڪم، خاص طور تي جيڪڏهن حالت ڄاڻايل آهي ۽ هڪ مناسب انڊيڪس آهي. "ٽيبل 1 مان هٽايو جتي col1 = :value" - ڇا وڌيڪ آسان ٿي سگهي ٿو، صحيح؟
وڊيو:
-
مان پهريون سال يعني 2007 کان وٺي هاءِ لوڊ پروگرام ڪميٽي تي آهيان.
-
۽ مان 2005 کان پوسٽ گريس سان گڏ آهيان. ان کي ڪيترن ئي منصوبن ۾ استعمال ڪيو.
-
گروپ پڻ 2007 کان RuPostges سان گڏ آھي.
-
اسان ميٽ اپ تي 2100 کان وڌيڪ شرڪت ڪندڙن تائين پهچي چڪا آهيون. نيو يارڪ کانپوءِ دنيا ۾ اهو ٻيو نمبر آهي، جيڪو گهڻو وقت اڳ سان فرانسسڪو کي پوئتي هٽائي چڪو آهي.
-
مان ڪيترن سالن کان ڪيليفورنيا ۾ رهي رهيو آهيان. مان اڪثر آمريڪي ڪمپنين سان گڏ ڪم ڪندو آهيان، جن ۾ وڏيون ڪمپنيون شامل آهن. اهي فعال پوسٽ گريس استعمال ڪندڙ آهن. ۽ اتي تمام دلچسپ شيون پيدا ٿين ٿيون.
- هي منهنجي ڪمپني آهي. اسان خودڪار ڪمن جي ڪاروبار ۾ آهيون جيڪي ترقي جي سست کي ختم ڪن ٿا.
جيڪڏهن توهان ڪجهه ڪريو ٿا، ڪڏهن ڪڏهن پوسٽ گريس جي چوڌاري ڪجهه خرابيون آهن. اچو ته توهان کي انتظار ڪرڻ جي ضرورت آهي جيستائين منتظم توهان کي ٽيسٽ بينچ حاصل ڪري، يا توهان کي انتظار ڪرڻو پوندو جيستائين DBA توهان کي جواب ڏئي. ۽ اسان ترقي، جاچ ۽ انتظامي عمل ۾ اهڙيون رڪاوٽون ڳوليون ٿا ۽ انهن کي آٽوميشن ۽ نوان طريقا استعمال ڪندي ختم ڪرڻ جي ڪوشش ڪندا آهيون.
مان تازو ئي لاس اينجلس ۾ VLDB تي هوس. هي سڀ کان وڏي ڊيٽابيس ڪانفرنس آهي. ۽ اتي هڪ رپورٽ آهي ته مستقبل ۾ DBMSs نه رڳو ذخيرو ڪندو، پر پڻ خودڪار طريقي سان ڊيٽا کي حذف. هي هڪ نئون موضوع آهي.
دنيا ۾ وڌيڪ ۽ وڌيڪ ڊيٽا آهي Zetabytes 1 petabytes آهن. ۽ هاڻي اهو اڳ ۾ ئي اندازو لڳايو ويو آهي ته اسان وٽ دنيا ۾ 000 زيٽابائٽس کان وڌيڪ ڊيٽا محفوظ آهي. ۽ انهن مان وڌيڪ ۽ وڌيڪ آهن.
۽ ان سان ڇا ڪجي؟ اهو واضح آهي ته ان کي ختم ڪرڻ جي ضرورت آهي. هتي هن دلچسپ رپورٽ جي هڪ لنڪ آهي. پر هن وقت تائين DBMS ۾ ان تي عمل نه ڪيو ويو آهي.
جيڪي ڄاڻن ٿا پئسو ڪيئن ڳڻيو اُھي ٻه شيون چاھين ٿا. اهي اسان کي ختم ڪرڻ چاهيندا آهن، تنهنڪري ٽيڪنالاجي طور اسان کي اهو ڪرڻ جي قابل هوندو.
جيڪو مان اڳتي ٻڌايان ٿو اهو هڪ تجريدي صورتحال آهي جنهن ۾ حقيقي حالتن جو هڪ گروپ شامل آهي، اهو آهي، هڪ خاص تالیف جيڪو اصل ۾ مون سان ۽ ڀرپاسي جي ڊيٽابيسس سان ڪيترائي ڀيرا، ڪيترن سالن کان ٿيو. ريڪ هر جڳهه آهن ۽ هرڪو هر وقت انهن تي قدم رکي ٿو.
اچو ته اسان وٽ ھڪڙو بنياد آھي يا ڪيترائي اڪا آھن جيڪي وڌي رھيا آھن. ۽ ڪجهه رڪارڊ واضح گندگي آهن. مثال طور، صارف اتي ڪجھ ڪم ڪرڻ شروع ڪيو، پر ختم نه ڪيو. ۽ ڪجهه وقت کان پوء اسان کي خبر آهي ته هن نامڪمل ڪم کي وڌيڪ محفوظ نه ٿو ڪري سگهجي. اهو آهي، اسان ڪجهه فضول شين کي صاف ڪرڻ چاهيندا آهيون خلا کي بچائڻ، ڪارڪردگي بهتر ڪرڻ، وغيره.
عام طور تي، ڪم کي خودڪار ڪرڻ آهي مخصوص شين کي ختم ڪرڻ، مخصوص لائينون ميز ۾.
۽ اسان کي هڪ گذارش آهي ته اسين اڄ ڳالهائينداسين، يعني ڪچرو هٽائڻ بابت.
اسان هڪ تجربيڪار ڊولپر کي اهو ڪرڻ لاءِ چيو. هن درخواست ورتي، ان کي پاڻ چيڪ ڪيو - سڀڪنھن شيء کي ڪم. مون ان کي اسٽيجنگ تي آزمايو - سڀ ڪجھ ٺيڪ آهي. ان کي ٻاهر ڪڍيو - سڀڪنھن شيء کي ڪم. هڪ ڏينهن ۾ هڪ ڀيرو اسين هن کي هلون ٿا - سڀ ڪجهه ٺيڪ آهي.
ڊيٽابيس وڌي رهيو آهي ۽ وڌي رهيو آهي. روزانو DELETE ٿورڙو سست ڪم ڪرڻ شروع ڪري ٿو.
پوءِ اسان محسوس ڪيو ته اسان هاڻي هڪ مارڪيٽنگ ڪمپني آهيون ۽ ٽرئفڪ ڪيترائي ڀيرا وڌيڪ هوندي، تنهنڪري اسان غير ضروري شين کي عارضي طور تي روڪڻ جو فيصلو ڪيو. ۽ اسان ان کي واپس ڪرڻ وساريو.
ڪجهه مهينن بعد انهن کي ياد آيو. ۽ اهو ڊولپر ڇڏي ويو يا ڪنهن ٻئي سان مصروف هو، انهن کي واپس ڪرڻ لاء هڪ ٻئي کي مقرر ڪيو.
هن ديو تي چيڪ ڪيو، اسٽيجنگ تي - سڀ ڪجهه ٺيڪ آهي. قدرتي طور، توهان کي اڃا تائين صاف ڪرڻ جي ضرورت آهي جيڪا جمع ڪئي وئي آهي. هن چيڪ ڪيو، سڀ ڪجهه ڪم ڪري ٿو.
اڳتي ڇا ٿيندو؟ پوءِ سڀ ڪجهه اسان لاءِ ڌار ٿي ويندو. اهو ايترو ته گهٽجي ٿو جو ڪنهن وقت هر شيءِ هيٺ اچي وڃي ٿي. هر ڪو صدمي ۾ آهي، ڪنهن کي سمجهه ۾ نٿو اچي ته ڇا ٿي رهيو آهي. ۽ پوء اهو ظاهر ٿيو ته هي DELETE مسئلو هو.
ڪجهه غلط ٿيو؟ هتي شين جي هڪ فهرست آهي جيڪا غلط ٿي سگهي ٿي. انهن مان ڪهڙو سڀ کان اهم آهي؟
-
مثال طور، ڪو به جائزو نه هو، يعني DBA ماهر نظر نه آيو. هڪ تجربيڪار اکين سان، هو فوري طور تي مسئلو ڳولي سگهندو، ۽ ان کان علاوه، هن کي پروڊ تائين رسائي آهي، جتي ڪيترائي ملين لائينون گڏ ڪيون ويون آهن.
-
ٿي سگهي ٿو ته انهن ڪجهه غلط چيڪ ڪيو.
-
ٿي سگهي ٿو هارڊويئر پراڻي آهي ۽ توهان کي هن ڊيٽابيس کي اپڊيٽ ڪرڻ جي ضرورت آهي.
-
يا ڊيٽابيس پاڻ ۾ ڪجهه غلط آهي، ۽ اسان کي Postgres کان MySQL ڏانهن منتقل ڪرڻ جي ضرورت آهي.
-
يا ٿي سگهي ٿو اتي آپريشن سان ڪجهه غلط آهي.
-
ٿي سگهي ٿو ڪم جي تنظيم ۾ ڪجهه غلطيون آهن ۽ توهان کي ڪنهن کي برطرف ڪرڻ ۽ بهتر ماڻهن کي نوڪري ڏيڻ جي ضرورت آهي؟
ڪوبه DBA چيڪ نه هو. جيڪڏهن ڪو ڊي بي اي هجي ها ته هو اهي لکين لک لائينون ڏسن ها ۽ بغير ڪنهن تجربي جي به چون ها: ”اهي ائين نٿا ڪن. اچو ته چئو ته اهو ڪوڊ GitLab، GitHub ۾ هو ۽ ڪوڊ جي نظرثاني جو عمل هو ۽ اتي ڪا به شيءِ نه هئي ته ڊي بي اي جي منظوري کان سواءِ اهو آپريشن پروڊ تي ٿئي ها، پوءِ ظاهر آهي ڊي بي اي چوندو: ”توهان ائين نٿا ڪري سگهو. ”
۽ هو چوندو ته توهان کي ڊسڪ IO سان مسئلو هوندو ۽ سڀ عمل چريو ٿي ويندا، اتي لاڪ به ٿي سگهي ٿو، ۽ توهان به آٽو ويڪيوم کي ڪجهه منٽن لاءِ بلاڪ ڪري ڇڏيندا، تنهنڪري اهو سٺو ناهي.
ٻي غلطي اها آهي ته انهن غلط جاءِ تي چيڪ ڪيو. اسان ان حقيقت کان پوءِ ڏٺو ته پروڊ تي ڪچري جي تمام گھڻي ڊيٽا جمع ٿي چڪي هئي، پر ڊولپر ان ڊيٽابيس ۾ ڊيٽا گڏ نه ڪئي هئي، ۽ نه ئي ڪنهن واقعي اهو ڪچرو اسٽيجنگ تي ٺاهيو هو. ان حساب سان، 1 لائينون هيون، جيڪي جلدي مڪمل ڪيون ويون.
اسان سمجھون ٿا ته اسان جا امتحان ڪمزور آھن، يعني اھو عمل جيڪو ٺھيل آھي ان ۾ مسئلا پيدا نه ٿين. هڪ مناسب ڊي بي تجربو نه ڪيو ويو.
هڪ مثالي تجربو ترجيحي طور تي ساڳيو سامان تي ڪيو وڃي. اهو هميشه ممڪن ناهي ته اهو ساڳيو هارڊويئر تي ڪيو وڃي، پر اهو تمام ضروري آهي ته اهو ڊيٽابيس جي مڪمل سائيز ڪاپي آهي. اھو اھو آھي جيڪو مان ھاڻي ڪيترن سالن کان تبليغ ڪري رھيو آھيان. ۽ هڪ سال اڳ مون هن بابت ڳالهايو، توهان اهو سڀ يوٽيوب تي ڏسي سگهو ٿا.
ٿي سگهي ٿو اسان جو سامان خراب آهي؟ جيڪڏهن توهان ڏسندا، دير سان ٽپو ويو آهي. اسان ڏٺو ته ري سائیکلنگ 100٪ هئي. يقينا، جيڪڏهن اهي جديد NVMe ڊرائيو هئا، پوء اهو شايد اسان لاء تمام آسان هوندو. ۽ شايد اسان ان جي ڪري نه ليٽنداسين.
جيڪڏھن توھان وٽ بادل آھن، پوء اپ گريڊ آسان آھي. اسان نئين هارڊويئر تي نوان نقل شروع ڪيا. مٽائڻ. ۽ سڀ ٺيڪ آهي. ڪافي آسان.
ڇا اهو ممڪن آهي ته ڪنهن به ننڍڙي ڊسڪ کي ڇڪڻ لاء؟ ۽ هتي، ڊي بي اي جي مدد سان، اسان هڪ خاص موضوع ۾ داخل ڪيو جنهن کي چيڪ پوائنٽ ٽيوننگ سڏيو ويندو آهي. اهو ظاهر ٿئي ٿو ته اسان وٽ چيڪ پوائنٽ ٽيوننگ نه هئي.
هڪ چيڪ پوائنٽ ڇا آهي؟ اهو ڪنهن به DBMS ۾ موجود آهي. جڏهن توهان جي ميموري ۾ ڊيٽا تبديل ٿئي ٿي، اهو فوري طور تي ڊسڪ ڏانهن نه لکيو ويو آهي. معلومات جيڪا ڊيٽا تبديل ڪئي وئي آهي پهريون ڀيرو اڳتي وڌڻ واري لاگ ڏانهن، لکڻ جي اڳيان لاگ ۾. ۽ ڪجهه نقطي تي، ڊي بي ايم ايس اهو فيصلو ڪري ٿو ته اهو حقيقي صفحن کي ڊسڪ تي اڇلائڻ جو وقت آهي، انهي ڪري ته جيڪڏهن اسان کي ناڪام ٿئي ٿي، اسان گهٽ REDO ڪري سگهون ٿا. اهو هڪ رانديڪو وانگر آهي. جيڪڏهن اسان کي ماريو ويو ته اسان راند کي آخري چوڪي کان شروع ڪنداسين. ۽ سڀ ڊي بي ايم ايس هن کي لاڳو ڪن ٿا.
Postgres ۾ سيٽنگون پوئتي پيل آهن. اهي 10-15 سالن جي پراڻي مقدار جي ڊيٽا ۽ عملن لاءِ ٺهيل آهن. ۽ چيڪ پوائنٽ ڪو به استثنا نه آهي.
اها معلومات اسان جي رپورٽ مان آهي Postgres چيڪ اپ سان، يعني خودڪار صحت جي چڪاس. ۽ هتي ڪيترن ئي terabytes جو ڪجهه ڊيٽابيس آهي. ۽ اهو واضح آهي ته چيڪ پوسٽون تقريبن 90 سيڪڙو ڪيسن ۾ مجبور آهن.
هن جو ڇا مطلب آهي؟ اتي ٻه سيٽنگون آهن. چيڪ پوائنٽ ٽائيم آئوٽ ۾ ٿي سگھي ٿو، مثال طور، 10 منٽن ۾. يا اهو ٿي سگهي ٿو جڏهن ڪافي ڊيٽا ڀريو ويو آهي.
۽ ڊفالٽ طور، max_wal_saze مقرر ڪيو ويو آھي 1 گيگا بائيٽ. حقيقت ۾، اهو اصل ۾ ٿئي ٿو Postgres ۾ 300-400 ميگا بائيٽ کان پوء. توهان تمام گهڻو ڊيٽا تبديل ڪيو آهي ۽ توهان وٽ هڪ چيڪ پوائنٽ آهي.
۽ جيڪڏهن ڪو به ان کي ٽيون نه ڪيو، پر خدمت وڌي وئي آهي، ۽ ڪمپني تمام گهڻو پئسا ڪمائي ٿو، ان ۾ تمام گهڻو ٽرانزيڪشن آهي، پوء چيڪ پوائنٽ هڪ منٽ ۾ هڪ ڀيرو ٿيندي آهي، ڪڏهن ڪڏهن هر 30 سيڪنڊن ۾، ۽ ڪڏهن ڪڏهن اهي هڪ ٻئي کي اوورليپ پڻ ڪن ٿا. . هي واقعي خراب آهي.
۽ اسان کي پڪ ڪرڻ جي ضرورت آهي ته اهو گهٽ اڪثر اچي ٿو. اھو آھي، اسان وڌائي سگھون ٿا max_wal_size. ۽ هو گهٽ ۾ گهٽ حملو ڪندو.
پر اسان هڪ مڪمل طريقو ٺاهيو آهي ته اهو ڪيئن ڪجي وڌيڪ صحيح طريقي سان، اهو آهي، سيٽنگون چونڊڻ بابت فيصلا ڪيئن ڪجي، واضح طور تي مخصوص ڊيٽا جي بنياد تي.
ان مطابق، اسان ڊيٽابيس تجربن جا ٻه سلسلو انجام ڏيون ٿا.
پهريون سلسلو - اسان max_wal_size تبديل ڪريون ٿا. ۽ اسان هڪ وڏي آپريشن ڪندا آهيون. پهرين اسان ان کي 1 گيگا بائيٽ جي ڊفالٽ سيٽنگ تي ڪندا آهيون. ۽ اسان ڪيترن ئي لکن لائنن مان وڏي پئماني تي DELETE ڪندا آهيون.
توهان ڏسي سگهو ٿا ته اهو اسان لاء ڪيترو ڏکيو آهي. اسان ڏسون ٿا ته ڊسڪ IO تمام خراب آهي. اچو ته ڏسون ڪيترو وال اسان پيدا ڪيو، ڇاڪاڻ ته اهو تمام ضروري آهي. ڏسون ته ڪيترا ڀيرا چيڪ پوسٽ ٿيو. ۽ اسان ڏسون ٿا ته اهو سٺو ناهي.
اڳتي وڌون ٿا max_wal_size. اسان ورجائي. وڌايو ، ورجايو. ۽ ڪيترائي ڀيرا. اصول ۾، 10 پوائنٽون سٺو آهي، جتي 1، 2، 4، 8 گيگا بائيٽ. ۽ اسان هڪ مخصوص نظام جي رويي کي ڏسو. اهو واضح آهي ته سامان هتي هجڻ گهرجي پروڊ وانگر. توهان وٽ ساڳيو ڊسڪ، ساڳئي مقدار جي ميموري، ۽ ساڳئي پوسٽ گريس سيٽنگون هجڻ گهرجن.
۽ انهي طريقي سان اسان اسان جي سسٽم کي مٽائينداسين، ۽ اسان ڄاڻون ٿا ته ڊي بي ايم ايس خراب ڪاميٽي جي صورت ۾ ڪيئن عمل ڪندو DELETE، اهو ڪيئن چيڪ پوائنٽ ڪندو.
روسي ۾ چيڪ پوائنٽ جو مطلب آهي ڪنٽرول پوائنٽ.
مثال: انڊيڪس ذريعي ڪيترن ئي ملين قطارن کي حذف ڪريو، قطارون صفحا تي ”پکڙيل“ آهن.
هتي هڪ مثال آهي. هي ڪجهه بنياد آهي. ۽ max_wal_size لاءِ 1 گيگا بائيٽ جي ڊفالٽ سيٽنگ سان، اهو بلڪل واضح آهي ته رڪارڊنگ لاءِ اسان جون ڊسڪون شيلف ڏانهن وينديون آهن. هي تصوير هڪ تمام بيمار مريض جي هڪ عام علامت آهي، اهو آهي، هن کي واقعي خراب محسوس ٿيو. ۽ صرف هڪ آپريشن هو، هتي صرف ڪيترن ئي ملين لائينن مان DELETE هو.
جيڪڏهن اهڙي عمل جي اجازت ڏني وئي آهي پروڊ ۾، پوء اسان صرف هيٺ ڪري ڇڏينداسين، ڇاڪاڻ ته اهو واضح آهي ته هڪ DELETE اسان کي شيلف ۾ ماريندو آهي.
وڌيڪ، جتي 16 گيگا بائيٽ آهن، توهان ڏسي سگهو ٿا ته ڏند اڳ ۾ ئي ظاهر ٿيڻ شروع ٿي ويا آهن. ڏند اڳ ۾ ئي بهتر آهن، يعني اسين ڇت تي ڌڪ هڻي رهيا آهيون، پر ايترو خراب ناهي. اتي ٿوري آزادي ظاهر ٿي. ساڄي پاسي رڪارڊنگ آهي. ۽ آپريشن جو تعداد ٻيو گراف آهي. ۽ اهو واضح آهي ته اسان اڳ ۾ ئي 16 گيگا بائيٽ سان ٿورو آسان سانس ڪري رهيا آهيون.
۽ جتي 64 گيگا بائيٽ نظر اچن ٿا، اهو مڪمل طور تي بهتر ٿي چڪو آهي. اڳ ۾ ئي ڏند صاف طور تي نظر اچن ٿا، اتي وڌيڪ موقعا آهن ٻين عملن کي بچائڻ ۽ ڊسڪ سان ڪجهه ڪرڻ لاء.
ائين ڇو
مان تفصيلن ۾ ٿورڙو ڇنڊڇاڻ ڪندس، پر چيڪ پوائنٽ جي ٽيوننگ کي ڪيئن کڻڻ جو هي موضوع هڪ پوري رپورٽ جي نتيجي ۾ ٿي سگهي ٿو، تنهنڪري آئون گهڻو تفصيل ۾ نه ويندس، پر آئون ٿورو بيان ڪندس ته اتي ڪهڙيون مشڪلاتون آهن.
جيڪڏهن چيڪ پوائنٽ گهڻو ڪري ٿئي ٿي، ۽ اسان پنهنجي قطار کي ترتيب سان اپڊيٽ نه ڪندا آهيون، پر انهن کي انڊيڪس ذريعي ڳوليندا آهيون، جيڪو سٺو آهي، ڇاڪاڻ ته اسان سڄي جدول کي ختم نه ڪندا آهيون، پوء اهو ٿي سگهي ٿو ته پهرين اسان پهرين صفحي کي ڇڪيو، پوء هزارون، ۽ پوءِ پھرين ڏانھن موٽيو. ۽ جيڪڏهن انهن دورو جي وچ ۾ پهرين صفحي تي چيڪ پوائنٽ اڳ ۾ ئي ڊسڪ ۾ محفوظ ڪيو آهي، پوء اهو ان کي ٻيهر محفوظ ڪندو، ڇاڪاڻ ته اسان ان کي ٻيو ڀيرو گندو ڪيو آهي.
۽ اسان چيڪ پوائنٽ کي ڪيترائي ڀيرا بچائڻ لاء مجبور ڪنداسين. ڄڻ ته ان لاءِ بيڪار ڪارروايون آهن.
پر اهو سڀ ڪجهه ناهي. Postgres ۾، صفحن جو وزن 8 ڪلو بائيٽ، ۽ لينڪس ۾ 4 ڪلو بائيٽ. ۽ اتي هڪ سيٽنگ آهي full_page_writes. اهو ڊفالٽ طور تي فعال آهي. ۽ اهو صحيح آهي، ڇاڪاڻ ته جيڪڏهن اسان ان کي بند ڪريون ٿا، اهو خطرو آهي ته جيڪڏهن ناڪامي ٿي، ته صفحي جو اڌ حصو بچايو ويندو.
فارورڊ لاگ جي WAL ۾ داخل ٿيڻ جو رويو اهڙو آهي ته جڏهن اسان وٽ هڪ چيڪ پوائنٽ آهي ۽ اسان پهريون ڀيرو هڪ صفحي کي تبديل ڪندا آهيون، سڄو صفحو، يعني سڀ 8 ڪلو بائيٽ، فارورڊ لاگ ۾ ختم ٿي ويندو آهي، جيتوڻيڪ اسان صرف هڪ لڪير کي تبديل ڪيو جنهن جو وزن 100 بائيٽ آهي. ۽ مجبور آهيون ته سڄو صفحو لکڻ تي.
ايندڙ تبديلين ۾ صرف هڪ مخصوص ٽوپل هوندو، پر پهريون ڀيرو اسان سڀ ڪجهه لکندا آهيون.
۽، مطابق، جيڪڏهن چيڪ پوائنٽ ٻيهر ٿئي ٿي، ته پوء اسان کي ٻيهر شروع کان هر شي کي شروع ڪرڻو پوندو ۽ سڄي صفحي کي ڪرم ڪرڻو پوندو. بار بار چيڪ پوسٽن سان، جڏهن اسان ساڳئي صفحن مان هلون ٿا، full_page_writes = on ان کان وڌيڪ ٿي سگهي ٿو، يعني اسان وڌيڪ WAL ٺاهيندا آهيون. وڌيڪ موڪليو ويو نقل ڏانهن، آرڪائيو ڏانهن، ڊسڪ ڏانهن.
۽، مطابق، اسان وٽ ٻه بيڪار آهن.
جيڪڏهن اسان وڌون ٿا max_wal_size، اهو ظاهر ٿئي ٿو ته اسان چيڪ پوائنٽ ۽ وال ليکڪ ٻنهي جي ڪم کي آسان بڻائي سگهون ٿا. ۽ اهو عظيم آهي.
اچو ته هڪ ٽيرا بائيٽ انسٽال ڪريون ۽ ان سان گڏ رهون. ان ۾ ڪهڙي خرابي آهي؟ اهو خراب آهي، ڇاڪاڻ ته ناڪامي جي صورت ۾ اسين ڪلاڪن جا ڪلاڪ اٿنداسين، ڇاڪاڻ ته چيڪ پوسٽ گهڻو وقت اڳ هو ۽ گهڻو ڪجهه تبديل ٿي چڪو آهي. ۽ اسان کي هن سڀني لاءِ REDO ڪرڻ جي ضرورت آهي. ۽ تنهنڪري اسان تجربن جو هڪ ٻيو سلسلو ڪري رهيا آهيون.
اسان آپريشن ڪندا آهيون ۽ ڏسون ٿا جڏهن چيڪ پوائنٽ مڪمل ٿيڻ جي ويجهو آهي، اسان مقصد تي -9 پوسٽ گريس کي قتل ڪريون ٿا.
۽ ان کان پوء، اسان ان کي ٻيهر شروع ڪريون ٿا، ۽ ڏسو ته هن سامان تي اڀرڻ ۾ ڪيترو وقت لڳندو، يعني، هن خراب صورتحال ۾ ڪيترو REDO ڪندو.
مان ٻه ڀيرا نوٽ ڪندس ته صورتحال خراب آهي. پهرين، اسان چيڪ پوائنٽ جي ختم ٿيڻ کان اڳ صحيح ٿي ويا، تنهنڪري اسان کي وڃائڻ لاء گهڻو ڪجهه آهي. ۽ ٻيو، اسان هڪ وڏي آپريشن ڪئي هئي. ۽ جيڪڏهن چيڪ پوسٽن جو وقت ختم ٿئي ها، ته پوءِ تمام گهڻو امڪان گهٽ WAL پيدا ٿئي ها آخري چيڪ پوسٽ کان. اهو آهي، هي هڪ ٻه ڀيرا نقصان وارو آهي.
اسان هن صورتحال کي مختلف max_wal_size لاءِ ماپون ٿا ۽ سمجهون ٿا ته جيڪڏهن max_wal_size 64 گيگا بائيٽ آهي ته پوءِ ٻيڻي بدترين صورتحال ۾ اسان 10 منٽن لاءِ اڀري وينداسين. ۽ اسان سوچيو ته ڇا اهو اسان لاء مناسب آهي يا نه. هي هڪ ڪاروباري مسئلو آهي. اسان کي اها تصوير انهن ماڻهن کي ڏيکارڻ جي ضرورت آهي جيڪي ڪاروباري فيصلن جا ذميوار آهن ۽ پڇڻ گهرجن: ”ڪهڙو وقت آهي جيڪو اسان ڪنهن مسئلي جي صورت ۾ انتظار ڪري سگهون ٿا؟ ڇا اسان وڌيڪ خراب صورتحال ۾ 3-5 منٽن تائين ليٽي سگهون ٿا؟ ۽ تون فيصلو ڪر.
۽ هتي هڪ دلچسپ نقطو آهي. اسان وٽ ڪانفرنس ۾ Patroni بابت ڪجهه رپورٽون آهن. ۽ شايد توهان ان کي استعمال ڪري رهيا آهيو. هي Postgres لاء autofailover آهي. GitLab ۽ ڊيٽا Egret هن بابت ڳالهايو.
۽ جيڪڏهن توهان وٽ هڪ خودڪار ناڪامي آهي جيڪا 30 سيڪنڊن ۾ ٿيندي، پوء شايد اسان 10 منٽن لاء ليٽي سگهون ٿا؟ ڇاڪاڻ ته هن نقطي تائين اسان نقل تي سوئچ ڪنداسين، ۽ سڀ ڪجهه ٺيڪ ٿي ويندو. هي هڪ تڪراري مسئلو آهي. مون کي هڪ واضح جواب نه ڄاڻندا آھن. مان صرف محسوس ڪريان ٿو ته هي موضوع نه رڳو آفت جي بحالي جي چوڌاري آهي.
جيڪڏهن اسان وٽ هڪ ناڪامي کان ڊگهي وصولي آهي، ته پوء اسان ٻين ڪيترن ئي حالتن ۾ ناگزير ٿينداسين. مثال طور، ساڳئي تجربن ۾، جڏهن اسان ڪجهه ڪندا آهيون ۽ ڪڏهن ڪڏهن 10 منٽن تائين انتظار ڪرڻو پوندو.
مان اڃا به گهڻو پري نه وڃان ها، جيتوڻيڪ اسان وٽ خودڪار ناڪامي آهي. ضابطي جي طور تي، قدر جهڙوڪ 64، 100 گيگا بائيٽ سٺو قدر آهن. ڪڏهن ڪڏهن اهو به گهٽ چونڊڻ جي قابل آهي. عام طور تي، هي هڪ ذيلي سائنس آهي.
ٻيهر ڪرڻ لاءِ، مثال طور، max_wal_size = 1، 8، توهان کي ماس آپريشن کي ڪيترائي ڀيرا ورجائڻو پوندو. توهان اهو ڪيو. ۽ توهان ان کي ٻيهر ڪرڻ چاهيو ٿا ساڳئي بنياد تي، پر توهان پهريان ئي هر شيء کي ختم ڪري ڇڏيو آهي. ڇا ڪجي؟
مان توهان کي بعد ۾ ٻڌائيندس اسان جي حل بابت ۽ اسان اهڙين حالتن ۾ ٻيهر ورجائڻ لاءِ ڇا ڪندا آهيون. ۽ اهو سڀ کان وڌيڪ صحيح طريقو آهي.
پر هن معاملي ۾ اسان خوش قسمت هئاسين. جيڪڏهن، جيئن هتي چوي ٿو "BEGIN، DELETE، ROLLBACK"، پوء اسين ٻيهر ڪري سگھون ٿا DELETE. اھو آھي، جيڪڏھن اسان ان کي پاڻ کي منسوخ ڪيو، پوء اسين ان کي ورجائي سگھون ٿا. ۽ جسماني طور تي توهان جي ڊيٽا هوندي. توهان کي ڪو به ٻوٽو نه آهي. توهان اهڙي DELETE تي ٻيهر ڪري سگهو ٿا.
هي DELETE with ROLLBACK چيڪ پوائنٽ ٽيوننگ لاءِ مثالي آهي، جيتوڻيڪ توهان وٽ صحيح طرح سان ترتيب ڏنل ڊيٽابيس ليبز نه آهي.
اسان ھڪڙي ڪالمن سان ھڪڙو نشان ٺاھيو آھي "i". پوسٽ گريس وٽ يوٽيلٽي ڪالم آهن. اهي پوشيده آهن جيستائين خاص طور تي طلب نه ڪيو وڃي. اهي آهن: ctid، xmid، xmax.
Ctid جسماني پتو آهي. صفحو صفر، صفحي ۾ پهريون ٽوپل.
اهو ڏسي سگھجي ٿو ته ROOLBACK کان پوءِ ٽوپل ساڳي جاءِ تي رهي. اهو آهي، اسان ٻيهر ڪوشش ڪري سگهون ٿا، اهو ساڳيو ئي عمل ڪندو. اهو ئي مکيه شيء آهي.
ايڪس اينڪس ٽپل جي موت جو وقت آهي. اهو داخل ڪيو ويو آهي، پر پوسٽ گريس ڄاڻي ٿو ته هي ٽرانزيڪشن واپس هليو ويو، تنهنڪري اهو مسئلو ناهي ته اهو 0 آهي يا هڪ رول واپس ٽرانزيڪشن. اهو مشورو ڏئي ٿو ته DELETE سسٽم جي رويي جي وڏي عملن کي ٻيهر ڏيڻ ۽ جانچ ڪرڻ لاء استعمال ڪري سگهجي ٿو. توهان غريبن لاءِ ڊيٽابيس ليب ٺاهي سگهو ٿا.
هي پروگرامرز بابت آهي. ڊي بي اي جي باري ۾ پڻ، اهي هميشه پروگرامرز کي هن لاء ڊاهيندا آهن: "توهان اهڙي ڊگهي ۽ مشڪل آپريشن ڇو ڪري رهيا آهيو؟" هي هڪ مڪمل طور تي مختلف عمودي موضوع آهي. اڳي انتظاميه هئي، پر هاڻي ترقي ٿيندي.
ظاهر آهي ته اسان ان کي ٽڪرن ۾ نه ٽوڙيو آهي. اهو واضح آهي. اهو ناممڪن آهي ته اهڙي DELETE کي ٽوڙڻ لاءِ لکين لائينن جي هڪ گروپ لاءِ حصن ۾. اهو ڪرڻ ۾ 20 منٽ لڳن ٿا، ۽ هر شيء لٽي ويندي. پر، بدقسمتي سان، جيتوڻيڪ تجربيڪار ڊولپر غلطيون ڪن ٿا، جيتوڻيڪ تمام وڏي ڪمپنين ۾.
ڇو ٽوڙڻ اهم آهي؟
-
جيڪڏهن اسان ڏسون ٿا ته ڊسڪ سخت آهي، پوء اچو ته ان کي سست ڪريو. ۽ جيڪڏھن اسان ڀڄي ويا آھيون، پوء اسان روڪي سگھون ٿا، اسان throttling کي سست ڪري سگھون ٿا.
-
۽ اسان ٻين کي گهڻو وقت تائين بلاڪ نه ڪنداسين. ڪجهه حالتن ۾ اهو فرق نٿو پوي، جيڪڏهن توهان حقيقي گندگي کي هٽائي رهيا آهيو جنهن تي ڪو به ڪم نه ڪري رهيو آهي، ته پوء توهان گهڻو ڪري ڪنهن کي بلاڪ نه ڪندا سواء آٽو ويڪيوم جي ڪم جي ڇاڪاڻ ته اهو ٽرانزيڪشن مڪمل ٿيڻ جو انتظار ڪندو. پر جيڪڏھن توھان ڪجھھ کي حذف ڪري سگھو ٿا جيڪو ڪو ٻيو درخواست ڪري سگھي ٿو، پوء انھن کي بلاڪ ڪيو ويندو، اتي ھڪڙي قسم جو سلسلو ردعمل ٿيندو. ويب سائيٽن ۽ موبائل ايپليڪيشنن تي ڊگهي ٽرانزيڪشن کان پاسو ڪيو وڃي.
هي دلچسپ آهي. مان اڪثر ڊولپرز کي ڏسندو آهيان، "مون کي ڪهڙي پيڪ جي سائيز چونڊڻ گهرجي؟"
اهو واضح آهي ته وڏي بيچ سائيز، ٽرانزيڪشن اوور هيڊ، يعني اضافي ٽرانزيڪشن اوور هيڊ. پر ساڳئي وقت، هن ٽرانزيڪشن لاء وقت وڌائي ٿو.
مون وٽ هڪ تمام سادو قاعدو آهي: جيترو ممڪن ٿي سگهي وٺو، پر في سيڪنڊ کان وڌ نه وڌو.
هڪ سيڪنڊ ڇو؟ وضاحت تمام سادو آهي ۽ هر ڪنهن لاءِ سمجهي سگهجي ٿو، جيتوڻيڪ غير ٽيڪنيڪل ماڻهو. اسان ردعمل ڏسون ٿا. اچو ته 50 ملي سيڪنڊ وٺو. جيڪڏهن ڪجهه تبديل ٿي چڪو آهي، اسان جي اکين جو رد عمل ٿيندو. جيڪڏهن اهو گهٽ آهي، اهو وڌيڪ ڏکيو آهي. جيڪڏهن ڪا شيءِ 100 ملي سيڪنڊن کان پوءِ جواب ڏئي ٿي، مثال طور، توهان مائوس سان ڪلڪ ڪيو ۽ اهو توهان کي 100 ملي سيڪنڊن کان پوءِ جواب ڏنو، توهان اڳ ۾ ئي اها ٿوري دير محسوس ڪري رهيا آهيو. هڪ سيڪنڊ اڳ ۾ ئي برڪ طور سمجهيو ويندو آهي.
ان جي مطابق، جيڪڏهن اسان پنهنجي ڪاميٽي آپريشن کي 10 سيڪنڊن ۾ ورهائي سگهون ٿا، ته پوء اسان اهو خطرو هلائيندا آهيون ته اسان ڪنهن کي بلاڪ ڪنداسين. ۽ اهو ڪجھ سيڪنڊن لاء ڪم ڪندو، ۽ ماڻهو اڳ ۾ ئي ان کي نوٽيس ڪندا. ان ڪري مان ان کي هڪ سيڪنڊ کان وڌيڪ نه ڪرڻ کي ترجيح ڏيان ٿو. پر ساڳئي وقت، ان کي تمام ننڍڙو نه ٽوڙيو، ڇو ته ٽرانزيڪشن مٿان مٿي قابل ذڪر ٿيندو. اهو بنيادي طور تي ڳري ٿيندو، ۽ ٻيا ڪيترائي مسئلا پيدا ٿي سگهن ٿيون.
اسان پيڪ جي سائيز کي چونڊيو. هر معاملي ۾ اسان اهو مختلف طريقي سان ڪري سگهون ٿا. خودڪار ٿي سگهي ٿو. ۽ اسان هڪ پيڪ جي پروسيسنگ جي ڪارڪردگي جا قائل آهيون. اهو آهي، اسان هڪ پيڪ کي DELETE يا تازه ڪاري ڪندا آهيون.
رستي ۾، مان توهان کي ٻڌايان ٿو ته سڀ ڪجهه نه رڳو DELETE بابت آهي. جيئن توهان اندازو لڳايو، اهي ڊيٽا تي تمام گهڻيون آپريشنون آهن.
۽ اسان ڏسون ٿا ته منصوبو شاندار آهي. توهان ڏسي سگهو ٿا انڊيڪس اسڪين، اڃا به بهتر انڊيڪس صرف اسڪين. ۽ اسان وٽ ڊيٽا جو هڪ ننڍڙو مقدار شامل آهي. ۽ هر شي هڪ سيڪنڊ کان گهٽ ۾ ڪم ڪري ٿي. سپر.
۽ اسان کي اڃا تائين پڪ ڪرڻ جي ضرورت آهي ته ڪو به تباهي نه آهي. اهو ٿئي ٿو ته پهرين بيچ جلدي ڪم ڪري رهيا آهن، ۽ پوء هر شيء خراب ٿي ويندي آهي ۽ خراب ۽ خراب ٿي ويندي آهي. اهو عمل اهڙو آهي ته توهان کي تمام گهڻو ٽيسٽ ڪرڻو پوندو. اھو بلڪل آھي جنھن لاءِ ڊيٽابيس ليبز جي ضرورت آھي.
۽ اسان کي اڃا تائين ڪجهه تيار ڪرڻ جي ضرورت آهي ته جيئن اهو اسان کي پيداوار ۾ صحيح طور تي مانيٽر ڪرڻ جي اجازت ڏيندو. مثال طور، اسان لاگ ۾ وقت لکي سگھون ٿا، اسان لکي سگھون ٿا ته اسان ڪٿي آھيون ۽ جيڪو اسان ھاڻي ڊليٽ ڪيو آھي. ۽ هي اسان کي بعد ۾ سمجهڻ جي اجازت ڏيندو ته ڇا ٿي رهيو آهي. ۽ جيڪڏهن ڪجهه غلط ٿي وڃي، جلدي مسئلو ڳوليو.
جيڪڏهن اسان کي سوالن جي ڪارڪردگي کي جانچڻ جي ضرورت آهي ۽ اسان کي ڪيترائي ڀيرا ٻيهر ورجائڻ جي ضرورت آهي، پوء اتي هڪ ساٿي بوٽ وانگر آهي. هو اڳ ۾ ئي تيار آهي. اهو هر روز ڪيترن ئي ڊولپرز طرفان استعمال ڪيو ويندو آهي. ۽ هو 30 سيڪنڊن ۾ درخواست تي هڪ وڏو ٽيرا بائيٽ ڊيٽابيس مهيا ڪري سگهي ٿو، توهان جي پنهنجي ڪاپي. ۽ توھان اتي ڪجھ ختم ڪري سگھوٿا ۽ چئي سگھوٿا RESET، ۽ ان کي ٻيهر حذف ڪريو. توھان ھن طريقي سان تجربو ڪري سگھو ٿا. مون کي هن شيء ۾ هڪ مستقبل ڏسي. ۽ اسان اڳ ۾ ئي ڪري رهيا آهيون.
ورهاڱي جون حڪمت عمليون ڇا آهن؟ مان ڏسان ٿو 3 مختلف ورهاڱي واري حڪمت عمليون جيڪي ڊولپرز پيڪ تي استعمال ڪندا آهن.
پهريون ته بلڪل سادو آهي. اسان وٽ هڪ عددي ID آهي. ۽ اچو ته ان کي ٽوڙيو مختلف وقفن ۾ ۽ ان سان ڪم ڪريو. نقصان پڌرو آهي. پهرين حصي ۾، اسان وٽ حقيقي گندگي جون 100 لائينون ٿي سگهن ٿيون، ٻئي ۾ 5 لائينون يا بلڪل نه، يا سڀ 1 لائينون ردي ٿي وينديون. تمام اڻ برابر ڪم، پر ٽوڙڻ آسان. انهن وڌ ۾ وڌ سڃاڻپ ورتي ۽ ان کي ٽوڙي ڇڏيو. هي هڪ سادي طريقو آهي.
ٻيو حڪمت عملي هڪ متوازن طريقو آهي. اهو Gitlab ۾ استعمال ٿيندو آهي. اسان ٽيبل کي ورتو ۽ اسڪين ڪيو. اسان ID پيڪن جون حدون ڳوليون ته هر پيڪ ۾ بلڪل 10 رڪارڊ شامل آهن. ۽ اھي مون کي ھڪڙي قسم جي قطار ۾ پھن ٿا. ۽ اسان اڳتي وڌندا آهيون. توھان ھي ڪري سگھو ٿا ڪيترن ئي موضوعن ۾.
پهرين حڪمت عملي ۾، رستي ۾، توهان ڪيترن ئي موضوعن ۾ پڻ ڪري سگهو ٿا. اهو ڏکيو نه آهي.
پر اتي ھڪڙو ٿڌو ۽ وڌيڪ بھترين طريقو آھي. هي ٽيون حڪمت عملي آهي. ۽ جڏهن ممڪن هجي، اهو بهتر آهي ته اهو چونڊيو وڃي. اسان اهو ڪندا آهيون خاص انڊيڪس جي بنياد تي. انهي صورت ۾، اهو گهڻو ڪري هڪ انڊيڪس هوندو جيڪو اسان جي گندگي جي حالت ۽ ID جي بنياد تي هوندو. اسان ID کي شامل ڪنداسين ته جيئن اهو صرف هڪ انڊيڪس اسڪين آهي ته جيئن اسان هيپ ڏانهن نه وڃون.
عام طور تي، انڊيڪس صرف اسڪين انڊيڪس اسڪين کان تيز آهي.
۽ اسان جلدي اسان جي IDs ڳوليندا آهيون جيڪي اسان ختم ڪرڻ چاهيون ٿا. اسان چونڊون BATCH_SIZE اڳ ۾. ۽ اسان نه رڳو انهن کي حاصل ڪندا آهيون، اسان انهن کي هڪ خاص طريقي سان حاصل ڪندا آهيون ۽ فوري طور تي انهن کي درست ڪندا آهيون. پر اسان انهن کي اهڙيءَ طرح بند ڪريون ٿا ته جيڪڏهن اهي اڳ ۾ ئي بند آهن، ته اسان انهن کي بند نه ڪندا آهيون، پر اڳتي وڌون ٿا ۽ اڳتي وٺي وڃون ٿا. هي اپڊيٽ اسڪپ لاڪ لاءِ آهي. هي Postgres سپر فيچر اسان کي اجازت ڏئي ٿو ته ڪيترن ئي موضوعن ۾ ڪم ڪريون جيڪڏهن اسان چاهيون ٿا. ممڪن آهي ته هڪ سلسلي ۾. ۽ پوء اتي آهي CTE - هي هڪ درخواست آهي. ۽ اسان وٽ حقيقي هٽائڻ هن CTE جي ٻئي منزل تي ٿي رهيو آهي - returning *. توهان id واپس ڪري سگهو ٿا، پر اهو بهتر آهي *، جيڪڏهن توهان وٽ هر لڪير ۾ ٿورو ڊيٽا آهي.
اسان کي هن جي ضرورت ڇو آهي؟ اسان کي رپورٽ ڪرڻ لاء هن جي ضرورت آهي. اسان هاڻي حقيقت ۾ ڪيتريون ئي لائينون حذف ڪيون آهن. ۽ اسان جون حدون ID يا create_at طرفان هن طرح آهن. توهان ڪري سگهو ٿا منٽ، وڌ ۾ وڌ. ٻيو ڪجهه به ڪري سگهجي ٿو. هتي تمام گهڻو آهي جيڪو توهان هتي ڪري سگهو ٿا. ۽ هي نگراني لاء تمام آسان آهي.
انڊيڪس بابت هڪ وڌيڪ نوٽ آهي. جيڪڏهن اسان اهو فيصلو ڪريون ٿا ته اسان کي هن خاص ڪم لاءِ هڪ خاص انڊيڪس جي ضرورت آهي، پوءِ اسان کي پڪ ڪرڻ جي ضرورت آهي ته اهو صرف ٽوپل اپڊيٽ کي خراب نه ڪري. اهو آهي، پوسٽ گريس وٽ اهڙا انگ اکر آهن. اهو توهان جي ٽيبل لاءِ pg_stat_user_tables ۾ ڏسي سگھجي ٿو. توهان ڏسي سگهو ٿا ته گرم اپڊيٽ استعمال ڪيا ويا آهن يا نه.
اهي حالتون آهن جڏهن توهان جي نئين انڊيڪس شايد انهن کي ڪٽي ڇڏيندي. ۽ ٻيون سڀ تازه ڪاريون جيڪي اڳ ۾ ئي هلندڙ آهن سست ٿي وينديون. نه صرف ان ڪري جو انڊيڪس ظاهر ٿيو (هر انڊيڪس کي سست ڪري ٿو تازه ڪاري ٿورڙو، پر ٿورڙو)، پر هتي اهو اڃا تائين شيون خراب ڪندو. ۽ هن ٽيبل لاءِ خاص اصلاح ڪرڻ ناممڪن آهي. اهو ڪڏهن ڪڏهن ٿيندو آهي. اها هڪ اهڙي نفاست آهي جيڪا گهٽ ماڻهن کي ياد آهي. ۽ هن ريڪ تي قدم کڻڻ آسان آهي. ڪڏهن ڪڏهن ائين به ٿئي ٿو ته توهان کي ٻئي طرف کان هڪ طريقه ڪار ڳولڻ جي ضرورت آهي ۽ اڃا به هن نئين انڊيڪس کان سواء، يا ٻيو انڊيڪس ٺاهيو، يا ٻيو ڪجهه ڪريو، مثال طور، توهان ٻيو طريقو استعمال ڪري سگهو ٿا.
پر اها آهي سڀ کان وڌيڪ بهتر حڪمت عملي، ان کي ڪيئن ورهايو وڃي بيچ ۾ ۽ هڪ ئي درخواست سان بيچ ۾ شوٽ ڪريو، هڪ وقت ۾ ٿورڙو حذف ڪريو، وغيره.
ڊگھو ٽرانزيڪشن -
بند ٿيل آٽو ويڪيوم
بلاڪ ڪرڻ جو مسئلو
غلطي # 5 ھڪڙو وڏو آھي. Okmeter کان نڪولي پوسٽ گريس مانيٽرنگ بابت ڳالهايو. بدقسمتي سان، مڪمل Postgres مانيٽرنگ موجود ناهي. ڪي ويجھا آھن، ڪي اڳتي آھن. Okmeter مڪمل ٿيڻ لاءِ ڪافي ويجهو آهي، پر اتي تمام گهڻو غائب آهي ۽ شامل ڪرڻ جي ضرورت آهي. توھان کي ھن لاء تيار ٿيڻ جي ضرورت آھي.
مثال طور، اهو بهتر آهي ته مئل ٽوپل جي نگراني ڪرڻ. جيڪڏهن توهان وٽ توهان جي ٽيبل ۾ تمام گهڻو مئل سامان آهي، پوء ڪجهه غلط آهي. اهو بهتر آهي ته هاڻي رد عمل ڏيو، ٻي صورت ۾ اتي تباهي اچي سگهي ٿي، ۽ اسان ليٽي سگهون ٿا. ٿئي ٿو.
جيڪڏهن ڪو وڏو IO آهي، پوء اهو واضح آهي ته اهو سٺو ناهي.
ڊگھو ٽرانزيڪشن پڻ. OLTP تي ڊگھي ٽرانزيڪشن جي اجازت نه ڏني وڃي. ۽ ھتي آھي ھڪڙي ڪڙي جي لنڪ، جيڪا توھان کي اجازت ڏئي ٿي ھن ٽڪڙي کي وٺي ۽ اڳ ۾ ئي ڪجھ ڊگھي ٽرانزيڪشن جي ٽريڪنگ ڪرڻ جي اجازت ڏئي ٿي.
ڊگھا ٽرانزيڪشن ڇو خراب آھن؟ ڇو ته سڀئي تالا صرف آخر ۾ جاري ڪيا ويندا. ۽ اسان سڀني کي بند ڪري ڇڏيو. پلس اسان سڀني ٽيبلن لاءِ آٽو ويڪيوم کي بلاڪ ڪريون ٿا. اهو سڀ ڪجهه سٺو ناهي. جيتوڻيڪ جيڪڏهن توهان ريپليڪا تي گرم اسٽينڊ بائي کي فعال ڪيو آهي، اهو اڃا تائين خراب آهي. عام طور تي، اهو بهتر آهي ته ڪٿي به ڊگهي ٽرانزيڪشن کان بچڻ لاء.
جيڪڏهن اسان وٽ ڪيترائي ٽيبل آهن جيڪي خالي نه آهن، پوء اسان کي خبردار ڪرڻ جي ضرورت آهي. اهڙي صورتحال هتي ممڪن آهي. اسان اڻ سڌي طرح autovacuum جي آپريشن کي متاثر ڪري سگهون ٿا. هي Avito کان هڪ ٽڪرو آهي، جنهن کي مون ٿورو بهتر ڪيو. ۽ اهو نڪتو هڪ دلچسپ اوزار اهو ڏسڻ لاء جيڪو اسان وٽ آٽو ويڪيوم سان آهي. مثال طور، اتي ڪي ٽيبلون انتظار ۾ آھن ۽ اھي پنھنجي موڙ جو انتظار نه ڪندا. توهان کي پڻ ان جي نگراني ۾ رکڻ جي ضرورت آهي ۽ هڪ خبرداري آهي.
۽ مسئلا بلاڪ. وڻن کي روڪڻ جو ٻيلو. مان ڪنهن کان ڪجهه وٺڻ ۽ ان کي بهتر ڪرڻ پسند ڪريان ٿو. هتي مون ڊيٽا ايگرٽ مان هڪ ٿڌو بار بار CTE ورتو، جيڪو وڻن کي بند ڪرڻ جو جنگل ڏيکاري ٿو. اها تشخيص لاء هڪ سٺي شيء آهي. ۽ مانيٽرنگ به ان جي بنياد تي ٺاهي سگهجي ٿي. پر اهو احتياط سان ڪيو وڃي. توهان کي پنهنجي لاءِ هڪ ننڍڙو بيان_ وقت ختم ڪرڻ جي ضرورت آهي. ۽ lock_timeout گهربل آهي.
ڪڏهن ڪڏهن اهي سڀئي غلطيون گڏ ٿين ٿيون.
منهنجي خيال ۾، هتي سڀ کان اهم غلطي تنظيمي آهي. اهو تنظيمي آهي، ڇاڪاڻ ته ٽيڪنالاجي ڪم نٿو ڪري. هي نمبر 2 آهي - اهي غلط جڳهه تي چيڪ ڪيا ويا.
اسان اتي چيڪ نه ڪيو ڇو ته اسان وٽ پيداوار وارو ڪلون نه هو جنهن تي چيڪ ڪرڻ آسان هو. ڊولپر کي شايد پيداوار تائين رسائي نه هجي.
۽ اسان غلط جاء تي چيڪ ڪيو. جيڪڏهن اهي اتي چيڪ ڪن ها ته اسان پاڻ کي ڏسي ها. ڊولپر اهو سڀ ڪجهه DBA کان سواءِ به ڏسي سگهي ٿو، جيڪڏهن هو ان کي سٺي ماحول ۾ چيڪ ڪري، جتي ڊيٽا جي ساڳي مقدار ۽ هڪجهڙائي واري ترتيب هجي. هن کي اهو سڀ ڪجهه ڏٺو هوندو ۽ شرمسار ٿيندو هو.
ڪار جي ويڪيوم بابت وڌيڪ. بعد ۾ اسان ڪيترن ئي ملين لائنن جي وڏي صفائي ڪئي آهي، اسان کي اڃا تائين هڪ REPACK ڪرڻ جي ضرورت آهي. اهو خاص طور تي انڊيڪس لاء اهم آهي. اسان اتي سڀ ڪجهه صاف ڪرڻ کان پوءِ اهي خراب محسوس ڪندا.
۽ جيڪڏھن توھان چاھيو ٿا ته روزاني ڪم کي ڪٽڻ واري ڪم کي واپس آڻيو، ته پوء آئون ان کي وڌيڪ ڀيرا ڪرڻ جي صلاح ڏيندس، پر ننڍا. اهو ٿي سگهي ٿو هڪ ڀيرو هر منٽ يا اڃا به گهڻو ڪري ٿورڙو. ۽ اسان کي ٻن شين جي نگراني ڪرڻ جي ضرورت آهي: ته هن شيء ۾ ڪا غلطي ناهي ۽ اهو پوئتي نه آهي. اهو چال جيڪو مون ڏيکاريو آهي اهو توهان کي حل ڪرڻ جي اجازت ڏيندو.
جيڪو اسان ڪندا آهيون اهو کليل ذريعو آهي. هي پوسٽ ٿيل آهي GitLab. ۽ اسان ان کي ٺاهيندا آهيون ته ماڻهو ڊي بي اي کان سواءِ به چيڪ ڪري سگهن ٿا. اسان هڪ ڊيٽابيس ليب ٺاهيندا آهيون، اهو آهي، اسان بنيادي جزو کي سڏيندا آهيون جنهن تي جو هن وقت ڪم ڪري رهيو آهي. ۽ توھان حاصل ڪري سگھوٿا پيداوار جي ڪاپي. ھاڻي ھڪڙو عمل آھي جو جو سست لاءِ، توھان اتي چئي سگھو ٿا: ”اھڙي ۽ اھڙي درخواست جي وضاحت ڪريو“ ۽ فوري طور تي توھان جي ڊيٽابيس جي ڪاپي لاءِ نتيجو حاصل ڪريو. توهان اتي به ڪري سگهو ٿا DELETE، ۽ ڪو به نوٽيس نه ڪندو.
اچو ته چئو ته توهان وٽ 10 ٽيرا بائيٽ آهن، اسان هڪ ڊيٽابيس ليب پڻ 10 ٽيرا بائيٽ ٺاهي رهيا آهيون. ۽ 10 ڊولپرز هڪ ئي وقت ۾ 10 ٽيرابائيٽ ڊيٽابيس سان گڏ ڪم ڪري سگهن ٿا. هرڪو اهو ڪري سگهي ٿو جيڪو هو چاهي ٿو. حذف ڪري سگهو ٿا، ڦٽو، وغيره هي شاندار آهي. اسان سڀاڻي ان بابت ڳالهائينداسين.
اهو پتلي رزق سڏيو ويندو آهي. هي ذيلي رزق آهي. اهو هڪ قسم جو تصور آهي جيڪو ترقي ۽ جاچ ۾ دير کي ختم ڪري ٿو ۽ دنيا کي ان سلسلي ۾ هڪ بهتر جڳهه بڻائي ٿو. اهو آهي، اهو صرف توهان کي ڪاميٽي آپريشن سان مسئلن کان بچڻ جي اجازت ڏئي ٿو.
مثال: 5 terabyte ڊيٽابيس، 30 سيڪنڊن کان گھٽ ۾ ڪاپي حاصل ڪرڻ. ۽ ان جو دارومدار سائيز تي به نه آهي، يعني اهو فرق نٿو پوي ته ڪيترا ٽيرا بائيٽ آهن.
اڄ توهان وڃي سگهو ٿا ۽ اسان جي اوزارن ۾ کڙو ڪريو. توهان رجسٽر ڪري سگهو ٿا ۽ ڏسو ته اتي ڇا آهي. توھان پنھنجي لاءِ ھي بوٽ انسٽال ڪري سگھو ٿا. اهو مفت آهي. لکو.
توهان جا سوال
گهڻو ڪري حقيقي حالتن ۾ اهو ظاهر ٿئي ٿو ته ڊيٽا جيڪا ٽيبل ۾ رهڻ گهرجي، ان کان گهڻو گهٽ آهي جيڪو ختم ٿيڻ جي ضرورت آهي. اهو آهي، اهڙي صورتحال ۾ اهو اڪثر آسان آهي هن طريقي تي عمل ڪرڻ، جڏهن اهو آسان آهي هڪ نئون اعتراض ٺاهڻ، صرف ضروري ڊيٽا کي نقل ڪريو ۽ پراڻي ٽيبل کي نقل ڪريو. اهو واضح آهي ته توهان کي هن لمحي لاءِ سافٽ ويئر جي ضرورت آهي جڏهن توهان سوئچ ڪري رهيا آهيو. اهو طريقو ڪيئن آهي؟
هي هڪ تمام سٺو طريقو آهي ۽ تمام سٺو ڪم آهي. اهو بلڪل ساڳيو آهي جيڪو pg_repack ڪندو آهي، اهو تمام گهڻو ساڳيو آهي جيڪو توهان کي ڪرڻو آهي جڏهن توهان ID ماڻهن ان کي 4 بائيٽ ڪيو. ڪيترائي فريم ورڪ ڪيترائي سال اڳ ڪيا هئا، ۽ پليٽ صرف وڏيون ٿي ويون آهن، ۽ انهن کي 8 بائيٽ ۾ تبديل ڪرڻ جي ضرورت آهي.
هي ڪم ڪافي ڏکيو آهي. اسان اهو ڪيو. ۽ توهان کي تمام محتاط هجڻ جي ضرورت آهي. اتي تالا، وغيره آهن، پر ٿي چڪو آهي. اھو آھي، معياري طريقو استعمال ڪرڻ آھي pg_repack. توهان اهڙي نشاني جو اعلان ڪيو. ۽ ان کان اڳ توھان ان کي سنيپ شاٽ ڊيٽا سان ڀرڻ شروع ڪريو، توھان پڻ ھڪڙي ٽيبل جو اعلان ڪريو جيڪو سڀني تبديلين کي ٽريڪ ڪري ٿو. اتي هڪ چال آهي ته توهان شايد ڪجهه تبديلين کي ٽريڪ نه ڪري سگهون. اتي subtleties آهن. ۽ پوءِ توھان مٽايو، تبديلين کي رولنگ ڪيو. اتي هڪ مختصر وقفو هوندو جڏهن اسان سڀني کي بند ڪري ڇڏينداسين، پر مجموعي طور تي اهو ڪيو پيو وڃي.
جيڪڏهن توهان GitHub تي pg_repack تي نظر رکون ٿا، پوء جڏهن آئي ڊي کي int 4 کان int 8 ۾ تبديل ڪرڻ جو ڪم هو، تڏهن اتي هڪ خيال هو ته pg_repack پاڻ کي استعمال ڪيو وڃي. اهو پڻ ممڪن آهي، پر هي هڪ هيڪر جو طريقو آهي، پر اهو پڻ هن لاء ڪم ڪندو. توهان ٽرگر ۾ مداخلت ڪري سگهو ٿا جيڪو استعمال ڪري ٿو pg_repack ۽ اتي چئو: "اسان کي هن ڊيٽا جي ضرورت ناهي،" يعني اسان صرف منتقل ڪريون ٿا جيڪو اسان کي گهربل آهي. ۽ پوءِ هو صرف سوئچ ڪري ٿو ۽ اهو ئي آهي.
هن طريقي سان، اسان ٽيبل جي هڪ ٻي ڪاپي پڻ حاصل ڪندا آهيون، جنهن ۾ ڊيٽا اڳ ۾ ئي ترتيب ڏنل آهي ۽ خوبصورت انڊيڪس سان تمام آسانيء سان ترتيب ڏني وئي آهي.
بلٽ نه، هي هڪ سٺو طريقو آهي. پر مان ڄاڻان ٿو ته ان لاءِ آٽوميشن کي ترقي ڪرڻ جي ڪوشش ڪئي وئي آهي، يعني هڪ آفاقي حل ڪرڻ. مان توهان کي هن خودڪار طريقي سان متعارف ڪرائي سگهان ٿو. اهو پٿون ۾ لکيل آهي، سٺو سامان.
مان صرف MySQL دنيا کان ٿورڙو آهيان، تنهنڪري مون کي ٻڌڻ آيو. ۽ اسان اهو طريقو استعمال ڪندا آهيون.
پر اهو صرف آهي جيڪڏهن اسان وٽ 90٪ آهي. جيڪڏهن اسان وٽ 5٪ آهي، پوء اهو استعمال ڪرڻ تمام سٺو ناهي.
رپورٽ لاءِ مهرباني! جيڪڏهن پيداوار جي مڪمل ڪاپي ٺاهڻ لاءِ ڪي به وسيلا نه آهن، ڇا لوڊ يا سائيز کي ڳڻڻ لاءِ ڪو الگورتھم يا فارمولا آهي؟
سٺو سوال. هينئر تائين اسان ملٽي ٽيرابائيٽ ڊيٽابيس ڳولڻ جي قابل آهيون. جيتوڻيڪ اتي هارڊويئر ساڳيو ناهي، مثال طور، گهٽ ميموري، گهٽ پروسيسر ۽ ڊسڪ بلڪل ساڳيا نه آهن، اسان اڃا تائين ڪندا آهيون. جيڪڏهن اتي بلڪل ڪٿي به نه آهي، ته توهان کي ان بابت سوچڻ جي ضرورت آهي. مون کي سڀاڻي تائين ان بابت سوچڻ ڏيو، توهان آيا آهيو، اسان ڳالهائينداسين، اهو هڪ سٺو سوال آهي.
رپورٽ لاءِ مهرباني! توهان پهرين حقيقت جي باري ۾ ڳالهائڻ شروع ڪيو ته اتي هڪ ٿڌو Postgres آهي، جنهن ۾ اهڙيون ۽ اهڙيون حدون آهن، پر اهو ترقي ڪري رهيو آهي. ۽ اهو سڀ ڪجهه وڏي پيماني تي آهي. ڇا اهو سڀ ڪجهه Postgres جي ترقيءَ سان تضاد نٿو رکي، جنهن ۾ ڪنهن قسم جو DELETE deferent ظاهر ٿيندو يا ٻيو ڪجهه جنهن کي گهٽ سطح تي رکڻ گهرجي، جنهن کي اسين هتي پنهنجي عجيب و غريب طريقن سان ڍڪڻ جي ڪوشش ڪري رهيا آهيون؟
جيڪڏهن SQL ۾ اسان چيو آهي ته هڪ ٽرانزيڪشن ۾ ڪيترائي رڪارڊ حذف ڪرڻ يا اپڊيٽ ڪرڻ، پوءِ پوسٽ گريس ان کي ڪيئن ورهائي سگهي ٿو؟ اسان جسماني طور تي عملن ۾ محدود آهيون. اسان اڃا تائين هڪ ڊگهي وقت تائين ائين ڪندا رهياسين. ۽ اسان هن وقت بند ڪنداسين، وغيره.
انهن انڊيڪس سان ساڳيو ڪم ڪيو.
مان سمجهان ٿو ته ساڳي چيڪ پوائنٽ ٽيوننگ خودڪار ٿي سگهي ٿي. ڪنهن ڏينهن ائين ٿي سگهي ٿو. پر پوءِ به مون کي اهو سوال سمجهه ۾ نه ٿو اچي.
سوال اهو آهي ته: ڇا ڪو ترقي وارو ویکٹر آهي جيڪو اتي وڃي ٿو، ۽ هتي توهان جي برابر آهي؟ اهي. ڇا اهي اڃا تائين ان بابت نه سوچيندا آهن؟
مون انهن اصولن بابت ڳالهايو جيڪي هاڻي استعمال ڪري سگهجن ٿيون. اتي هڪ ٻيو بوٽ آهي ، ان سان توهان ڪري سگهو ٿا خودڪار چيڪ پوائنٽ ٽيوننگ. ڇا اهو ڪڏهن Postgres ۾ ٿيندو؟ مون کي خبر ناهي، اهو اڃا تائين بحث نه ڪيو ويو آهي. اسان اڃا تائين ان کان پري آهيون. پر اهڙا سائنسدان آهن جيڪي نوان نظام ٺاهي رهيا آهن. ۽ اهي اسان کي خودڪار انڊيڪس ۾ ڇڪيندا آهن. ترقيون آهن. مثال طور، توهان خودڪار طريقي سان ڏسي سگهو ٿا. اهو خودڪار طريقي سان پيٽرولر چونڊيندو آهي. پر هو اڃا تائين توهان لاءِ چيڪ پوائنٽ ٽيوننگ نه ڪندو. اهو آهي، اهو ڪارڪردگي لاء چونڊيو ويندو، شيل بفر، وغيره.
۽ چيڪ پوائنٽ ٽيوننگ لاءِ توھان ھيٺ ڏنل ڪم ڪري سگھو ٿا: جيڪڏھن توھان وٽ ھزار ڪلسٽرز ۽ هارڊويئر جا مختلف ٽڪرا آھن، بادل ۾ مختلف ورچوئل مشينون، توھان استعمال ڪري سگھو ٿا اسان جو بوٽ خودڪار ڪرڻ. ۽ max_wal_size خودڪار طريقي سان چونڊيو ويندو توهان جي ٽارگيٽ سيٽنگن جي مطابق. پر بدقسمتيءَ سان اهو اڃا تائين ڪنيال ۾ هجڻ جي ويجهو ناهي.
منجهند جو سلام توهان ڊگهي ٽرانزيڪشن جي خطرن بابت ڳالهايو. توهان چيو ته autovacuum حذف ڪرڻ جي صورت ۾ بلاڪ ڪيو ويو آهي. اهو اسان کي ٻيو ڪيئن نقصان پهچائيندو؟ ڇو ته اسان وڌيڪ ڳالهائڻ وارا آهيون خلا کي خالي ڪرڻ ۽ ان کي استعمال ڪرڻ جي قابل. اسان کي ٻيو ڇا وڃائڻو آهي؟
Autovacuum هتي سڀ کان وڏو مسئلو نه ٿي سگهي. ۽ حقيقت اها آهي ته هڪ ڊگهو ٽرانزيڪشن ٻين ٽرانزيڪشن کي بلاڪ ڪري سگهي ٿو هڪ وڌيڪ خطرناڪ امڪان آهي. هوءَ ملي سگهي ٿي يا نه ٿي سگهي. جيڪڏهن هوء ملي، پوء شيون تمام خراب ٿي سگهي ٿي. ۽ autovacuum سان اهو پڻ هڪ مسئلو آهي. OLTP ۾ ڊگهي ٽرانزيڪشن سان ٻه مسئلا آهن: لاڪ ۽ آٽو ويڪيوم. ۽ جيڪڏهن توهان ريپليڪا تي گرم اسٽينڊ بائي موٽڻ کي فعال ڪيو آهي، ته پوء آٽو ويڪيوم بلاڪنگ پڻ ماسٽر تي پهچي ويندو، اهو ريپليڪا مان پهچي ويندو. پر گهٽ ۾ گهٽ اتي ڪو به تالا نه هوندو. ۽ هتي به تالا لڳندا. اسان ڊيٽا جي تبديلين بابت ڳالهائي رهيا آهيون، تنهنڪري تالا هڪ اهم نقطو هتي آهن. ۽ جيڪڏهن اهو هڪ ڊگهو، ڊگهو وقت تائين هلندو آهي، پوء وڌيڪ ۽ وڌيڪ ٽرانزيڪشن بند ٿي ويا آهن. اهي ٻين کي ڦاسائي سگهن ٿا. ۽ تالا وڻن کي نظر اچن ٿا. مون سٽ جي لنڪ ڏني. ۽ اهو مسئلو جلدي آٽو ويڪيوم جي مسئلي کان وڌيڪ قابل ذڪر ٿي ويندو آهي، جيڪو صرف جمع ڪري سگهي ٿو.
رپورٽ لاءِ مهرباني! توهان پنهنجي رپورٽ کي اهو چوڻ شروع ڪيو ته توهان غلط ٽيسٽ ڪئي. اسان پنهنجو خيال جاري رکيو ته اسان کي ساڳيو سامان کڻڻو پوندو، بنيادي طور تي ساڳيو. اچو ته اسان ڊولپر کي هڪ بنياد ڏنو. ۽ هن درخواست جي تعميل ڪئي. ۽ لڳي ٿو ته هو سٺو ڪم ڪري رهيو آهي. پر اهو لائيو تي چيڪ نٿو ڪري، پر لائيو تي، مثال طور، اسان جو لوڊ 60-70٪ آهي. ۽ جيتوڻيڪ اسان هن ٽيوننگ کي استعمال ڪندا آهيون، اهو تمام سٺو نه ٿو ڦري
توهان جي ٽيم تي هڪ ماهر هجڻ ۽ DBA ماهرن کي استعمال ڪندي جيڪي اڳڪٿي ڪري سگهن ٿا ته حقيقي پس منظر جي لوڊ هيٺ ڇا ٿيندو اهم آهي. جڏهن اسان صرف اسان جي خالص تبديلين ذريعي هليا ويا، اسان تصوير ڏسون ٿا. پر هڪ وڌيڪ ترقي يافته طريقو هو جڏهن اسان ساڳيو ڪم ڪيو، پر هڪ تخليقي پيداوار لوڊ سان. هي تمام ٿڌو آهي. اسان کي اڃا تائين هن نقطي ڏانهن وڌڻ جي ضرورت آهي. اهو پختو آهي. اسان خالص طور تي ڏٺو ته اسان وٽ ڇا آهي ۽ اهو پڻ ڏٺو ته ڇا اسان وٽ ڪافي وسيلا آهن. اھو ھڪڙو سٺو سوال آھي.
جڏهن اسان اڳ ۾ ئي ڪري رهيا آهيون هڪ گندگي چونڊيو ۽ اسان وٽ آهي، مثال طور، هڪ ختم ٿيل پرچم
اھو اھو آھي جيڪو autovacuum خودڪار طريقي سان Postgres ۾ ڪندو آھي.
ها، هو اهو ڪري ٿو؟
آٽو ويڪيوم ڪچرو گڏ ڪندڙ آهي.
مهرباني
رپورٽ لاءِ مهرباني! ڇا اتي ڪو اختيار آهي ته فوري طور تي ورهاڱي سان ڊيٽابيس کي ترتيب ڏيو ته جيئن سمورو گندگي کي هٽايو وڃي مکيه ٽيبل کان ڪنهن پاسي ڏانهن؟
يقيناً آهي.
ڇا اسان پوءِ پاڻ کي بچائي سگهون ٿا جيڪڏهن اسان هڪ ٽيبل کي بند ڪيو آهي جنهن کي استعمال نه ڪيو وڃي؟
يقيناً آهي. پر هي هڪ ڪڪڙ ۽ هڏين جو سوال آهي. جيڪڏهن اسان سڀني کي خبر آهي ته مستقبل ۾ ڇا ٿيندو، پوء، يقينا، اسان سڀ ڪجهه عظيم ڪنداسين. پر ڪاروبار تبديل ٿي رهيو آهي، نوان ڪالمن ۽ نئين درخواستون ظاهر ٿيندا آهن. ۽ پوء - اڙي، اسان ان کي ختم ڪرڻ چاهيون ٿا. پر اها هڪ مثالي صورتحال آهي؛ اهو زندگي ۾ ٿئي ٿو، پر هميشه نه. پر مجموعي طور تي اهو هڪ سٺو خيال آهي. بس ڪٽيو ۽ بس.
جو ذريعو: www.habr.com