המדריך הבסיסי לטרנזאקציות באורקל
הפוסט הזה הוא הכנה לפוסט נוסף על הפרמטר commit_write. מכוון שהמאמר יצא ארוך במיוחד, פיצלתי אותם לשניים. בפוסט הזה נדבר על איך טרנזאקציות עובדות ובפוסט הבא נדבר על איך לעקוף את זה…
אורקל, כמו בסיסי נתונים יחסיים אחרים, מאפשר לנו עבודה עם טרנזאקציות – זה הבסיס למרבית המערכות שמבוססות על בסיסי נתונים. כשאנחנו עובדים עם טרנזאקציה, אנחנו רוצים שהנתונים שלנו ישמרו כמו שצריך אבל איך אנחנו מגדרים "כמו שצריך"?
כדי לענות על השאלה הזו ישבו טובי המומחים באקדמיה והגדירו סטנדרט שנקרא ACID: Atomic, Consistent, Isolation, Durability. כדי להבין מה זה אומר, בואו ונפרק את ההגדרה:
- Atomic– טרנזאקציות ישמרו בצורה של הכול או כלום. אין חצי טרנזאקציה.
- Consistent– אם ביצענו מספר פעולות שתלויות אחת בשנייה אנחנו רוצים שהטרנזאקציה תשמור את הנתונים בצורה אמינה.
- Isolation– כל עוד אנחנו מבצעים טרנזאקציה, אף אחד לא צריך לדעת על זה.
- Durability– אם בסיס הנתונים שלנו נופל, אנחנו רוצים שכל המידע שביצענו לו commit יהיה שם גם אחרי שהוא יעלה בחזרה.
העניין הוא ש-ACID עולה לנו: הוא עולה לנו זמן והוא עולה לנו משאבים. מה קורה אם מה שחשוב לנו זה הביצועים ואנחנו מוכנים לוותר על אחד מעקרונות ה-ACID בתמורה לזמן ולמשאבים?
על פניו, לא מדובר במשהו חדש – כתבתי על זה גם בעבר בנושאים הקשורים ל-NoSQL. בפוסט הזה נדבר על התהליך שקורה מתחת לפני השטח כשעושים טרנזאקציה בבסיס הנתונים. הפוסט הבא יתמקד ב-Durability ואיך ניתן לשחרר קצת את החבל מהבחינה הזו באורקל (מבלי ללכת לפתרונות NoSQL).
לפני שנצלול לעסק, אזהרה: הפוסט הזה מדבר על נושאים שמשפיעים על האמינות של בסיס הנתונים. שינוי הפרמטרים וההתנהגות שיוזכרו בפוסט הזה ובפוסט הבא הן פעולות מסוכנות. אם אתם לא בטוחים במאה אחוזים שהבנתם את הסיכונים שקשורים לפרמטרים האלה, אל תשנו אותם ובכל מקרה אני לא אחראי לתוצאות.
