Lugu 300 miljoni kirje füüsilisest kustutamisest MySQL-is

Sissejuhatus

Tere. Mina olen ningenMe, veebi arendaja.

Nagu pealkirjas öeldud, on minu lugu 300 miljoni kirje füüsilisest kustutamisest MySQL-is.

See huvitab mind, seetõttu otsustasin koostada meelespea (juhendi).

Algus — Alarm

Kogumisprotsessis, mida ma kasutan ja hooldan, on regulaarne protsess, mis korjab MySQL-ist andmed viimase kuu kohta üks kord päevas. serverisTavaliselt lõpetatakse see protsess umbes 1 tunni jooksul, kuid seekord ei lõpetanud see 7 või 8 tunni jooksul ja alarm ei lakka ilmumast…

Põhjuse otsimine

Proovisin protsessi taaskäivitada, vaadata logisid, kuid midagi hullemat ma ei näinud.

Päring indekseeriti õigesti. Kuid kui ma mõtlema hakkasin, mis valesti käib, sain ma aru, et andmebaasi suurus on üsna suur.
hoge_table | 350'000'000 |

350 miljonit kirjet. Tundub, et indekseerimine toimis õigesti, lihtsalt väga aeglaselt.

Kogutud andmed kuu kohta olid umbes 12 000 000 kirjet. Tundub, et select-käsk võttis palju aega ja tehing ei täitunud pikka aega.

DB

Põhimõtteliselt on see tabel, mis kasvab iga päev umbes 400 000 kirje võrra. Andmebaas pidi koguma andmeid ainult viimase kuu kohta, seega arvati, et see talub just selle mahu andmeid, kuid kahjuks ei olnud rotate operatsioon sisse lülitatud.

See andmebaas ei olnud minu loodud. Võtsin selle üle teiselt arendajalt, seetõttu on jäänud tunne, et see on tehniline võlg.

Kohale jõudis hetk, mil igapäevaselt sisestatav andmemahu suurenemine saavutas lõpuks piiri. Eeldatakse, et töötades sellise suure andmemahuga, tuleks neid jagada, kuid kahjuks seda ei tehtud.

Ja siis astusin ma mängu.

Parandus

Mugav oli andmebaasi mahtu vähendada ja töötlusaega lühendada, kui muuta kogu loogikat.

Kuna olukord peaks paranema oluliselt, kui kustutada 300 miljonit kirjet, otsustasin seda teha… Ah, ma arvasin, et see tõesti toimib.

Tegevus 1

Usaldusväärse varukoopia teinud, hakkasin lõpuks päringut saatma.

「Päringu saatmine」

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

KUSTUTA FROM hoge_table KUS create_time <= 'YYYY-MM-DD HH:MM:SS';

「…」

「…」

„Hmm... Pole pole puudub. Kas protsess võtab palju aega?” — mõtlesin ma, kuid igaks juhuks vaatasin grafanasse ja nägin, et ketta koormus suurenes väga kiiresti.
„Ohtlik” — mõtlesin ma veel kord ja peatasin kohe päringu.

Tegevus 2

Kõike analüüsides sain aru, et andmehulka oli liiga suur, et kõike ühel korral kustutada.

Otsustasin kirjutada skripti, mis suudab kustutada umbes 1 000 000 kirjet ja käivitasin selle.

„rakendan skripti”

„Nüüd peaks kindlasti toimima,” — mõtlesin ma.

Tegevus 3

Teine meetod toimis, kuid osutus küllalt töömahukaks.
Kui kõik teha korralikult, ilma liigsete närvideta, kuluks umbes kaks nädalat. Kuid see stsenaarium ei vastanud teenuse nõuetele, seega tuli sellest loobuda.

Seetõttu otsustasin:

Kopeerime tabeli ja nimetame ümber.

Eelmise sammu põhjal sain aru, et sellise suure andmemahtu kustutamine tekitab sama suure koormuse. Seega otsustasin luua uue tabeli nullist insert'i abil ja kanda sinna andmed, mille kavatsesin kustutada.

| hoge_table     | 350'000'000|
| tmp_hoge_table |  50'000'000|

Kui luua uus tabel, mis on sama suur kui eespool näidatud, siis peaks andmete töötlemise kiirus olema 1/7 kiiremini.

Loomiseks ja ümbernimetamiseks tabeli, hakkasin seda kasutama peamise tabelina. Nüüd, kui kustutan 300 miljoni kirje tabeli, peaks kõik olema korras.
Selgus, et truncate või drop tekitavad väiksemat koormust kui delete, ja otsustasin seda meetodit kasutada.

Tegevus

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

INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';

「…」
「…」
„Hmm...?”

Tegevus 4

Mõtlesin, et eelmine idee toimib, kuid pärast insert päringu saatmist läks palju viga. MySQL ei hooli.

Olin juba nii väsinud, et hakkasin mõtlema, et ei taha enam sellega tegeleda.

Mõtlesin veidi ja sain aru, et võib-olla oli ühe korra jaoks too palju insert päringuid...
Katsusin saata insert päringu andmemahtudele, mida andmebaas peab 1 päevaga töötlema. Õnnestus!

Ja pärast seda jätkame samade andmemahtude päringute saatmist. Kuna peame eemaldama kuu andmemahtu, korrame seda operatsiooni umbes 35 korda.

Tabeli ümbernimetamine

Siin oli õnn minu poolel: kõik läks sujuvalt.

Häired kadusid

Partii töötlemise kiirus suurenes.

Varasemalt võttis see protsess umbes tund aega, nüüd kulub umbes 2 minutit.

Pärast seda, kui ma veendusin, et kõik probleemid on lahendatud, kustutasin 300 miljonit kirjet. Kustutasin tabeli ja tundsin end nagu uuesti sündinud.

Kokkuvõte

Sain aru, et partii töötlemise käigus jäi välja pööramise töötlemine ja see oli peamine probleem. Selline arhitektuuri viga toob kaasa ajakulu.

Kas mõtlete koormusele andmete replikatsiooni ajal, kustutades kirjeid andmebaasist? Ärgem koormake MySQL-i üle.

Need, kes tunnevad andmebaase hästi, ei puutu sellise probleemiga tõenäoliselt kokku. Loodetavasti oli see artikkel teistele kasulik.

Aitäh lugemise eest!

Oleksime väga tänulikud, kui räägiksite meile, kas see artikkel meeldis, kas tõlge oli arusaadav ja kas see oli teile kasulik?

Allikas: habr.com