{"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\/pl\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","title":{"rendered":"Historia o fizycznym usuni\u0119ciu 300 milion\u00f3w rekord\u00f3w w MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wprowadzenie<\/h2>\n

\nCze\u015b\u0107. Jestem ningenMe, web developer.<\/p>\n

Jak wskazuje tytu\u0142, moja historia to opowie\u015b\u0107 o fizycznym usuni\u0119ciu 300 milion\u00f3w rekord\u00f3w w MySQL.<\/p>\n

Zainteresowa\u0142em si\u0119 tym, wi\u0119c postanowi\u0142em stworzy\u0107 notatk\u0119 (instrukcj\u0119).<\/p>\n

Pocz\u0105tek \u2014 Alert<\/h2>\n

\nW pakiecie serwerze<\/a>, kt\u00f3ry u\u017cywam i utrzymuj\u0119, jest regularny proces, kt\u00f3ry raz dziennie zbiera dane z ostatniego miesi\u0105ca z MySQL. <\/p>\n

Zazwyczaj ten proces ko\u0144czy si\u0119 w ci\u0105gu oko\u0142o 1 godziny, ale tym razem nie ko\u0144czy\u0142 si\u0119 przez 7 lub 8 godzin, a alert wci\u0105\u017c si\u0119 pojawia\u0142... <\/a><\/noindex><\/p>\n

Szukaj\u0105c przyczyny<\/h2>\n

\nPr\u00f3bowa\u0142em zrestartowa\u0107 proces, sprawdzi\u0107 logi, ale nie zauwa\u017cy\u0142em nic powa\u017cnego.
\nZapytanie by\u0142o poprawnie indeksowane. Lecz gdy zastanowi\u0142em si\u0119, co mo\u017ce by\u0107 nie tak, zda\u0142em sobie spraw\u0119, \u017ce rozmiar bazy danych jest do\u015b\u0107 du\u017cy. <\/p>\n

hoge_table | 350'000'000 |<\/code><\/pre>\n
\n350 milion\u00f3w rekord\u00f3w. Wygl\u0105da na to, \u017ce indeksacja dzia\u0142a\u0142a poprawnie, po prostu bardzo wolno.<\/p>\n
Wymagany zbi\u00f3r danych za miesi\u0105c wynosi\u0142 oko\u0142o 12 000 000 rekord\u00f3w. Wygl\u0105da na to, \u017ce polecenie select zaj\u0119\u0142o du\u017co czasu, a transakcja d\u0142ugo nie by\u0142a wykonywana. <\/p>\n
DB<\/h2>\n
\nW zasadzie to tabela, kt\u00f3ra ka\u017cdego dnia zwi\u0119ksza si\u0119 o oko\u0142o 400 000 rekord\u00f3w. Baza powinna zbiera\u0107 dane tylko za ostatni miesi\u0105c, wi\u0119c zak\u0142adano, \u017ce wytrzyma ten wolumin danych, ale niestety operacja rotate nie by\u0142a w\u0142\u0105czona.<\/p>\n
Ta baza danych nie zosta\u0142a stworzona przeze mnie. Przej\u0105\u0142em j\u0105 od innego dewelopera, dlatego pozosta\u0142o odczucie istnienia d\u0142ugu technicznego. <\/p>\n
Nadszed\u0142 moment, gdy wolumen codziennie wstawianych danych sta\u0142 si\u0119 du\u017cy i w ko\u0144cu osi\u0105gn\u0105\u0142 limit. Zak\u0142ada si\u0119, \u017ce pracuj\u0105c z takim du\u017cym woluminem danych, nale\u017cy je dzieli\u0107, ale niestety to nie zosta\u0142o zrobione.<\/p>\n
I wtedy do akcji wkroczy\u0142em ja.<\/p>\n
Naprawa<\/h2>\n
\nRozs\u0105dniej by\u0142o zmniejszy\u0107 sam\u0105 baz\u0119 danych i skr\u00f3ci\u0107 czas jej przetwarzania, ni\u017c zmienia\u0107 sam\u0105 logik\u0119.<\/p>\n
Sytuacja powinna si\u0119 znacznie zmieni\u0107, je\u015bli usun\u0119 300 milion\u00f3w rekord\u00f3w, wi\u0119c postanowi\u0142em to zrobi\u0107... Ech, my\u015bla\u0142em, \u017ce to na pewno zadzia\u0142a.<\/p>\n
Akcja 1<\/h2>\n
\nPo przygotowaniu solidnej kopii zapasowej w ko\u0144cu zacz\u0105\u0142em wysy\u0142a\u0107 zapytania.<\/p>\n
\u300cWysy\u0142anie zapytania\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
\u201cHmm\u2026 Brak odpowiedzi. Mo\u017ce proces zajmuje du\u017co czasu?\u201d \u2014 pomy\u015bla\u0142em, ale dla pewno\u015bci spojrza\u0142em na grafana i zobaczy\u0142em, \u017ce obci\u0105\u017cenie dysku szybko ros\u0142o. 
\n\u201eTo troch\u0119 niebezpieczne\u201d \u2014 pomy\u015bla\u0142em jeszcze raz i natychmiast zatrzyma\u0142em zapytanie.<\/p>\n
Dzia\u0142anie 2<\/h2>\n
\nPo przeanalizowaniu wszystkiego zrozumia\u0142em, \u017ce obj\u0119to\u015b\u0107 danych by\u0142a zbyt du\u017ca, aby usun\u0105\u0107 wszystko naraz.<\/p>\n
Postanowi\u0142em napisa\u0107 skrypt, kt\u00f3ry b\u0119dzie m\u00f3g\u0142 usun\u0105\u0107 oko\u0142o 1 000 000 rekord\u00f3w i uruchomi\u0142em go.<\/p>\n
\u300crealizuj\u0119 skrypt\u300d<\/p>\n
\u201eTeraz na pewno zadzia\u0142a\u201d \u2014 pomy\u015bla\u0142em.<\/p>\n
Dzia\u0142anie 3<\/h2>\n
\nDruga metoda zadzia\u0142a\u0142a, ale okaza\u0142a si\u0119 bardzo czasoch\u0142onna.
\nAby zrobi\u0107 to wszystko dok\u0142adnie, bez zb\u0119dnego stresu, potrzeba by\u0142oby oko\u0142o dw\u00f3ch tygodni. Niemniej jednak ten scenariusz nie spe\u0142nia\u0142 wymaga\u0144 serwisowych, wi\u0119c musia\u0142em z niego zrezygnowa\u0107.<\/p>\n
Dlatego oto, co postanowi\u0142em zrobi\u0107:<\/p>\n
Kopiujemy tabel\u0119 i zmieniamy jej nazw\u0119.<\/h3>\n
\nZ poprzedniego kroku zrozumia\u0142em, \u017ce usuni\u0119cie tak du\u017cej obj\u0119to\u015bci danych stwarza tak du\u017c\u0105 obci\u0105\u017cenie. Dlatego postanowi\u0142em stworzy\u0107 now\u0105 tabel\u0119 od zera za pomoc\u0105 insert i przenie\u015b\u0107 do niej dane, kt\u00f3re zamierza\u0142em usun\u0105\u0107.<\/p>\n
| hoge_table     | 350'000'000|\n| tmp_hoge_table |  50'000'000|<\/code><\/pre>\n
\nJe\u015bli utworzymy now\u0105 tabel\u0119 o rozmiarze takim jak podano powy\u017cej, pr\u0119dko\u015b\u0107 przetwarzania danych r\u00f3wnie\u017c powinna by\u0107 o 1\/7 szybsza.<\/p>\n
Utworzywszy tabel\u0119 i zmieniaj\u0105c jej nazw\u0119, zacz\u0105\u0142em u\u017cywa\u0107 jej jako tabeli master (podstawowej). Teraz, je\u015bli usun\u0119 tabel\u0119 z 300 milionami rekord\u00f3w, wszystko powinno by\u0107 w porz\u0105dku.
\nDowiedzia\u0142em si\u0119, \u017ce truncate lub drop powoduj\u0105 mniejsze obci\u0105\u017cenie ni\u017c delete i postanowi\u0142em u\u017cy\u0107 tej metody.<\/p>\n
Wykonywanie<\/h3>\n
\n\u300cWysy\u0142anie zapytania\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\u300cem…\uff1f\u300d<\/p>\n
Dzia\u0142anie 4<\/h2>\n
\nMy\u015bla\u0142em, \u017ce poprzedni pomys\u0142 zadzia\u0142a, ale po wys\u0142aniu zapytania insert pojawi\u0142o si\u0119 wiele b\u0142\u0119d\u00f3w. MySQL nie oszcz\u0119dza.<\/p>\n
Ju\u017c by\u0142em tak zm\u0119czony, \u017ce zacz\u0105\u0142em my\u015ble\u0107, \u017ce nie chc\u0119 si\u0119 ju\u017c tym zajmowa\u0107.<\/p>\n
Siedzia\u0142em, my\u015bla\u0142em i zrozumia\u0142em, \u017ce mo\u017ce by\u0142o za du\u017co zapyta\u0144 insert na raz\u2026
\nSpr\u00f3bowa\u0142em wys\u0142a\u0107 zapytanie insert na obj\u0119to\u015b\u0107 danych, kt\u00f3r\u0105 baza powinna przetwarza\u0107 przez jeden dzie\u0144. Uda\u0142o si\u0119!<\/p>\n
Po tym kontynuujemy wysy\u0142anie zapyta\u0144 na t\u0119 sam\u0105 obj\u0119to\u015b\u0107 danych. Poniewa\u017c trzeba usun\u0105\u0107 miesi\u0119czn\u0105 obj\u0119to\u015b\u0107 danych, powtarzamy t\u0119 operacj\u0119 oko\u0142o 35 razy.<\/p>\n
Zmiana nazwy tabeli <\/h3>\n
\nTutaj szcz\u0119\u015bcie by\u0142o po mojej stronie: wszystko posz\u0142o g\u0142adko.<\/p>\n
Alerty znikn\u0119\u0142y.<\/h3>\n
\nSzybko\u015b\u0107 przetwarzania wsadowego wzros\u0142a.<\/p>\n
Wcze\u015bniej ten proces zajmowa\u0142 oko\u0142o godziny, teraz trwa oko\u0142o 2 minut. <\/p>\n
Po tym, jak upewni\u0142em si\u0119, \u017ce wszystkie problemy zosta\u0142y rozwi\u0105zane, usun\u0105\u0142em 300 milion\u00f3w rekord\u00f3w. Usun\u0105\u0142em tabel\u0119 i poczu\u0142em si\u0119 jak na nowo narodzony.<\/p>\n
Podsumowanie<\/h2>\n
\nZrozumia\u0142em, \u017ce w przetwarzaniu wsadowym przeoczono przetwarzanie rotacji, co stanowi\u0142o g\u0142\u00f3wny problem. Taki b\u0142\u0105d w architekturze prowadzi do marnowania czasu. <\/p>\n
Czy zastanawiasz si\u0119 nad obci\u0105\u017ceniem podczas replikacji danych, usuwaj\u0105c rekordy z bazy? Nie przeci\u0105\u017cajmy MySQL.<\/p>\n
Osoby, kt\u00f3re dobrze znaj\u0105 si\u0119 na bazach danych, na pewno nie napotkaj\u0105 takiego problemu. Mam nadziej\u0119, \u017ce ten artyku\u0142 by\u0142 pomocny dla pozosta\u0142ych.<\/p>\n
Dzi\u0119kujemy za przeczytanie!<\/p>\n
B\u0119dziemy bardzo wdzi\u0119czni, je\u015bli opowiesz nam, czy podoba\u0142 Ci si\u0119 ten artyku\u0142, czy t\u0142umaczenie by\u0142o zrozumia\u0142e i czy by\u0142o pomocne.<\/i>
\n
\u0179r\u00f3d\u0142o: 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\udd47Historia o fizycznym usuni\u0119ciu 300 milion\u00f3w rekord\u00f3w w MySQL | ProHoster","description":"Wprowadzenie Cze\u015b\u0107.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/95518","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=95518"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/95518\/revisions"}],"predecessor-version":[{"id":159882,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/95518\/revisions\/159882"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=95518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=95518"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=95518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}