Inngangur
Halló. Ég er ningenMe, vefhönnuður.
Eins og titillinn segir, er sagan mín sagan um að eyða líkamlega 300 milljón færslum í MySQL.
Ég fékk áhuga á þessu, svo ég ákvað að gera áminningu (leiðbeiningar).
Heim - Viðvörun
Lotuþjónninn sem ég nota og viðhalda er með reglulegt ferli sem safnar gögnum síðasta mánaðar frá MySQL einu sinni á dag.
Venjulega er þessu ferli lokið innan um 1 klukkustund, en að þessu sinni lauk því ekki í 7 eða 8 klukkustundir, og viðvörunin hætti ekki að birtast...
Að leita að ástæðu
Ég reyndi að endurræsa ferlið og skoða skrárnar, en ég sá ekkert athugavert.
Fyrirspurnin var rétt skráð. En þegar ég hugsaði um hvað væri að fara, áttaði ég mig á því að stærð gagnagrunnsins er frekar stór.
hoge_table | 350'000'000 |350 milljón skrár. Flokkun virtist vera rétt, bara mjög hægt.
Nauðsynleg gagnasöfnun á mánuði var um það bil 12 færslur. Það lítur út fyrir að velja skipunin hafi tekið langan tíma og viðskiptin hafi ekki verið framkvæmd í langan tíma.
DB
Þetta er í rauninni tafla sem stækkar um 400 færslur á hverjum degi. Gagnagrunnurinn átti aðeins að safna gögnum fyrir síðasta mánuð og því var búist við að hann myndi þola nákvæmlega þetta gagnamagn, en því miður var snúningsaðgerðin ekki innifalin.
Þessi gagnagrunnur var ekki þróaður af mér. Ég tók við því af öðrum forritara, þannig að það leið samt eins og tæknileg skuld.
Það kom að því að magn gagna sem sett var inn daglega varð mikið og náði loks hámarki. Gert er ráð fyrir að þegar unnið er með svo mikið gagnamagn þyrfti að aðskilja þau en það var því miður ekki gert.
Og svo kom ég í aðgerð.
Leiðrétting
Skynsamlegra var að minnka gagnagrunninn sjálfan og stytta vinnslutímann heldur en að breyta rökfræðinni sjálfri.
Staðan ætti að breytast verulega ef þú eyðir 300 milljón færslum, svo ég ákvað að gera það... Æ, ég hélt að þetta myndi örugglega virka.
Aðgerð 1
Eftir að hafa útbúið áreiðanlegt öryggisafrit byrjaði ég loksins að senda beiðnir.
「Sendu beiðni」
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"..."
"..."
“Hmm... Ekkert svar. Kannski tekur ferlið langan tíma?“ — Ég hugsaði, en fyrir tilviljun, horfði ég á grafana og sá að diskaálagið var að aukast mjög hratt.
„Hættulegt,“ hugsaði ég aftur og hætti strax við beiðnina.
Aðgerð 2
Eftir að hafa greint allt, áttaði ég mig á því að gagnamagnið var of mikið til að eyða öllu í einu.
Ég ákvað að skrifa handrit sem gæti eytt um 1 færslum og setti það af stað.
「Ég útfæri handritið」
„Nú mun þetta örugglega virka,“ hugsaði ég.
Aðgerð 3
Önnur aðferðin virkaði en reyndist mjög vinnufrek.
Að gera allt vandlega, án óþarfa tauga, myndi taka um tvær vikur. En samt uppfyllti þessi atburðarás ekki þjónustukröfurnar og því urðum við að hverfa frá henni.
Svo hér er það sem ég ákvað að gera:
Afritaðu töfluna og endurnefna hana
Frá fyrra skrefi áttaði ég mig á því að það að eyða svo miklu magni af gögnum skapar jafn mikið álag. Svo ég ákvað að búa til nýja töflu frá grunni með því að nota insert og færa gögnin sem ég ætlaði að eyða inn í hana.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Ef þú gerir nýju töfluna í sömu stærð og hér að ofan ætti gagnavinnsluhraði líka að verða 1/7 hraðari.
Eftir að hafa búið til töfluna og endurnefna hana byrjaði ég að nota hana sem aðaltöfluna. Nú ef ég felli borðið með 300 milljón færslur ætti allt að vera í lagi.
Ég komst að því að stytta eða sleppa skapar minna kostnaðarauka en eyða og ákvað að nota þessa aðferð.
Frammistaða
「Sendu beiðni」
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"..."
"..."
"Em...?"
Aðgerð 4
Ég hélt að fyrri hugmyndin myndi virka, en eftir að innsetningarbeiðnin var send birtust margar villur. MySQL er ekki fyrirgefandi.
Ég var þegar orðin svo þreytt að ég fór að hugsa um að ég vildi ekki gera þetta lengur.
Ég sat og hugsaði og áttaði mig á því að kannski voru of margar innsetningarfyrirspurnir í eitt skipti...
Ég prófaði að senda inn beiðni um hversu mikið gagnamagn gagnagrunnurinn ætti að vinna úr á 1 degi. Gerðist!
Jæja, eftir það höldum við áfram að senda beiðnir um sama magn af gögnum. Þar sem við þurfum að fjarlægja mánaðarvirði af gögnum endurtökum við þessa aðgerð um það bil 35 sinnum.
Endurnefna borð
Hér var heppnin með mér: allt gekk snurðulaust fyrir sig.
Viðvörun horfin
Hraði runuvinnslu hefur aukist.
Áður tók þetta ferli um klukkustund, nú tekur það um 2 mínútur.
Eftir að ég var viss um að öll vandamálin væru leyst féll ég niður 300 milljónir platna. Ég eyddi töflunni og fannst ég endurfæddur.
Samantekt
Ég áttaði mig á því að snúningsvinnslu vantaði í lotuvinnslu og það var aðalvandamálið. Slík byggingarvilla leiðir til tímasóunar.
Hugsar þú um álagið við afritun gagna þegar gögnum er eytt úr gagnagrunninum? Við skulum ekki ofhlaða MySQL.
Þeir sem eru vel að sér í gagnagrunnum munu örugglega ekki lenda í slíku vandamáli. Fyrir ykkur hin vona ég að þessi grein hafi verið gagnleg.
Takk fyrir að lesa!
Við munum vera mjög ánægð ef þú segir okkur hvort þér líkaði við þessa grein, hvort þýðingin sé skýr, hvort hún hafi verið gagnleg fyrir þig?
Heimild: www.habr.com