تعارف
سلام. مان ningenMe آهيان، ويب ڊولپر.
جيئن عنوان چوي ٿو، منهنجي ڪهاڻي جسماني طور تي MySQL ۾ 300 ملين رڪارڊ کي حذف ڪرڻ جي ڪهاڻي آهي.
مون کي هن ۾ دلچسپي ورتي، تنهنڪري مون هڪ ياد ڏياريندڙ (هدايتون) ٺاهڻ جو فيصلو ڪيو.
گھر - خبرداري
بيچ سرور جيڪو آئون استعمال ڪريان ٿو ۽ برقرار رکي ٿو هڪ باقاعده عمل آهي جيڪو MySQL کان گذريل مهيني جي ڊيٽا گڏ ڪري ٿو ڏينهن ۾ هڪ ڀيرو.
عام طور تي اهو عمل تقريباً 1 ڪلاڪ اندر مڪمل ٿي ويندو آهي، پر هن ڀيري اهو 7 يا 8 ڪلاڪن تائين مڪمل نه ٿيو ۽ الرٽ پاپ اپ ٿيڻ بند نه ٿيو...
سبب ڳولي رهيو آهي
مون عمل کي ٻيهر شروع ڪرڻ جي ڪوشش ڪئي ۽ لاگز کي ڏسو، پر مون کي ڪجهه به غلط نظر نه آيو.
سوال صحيح ترتيب ڏنل آهي. پر جڏهن مون سوچيو ته ڇا غلط ٿي رهيو آهي، مون محسوس ڪيو ته ڊيٽابيس جي سائيز ڪافي وڏي آهي.
hoge_table | 350'000'000 |350 ملين رڪارڊ. انڊيڪسنگ صحيح ڪم ڪرڻ لڳي، بس تمام سست.
هر مهيني گهربل ڊيٽا گڏ ڪرڻ لڳ ڀڳ 12 رڪارڊ هئا. اهو ڏسڻ ۾ اچي ٿو ته چونڊ حڪم گهڻو وقت ورتو ۽ ٽرانزيڪشن گهڻو وقت تائين عمل نه ڪيو ويو.
DB
اهو بنيادي طور تي هڪ ٽيبل آهي جيڪو وڌندو آهي تقريباً 400 داخلائن هر روز. ڊيٽابيس کي صرف گذريل مهيني لاءِ ڊيٽا گڏ ڪرڻي هئي، تنهن ڪري، اها توقع ڪئي وئي ته اها ڊيٽا جي ايتري مقدار کي برداشت ڪندي، پر، بدقسمتي سان، روٽيٽ آپريشن شامل نه ڪيو ويو.
هي ڊيٽابيس مون پاران تيار نه ڪيو ويو آهي. مون ان کي ڪنهن ٻئي ڊولپر کان وٺي ورتو، تنهنڪري اهو اڃا تائين ٽيڪنيڪل قرض وانگر محسوس ٿيو.
اتي هڪ نقطو آيو جڏهن ڊيٽا جو مقدار روزانو داخل ڪيو ويو ۽ آخرڪار ان جي حد تائين پهچي ويو. اهو فرض ڪيو ويو آهي ته جڏهن ڊيٽا جي اهڙي وڏي رقم سان ڪم ڪري، ان کي الڳ ڪرڻ ضروري آهي، پر اهو، بدقسمتي سان، نه ڪيو ويو.
۽ پوءِ مان عمل ۾ آيس.
اصلاح
اهو وڌيڪ منطقي هو ته ڊيٽابيس جي سائيز کي گھٽائڻ ۽ ان کي پروسيسنگ لاء وقت گھٽائڻ جي ڀيٽ ۾ منطق کي تبديل ڪرڻ کان.
جيڪڏهن توهان 300 ملين رڪارڊز کي ختم ڪري ڇڏيو ته صورتحال کي خاص طور تي تبديل ٿيڻ گهرجي، تنهنڪري مون ائين ڪرڻ جو فيصلو ڪيو... ها، مون سوچيو ته اهو ضرور ڪم ڪندو.
عمل 1
هڪ قابل اعتماد بيڪ اپ تيار ڪرڻ بعد، مون آخرڪار درخواستون موڪلڻ شروع ڪيو.
"درخواست موڪلڻ"
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';”…“
”…“
”هم... جواب ڪونھي. ٿي سگهي ٿو اهو عمل گهڻو وقت وٺندو؟ - مون سوچيو، پر صرف ان صورت ۾، مون گرافانا ڏانهن ڏٺو ۽ ڏٺو ته ڊسڪ لوڊ تمام تيزيء سان وڌي رهيو هو.
”خطرناڪ،“ مون وري سوچيو ۽ فوري طور تي درخواست روڪي ڇڏي.
عمل 2
هر شي جو تجزيو ڪرڻ کان پوء، مون محسوس ڪيو ته ڊيٽا جو حجم تمام وڏو هو هڪ ڀيرو هر شيء کي ختم ڪرڻ لاء.
مون هڪ اسڪرپٽ لکڻ جو فيصلو ڪيو جيڪو اٽڪل 1 رڪارڊ کي ختم ڪري سگهي ٿو ۽ ان کي شروع ڪيو.
"مان اسڪرپٽ تي عمل ڪريان ٿو"
”هاڻي اهو ضرور ڪم ڪندو،“ مون سوچيو.
عمل 3
ٻيو طريقو ڪم ڪيو، پر تمام گهڻي محنت وارو ثابت ٿيو.
هر شي کي احتياط سان ڪرڻ لاء، غير ضروري اعصاب کان سواء، اٽڪل ٻه هفتا وٺي سگهندا. پر اڃا تائين، هي منظر خدمت جي گهرج کي پورو نه ڪيو، تنهنڪري اسان کي ان کان پري وڃڻو پيو.
تنهنڪري هتي آهي جيڪو مون ڪرڻ جو فيصلو ڪيو:
ٽيبل کي نقل ڪريو ۽ ان کي تبديل ڪريو
پوئين قدم کان، مون محسوس ڪيو ته ڊيٽا جي اهڙي وڏي مقدار کي حذف ڪرڻ هڪ جيتري وڏي لوڊ ٺاهي ٿي. تنهن ڪري مون انسرٽ استعمال ڪندي شروع کان هڪ نئين ٽيبل ٺاهڻ جو فيصلو ڪيو ۽ ان ڊيٽا کي منتقل ڪيو جنهن کي مان حذف ڪرڻ وارو هوس.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|جيڪڏھن توھان نئين جدول کي ساڳي سائيز ٺاھيو جيئن مٿي، ڊيٽا پروسيسنگ جي رفتار پڻ 1/7 تيز ٿيڻ گھرجي.
ٽيبل ٺاهڻ ۽ ان جو نالو تبديل ڪرڻ کان پوء، مون ان کي ماسٽر ٽيبل طور استعمال ڪرڻ شروع ڪيو. هاڻي جيڪڏهن آئون 300 ملين رڪارڊ سان ٽيبل کي ڇڏي ڏيان ته سڀ ڪجهه ٺيڪ ٿيڻ گهرجي.
مون کي معلوم ٿيو ته ترڪيب يا ڊراپ ختم ڪرڻ کان گهٽ اوور هيڊ ٺاهي ۽ هن طريقي کي استعمال ڪرڻ جو فيصلو ڪيو.
ناڪام
"درخواست موڪلڻ"
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
”…“
”…“
”ايم…؟
عمل 4
مون سوچيو ته اڳوڻو خيال ڪم ڪندو، پر داخل ڪرڻ جي درخواست موڪلڻ کان پوء، ڪيتريون ئي غلطيون ظاهر ٿيون. MySQL بخشڻ وارو ناهي.
مان اڳ ۾ ئي ايترو ٿڪل هوس جو مون سوچڻ شروع ڪيو ته مان هاڻي اهو ڪرڻ نه چاهيندس.
مان ويھي رھيس ۽ سوچيم ۽ محسوس ڪيم ته شايد ھڪڙي وقت لاءِ گھڻا داخل سوال ھئا...
مون ڊيٽا جي مقدار لاءِ داخل ڪرڻ جي درخواست موڪلڻ جي ڪوشش ڪئي جيڪا ڊيٽابيس کي 1 ڏينهن ۾ پروسيس ڪرڻ گهرجي. ٿيو!
خير، ان کان پوء اسان ڊيٽا جي ساڳئي رقم لاء درخواستون موڪلڻ جاري رکون ٿا. جيئن ته اسان کي هڪ مهيني جي قيمتي ڊيٽا کي هٽائڻ جي ضرورت آهي، اسان هن آپريشن کي تقريبا 35 ڀيرا ورجائيندا آهيون.
ٽيبل جو نالو تبديل ڪرڻ
هتي قسمت منهنجي پاسي تي هئي: هر شيء آسان ٿي وئي.
الرٽ غائب ٿي ويو
بيچ پروسيسنگ جي رفتار وڌي وئي آهي.
اڳي اهو عمل اٽڪل هڪ ڪلاڪ لڳندو هو، هاڻي ان ۾ لڳ ڀڳ 2 منٽ لڳن ٿا.
مون کي پڪ ٿي وئي ته سڀ مسئلا حل ٿي ويا آهن، مون 300 ملين رڪارڊ ڪڍي ڇڏيو. مون ٽيبل کي ختم ڪيو ۽ ٻيهر جنم ورتو.
خلاصو
مون محسوس ڪيو ته گردش پروسيسنگ بيچ پروسيسنگ ۾ غائب هئي، ۽ اهو بنيادي مسئلو هو. هن قسم جي تعميراتي غلطي وقت جي ضايع ٿيڻ جي ڪري ٿي.
ڇا توهان ڊيٽا جي نقل جي دوران لوڊ جي باري ۾ سوچيو ٿا جڏهن ڊيٽابيس مان رڪارڊ حذف ڪري رهيا آهيو؟ اچو ته MySQL کي اوورلوڊ نه ڪريون.
اهي جيڪي ڊيٽابيس ۾ چڱي طرح ماهر هوندا آهن انهن کي يقيني طور تي اهڙي مسئلي کي منهن نه ڏيندو. توهان جي باقي لاء، مون کي اميد آهي ته هي مضمون مفيد هو.
پڙهڻ لاءِ مهرباني!
اسان کي تمام گهڻي خوشي ٿيندي جيڪڏهن توهان اسان کي ٻڌايو ته ڇا توهان کي هي مضمون پسند آيو، ڇا ترجمو واضح آهي، ڇا اهو توهان لاءِ مفيد هو؟
جو ذريعو: www.habr.com