හැඳින්වීම
ආයුබෝවන්. මම ningenMe, web developer.
මාතෘකාවට අනුව, මගේ කතාව MySQL හි වාර්තා මිලියන 300 ක් භෞතිකව මකා දැමීමේ කතාවයි.
මම මේ ගැන උනන්දු වුණා, ඒ නිසා මම මතක් කිරීමක් (උපදෙස්) කිරීමට තීරණය කළා.
නිවස - අනතුරු ඇඟවීම
මම භාවිතා කරන සහ නඩත්තු කරන කණ්ඩායම් සේවාදායකයට දිනකට වරක් MySQL වෙතින් පසුගිය මාසයේ දත්ත රැස් කරන විධිමත් ක්‍රියාවලියක් ඇත.
සාමාන්‍යයෙන් මෙම ක්රියාවලිය පැය 1ක් පමණ ඇතුළත අවසන් වන නමුත් මෙවර එය පැය 7ක් හෝ 8ක් යනතුරු සම්පූර්ණ නොවූ අතර, Alert එක මතුවීම නතර වූයේද නැත...
හේතුවක් සොයමින්
මම ක්රියාවලිය නැවත ආරම්භ කර ලඝු-සටහන් දෙස බැලීමට උත්සාහ කළ නමුත් මම කිසිඳු වරදක් දුටුවේ නැත.
විමසුම නිවැරදිව සුචිගත කර ඇත. ඒත් මොකක්ද අවුල කියලා හිතුවාම තේරුනා database size එක සෑහෙන්න ලොකුයි කියලා.
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 overload නොකර ඉමු.
දත්ත සමුදායන් පිළිබඳ මනා දැනුමක් ඇති අය අනිවාර්යයෙන්ම එවැනි ගැටලුවකට මුහුණ නොදෙනු ඇත. ඉතිරි අයට, මෙම ලිපිය ප්‍රයෝජනවත් වේ යැයි මම බලාපොරොත්තු වෙමි.
කියවීමට ස්තූතියි!
ඔබ මෙම ලිපියට කැමතිද, පරිවර්තනය පැහැදිලිද, එය ඔබට ප්‍රයෝජනවත්ද යන්න ඔබ අපට පැවසුවහොත් අපි ඉතා සතුටු වන්නෙමු.
මූලාශ්රය: www.habr.com