הסיפור של מחיקה פיזית של 300 מיליון רשומות ב-MySQL

מבוא

שלום. אני ningenMe, מפתח אתרים.

כפי שהכותרת אומרת, הסיפור שלי הוא הסיפור של מחיקה פיזית של 300 מיליון רשומות ב-MySQL.

התעניינתי בזה, אז החלטתי לעשות תזכורת (הוראות).

בית - התראה

לשרת האצווה שאני משתמש ומתוחזק בו יש תהליך קבוע שאוסף את הנתונים של החודש האחרון מ-MySQL פעם ביום.

בדרך כלל תהליך זה מסתיים תוך כשעה, אך הפעם הוא לא הסתיים במשך 1 או 7 שעות, וההתראה לא הפסיקה לצוץ...

מחפש סיבה

ניסיתי להפעיל מחדש את התהליך ולהסתכל על היומנים, אבל לא ראיתי שום דבר לא בסדר.
השאילתה נוספה לאינדקס כהלכה. אבל כשחשבתי מה משתבש, הבנתי שגודל מסד הנתונים די גדול.

hoge_table | 350'000'000 |

350 מיליון רשומות. נראה היה שהאינדקס עובד כמו שצריך, רק איטי מאוד.

איסוף הנתונים הנדרש לחודש היה כ-12 רשומות. נראה שפקודת הבחירה ארכה זמן רב והעסקה לא בוצעה במשך זמן רב.

DB

זה בעצם טבלה שגדלה בכ-400 כניסות מדי יום. בסיס הנתונים היה אמור לאסוף נתונים רק עבור החודש האחרון, לכן היה צפוי שהוא יעמוד בדיוק בכמות הנתונים הזו, אך למרבה הצער, פעולת הסיבוב לא נכללה.

מסד הנתונים הזה לא פותח על ידי. לקחתי את זה ממפתח אחר, אז זה עדיין הרגיש כמו חוב טכני.

הגיע שלב שבו נפח הנתונים שהוכנס מדי יום הפך גדול ולבסוף הגיע לקצה גבול היכולת. ההנחה היא שכאשר עובדים עם כמות כה גדולה של נתונים, יהיה צורך להפריד ביניהם, אך הדבר, למרבה הצער, לא נעשה.

ואז נכנסתי לפעולה.

תיקון

זה היה יותר רציונלי להקטין את גודל בסיס הנתונים עצמו ולצמצם את זמן העיבוד שלו מאשר לשנות את ההיגיון עצמו.

המצב אמור להשתנות באופן משמעותי אם תמחק 300 מיליון רשומות, אז החלטתי לעשות זאת... אה, חשבתי שזה בהחלט יעבוד.

פעולה 1

לאחר שהכנתי גיבוי אמין, סוף סוף התחלתי לשלוח בקשות.

「שליחת בקשה」

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

"..."

"..."

"הממ... אין תשובה. אולי התהליך לוקח הרבה זמן?" - חשבתי, אבל ליתר בטחון, הסתכלתי על גראפנה וראיתי שעומס הדיסקים גדל מהר מאוד.
"מסוכן", חשבתי שוב ומיד הפסקתי את הבקשה.

פעולה 2

לאחר ניתוח הכל, הבנתי שנפח הנתונים גדול מכדי למחוק הכל בבת אחת.

החלטתי לכתוב תסריט שיכול למחוק כ-1 רשומות והשקתי אותו.

「אני מיישם את התסריט」

"עכשיו זה בהחלט יעבוד," חשבתי.

פעולה 3

השיטה השנייה עבדה, אבל התבררה כרוכה מאוד בעבודה.
לעשות הכל בזהירות, בלי עצבים מיותרים, ייקח בערך שבועיים. אבל עדיין, התרחיש הזה לא עמד בדרישות השירות, אז נאלצנו להתרחק ממנו.

אז הנה מה שהחלטתי לעשות:

העתק את הטבלה ושנה את שמה

מהשלב הקודם הבנתי שמחיקת כמות כל כך גדולה של נתונים יוצרת עומס גדול לא פחות. אז החלטתי ליצור טבלה חדשה מאפס באמצעות insert ולהעביר אליה את הנתונים שאני עומד למחוק.

| hoge_table     | 350'000'000|
| tmp_hoge_table |  50'000'000|

אם תהפוך את הטבלה החדשה לאותו גודל כמו לעיל, גם מהירות עיבוד הנתונים אמורה להיות מהירה יותר ב-1/7.

לאחר יצירת הטבלה ושינוי שמה, התחלתי להשתמש בה בתור הטבלה הראשית. עכשיו אם אני שומט את הטבלה עם 300 מיליון רשומות הכל אמור להיות בסדר.
גיליתי שקטוע או ירידה יוצר פחות תקורה מאשר מחיקה והחלטתי להשתמש בשיטה הזו.

הגשמה

「שליחת בקשה」

INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';

"..."
"..."
"הם...?"

פעולה 4

חשבתי שהרעיון הקודם יעבוד, אבל לאחר שליחת בקשת ההוספה, הופיעו מספר שגיאות. MySQL לא סלחן.

כבר הייתי כל כך עייף שהתחלתי לחשוב שאני לא רוצה לעשות את זה יותר.

ישבתי וחשבתי והבנתי שאולי היו יותר מדי שאילתות הוספה לפעם אחת...
ניסיתי לשלוח בקשה להוספה עבור כמות הנתונים שמסד הנתונים אמור לעבד ביום אחד. קרה!

ובכן, לאחר מכן אנו ממשיכים לשלוח בקשות עבור אותה כמות נתונים. מכיוון שעלינו להסיר נתונים של חודש, אנו חוזרים על הפעולה הזו כ-35 פעמים.

שינוי שם שולחן

כאן המזל היה לצידי: הכל עבר חלק.

התראה נעלמה

מהירות עיבוד האצווה גדלה.

בעבר תהליך זה לקח כשעה, כעת הוא לוקח בערך 2 דקות.

אחרי שהייתי בטוח שכל הבעיות נפתרו, הורדתי 300 מיליון שיאים. מחקתי את הטבלה והרגשתי שנולדתי מחדש.

סיכום

הבנתי שחסר עיבוד רוטציה בעיבוד אצווה, וזו הייתה הבעיה העיקרית. סוג זה של טעות אדריכלית מביא לבזבוז זמן.

האם אתה חושב על העומס במהלך שכפול נתונים בעת מחיקת רשומות ממסד הנתונים? בואו לא נעמיס על MySQL.

מי שבקיא במאגרי מידע בהחלט לא ייתקל בבעיה כזו. לשארכם, אני מקווה שמאמר זה היה שימושי.

תודה שקראת!

נשמח מאוד אם תספר לנו אם אהבת את המאמר הזה, האם התרגום ברור, האם הוא היה שימושי עבורך?

מקור: www.habr.com