Aféierung
Hallo. Ech ningenMe, Web Entwéckler.
Wéi den Titel seet, meng Geschicht ass d'Geschicht vun der kierperlecher Läschung vun 300 Milliounen Opzeechnungen am MySQL.
Ech hunn mech interesséiert an dësem, also hunn ech beschloss eng Erënnerung ze maachen (Instruktioune).
Home - Alarm
De Batch-Server deen ech benotzen an erhalen huet e reegelméissege Prozess deen d'Donnéeën vum leschte Mount aus MySQL eemol am Dag sammelt.
Normalerweis ass dëse Prozess bannent ongeféier 1 Stonn ofgeschloss, awer dës Kéier ass et net fäerdeg fir 7 oder 8 Stonnen, an d'Alarm huet net opgehalen ...
De Grond ze fannen
Ech hu probéiert de Prozess nei ze starten an d'Logbicher ze kucken, awer ech hunn näischt falsch gesinn.
D'Ufro gouf richteg indexéiert. Awer wann ech geduecht hunn wat falsch gaang ass, hunn ech gemierkt datt d'Datebankgréisst zimlech grouss ass.
hoge_table | 350'000'000 |350 Millioune Rekorder. Indexéierung schéngt richteg ze schaffen, just ganz lues.
Déi erfuerderlech Datesammlung pro Mount war ongeféier 12 records. Et gesäit aus wéi wann de Select Kommando eng laang Zäit gedauert huet an d'Transaktioun net laang ausgefouert gouf.
DB
Et ass wesentlech en Dësch deen all Dag ëm ongeféier 400 Entréen wiisst. D'Datebank sollt nëmmen Daten fir de leschte Mount sammelen, dofir gouf erwaart datt se genee dës Quantitéit un Daten widderstoen, awer leider war d'Rotatiounsoperatioun net abegraff.
Dës Datebank gouf net vu mir entwéckelt. Ech hunn et vun engem aneren Entwéckler iwwerholl, sou datt et nach ëmmer wéi technesch Schold gefillt huet.
Et ass e Punkt komm, wou de Volume vun den Donnéeën, déi all Dag agefouert goufen, grouss ginn an endlech seng Limit erreecht hunn. Et gëtt ugeholl datt wann Dir mat esou enger grousser Quantitéit un Daten schafft, et néideg wier se ze trennen, awer dëst ass leider net gemaach.
An dunn sinn ech an Aktioun komm.
Korrektur
Et war méi rational d'Gréisst vun der Datebank selwer ze reduzéieren an d'Zäit fir d'Veraarbechtung ze reduzéieren wéi d'Logik selwer z'änneren.
D'Situatioun soll däitlech änneren wann Dir 300 Millioune Rekorder läscht, also hunn ech decidéiert dat ze maachen ... Ee, ech hat geduecht datt dëst definitiv klappt.
Aktioun 1
Nodeems ech en zouverléissege Backup virbereet hunn, hunn ech endlech ugefaang Ufroen ze schécken.
「Ufro schécken」
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';「…」
「…」
"Hmm ... Keng Äntwert. Vläicht dauert de Prozess laang?" - Ech hu geduecht, awer just am Fall, hunn ech op Grafana gekuckt a gesinn datt d'Diskbelaaschtung ganz séier wiisst.
"Geféierlech", hunn ech nach eng Kéier geduecht an direkt d'Ufro gestoppt.
Aktioun 2
Nodeems ech alles analyséiert hunn, hunn ech gemierkt datt de Volume vun den Donnéeën ze grouss war fir alles op eemol ze läschen.
Ech hu beschloss, e Skript ze schreiwen, deen ongeféier 1 Opzeechnungen läschen konnt an et lancéiert.
「Ech implementéieren de Skript」
"Elo wäert dëst definitiv funktionnéieren," hunn ech geduecht.
Aktioun 3
Déi zweet Method huet geschafft, awer huet sech als ganz Aarbechtsintensiv erausgestallt.
Alles suergfälteg ze maachen, ouni onnéideg Nerven, géif ongeféier zwou Wochen daueren. Awer trotzdem huet dësen Szenario net de Servicefuerderunge entsprécht, also hu mir missen ewech goen.
Also hei ass wat ech decidéiert hunn ze maachen:
Kopéiert den Dësch an ëmbenannt se
Vum virege Schrëtt hunn ech gemierkt datt d'Läsche vun esou enger grousser Quantitéit un Daten eng gläich grouss Laascht erstellt. Also hunn ech beschloss en neien Dësch vun Null ze kreéieren andeems Dir Insert benotzt an d'Donnéeën, déi ech geläscht hunn, réckelen.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Wann Dir den neien Dësch déi selwecht Gréisst wéi uewen maacht, soll d'Datenveraarbechtungsgeschwindegkeet och 1/7 méi séier ginn.
Nodeems ech den Dësch erstallt hunn an en ëmbenannt hunn, hunn ech ugefaang als Meeschtesch Dësch ze benotzen. Wann ech elo den Dësch mat 300 Millioune Rekorder falen, soll alles gutt sinn.
Ech hunn erausfonnt datt Truncate oder Drop manner Overhead erstellt wéi läschen an hunn decidéiert dës Method ze benotzen.
Leeschtung
「Ufro schécken」
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
「…」
「…」
"Em...?"
Aktioun 4
Ech hu geduecht datt déi viregt Iddi funktionnéiert, awer nodeems Dir d'Insert-Ufro geschéckt huet, sinn e puer Feeler opgetaucht. MySQL ass net verzeien.
Ech war schonn esou midd, datt ech ugefaang hunn ze denken, datt ech dat net méi wëlle maachen.
Ech souz a geduecht a realiséiert datt et vläicht ze vill Insert Ufroe fir eng Kéier waren ...
Ech hu probéiert eng Insert-Ufro ze schécken fir d'Quantitéit un Daten déi d'Datebank an 1 Dag veraarbecht soll. Ass geschitt!
Gutt, duerno wäerte mir weider Ufroe fir déiselwecht Quantitéit un Daten schécken. Well mir mussen e Mount Wäert vun Daten ewechhuelen, widderhuelen mir dës Operatioun ongeféier 35 Mol.
En Dësch ëmbenennen
Hei war d'Gléck op menger Säit: alles goung glat.
Alarm vermësst
Batch Veraarbechtungsgeschwindegkeet ass eropgaang.
Virdrun huet dëse Prozess ongeféier eng Stonn gedauert, elo dauert et ongeféier 2 Minutten.
Nodeems ech sécher war datt all d'Problemer geléist goufen, hunn ech 300 Millioune Rekorder erofgelooss. Ech geläscht den Dësch a gefillt remgebuer.
Resumé
Ech hu gemierkt datt d'Rotatiounsveraarbechtung an der Batchveraarbechtung fehlt, an dat war den Haaptproblem. Dës Zort vun architektonesche Feeler resultéiert an enger Verschwendung vun Zäit.
Denkt Dir un d'Laascht wärend der Datereplikatioun wann Dir records aus der Datebank läschen? Loosst eis MySQL net iwwerlaascht.
Déi, déi gutt an Datenbanken beherrscht sinn, wäerten definitiv net sou e Problem stoussen. Fir de Rescht vun Iech hoffen ech, datt dësen Artikel nëtzlech war.
Merci fir d'Liesen!
Mir wäerte ganz frou sinn wann Dir eis sot, ob Dir dësen Artikel gär hutt, ob d'Iwwersetzung kloer ass, ob et Iech nëtzlech war?
Source: will.com