Приказната за физичко бришење на 300 милиони записи во MySQL

Вовед

Здраво. Јас сум ningenMe, веб-развивач.

Како што вели насловот, мојата приказна е приказна за физички бришење на 300 милиони записи во MySQL.

Се заинтересирав за ова, па решив да направам потсетник (инструкции).

Дома - Алармирање

Серискиот сервер што го користам и одржувам има редовен процес кој ги собира податоците од минатиот месец од MySQL еднаш дневно.

Обично овој процес се завршува во рок од околу 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

Мислев дека претходната идеја ќе функционира, но по испраќањето на барањето за вметнување, се појавија повеќе грешки. MySQL не простува.

Веќе бев толку уморен што почнав да мислам дека не сакам повеќе да го правам ова.

Седнав и размислував и сфатив дека можеби имало премногу прашања за вметнување еднаш...
Се обидов да испратам барање за вметнување за количината на податоци што базата треба да ги обработи за 1 ден. Се случи!

Па, после тоа продолжуваме да испраќаме барања за иста количина на податоци. Бидејќи треба да ги отстраниме податоците во вредност од еден месец, ја повторуваме оваа операција приближно 35 пати.

Преименување на маса

Тука среќата беше на моја страна: сè помина без проблеми.

Алармот исчезна

Брзината на сериска обработка е зголемена.

Претходно овој процес траеше околу еден час, сега трае околу 2 минути.

Откако се уверив дека сите проблеми се решени, испуштив 300 милиони плочи. Ја избришав табелата и се почувствував препородено.

Резиме

Сфатив дека ротационата обработка недостасува во сериската обработка и тоа беше главниот проблем. Овој тип на архитектонска грешка резултира со губење време.

Дали размислувате за оптоварувањето при репликација на податоците при бришење записи од базата на податоци? Да не преоптоваруваме MySQL.

Оние кои се добро упатени во базите на податоци дефинитивно нема да наидат на таков проблем. За останатите, се надевам дека оваа статија беше корисна.

Ви благодариме за читањето!

Ќе ни биде многу драго ако ни кажете дали ви се допадна овој напис, дали преводот е јасен, дали ви беше корисен?

Извор: www.habr.com