MySQL मधील 300 दशलक्ष रेकॉर्ड भौतिकरित्या हटविण्याची कथा

परिचय

नमस्कार. मी ningenMe, वेब डेव्हलपर आहे.

शीर्षकात म्हटल्याप्रमाणे, माझी कथा ही MySQL मधील 300 दशलक्ष रेकॉर्ड भौतिकरित्या हटविण्याची कथा आहे.

मला यात रस वाटला, म्हणून मी एक स्मरणपत्र (सूचना) बनवण्याचा निर्णय घेतला.

होम - अलर्ट

मी ज्या बॅच सर्व्हरचा वापर करतो आणि देखरेख करतो त्याची नियमित प्रक्रिया असते जी दिवसातून एकदा MySQL वरून गेल्या महिन्याचा डेटा संकलित करते.

सहसा ही प्रक्रिया सुमारे 1 तासाच्या आत पूर्ण होते, परंतु यावेळी ती 7 किंवा 8 तास पूर्ण झाली नाही आणि अलर्ट पॉप अप थांबला नाही...

कारण शोधत आहे

मी प्रक्रिया पुन्हा सुरू करण्याचा आणि लॉग पाहण्याचा प्रयत्न केला, परंतु मला काहीही चुकीचे दिसले नाही.
क्वेरी योग्यरित्या अनुक्रमित केली गेली. पण काय चूक होत आहे याचा विचार केल्यावर माझ्या लक्षात आले की डेटाबेसचा आकार खूप मोठा आहे.

hoge_table | 350'000'000 |

350 दशलक्ष रेकॉर्ड. अनुक्रमणिका योग्यरित्या कार्य करत असल्याचे दिसते, अगदी हळू.

दरमहा आवश्यक डेटा संकलन अंदाजे 12 रेकॉर्ड होते. असे दिसते की सिलेक्ट कमांडला बराच वेळ लागला आणि व्यवहार बराच काळ कार्यान्वित झाला नाही.

DB

हे मूलत: एक टेबल आहे जे दररोज सुमारे 400 नोंदींनी वाढते. डेटाबेसने केवळ गेल्या महिन्यासाठी डेटा संकलित करणे अपेक्षित होते, म्हणून, हे अपेक्षित होते की ते डेटाच्या या प्रमाणात अचूकपणे टिकून राहतील, परंतु, दुर्दैवाने, रोटेट ऑपरेशन समाविष्ट केले गेले नाही.

हा डेटाबेस मी विकसित केलेला नाही. मी ते दुसर्‍या विकसकाकडून घेतले, त्यामुळे ते अजूनही तांत्रिक कर्जासारखे वाटले.

असा एक मुद्दा आला जेव्हा दररोज घातलेल्या डेटाची मात्रा मोठी झाली आणि शेवटी त्याची मर्यादा गाठली. असे गृहीत धरले जाते की एवढ्या मोठ्या प्रमाणात डेटासह कार्य करताना, त्यांना वेगळे करणे आवश्यक असेल, परंतु दुर्दैवाने हे केले गेले नाही.

आणि मग मी कृतीत आलो.

दुरुस्ती

तर्कशास्त्र बदलण्यापेक्षा डेटाबेसचा आकार कमी करणे आणि त्यावर प्रक्रिया करण्यासाठी लागणारा वेळ कमी करणे अधिक तर्कसंगत होते.

जर तुम्ही 300 दशलक्ष रेकॉर्ड मिटवले तर परिस्थिती लक्षणीय बदलली पाहिजे, म्हणून मी तसे करण्याचे ठरवले... अरे, मला वाटले की हे नक्कीच कार्य करेल.

कृती १

एक विश्वासार्ह बॅकअप तयार केल्यावर, मी शेवटी विनंत्या पाठवायला सुरुवात केली.

'विनंती पाठवत आहे'

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

"…"

"…"

"हम्म... उत्तर नाही. कदाचित प्रक्रियेस बराच वेळ लागेल?" — मला वाटले, पण फक्त बाबतीत, मी ग्राफनाकडे पाहिले आणि पाहिले की डिस्कचा भार खूप वेगाने वाढत आहे.
“धोकादायक,” मी पुन्हा विचार केला आणि लगेच विनंती थांबवली.

कृती १

प्रत्येक गोष्टीचे विश्लेषण केल्यावर, मला समजले की डेटाची मात्रा एकाच वेळी सर्वकाही हटविण्यासाठी खूप मोठी आहे.

मी एक स्क्रिप्ट लिहिण्याचे ठरवले जे सुमारे 1 रेकॉर्ड हटवू शकते आणि ते लॉन्च केले.

''मी स्क्रिप्ट अंमलात आणतो''

"आता हे नक्कीच काम करेल," मी विचार केला.

कृती १

दुसरी पद्धत कार्य करते, परंतु खूप श्रम-केंद्रित असल्याचे दिसून आले.
सर्व काही काळजीपूर्वक करण्यासाठी, अनावश्यक नसांशिवाय, सुमारे दोन आठवडे लागतील. परंतु तरीही, ही परिस्थिती सेवा आवश्यकता पूर्ण करत नाही, म्हणून आम्हाला त्यापासून दूर जावे लागले.

म्हणून मी काय करायचे ठरवले ते येथे आहे:

टेबल कॉपी करा आणि त्याचे नाव बदला

मागील पायरीवरून, माझ्या लक्षात आले की एवढ्या मोठ्या प्रमाणात डेटा हटवल्याने तितकाच मोठा भार निर्माण होतो. म्हणून मी इन्सर्ट वापरून सुरवातीपासून एक नवीन टेबल तयार करण्याचा आणि त्यात मी हटवणार असलेला डेटा हलवण्याचा निर्णय घेतला.

| 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';

"…"
"…"
"एम...?"

कृती १

मला वाटले की मागील कल्पना कार्य करेल, परंतु इन्सर्ट रिक्वेस्ट पाठवल्यानंतर अनेक त्रुटी दिसून आल्या. MySQL क्षमाशील नाही.

मी आधीच इतका थकलो होतो की मला असे वाटू लागले की मला हे आता करायचे नाही.

मी बसलो आणि विचार केला आणि लक्षात आले की कदाचित एका वेळेसाठी बर्याच प्रविष्ट क्वेरी आहेत...
डेटाबेसने 1 दिवसात किती डेटावर प्रक्रिया करावी यासाठी मी इन्सर्ट विनंती पाठवण्याचा प्रयत्न केला. झाले!

बरं, त्यानंतर आम्ही त्याच प्रमाणात डेटासाठी विनंत्या पाठवत आहोत. आम्हाला एका महिन्याचा डेटा काढून टाकण्याची आवश्यकता असल्याने, आम्ही हे ऑपरेशन अंदाजे 35 वेळा पुनरावृत्ती करतो.

टेबलचे नाव बदलत आहे

येथे नशीब माझ्या बाजूने होते: सर्व काही सुरळीत झाले.

अलर्ट गायब झाला

बॅच प्रक्रियेचा वेग वाढला आहे.

पूर्वी या प्रक्रियेला एक तास लागत होता, आता सुमारे 2 मिनिटे लागतात.

सर्व समस्यांचे निराकरण झाल्याची मला खात्री झाल्यानंतर, मी 300 दशलक्ष रेकॉर्ड टाकले. मी टेबल हटवले आणि मला पुनर्जन्म वाटला.

सारांश

मला समजले की बॅच प्रोसेसिंगमध्ये रोटेशन प्रोसेसिंग गहाळ आहे आणि हीच मुख्य समस्या होती. अशा प्रकारच्या वास्तुशास्त्रीय त्रुटींमुळे वेळेचा अपव्यय होतो.

डेटाबेसमधून रेकॉर्ड हटवताना तुम्ही डेटा प्रतिकृती दरम्यान लोडबद्दल विचार करता? चला MySQL ओव्हरलोड करू नका.

डेटाबेसमध्ये पारंगत असलेल्यांना अशी समस्या नक्कीच येणार नाही. तुमच्या उर्वरितांसाठी, मला आशा आहे की हा लेख उपयुक्त होता.

वाचल्याबद्दल धन्यवाद!

तुम्हाला हा लेख आवडला की नाही, भाषांतर स्पष्ट आहे का, तुमच्यासाठी उपयुक्त आहे की नाही हे तुम्ही आम्हाला सांगितल्यास आम्हाला खूप आनंद होईल?

स्त्रोत: www.habr.com