ביטול הנעילה של מנהל המנעולים של Postgres. ברוס ממוג'יאן

תמלול ההרצאה של ברוס Momjian משנת 2020 "ביטול נעילת מנהל המנעול של Postgres".

(הערה: ניתן לקבל את כל שאילתות ה-SQL מהשקופיות מהקישור הזה: http://momjian.us/main/writings/pgsql/locking.sql)

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

שמי הוא ברוס ממוג'יאן. אני עובד ב-EnterpriseDB ועובד עם Postgres כבר למעלה מ-23 שנים. אני גר בפילדלפיה, ארה"ב. אני נוסע בערך 90 ימים בשנה. ואני משתתף בכ-40 כנסים. שֶׁלִי אתר אינטרנט, המכיל את השקופיות שאראה לכם כעת. לכן, לאחר הכנס תוכלו להוריד אותם מהאתר האישי שלי. הוא מכיל גם כ-30 מצגות. יש גם סרטונים ומספר רב של רשומות בבלוג, יותר מ-500. זהו משאב אינפורמטיבי למדי. ואם אתה מעוניין בחומר הזה, אז אני מזמין אותך להשתמש בו.

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

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

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

בואו נדבר על חסימה.

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

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

כאן אנו רואים מונחים שמבלבלים אותי. לדוגמה, SHARE UPDATE ECXLUSIVE. הבא SHARE RAW ECXLUSIVE. למען האמת, השמות האלה לא מאוד ברורים. ננסה לשקול אותם ביתר פירוט. חלקם מכילים את המילה "שיתוף", שפירושה להפריד. חלקם מכילים את המילה "בלעדי". חלקם מכילים את שתי המילים הללו. אני רוצה להתחיל עם איך המנעולים האלה עובדים.

וגם המילה "גישה" חשובה מאוד. והמילים "שורה" הן מחרוזת. כלומר, חלוקת גישה, חלוקת שורות.

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

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

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

http://momjian.us/main/writings/pgsql/locking.sql

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

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

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

ועלינו להבין זאת. זה מאוד חשוב, אחרת לא נוכל להבין נעילה ב-Postgres.

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

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

לכן, אם אני מריץ בקשה, זה אומר שמזהה הקצה האחורי הוא 2.

ואם אני מריץ סדרה של עסקאות כאלה, אז אנחנו רואים שהמונה גדל בכל פעם שאני מריץ שאילתה. לדוגמה, כאשר אני מריץ את השאילתה 2/10, 2/11, 2/12 וכו'.

זכור שיש כאן שתי עמודות. בצד שמאל אנו רואים את מזהה העסקה הוירטואלית - 2/12. ובצד ימין יש לנו מזהה עסקה קבוע. והשדה הזה ריק. והעסקה הזו לא משנה את מסד הנתונים. אז אני לא נותן לזה מזהה עסקה קבוע.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה אם אני מפעיל SELECT ויש לי שלוש טבלאות שונות? בעבר הרצתי רק טבלה אחת, כעת אני מפעיל שלוש: pg_class, pg_namespace ו-pg_attribute.

ועכשיו כשאני מסתכל על השאילתה, אני רואה 9 AccessShareLocks בשלוש טבלאות. למה? שלוש טבלאות מסומנות בכחול: pg_attribute, pg_class, pg_namespace. אבל אתה יכול גם לראות שלכל האינדקסים המוגדרים דרך הטבלאות הללו יש גם AccessShareLock.

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

ROW SHARE - המנעול הזה קצת שונה.

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

אז מה עושה SHARE LOCK? אנו רואים שמזהה העסקה הוא 681 עבור SELECT. וזה מעניין. מה קרה פה? הפעם הראשונה שאנו רואים את המספר היא בשדה "נעילה". אנחנו לוקחים את מזהה העסקה והוא אומר שהוא חוסם אותו במצב בלעדי. זה רק אומר שיש לי שורה שננעלה טכנית איפשהו בטבלה. אבל הוא לא אומר איפה בדיוק. נסתכל על זה ביתר פירוט מעט מאוחר יותר.

כאן אנו אומרים שהמנעול משמש אותנו.

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

SHARE EXCLUSIVE הוא מנעול ארוך יותר.

זוהי פקודת (ANALYZE) מנתח שתשמש.

SHARE LOCK - אתה יכול לנעול באופן מפורש במצב שיתוף.

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

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

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

SHARE ROW בלעדי - שוב ניתן להגדיר אותו במפורש (באופן מפורש).

או שנוכל ליצור כלל, כלומר, לקחת מקרה ספציפי שבו הוא ישמש.

נעילה בלעדית פירושה שאף אחד אחר לא יכול לשנות את הטבלה.

כאן אנו רואים סוגים שונים של מנעולים.

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

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

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

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

בואו נסתכל על כמה דוגמאות ספציפיות.

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

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

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

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

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

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

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

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

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

מה לגבי חסימה מפורשת?

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

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

ואותו דבר, אם נעשה שיתוף, נוכל לעשות הכל 30 פעמים.

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

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

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

ואם אני מסתכל על המזהה האחורי שלי עכשיו, זה עכשיו 695.

ואני יכול לראות 695 מופיעים בטבלה שלי.

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

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

ואתה צריך להקשיב להרצאה שלי ב-MVCC כדי להבין איך זה קורה. אבל זה המחשה שאתה יכול לעשות את זה באותו זמן, כלומר לעשות SELECT ו-UPDATE בו זמנית.

בואו נתאפס ונעשה עוד פעולה אחת.

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

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

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

אבל תסתכל על משהו אחר - 2/51 הוא העסקה הראשונה שלנו, הפגישה הראשונה שלנו. 3/112 היא הבקשה השנייה שהגיעה מלמעלה ששינתה את הערך הזה ל-3. ואם תשים לב, העליונה ננעלה את עצמה, שהיא 699. אבל 3/112 לא העניק את המנעול. העמודה Lock_mode אומרת למה היא מחכה. הוא מצפה ל-699. ואם מסתכלים היכן נמצא 699, הוא גבוה יותר. ומה עשתה הפגישה הראשונה? היא יצרה מנעול בלעדי על מזהה העסקה שלה. כך פוסטגרס עושה את זה. זה חוסם את מזהה העסקה שלו. ואם אתה רוצה לחכות שמישהו יאשר או יבטל, אז אתה צריך לחכות בזמן שיש עסקה ממתינה. ובגלל זה אנחנו יכולים לראות קו מוזר.

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

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

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

וב-lock_type, tuple אתה רואה מספרים.

אתה יכול לראות שזה 0/10. וזהו מספר העמוד, וגם הקיזוז של השורה המסוימת הזו.

ואתה רואה שזה הופך ל-0/11 כשאנחנו מעדכנים.

אבל במציאות זה 0/10, כי יש המתנה למבצע הזה. יש לנו הזדמנות לראות שזו הסדרה שאני מחכה לאשר.

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

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

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

מה אם נעשה שלושה עדכונים בו זמנית ונאמר שהשורה היא כעת שלושה. ונשנה את 3 ל-4.

והנה אנו רואים 4. ומזהה עסקה 702.

ואז אשנה 4 ל-5. ו-5 ל-6, ו-6 ל-7. ואני אסדר מספר אנשים שיחכו לסיום העסקה האחת הזו.

והכל מתבהר. מהי השורה הראשונה? זהו 702. זהו מזהה העסקה שקבע במקור את הערך הזה. מה כתוב בטור ה-Grated שלי? יש לי סימנים f. אלו הם העדכונים שלי שלא ניתן לאשר (5, 6, 7), כי אנחנו מחכים שמזהה עסקה 702 יסתיים. שם יש לנו חסימת מזהה עסקה. וזה מביא ל-5 נעילות מזהה עסקה.

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

כך זה נראה. ברור שכולם מחכים לקו ה-12.

זה מה שראינו כאן. הנה 0/12.

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

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

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

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

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

ועכשיו נתקין שני מבוי סתום. נשים 50 ו-80. בשורה הראשונה אעדכן מ-50 ל-50. אקבל עסקה מספר 710.

ואז אני אשנה 80 ל-81, ו-50 ל-51.

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

ואפילו כתוב באיזו שורה מתרחשים הקיפאון. וכאן זה מתחיל להיות מוזר.

כעת אנו מעדכנים 80 ל-80.

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

וזה פשוט יתחיל לעכב הכל. ואנחנו לא רוצים את זה.

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

האם יש מבוי סתום תלת כיווני? האם זה אפשרי? כן.

אנו מכניסים את המספרים הללו לטבלה. אנחנו משנים 40 ל-40, אנחנו עושים חסימה.

אנו משנים 60 ל-61, 80 ל-81.

ואז נשנה 80 ואז בום!

ו-714 מחכה כעת ל-715. ה-716 מחכה ל-715. ואי אפשר לעשות כלום בנידון.

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

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

הבעיה הבאה ניתנת לסידרה.

אם נעילה מיוחדת הניתנת לסידרה.

ואנחנו חוזרים ל-719. הפלט שלו די נורמלי.

ואתה יכול ללחוץ כדי להפוך את העסקה לניתנת לסידרה.

ואתה מבין שעכשיו יש לך סוג אחר של מנעול SA - זה אומר שניתן לסידרה.

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

וגם אתה יכול להוסיף אינדקסים ייחודיים.

בטבלה זו יש לנו אינדקסים ייחודיים.

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

ואם נעשה עסקאות משנה.

כאן יש לנו 723.

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

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

זוהי יצירה של מנעולים מפורשים (מפורשים), שיש להם pg_advisory_lock.

ואתה רואה שסוג החסימה רשום כמייעץ. וכאן כתוב "מייעצת" באדום. ואתה יכול לחסום כך בו זמנית עם pg_advisory_unlock.

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

וכאן אנו יוצרים pg_stat_view.

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

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

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

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

שאלות:

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

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

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

זה ייראה כמו מנעול בלעדי, נכון?

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

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

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

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

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

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

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

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

אתה יכול לפתוח שקופית 75?

כן.

והשאלה שלי היא הבאה. מדוע שני תהליכי העדכון מצפים ל-703?

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

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

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

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

נראה לי שזה הרבה יותר הגיוני כש-705 מצפה ל-704.

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

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

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

מקור: www.habr.com