پېژندنه
سلام. زه 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 ملیون ریکارډونه واخیستل. ما میز حذف کړ او د بیا زیږون احساس مې وکړ.
لنډیز
ما پوهیده چې د گردش پروسس د بیچ پروسس کولو کې ورک و، او دا اصلي ستونزه وه. دا ډول معماري غلطي د وخت ضایع کیدو لامل کیږي.
ایا تاسو د ډیټا نقل کولو پرمهال د بار په اړه فکر کوئ کله چې له ډیټابیس څخه ریکارډونه حذف کوئ؟ راځئ چې مای ایس کیو ایل ډیر نه کړو.
هغه څوک چې په ډیټابیسونو کې ښه پوهه لري یقینا به د داسې ستونزې سره مخ نشي. ستاسو د پاتې لپاره، زه امید لرم چې دا مقاله ګټوره وه.
د لوستلو لپاره مننه!
موږ به ډیر خوښ شو که تاسو موږ ته ووایاست چې ایا تاسو دا مقاله خوښ کړې ، ایا ژباړه روښانه ده ، ایا دا ستاسو لپاره ګټوره وه؟
سرچینه: www.habr.com