Pambuka
Halo. Aku ningenMe, pangembang web.
Minangka judhul kasebut, critaku yaiku crita mbusak 300 yuta rekaman ing MySQL kanthi fisik.
Aku dadi kasengsem ing iki, mula aku mutusake kanggo nggawe pangeling (instruksi).
Ngarep - Tandha
Server batch sing digunakake lan njaga nduweni proses reguler sing ngumpulake data sasi pungkasan saka MySQL sapisan dina.
Biasane proses iki rampung ing sekitar 1 jam, nanging wektu iki ora rampung kanggo 7 utawa 8 jam, lan tandha ora mandheg pop munggah ...
Nggoleki alesan
Aku nyoba kanggo miwiti maneh proses lan katon ing log, nanging aku ora weruh apa-apa salah.
Pitakon kasebut diindeks kanthi bener. Nanging nalika aku mikir babagan apa sing salah, aku ngerti yen ukuran database cukup gedhe.
hoge_table | 350'000'000 |350 yuta cathetan. Pengindeksan katon mlaku kanthi bener, mung alon banget.
Pangumpulan data sing dibutuhake saben sasi kira-kira 12 cathetan. Iku katon kaya printah pilih njupuk wektu dawa lan transaksi ora kaleksanan kanggo dangu.
DB
Iki minangka tabel sing tuwuh kira-kira 400 entri saben dina. Basis data mesthine ngumpulake data mung kanggo sasi pungkasan, mula samesthine bakal tahan persis jumlah data kasebut, nanging sayangé, operasi rotasi ora kalebu.
Database iki ora dikembangake dening aku. Aku njupuk liwat saka pangembang liyane, supaya isih felt kaya utang technical.
Ana titik nalika volume data sing dilebokake saben dina dadi gedhe lan pungkasane tekan watese. Dianggep yen nalika nggarap data sing akeh banget, kudu dipisahake, nanging sayangé, iki ora rampung.
Banjur aku tumindak.
Koreksi
Iku luwih rasional kanggo nyuda ukuran database dhewe lan nyuda wektu kanggo proses tinimbang ngganti logika dhewe.
Kahanan kudu owah sacara signifikan yen sampeyan mbusak 300 yuta rekaman, mula aku mutusake kanggo nglakoni ... Eh, aku panginten iki mesthi bakal bisa.
Tindakan 1
Sawise nyiapake cadangan sing dipercaya, pungkasane aku wiwit ngirim panjaluk.
「Kirimi panjalukan」
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"…"
"…"
“Hmm... Ora ana wangsulan. Mungkin prosese butuh wektu suwe?” - Aku panginten, nanging mung ing kasus, Aku katon ing grafana lan weruh sing mbukak disk iki akeh banget cepet.
"Mbebayani," pikirku maneh lan langsung mandhegake panjaluk kasebut.
Tindakan 2
Sawise nganalisa kabeh, aku nyadari yen volume data gedhe banget kanggo mbusak kabeh sekaligus.
Aku mutusake kanggo nulis skrip sing bisa mbusak udakara 1 rekaman lan diluncurake.
「Aku ngetrapake skrip」
"Saiki iki mesthi bakal bisa," pikirku.
Tindakan 3
Cara sing kapindho makarya, nanging dadi banget tenaga kerja.
Kanggo nindakake kabeh kanthi ati-ati, tanpa saraf sing ora perlu, bakal njupuk kira-kira rong minggu. Nanging, skenario iki ora nyukupi syarat layanan, mula kita kudu pindhah saka iku.
Mangkene apa sing dakkarepake:
Nyalin tabel lan ganti jeneng
Saka langkah sadurunge, aku nyadari yen mbusak data sing akeh banget nggawe beban sing padha. Dadi aku mutusaké kanggo nggawe tabel anyar saka ngeruk nggunakake insert lan mindhah data aku arep mbusak menyang.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Yen sampeyan nggawe tabel anyar ukuran padha ing ndhuwur, kacepetan Processing data uga kudu dadi 1/7 luwih cepet.
Sawise nggawe tabel lan ngganti jeneng, aku miwiti nggunakake minangka tabel master. Saiki yen aku nyelehake meja kanthi 300 yuta cathetan kabeh kudu apik.
Aku nemokake manawa truncate utawa nyelehake nggawe overhead kurang saka mbusak lan mutusake nggunakake metode iki.
Kinerja
「Kirimi panjalukan」
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"…"
"…"
"Em...?"
Tindakan 4
Aku panginten idea sadurungé bakal bisa, nanging sawise ngirim panjalukan insert, sawetara kasalahan katon. MySQL ora ngapura.
Aku wis kesel banget aku wiwit mikir yen aku ora pengin nindakake iki maneh.
Aku lungguh lan mikir lan temen maujud sing mungkin ana akeh banget pitakonan sisipan kanggo siji wektu...
Aku nyoba ngirim panjalukan sisipan kanggo jumlah data sing kudu diproses ing database sajrone 1 dina. Kedadeyan!
Inggih, sawise iku, kita terus ngirim panjalukan kanggo jumlah data sing padha. Amarga kita kudu mbusak data sasi, kita mbaleni operasi iki kira-kira 35 kaping.
Ngganti jeneng tabel
Ing kene luck ana ing sisihku: kabeh lancar.
Lansiran ilang
kacepetan Processing kumpulan wis tambah.
Sadurunge proses iki njupuk watara jam, saiki njupuk bab 2 menit.
Sawise aku yakin yen kabeh masalah wis ditanggulangi, aku ngeculake 300 yuta cathetan. Aku mbusak meja lan felt reborn.
Ringkesan
Aku temen maujud sing Processing rotasi ilang ing Processing kumpulan, lan sing masalah utama. Kesalahan arsitektur kaya iki nyebabake mbuwang wektu.
Apa sampeyan mikir babagan beban sajrone replikasi data nalika mbusak cathetan saka database? Aja kakehan MySQL.
Wong-wong sing wis ngerti babagan database mesthi ora bakal nemoni masalah kasebut. Kanggo sampeyan liyane, muga-muga artikel iki migunani.
Matur nuwun kanggo maca!
Kita bakal bungah banget yen sampeyan ngandhani apa sampeyan seneng karo artikel iki, apa terjemahan kasebut jelas, apa migunani kanggo sampeyan?
Source: www.habr.com