Pîrozbahiyê
Slav. Ez ningenMe, pêşdebirê malperê me.
Wekî ku sernav dibêje, çîroka min çîroka jêbirina fîzîkî ya 300 mîlyon tomar di MySQL de ye.
Ez bi vê yekê re eleqedar bûm, ji ber vê yekê min biryar da ku bîranînek (telîmatan) bikim.
Mal - Alert
Pêşkêşkara hevîrê ku ez bikar tînim û diparêzim pêvajoyek birêkûpêk heye ku rojane carekê daneyên meha paşîn ji MySQL berhev dike.
Bi gelemperî ev pêvajo di nav 1 demjimêran de qediya, lê vê carê 7 an 8 demjimêran temam nebû, û hişyarî ji xuyangê rawesta ...
Li sedemekê digere
Min hewl da ku pêvajoyê ji nû ve dest pê bikim û li têketin binêrim, lê min tiştek xelet nedît.
Pirs bi rast hat îndeks kirin. Lê gava ku ez li ser çi xelet difikirîm, min fêm kir ku mezinahiya databasê pir mezin e.
hoge_table | 350'000'000 |350 milyon tomar. Indekskirin dixuye ku rast dixebite, tenê pir hêdî.
Di mehê de berhevkirina daneyên pêwîst bi qasî 12 tomar bû. Wusa dixuye ku emrê hilbijartî demek dirêj girt û danûstendin ji bo demek dirêj nehat bicîh kirin.
DB
Ew bi bingehîn tabloyek e ku her roj bi qasî 400 navnîşan mezin dibe. Diviyabû ku databas tenê ji bo meha borî daneyan berhev bike, ji ber vê yekê, çaverê bû ku ew ê tam li hember vê hêjeya daneyê bisekine, lê, mixabin, operasyona zivirandinê tê de nebû.
Ev databas ji aliyê min ve nehatiye pêşxistin. Min ew ji pêşdebirek din girt, ji ber vê yekê ew hîn jî wekî deynê teknîkî hîs kir.
Demek hat ku qebareya daneyên ku rojane dihatin danîn mezin bû û di dawiyê de gihîşt sînorê xwe. Tê texmîn kirin ku dema ku bi hejmareke mezin a daneyan re bixebite, pêdivî ye ku wan ji hev veqetînin, lê mixabin ev nehat kirin.
Û paşê ez ketim tevgerê.
Serrastkirî
Kêmkirina mezinahiya databasê bixwe û kêmkirina dema pêvajokirina wê ji guhertina mantiqê bêtir maqûl bû.
Ger hûn 300 mîlyon tomar ji holê rakin divê rewş pir girîng were guheztin, ji ber vê yekê min biryar da ku wiya bikim... Eh, min digot qey ev ê bê guman bixebite.
Çalakî 1
Piştgiriyek pêbawer amade kir, min di dawiyê de dest bi şandina daxwazan kir.
''Daxwazek şandin''
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"…"
"…"
“Hmm... Bê bersiv. Dibe ku pêvajo demek dirêj bigire?” - Ez fikirîm, lê her gav, min li grafana nêrî û dît ku barkirina dîskê pir zû mezin dibe.
"Metirsîdar," min dîsa fikirî û yekser daxwaz rawestand.
Çalakî 2
Piştî analîzkirina her tiştî, min fêm kir ku qebareya daneyê pir mezin bû ku meriv her tiştî bi yekcar jê bibe.
Min biryar da ku ez skrîptek binivîsim ku karibe bi qasî 1 tomar jê bibe û ew dest pê kir.
'Ez senaryoyê bi cih dikim'
"Niha ev ê bê guman bixebite," min fikirîn.
Çalakî 3
Rêbaza duyemîn xebitî, lê derket holê ku pir kedkar e.
Ji bo kirina her tiştî bi baldarî, bêyî nervên nehewce, dê du hefte bidome. Lê dîsa jî, ev senaryo ne li gorî hewcedariyên karûbarê bû, ji ber vê yekê em neçar man ku jê dûr bikevin.
Ji ber vê yekê tiştê ku min biryar da ku bikim ev e:
Tabloyê kopî bikin û navê wê biguherînin
Ji pêngava paşîn, min fêm kir ku jêbirina hejmareke wusa mezin a daneyan barek wekhev mezin diafirîne. Ji ber vê yekê min biryar da ku bi karanîna têxê tabloyek nû ji nû ve biafirînim û daneyên ku ez ê jêbikim biguhezînim nav wê.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Ger hûn tabloya nû bi heman mezinahiya jorîn çêbikin, divê leza hilberandina daneyê jî 1/7 zûtir bibe.
Piştî çêkirina tabloyê û guherandina navê wê, min dest bi karanîna wê wekî tabloya sereke kir. Niha ger ez tabloya bi 300 mîlyon qeydan davêjim divê her tişt baş be.
Min fêhm kir ku qutkirin an avêtin ji jêbirinê kêmtir serêş diafirîne û biryar da ku vê rêbazê bikar bînim.
Têrbûn
''Daxwazek şandin''
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"…"
"…"
"Em...?"
Çalakî 4
Min difikirî ku ramana berê dê bixebite, lê piştî şandina daxwaza têxê, gelek xeletî xuya bûn. MySQL efû nake.
Ez jixwe ew qas westiyayî bûm ku min dest pê kir ku ez bifikirim ku ez êdî naxwazim vî karî bikim.
Ez rûniştim û fikirîm û min fêm kir ku belkî ji bo yek carê gelek pirsnameyên têxê hene ...
Min hewl da ku ji bo mîqdara daneya ku databas divê di nav 1 rojan de pêvajoyê bike daxwazek têxê bişînim. Bûye!
Welê, piştî wê em şandina daxwazan ji bo heman hejmarê daneyan berdewam dikin. Ji ber ku pêdivî ye ku em daneyên mehekê jê bikin, em vê operasyonê bi qasî 35 caran dubare dikin.
Guherîna navekî tabloyê
Li vir şens li aliyê min bû: her tişt bi hêsanî derbas bû.
Hişyar winda bû
Leza hilberandina hevîrê zêde bûye.
Berê ev pêvajo bi qasî saetekê dikişand, niha bi qasî 2 deqîqeyan digire.
Piştî ku ez piştrast bûm ku hemî pirsgirêk çareser bûne, min 300 mîlyon tomar avêtin. Min tablo jê kir û min xwe ji nû ve jidayikbûnê hîs kir.
Berhevkirinî
Min fêm kir ku pêvajoyek zivirandinê di pêvajoyek hevîrê de winda bû, û ew pirsgirêka sereke bû. Ev celeb xeletiya mîmarî dibe sedema windakirina demê.
Dema ku tomarên ji databasê jêbirin hûn li barkirina di dema dubarekirina daneyê de difikirin? Ka em MySQL zêde bar nekin.
Yên ku di databasan de baş haydar in bê guman dê bi pirsgirêkek wusa re rû bi rû nemînin. Ji bo we yên din, ez hêvî dikim ku ev gotara kêrhatî bû.
Spas ji bo xwendinê!
Em ê pir kêfxweş bibin ku hûn ji me re bibêjin ka we ji vê gotarê hez kir, ka werger zelal e, gelo ew ji we re bikêr bû?
Source: www.habr.com