Историята на физическото изтриване на 300 милиона записа в MySQL

въведение

Здравейте. Аз съм ningenMe, уеб разработчик.

Както се казва в заглавието, моята история е историята на физическото изтриване на 300 милиона записа в MySQL.

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

Начало - Сигнал

Пакетният сървър, който използвам и поддържам, има редовен процес, който събира данните от последния месец от 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.

Тези, които са добре запознати с базите данни, определено няма да се сблъскат с такъв проблем. За останалите се надявам тази статия да е била полезна.

Благодаря за четенето!

Ще се радваме много, ако ни кажете дали ви е харесала тази статия, дали преводът е ясен, дали ви е била полезна?

Източник: www.habr.com