DELETE היקר. ניקולאי Samokhvalov (Postgres.ai)

מתישהו בעתיד הרחוק, הסרה אוטומטית של נתונים מיותרים תהיה אחת המשימות החשובות של ה-DBMS [1]. בינתיים אנחנו בעצמנו צריכים לדאוג למחיקת או להעביר נתונים מיותרים למערכות אחסון זולות יותר. נניח שהחלטת למחוק כמה מיליוני שורות. משימה פשוטה למדי, במיוחד אם המצב ידוע ויש אינדקס מתאים. "DELETE FROM table1 WHERE col1 = :value" - מה יכול להיות יותר פשוט, נכון?

וידאו:

• אני בוועדת תכנית Highload מהשנה הראשונה, כלומר משנת 2007.

• ואני עם Postgres מאז 2005. השתמש בו בפרויקטים רבים.

• קבוצה עם RuPostges גם מאז 2007.

• גדלנו ל-2100+ משתתפים ב-Meetup. היא שנייה בעולם אחרי ניו יורק, שסאן פרנסיסקו עקפה אותה במשך זמן רב.

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

https://postgres.ai/ היא החברה שלי. אנחנו עוסקים באוטומציה של משימות שמבטלות האטות בפיתוח.

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

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

יש יותר ויותר נתונים בעולם הזטה-בייט - זה 1 פטה-בייט. ועכשיו כבר מעריכים שיש לנו יותר מ-000 זטה-בייט של נתונים מאוחסנים בעולם. ויש עוד ועוד כאלה.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

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

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

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

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

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

ויש לנו בקשה כזו, עליה נדבר היום, כלומר על פינוי אשפה.

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

מסד הנתונים גדל וגדל. ה-DELETE היומי מתחיל לעבוד קצת יותר לאט.

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

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

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

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

משהו השתבש? הנה רשימה של מה שיכול היה להשתבש. מה מבין אלה הוא החשוב ביותר?

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

• אולי הם בדקו משהו לא בסדר.

• אולי החומרה מיושנת ואתה צריך לשדרג את הבסיס הזה.

• או שמשהו לא בסדר במסד הנתונים עצמו, ואנחנו צריכים לעבור מ-Postgres ל-MySQL.

• או שאולי יש משהו לא בסדר בניתוח.

• אולי יש כמה טעויות בארגון העבודה ואתה צריך לפטר מישהו ולהעסיק את האנשים הטובים ביותר?

לא היה בדיקת DBA. אם היה DBA, הוא היה רואה את כמה מיליוני שורות אלה ואפילו בלי שום ניסויים היה אומר: "הם לא עושים את זה". נניח שאם הקוד הזה היה ב-GitLab, GitHub והיה תהליך סקירת קוד ולא היה דבר כזה שללא אישור ה-DBA הפעולה הזו הייתה מתרחשת ב-Prod, אז ברור שה-DBA היה אומר: "לא ניתן לעשות את זה. ."

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

http://bit.ly/nancy-hl2018-2

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

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

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

אולי הציוד שלנו גרוע? אם תסתכל, אז האחזור קפץ. ראינו שהניצול הוא 100%. כמובן, אם אלו היו כונני NVMe מודרניים, כנראה שזה היה הרבה יותר קל עבורנו. ואולי לא נשכב מזה.

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

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

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

ההגדרות ב-Postgres נשארות מאחור. הם מיועדים לנפחים בני 10-15 של נתונים ועסקאות. ומחסום אינו יוצא מן הכלל.

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

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

וכברירת מחדל, max_wal_saze מוגדר ל-1 גיגה-בייט. למעשה, זה באמת קורה ב-Postgres אחרי 300-400 מגה-בייט. שינית כל כך הרבה נתונים והמחסום שלך קורה.

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

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

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

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

הסדרה הראשונה - אנו משנים את max_wal_size. ואנחנו עושים מבצע ענק. ראשית, אנו עושים זאת בהגדרת ברירת המחדל של 1 גיגה-בייט. ואנחנו מבצעים DELETE מאסיבי של מיליוני קווים רבים.

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

בשלב הבא נגדיל את max_wal_size. אנחנו חוזרים. אנחנו מגדילים, אנחנו חוזרים. וכל כך הרבה פעמים. באופן עקרוני, 10 נקודות זה טוב, כאשר 1, 2, 4, 8 גיגה-בייט. ואנחנו מסתכלים על ההתנהגות של מערכת מסוימת. ברור שכאן הציוד צריך להיות כמו בפרוד. אתה חייב להיות בעל אותם דיסקים, אותה כמות זיכרון ואותן הגדרות Postgres.

ובדרך זו נחליף את המערכת שלנו, ואנחנו יודעים איך ה-DBMS יתנהג במקרה של מסה גרועה DELETE, איך הוא יעמוד במחסום.

מחסום ברוסית הם מחסומים.

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

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

אם מבצע כזה יתאפשר בדחיפה, אז פשוט נשכב, כי ברור ש-DELETE אחד הורג אותנו בגדוד.

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

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

למה כל כך?

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

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

ואנו נאלץ את המחסום להציל אותו פעמים רבות. איך יהיו פעולות מיותרות עבורו.

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

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

בשינויים הבאים, יהיה רק ​​tuple ספציפי, אבל בפעם הראשונה אנחנו רושמים הכל.

ובהתאם לכך, אם המחסום קרה שוב, אז עלינו להתחיל הכל מאפס מחדש ולדחוף את כל העמוד. עם מחסומים תכופים, כאשר אנו עוברים על אותם דפים, full_page_writes = on יהיה יותר ממה שהוא יכול להיות, כלומר אנו מייצרים יותר WAL. עוד נשלח לרפליקות, לארכיון, לדיסק.

ובהתאם לכך, יש לנו שתי יתירות.

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

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

אנחנו עושים מבצע ורואים מתי המחסום עומד להסתיים, אנחנו כן הורגים -9 Postgres בכוונה.

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

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

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

והנה נקודה מעניינת. יש לנו כמה דיווחים על פטרוני בכנס. ואולי אתה משתמש בזה. זהו כשל אוטומטי עבור Postgres. GitLab ו-Data Egret דיברו על זה.

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

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

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

כדי לבצע איטרציות, למשל, max_wal_size =1, 8, עליך לחזור על פעולת המסה פעמים רבות. עשית זאת. ועל אותו בסיס אתה רוצה לעשות את זה שוב, אבל כבר מחקת הכל. מה לעשות?

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

אבל במקרה הזה, היה לנו מזל. אם, כמו שכתוב כאן "BEGIN, DELETE, ROLLBACK", אז נוכל לחזור על DELETE. כלומר, אם ביטלנו את זה בעצמנו, אז נוכל לחזור על זה. ובאופן פיזי אצלך הנתונים יהיו באותו מקום. אתה אפילו לא מקבל שום נפיחות. אתה יכול לחזור על מחיקות כאלה.

DELETE זה עם ROLLBACK אידיאלי לכוונון נקודות ביקורת, גם אם אין לך מעבדות מסד נתונים פרוסות כהלכה.

הכנו צלחת עם עמודה אחת "i". ל-Postgres יש עמודות שירות. הם בלתי נראים אלא אם כן ביקשו זאת במפורש. אלה הם: ctid, xmid, xmax.

Ctid היא כתובת פיזית. עמוד אפס, הטפול הראשון בעמוד.

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

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

זה לגבי מתכנתים. גם לגבי DBA תמיד נוזפים במתכנתים על זה: "למה אתה עושה פעולות כל כך ארוכות וקשות?". זה נושא ניצב אחר לגמרי. פעם היה מינהל, ועכשיו יהיה פיתוח.

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

למה חשוב לשבור?

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

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

https://postgres.ai/products/joe/

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

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

יש לי כלל מאוד פשוט: קח כמה שאתה יכול, אבל אל תעבור על קובצי הפעלה בשנייה.

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

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

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

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

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

מהן אסטרטגיות מחיצות? אני רואה 3 אסטרטגיות חלוקה שונות שהמפתחים בחבילה משתמשים בהן.

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

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

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

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

בדרך כלל, סריקת אינדקס בלבד מהירה יותר מסריקת אינדקס.

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

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

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

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

אבל זו האסטרטגיה הכי אופטימלית, איך לפצל לקבוצות ולירות באצווה בבקשה אחת, למחוק קצת וכו'.

עסקאות ארוכות https://gitlab.com/snippets/1890447

שאיבה אוטומטית חסומה - https://gitlab.com/snippets/1889668

בעיית חסימה - https://gitlab.com/snippets/1890428

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

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

אם יש IO גדול, אז ברור שזה לא טוב.

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

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

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

ומוציא בלוקים. יער של עצי בלוקים. אני אוהב לקחת משהו ממישהו ולשפר אותו. כאן לקחתי CTE רקורסיבי מגניב מ-Data Egret שמראה יער של עצי נעילה. זהו כלי אבחון טוב. ועל בסיסו, ניתן גם לבנות ניטור. אבל זה חייב להיעשות בזהירות. אתה צריך לעשות statement_timeout קטן לעצמך. ו-lock_timeout רצוי.

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

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

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

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

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

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

מה שאנחנו עושים זה קוד פתוח. זה פורסם ב-GitLab. ואנחנו עושים את זה כך שאנשים יוכלו לבדוק גם בלי DBA. אנחנו עושים מעבדת מסד נתונים, כלומר קוראים לרכיב הבסיס עליו ג'ו עובד כרגע. ואתה יכול לתפוס עותק של ההפקה. עכשיו יש יישום של Joe ל-slack, אתה יכול להגיד שם: "הסבר בקשה כזו ואחרת" ומיד לקבל את התוצאה עבור העותק שלך של מסד הנתונים. אתה יכול אפילו למחוק שם, ואף אחד לא ישים לב לזה.

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

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

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

היום אתה יכול ללכת ל postgres.ai ולחפור בכלים שלנו. אפשר להירשם כדי לראות מה יש. אתה יכול להתקין את הבוט הזה. זה בחינם. לִכתוֹב.

שאלות

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

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

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

אם אתה מסתכל על pg_repack ב-GitHub, אז שם, כשהייתה משימה להמיר מזהה מ-int 4 ל-int 8, אז היה רעיון להשתמש ב-pg_repack עצמו. זה גם אפשרי, אבל זה קצת פריצה, אבל זה יעבוד גם בשביל זה. אתה יכול להתערב בטריגר שבו pg_repack משתמש ולהגיד שם: "אנחנו לא צריכים את הנתונים האלה", כלומר אנחנו מעבירים רק את מה שאנחנו צריכים. ואז הוא פשוט מחליף וזהו.

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

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

אני רק קצת מעולם MySQL, אז באתי להקשיב. ואנחנו משתמשים בגישה הזו.

אבל זה רק אם יש לנו 90%. אם יש לנו 5%, אז זה לא ממש טוב להשתמש בו.

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

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

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

אם אמרנו ב-SQL למחוק או לעדכן רשומות רבות בטרנזקציה אחת, אז איך Postgres יכולה להפיץ את זה שם? אנחנו מוגבלים פיזית בפעולות. אנחנו עדיין נעשה את זה עוד הרבה זמן. וננעל בזמן הזה וכו'.

נעשה עם אינדקסים.

אני יכול להניח שאותו כוונון מחסום יכול להיות אוטומטי. מתישהו זה יכול להיות. אבל אז אני לא ממש מבין את השאלה.

השאלה היא האם יש וקטור כזה של התפתחות שהולך לכאן ולכאן, וכאן שלך הולך במקביל? הָהֵן. הם עוד לא חשבו על זה?

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

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

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

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

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

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

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

זה מה ש-autovacuum עושה אוטומטית ב-Postgres.

אה, הוא עושה את זה?

אוטווואקום הוא אוסף האשפה.

תודה לך!

תודה על הדיווח! האם יש אפשרות לעצב מיידית מסד נתונים עם חלוקה למחיצות בצורה כזו שכל הזבל יתלכלך מהשולחן הראשי איפשהו לצד?

כמובן שיש.

האם אפשר אם כן להגן על עצמנו אם נעלנו שולחן שאסור להשתמש בו?

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

מקור: www.habr.com