{"id":95518,"date":"2020-09-30T19:42:27","date_gmt":"2020-09-30T17:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql"},"modified":"2020-09-30T19:42:27","modified_gmt":"2020-09-30T17:42:27","slug":"istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","title":{"rendered":"Die Geschichte der physischen L\u00f6schung von 300 Millionen Datens\u00e4tzen in MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h2>\n

\nHallo. Ich bin ningenMe, ein Webentwickler.<\/p>\n

Wie im Titel erw\u00e4hnt, ist meine Geschichte die eines physischen L\u00f6schens von 300 Millionen Datens\u00e4tzen in MySQL.<\/p>\n

Ich war daran interessiert, also beschloss ich, eine Zusammenfassung (Anleitung) zu erstellen.<\/p>\n

Beginn \u2014 Alarm<\/h2>\n

\nIn dem Batch Server<\/a>, den ich verwende und betreue, gibt es einen regelm\u00e4\u00dfigen Prozess, der einmal t\u00e4glich die Daten des letzten Monats aus MySQL abruft. <\/p>\n

Normalerweise dauert dieser Prozess etwa 1 Stunde, aber diesmal dauerte er 7 oder 8 Stunden, und der Alarm h\u00f6rte nicht auf zu erscheinen... <\/a><\/noindex><\/p>\n

Ursachenanalyse<\/h2>\n

\nIch habe versucht, den Prozess neu zu starten und die Protokolle zu \u00fcberpr\u00fcfen, aber ich konnte nichts Ungew\u00f6hnliches feststellen.
\nDie Abfrage war richtig indiziert. Aber als ich dar\u00fcber nachdachte, was schiefgeht, wurde mir klar, dass die Datenbank recht gro\u00df ist. <\/p>\n

hoge_table | 350'000'000 |<\/code><\/pre>\n
\n350 Millionen Datens\u00e4tze. Es scheint, dass die Indizierung richtig funktionierte, nur sehr langsam.<\/p>\n
Die ben\u00f6tigte Datensammlung f\u00fcr den Monat betrug etwa 12.000.000 Datens\u00e4tze. Es sieht so aus, als ob der SELECT-Befehl viel Zeit in Anspruch nahm und die Transaktion lange Zeit nicht ausgef\u00fchrt wurde. <\/p>\n
DB<\/h2>\n
\nIm Grunde genommen handelt es sich um eine Tabelle, die jeden Tag um etwa 400.000 Eintr\u00e4ge w\u00e4chst. Die Datenbank sollte nur die Daten des letzten Monats sammeln, entsprechend wurde angenommen, dass sie mit diesem Datenvolumen umgehen kann, aber leider wurde die Rotate-Operation nicht aktiviert.<\/p>\n
Diese Datenbank wurde nicht von mir entwickelt. Ich habe sie von einem anderen Entwickler \u00fcbernommen, weshalb das Gef\u00fchl bleibt, dass es sich um technischen Schulden handelt. <\/p>\n
Der Zeitpunkt kam, als das Volumen der t\u00e4glich eingef\u00fcgten Daten gro\u00df wurde und schlie\u00dflich einen Grenzwert erreichte. Man w\u00fcrde erwarten, dass man bei so gro\u00dfen Datenmengen diese trennen sollte, aber leider wurde das nicht gemacht.<\/p>\n
Und hier kam ich ins Spiel.<\/p>\n
Korrektur<\/h2>\n
\nEs w\u00e4re sinnvoller gewesen, die Datenbank selbst zu verkleinern und die Verarbeitungszeit zu verk\u00fcrzen als die Logik zu \u00e4ndern.<\/p>\n
Die Situation sollte sich erheblich ver\u00e4ndern, wenn 300 Millionen Eintr\u00e4ge gel\u00f6scht werden, also entschied ich mich daf\u00fcr\u2026 Ach, ich dachte, das w\u00fcrde auf jeden Fall funktionieren.<\/p>\n
Aktion 1<\/h2>\n
\nNachdem ich ein zuverl\u00e4ssiges Backup erstellt hatte, begann ich schlie\u00dflich, Anfragen zu senden.<\/p>\n
\u300cAnfrage senden\u300d<\/p>\n
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u300c…\u300d<\/p>\n
\u300c…\u300d<\/p>\n
\u201eHmm... Keine Antwort. Vielleicht dauert der Prozess zu lange?\u201c \u2014 dachte ich, aber sicherheitshalber schaute ich in Grafana und sah, dass die Festplattenauslastung sehr schnell anstieg. 
\n\u201eDas ist riskant\u201c \u2014 dachte ich erneut und stoppte sofort die Anfrage.<\/p>\n
Aktion 2<\/h2>\n
\nNachdem ich alles analysiert hatte, stellte ich fest, dass das Datenvolumen zu gro\u00df war, um es auf einmal zu l\u00f6schen.<\/p>\n
Ich entschied mich, ein Skript zu schreiben, das etwa 1.000.000 Eintr\u00e4ge l\u00f6schen kann, und startete es.<\/p>\n
\u300cSkript implementieren\u300d<\/p>\n
\u201eJetzt wird es bestimmt funktionieren\u201c, \u2014 dachte ich.<\/p>\n
Aktion 3<\/h2>\n
\nDie zweite Methode funktionierte, war aber sehr arbeitsintensiv.
\nUm alles ordentlich und ohne unn\u00f6tigen Stress zu erledigen, br\u00e4uchte es etwa zwei Wochen. Aber dennoch entsprach dieses Szenario nicht den Serviceanforderungen, weshalb ich davon Abstand nehmen musste.<\/p>\n
Also, das habe ich beschlossen:<\/p>\n
Tabelle kopieren und umbenennen<\/h3>\n
\nAus dem vorherigen Schritt habe ich verstanden, dass das L\u00f6schen eines so gro\u00dfen Datenvolumens auch eine gro\u00dfe Last erzeugt. Daher entschied ich mich, eine neue Tabelle von Grund auf mit INSERT zu erstellen und die Daten, die ich l\u00f6schen wollte, dorthin zu verschieben.<\/p>\n
| hoge_table     | 350'000'000|\n| tmp_hoge_table |  50'000'000|<\/code><\/pre>\n
\nWenn ich eine neue Tabelle in der gleichen Gr\u00f6\u00dfe wie oben angegeben erstelle, sollte die Datenverarbeitungsrate auch um 1\/7 schneller sein.<\/p>\n
Nachdem ich die Tabelle erstellt und umbenannt hatte, begann ich, sie als Mastertabelle zu nutzen. Jetzt, wenn ich die Tabelle mit 300 Millionen Datens\u00e4tzen l\u00f6sche, sollte alles in Ordnung sein.
\nIch habe herausgefunden, dass truncate oder drop weniger Last erzeugt als delete und beschloss, diesen Ansatz zu verwenden.<\/p>\n
Ausf\u00fchrung<\/h3>\n
\n\u300cAnfrage senden\u300d<\/p>\n
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u300c…\u300d
\n\u300c…\u300d
\n\u300c\u044d\u043c…\uff1f\u300d<\/p>\n
Aktion 4<\/h2>\n
\nIch dachte, die vorherige Idee w\u00fcrde funktionieren, aber nach dem Senden der Insert-Anfrage trat ein mehrfacher Fehler auf. MySQL ist gnadenlos.<\/p>\n
Ich bin so m\u00fcde, dass ich anfing zu denken, dass ich keine Lust mehr darauf habe.<\/p>\n
Ich habe nachgedacht und erkannt, dass es vielleicht bei einmal zu viele Insert-Anfragen waren\u2026
\nIch habe versucht, eine Insert-Anfrage mit der Datenmenge zu senden, die die Datenbank an einem Tag verarbeiten sollte. Es hat geklappt!<\/p>\n
Nach diesem Vorgang senden wir weiterhin Anfragen mit dem gleichen Datenvolumen. Da wir ein Monatsdatenvolumen entfernen m\u00fcssen, wiederholen wir diesen Vorgang etwa 35 Mal.<\/p>\n
Umbenennung der Tabelle <\/h3>\n
\nHier hatte ich Gl\u00fcck: alles lief glatt.<\/p>\n
Alert verschwunden<\/h3>\n
\nDie Verarbeitungszeit hat sich verk\u00fcrzt.<\/p>\n
Fr\u00fcher dauerte dieser Prozess etwa eine Stunde, jetzt dauert es ungef\u00e4hr 2 Minuten. <\/p>\n
Nachdem ich sichergestellt hatte, dass alle Probleme gel\u00f6st waren, habe ich 300 Millionen Datens\u00e4tze gel\u00f6scht. Ich habe die Tabelle entfernt und f\u00fchlte mich neu geboren.<\/p>\n
Zusammenfassung<\/h2>\n
\nMir wurde klar, dass beim Batch-Processing das rotate processing \u00fcbersehen wurde, und das war das Hauptproblem. Ein solcher Architekturfefehl f\u00fchrt zu einer v\u00f6lligen Zeitverschwendung. <\/p>\n
Machen Sie sich Gedanken \u00fcber die Last beim Replizieren von Daten, w\u00e4hrend Sie Datens\u00e4tze aus der Datenbank l\u00f6schen? Lassen Sie uns MySQL nicht \u00fcberlasten.<\/p>\n
Diejenigen, die sich gut mit Datenbanken auskennen, werden mit einem solchen Problem sicher nicht konfrontiert. Ich hoffe, dieser Artikel war f\u00fcr die anderen hilfreich.<\/p>\n
Vielen Dank f\u00fcr das Lesen!<\/p>\n
Wir w\u00fcrden uns sehr freuen, wenn Sie uns mitteilen, ob Ihnen dieser Artikel gefallen hat, ob die \u00dcbersetzung verst\u00e4ndlich war und ob er Ihnen hilfreich war.<\/i>
\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0442. \u042f ningenMe, \u0432\u0435\u0431-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a. \u041a\u0430\u043a \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u043d\u0430\u0437\u0432\u0430\u043d\u0438\u0438, \u043c\u043e\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u2014 \u044d\u0442\u043e \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u043e \u0444\u0438\u0437\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0443\u0434\u0430\u043b\u0435\u043d\u0438\u0438 300 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u0437\u0430\u043f\u0438\u0441\u0435\u0439 \u0432 MySQL. \u042f \u0437\u0430\u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043e\u0432\u0430\u043b\u0441\u044f \u044d\u0442\u0438\u043c, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0440\u0435\u0448\u0438\u043b \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043f\u0430\u043c\u044f\u0442\u043a\u0443 (\u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u044e). \u041d\u0430\u0447\u0430\u043b\u043e \u2014 Alert \u0412 \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0435, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044f \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e \u0438 \u043e\u0431\u0441\u043b\u0443\u0436\u0438\u0432\u0430\u044e, \u0438\u043c\u0435\u0435\u0442\u0441\u044f \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u044b\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043e\u0434\u0438\u043d \u0440\u0430\u0437 \u0432 \u0434\u0435\u043d\u044c \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442 \u0434\u0430\u043d\u043d\u044b\u0435 \u0437\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0439 \u043c\u0435\u0441\u044f\u0446 \u0438\u0437 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-95518","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Geschichte \u00fcber die physische L\u00f6schung von 300 Millionen Datens\u00e4tzen in MySQL | ProHoster","description":"Einf\u00fchrung Hallo. Ich bin ningenMe, Webentwickler. Wie im Titel erw\u00e4hnt, ist meine Geschichte die \u00fcber die physische L\u00f6schung von 300 Millionen Datens\u00e4tzen in MySQL. Ich fand das Thema interessant und habe deshalb beschlossen, eine Anleitung (Memo) zu erstellen. Beginnen wir \u2014 Hinweis: Auf dem Batch-Server, den ich benutze und verwalte, gibt es einen regelm\u00e4\u00dfigen Prozess, der einmal t\u00e4glich die Daten des letzten Monats sammelt aus","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u043e \u0444\u0438\u0437\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0443\u0434\u0430\u043b\u0435\u043d\u0438\u0438 300 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u0437\u0430\u043f\u0438\u0441\u0435\u0439 \u0432 MySQL | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0442. \u042f ningenMe, \u0432\u0435\u0431-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a. \u041a\u0430\u043a \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u043d\u0430\u0437\u0432\u0430\u043d\u0438\u0438, \u043c\u043e\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u2014 \u044d\u0442\u043e \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u043e \u0444\u0438\u0437\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0443\u0434\u0430\u043b\u0435\u043d\u0438\u0438 300 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u0437\u0430\u043f\u0438\u0441\u0435\u0439 \u0432 MySQL. \u042f \u0437\u0430\u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043e\u0432\u0430\u043b\u0441\u044f \u044d\u0442\u0438\u043c, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0440\u0435\u0448\u0438\u043b \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043f\u0430\u043c\u044f\u0442\u043a\u0443 (\u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u044e). \u041d\u0430\u0447\u0430\u043b\u043e \u2014 Alert \u0412 \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0435, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044f \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e \u0438 \u043e\u0431\u0441\u043b\u0443\u0436\u0438\u0432\u0430\u044e, \u0438\u043c\u0435\u0435\u0442\u0441\u044f \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u044b\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043e\u0434\u0438\u043d \u0440\u0430\u0437 \u0432 \u0434\u0435\u043d\u044c \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442 \u0434\u0430\u043d\u043d\u044b\u0435 \u0437\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0439 \u043c\u0435\u0441\u044f\u0446 \u0438\u0437","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-30T17:42:27+00:00","article:modified_time":"2020-09-30T17:42:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"95518","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:04:40","updated":"2026-02-09 21:38:05"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/95518","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=95518"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/95518\/revisions"}],"predecessor-version":[{"id":159882,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/95518\/revisions\/159882"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=95518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=95518"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=95518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}