அறிமுகம்
வணக்கம். நான் 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