Cyflwyniad
Helo. Rwy'n ningenMe, datblygwr gwe.
Fel y mae'r teitl yn ei ddweud, fy stori yw hanes dileu 300 miliwn o gofnodion yn MySQL yn gorfforol.
Dechreuais ddiddordeb yn hyn, felly penderfynais wneud nodyn atgoffa (cyfarwyddiadau).
Cartref - Rhybudd
Mae gan y gweinydd swp rwy'n ei ddefnyddio a'i gynnal broses reolaidd sy'n casglu data'r mis diwethaf o MySQL unwaith y dydd.
Fel arfer cwblheir y broses hon o fewn tua 1 awr, ond ni chwblhawyd y tro hwn am 7 neu 8 awr, ac ni ddaeth y rhybudd i ben ...
Chwilio am reswm
Ceisiais ailgychwyn y broses ac edrych ar y logiau, ond ni welais unrhyw beth o'i le.
Mynegwyd yr ymholiad yn gywir. Ond pan feddyliais beth oedd yn mynd o'i le, sylweddolais fod maint y gronfa ddata yn eithaf mawr.
hoge_table | 350'000'000 |350 miliwn o gofnodion. Roedd yn ymddangos bod y mynegeio yn gweithio'n gywir, dim ond yn araf iawn.
Y casgliad data gofynnol y mis oedd tua 12 o gofnodion. Mae'n edrych fel bod y gorchymyn dethol wedi cymryd amser hir ac ni weithredwyd y trafodiad am amser hir.
DB
Yn ei hanfod mae'n fwrdd sy'n cynyddu tua 400 o gofnodion bob dydd. Roedd y gronfa ddata i fod i gasglu data ar gyfer y mis diwethaf yn unig, felly, y disgwyl oedd y byddai'n gwrthsefyll yr union swm hwn o ddata, ond, yn anffodus, ni chynhwyswyd y gweithrediad cylchdroi.
Ni ddatblygwyd y gronfa ddata hon gennyf i. Fe wnes i ei gymryd drosodd gan ddatblygwr arall, felly roedd yn dal i deimlo fel dyled dechnegol.
Daeth pwynt pan ddaeth cyfaint y data a fewnosodwyd bob dydd yn fawr a chyrraedd ei derfyn o'r diwedd. Tybir, wrth weithio gyda chymaint o ddata, y byddai angen eu gwahanu, ond ni wnaethpwyd hyn, yn anffodus.
Ac yna deuthum i weithredu.
Cywiriad
Roedd yn fwy rhesymegol lleihau maint y gronfa ddata ei hun a lleihau'r amser ar gyfer ei phrosesu na newid y rhesymeg ei hun.
Dylai'r sefyllfa newid yn sylweddol os ydych chi'n dileu 300 miliwn o gofnodion, felly penderfynais wneud hynny... Eh, roeddwn i'n meddwl y byddai hyn yn bendant yn gweithio.
Gweithred 1
Ar ôl paratoi copi wrth gefn dibynadwy, dechreuais anfon ceisiadau o'r diwedd.
‘Anfon cais’
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"…"
"…"
“Hmm... Dim ateb. Efallai bod y broses yn cymryd amser hir?” - Roeddwn i'n meddwl, ond rhag ofn, edrychais ar grafana a gweld bod y llwyth disg yn tyfu'n gyflym iawn.
“Peryglus,” meddyliais eto ac atal y cais ar unwaith.
Gweithred 2
Ar ôl dadansoddi popeth, sylweddolais fod cyfaint y data yn rhy fawr i ddileu popeth ar unwaith.
Penderfynais ysgrifennu sgript a allai ddileu tua 1 o gofnodion a'i lansio.
‘Rwy’n gweithredu’r sgript’
“Nawr bydd hyn yn bendant yn gweithio,” meddyliais.
Gweithred 3
Gweithiodd yr ail ddull, ond trodd allan i fod yn llafurddwys iawn.
Byddai gwneud popeth yn ofalus, heb nerfau diangen, yn cymryd tua phythefnos. Ond o hyd, nid oedd y senario hwn yn bodloni gofynion y gwasanaeth, felly bu'n rhaid i ni symud oddi wrtho.
Felly dyma beth wnes i benderfynu ei wneud:
Copïwch y tabl a'i ailenwi
O'r cam blaenorol, sylweddolais fod dileu cymaint o ddata yn creu llwyth yr un mor fawr. Felly penderfynais greu tabl newydd o'r dechrau gan ddefnyddio mewnosod a symud y data roeddwn i'n mynd i'w ddileu i mewn iddo.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Os gwnewch y tabl newydd yr un maint ag uchod, dylai'r cyflymder prosesu data hefyd ddod yn 1/7 yn gyflymach.
Ar ôl creu'r bwrdd a'i ailenwi, dechreuais ei ddefnyddio fel y prif fwrdd. Nawr os ydw i'n gollwng y bwrdd gyda 300 miliwn o gofnodion dylai popeth fod yn iawn.
Darganfûm fod cwtogi neu ollwng yn creu llai o orbenion na dileu a phenderfynais ddefnyddio'r dull hwn.
Perfformiad
‘Anfon cais’
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"…"
"…"
"Em…?"
Gweithred 4
Roeddwn i'n meddwl y byddai'r syniad blaenorol yn gweithio, ond ar ôl anfon y cais mewnosod, ymddangosodd gwallau lluosog. Nid yw MySQL yn faddau.
Roeddwn i wedi blino cymaint yn barod nes i mi ddechrau meddwl nad oeddwn i eisiau gwneud hyn bellach.
Eisteddais a meddwl a sylweddoli efallai bod gormod o ymholiadau mewnosod am un tro...
Ceisiais anfon cais mewnosod am faint o ddata y dylai'r gronfa ddata ei brosesu mewn 1 diwrnod. Digwyddodd!
Wel, ar ôl hynny rydym yn parhau i anfon ceisiadau am yr un faint o ddata. Gan fod angen i ni ddileu gwerth mis o ddata, rydym yn ailadrodd y llawdriniaeth hon tua 35 o weithiau.
Ailenwi tabl
Yma roedd lwc ar fy ochr: aeth popeth yn esmwyth.
Rhybudd wedi mynd ar goll
Mae cyflymder prosesu swp wedi cynyddu.
Yn flaenorol, cymerodd y broses hon tua awr, nawr mae'n cymryd tua 2 funud.
Ar ôl i mi fod yn siŵr bod yr holl broblemau wedi'u datrys, gollyngais 300 miliwn o gofnodion. Rwy'n dileu'r tabl ac yn teimlo aileni.
Crynodeb
Sylweddolais fod prosesu cylchdro ar goll mewn prosesu swp, a dyna oedd y brif broblem. Mae'r math hwn o gamgymeriad pensaernïol yn arwain at wastraff amser.
Ydych chi'n meddwl am y llwyth wrth atgynhyrchu data wrth ddileu cofnodion o'r gronfa ddata? Gadewch i ni beidio â gorlwytho MySQL.
Yn sicr ni fydd y rhai sy'n hyddysg mewn cronfeydd data yn dod ar draws problem o'r fath. I'r gweddill ohonoch, rwy'n gobeithio bod yr erthygl hon wedi bod yn ddefnyddiol.
Diolch am ddarllen!
Byddwn yn falch iawn os dywedwch wrthym a oeddech yn hoffi'r erthygl hon, a yw'r cyfieithiad yn glir, a oedd yn ddefnyddiol i chi?
Ffynhonnell: hab.com