Hadithi ya kufuta rekodi milioni 300 kwenye MySQL

Utangulizi

Habari. Mimi ni ningenMe, msanidi wa wavuti.

Kama kichwa kinavyosema, hadithi yangu ni hadithi ya kufuta rekodi milioni 300 kwenye MySQL.

Nilipendezwa na hili, kwa hiyo niliamua kufanya ukumbusho (maelekezo).

Nyumbani - Tahadhari

Seva ya bechi ninayotumia na kudumisha ina mchakato wa kawaida ambao unakusanya data ya mwezi uliopita kutoka kwa MySQL mara moja kwa siku.

Kawaida mchakato huu unakamilika ndani ya saa 1, lakini wakati huu haukukamilika kwa masaa 7 au 8, na tahadhari haikuacha kutokea...

Kutafuta sababu

Nilijaribu kuanzisha upya mchakato na kuangalia magogo, lakini sikuona chochote kibaya.
Hoja iliorodheshwa kwa usahihi. Lakini nilipofikiria juu ya kile kinachoenda vibaya, niligundua kuwa saizi ya hifadhidata ni kubwa sana.

hoge_table | 350'000'000 |

rekodi milioni 350. Uorodheshaji ulionekana kufanya kazi kwa usahihi, polepole sana.

Ukusanyaji wa data uliohitajika kwa mwezi ulikuwa takriban rekodi 12. Inaonekana kama amri ya kuchagua ilichukua muda mrefu na muamala haukutekelezwa kwa muda mrefu.

DB

Kimsingi ni jedwali ambalo hukua kwa takriban maingizo 400 kila siku. Database ilitakiwa kukusanya data tu kwa mwezi uliopita, kwa hiyo, ilitarajiwa kuwa itastahimili hasa kiasi hiki cha data, lakini, kwa bahati mbaya, operesheni ya mzunguko haikujumuishwa.

Database hii haikutengenezwa na mimi. Niliichukua kutoka kwa msanidi mwingine, kwa hivyo bado ilionekana kama deni la kiufundi.

Ilifika wakati kiasi cha data iliyoingizwa kila siku ikawa kubwa na hatimaye kufikia kikomo chake. Inachukuliwa kuwa wakati wa kufanya kazi na kiasi kikubwa cha data, itakuwa muhimu kuwatenganisha, lakini hii, kwa bahati mbaya, haikufanyika.

Na kisha nikaingia kwenye hatua.

Marekebisho

Ilikuwa busara zaidi kupunguza saizi ya hifadhidata yenyewe na kupunguza wakati wa kuichakata kuliko kubadilisha mantiki yenyewe.

Hali inapaswa kubadilika kwa kiasi kikubwa ikiwa utafuta rekodi milioni 300, kwa hiyo niliamua kufanya hivyo ... Eh, nilifikiri hii itafanya kazi.

Kitendo 1

Baada ya kuandaa nakala ya kuaminika, hatimaye nilianza kutuma maombi.

"Kutuma ombi"

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

"…"

"…"

“Hmm... Hakuna jibu. Labda mchakato unachukua muda mrefu?" - Nilidhani, lakini ikiwa tu, nilitazama grafana na kuona kwamba mzigo wa disk ulikuwa unakua haraka sana.
“Hatari,” niliwaza tena na mara moja nikasimamisha ombi hilo.

Kitendo 2

Baada ya kuchambua kila kitu, niligundua kuwa kiasi cha data kilikuwa kikubwa sana kufuta kila kitu mara moja.

Niliamua kuandika hati ambayo inaweza kufuta takriban rekodi 1 na kuizindua.

"Ninatekeleza maandishi"

"Sasa hii itafanya kazi," niliwaza.

Kitendo 3

Njia ya pili ilifanya kazi, lakini ikawa ngumu sana.
Kufanya kila kitu kwa uangalifu, bila mishipa isiyohitajika, itachukua muda wa wiki mbili. Lakini bado, hali hii haikukidhi mahitaji ya huduma, kwa hivyo tulilazimika kuiacha.

Kwa hivyo hii ndio niliamua kufanya:

Nakili jedwali na uipe jina jipya

Kutoka kwa hatua ya awali, niligundua kuwa kufuta kiasi kikubwa cha data hujenga mzigo mkubwa sawa. Kwa hivyo niliamua kuunda jedwali mpya kutoka mwanzo kwa kutumia kuingiza na kuhamisha data ambayo ningeifuta ndani yake.

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

Ukifanya jedwali jipya kuwa na ukubwa sawa na hapo juu, kasi ya usindikaji wa data inapaswa pia kuwa 1/7 haraka.

Baada ya kuunda jedwali na kuipa jina jipya, nilianza kuitumia kama meza kuu. Sasa nikiangusha meza na rekodi milioni 300 kila kitu kinapaswa kuwa sawa.
Niligundua kuwa truncate au drop huunda kichwa kidogo kuliko kufuta na nikaamua kutumia njia hii.

Utimilifu

"Kutuma ombi"

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

"…"
"…"
"Em…?"

Kitendo 4

Nilidhani wazo la awali lingefanya kazi, lakini baada ya kutuma ombi la kuingiza, makosa mengi yalionekana. MySQL sio kusamehe.

Tayari nilikuwa nimechoka sana hivi kwamba nilianza kufikiria kuwa sitaki kufanya hivi tena.

Nilikaa na kufikiria na kugundua kuwa labda kulikuwa na maswali mengi ya kuingiza kwa wakati mmoja ...
Nilijaribu kutuma ombi la kuingiza kiasi cha data ambacho hifadhidata inapaswa kuchakata kwa siku 1. Imetokea!

Naam, baada ya hayo tunaendelea kutuma maombi ya kiasi sawa cha data. Kwa kuwa tunahitaji kuondoa data ya mwezi mmoja, tunarudia operesheni hii takriban mara 35.

Kubadilisha jina la jedwali

Hapa bahati ilikuwa upande wangu: kila kitu kilikwenda vizuri.

Arifa imepotea

Kasi ya kuchakata bechi imeongezeka.

Hapo awali mchakato huu ulichukua kama saa moja, sasa inachukua kama dakika 2.

Baada ya kuwa na uhakika kwamba matatizo yote yametatuliwa, niliacha rekodi milioni 300. Niliifuta meza na kuhisi kuzaliwa upya.

Muhtasari

Niligundua kuwa usindikaji wa mzunguko haukuwepo katika usindikaji wa kundi, na hiyo ndiyo ilikuwa shida kuu. Aina hii ya makosa ya usanifu husababisha kupoteza muda.

Unafikiria juu ya mzigo wakati wa kurudia data wakati wa kufuta rekodi kutoka kwa hifadhidata? Wacha tusizidishe MySQL.

Wale ambao wanajua vizuri hifadhidata hakika hawatakutana na shida kama hiyo. Kwa ninyi wengine, natumai nakala hii ilikuwa muhimu.

Asante kwa kusoma!

Tutafurahi sana ikiwa utatuambia ikiwa ulipenda nakala hii, ikiwa tafsiri ni wazi, ikiwa ilikuwa muhimu kwako?

Chanzo: mapenzi.com