Ang kwento ng pisikal na pagtanggal ng 300 milyong tala sa MySQL

Pagpapakilala

Kamusta. Ako si ningenMe, web developer.

Tulad ng sinasabi ng pamagat, ang aking kuwento ay ang kuwento ng pisikal na pagtanggal ng 300 milyong mga tala sa MySQL.

Naging interesado ako dito, kaya nagpasiya akong gumawa ng paalala (mga tagubilin).

Tahanan - Alerto

Ang batch server na ginagamit at pinapanatili ko ay may regular na proseso na nangongolekta ng data noong nakaraang buwan mula sa MySQL isang beses sa isang araw.

Karaniwan ang prosesong ito ay nakumpleto sa loob ng humigit-kumulang 1 oras, ngunit sa pagkakataong ito ay hindi ito nakumpleto sa loob ng 7 o 8 oras, at ang alerto ay hindi huminto sa pag-pop up...

Naghahanap ng dahilan

Sinubukan kong i-restart ang proseso at tingnan ang mga log, ngunit wala akong nakitang mali.
Na-index nang tama ang query. Ngunit nang naisip ko kung ano ang mali, napagtanto ko na ang laki ng database ay medyo malaki.

hoge_table | 350'000'000 |

350 milyong mga rekord. Mukhang gumagana nang tama ang pag-index, napakabagal lang.

Ang kinakailangang pangongolekta ng data bawat buwan ay humigit-kumulang 12 mga tala. Mukhang natagalan ang piling utos at ang transaksyon ay hindi naisagawa ng mahabang panahon.

DB

Ito ay mahalagang talahanayan na lumalaki ng humigit-kumulang 400 mga entry araw-araw. Ang database ay dapat na mangolekta ng data para lamang sa nakaraang buwan, samakatuwid, inaasahan na ito ay makatiis nang eksakto sa ganitong halaga ng data, ngunit, sa kasamaang-palad, ang pag-ikot ng operasyon ay hindi kasama.

Ang database na ito ay hindi ko binuo. Kinuha ko ito mula sa isa pang developer, kaya parang teknikal na utang.

Dumating ang isang punto na ang dami ng data na ipinasok araw-araw ay naging malaki at sa wakas ay umabot sa limitasyon nito. Ito ay ipinapalagay na kapag nagtatrabaho sa tulad ng isang malaking halaga ng data, ito ay kinakailangan upang paghiwalayin ang mga ito, ngunit ito, sa kasamaang-palad, ay hindi nagawa.

At pagkatapos ay kumilos na ako.

Pagwawasto

Ito ay mas makatwiran upang bawasan ang laki ng database mismo at bawasan ang oras para sa pagproseso nito kaysa baguhin ang logic mismo.

Ang sitwasyon ay dapat magbago nang malaki kung magbubura ka ng 300 milyong mga tala, kaya nagpasya akong gawin ito... Eh, akala ko ito ay tiyak na gagana.

Hakbang 1

Dahil naghanda ako ng maaasahang backup, sa wakas ay nagsimula akong magpadala ng mga kahilingan.

「Nagpapadala ng kahilingan」

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

"…"

"…"

“Hmm... Walang sagot. Baka mahaba ang proseso?" — Akala ko, ngunit kung sakali, tumingin ako sa grafana at nakita kong napakabilis ng paglaki ng disk load.
"Mapanganib," muli kong naisip at agad na itinigil ang kahilingan.

Hakbang 2

Matapos suriin ang lahat, napagtanto ko na ang dami ng data ay masyadong malaki upang tanggalin ang lahat nang sabay-sabay.

Nagpasya akong magsulat ng script na maaaring magtanggal ng humigit-kumulang 1 na mga tala at inilunsad ito.

「Ipinatupad ko ang script」

"Ngayon ito ay tiyak na gagana," naisip ko.

Hakbang 3

Ang pangalawang paraan ay nagtrabaho, ngunit naging napakahirap sa paggawa.
Upang gawin ang lahat nang maingat, nang walang hindi kinakailangang mga nerbiyos, ay aabutin ng mga dalawang linggo. Ngunit gayunpaman, hindi natugunan ng sitwasyong ito ang mga kinakailangan sa serbisyo, kaya kinailangan naming lumayo rito.

Kaya narito ang napagpasyahan kong gawin:

Kopyahin ang talahanayan at palitan ang pangalan nito

Mula sa nakaraang hakbang, napagtanto ko na ang pagtanggal ng ganoong kalaking dami ng data ay lumilikha ng parehong malaking pagkarga. Kaya nagpasya akong lumikha ng isang bagong talahanayan mula sa simula gamit ang insert at ilipat ang data na tatanggalin ko dito.

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

Kung gagawin mo ang bagong talahanayan sa parehong laki tulad ng nasa itaas, ang bilis ng pagproseso ng data ay dapat ding maging 1/7 na mas mabilis.

Matapos gawin ang talahanayan at palitan ang pangalan nito, sinimulan ko itong gamitin bilang master table. Ngayon kung ibababa ko ang talahanayan na may 300 milyong mga talaan ang lahat ay dapat na maayos.
Nalaman ko na ang truncate o drop ay lumilikha ng mas kaunting overhead kaysa sa tanggalin at nagpasyang gamitin ang paraang ito.

Katuparan

「Nagpapadala ng kahilingan」

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

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

Hakbang 4

Akala ko gagana ang nakaraang ideya, ngunit pagkatapos ipadala ang kahilingan sa pagpasok, maraming mga error ang lumitaw. Ang MySQL ay hindi mapagpatawad.

Pagod na ako kaya naisip ko na ayaw ko nang gawin ito.

Umupo ako at nag-isip at napagtanto na marahil ay napakaraming insert query sa isang pagkakataon...
Sinubukan kong magpadala ng insert request para sa dami ng data na dapat iproseso ng database sa loob ng 1 araw. Nangyari!

Well, pagkatapos nito ay patuloy kaming nagpapadala ng mga kahilingan para sa parehong dami ng data. Dahil kailangan naming alisin ang isang buwang halaga ng data, inuulit namin ang operasyong ito nang humigit-kumulang 35 beses.

Pagpapalit ng pangalan ng talahanayan

Narito ang swerte ay nasa aking panig: ang lahat ay naging maayos.

Nawala ang alerto

Ang bilis ng pagproseso ng batch ay tumaas.

Dati ang prosesong ito ay tumatagal ng halos isang oras, ngayon ay tumatagal ng mga 2 minuto.

Matapos kong matiyak na ang lahat ng mga problema ay nalutas, naghulog ako ng 300 milyong mga rekord. Tinanggal ko ang mesa at naramdaman kong muling isilang.

Buod

Napagtanto ko na ang pagpoproseso ng pag-ikot ay nawawala sa pagpoproseso ng batch, at iyon ang pangunahing problema. Ang ganitong uri ng error sa arkitektura ay humahantong sa isang pag-aaksaya ng oras.

Iniisip mo ba ang tungkol sa pag-load sa panahon ng pagtitiklop ng data kapag nagtatanggal ng mga tala mula sa database? Huwag nating i-overload ang MySQL.

Ang mga bihasa sa mga database ay tiyak na hindi makakatagpo ng ganoong problema. Para sa iba pa sa inyo, sana ay naging kapaki-pakinabang ang artikulong ito.

Salamat sa pagbabasa!

Lubos kaming matutuwa kung sasabihin mo sa amin kung nagustuhan mo ang artikulong ito, kung ang pagsasalin ay malinaw, kung ito ay kapaki-pakinabang sa iyo?

Pinagmulan: www.habr.com