Ynlieding
Hallo. Ik bin ningenMe, webûntwikkelder.
Lykas de titel seit, is myn ferhaal it ferhaal fan fysyk wiskjen fan 300 miljoen records yn MySQL.
Ik waard ynteressearre yn dit, dus ik besleat om in herinnering (ynstruksjes).
Thús - Alert
De batchserver dy't ik brûk en ûnderhâld hat in regelmjittich proses dat de gegevens fan 'e lêste moanne fan MySQL ien kear deis sammelt.
Normaal wurdt dit proses binnen sawat 1 oere foltôge, mar dizze kear is it net foltôge foar 7 of 8 oeren, en de warskôging stoppe net op te ferskinen ...
It finen fan de reden
Ik besocht it proses opnij te begjinnen en nei de logs te sjen, mar ik seach neat ferkeard.
De fraach is goed yndeksearre. Mar doe't ik tocht oer wat der mis gie, realisearre ik dat de databankgrutte frij grut is.
hoge_table | 350'000'000 |350 miljoen records. Yndeksearring like goed te wurkjen, gewoan heul stadich.
De fereaske gegevenssammeling per moanne wie sawat 12 records. It liket derop dat it selektearkommando in lange tiid duorre en de transaksje in lange tiid net útfierd waard.
DB
It is yn wêzen in tabel dy't elke dei mei sawat 400 yngongen groeit. De databank soe allinich gegevens sammelje foar de lêste moanne, dêrom waard ferwachte dat it krekt dizze hoemannichte gegevens soe wjerstean, mar spitigernôch wie de rotaasjeoperaasje net opnommen.
Dizze databank is net troch my ûntwikkele. Ik naam it oer fan in oare ûntwikkelder, dus it fielde noch as technyske skuld.
Der kaam in punt doe't de folume fan gegevens ynfoege deistich waard grut en úteinlik berikte syn limyt. Der wurdt fan útgien dat by it wurkjen mei sa'n grutte hoemannichte gegevens it nedich wêze soe om se te skieden, mar dit is spitigernôch net dien.
En doe kaam ik yn aksje.
Korreksje
It wie rationaler om de grutte fan 'e databank sels te ferminderjen en de tiid foar it ferwurkjen te ferminderjen dan de logika sels te feroarjen.
De situaasje moat signifikant feroarje as jo 300 miljoen records wiskje, dus ik besleat dat te dwaan ... Eh, ik tocht dat dit perfoarst soe wurkje.
Aksje 1
Nei't ik in betroubere reservekopy hie taret, begon ik einlings oanfragen te ferstjoeren.
「In fersyk ferstjoere」
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';「…」
「…」
“Hmm... Gjin antwurd. Miskien duorret it proses lang?” - Ik tocht, mar foar it gefal, ik seach nei grafana en seach dat de skiif load wie tige fluch.
"Gefaarlik," tocht ik nochris en stoppe it fersyk daliks.
Aksje 2
Nei it analysearjen fan alles, realisearre ik dat it folume fan gegevens te grut wie om alles tagelyk te wiskjen.
Ik besleat in skript te skriuwen dat sawat 1 records kin wiskje en lansearre it.
「Ik implementearje it skript」
"No dit sil grif wurkje," tocht ik.
Aksje 3
De twadde metoade wurke, mar blykte tige arbeidsintensyf te wêzen.
Om alles foarsichtich te dwaan, sûnder ûnnedige senuwen, soe sawat twa wiken duorje. Mar dochs foldie dit senario net oan de tsjinsteasken, dus wy moasten der fan ôf.
Dus hjir is wat ik besleat te dwaan:
Kopiearje de tabel en omneame it
Fan 'e foarige stap realisearre ik dat it wiskjen fan sa'n grutte hoemannichte gegevens in like grutte lading skept. Dat ik besleat om in nije tabel fanôf it begjin te meitsjen mei ynfoegje en ferpleatse de gegevens dy't ik deryn woe wiskje.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|As jo de nije tabel deselde grutte meitsje as hjirboppe, moat de gegevensferwurkingssnelheid ek 1/7 flugger wurde.
Nei it oanmeitsjen fan de tabel en it omneame, begon ik it te brûken as de mastertabel. No as ik de tafel mei 300 miljoen records delfalle moat alles goed wêze.
Ik fûn út dat truncate of drop minder overhead makket dan wiskje en besleat dizze metoade te brûken.
Ferfolling
「In fersyk ferstjoere」
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
「…」
「…」
"Em...?"
Aksje 4
Ik tocht dat it foarige idee soe wurkje, mar nei it ferstjoeren fan it ynfoegje fersyk, ferskynden meardere flaters. MySQL is net ferjaan.
Ik wie al sa wurch dat ik begûn te tinken dat ik dit net mear dwaan woe.
Ik siet en tocht en realisearre dat der miskien tefolle ynfoegjefragen foar ien kear wiene ...
Ik besocht in ynfoegje fersyk te stjoeren foar de hoemannichte gegevens dy't de databank yn 1 dei moat ferwurkje. Happened!
No, dêrnei ferstjoere wy fersiken foar deselde hoemannichte gegevens. Sûnt wy moatte fuortsmite in moanne wearde fan gegevens, wy werhelje dizze operaasje likernôch 35 kear.
Omneame in tabel
Hjir wie it gelok oan myn kant: alles gie soepel.
Alert ferdwûn
Batch ferwurkjen snelheid is tanommen.
Earder duorre dit proses sawat in oere, no duorret it sawat 2 minuten.
Neidat ik wie wis dat alle problemen waarden oplost, Ik sakke 300 miljoen records. Ik wiske de tafel en fielde reborn.
Gearfetting
Ik realisearre dat rotaasje ferwurking wie mist yn batch ferwurking, en dat wie it wichtichste probleem. Dit soarte fan arsjitektoanyske flater resultearret yn in fergriemerij fan tiid.
Tinke jo oer de lading by gegevensreplikaasje by it wiskjen fan records út 'e databank? Litte wy MySQL net oerladen.
Dejingen dy't goed yn 'e databases binne, sille sa'n probleem perfoarst net tsjinkomme. Foar de rest fan jo hoopje ik dat dit artikel nuttich wie.
Tank foar it lêzen!
Wy sille tige bliid wêze as jo ús fertelle oft jo dit artikel leuk fine, oft de oersetting dúdlik is, oft it nuttich foar jo wie?
Boarne: www.habr.com