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

שלום לכולם. ולדיסלב רודן בקשר. כיום אני מנחה הקורס לקורס High Work Architect ב-OTUS וגם מלמד קורסי ארכיטקטורת תוכנה.

בנוסף להוראה, כפי שאולי שמתם לב, אני כותב חומר מקורי לבלוג OTUS ב-Habré ואני רוצה לחפף עם המאמר של היום במקביל להשקת הקורס "PostgreSQL", הפתוח להרשמה כבר עכשיו.

מבוא

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

בידוד

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

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

כתיבה מלוכלכת

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

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

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

קריאה מלוכלכת

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

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

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

עדכון אבד

עדכון אבוד פירושו עדכונים שאבדו, והתרגום משקף בצורה די מדויקת את מהות הבעיה:

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

הסמן איבד עדכון

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

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

קריאה בלתי חוזרת

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

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

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

קריאת פנטום

Phantom היא קריאה של נתונים שנוספו על ידי עסקה אחרת.

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

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

קרא הטיה

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

נניח שיש לנו טבלאות המייצגות פוסטים ומטא מידע שלהם:

עסקה אחת קוראת מהטבלאות, השנייה משנה אותן:

כתוצאה מעסקה T1, לפוסט יש כותרת = טוב, ו-update_by = T2, שזה סוג של חוסר עקביות.

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

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

כתוב עיוות

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

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

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

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

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

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

ממצאים

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

למידע נוסף על הקורס.

מקור: www.habr.com