{"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 \u00fcber die physische 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, Webentwickler.<\/p>\n

Wie im Titel erw\u00e4hnt, ist meine Geschichte eine Geschichte \u00fcber das physische L\u00f6schen von 300 Millionen Datens\u00e4tzen in MySQL.<\/p>\n

Ich habe mich daf\u00fcr interessiert, also entschied ich mich, ein Memo (eine Anleitung) zu erstellen.<\/p>\n

Der Anfang \u2013 Alert<\/h2>\n

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

In der Regel dauert dieser Prozess etwa 1 Stunde, aber diesmal ben\u00f6tigte er 7 oder 8 Stunden, und die Warnungen h\u00f6rten nicht auf ... <\/a><\/noindex><\/p>\n

Die Ursache suchen<\/h2>\n

\nIch habe versucht, den Prozess neu zu starten, die Logs anzusehen, aber ich sah nichts Schlimmes.
\nDie Abfrage wurde korrekt indiziert. Aber als ich nachdachte, was schiefgehen k\u00f6nnte, merkte ich, dass das Datenbankvolumen ziemlich gro\u00df ist. <\/p>\n

hoge_table | 350'000'000 |<\/code><\/pre>\n
\n350 Millionen Datens\u00e4tze. Es scheint, dass die Indizierung korrekt funktionierte, nur sehr langsam.<\/p>\n
Die erforderliche Datensammlung f\u00fcr den Monat betrug etwa 12.000.000 Datens\u00e4tze. Es scheint, dass das Select-Team viel Zeit ben\u00f6tigte, und die Transaktion lange Zeit nicht abgeschlossen wurde. <\/p>\n
DB<\/h2>\n
\nIm Grunde genommen ist es eine Tabelle, die t\u00e4glich um etwa 400.000 Datens\u00e4tze w\u00e4chst. Die Datenbank sollte nur die Daten des letzten Monats sammeln, daher war die Erwartung, dass sie dieses Datenvolumen bew\u00e4ltigen kann, aber leider war die Operation rotate nicht aktiviert.<\/p>\n
Diese Datenbank wurde nicht von mir entwickelt. Ich habe sie von einem anderen Entwickler \u00fcbernommen, daher bleibt das Gef\u00fchl, dass es sich um technische Schulden handelt. <\/p>\n
Der Moment kam, als das Volumen der t\u00e4glich eingef\u00fcgten Daten gro\u00df wurde und schlie\u00dflich an die Grenzen stie\u00df. Es wird erwartet, dass man bei so einem gro\u00dfen Datenvolumen sie aufteilt, aber das wurde leider nicht gemacht.<\/p>\n
Und dann kam ich ins Spiel.<\/p>\n
Behebung<\/h2>\n
\nEs war sinnvoller, die Datenbank selbst zu verkleinern und die Verarbeitungszeit zu reduzieren, als die Logik selbst zu \u00e4ndern.<\/p>\n
Die Situation sollte sich erheblich \u00e4ndern, wenn 300 Millionen Datens\u00e4tze gel\u00f6scht werden, also beschloss ich, dies zu tun ... Ach, ich dachte, das w\u00fcrde sicher funktionieren.<\/p>\n
Aktion 1<\/h2>\n
\nNachdem ich ein zuverl\u00e4ssiges Backup erstellt hatte, begann ich endlich, Abfragen zu senden.<\/p>\n
\u201eAbfrage senden\u201c<\/p>\n
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u201e\u2026\u201c<\/p>\n
\u201e\u2026\u201c<\/p>\n
\u201eHmm\u2026 Keine Antwort. Vielleicht dauert der Prozess zu lange?\u201c \u2013 dachte ich, aber ich schaute vorsichtshalber in Grafana und sah, dass die Festplattenauslastung sehr schnell anstieg. 
\n\u201eGef\u00e4hrlich\u201c \u2013 dachte ich wieder und stoppte sofort die Abfrage.<\/p>\n
Aktion 2<\/h2>\n
\nNachdem ich alles analysiert hatte, wurde mir klar, dass das Datenvolumen zu gro\u00df war, um alles auf einmal zu l\u00f6schen.<\/p>\n
Ich beschloss, ein Skript zu schreiben, das etwa 1.000.000 Datens\u00e4tze l\u00f6schen kann, und startete es.<\/p>\n
\u201eIch werde das Skript umsetzen\u201c<\/p>\n
\u201eJetzt wird es bestimmt funktionieren\u201c, dachte ich.<\/p>\n
Aktion 3<\/h2>\n
\nDie zweite Methode funktionierte, war jedoch sehr arbeitsintensiv.
\nUm alles ordentlich und ohne unn\u00f6tige Nerven zu machen, h\u00e4tte ich ungef\u00e4hr zwei Wochen gebraucht. Dennoch entsprach dieses Szenario nicht den Dienstanforderungen, also musste ich davon absehen.<\/p>\n
Deshalb habe ich Folgendes beschlossen:<\/p>\n
Tabelle kopieren und umbenennen<\/h3>\n
\nAus dem vorherigen Schritt verstand ich, dass das L\u00f6schen eines so gro\u00dfen Datenvolumens ebenso gro\u00dfe Last verursacht. Daher entschloss 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 beschrieben erstelle, sollte die Datenverarbeitungsgeschwindigkeit auch um 1\/7 schneller werden.<\/p>\n
Nachdem ich die Tabelle erstellt und umbenannt hatte, begann ich, sie als Haupttabelle zu verwenden. Nun, wenn ich die Tabelle mit 300 Millionen Datens\u00e4tzen l\u00f6sche, sollte alles in Ordnung sein.
\nIch fand heraus, dass TRUNCATE oder DROP eine geringere Last erzeugen als DELETE, und beschloss, diese Methode zu verwenden.<\/p>\n
Ausf\u00fchrung<\/h3>\n
\n\u201eAbfrage senden\u201c<\/p>\n
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u201e\u2026\u201c
\n\u201e\u2026\u201c
\n\u201eem\u2026?\u201c<\/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 unerbittlich.<\/p>\n
Ich war bereits so m\u00fcde, dass ich zu denken begann, dass ich nicht mehr weitermachen wollte.<\/p>\n
Ich setzte mich hin und \u00fcberlegte und erkannte, dass vielleicht die Anzahl der INSERT-Anfragen f\u00fcr einmal zu hoch war\u2026
\nIch versuchte, eine INSERT-Anfrage f\u00fcr das Datenvolumen zu senden, mit dem die Datenbank an einem Tag umgehen sollte. Es hat funktioniert!<\/p>\n
Und danach senden wir weiterhin Anfragen f\u00fcr das gleiche Datenvolumen. Da wir ein monatliches Datenvolumen entfernen m\u00fcssen, wiederholen wir diese Operation etwa 35 Mal.<\/p>\n
Tabelle umbenennen <\/h3>\n
\nHier hatte ich Gl\u00fcck: Alles lief reibungslos.<\/p>\n
Die Warnungen sind verschwunden.<\/h3>\n
\nDie Geschwindigkeit der Batch-Verarbeitung hat zugenommen.<\/p>\n
Fr\u00fcher dauerte dieser Prozess etwa eine Stunde, jetzt etwa 2 Minuten. <\/p>\n
Nachdem ich mich vergewissert hatte, dass alle Probleme gel\u00f6st waren, habe ich 300 Millionen Datens\u00e4tze gel\u00f6scht. Ich habe die Tabelle entfernt und f\u00fchlte mich wie neu geboren.<\/p>\n
Zusammenfassung<\/h2>\n
\nIch habe verstanden, dass beim Batch-Processing das Rotate-Processing \u00fcbersehen wurde, und das war das Hauptproblem. Ein solcher Fehler in der Architektur f\u00fchrt zu einer sinnlosen Zeitverschwendung. <\/p>\n
Denken Sie an die Last bei der Replikation von Daten, wenn Sie Datens\u00e4tze aus der Datenbank entfernen? Lassen Sie uns MySQL nicht \u00fcberlasten.<\/p>\n
Diejenigen, die sich gut mit Datenbanken auskennen, werden mit einem solchen Problem sicherlich nicht konfrontiert werden. Ich hoffe, dieser Artikel war f\u00fcr die anderen n\u00fctzlich.<\/p>\n
Danke f\u00fcrs 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 sie Ihnen n\u00fctzlich 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 das physische L\u00f6schen von 300 Millionen Datens\u00e4tzen in MySQL | ProHoster","description":"Einf\u00fchrung Hallo.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}