Увод
Здраво. Ја сам нингенМе, веб програмер.
Као што наслов каже, моја прича је прича о физичком брисању 300 милиона записа у МиСКЛ-у.
Заинтересовао сам се за ово, па сам одлучио да направим подсетник (упутство).
Почетна - Упозорење
Групни сервер који користим и одржавам има редован процес који прикупља податке за прошли месец из МиСКЛ-а једном дневно.
Обично се овај процес заврши у року од око 1 сат, али овај пут се није завршио 7 или 8 сати, а упозорење није престало да искаче...
Проналажење разлога
Покушао сам да поново покренем процес и погледам евиденције, али нисам видео ништа лоше.
Упит је исправно индексиран. Али када сам размислио шта није у реду, схватио сам да је величина базе података прилично велика.
hoge_table | 350'000'000 |350 милиона записа. Чинило се да индексирање ради исправно, само веома споро.
Потребно прикупљање података месечно је било приближно 12 записа. Изгледа да је команда за одабир трајала дуго и да трансакција није била извршена дуго времена.
DB
То је у суштини табела која расте за око 400 уноса сваког дана. База је требало да прикупља податке само за последњих месец дана, па се очекивало да ће издржати управо оволику количину података, али, нажалост, операција ротирања није укључена.
Ову базу података нисам развио ја. Преузео сам га од другог програмера, тако да се и даље осећао као технички дуг.
Дошао је тренутак када је обим података који се убацују дневно постао велики и коначно достигао свој лимит. Претпоставља се да би при раду са тако великом количином података било неопходно да их раздвојимо, али то, нажалост, није учињено.
А онда сам ступио у акцију.
Исправка
Рационалније је било смањити величину саме базе података и смањити време за њену обраду него променити саму логику.
Ситуација би требало значајно да се промени ако избришете 300 милиона записа, па сам одлучио да то урадим... Ех, мислио сам да ће ово сигурно успети.
Акција 1
Пошто сам припремио поуздану резервну копију, коначно сам почео да шаљем захтеве.
「Слање захтева」
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';「…」
「…」
„Хм... Без одговора. Можда процес траје дуго?” — Мислио сам, али за сваки случај сам погледао графану и видео да оптерећење диска расте веома брзо.
„Опасно“, помислио сам поново и одмах прекинуо захтев.
Акција 2
Након што сам све анализирао, схватио сам да је обим података превелик да бих све избрисао одједном.
Одлучио сам да напишем скрипту која би могла да обрише око 1 записа и покренуо сам је.
「Ја имплементирам сценарио」
„Сада ће ово сигурно успети“, помислио сам.
Акција 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
Мислио сам да ће претходна идеја радити, али након слања захтева за уметање појавило се више грешака. МиСКЛ не опрашта.
Већ сам био толико уморан да сам почео да мислим да то више не желим да радим.
Седео сам и размишљао и схватио да је можда било превише упита за уметање једном...
Покушао сам да пошаљем захтев за уметање количине података коју база података треба да обради за 1 дан. Десило!
Па, после тога настављамо да шаљемо захтеве за исту количину података. Пошто морамо да уклонимо податке за месец дана, ову операцију понављамо отприлике 35 пута.
Преименовање табеле
Овде је срећа била на мојој страни: све је прошло глатко.
Упозорење је нестало
Брзина групне обраде је повећана.
Раније је овај процес трајао око сат времена, сада траје око 2 минута.
Након што сам био сигуран да су сви проблеми решени, испустио сам 300 милиона записа. Избрисао сам табелу и осећао се препорођено.
Резиме
Схватио сам да у групној обради недостаје обрада ротације и то је био главни проблем. Оваква архитектонска грешка доводи до губљења времена.
Да ли размишљате о оптерећењу током репликације података приликом брисања записа из базе података? Хајде да не преоптерећујемо МиСКЛ.
Они који су добро упућени у базе података сигурно неће наићи на такав проблем. За вас остале, надам се да је овај чланак био користан.
Хвала за читање!
Биће нам веома драго ако нам кажете да ли вам се допао овај чланак, да ли је превод јасан, да ли вам је био користан?
Извор: ввв.хабр.цом