Ievads
Sveiki. Es esmu ningenMe, tÄ«mekļa izstrÄdÄtÄjs.
KÄ saka virsraksts, mans stÄsts ir stÄsts par 300 miljonu ierakstu fizisku dzÄÅ”anu pakalpojumÄ MySQL.
Mani tas sÄka interesÄt, tÄpÄc nolÄmu uztaisÄ«t atgÄdinÄjumu (instrukciju).
SÄkums ā brÄ«dinÄjums
PakeÅ”serverim, kuru izmantoju un uzturu, ir regulÄrs process, kas reizi dienÄ apkopo pÄdÄjÄ mÄneÅ”a datus no MySQL.
Parasti Å”is process tiek pabeigts aptuveni 1 stundas laikÄ, taÄu Å”oreiz tas netika pabeigts 7 vai 8 stundas, un brÄ«dinÄjums nepÄrstÄja parÄdÄ«ties...
MeklÄ iemeslu
Es mÄÄ£inÄju atsÄkt procesu un apskatÄ«t žurnÄlus, bet es neredzÄju neko sliktu.
VaicÄjums tika indeksÄts pareizi. Bet, domÄjot par to, kas notiek nepareizi, es sapratu, ka datu bÄzes apjoms ir diezgan liels.
hoge_table | 350'000'000 |350 miljoni ierakstu. Å Ä·ita, ka indeksÄÅ”ana darbojas pareizi, tikai ļoti lÄni.
NepiecieÅ”amÄ datu vÄkÅ”ana mÄnesÄ« bija aptuveni 12 000 000 ierakstu. IzskatÄs, ka atlases komanda aizÅÄma ilgu laiku un transakcija netika izpildÄ«ta ilgu laiku.
DB
BÅ«tÄ«bÄ tÄ ir tabula, kas katru dienu pieaug par aptuveni 400 000 ierakstu. Datu bÄzei bija paredzÄts apkopot datus tikai par pÄdÄjo mÄnesi, tÄpÄc bija paredzÄts, ka tÄ izturÄs tieÅ”i Å”Ädu datu apjomu, taÄu diemžÄl rotÄcijas darbÄ«ba netika iekļauta.
Å o datu bÄzi neesmu izstrÄdÄjis es. Es to pÄrÅÄmu no cita izstrÄdÄtÄja, tÄpÄc tas joprojÄm likÄs kÄ tehniskais parÄds.
PienÄca brÄ«dis, kad katru dienu ievietoto datu apjoms kļuva liels un beidzot sasniedza savu robežu. Tiek pieļauts, ka, strÄdÄjot ar tik lielu datu apjomu, bÅ«tu nepiecieÅ”ams tos atdalÄ«t, taÄu tas diemžÄl netika izdarÄ«ts.
Un tad es sÄku darboties.
Korekcija
Bija racionÄlÄk samazinÄt paÅ”as datu bÄzes lielumu un samazinÄt tÄs apstrÄdes laiku, nevis mainÄ«t paÅ”u loÄ£iku.
SituÄcijai vajadzÄtu bÅ«tiski mainÄ«ties, ja izdzÄsÄ«siet 300 miljonus ierakstu, tÄpÄc es nolÄmu to darÄ«t... Eh, es domÄju, ka tas noteikti darbosies.
1. darbība
Sagatavojis uzticamu dublÄjumu, beidzot sÄku sÅ«tÄ«t pieprasÄ«jumus.
''Pieprasījuma sūtīŔana''
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"ā¦"
"ā¦"
āHmm... Nav atbildes. VarbÅ«t process aizÅem ilgu laiku?ā ā nodomÄju, bet katram gadÄ«jumam paskatÄ«jos uz grafÄnu un ieraudzÄ«ju, ka diska noslodze ļoti strauji aug.
"BÄ«stami," es vÄlreiz nodomÄju un nekavÄjoties pÄrtraucu pieprasÄ«jumu.
2. darbība
IzanalizÄjot visu, es sapratu, ka datu apjoms ir pÄrÄk liels, lai izdzÄstu visu uzreiz.
Es nolÄmu uzrakstÄ«t skriptu, kas varÄtu dzÄst apmÄram 1 000 000 ierakstu, un palaidu to.
"Es Ä«stenoju skriptu"
"Tagad tas noteikti darbosies," es domÄju.
3. darbība
OtrÄ metode darbojÄs, taÄu izrÄdÄ«jÄs ļoti darbietilpÄ«ga.
Lai visu izdarÄ«tu uzmanÄ«gi, bez liekiem nerviem, bÅ«tu vajadzÄ«gas kÄdas divas nedÄļas. Bet tomÄr Å”is scenÄrijs neatbilda apkalpoÅ”anas prasÄ«bÄm, tÄpÄc nÄcÄs no tÄ atteikties.
LÅ«k, ko es nolÄmu darÄ«t:
KopÄjiet tabulu un pÄrdÄvÄjiet to
No iepriekÅ”ÄjÄ soļa sapratu, ka tik liela datu apjoma dzÄÅ”ana rada tikpat lielu slodzi. TÄpÄc es nolÄmu izveidot jaunu tabulu no jauna, izmantojot ievietoÅ”anu, un pÄrvietot tajÄ datus, ko gatavojos dzÄst.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Ja jauno tabulu veidojat tÄda paÅ”a izmÄra kÄ iepriekÅ”, arÄ« datu apstrÄdes Ätrumam vajadzÄtu kļūt par 1/7 ÄtrÄkam.
PÄc tabulas izveidoÅ”anas un pÄrdÄvÄÅ”anas es sÄku to izmantot kÄ galveno tabulu. Tagad, ja es nomestu tabulu ar 300 miljoniem ierakstu, visam vajadzÄtu bÅ«t kÄrtÄ«bÄ.
Es uzzinÄju, ka saÄ«sinÄÅ”ana vai nomeÅ”ana rada mazÄk papildu izdevumu nekÄ dzÄÅ”ana, un nolÄmu izmantot Å”o metodi.
Piepildījums
''Pieprasījuma sūtīŔana''
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"ā¦"
"ā¦"
"Em...?"
4. darbība
Es domÄju, ka iepriekÅ”ÄjÄ ideja darbosies, bet pÄc ievietoÅ”anas pieprasÄ«juma nosÅ«tÄ«Å”anas parÄdÄ«jÄs vairÄkas kļūdas. MySQL nav piedodoÅ”s.
Es jau biju tik nogurusi, ka sÄku domÄt, ka vairs negribu to darÄ«t.
SÄdÄju un domÄju un sapratu, ka varbÅ«t vienu reizi bija pÄrÄk daudz ieliktÅu vaicÄjumu...
Es mÄÄ£inÄju nosÅ«tÄ«t ievietoÅ”anas pieprasÄ«jumu par datu apjomu, kas datu bÄzei jÄapstrÄdÄ 1 dienas laikÄ. Notika!
Nu, pÄc tam mÄs turpinÄm sÅ«tÄ«t pieprasÄ«jumus par tÄdu paÅ”u datu apjomu. TÄ kÄ mums ir jÄnoÅem mÄneÅ”a dati, mÄs atkÄrtojam Å”o darbÄ«bu aptuveni 35 reizes.
Tabulas pÄrdÄvÄÅ”ana
Å eit veiksme bija manÄ pusÄ: viss noritÄja gludi.
BrÄ«dinÄjums pazudis
PakeÅ”u apstrÄdes Ätrums ir palielinÄjies.
IepriekÅ” Å”is process ilga apmÄram stundu, tagad tas aizÅem apmÄram 2 minÅ«tes.
Kad biju pÄrliecinÄts, ka visas problÄmas ir atrisinÄtas, es samazinÄju 300 miljonus ierakstu. IzdzÄsu tabulu un jutos atdzimusi.
Kopsavilkums
Es sapratu, ka pakeÅ”u apstrÄdÄ trÅ«kst rotÄcijas apstrÄdes, un tÄ bija galvenÄ problÄma. Å Äda veida arhitektÅ«ras kļūda noved pie laika izŔķieÅ”anas.
Vai, dzÄÅ”ot ierakstus no datu bÄzes, domÄjat par slodzi datu replikÄcijas laikÄ? NepÄrslogosim MySQL.
Tie, kas labi pÄrzina datubÄzes, noteikti nesaskarsies ar Å”Ädu problÄmu. PÄrÄjiem, es ceru, ka Å”is raksts bija noderÄ«gs.
Paldies, ka izlasÄ«jÄt!
MÄs bÅ«sim ļoti priecÄ«gi, ja pastÄstÄ«sit, vai jums patika Å”is raksts, vai tulkojums ir skaidrs, vai tas jums bija noderÄ«gs?
Avots: www.habr.com