MySQL-n 300 milioi erregistro fisikoki ezabatzearen istorioa

Sarrera

Kaixo. NingenMe naiz, web garatzailea.

Izenburuak dioen bezala, nire istorioa MySQL-en 300 milioi erregistro fisikoki ezabatzearen istorioa da.

Honen interesa piztu zitzaidan, beraz, gogorarazle bat egitea erabaki nuen (argibideak).

Hasiera - Alerta

Erabili eta mantentzen dudan batch zerbitzariak egunean behin MySQL-tik azken hilabeteko datuak biltzen dituen ohiko prozesu bat du.

Normalean, prozesu hau ordubete inguruko epean amaitzen da, baina oraingoan ez da 1 edo 7 orduz amaitu, eta alertak ez zuen gelditzen...

Arrazoiren bat bilatzen

Prozesua berrabiarazten eta erregistroak ikusten saiatu nintzen, baina ez nuen ezer gaizki ikusi.
Kontsulta behar bezala indexatu da. Baina zer gertatzen ari zen pentsatu nuenean, datu-basearen tamaina nahiko handia dela konturatu nintzen.

hoge_table | 350'000'000 |

350 milioi disko. Indexatzea ondo funtzionatzen ari zela zirudien, oso motela.

Hilero eskatutako datu bilketa 12 erregistro gutxi gorabehera. Aukeratutako komandoak denbora luzea hartu duela dirudi eta transakzioa ez da denbora luzez exekutatu.

DB

Funtsean, egunero 400 sarrera inguru hazten den taula da. Datu-baseak azken hilabeteko datuak bakarrik bildu behar zituen, beraz, datu kopuru hori zehatz-mehatz jasango zuela espero zen, baina, tamalez, ez zen txandaketa eragiketa sartu.

Datu-base hau ez dut nik garatu. Beste garatzaile batengandik hartu nuen, beraz, oraindik zor teknikoa bezala sentitu zen.

Iritsi zen une bat egunero txertatutako datuen bolumena handitu zen eta azkenean bere mugara iritsi zen. Suposatzen da datu kopuru handiarekin lan egitean horiek bereiztea beharrezkoa izango zela, baina hori, zoritxarrez, ez zen egin.

Eta orduan sartu nintzen ekintzara.

Zuzenketa

Arrazionalagoa zen datu-basearen beraren tamaina murriztea eta prozesatzeko denbora murriztea logika bera aldatzea baino.

Egoerak nabarmen aldatu beharko luke 300 milioi erregistro ezabatzen badituzu, beraz, hori egitea erabaki nuen... Eh, uste nuen honek funtzionatuko zuela.

1. ekintza

Babeskopia fidagarri bat prestatuta, azkenean eskaerak bidaltzen hasi nintzen.

「Eskaera bat bidaltzen」

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

"…"

"…"

“Hmm... Ez dago erantzunik. Agian prozesuak denbora luzea hartzen du?». — Pentsatu nuen, baina badaezpada, grafana begiratu eta diskoaren karga oso azkar hazten ari zela ikusi nuen.
"Arriskutsua", pentsatu nuen berriro eta berehala gelditu nuen eskaera.

2. ekintza

Dena aztertu ondoren, konturatu nintzen datuen bolumena handiegia zela dena aldi berean ezabatzeko.

1 erregistro inguru ezaba ditzakeen gidoia idaztea erabaki nuen eta martxan jarri nuen.

「Scripta inplementatzen dut」

"Orain, zalantzarik gabe, funtzionatuko du", pentsatu nuen.

3. ekintza

Bigarren metodoak funtzionatu zuen, baina oso lan intentsiboa izan zen.
Dena kontu handiz egiteko, alferrikako nerbiorik gabe, bi aste inguru beharko lirateke. Baina, hala ere, eszenatoki honek ez zituen zerbitzu-eskakizunak betetzen, hortaz alde egin behar izan genuen.

Beraz, hona hemen egitea erabaki nuena:

Kopiatu taula eta izena aldatu

Aurreko urratsetik, konturatu nintzen datu kopuru handia ezabatzeak karga berdin handia sortzen duela. Beraz, taula berri bat sortzea erabaki nuen txertatzea erabiliz eta ezabatuko nituen datuak bertara mugitzea.

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

Taula berria goiko tamaina berekoa egiten baduzu, datuak prozesatzeko abiadura ere 1/7 azkarragoa bihurtu beharko litzateke.

Taula sortu eta izena aldatu ondoren, mahai nagusi gisa erabiltzen hasi nintzen. Orain 300 milioi erregistro dituen mahaia jaisten badut dena ondo egon beharko litzateke.
Moztu edo erortzeak ezabatzeak baino gastu gutxiago sortzen duela jakin nuen eta metodo hau erabiltzea erabaki nuen.

Emanaldia

「Eskaera bat bidaltzen」

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

"…"
"…"
"Em...?"

4. ekintza

Aurreko ideiak funtzionatuko zuela uste nuen, baina txertatzeko eskaera bidali ondoren, hainbat errore agertu ziren. MySQL-k ez du barkatzen.

Hain nekatuta nengoen jada ez nuela hau gehiago egin nahi pentsatzen hasi nintzen.

Eseri eta pentsatu eta konturatu nintzen agian txertatzeko kontsulta gehiegi zeudela aldi baterako...
Datu-baseak egun batean prozesatu beharko lukeen datu kopuruaren txertatze eskaera bidaltzen saiatu nintzen. Gertatu da!

Tira, horren ostean datu kopuru bereko eskaerak bidaltzen jarraitzen dugu. Hilabeteko datuak kendu behar ditugunez, eragiketa hau gutxi gorabehera 35 aldiz errepikatuko dugu.

Taula baten izena aldatzea

Hemen zortea nire alde zegoen: dena ondo joan zen.

Alerta desagertu da

Batch prozesatzeko abiadura handitu egin da.

Lehen prozesu honek ordubete inguru behar zuen, orain 2 minutu inguru.

Arazo guztiak konponduta zeudela ziur egon ondoren, 300 milioi disko bota nituen. Mahaia ezabatu eta berriro jaio nintzen.

Laburpen

Batch prozesatzeko errotazio prozesatzea falta zela konturatu nintzen, eta hori zen arazo nagusia. Akats arkitektoniko honek denbora galtzea dakar.

Datu-erreplikatzerakoan kargari buruz pentsatzen al duzu datu-basetik erregistroak ezabatzean? Ez dezagun MySQL gainkargatu.

Datu-baseetan ondo ezagutzen dutenek, zalantzarik gabe, ez dute horrelako arazorik aurkituko. Gainontzekoentzat, artikulu hau erabilgarria izatea espero dut.

Eskerrik asko irakurtzeagatik!

Oso poztuko gara artikulu hau gustatu zaizun ala ez, itzulpena argia den ala ez, baliagarria izan zaizun esaten badiguzu?

Iturria: www.habr.com