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 റെക്കോർഡുകൾ ഇല്ലാതാക്കാൻ കഴിയുന്ന ഒരു സ്ക്രിപ്റ്റ് എഴുതാൻ ഞാൻ തീരുമാനിച്ചു, അത് സമാരംഭിച്ചു.

"ഞാൻ തിരക്കഥ നടപ്പിലാക്കുന്നു"

“ഇപ്പോൾ ഇത് തീർച്ചയായും പ്രവർത്തിക്കും,” ഞാൻ വിചാരിച്ചു.

പ്രവർത്തനം 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