MySQL-ში 300 მილიონი ჩანაწერის ფიზიკურად წაშლის ისტორია

შესავალი

გამარჯობა. მე ვარ 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 000 000 ჩანაწერის წაშლას შეძლებდა და გავუშვი.

''მე ვახორციელებ სკრიპტს''

”ახლა ეს აუცილებლად იმუშავებს”, გავიფიქრე მე.

მოქმედება 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