тааныштыруу
Салам. Мен ningenMe, веб-иштеп чыгуучумун.
Аталышында айтылгандай, менин окуям MySQLде 300 миллион жазууну физикалык түрдө жок кылуу окуясы.
Мен бул нерсеге кызыгып калдым, ошондуктан мен эскертүү (инструкция) жасоону чечтим.
Башкы бет - эскертүү
Мен колдонгон жана тейлеген пакеттик серверде күн сайын бир жолу MySQLден акыркы айдагы маалыматтарды чогултуучу үзгүлтүксүз процесс бар.
Адатта бул процесс болжол менен 1 сааттын ичинде бүтөт, бирок бул жолу ал 7 же 8 саатка чейин бүтпөйт жана эскертүү токтогон жок...
Себебин табуу
Мен процессти кайра баштоого жана журналдарды кароого аракет кылдым, бирок туура эмес эч нерсе көргөн жокмун.
Суроо туура индекстелди. Бирок эмне туура эмес болуп жатканын ойлогондо, базанын көлөмү абдан чоң экенин түшүндүм.
hoge_table | 350'000'000 |350 миллион жазуу. Индекстөө туура иштеп жаткандай көрүндү, жөн гана өтө жай.
Айына талап кылынган маалыматтарды чогултуу болжол менен 12 000 000 жазууну түздү. Тандоо буйругу көпкө созулуп, транзакция көпкө чейин аткарылган жок окшойт.
DB
Бул күн сайын болжол менен 400 000 жазууга өскөн таблица. Маалыматтар базасы акыркы ай ичинде гана маалыматтарды чогултушу керек болчу, ошондуктан ал так ушундай көлөмдөгү маалыматтарды туруштук бере алат деп күтүлгөн, бирок, тилекке каршы, айлануу операциясы киргизилген эмес.
Бул маалымат базасы мен тарабынан иштелип чыккан эмес. Мен аны башка иштеп чыгуучудан алдым, андыктан ал дагы эле техникалык карыздай сезилди.
Күн сайын киргизилген маалыматтардын көлөмү чоңоюп, акыры чегине жеткен учур келди. Мындай чоң көлөмдөгү маалыматтар менен иштөөдө аларды бөлүү керек болот деп болжолдонууда, бирок, тилекке каршы, бул ишке ашкан жок.
Анан мен ишке кирдим.
Түзөтүү
Логиканы өзгөртүүгө караганда, маалымат базасынын көлөмүн кыскартуу жана аны иштетүү убактысын кыскартуу акылга сыярлык болгон.
Эгер сиз 300 миллион жазууну өчүрсөңүз, кырдаал кескин өзгөрүшү керек, ошондуктан мен ушундай кылууну чечтим ... Эх, бул сөзсүз түрдө иштейт деп ойлогом.
Аракет 1
Ишенимдүү резервдик көчүрмөнү даярдап, акыры сурамдарды жөнөтө баштадым.
「Сураныч жөнөтүү」
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';「…」
「…」
«Мм... Жооп жок. Балким процесс көпкө созулушу мүмкүн?» — деп ойлодум, бирок графанага карасам, дисктин жүгү абдан тез өсүп жатканын көрдүм.
"Коркунучтуу" деп кайра ойлонуп, суранычымды дароо токтотуп койдум.
Аракет 2
Баарын талдап чыккандан кийин, маалыматтардын көлөмү бир эле учурда баарын жок кылуу үчүн өтө чоң экенин түшүндүм.
Мен болжол менен 1 000 000 жазууну жок кыла турган сценарий жазууну чечтим жана аны ишке киргиздим.
「Мен сценарийди ишке ашырам」
"Эми бул сөзсүз түрдө ишке ашат" деп ойлодум.
Аракет 3
Экинчи ыкма иштеди, бирок абдан эмгекти талап кылуучу болуп чыкты.
Керексиз нервдер жок кылдаттык менен баарын жасоо эки жумадай убакытты талап кылат. Бирок ошентсе да бул сценарий сервистик талаптарга жооп бербегендиктен, андан алыстап кетүүгө туура келди.
Ошентип, мен эмне кылууну чечтим:
Таблицаны көчүрүп, анын атын өзгөртүңүз
Мурунку кадамдан мен мындай чоң көлөмдөгү маалыматтарды жок кылуу бирдей чоң жүктү жаратаарын түшүндүм. Ошентип, мен вставканы колдонуп нөлдөн баштап жаңы таблица түзүүнү чечтим жана ага жок кылам деп жаткан маалыматтарды жылдырууну чечтим.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Эгерде сиз жаңы таблицаны жогорудагыдай өлчөмдө жасасаңыз, маалыматтарды иштетүү ылдамдыгы да 1/7 тезирээк болушу керек.
Таблицаны түзүп, анын атын өзгөрткөндөн кийин мен аны башкы таблица катары колдоно баштадым. Эми мен 300 миллион жазуусу бар таблицаны түшүрсөм, баары жакшы болот.
Мен кыскартуу же түшүрүү жок кылуудан азыраак чыгым жаратаарын билип, бул ыкманы колдонууну чечтим.
аткаруу
「Сураныч жөнөтүү」
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
「…」
「…」
"Эм...?"
Аракет 4
Мен мурунку идея иштейт деп ойлогом, бирок кыстаруу өтүнүчүн жөнөткөндөн кийин бир нече каталар пайда болду. MySQL кечиримдүү эмес.
Мен ушунчалык чарчагандыктан, мындан ары муну кылгым келбейт деп ойлой баштадым.
Мен отуруп, ойлонуп, балким, бир жолу өтө көп суроо бар экенин түшүндүм...
Мен маалымат базасы 1 күндө иштете турган маалыматтардын көлөмүн киргизүү өтүнүчүн жөнөтүүгө аракет кылдым. Болду!
Ооба, андан кийин биз ошол эле көлөмдөгү маалымат үчүн суроо-талаптарды жөнөтүүнү улантабыз. Биз бир айлык маалыматтарды алып салуу керек болгондуктан, биз бул операцияны болжол менен 35 жолу кайталайбыз.
Таблицанын атын өзгөртүү
Бул жерде ийгилик мен тарапта болду: баары ойдогудай өттү.
Сигнал жоголду
Партияны иштетүү ылдамдыгы жогорулады.
Мурда бул процесс бир саатка жакын убакытты талап кылса, азыр 2 мүнөттөй убакыт талап кылынат.
Бардык көйгөйлөр чечилгенине ишенгенден кийин, мен 300 миллион жазууну таштадым. Мен үстөлдү өчүрүп, кайра жаралганымды сездим.
Жыйынтык
Партиялык иштетүүдө айлануу процесси жок экенин түшүндүм жана бул негизги көйгөй. Архитектуралык катанын бул түрү убакытты текке кетирүүгө алып келет.
Маалыматтар базасынан жазууларды өчүрүүдө маалыматтарды репликациялоо учурундагы жүктөм жөнүндө ойлонуп жатасызбы? Келгиле, MySQLди ашыкча жүктөбөйлү.
Маалыматтар базасын жакшы билгендер, албетте, мындай көйгөйгө туш болбойт. Калгандары үчүн, бул макала пайдалуу болду деп үмүттөнөм.
окуганыңыз үчүн рахмат!
Бул макала сизге жактыбы, котормосу түшүнүктүүбү, сизге пайдалуу болдубу, айтып берсеңиз абдан кубанычта болобуз?
Source: www.habr.com