{"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\/fr\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","title":{"rendered":"Une histoire sur la suppression physique de 300 millions d'enregistrements dans MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduction<\/h2>\n

\nBonjour. Je suis ningenMe, d\u00e9veloppeur web.<\/p>\n

Comme indiqu\u00e9 dans le titre, mon histoire est celle de la suppression physique de 300 millions d'enregistrements dans MySQL.<\/p>\n

Je me suis int\u00e9ress\u00e9 \u00e0 ce sujet, alors j'ai d\u00e9cid\u00e9 de r\u00e9diger une note (mode d'emploi).<\/p>\n

D\u00e9but - Alerte<\/h2>\n

\nDans le lot le serveur<\/a>, que j'utilise et maintiens, il existe un processus r\u00e9gulier qui collecte les donn\u00e9es du mois dernier dans MySQL une fois par jour. <\/p>\n

En g\u00e9n\u00e9ral, ce processus se termine en environ 1 heure, mais cette fois, il n'a pas abouti pendant 7 ou 8 heures, et l'alerte a continu\u00e9 \u00e0 appara\u00eetre... <\/a><\/noindex><\/p>\n

Recherche de la cause<\/h2>\n

\nJ'ai essay\u00e9 de red\u00e9marrer le processus, de v\u00e9rifier les logs, mais je n'ai rien vu d'inqui\u00e9tant.
\nLa requ\u00eate \u00e9tait correctement index\u00e9e. Mais en r\u00e9fl\u00e9chissant \u00e0 ce qui pourrait clocher, j'ai r\u00e9alis\u00e9 que la taille de la base de donn\u00e9es \u00e9tait assez grande. <\/p>\n

hoge_table | 350'000'000 |<\/code><\/pre>\n
\n350 millions d'enregistrements. Il semble que l'indexation fonctionnait correctement, juste tr\u00e8s lentement.<\/p>\n
La collecte de donn\u00e9es pour le mois requi\u00e8rait environ 12 000 000 d'enregistrements. Il semble que la commande select ait pris beaucoup de temps, et la transaction n'a pas \u00e9t\u00e9 ex\u00e9cut\u00e9e pendant longtemps. <\/p>\n
DB<\/h2>\n
\nEn fait, il s'agit d'une table qui augmente d'environ 400 000 enregistrements chaque jour. La base de donn\u00e9es aurait d\u00fb collecter uniquement les donn\u00e9es du mois dernier, donc on s'attendait \u00e0 ce qu'elle puisse g\u00e9rer ce volume, mais malheureusement, l'op\u00e9ration de rotation n'\u00e9tait pas activ\u00e9e.<\/p>\n
Cette base de donn\u00e9es n'a pas \u00e9t\u00e9 d\u00e9velopp\u00e9e par moi. Je l'ai re\u00e7ue d'un autre d\u00e9veloppeur, donc il reste un sentiment de dette technique. <\/p>\n
Il est arriv\u00e9 un moment o\u00f9 le volume des donn\u00e9es ins\u00e9r\u00e9es quotidiennement est devenu important et a finalement atteint la limite. On suppose que lorsqu'on travaille avec un grand volume de donn\u00e9es, il faudrait les diviser, mais cela n'a pas \u00e9t\u00e9 fait.<\/p>\n
Et c'est l\u00e0 que j'interviens.<\/p>\n
Correction<\/h2>\n
\nIl \u00e9tait plus judicieux de r\u00e9duire la base de donn\u00e9es elle-m\u00eame et de diminuer le temps de traitement plut\u00f4t que de changer la logique.<\/p>\n
La situation devrait changer consid\u00e9rablement si je supprime 300 millions d'enregistrements, donc j'ai d\u00e9cid\u00e9 de le faire... Ah, je pensais que cela fonctionnerait certainement.<\/p>\n
Action 1<\/h2>\n
\nApr\u00e8s avoir pr\u00e9par\u00e9 une sauvegarde fiable, j'ai enfin commenc\u00e9 \u00e0 envoyer des requ\u00eates.<\/p>\n
\u300cEnvoi de la requ\u00eate\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\u2026 Pas de r\u00e9ponse. Peut-\u00eatre que le processus prend beaucoup de temps ?\u201d \u2014 pensais-je, mais par pr\u00e9caution, j'ai jet\u00e9 un \u0153il sur Grafana et vu que la charge du disque augmentait tr\u00e8s rapidement. 
\n\u00abC'est risqu\u00e9\u00bb \u2014 pensais-je encore une fois et j'ai imm\u00e9diatement arr\u00eat\u00e9 la requ\u00eate.<\/p>\n
Action 2<\/h2>\n
\nApr\u00e8s avoir analys\u00e9 le tout, j'ai r\u00e9alis\u00e9 que le volume de donn\u00e9es \u00e9tait trop important pour tout supprimer d'un coup.<\/p>\n
J'ai d\u00e9cid\u00e9 d'\u00e9crire un script qui pourrait supprimer environ 1 000 000 d'enregistrements et je l'ai lanc\u00e9.<\/p>\n
\u300cje r\u00e9alise le script\u300d<\/p>\n
\u00ab\u00c7a va fonctionner cette fois\u00bb, pensais-je.<\/p>\n
Action 3<\/h2>\n
\nLa deuxi\u00e8me m\u00e9thode a fonctionn\u00e9, mais s'est av\u00e9r\u00e9e tr\u00e8s laborieuse.
\nPour tout faire proprement, sans stress, cela prendrait environ deux semaines. Cependant, ce sc\u00e9nario ne correspondait pas aux exigences de service, donc j'ai d\u00fb abandonner.<\/p>\n
Donc, voici ce que j'ai d\u00e9cid\u00e9 de faire :<\/p>\n
Nous copions la table et la renommons.<\/h3>\n
\n\u00c0 partir de l'\u00e9tape pr\u00e9c\u00e9dente, j'ai compris que la suppression d'un si grand volume de donn\u00e9es cr\u00e9e une charge tout aussi importante. Par cons\u00e9quent, j'ai d\u00e9cid\u00e9 de cr\u00e9er une nouvelle table \u00e0 partir de z\u00e9ro avec insert et d'y d\u00e9placer les donn\u00e9es que je comptais supprimer.<\/p>\n
| hoge_table     | 350'000'000|\n| tmp_hoge_table |  50'000'000|<\/code><\/pre>\n
\nSi je cr\u00e9e une nouvelle table de la m\u00eame taille que celle indiqu\u00e9e ci-dessus, la vitesse de traitement des donn\u00e9es devrait \u00e9galement \u00eatre 1\/7 plus rapide.<\/p>\n
Apr\u00e8s avoir cr\u00e9\u00e9 la table et l'avoir renomm\u00e9e, j'ai commenc\u00e9 \u00e0 l'utiliser comme table ma\u00eetresse. Maintenant, si je supprime la table avec 300 millions d'enregistrements, tout devrait bien se passer.
\nJ'ai appris que truncate ou drop cr\u00e9e moins de charge que delete, et j'ai d\u00e9cid\u00e9 d'utiliser cette m\u00e9thode.<\/p>\n
Ex\u00e9cution<\/h3>\n
\n\u300cEnvoi de la requ\u00eate\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\u300c\u00e9m\u2026\uff1f\u300d<\/p>\n
Action 4<\/h2>\n
\nJe pensais que l'id\u00e9e pr\u00e9c\u00e9dente fonctionnerait, mais apr\u00e8s avoir envoy\u00e9 la requ\u00eate d'insertion, un message d'erreur multiple est apparu. MySQL ne fait pas de cadeaux.<\/p>\n
J'\u00e9tais tellement fatigu\u00e9 que j'ai commenc\u00e9 \u00e0 penser que je ne voulais plus m'en occuper.<\/p>\n
J'ai r\u00e9fl\u00e9chi un moment et pens\u00e9 que peut-\u00eatre pour une seule fois, il y avait trop de requ\u00eates d'insertion\u2026
\nJ'ai essay\u00e9 d'envoyer une requ\u00eate d'insertion pour le volume de donn\u00e9es que la base doit traiter en un jour. \u00c7a a fonctionn\u00e9 !<\/p>\n
Eh bien, apr\u00e8s cela, nous continuons \u00e0 envoyer des requ\u00eates pour le m\u00eame volume de donn\u00e9es. Comme il faut supprimer le volume mensuel de donn\u00e9es, nous r\u00e9p\u00e9tons cette op\u00e9ration environ 35 fois.<\/p>\n
Renommage de la table <\/h3>\n
\nIci, la chance \u00e9tait de mon c\u00f4t\u00e9 : tout s'est bien pass\u00e9.<\/p>\n
Les alertes ont disparu.<\/h3>\n
\nLa vitesse de traitement par lots a augment\u00e9.<\/p>\n
Auparavant, ce processus prenait environ une heure, maintenant il ne prend plus qu'environ 2 minutes. <\/p>\n
Apr\u00e8s avoir v\u00e9rifi\u00e9 que tous les probl\u00e8mes \u00e9taient r\u00e9solus, j'ai supprim\u00e9 300 millions d'enregistrements. J'ai effac\u00e9 la table et je me suis senti rena\u00eetre.<\/p>\n
R\u00e9sum\u00e9<\/h2>\n
\nJ'ai compris que lors du traitement par lots, le traitement des rotations avait \u00e9t\u00e9 n\u00e9glig\u00e9, et c'\u00e9tait l\u00e0 le principal probl\u00e8me. Une telle erreur d'architecture conduit \u00e0 un gaspillage de temps. <\/p>\n
Vous demandez-vous quelle sera la charge lors de la r\u00e9plication des donn\u00e9es en supprimant des enregistrements de la base ? \u00c9vitons de surcharger MySQL.<\/p>\n
Ceux qui ont une bonne ma\u00eetrise des bases de donn\u00e9es ne rencontreront certainement pas ce probl\u00e8me. J'esp\u00e8re que cet article a \u00e9t\u00e9 utile au reste.<\/p>\n
Merci pour votre lecture !<\/p>\n
Nous serions tr\u00e8s heureux que vous nous disiez si cet article vous a plu, si la traduction est claire et si elle vous a \u00e9t\u00e9 utile ?<\/i>
\n
Source : 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\udd47Histoire de la suppression physique de 300 millions d'enregistrements dans MySQL | ProHoster","description":"Introduction Bonjour.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/95518","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=95518"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/95518\/revisions"}],"predecessor-version":[{"id":159882,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/95518\/revisions\/159882"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=95518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=95518"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=95518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}