{"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\/it\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","title":{"rendered":"Una storia di cancellazione fisica di 300 milioni di record in MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduzione<\/h2>\n

\nCiao. Sono ningenMe, sviluppatore web.<\/p>\n

Come dice il titolo, la mia storia \u00e8 quella di una rimozione fisica di 300 milioni di record in MySQL.<\/p>\n

Sono stato interessato a questo, quindi ho deciso di preparare un promemoria (istruzioni).<\/p>\n

Inizio - Alert<\/h2>\n

\nNel batch server<\/a>, che utilizzo e gestisco, c'\u00e8 un processo regolare che una volta al giorno raccoglie i dati dell'ultimo mese da MySQL. <\/p>\n

Di solito, questo processo termina dopo circa 1 ora, ma questa volta non si \u00e8 concluso per 7 o 8 ore, e l'alert continuava a comparire... <\/a><\/noindex><\/p>\n

Ricerca della causa<\/h2>\n

\nHo provato a riavviare il processo, a controllare i log, ma non ho visto nulla di preoccupante.
\nLa query era indicizzata correttamente. Ma quando ho riflettuto su cosa stesse andando storto, ho capito che le dimensioni del database erano piuttosto grandi. <\/p>\n

hoge_table | 350'000'000 |<\/code><\/pre>\n
\n350 milioni di record. Sembra che l'indicizzazione funzionasse correttamente, solo molto lentamente.<\/p>\n
La raccolta di dati richiesta per il mese ammontava a circa 12.000.000 di record. Sembra che il comando select abbia impiegato molto tempo e la transazione non sia stata eseguita per lungo tempo. <\/p>\n
DB<\/h2>\n
\nFondamentalmente, \u00e8 una tabella che cresce ogni giorno di circa 400.000 record. Il database avrebbe dovuto raccogliere dati solo per l'ultimo mese, quindi il calcolo era fatto affinch\u00e9 sopportasse proprio quel volume di dati, ma sfortunatamente, l'operazione di rotation non era attivata.<\/p>\n
Questo database non \u00e8 stato progettato da me. L'ho ricevuto da un altro sviluppatore, quindi c'\u00e8 la sensazione che si tratti di un debito tecnico. <\/p>\n
\u00c8 arrivato il momento in cui il volume dei dati inseriti quotidianamente \u00e8 diventato elevato e ha finalmente raggiunto un limite. Si presume che, lavorando con un volume cos\u00ec grande di dati, sia necessario suddividerli, ma purtroppo questo non \u00e8 stato fatto.<\/p>\n
E qui sono intervenuto io.<\/p>\n
Correzione<\/h2>\n
\nEra pi\u00f9 razionale ridurre il database stesso e ridurre il tempo necessario per elaborarlo piuttosto che cambiare la logica stessa.<\/p>\n
La situazione dovrebbe cambiare notevolmente se si eliminano 300 milioni di record, quindi ho deciso di farlo... Ah, pensavo che avrebbe funzionato di certo.<\/p>\n
Azione 1<\/h2>\n
\nDopo aver preparato un backup affidabile, ho finalmente iniziato a inviare le query.<\/p>\n
\u300cInvio della query\u300d<\/p>\n
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u300c\u2026\u300d<\/p>\n
\u300c\u2026\u300d<\/p>\n
\u201cHmm... Nessuna risposta. Magari il processo sta impiegando molto tempo?\u201d \u2014 pensai, ma per scrupolo guardai in grafana e vidi che il carico del disco stava aumentando molto rapidamente. 
\n\u00abPericoloso\u00bb \u2014 pensai di nuovo e subito fermai la query.<\/p>\n
Azione 2<\/h2>\n
\nAnalizzando tutto, ho capito che il volume dei dati era troppo grande per eliminarli tutti in una sola volta.<\/p>\n
Ho deciso di scrivere uno script che potesse eliminare circa 1.000.000 di record e l'ho avviato.<\/p>\n
\u300crealizzer\u00f2 lo script\u300d<\/p>\n
\u201cAdesso funzioner\u00e0 sicuramente,\u201d pensai.<\/p>\n
Azione 3<\/h2>\n
\nIl secondo metodo ha funzionato, ma si \u00e8 rivelato molto laborioso.
\nPer fare tutto in modo ordinato, senza nervosismi, ci sarebbero volute circa due settimane. Tuttavia, questo scenario non soddisfaceva i requisiti di servizio, quindi ho dovuto abbandonarlo.<\/p>\n
Perci\u00f2, ecco cosa ho deciso di fare:<\/p>\n
Copiare la tabella e rinominarla<\/h3>\n
\nDallo step precedente ho capito che eliminare un volume cos\u00ec grande di dati crea un carico altrettanto elevato. Quindi ho deciso di creare una nuova tabella da zero usando insert e trasferirci i dati che intendevo eliminare.<\/p>\n
| hoge_table     | 350'000'000|\n| tmp_hoge_table |  50'000'000|<\/code><\/pre>\n
\nSe creo una nuova tabella delle stesse dimensioni di quella sopra, la velocit\u00e0 di elaborazione dei dati dovrebbe aumentare di 1\/7.<\/p>\n
Creata la tabella e rinominata, ho cominciato a usarla come tabella master. Ora, se elimino la tabella con 300 milioni di record, dovrebbe andare tutto bene.
\nHo appreso che truncate o drop creano un carico minore rispetto a delete e ho deciso di utilizzare questo metodo.<\/p>\n
Esecuzione<\/h3>\n
\n\u300cInvio della query\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\u2026\u300d
\n\u300c\u2026\u300d
\n\u300cem\u2026\uff1f\u300d<\/p>\n
Azione 4<\/h2>\n
\nPensavo che l'idea precedente avrebbe funzionato, ma dopo aver inviato la richiesta di insert \u00e8 comparso un errore multiplo. MySQL non guarda in faccia a nessuno.<\/p>\n
Ero cos\u00ec stanco che ho iniziato a pensare che non avrei pi\u00f9 voluto occuparmene.<\/p>\n
Ho riflettuto un po' e ho capito che, forse, per una sola volta erano troppe le richieste di insert\u2026
\nHo provato a inviare una richiesta di insert per il volume di dati che il database deve elaborare in un giorno. Ci sono riuscito!<\/p>\n
E dopo questo continuiamo ad inviare richieste per lo stesso volume di dati. Poich\u00e9 dobbiamo rimuovere il volume mensile di dati, ripetiamo questa operazione circa 35 volte.<\/p>\n
Rinominare la tabella <\/h3>\n
\nQui la fortuna era dalla mia parte: tutto \u00e8 andato liscio.<\/p>\n
Gli Alert sono scomparsi<\/h3>\n
\nLa velocit\u00e0 di elaborazione in batch \u00e8 aumentata.<\/p>\n
In precedenza, questo processo durava circa un'ora, ora ci vogliono circa 2 minuti. <\/p>\n
Dopo essermi assicurato che tutti i problemi fossero risolti, ho eliminato 300 milioni di record. Ho rimosso la tabella e mi sono sentito rinato.<\/p>\n
Riassunto<\/h2>\n
\nHo capito che nel processo batch \u00e8 stata trascurata la rotazione e questo era il problema principale. Un tale errore nell'architettura porta a una perdita di tempo. <\/p>\n
Ti sei mai chiesto il carico durante la replica dei dati, rimuovendo record dal database? Non sovraccarichiamo MySQL.<\/p>\n
Coloro che comprendono bene i database non si troveranno certamente ad affrontare tale problema. Spero che questo articolo sia stato utile agli altri.<\/p>\n
Grazie per aver letto!<\/p>\n
Saremmo molto felici se ci dicessi se ti \u00e8 piaciuto questo articolo, se la traduzione \u00e8 stata chiara e se ti \u00e8 stata utile.<\/i>
\n
Fonte: 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\udd47Storia sulla cancellazione fisica di 300 milioni di record in MySQL | ProHoster","description":"Introduzione Ciao.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/95518","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=95518"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/95518\/revisions"}],"predecessor-version":[{"id":159882,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/95518\/revisions\/159882"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=95518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=95518"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=95518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}