{"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":"Storia del ripristino fisico 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 suggerisce il titolo, la mia storia riguarda l'eliminazione fisica di 300 milioni di record in MySQL.<\/p>\n

Mi sono interessato a questo, quindi ho deciso di creare una guida (istruzione).<\/p>\n

Inizio \u2014 Alert<\/h2>\n

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

Di solito, questo processo si completa in circa 1 ora, ma questa volta ha impiegato 7 o 8 ore e l'alert non smetteva di apparire... <\/a><\/noindex><\/p>\n

Cercare la 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 mi sono chiesto cosa non andasse, ho capito che il volume del database era piuttosto grande. <\/p>\n

hoge_table | 350'000'000 |<\/code><\/pre>\n
\n350 milioni di record. Sembra che l'indicizzazione funzionasse correttamente, semplicemente molto lentamente.<\/p>\n
La raccolta di dati richiesta per il mese era di circa 12.000.000 di record. Sembra che la query select abbia richiesto molto tempo e la transazione non si sia completata a lungo. <\/p>\n
DB<\/h2>\n
\nFondamentalmente, \u00e8 una tabella che cresce ogni giorno di circa 400.000 record. Il database doveva raccogliere i dati solo dell'ultimo mese, quindi era previsto che gestisse solo questo volume di dati, ma, sfortunatamente, l'operazione rotate non era attivata.<\/p>\n
Questo database non \u00e8 stato progettato da me. L'ho preso da un altro sviluppatore, quindi \u00e8 rimasta la sensazione di un debito tecnico. <\/p>\n
\u00c8 arrivato un momento in cui il volume dei dati inseriti quotidianamente \u00e8 diventato troppo grande e ha finalmente raggiunto il limite. Si presume che, lavorando con un volume di dati cos\u00ec grande, si debbano dividere, ma purtroppo ci\u00f2 non \u00e8 stato fatto.<\/p>\n
Ed \u00e8 qui che sono intervenuto.<\/p>\n
Correzione<\/h2>\n
\nEra pi\u00f9 razionale ridurre il database stesso e ridurre il tempo di elaborazione piuttosto che cambiare la logica stessa.<\/p>\n
La situazione dovrebbe cambiare notevolmente se cancellassimo 300 milioni di record, quindi ho deciso di procedere\u2026 Ah, pensavo che questo sicuramente avrebbe funzionato.<\/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\u00ab\u2026\u00bb<\/p>\n
\u00ab\u2026\u00bb<\/p>\n
\u201cHmm\u2026 Nessuna risposta. Forse il processo richiede molto tempo?\u201d \u2014 pensai, ma per sicurezza controllai Grafana e vidi che il carico del disco stava aumentando rapidamente. 
\n\u201cPericoloso\u201d \u2014 pensai di nuovo e fermai subito la query.<\/p>\n
Azione 2<\/h2>\n
\nDopo aver analizzato tutto, ho capito che il volume dei dati era troppo grande per eliminare tutto 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
\u300cImplemento lo script\u300d<\/p>\n
\u201cOra sicuramente funzioner\u00e0\u201d, pensai.<\/p>\n
Azione 3<\/h2>\n
\nIl secondo metodo ha funzionato, ma era molto laborioso.
\nPer fare tutto in modo accurato, senza stress inutili, ci sarebbero volute circa due settimane. Ma questo scenario non rispettava i requisiti di servizio, quindi ho dovuto abbandonarlo.<\/p>\n
Quindi, ecco cosa ho deciso di fare:<\/p>\n
Copiamo la tabella e la rinominiamo<\/h3>\n
\nDal passo precedente ho capito che l'eliminazione di un volume cos\u00ec grande di dati crea un carico altrettanto grande. Quindi ho deciso di creare una nuova tabella da zero usando insert e spostarci i dati che intendevo eliminare.<\/p>\n
| hoge_table     | 350'000'000|\n| tmp_hoge_table |  50'000'000|<\/code><\/pre>\n
\nSe crei una nuova tabella della stessa dimensione di quella sopra, la velocit\u00e0 di elaborazione dei dati dovrebbe anche essere 1\/7 pi\u00f9 veloce.<\/p>\n
Creando la tabella e rinominandola, ho iniziato a usarla come tabella master. Ora, se elimino la tabella con 300 milioni di record, tutto dovrebbe andare bene.
\nHo scoperto che truncate o drop creano un carico minore rispetto a delete e ho deciso di usare questo metodo.<\/p>\n
Esecuzione<\/h3>\n
\n\u300cInvio della query\u300d<\/p>\n
INSERT INTO tmp_hoge_table SELECT FROM hoge_table WHERE create_time > 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u00ab\u2026\u00bb
\n\u00ab\u2026\u00bb
\n\u00abem\u2026?\u00bb<\/p>\n
Azione 4<\/h2>\n
\nPensavo che l'idea precedente avrebbe funzionato, ma dopo aver inviato la query insert sono comparsi vari errori. MySQL non perdona.<\/p>\n
Ero cos\u00ec stanco che ho cominciato a pensare che non volessi farlo pi\u00f9.<\/p>\n
Ho riflettuto e ho capito che, forse, per una volta c'erano troppi insert.
\nHo provato a inviare una query insert per il volume di dati che il database doveva elaborare in un giorno. Ce l'ho fatta!<\/p>\n
E dopo questo ho continuato a inviare query per lo stesso volume di dati. Poich\u00e9 dovevo rimuovere il volume mensile di dati, ho ripetuto questa operazione circa 35 volte.<\/p>\n
Rinominare la tabella <\/h3>\n
\nQui la fortuna \u00e8 stata dalla mia parte: \u00e8 andato tutto liscio.<\/p>\n
Gli alert sono scomparsi.<\/h3>\n
\nLa velocit\u00e0 di elaborazione batch \u00e8 aumentata.<\/p>\n
In precedenza, questo processo richiedeva 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 cancellato la tabella e mi sono sentito rinato.<\/p>\n
Riepilogo<\/h2>\n
\nHo capito che nella elaborazione in batch era stata trascurata la rotazione, e questo era il problema principale. Un errore di questo tipo nell'architettura porta a una perdita di tempo inutile. <\/p>\n
Ti preoccupa il carico durante la replicazione dei dati quando elimini le voci dal database? Evitiamo di sovraccaricare MySQL.<\/p>\n
Coloro che hanno una buona conoscenza dei database sicuramente non si imbatteranno in questo problema. Spero che questo articolo sia stato utile per gli altri.<\/p>\n
Grazie per la lettura!<\/p>\n
Saremmo molto felici se ci dicessi se ti \u00e8 piaciuto questo articolo, se la traduzione \u00e8 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 sull'eliminazione fisica di 300 milioni di voci 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}]}}